On 4/12/2018 5:53 am, dean.l...@oracle.com wrote:
On 11/30/18 7:46 PM, JC Beyler wrote:
Questions because I'm not familiar with JVMCI consequences so not
really comments on the webrev but so that I know:
- Is it normaly that you can suspend when you are in a JVMCI frame?
Yes, because it's just Java code, and we allow all Java code to be
suspended, even Graal and JVMCI code.
A choice which can be argued for and against. On the one hand it is nice
to be able to try to debug JVMCI code, and on the other this injects
execution of Java code into places which to date could not execute Java
code and so can "shift" debugging actions from the application/test
code, to the JVMCI code. Arguably the application/test code may need to
have been more specific about its intent (ie verifying that the debuggee
is suspended in the expected frame) and has just "been lucky" but
nevertheless the use of JVMCI may disrupt existing code using these
facilities.
will/is there not a better way that we could detect that we are in a
JVMCI frame?
We could check the threads's _adjusting_comp_level flag for this
particular case, if we decided that we don't want to be able to debug
JVMCI Java code.
Is it always safe to suspend a JVMCI frame?
That's a good question. If it was grabbing any locks, then suspending
it could cause problems for other threads calling into JVMCI.
Another solution would be to do adjusting_comp_level() in a separate
thread. So I think there are at least 3 possible solutions:
1) Allow JVMCI adjusting_comp_level call to be suspended/debugged
2) Don't allow it to be suspended/debugged,
a) by running in a separate thread, or
b) don't suspend when _adjusting_comp_level flag is set
We could introduce a concept of "system Java" code, which, just like
Unix kernel code that is not debuggable without a kernel debugger, would
not normally be debuggable without setting a special flag.
That may be something to consider in the future (albeit something that
should IMHO have been considered well in the past!) but I think it's out
of scope for this particular issue if we want to address this in 12.
There's certainly a need, again IMHO, for a broader discussion as to how
VM services written in Java should interact with other platform services
intended for use with application and library code. I don't know if
JVMCI/Graal explicitly hide themselves from agents and
retransformation/redefinition/ClassFileLoadHook, or even basic things
like event generation (where JVMCI may now generate many more events
than previously encountered).
CCing graal-dev alias.
As a non-subscriber my reply will get held for moderation.
Cheers,
David
-----
dl
