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.spit...@oracle.com" <serguei.spit...@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.spit...@oracle.com" <serguei.spit...@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.l...@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) > >> > > > > > > > >
