Parallel reference processingq

Kirk Pepperdine kirk at
Tue Jun 6 19:26:30 UTC 2017

> On Jun 6, 2017, at 7:44 PM, sangheon < at> 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 <> 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. In the real world most applications use weak, soft and final references with a sprinkling of Phantom. I think Aleksey’s link was most interesting, my bad for not searching the bug database prior to posting.

Anyways, I don’t mind charging clients a fee to tell them to turn on this flag but….

Kind regards,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the hotspot-gc-dev mailing list