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

[serguei.spitsyn at oracle.com]

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


Thanks,
Serguei


On 12/3/18 20:45, David Holmes wrote:
> 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