RFR (S) 8203356: VM Object Allocation Collector can infinite recurse

JC Beyler jcbeyler at google.com
Tue Aug 28 04:01:01 UTC 2018


Hi Chris,

Thanks for looking at the webrev. I fixed the copyrights for the files here
and also created https://bugs.openjdk.java.net/browse/JDK-8210035 because I
saw that files I created for the HeapMonitor work have the same issue. I'll
send out a webrev shortly to fix those.

Thanks again!
Jc

On Mon, Aug 27, 2018 at 3:39 PM Chris Plummer <chris.plummer at oracle.com>
wrote:

> Hi JC,
>
> The jvmtiExport.cpp changes look fine, but I'm no expert in this area.
>
> I think you need to fix the copyrights in the new files. My understanding
> is they need to include the Oracle copyright. Search for examples from "Red
> Hat" and "SAP" to see what I mean.
>
> I'm not sure about the nbproject changes. I've never seen this file get
> updated before.
>
> thanks,
>
> Chris
>
> On 8/22/18 4:20 PM, JC Beyler wrote:
>
> Hi all,
>
> Would anyone want to look at this change? It helps fix a minor bug if
> someone provokes a VM allocation during a VM Allocation Event.
>
> Webrev: http://cr.openjdk.java.net/~jcbeyler/8203356/webrev.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8203356
>
> Thanks!
> Jc
>
> On Thu, Aug 2, 2018 at 12:46 PM JC Beyler <jcbeyler at google.com> wrote:
>
>> Hi all,
>>
>> (Renaming the thread that did not have the RFR in front of the subject, I
>> apologize)
>>
>> Could someone review this change:
>>
>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8203356/webrev.00/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203356
>>
>> Basically, if during a callback from a VMObjectAlloc event, the user
>> provokes a clone, the code would send a new callback and you can recurse
>> infinitely.
>>
>> I added a test that fails without the fix and passes now.
>>
>> Thanks,
>> Jc
>>
>
>
> --
>
> Thanks,
> Jc
>
>
>

-- 

Thanks,
Jc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180827/126502c7/attachment.html>


More information about the serviceability-dev mailing list