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 4:32 pm, serguei.spitsyn at 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.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
>