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

[Aleksey Shipilev]

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!

> 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.

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


-- 
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