RFR (S): 8165859: gcTaskThread is missing volatile qualifier and barriers for _time_stamps
erik.osterlund at oracle.com
Fri Sep 23 13:43:46 UTC 2016
I think closing the bug as a duplicate makes sense - it does indeed seem
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:
> 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