[Mono-devel-list] [PATCH] Field Layout Optimization
Ben Maurer
bmaurer at users.sourceforge.net
Sun Mar 14 18:24:17 EST 2004
Hello,
The following patch optimizes the layout of fields both for object
instances and for static data.
The patch does two things:
Create a better autolayout:
Right now, we do a `GC aware' layout that places object
references at the beginning of the object. However we can do
better.
Lets say you have the following class:
class T {
bool a;
long b;
bool c;
long d;
}
We lay out the class as follows (. is padding):
a.......bbbbbbbbc.......dddddddd
However, obviously we are wasting alot of space with padding.
This patch makes the class get laid out as:
ab......bbbbbbbbdddddddd
Omit literal data from static memory:
Right now, if you have a literal field (const in C#), the field
is stored in memory. However the CLI spec says `In contrast to
initonly fields, literal fields do not exist at runtime. There
is no memory allocated for them. literal fields become part of
the metadata but cannot be accessed by the code'. This patch
implements that behavior. For MCS bootstrap, this reduces the
static memory by 2kb, from 7kb to 5kb.
As well, a command line option is added to mini, --print-class-layout.
This prints the physical layout of every class the runtime uses. Some
sample output is:
> Layout for System.Type
> Instance:
> 0 - 8 <parent> (MemberInfo)
> 8 - 12 _impl (System.RuntimeTypeHandle)
> Static:
> 0 - 4 EmptyTypes (System.Type[])
> 4 - 8 FilterAttribute (System.Reflection.MemberFilter)
> 8 - 12 FilterName (System.Reflection.MemberFilter)
> 12 - 16 FilterNameIgnoreCase (System.Reflection.MemberFilter)
> 16 - 20 Missing (System.Object)
> 20 - 22 Delimiter (System.Char)
This was very helpful to me while designing the patch, and I hope it
might be of aid to hackers in the future.
A ChangeLog:
* class.[ch]:
- (mono_print_class_layout) A global variable to signal that
layout tables should be printed
- (mono_class_layout_fields) Optimize field layout. For instance
fields, reference fields are placed first, then sorted by
alignment requirements. For static fields, just sorted by
alignment requirmeents. Also, literal fields are not included in
the static layout plan.
- (print_class_layout) a utility function to print class layout.
* icall.c, reflection.c:
- account for api changes.
* object.[ch]:
- (get_default_field_value) A helper to get a fields default
value, as stored in the metadata.
- (mono_class_vtable) Account for api changes; Assert that a
field being RVA based is mutually exclusive with having a
default value, do not place literal fields in the static data
area.
- (mono_field_static_set_value) assert that a constant is not
being set.
- (mono_field_static_get_value) get literal values directly from
the metadata.
- (mono_ldstr_metdata_sig) load a string from *anywhere* in the
metadata. A generalization of mono_ldstr.
- (mono_ldstr) call mono_ldstr_metdata_sig
Open issues:
* Is the assertion that being rva based and having a default value
are mutually exclusive correct? It would not be logical to have
both.
* What should mono_field_static_set_value when it tries to set a
const value?
* Is it correct to load strings that are stored in literal fields
as interned. The reason I did this was to ensure that we dont
create a string on each access (which is incorrect). However, I
am not sure if it shoudl be interned.
This patch caused no regressions on corlib tests, mono/tests or the mini
regression tests.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mini-print-class-layout.patch
Type: text/x-patch
Size: 1218 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040314/1b024d72/attachment.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: metadata-auto-layout.patch
Type: text/x-patch
Size: 22173 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040314/1b024d72/attachment-0001.bin
More information about the Mono-devel-list
mailing list