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

[Daniil Titov]

Hi Dean, 

The blocking issue  for suspended JVMCI compiler thread in case of Graal and -XComp was recently solved in  JDK-8195627 " Graal] nsk/jdi/VirtualMachine/redefineClasses/redefineclasses026 hangs with Graal in Xcomp mode" .  Could you please say do you think it will not be sufficient for the case you described?

Just in case please find below the links to Jira and review thread for JDK-8195627:
Review thread :  http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October/025764.html
Jira issue: https://bugs.openjdk.java.net/browse/JDK-8195627 

Thanks,
Daniil

On 11/9/18, 12:14 PM, "serguei.spitsyn at oracle.com" <serguei.spitsyn at oracle.com> wrote:

    We need to understand/formulate what requirements/limits the Graal 
    compiler has to follow and then negotiate it with the Compiler team.
    I feel it is not a good idea to work around these issues to make the 
    tests to pass.
    Sorry that I've lost track of the discussion - will need to re-read the 
    email thread thoroughly.
    
    Thanks,
    Serguei
    
    
    On 11/9/18 11:42, Chris Plummer wrote:
    > This sounds like a general issue with debugging and graal. Debuggers 
    > expect to be able to suspend all threads, and then resume just the 
    > ones they want to see executed. You're saying there are situations in 
    > which the resumed thread will end up blocking on the suspended 
    > compiler thread(s).
    >
    > Chris
    >
    >
    > On 11/9/18 10:19 AM, dean.long at oracle.com wrote:
    >> With OSR, a compile can be initiated in a for loop, so I'd say this 
    >> is still not safe if the compile can be blocking, which happens if:
    >>
    >>     bool is_blocking = !directive->BackgroundCompilationOption || 
    >> CompileTheWorld || ReplayCompiles;
    >>
    >> So that probably means the test cannot be run with -Xcomp.
    >>
    >> dl
    >>
    >> On 11/8/18 3:12 PM, Daniil Titov wrote:
    >>> The proposed fix for this case is to suspend VM while the body of 
    >>> the "for" loop (lines 150 - 356) is executed while ensuring that for 
    >>> line 151 ( line = pipe.printlln()) VM is temporary resumed ( line 
    >>> numbers are given for an original version of 
    >>> test/hotspot/jtreg/vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance001.java)
    >>
    >
    >