On 11/4/18 11:45 PM, serguei.spit...@oracle.com wrote:
On 11/4/18 23:40, serguei.spit...@oracle.com wrote:
Hi Daniil,
I agree with Chris below.
Will tell more on reply to your reply.
Thanks,
Serguei
On 11/2/18 20:59, Chris Plummer 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
Forgot to comment on the below.
It is probably a typo.
Should it be about the Graal, not the C2?
As I understand we have no issue with the C2.
Actually it was the C1 Compiler Thread that was the problem, although it
only turned up during Graal testing.
Chris
Thanks,
Serguei
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
