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)
