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

[serguei.spitsyn at oracle.com]

On 11/4/18 23:40, serguei.spitsyn at 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.

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