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
