Download the jcstress test bundle from here:
  https://builds.shipilev.net/jcstress/jcstress-tests-all-20210703.jar

Run it with release build:
 $ build/linux-x86_64-server-release/images/jdk/bin/java -jar jcstress-tests-all-20210703.jar --jvmArgs "-XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGuaranteedGCInterval=10 -Xint" -sc false -t atomicity.varHandles.arrays.CAETest.CompareAndExchangeString -m stress

                RESULT SAMPLES FREQ EXPECT DESCRIPTION
            2, null, 2 141,448,926 54.14% Acceptable actor2 update successfully
         null, null, 2 265 <0.01% Forbidden This won't happen because compareAndExchange is atomic
      null, null, null 0 0.00% Forbidden This won't happen because compareAndExchange is atomic
    null, null, object 0 0.00% Forbidden This won't happen because compareAndExchange is atomic
  null, object, object 119,824,409 45.86% Acceptable actor1 update successfully

The test is basically:

    @Actor
    public void actor1(LLL_Result r) {
        r.r1 = (String) vh.compareAndExchange(this, null, "object");
    }

    @Actor
    public void actor2(LLL_Result r) {
        r.r2 = (String) vh.compareAndExchange(this, null, "2");
    }

    @Arbiter
    public void arbiter1(LLL_Result r) {
        r.r3 = field;
    }

This "null, null, 2" outcome says that two compareAndExchanges returned "null" as the answer, and the final result was "2". Which probably implies that "null" was the GC-washed result.

Bisection shows it started with JDK-8256011, but I wonder if the real reason is something like JDK-8255991, where we return nulls from the CAS paths.

Note that the test fails in *interpreter* too. Reverting the shenandoahBarrierSet.inline.hpp hunk from JDK-8255991:
 https://github.com/openjdk/jdk/commit/d99e1f6c296c23b8714fc94fe4f3c7bece000f9c#diff-6db05938f86f624bd091e0092da9760ab46d8c18ec2654f97d4bb78f7ea52311

...makes the test pass.