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.ti...@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.plum...@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