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

[Erik Österlund]

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: 
http://cr.openjdk.java.net/~eosterlund/8165859/webrev.02/

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)

Thanks,
/Erik

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