Sharing the markword (aka Valhalla's markword use)

[Kennke, Roman]

>>> We have a plan how we can make the class-pointer much smaller. Based on the
>>> observation that most workloads only require a few 10000 classes, let’s say 15
>>> bits is ‘enough’ and not wasteful. Workloads that require more often generate
>>> those classes, which often don’t have many instances (e.g. only 1). In order to
>>> address arbitrary many classes, we would require one more bit that indicates
>>> that the class-pointer should be loaded from a dedicated field - this could be
>>> compressed 32 bits, or uncompressed 64 bits, or somehow be combined with the 15
>>> class-bits from the header
>> 
>> I shall add that this is possible because we know at class-loading time whether
>> or not we’re going to exceed the class-addressing-limit, and reserve the extra
>> Klass* field at class-loading time, during field layout, and allocate all
>> affected instances with that extra field right from the start, no stunts needed
>> like with the compact I-hash stuff.
> 
> and
> 
>> Using those 16 class-bits, and assuming 2(hash)+4(Valhalla)+4(age)+3(locking),
>> we’d still have a reserve of 3 bits. We could use them for more classes, or
>> reserve them for future use. It does not seem unreasonable to make the
>> class-bits even smaller, in case we ever need more bits.
> 
> If you have 2 bits for the hash, you need the compact identity hash optimization too.
> So splitting the classpointer to save more bits is a third optimization.
> 
> Liliput 64 uses compressed classpointer (22 bits) and lightweight locking,
> Liliput 32 uses compact identity hash (2 bits) with storage inflation on demand (plus all the above),
> Liliput 16 uses split classpointer (plus all the above).

Not quite.

Lilliput 64 uses 22 bit compressed class-pointer, 31 bits I-hash and 4 age, 4 Valhalla, 1 self-forwarding and 2 lock bits.

Lilliput 32 would use 16 (possibly up to 19) bits class-pointer, 2 I-hash-bits, and the others same as above.

We don’t currently have plans for Lilliput 16. While that may be possible, I would expect diminishing returns because of extra efforts (CPU cycles and/or out-of-heap storage) to squeeze the bits.

Roman





Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879