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

[Kim Barrett]

> On Oct 15, 2018, at 7:33 PM, sangheon.kim at oracle.com wrote:
> 
> Let me answer to your recent 2 emails together.
> 
> On 10/15/18 6:15 AM, Roman Kennke wrote:
>> 
>> Am 13.10.18 um 11:38 schrieb Roman Kennke:
>>> 
>>> 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.
> I was thinking why it is a problem..
> And now I understand your statement is something like 'why not obey an provided executor' rather than single-thread stuff. Because current code is run in single thread which is VMThread (RP::_processing_is_mt = false).
> 
> All existing GCs (when I worked on the code) have below setting,
> RP::_processing_is_mt = (ParallelGCThreads > 1) && ParallelRefProcEnabled
> which convinced me 1 worker case can be considered same as running on VMThread because ParallelGCThreads == 1 is not considered as mt processing.
> 
> If you are suggesting that we should always use an executor if it is provided, it would be okay for this case. But I'm not sure whether it is the way we want to go.

I think what Roman is suggesting is to always invoke the executor, and
leave it to the executor to decide whether to run directly or not.  I
thought there was some problem with doing that (either for Parallel or
CMS), but you (Sangheon) are more familiar with the difficulties
encountered during JDK-8043575.  I think the issue was that both
Parallel and CMS required making the decision early (at the beginning)
and couldn't change it on the fly for the various phases.  Is that
correct?  That seems like it might make deferral to executor invocation
problematic.