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