RFR(XS): JDK-8212122: Allow ReferenceProcessor to always be MT processing
kim.barrett at oracle.com
Mon Oct 15 21:51:00 UTC 2018
> 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:
> An example how G1 can be made to strictly do the current behaviour (i.e.
> execute in VMThread when ergo_workers==1):
> ... 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)?
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.
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.
More information about the hotspot-gc-dev