3 ms·

In practice (IIRC, I'd have to check again to be 100% sure) there's a little 'extra garbage' (my name, the real name is something else) pointer inside .NET obje

In practice (IIRC, I'd have to check again to be 100% sure) there's a little 'extra garbage' (my name, the real name is something else) pointer inside .NET object headers, and if your object has an identity hashcode or has been used with locking, the extra garbage pointer points to a separate heap allocation containing the hashcode and the locking info. That way you're not paying for it for every object. I think in some cases there are optimizations to be able to store the hashcode inline (tagging, etc). So it ends up being similar to these 'compact object headers' described here in terms of size but is done by making those optional features more expensive instead of by bitpacking stuff into the object header. Caveat: There are multiple .NET implementations so what I've said may not apply to all of them

mike_hearn 4y ago
As the JEP explains, the JVM has done both those things for a long time. In particular the object doesn't actually pay the price of a lock unless it's actually locked at some point. It used to be the case that the JVM was even more extreme and you wouldn't pay the price of a lock unless the object was actually contended, this was called biased locking, but the code complexity to implement it was eventually determined to be no longer worth it on modern hardware.