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

[serguei.spitsyn at oracle.com]

Hi Daniil,

Just wanted to comment this as I understand it.

On 11/4/18 12:40, Daniil Titov wrote:
> 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.

Your change looks like a workaround for the Graal issue that it runs out 
of metaspace.
It could be Okay to have such a fix until the underlying issue is fixed.
However, this workaround is most likely unsafe as Dean L. noticed.


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

Most likely, this also was a workaround for some other issue related to 
the JFR activity.
The best approach is to avoid such workarounds and be more precise on 
what is really tested.

Thanks,
Serguei


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