RFR: Use PLABs for old gen allocations, including promotions.
Bernd Mathiske
bmathiske at openjdk.java.net
Tue Apr 13 21:10:51 UTC 2021
On Mon, 12 Apr 2021 20:48:32 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:
>> Introducing a 3rd kind of LAB for generational mode: "PLAB".
>>
>> (This PR is in draft form as testing is still ongoing.
>> Our smoke testing till flags a few unexpected crashes in generational mode.)
>>
>> Shenandoah already has TLABs and GCLABs. The latter pertain firmly to young gen and allocations in old gen are so far always shared allocations, without LAB. With this PR, old gen allocations go through LABs as well and we separate those from the other two kinds. In other words, each generation has its separate GC-decicated LAB.
>>
>> When not in generational mode, GCLABs work as before and PLABs are never used.
>>
>> The new diagnostic flag -XX:-ShenandoahUsePLAB can be used to turn off PLAB use, so that all old gen allocations are shared as before this PR. By default PLABs will be used.
>>
>> Note that In source code, the type of both GCLABs and PLABs is "PLAB*", sonce GCLABs already had that type, but variable references and other value-level identifiers are consistently named "gclab" and "plab".
>>
>> In ShenandoahFreeSet::allocate_single() there is a notable additional change that can easily be reverted if needed. Instead of fitting the intended allocation into any free or occupied region that can hold it, we now search for an occupied region in the same generation first, before considering free regions. The idea is to pack regions more densely as long as they have space left. This provides more opportunity for region borrowing between generations, should the need arise. For single-generational Shenandoah, it should not make a huge difference, right? Or is it crucial to find any free slot hit in that search loop ASAP?
>>
>> Full collections need to set empty/trash regions that they compact into to non-FREE. For now, they will be made "YOUNG". (See the second commit.)
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 147:
>
>> 145: HeapWord *result = try_allocate_in(r, req, in_new_region);
>> 146: if (result != NULL) {
>> 147: if (r->is_old()) {
>
> Sorry, it's not clear to me why we aren't concerned about pointers to young anymore?
Not as long as no content has been written into such objects. Here we are merely allocating an object that does not have references yet. If the mutator gets to it afterwards to plant references into it, this will still be in young gen, so no remset action is required. The only way to make this object hold old->young references is by means of promotion. That's covered in try_evacuate_object() for normal-sized objects (see above). For humongous objects, it's supposed to be covered in the course of region promotion.
> src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 248:
>
>> 246: // We should revisit this.
>> 247: // Furthermore, the object start should be registered for remset scanning.
>> 248: MemRegion mr(cast_from_oop<HeapWord*>(result), result->size());
>
> Don't we need this? The object going into the old region may have pointers to young that need to be scanned.
We do need this, but not necessarily right here. I moved this close to where the object transitions, in try_evacuate_object. When a thread succeeds in moving the object there, its card is dirtied and it is registered right away. See line ~340, where it says "// Successfully evacuated. Our copy is now the public one!".
> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 102:
>
>> 100: do_commit();
>> 101: case _empty_committed:
>> 102: set_affiliation(YOUNG_GENERATION);
>
> It's not clear to me why we would set the affiliation here. Do we know this region isn't going to be used for evacuations in old gen?
This is to fix full single-generational collections. But yes, not good enough in the long run. => I need to put a TODO note to remind us of later repairing proper full collections in generational mode.
-------------
PR: https://git.openjdk.java.net/shenandoah/pull/30
More information about the shenandoah-dev
mailing list