RFR(xs): 8213834: JVMTI ResourceExhausted should not be posted in CompilerThread

[serguei.spitsyn at oracle.com]

Hi Dan,

I thought the same event is going to be posted again on a different thread.
It was wrong assumption, so you are right, it is not a good approach to 
fix this issue.

Thanks,
Serguei


On 11/14/18 11:32, Daniel D. Daugherty wrote:
> I have a philosophical problem with a fix like this.
>
> The fix is making the assumption that the handler for this event will 
> want
> to run Java code and if the event is posted from a Java thread that 
> cannot
> run Java code, then we skip posting the event.
>
> If I happen to have a more conservative agent that does not run Java code
> in its handlers, then my agent won't receive this event even though it
> should not cause my agent any problems. That might be an unexpected 
> change
> in behavior on the part of my agent.
>
> Dan
>
>
>
> On 11/14/18 10:06 AM, Daniel D. Daugherty wrote:
>> Adding serviceability-dev at ...
>>
>> Since the proposed solution to the bug is to not post an event, I think
>> the Serviceability Team (which owns JVM/TI) needs to be involved 
>> directly
>> in the review.
>>
>> Dan
>>
>>
>> On 11/14/18 9:28 AM, Thomas Stüfe wrote:
>>> Dear all,
>>>
>>> may I please have reviews on this small patch. Note that this is
>>> borderline serviceability. I try to avoid crossposting, but if you
>>> think this should be looked at by serviceability feel free to forward
>>> it there.
>>>
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8213834
>>>
>>> CR: 
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8213834-jvmti-reourceexhausted-shall-not-be-posted-from-compiler-thread/webrev.00/webrev/
>>>
>>> Short description: we may post ResourceExhausted from Compiler
>>> threads. Handlers of this event may call back into the JVM, which may
>>> cause problems since we run in the compiler thread. The proposed
>>> solution is not to post the event in that case.
>>>
>>> See previous discussion here:
>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-November/025898.html 
>>>
>>>
>>> Thanks, Thomas
>>
>