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

[dean.long at oracle.com]

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.

> 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.

CCing graal-dev alias.

dl