RFR: Use PLABs for old gen allocations, including promotions. [v2]

Bernd Mathiske bmathiske at openjdk.java.net
Fri Apr 16 19:07:04 UTC 2021


On Fri, 16 Apr 2021 14:26:40 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Bernd Mathiske has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Register filler objects for unsuccessful non-LAB evacuations.
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 125:
> 
>> 123:       result = allocate_with_affiliation(FREE, req, in_new_region);
>> 124:       if (result != NULL) {
>> 125:         return result;
> 
> I am not sure about this. What must not happen here is that we mix new allocations and evacuations into the same region. That is because we need to update references in evacuated objects later, but not for new objects (we're guaranteed to only store to-space refs into new objects). I guess it's similar for promotions: we do need to update refs in promoted objects. That means we can mix promotions and evacuations, but cannot mix either of them with new allocations. Can you clarify this?

There is no mixing between new allocations and evacuations or promotions, because new allocations are handled in the separate switch cases _alloc_tlab and _alloc_shared, only using the mutator view. Here we use the GC view (except for overflow into trash/empty mutator regions that get "flipped").

Even though from an old gen perspective promotions are "incoming allocations", they bypass the to-space invariant by copying object content without passing barriers. In that they are in the same boat/region/PLAB with evacuations from old gen to old gen. Yes, they also need to be processed by update-refs. And we mix them in PLABs, just as we already did in case _alloc_shared_gc.

allocate_with_affiliation() is introduced for separating the hunt for a suitable region in the same generation from the hunt for a free region. Instead of taking whichever comes first, we now attempt to fit into a non-free region first. I can undo this if there is a good reason to not try to pack existing non-free regions first.

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

PR: https://git.openjdk.java.net/shenandoah/pull/30


More information about the shenandoah-dev mailing list