Agreed on both statements below.
Thanks,
Serguei
On 12/3/18 23:32, David Holmes wrote:
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
