RFR: JDK-8260332: ParallelGC: Cooperative pretouch for oldgen expansion

[Kim Barrett]

> On Mar 12, 2021, at 3:01 PM, Amit Pawar <github.com+71302734+amitdpawar at openjdk.java.net> wrote:
> 
> In case of ParallelGC, oldgen expansion can happen during promotion. Expanding thread will touch the pages and can't request for task execution as this GC thread is already executing a task. The expanding thread holds the lock on "ExpandHeap_lock" to resize the oldgen and other threads may wait for their turn. This is a blocking call.
> 
> This patch changes this behavior by adding another constructor in "MutexLocker" class to enable non blocking or try_lock operation. This way one thread will acquire the lock and other threads can join pretouch work. Threads failed to acquire the lock will join pretouch only when task is marked ready by expanding thread.
> 
> Following minimum expansion size are seen during expansion.
> 1. 512KB without largepages and without UseNUMA.
> 2. 64MB without largepages and with UseNUMA,
> 3. 2MB (on x86)  with large pages and without UseNUMA,
> 4. 64MB without large pages and with UseNUMA.
> 
> When Oldgen is expanding repeatedly with smaller size then this change wont help. For such cases, resize size should adapt to application demand to make use of this change. For example if application nature triggers 100 expansion with smaller sizes in same GC then it is better to increase the expansion size during each resize to reduce the number of resizes. If this patch is accepted then will plan to fix this case in another patch.

Sorry, but a change like this needs better motivation. What you say
above suggests this change doesn't actually help.

It's intentional that oldgen expansions aren't generally large, as the
oldgen shouldn't be grown unnecessarily. There are already parameters
such as MinHeapDeltaBytes to control and manipulate this.

It is also preferable to complete an expansion request quickly to make
the additional space available to other threads in the main allocation
path, rather than making them go to the expand path. Making expansions
larger could force more threads to take the slower expand path, which
doesn't seem like a win even if they then help with the pretouch part
of another thread's expansion. (And that also assumes UsePreTouch is
even enabled.)

So the followup change that you say is needed to make this one
profitable seems questionable.

The proposed change is also surprisingly large and intrusive for
something that seems like it should be very localized.

> Jtreg all test passed.

A change like this needs a lot more testing than that, both functionally
and performance.