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

JITted code erroneously hangs on to a MethodHandle.constant

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Incomplete
    • Icon: P2 P2
    • 9
    • 8u20
    • hotspot

        The nashorn staging repo scheduled to go into 8u20 tries to turn indy property getters in the global scope into MethodHandle.constants if they aren't rewritten too often.

        hg clone http://hg.openjdk.java.net/nashorn/jdk9/nashorn
        cd nashorn
        cd make
        ant clean jar
        sh ../bin/runoptdualcatch.sh program.js

        where program.js is:

        var N = 1000;

        var array = new Array(N);
        var WeakReferenceArray = Java.type("java.lang.ref.WeakReference[]");
        var refArray = new WeakReferenceArray(N);

        for (var i = 0; i < N; i ++) {
            var object = new java.awt.Color(0,0,0); //object write
            array[i] = object; //object read treated as MethodHandle.constant first lap
            refArray[i] = new java.lang.ref.WeakReference(object); //object read, ditto
        }

        object = null;

        for (var i = 0; i < N; i ++) {
            delete array[i];
        }

        java.lang.System.gc();
        java.lang.System.gc();
        java.lang.System.gc();

        for (var i = 0; i < N; i ++) {
            if (refArray[i].get() != null) {
                print("Reference found at " + i + " " + refArray + " " + refArray[i].get());
            }
        }

        print("All references gone");

        Should, given the default behavior of system GC clear out the refArray contents.
        Now, the constant optimization will treat the two object reads in the first for loop as Methodhandle constants for the zeroth element of the array. When the loop gets to the second lap, it will discover that this is not a profitable strategy since object is reassigned, and relink the two object getter callsites to normal indy getters. No one holds on to the MethodHandle constant anywhere, but the test fails, because the zeroth reference (and only the zeroth) in the array, the one that was a constant is still there after the system gc:s.

        putting a while(1) before the System.gcs and generating an hprof dump produced another bug:
        https://bugs.openjdk.java.net/browse/JDK-8038797

        We couldn't find a root for the stray object value (the Color) wrapped in the constant on the heap.

        What makes me think that this is a JIT bug, is that if I run with -Xint, everything works and the array is indeed all nulled out - all 1000 elements.

              rbackman Rickard Backman (Inactive)
              lagergren Marcus Lagergren
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: