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

David Holmes david.holmes at oracle.com
Thu Nov 22 08:12:51 UTC 2018


Hi Serguei,

Must be a mail system issue. This is the reply I wrote in response to 
the two replies you had attached:

http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-November/025927.html

"Hi Dan, Serguei,

I'm going to combine my response to you both into one as it's the same
discussion ..."

:)

Cheers,
David

On 22/11/2018 6:06 pm, serguei.spitsyn at oracle.com wrote:
> On 11/21/18 23:42, 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 :
> 
> Hi David,
> 
> I guess, it is again some issue with the mailing system.
> Please, find my and Dan's replies to your email in the attachments.
> 
> I'm still thinking about what would be a better choice here.
> 
> Thanks,
> Serguei
> 
> 
>> 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
>>>
> 


More information about the serviceability-dev mailing list