[Mono-devel-list] [PATCH] Field Layout Optimization

[Torstensson, Patrik]

Have you tested performance with the new field layout?

If I get this correctly you put two bools together, right? So it's
ac...... Or?

Remember that there is penalties for reading memory that is not dword
aligned, so performance will probably be affected by your patch. Don't
see why padding is 8 bytes but what do I know.. :-)

-- Patrik

-----Original Message-----
From: mono-devel-list-admin at lists.ximian.com
[mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of Ben Maurer
Sent: den 15 mars 2004 00:24
To: Mono Development
Subject: [Mono-devel-list] [PATCH] Field Layout Optimization

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.