Parallel reference processingq

[sangheon]

On 06/06/2017 11:17 PM, Kirk Pepperdine wrote:
>
>>>>>>
>>>>>> 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.
>
> I think we’re talking past each other, my apologies for being a bit 
> too terse.
It was same here.. :)

> The referenced bug report seems to cover all of my concerns.
Good to hear the CR would cover your concerns.

>
>> 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. :)
>
> Right, hence my comment that SpecJVM isn’t a great benchmark as it 
> doesn’t represent enterprise applications and hence has nothing useful 
> to say about reference processing which is commonly seen in enterprise 
> applications.
Yes, SpecJVM doesn't represent enterprise applications.

I was trying to say that MTness of reference processing is mostly 
affected by the total of references. But saying the benchmark name made 
a noise.
JDK-8043575 is mostly about dynamically choosing MTness for reference 
processing. Focusing on the switch(turn on/off the option), any 
applications that showing several aspects(many references, limited 
references etc..) seem okay to me. In my case, as SpecJVM2008-Derby has 
many final references(over 12k), my prototype should show almost same 
result as "baseline, +ParallelRefProcEnabled". And for other sub-tests 
of SpecJVM2008, my prototype should show almost same as "baseline, 
-ParallelRefProcEnabled" because with limited references, single thread 
shows better results.

Initially I worked with micro-benchmark but I also wanted to test with 
known benchmark as well.
Hope this explains why I used SpecJVM2008.

>
>>
>> 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 don’t have a specific benchmark for this. I’m relying on 
> observations made from customer’s applications. I don’t know if the 
> SPEC application server benchmark addresses this question. I’ve not 
> run it in quite some time so I don’t recall. At any rate, it is very 
> clear that real world applications use many frameworks that rely 
> heavily on the use of reference types. For example, Hibernate with 
> secondary caching turned on. CMS is sensitive but the G1’s remark 
> phase appears to be exceptionally sensitive to the amount of 
> references it processes. I’ve attached a pause time and G1 breakout of 
> the other phases that is very typical of what I’m seeing.
Thank you for the attachments.
I will analyze a bit more.

Thanks,
Sangheon


>
> Kind regards,
> Kirk
>
>
>

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