RFR: 8072498: Multi-thread JNI weak reference processing

[Kim Barrett]

> On Aug 9, 2018, at 5:43 PM, Roman Kennke <rkennke at redhat.com> wrote:
> 
> Am 09.08.2018 um 20:57 schrieb Kim Barrett:
>> […]
>> New webrevs without the external optimization of run_task:
>> full: http://cr.openjdk.java.net/~kbarrett/8072498/open.01/
>> incr: http://cr.openjdk.java.net/~kbarrett/8072498/open.01.inc/
>> 
>> And still need another reviewer.
> 
> 
> 
> Wouldn't it be much more useful to turn the design around such that
> weak_oops_do() can be called from a worker, like e.g.
> Threads::possibly_parallel_oops_do(), and leave all the actual wiring up
> of workers to the GC?

If I understand what you are asking for, this is why
WeakProcessor::Task is broken out as a separate public entity, and
indeed is used that way in G1FullGCAdjustTask.

> That would allow to be used in GC that doesn't
> even use WorkGang (e.g. CMS) and probably also helps with ParallelGC? I
> know it would fit better into the picture in Shenandoah, and seems more
> consistent with other parallel oops processing routines. Not sure if it
> would be possible at all, though.

CMS does use WorkGang (actually, YieldingFlexibleWorkGang). It's
ParallelGC that doesn't use WorkGang at all. But note that CMS is
deprecated, so we (Oracle) are not planning to enhance it by using a
parallel version of WeakProcessor.

I looked at making ParallelGC use this, and ran into the same kinds of
problems that Thomas and Sangheon ran into in their work on dynamic
worker activation for j.l.r.Reference processing.  We think the real
solution there may be to make ParallelGC use WorkGang: JDK-8204951.

> Side-note and somewhat off-topic: the specialization via templates is
> probably useful for performance, especially for cheap stuff like
> BoolObjectClosures. I was wondering a while back if that would be
> something to apply to the rest of ReferenceProcessor, and, infact, to
> the rest of root scanning routines too. ? I know it's probably a lot of
> work to get that right…

AlwaysTrueClosure and DoNothingClosure are particularly relevant.

This only has an opportunity to be effective because the OopStorage
API was designed with this in mind. And even then it depends on the
compiler to be reasonably clever, either doing good points-to analysis
or speculative devirtualization. (gcc seems to do pretty well at both
of these; I've not studied the generated code for other compilers.)
C++11 final annotations (for example) would likely make things much
easier for the compiler.

> I will take a closer look at all this tomorrow. It's far too late here
> and I'd probably get it all wrong ;-)

Thanks.  I look forward to your comments.