RFR (S): 8165859: gcTaskThread is missing volatile qualifier and barriers for _time_stamps

Erik Österlund erik.osterlund at oracle.com
Fri Sep 23 13:43:46 UTC 2016

Hi Kim,

I think closing the bug as a duplicate makes sense - it does indeed seem 
very related.
I agree that perhaps what this class needs is not more thread-safety 
mechanisms but for somebody to have a look at why on earth it is 
accessed concurrently in the first place, and get rid of that fishy CAS.

Here is my suggested solution: 

The problem seems to be that the task thread notifies the vm thread that 
it is done, and then after that updates the entries that are to be 
printed by the vm thread. By simply updating the entries first, and then 
notifying that the worker is done, the concurrent access scenario should 
be completely gone.

What do you think?

(testing: JPRT, JTreg hotspot_all, local testing running through a bunch 
of DaCapo benchmarks)


On 2016-09-21 00:19, Kim Barrett wrote:
>> On Sep 20, 2016, at 3:47 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> Unfortunately, I'm coming to believe there's some questionable code
>> here, and throwing a volatile and maybe a barrier or two at it doesn't
>> look like an improvement to me.
> Stefan Karlsson pointed to another bug in this area:
> https://bugs.openjdk.java.net/browse/JDK-8024399
> PrintGCTaskTimeStamps: amount of tasks reported for GC-thread sometimes differs from expected value
> After reading through that and related stuff, I'm inclined toward
> closing this bug (JDK-8165859) as a duplicate of JDK-8024399.

More information about the hotspot-runtime-dev mailing list