RFR 8205113: Update JVMTI doc references to object allocation tracking
David Holmes
david.holmes at oracle.com
Mon Jun 18 07:57:08 UTC 2018
On 18/06/2018 5:01 PM, Jeremy Manson wrote:
> We haven't changed when a VM issues "VM object allocation" events.
>
> There were references in the docs to a requirement to use bytecode
> rewriting and JNI interception to track allocations. With
> SampledObjectAlloc, this is no longer the case - SampledObjectAlloc can
> track them. This change is supposed to remove the references to those
> requirements, and provide suitable replacement text.
>
> VM object alloc has specific language about being able to use it to
> track allocations that cannot be tracked with bytecode instrumentation
> and JNI interception. My goal in rephrasing was to make it clear that,
> while you can still use it for this, you can also just use
> SampledObjectAlloc for everything.
Okay. That doesn't come across clearly to me - sorry. So you will now
get both kinds of events for allocations done in the VM?
Thanks,
David
> Jeremy
>
> On Sun, Jun 17, 2018 at 9:11 PM David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
> Hi Jeremy,
>
> On 16/06/2018 2:33 AM, Jeremy Manson wrote:
> > Hi all,
> >
> > There are a number of references in the JVMTI doc to its not doing
> > object allocation tracking. Now that JEP 331 has landed, these
> > references are obsolete. This patch changes those references
> accordingly.
> >
> > While I was there, I took the liberty of fixing some spelling errors.
> >
> > As far as I know, these are non-normative changes and modify no
> API, so
> > they should not require a CSR.
>
> I'm unclear on the nature of the change to "VM Object Allocation". Does
> the existence of SampledObjectAlloc change when a VM should issue "VM
> object allocation" events?
>
> Thanks,
> David
>
> >
> > Bug:
> > https://bugs.openjdk.java.net/browse/JDK-8205113
> >
> > Webrev:
> > http://cr.openjdk.java.net/~jmanson/8205113/webrev.00/
> >
> > Thanks!
> >
> > Jeremy
>
More information about the serviceability-dev
mailing list