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

[serguei.spitsyn at oracle.com]

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