RFR 8214572: nsk/jvmti/unit/ForceEarlyReturn/earlyretbase should not suspend the thread when the top frame executes JVMCI code

[David Holmes]

On 4/12/2018 5:53 am, dean.long at 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