Is it possible to reimplement 64-bit object header based on improved i-hash?

[Kennke, Roman]

Hi Glavo,

> Just a whim: Is it possible to reimplement 64-bit object header based on improved i-hash?
> Compared to JEP 450, I feel like this seems more suitable as the default behavior of the JVM.
> This will not limit the number of classes and will reserve enough bits in the mark word for new GC or other things.
> It will also be easier to expand to 64-bit/128-bit i-hash in the future.
> I think it's a perfect evolution of the current 96-bit object header.
> 

Only very few applications, if any, would benefit from having more classes (>500.000 currently). However, *almost all* applications would benefit from smaller 4-byte headers. It seems an obvious trade-off to choose 4-byte headers. We do have a plan how to support more classes, if that’s necessary, but to be honest, I currently doubt that any application reaches that limit.

> As for Lilliput 2, although it is very good, it reserves too few bits for mark words.

No, I don’t think so. We currently even reserve 4 bits for future work coming from Valhalla, and Valhalla may not even need them all. And I would not keep around spare bits just in case that we ever need them. We did have spare bits in the header ever since 64 bit JVMs became a thing (pre-dating OpenJDK), and they have never been used. What’s not available can’t be used, period, and we need to find ways to deal with such situations when they arise. It doesn’t make sense to punish ourselves now, just in case we need something later, which may well never happen at all.

> Therefore, even if it is delivered, a 64-bit object header implementation may be retained for a long time in the future to cope with possible future needs.

Nope. If and when 4-byte headers are delivered, we will get rid of any old implementation eventually.

Cheers,
Roman