RFR: 8229169: False failure of GenericTaskQueue::pop_local on architectures with weak memory model

[Jie Fu]

Hi Martin,

Thanks for your review and valuable comments.

Updated: http://cr.openjdk.java.net/~jiefu/8229169/webrev.01/

Please see comments inline.

On 2019/8/6 下午5:29, Doerr, Martin wrote
>  From your description, OrderAccess ::loadload() seems to be the appropriate barrier.
> It should be used on all platforms because it contains a compiler barrier for TSO platforms which prevent compilers from reordering the load accesses.
Done. Thanks.
>
> We should also check that the writer of _age._top uses at least a release (or storestore) barrier in your scenario.
The writer calls GenericTaskQueue<E, F, N>::pop_global to update 
_age._top with _age.cmpxchg(newAge, oldAge) [1] .
I think it already contains the release (or storestore) barrier semantic.
What do you think?
> I wonder why I've never seen this issue on PPC64. The test "TestHumongousClassLoader" seems to work stable. But could be that we just never hit this corner case by chance.
Here is my reproducer to debug this issue: 
http://cr.openjdk.java.net/~jiefu/8229169/reproducer/
And this is my patch used to catch the corner case: 
http://cr.openjdk.java.net/~jiefu/8229169/gc-debug.diff
HTH.

Any comments?

Thanks a lot.
Best regards,
Jie

[1] 
http://hg.openjdk.java.net/jdk/jdk/file/8f067351c370/src/hotspot/share/gc/shared/taskqueue.inline.hpp#l222