RFR(10): JDK-8178536: OOM ERRORS + SERVICE-THREAD TAKES A PROCESSOR TO 100%
Poonam Parhar
poonam.bajaj at oracle.com
Thu Jun 15 00:39:18 UTC 2017
On 6/14/2017 3:14 PM, Mandy Chung wrote:
>
>> On Jun 14, 2017, at 12:58 PM, Poonam Parhar <poonam.bajaj at oracle.com
>> <mailto:poonam.bajaj at oracle.com>> wrote:
>>
>>
>>
>> [Poonam] yes, that could also be another way. But for this bug, I
>> would like to keep the changes in sync with how the exceptions in the
>> Java code called from the VM side of the Service Thread are handled.
>> For example, ServiceThread::service_thread_entry() also calls
>> GCNotifier::sendNotification() and here’s how the pending exception
>> is handled.//
>> *//*
>>
>
> You can still keep the clear pending exception. The main thing I
> suggest is to change the trigger method to take the raw long value
> parameters instead of MemoryUsage and the object allocation is all
> done in Java.
>
>> :
>>
>> When we get to the issue of enabling the debugging of the user code
>> currently being executed on the ServiceThread, we will have to be
>> looking at these other notifications as well and I would prefer that
>> we make those changes together under the same bug and not with this
>> change.
>>
>> Please let me know what you think.
>>
>>
>
> I’m okay if you want to resolve this issue as is. And follow up my
> feedback together with the other issue with ServiceThread.
Thanks Mandy! Yes, I would like to integrate this fix as is, and change
the trigger() parameters for the other issue.
Regards,
Poonam
>
> Mandy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20170614/3bf83acd/attachment.html>
More information about the serviceability-dev
mailing list