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

[JC Beyler]

Hi Daniil,

Quick question about looking at the launch options, is there any reason you
do not simply use:
sun.hotspot.code.Compiler.isGraalEnabled();

Is it because you do not want to specifically call out Graal?

Thanks,
Jc

On Sun, Nov 4, 2018 at 12:41 PM Daniil Titov <daniil.x.titov at oracle.com>
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.
>
> 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
>     >
>     >
>     >
>
>
>
>
>
>

-- 

Thanks,
Jc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20181104/d457573f/attachment.html>