On 4/12/2018 4:32 pm, serguei.spit...@oracle.com wrote:
Hi David and Dean,
One option is to add a command line option (disabled by default)
to enable debugging/profiling of the Graal compiler.
This will help to avoid all these Graal related issues,
simplify the development and stabilize the tests.
It would simply tests, which could just disable it. But things would
still need to work correctly if enabled - we can't have the current
problems of trying to do an early return, or popframe, from the wrong frame.
Not sure the Graal developer will like this proposal though. :)
Also, it is not very clear what level of complexity we add with this.
For instance, we will have to identify all spots where new checks have
to be added.
Yes identifying exactly where you needed to check for this is
non-trivial I think.
And this all needs a broader discussion before choosing this kind of
approach.
Cheers,
David
Thanks,
Serguei
On 12/3/18 20:45, David Holmes wrote:
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
