Reducing class pointer size useful?

[Thomas Stüfe]

Hi Roman,

On Mon, Sep 13, 2021 at 4:19 PM Roman Kennke <rkennke at redhat.com> wrote:

> Hi Thomas,
>
> Yes, indeed, this would be very helpful!
>
> The current state of the prototype is that I'm putting the compressed
> Klass* in the upper 32bit of the header. (The original Klass* is still
> currently present in the 2nd word, but unused, except for verification
> purposes.) The layout is basically: 32bits for Klass*, 26bits for the
> hashcode, and 6 bits for the rest (locking and GC). Here it would be
> nice to have 32bit hashcodes instead, and 26bits for the Klass*.
>
>
Understood.


> I'm also working on moving the hashcode out of the header, requiring
> only 2 bits for managing the hashcode state, which makes it very
> reasonable to consider header sizes of 32bit: 24bits for the Klass* and
> 8 bits for GC+locking+hashcode.
>
> So yes, any mechanims to reduce the Klass* to 24bits (maybe with some
> flexibility in case we need more bits, e.g. for Loom or Valhalla) would
> be very welcome. My thinking went in very similar direction as you
> indicated (larger alignments for the Klass objects), and John Rose
> sketched some more ideas in his reply.
>
> Are you planning to work on this?
>

Of the three steps I sketched out:
- getting the class space to use its separate alignment, and make it
tweakable
- getting the various encoding functions to work (again?) with arbitrary
shifts
- getting CDS to work with larger alignments

I'll tackle the first, then maybe the second. After that, we hopefully are
able to work with arbitrary alignments for Klass and it should work at
least with Xshare:off.

(Note: metaspace-wise I think the largest alignment which would not cause
larger ripples would be 1K, since that is the smallest chunk size, but that
should be plenty)

Let's see how this goes. Maybe I'm wrong and it does not work, but then we
know.

Cheers, Thomas


>
> Thanks,
> Roman
>
>
> > Hi,
> >
> > Would it be of use for Lilliput to shrink the class pointer size beyond
> 32
> > bit? I did not closely follow the discussions. Therefore I am not sure
> > where the current thinking goes.
> >
> > If yes, maybe we could reduce the pointer size not only by reducing the
> > encoding range but by using larger alignments.
> >
> > We encode with add-and-shift, as we do with compressed oops.
> Traditionally
> > the shift was 3, since sizeof(void*) is the alignment requirement for
> > metaspace allocations. This shift was used to enlarge the coverage of
> class
> > pointer encoding from 4GB to 32GB (KlassEncodingMetaspaceMax). But we
> never
> > used this to my knowledge since we limit class space size to 3GB at most.
> > And nobody needs 32GB class space anyway. So there was never a reason to
> > cover more than (3GB + <cds size>). Unless I missed something, the shift
> > had been useless. In fact, we recently removed the shift if CDS is on
> > (JDK-8265705) to solve an unrelated aarch64 issue, and nothing bad
> happened.
> >
> > But we could use the shift, not to enlarge the encoding range but to
> reduce
> > the class pointer size. And we could use a larger shift value. For
> example,
> > let's say we shift 8 bits. Then cut off those bits and reduce the class
> > pointer to 24 bits.
> >
> > The resulting alignment would be 256 bytes. Applied to all metaspace
> > allocations such an alignment would be prohibitively expensive, since
> most
> > allocations are very small. But if we apply this larger alignment to the
> > class space only, leave the rest of the metaspace alone, it is not so
> bad.
> > Before JEP 387, using different alignments would have been difficult to
> > implement, but metaspace coding is much more modular now, and using
> > different alignments for the different regions can be done.
> >
> > So we apply the larger alignment only to Klass structures. Klass
> structures
> > are large, and the relative loss due to alignment would matters less.
> They
> > are variable-sized but sizes are clustered between ~512 bytes and ~1K.
> They
> > can get much larger than that, but that is rare. Alignment loss would be
> > between 0-255 bytes, lets say on average 127. For a typical larger app of
> > 10000 classes, this would waste ~1.2MB. If that is acceptable depends on
> > what positive effect the smaller compressed class pointer has on project
> > Lilliput.
> >
> > ---
> >
> > One could argue that using an 8 bit shifted class pointer emans it stops
> > being a pointer and becomes an index into a table of 256-byte-slots,
> > populated with variable-sized Klass structures. With Klass sizes
> clustered
> > between 512 bytes..1K each Klass would populate 2..4 slots on average.
> The
> > 24-bit pointer is enough to address 16mio slots, hence on average 4..8
> > million Klass structures, still covering a 4G total range.
> >
> > We could further slim down the class pointer if we agree on a lower
> maximum
> > number of classes. E.g. with 22 bits, we could address 4mio slots and
> house
> > about 500k...1mio classes, still allowing for a maximum encoding range of
> > 1G.
> >
> > We could play around with these variables. E.g. a larger shift of 10
> bits -
> > 1KB alignment - would mean most Klass structures occupy just one slot, we
> > would have to live a somewhat higher alignment waste of 0...1024, but now
> > can reduce the encoded class pointer to 20 bits, still being able to
> > address 1 mio slots resp. close to 1mio classes, with the total encoding
> > range still covering a 1GB.
> >
> > ---
> >
> > I think this approach is a variant of the
> > Klass-structures-in-a-table-and-store-the-index approach, but it allows
> for
> > those rare Klass structures to be larger than a single table slot and it
> > has a much larger max. cap on the number of classes than if we were just
> to
> > limit the encoding range. To me this matters somewhat because I have seen
> > productive installations where the number of classes was the low
> 100000's.
> > I don't think the 8192 limit cited in the Lilliput Wiki is practical.
> >
> > If I am right this approach should not require a lot of changes:
> > - we would need to modify metaspace to use separte alignments for the
> class
> > space
> > - may have to fix class pointer encoding for the various platforms if
> they
> > don't work with larger shifts out of the box, or are inefficient. E.g. on
> > x64, we use LEAQ to encode pointers, and LEAQ allows for a max. shift of
> 3,
> > so for shift=8 we may need to use separate add and shift.
> > - CDS may need some work too, since the Klass structures in the CDS
> region
> > need to be aligned to the larger alignment as well.
> >
> > Hope I did not make some gross miscalculation somewhare, but that's my
> > idea. What do you think.
> >
> > Thanks, Thomas
> >
>
>