RFR: JDK-8211955: GC abstraction for LAB reserve

Roman Kennke rkennke at redhat.com
Tue Oct 9 20:16:26 UTC 2018


TLABs need to be made parseable before GC. This means to fill remaining
space with a dummy object, so that there remain no holes in the heap,
and the heap becomes contiguously filled with objects. However, since we
cannot (generally) fill holes with arbitrarily small objects, we need an
'allocation reserve' at the end of TLABs (and PLABs).

Current PLAB and TLAB reserve assumes a specific object size. GCs like
Shenandoah need to allocate a little more space per object and thus
require some abstraction to get the minimum filler object size /
allocation reserve.

This change proposes an API in CollectedHeap to determine the minimum
filler object size. It also proposes some consolidation between TLAB and
PLAB in this respect. plab.cpp has this logic to calculate the reserve:

AlignmentReserve = oopDesc::header_size() > MinObjAlignment ?
align_object_size(arrayOopDesc::header_size(T_INT)) : 0;

The idea is that if obj-alignment is larger/equal than min-object-size,
then we don't need a reserve, because we can always make the filler fit.
Otherwise, we choose the min-array-size (3 words). The reason for the
latter eludes me: it should be enough to choose the minimum object size
(2 words).

TLAB always uses min-array-size, and does not take MinObjAlignment into
account.

I propose to add two methods to CollectedHeap:

  virtual size_t min_dummy_object_word_size() const;

to return the minimum possible filler object size. GCs can override this
to return a different size (e.g. Shenandoah would return one extra word
here). And then:

  size_t tlab_alloc_reserve() const;

to calculate the allocation reserve, using the logic from PLAB that
takes MinObjAlignment into account. This uses
min_dummy_object_word_size() and would be used by both TLAB and PLAB.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8211955
Webrev:
http://cr.openjdk.java.net/~rkennke/JDK-8211955/webrev.00/

What do you think?

Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20181009/22a3b2c7/signature.asc>


More information about the hotspot-gc-dev mailing list