RFR: DRAFT: Add generations to freeset

[Kelvin Nilsen]

On Sun, 9 Apr 2023 22:11:36 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> ShenandoahFreeSet has not yet been modified to deal efficiently with the combination of old-gen and young-gen collection set reserves.  This PR makes changes so that we can distinguish between collector_is_free, old_collector_is_free, and mutator_is_free.  Further, it endeavors to keep each set of free regions tightly packed, so the range of regions representing each set is small.
> 
> As currently drafted, there are regressions represented by assertion failures and crashes.  The purpose of publishing this draft PR is to allow careful scrutiny of the code.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 524:

> 522: 	  _heap->generation_for(req.affiliation())->increase_used(waste);
> 523:           if (req.affiliation() == ShenandoahRegionAffiliation::OLD_GENERATION) {
> 524:             _heap->card_scan()->register_object(fill_addr);

I'm asking myself whether this needs a lock.  This code is inside try_allocate_in(), which is called by allocate_single() and allocate_with_affiliation() and allocate_old_with_affiliation(), which are called by allocate(), which is called by ShenandoahHeap::allocate_memory_under_lock();  so I have the lock.

Other threads may be concurrently registering objects that belong to the same region without acquring a lock, but this would only happen for objects allocated from within a plab, and we know that none of those will touch the same memory as is affected by this operation, so no locking is necessary.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/250#discussion_r1161355386