RFR 8203174: [Graal] JDI tests fail with Unexpected exception: com.sun.jdi.ObjectCollectedException

[Daniil Titov]

Hi Chris,

There were multiple issues here but with JDK-8193126 being fixed I can no longer observe metaspace related issues and suspending the target VM seems as a sufficient to prevent newly created objects being collected before we have a chance to call disableCollection() on them.

I noticed that the check for JFR uses the same approach to detect whether the Flight Recorder is on.

public boolean isJFR_active() {
    String opts = argumentHandler.getLaunchOptions();
         int jfrPos = opts.indexOf("-XX:+FlightRecorder");
         if (jfrPos >= 0)
              return true;
          else
              return false;
      }
 
The other option I had in mind is to check the presence of "JMCI Compiler" threads in the target VM but I less inclined to it since it relies on the thread name that might be changed at some point in the future as well. On more option could be to completely remove checks with "java.lang.String" class regardless JVMCI is on or off but it would reduce the coverage in the case when JVMC is off.

Best regards,
Daniil

On 11/2/18, 8:59 PM, "Chris Plummer" <chris.plummer at oracle.com> wrote:

    Hi Daniil,
    
    I thought the issue was that C2 was doing metadata allocations, and when 
    it ran out of metaspace it did a GC (one that was not triggered by a 
    failed object allocation). As a results we were getting objects GCs 
    before the test ever got the chance to disable collection on them. I 
    thought we also concluded other than this metaspace issue, if the test 
    is properly disabling collection on the objects it cared about, it 
    shouldn't matter if there are GC's triggered by excessive object 
    allocations.
    
    I don't think the following check will always be valid. It may be on by 
    default at some point:
    
      651     public boolean isJVMCICompilerOn() {
      652         String opts = argumentHandler.getLaunchOptions();
      653         return opts.indexOf("-XX:+UseJVMCICompiler") >= 0;
      654     }
    
    thanks,
    
    Chris
    
    On 11/2/18 4:29 PM, Daniil Titov wrote:
    > Please review the change that fixes several tests failing with com.sun.jdi.ObjectCollectedException when running with Graal.
    >
    > There main problem here is that with Graal on JVMCI Compiler threads in the target VM create a lot of objects and sporadically trigger GC that results in the objects created in the target VM in the tests being GCed before the tests complete. The other problem is that for some classes the tests use, e.g. "java.lang.String",  there is already a huge number of instances created by JVMCI threads.
    >
    > The fix suspends target VM to prevent JVMCI compiler threads from creating new objects during the tests execution. In cases when IOPipe is used for communication between the test and the debuggee the fix suspends all threads but the main rather than suspending the VM. The fix also filters out the checks for some test classes (e.g. "java.lang.String") in cases when the target VM is run with JVMCI compiler options on.
    >
    > Webrev: http://cr.openjdk.java.net/~dtitov/8203174/webrev.01/
    > Bug: https://bugs.openjdk.java.net/browse/JDK-8203174
    >
    > Thanks,
    > Daniil
    >
    >
    >