Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8269897

Shenandoah: Resolve UNKNOWN access strength, where possible

    XMLWordPrintable

    Details

    • Subcomponent:
      gc
    • Resolved In Build:
      b06

      Backports

        Description

        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.

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                rkennke Roman Kennke
                Reporter:
                shade Aleksey Shipilev
                Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved: