Parallel reference processingq

[Kirk Pepperdine]

>>>>> 
>>>>> 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. The referenced bug report seems to cover all of my 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.

> 
> 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.

Kind regards,
Kirk





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20170607/cfe22ddc/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-2.tiff
Type: image/tiff
Size: 1102226 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20170607/cfe22ddc/PastedGraphic-2.tiff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 1292744 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20170607/cfe22ddc/PastedGraphic-1.tiff>