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

[sangheon.kim at oracle.com]

On 10/15/18 5:41 PM, Kim Barrett wrote:
>> 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?
I answered in different email thread, but let me repeat here.

It is hard for CMS. (https://bugs.openjdk.java.net/browse/JDK-6938732)
Serial / parallel uses different mechanism to treat so it is hard to 
change it from  RP::process_discovered_references().

For Parallel GC, it is doable but it requires much work. And this is why 
we decided to exclude parallel gc support from JDK-8043575.

Thanks,
Sangheon


> That seems like it might make deferral to executor invocation
> problematic.
>
>
>