Hi Marcus,
I think all the copyrights need to be updated.
Since I had been able to reproduce the problem on nearly every run, I
tried your fix and the crash no longer occurs. However, I now see that
in about 1 in 5 runs, the final message that used to trigger the crash
now gets printed
can be used in a parallel with a safepoint.
+ // See the work around in PerfDataManager::destroy().
OM_PERFDATA_OP(FutileWakeups, inc());
}
Dan
On 9/2/15 10:03 AM, Daniel D. Daugherty wrote:
On 9/2/15 9:40 AM, Tom Benson wrote:
Hi Dan,
OK. I didn't review what was added in round 1 once yo
at a safepoint in
PerfDataManager::destroy? Just a thought.
Tom
On 9/2/2015 11:15 AM, Daniel D. Daugherty wrote:
On 9/2/15 8:49 AM, Tom Benson wrote:
Hi,
I'm a bit confused on one point... Since you now only call
PerfDataManager::destroy at a safepoint, why do you still have the
comment about
Hi,
I'm a bit confused on one point... Since you now only call
PerfDataManager::destroy at a safepoint, why do you still have the
comment about 'the race' and the sleep?
Tom
On 9/2/2015 7:52 AM, Daniel D. Daugherty wrote:
David,
Thanks for the very fast re-review!
Enjoy your vacation!
Hi,
One more pair of eyes on this. 8^)
On 8/27/2015 8:16 PM, Kim Barrett wrote:
On Aug 27, 2015, at 5:42 PM, Daniel D. Daugherty daniel.daughe...@oracle.com
wrote:
Sorry for starting another e-mail thread fork in an already complicated
review...
OK, that was fascinating. No, really, I mean
Hi again,
Just noticed I skipped this question in your reply:
So in ReenterI() the OM_PERFDATA_OP(FutileWakeups, inc()) call
immediately
follows an OrderAccess::fence() call. Doesn't that make that increment as
safe as it can be without having a real lock?
Yes - odd that I noticed the
