Parallel reference processingq

[sangheon]

On 06/06/2017 12:51 PM, Kirk Pepperdine wrote:
>
>> On Jun 6, 2017, at 9:40 PM, sangheon <sangheon.kim at oracle.com 
>> <mailto:sangheon.kim at oracle.com>> wrote:
>>
>>
>>
>> On 06/06/2017 12:26 PM, Kirk Pepperdine wrote:
>>>
>>>> On Jun 6, 2017, at 7:44 PM, sangheon <sangheon.kim at oracle.com 
>>>> <mailto:sangheon.kim at oracle.com>> wrote:
>>>>
>>>> Hi Kirk,
>>>>
>>>> On 06/06/2017 01:26 AM, Kirk Pepperdine wrote:
>>>>> Hi,
>>>>>
>>>>> I’m keep running into cases where reference processing dominates the pause times budget (no matter which collector is configured). In all cases configuring parallel reference processing helped enormously. Reference processing is single threaded by default. I’m wondering if there is a reason why reference processing could be parallel by default or parallelized if the workload exceeds a reasonable threshold.
>>>> The biggest reason that I think is in some cases - if there are not 
>>>> many references [1]- single thread case is faster. Of course, this 
>>>> is controversial as choosing a benchmark will show different 
>>>> results. Probably big enough applications tend to have many 
>>>> references. But this is why we don't set 
>>>> 'ParallelRefProcEnabled=true' as a default.
>>>>
>>>> Current implementation spends some time on starting/stopping worker 
>>>> threads. We start and stop worker threads 9 times (3 for 
>>>> SoftReference and 2 times for other types) for reference 
>>>> processing.  And this results in slower than single thread case in 
>>>> some cases.
>>>>
>>>> JDK-8043575 <https://bugs.openjdk.java.net/browse/JDK-8043575> is 
>>>> proposing to dynamically switch between MT and single thread. And 
>>>> there are other CRs to enhance references processing.
>>>> I have a prototype but need more refining. Please keep on eye on 
>>>> this if you are interested. (Thanks, Aleksey for the link at the 
>>>> other email thread)
>>>>
>>>> [1]: e.g. Most of Specjvm2008 sub-tests don't use references. Derby 
>>>> is exceptional case that shows over 12k FinalReferences. So single 
>>>> thread is faster except Derby case.
>>>
>>> SpecJVM doesn’t represent the real world.
>> Absolutely!
>> I was trying to answer the reason why ParallelRefProcEnabled is set 
>> to false as a default.
>
> I got that.. I was trying to suggest that basing this decision on that 
> benchmark isn’t a great idea.
Probably my explanation was incomplete.
ParallelRefProcEnabled command-line option was introduced long time ago 
with false as a default. And my previous answer with Specjvm2008 was my 
guess from recent data when I investigated JDK-8043575. I was saying if 
we don't have enough references to process, single thread is better 
choice. So this could be the reason of current default value. Or my 
guess would be simply wrong. :)

Probably you are saying that we have to use other benchmarks to decide 
the default value.
May I ask what is your recommendation for the benchmarks?
I will not try to change its default value but your recommendation would 
be helpful for further investigation.

Thanks,
Sangheon


>
> Kind regards,
> Kirk
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20170606/22be8732/attachment.htm>