[master] RFR: Smaller class pointers [v3]

[Thomas Stuefe]

On Wed, 8 Dec 2021 18:47:47 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback Ioi, fix CDS archive size estimate
>
> Also, FTR, there are other ways to keep cache density without the extra add/xor step of smearing M-shifted bits.  It would require deeper cuts, but it is worth thinking again of the thing you already mentioned, where a Klass block is split into a fixed-sized "near Klass" and an indirectly addressed "far Klass".  The near Klass would be sized as a small number of cache blocks, to keep Klass metadata dense in the data cache.  There is a sensitive performance tradeoff, though, since you want parts of the Klass which are accessed frequently (dynamic type checks, vtables, GC metadata) to be in the near Klass.  Since v-tables are variable in size, this means some v-table entries (probably) get favored over others.  Tricky business.  I think Coleen looked into this many years ago and may have further insights.
> 
> Independently, a possible future benefit of a near-Klass/far-Klass split would be that we could consider building in a one-to-many relation across the linking indirection.  That could support a tightly integrated "species" concept, where an object's header can point to a near-Klass which represents an individuated species of its class.  In theory that could help represent specialized types like ArrayList<int> as distinct from the erased class ArrayList.

Since I did not hear back from  @rose00, @rkennke did ask me to speed this up and I have vacation looming, I decided to push. There is nothing we could not possibly revert later, but it gives us 22 bit class pointers for now and we can work with that.

Thanks @rkennke,  @iklam and @rose00 for the feedback!

-------------

PR: https://git.openjdk.java.net/lilliput/pull/13