RFR(XS): JDK-8212122: Allow ReferenceProcessor to always be MT processing

Roman Kennke rkennke at redhat.com
Tue Oct 16 07:29:07 UTC 2018



Am 15. Oktober 2018 23:51:00 MESZ schrieb Kim Barrett <kim.barrett at oracle.com>:
>> On Oct 15, 2018, at 9:15 AM, Roman Kennke <rkennke at redhat.com> wrote:
>>> The problem is the (rather new) ergonomics code in RP that scales
>number
>>> of threads to spin up based on the amount of work to do. And if it
>ends
>>> up being only 1 thread, then it goes down the single-threaded-path.
>>> Otherwise I wouldn't actually need this change... (that might be
>another
>>> approach to this problem: don't actually change _mt_processing flag
>at
>>> all, and call the executor even with 1 thread. In Shenandoah, we do
>this
>>> and it works fine, and we special-case the 1-thread-path by not
>spinning
>>> up the workers and execute it in the calling thread (which is the
>VMThread).
>> 
>> In other words, this is a fix that actually removes 'cruft', and
>seems
>> less surprising API-wise: i.e. if caller asks for mt_processing, then
>> don't change it, and leave it to caller to execute in VMThread if it
>wishes.
>> 
>> Updated webrev:
>> http://cr.openjdk.java.net/~rkennke/JDK-8212122/webrev.01/
>> 
>> An example how G1 can be made to strictly do the current behaviour
>(i.e.
>> execute in VMThread when ergo_workers==1):
>> 
>> http://cr.openjdk.java.net/~rkennke/JDK-8212122/webrev.01.g1/
>> 
>> ... altough I haven't tested it at all. It works well with
>Shenandoah,
>> but I don't know if you'd actually do it/want it/ask me to do it ;-)
>> 
>> What do you think? Which approach do you like best (except the huge
>> parallel/CMS/WorkGang/ReferenceProcessor reworking)?
>> 
>> Thanks,
>> Roman
>
>Sorry I haven't had time to give this much attention yet; I was
>planning to look at it today or tomorrow.  But your latest comments
>(which I might not fully understand yet, so keep that in mind) are
>leading me to question this change.
>
>Putting it on callers of run_task to do the 1-thread optimization
>doesn't seem appropriate.  I recently had a change that included that
>sort of thing, and Thomas convinced me that decision ought to be in
>run_task, rather than in callers of run_task.  I think that hasn't
>happened yet because of a combination of nobody getting around to it
>and wondering whether there might be any uses where running the task
>directly from the VMThread might be a problem.

Yeah I was initially thinking the same: put it in WorkGang directly. But as you said, this seems like a subtle change of behavior of which I'm not sure it'd break things. Plus it wouldn't work for GCs that don't use WorkGang at all.

>Maybe the selection of whether to run the 1-thread case directly or
>via the executor should be a property of the executor?  That seems to
>be kind of what you are proposing, except I think you are suggesting
>the executor's execute function be responsible for that.  I think that
>didn't work for CMS and Parallel? Sangheon probably remembers better
>than exactly what the issues were there.  The choice could instead be
>a predicate on the executor, called with the number of threads.

 True, it's even more reliable to decide that before diving into the executor and use the 'real' 1-threaded setup for 1-threaded execution. I'll come up with a patch for this later (I'm currently on the road..)

Thanks, Roman


More information about the hotspot-gc-dev mailing list