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