RFR: Convert old-gen single threaded pretouch to multi-threaded during

Amit Pawar amith.pawar at gmail.com
Wed Jan 27 16:03:21 UTC 2021


Thanks Kim for replying.

On Sun, Jan 24, 2021 at 8:07 PM Kim Barrett <kim.barrett at oracle.com> wrote:

> > On Jan 8, 2021, at 8:08 AM, Amit Pawar <amith.pawar at gmail.com> wrote:
> >
> > Hi
> >
> > I am trying to improve the pre-touch time taken during old-gen resizing.
> > Need your suggestions whether following change will be accepted or not.
> >
> > What is happening ?
> > Every GC thread resizes the old-gen during object promotion if there is
> no
> > enough room for the object. After expanding GC thread will pre-touch the
> > pages alone and cant pre-touch in parallel using PretouchTask task as it
> is
> > already executing a GC task. The total GC pause time depends upon resize
> > size and number of resizes.
> >
> > What is fix?
> > Create another WorkGang and then GC thread can execute pre-touch task
> with
> > this new WorkGang to reduce the pre-touch time taken. The code change is
> > given below.
>
> I don't think adding a work gang is the right approach here.  The threads
> in
> that new work gang may just end up competing for CPUs with the already
> in-progress work gang doing the normal GC work.
>

A better approach would be to refactor pretouch parallization to allow
> threads to join the fray as needed.  Then arrange for the in-progress work
> gang threads to join the pretouch if they would otherwise be waiting for it
> to complete.
>
> OK.

> I've recently been looking at the relevant parts of ParallelGC, and it
> looks
> like it shouldn't be too hard to allow threads waiting for expansion to
> cooperate in any ongoing pretouch, esp. after some other recent RFEs have
> been dealt with. I've filed JDK-8260332 for this. I haven't looked at the
> G1
> side of things yet.
>
It will be useful if you can share those RFEs or suggest which part of the
code to refer to.


Thanks,
Amit



More information about the hotspot-gc-dev mailing list