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

[Kim Barrett]

> On Sep 23, 2016, at 9:43 AM, Erik Österlund <erik.osterlund at oracle.com> wrote:
> 
> 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?

This looks ok.

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

Did you try reproducing before and after with any of the reproducers for JDK-8024399?

If that seems to work, attach the patch to that bug, and assign to yourself if you want.

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