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

[serguei.spitsyn at oracle.com]

Agreed on both statements below.

Thanks,
Serguei


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