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

[Daniel D. Daugherty]

On 11/22/18 2:42 AM, David Holmes wrote:
>
>
> On 22/11/2018 5:36 pm, Thomas Stüfe wrote:
>> Hi JC,
>>
>> On Wed, Nov 21, 2018 at 6:03 PM JC Beyler <jcbeyler at google.com> wrote:
>>>
>>> Hi Thomas,
>>>
>> <snip>
>>>
>>> I actually agree with not using the service thread to be honest, 
>>> resource exhaustion seems to be something you'd want to know sooner 
>>> than later.
>>>
>>> How about we do both?
>>>    - Fix it now so that the compiler thread does not post the event 
>>> because we'd rather not have crashes and that can get backported
>>>    - Put out a RFE that would add the information to ThreadInfo and 
>>> work through the process of a CSR/etc. to get it working for future 
>>> versions?
>>>
>>> Thanks,
>>> Jc
>>>
>>
>> Makes sense, sure. But both Dan and Serguei voiced opposition to this
>> patch. Dan, Serguei, what do you think?
>
> I note neither Dan nor Serguei responded to my response to them :)

I didn't think a response from me was needed. The last thing I said was:

> I would have no problem suppressing the event from a "hidden" thread
> because those threads intentionally try to hide from JVM/TI. That would
> cover the case for the C1 and C2 CompilerThreads, but I don't know
> about these newer JVM/CI Compiler threads that actually run Java code...

I read your combined response to this as not in conflict with what I said.

The last line of your response:

 > So my preferred point solution is still to skip posting ResourceExhausted
 > if the thread can not run Java code.

matches what I said since the C1 and C2 compiler threads are hidden and
cannot run Java code. We're in agreement.

Dan



>
> Cheers,
> David
> -----
>
>>
>> If we do not find an agreement, I would rather close this bug as WNF
>> than push it in without consensus. I would then just fix it downstream
>> in our port.
>>
>> Your proposed RFE would still make sense, but not in jdk12 anymore,
>> let alone in older releases.
>>
>> Thanks, Thomas
>>
>