Plans to reduce object header size

[mcpiroman]

As far as I know, in .NET objects of classes have 12 byte header, similarly to JVM.
Now, the OpenJDK started a project Lilliput aiming to reduce the header size to 8 or 4 bytes.
Was maybe an analogous feature considered for .NET?

[teo-tsirpanis]

A caveat when considering to add JVM optimizations to .NET is that JVM and .NET are very different runtimes. JVM does not have structs, spans, pointers and byrefs, which forces applications to to create a lot more garbage, with fewer avenues to reduce them. That's why JVM has stuff that .NET hasn't yet, like escape analysis and fancy pauseless garbage collectors; it needs them more to band-aid its inherent design limitations.

I'm not saying that we should not innovate and add these features, but their urgency and value they would bring is different than in JVM and we should independently evaluate them and the tradeoffs they would bring. And I can see quite the tradeoffs with compressing the object header; for one they would make virtual methods slower.

[jkotas]

I can see quite the tradeoffs with compressing the object header; for one they would make virtual methods slower.

Also, it would make garbage collection to take longer and Monitor-style locks slower. There is more discussion about some of the tradeoffs involved in #34812. We believe that one of the pre-requisites for experimenting with this is to introduce first class Lock type discussed in #34812 and start using it on performance critical paths instead of the implicit object lock.

[svick]

As I understand it, on a 64-bit system, an object consists of:

• 4 bytes padding (byte offset -8)
• 4 bytes object header (byte offset -4)
• 8 bytes method table pointer (byte offset 0)
• object fields
• usually 0-7 bytes of padding

What I've been wondering: is all the padding necessary? I get that the method table pointer has to be 8-byte aligned, but that could still be achieved without having the 4 bytes of padding at the start of every object, no?

As an example, consider allocating two objects, each with a single byte field. Today, it looks like this:

 0       4      8      16   17      24      28     32     40   41      
+-------+------+------+----+-------+-------+------+------+----+-------+
|padding|header|MT ptr|data|padding|padding|header|MT ptr|data|padding|
+----------------------------------+----------------------------------+
|o1                                |o2                                |
+----------------------------------+----------------------------------+

Couldn't it look like this instead, saving 4 bytes?

 0       4      8      16   17      20     24     32   33      
+-------+------+------+----+-------+------+------+----+-------+
|padding|header|MT ptr|data|padding|header|MT ptr|data|padding|
+----------------------------------+--------------------------+
        |o1                        |o2                        |
        +--------------------------+--------------------------+

Though I can imagine that this would make heap compaction somewhat harder and potentially less efficient.

Alternatively, maybe the object header could be moved to offset 8, which would mean that the 4 bytes of padding would be available for the object layout algorithm instead?

[jkotas]

4 bytes padding (byte offset -8)

GC team has some plans to put this padding to a good use to make GC faster. I remember discussion about it, but I do not remember the details of the design.