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

[serguei.spitsyn at oracle.com]

Then consider it reviewed.

Thanks!
Serguei

On 11/13/18 12:50 PM, Daniil Titov wrote:
> Hi Serguei,
>
> Thank you for reviewing this change. You are right, the latest webrev is still v3.
>
> Webrev: http://cr.openjdk.java.net/~dtitov/8203174/webrev.03/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8203174
>
> Best regards,
> Daniil
>
> On 11/13/18, 12:05 PM, "serguei.spitsyn at oracle.com" <serguei.spitsyn at oracle.com> wrote:
>
>      Hi Daniil,
>      
>      I do not see the latest webrev in this email anymore.
>      Is it still the v3 version?
>      
>      If so then the fix looks good to me.
>      I like the comments you added there as they help.
>      
>      I was also concerned about the compiler issue.
>      Thank you for pointing that it was resolved with the JDK-8195627.
>      
>      Thanks,
>      Serguei
>      
>      
>      On 11/9/18 12:26 PM, Daniil Titov wrote:
>      > 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)
>      >      >>
>      >      >
>      >      >
>      >
>      >
>      >
>      >
>      
>      
>
>