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

[Chris Plummer]

On 11/4/18 11:45 PM, serguei.spitsyn at oracle.com wrote:
> 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.
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
>>>>
>>>>
>>>>
>>>
>>>
>>
>