[master] RFR: Smaller class pointers [v3]

[John R Rose]

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.

FTR (16 months later!) my comments were future-oriented and I am happy with the progress this push made.  Some of those comments may help reduce risk of class ID overflow later on.

I personally think it would be interesting to experiment with a version of this change which makes `MaxNarrowKlassPointerBits` a command-line configurable value, and then (as a follow-on) undertakes to deal with overflow by adding a second injected field (with a full 32 bits) to impacted layouts, but not to layouts of the “favored” classes, which will usually be the majority.

The C++ access code would be slightly slower.  And the extra injected field requires a usually-not-taken branch to a not-so-fast path that picks up the injected overflow bits.

Such an experiment would help make stress-tests (with very small MNKPB values).  It could facilitate experiments with different header layouts, even 32-bit layouts, or maybe hoisting (some or all) klass bits into 64-bit oops.

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

PR Comment: https://git.openjdk.org/lilliput/pull/13#issuecomment-1515071487