Application failure with traversal

Aleksey Shipilev shade at redhat.com
Fri Feb 9 18:37:42 UTC 2018


On 02/09/2018 07:18 PM, Lennart Börjeson wrote:
>> 9 feb. 2018 kl. 18:36 skrev Aleksey Shipilev <shade at redhat.com>:
>> On 02/09/2018 06:27 PM, Lennart Börjeson wrote:
>> OK, both good and bad! And that is without any GC cycle happening, right? If so, that must
>> definitely point at something gone wrong in C2, which means we can use passive mode, and gradually
>> narrow down which part had failed (in order of most probability):
>>
>> 0) Run with -XX:-TieredCompilation -XX:ShenandoahGCHeuristics=passive
> Runs OK.
>> 1) Add -XX:+ShenandoahBarriersForConst
> Runs OK.
>> 2) Add -XX:+ShenandoahAsmWB
> Runs OK.
>> 3) Add -XX:+ShenandoahReadBarrier
> Fails.

...

> I also ran with all barriers except ReadBarrier enabled, i.e. with -XX:-TieredCompilation -XX:ShenandoahGCHeuristics=passive -XX:+ShenandoahBarriersForConst -XX:+ShenandoahAsmWB -XX:-ShenandoahReadBarrier -XX:+ShenandoahWriteBarrier -XX:-ShenandoahWriteBarrierRB -XX:+ShenandoahStoreValEnqueueBarrier  -XX:+ShenandoahCASBarrier -XX:+ShenandoahAcmpBarrier -XX:+ShenandoahCloneBarrier
> 
> This runs OK.

This is baffling. I think we are going to need a reproducer, or at least a better understanding on
what code patterns it fails. Does it fail within your own Java code, or in some library code we can
inspect?

-Aleksey



More information about the shenandoah-dev mailing list