gc/shenandoah/compiler/TestReferenceCAS.java failed with -Xcomp

[Leslie Zhai]

Hi Aleksey,

Thanks for your kind response!

> 2023年4月24日 18:26，Aleksey Shipilev <shipilev at amazon.de> 写道：
> 
> Hi!
> 
> On 24.04.23 10:44, Leslie Zhai wrote:
>> ```
>>  template <typename T>
>>  inline void ShenandoahBarrierSet::AccessBarrier<decorators, BarrierSetT>::oop_store_common(T* addr, oop value) {
>>    shenandoah_assert_marked_if(nullptr, value, !CompressedOops::is_null(value) && ShenandoahHeap::heap()->is_evacuation_in_progress());
>> -  shenandoah_assert_not_in_cset_if(addr, value, value != nullptr && !ShenandoahHeap::heap()->cancelled_gc());
>> +  shenandoah_assert_not_in_cset_if(addr, value, value != nullptr && !ShenandoahHeap::heap()->cancelled_gc() && strcmp(ShenandoahGCHeuristics, "aggressive"));
>>    ShenandoahBarrierSet* const bs = ShenandoahBarrierSet::barrier_set();
>>    bs->iu_barrier(value);
>>    bs->satb_barrier<decorators>(addr);
>> ```
>> But what is the root cause about `aggressive` ShenandoahGCHeuristics fail to work?
> 
> "Aggressive" does many back-to-back GC cycles, evacuating most (all?) objects. This is the testing mode that amplifies the potential GC bugs. So if a test fails with "aggressive" only, it means there is a rare GC bugs, and you have just caught it!

Thanks for Sun yaqi bug report!

> 
>> 1.
>> STDOUT:
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (/mnt/repo/openjdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp:246), pid=760863, tid=761352
>> #  Error: Shenandoah assert_not_in_cset failed; Object should not be in collection set
>> 
>> Referenced from:
>>   interior location: 0x00007f2a28b000c8
>>   inside Java heap
>>     not in collection set
>>   region: |    1|R  |BTE 7f2a28b00000, 7f2a28b7ff20, 7f2a28b80000|TAMS 7f2a28b00000|UWM 7f2a28b00000|U   511K|T   511K|G     0B|S     0B|L     0B|CP   0
>> 
>> Object:
>>   0x00007f2a7bf05100 - klass 0x0000000800006340 java.security.CodeSource
>>     not allocated after mark start
>>     not after update watermark
>>         marked strong
>>     not marked weak
>>         in collection set
>>   mark: marked(0x00007f2a7bf838d3)
>>   region: | 2665|CS |BTE 7f2a7bf00000, 7f2a7bf80000, 7f2a7bf80000|TAMS 7f2a7bf80000|UWM 7f2a7bf80000|U   512K|T     0B|G   511K|S   184B|L   415K|CP   0
> 
> This assert makes sure we don't store the reference to collection set anywhere. It looks like the "value" we were passed is actually in collection set, which cannot happen if we passed the value through the load-barrier, unless the GC is already failing1. Was that value from the CAS somewhere?
> 
> 
>> 2. https://github.com/xiangzhai/jdk/commit/37ab11ed23fe45c9411d87cb3a74e9fcedc1accc
> 
> I think you can get the similar testing environment without adjusting the tests, but just doing:
> 
>   make test TEST=... TEST_VM_OPTS="-Xcomp"
> 
> I was able to reproduce it on Mac M1 with the command above.

Yes :)

> 
> Filed: https://bugs.openjdk.org/browse/JDK-8306734 -- gonna take a look at that.

Thanks,
Leslie Zhai

> 
> 
> -- 
> Thanks,
> -Aleksey
> 
> 
> 
> 
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879
> 
>