RFR 8205113: Update JVMTI doc references to object allocation tracking
Jeremy Manson
jeremymanson at google.com
Wed Jun 20 06:29:38 UTC 2018
Maybe we should make that clarification.
Also, the reason I danced around that in my revision is that if you set the
sampling rate to 0, you get unconditional sampling.
Jeremy
On Tue, Jun 19, 2018 at 10:41 PM serguei.spitsyn at oracle.com <
serguei.spitsyn at oracle.com> wrote:
> On 6/19/18 21:54, David Holmes wrote:
> > On 20/06/2018 2:41 PM, serguei.spitsyn at oracle.com wrote:
> >> On 6/19/18 21:11, Jeremy Manson wrote:
> >>> That would be okay with me, assuming that my other corrections are
> >>> made.
> >>
> >> Another option would be to say "non-sampling" instead of
> >> "unconditional":
> >>
> >> == Sent when a method causes the virtual machine to allocate an
> >> == Object visible to Java programming language code and the allocation
> >> += is not detectable by other *non-sampling* instrumentation mechanisms.
> >>
> >>
> >>> I'd also like to fix the spelling of instrumentation in the first
> >>> sentence.
> >>
> >> Yes, of course.
> >>
> >> Let's wait for David's opinion.
> >
> > I'm okay with Serguei's suggestion (combined with Jeremy's other
> > changes).
> >
> > I'm not that familiar with conditional versus unconditional
> > instrumentation.
>
> The whole point of the SampledObjectAlloc events is to post them
> conditionally
> depending on the SamplingRate so that just some amount of allocations is
> sampled.
> It is why the overhead can be minimal (less than 5 percents).
> It is still possible to sample every allocation with the SamplingRate == 1.
>
> The VMObjectAlloc events are posted unconditionally, so every VM
> allocation is posted.
>
> Thanks,
> Serguei
>
>
> >
> > Thanks,
> > David
> >
> >>
> >> Thanks,
> >> Serguei
> >>
> >>
> >>>
> >>> Jeremy
> >>>
> >>> On Mon, Jun 18, 2018 at 11:01 PM serguei.spitsyn at oracle.com
> >>> <mailto:serguei.spitsyn at oracle.com> <serguei.spitsyn at oracle.com
> >>> <mailto:serguei.spitsyn at oracle.com>> wrote:
> >>>
> >>> Hi Jeremy and David,
> >>>
> >>> Sorry for being late to the party.
> >>>
> >>> I'm also concerned about the Jeremy's spec update is more
> >>> intrusive than necessary.
> >>> One specifics of the new SampledObjectAlloc event is that it is
> >>> posted conditionally.
> >>> So, it is not fully comparable with the VMObjectAlloc event and
> >>> can not replace it in any way.
> >>> I'm even not yet convinced that any spec update is necessary.
> >>>
> >>> However, something like below would look minimal and reasonable:
> >>>
> >>> == Sent when a method causes the virtual machine to allocate an
> >>> == Object visible to Java programming language code and the
> >>> allocation
> >>> += is not detectable by other *unconditional* intrumentation
> >>> mechanisms.
> >>>
> >>> == Generally object allocation should be detected by instrumenting
> >>> == the bytecodes of allocating methods.
> >>>
> >>> == Object allocation generated in native code by JNI function
> >>> == calls should be detected using
> >>> == <internallink id="jniIntercept">JNI function
> >>> interception</internallink>.
> >>>
> >>> == Some methods might not have associated bytecodes and are not
> >>> == native methods, they instead are executed directly by the
> >>> == VM. These methods should send this event.
> >>>
> >>> == Virtual machines which are incapable of bytecode instrumentation
> >>> == for some or all of their methods can send this event.
> >>>
> >>> *++ Note that the <internallink
> >>> id="SampledObjectAlloc">SampledObjectAlloc</internallink>**
> >>> **++ event is conditionally triggered on all Java object
> >>> allocations, including those**
> >>> **++ caused by bytecode method execution, JNI method execution,
> >>> and directly by VM methods.**
> >>> *
> >>>
> >>> Maybe, just adding the last statement would be good enough.
> >>>
> >>> Thanks,
> >>> Serguei
> >>>
> >>>
> >>> On 6/18/18 21:36, David Holmes wrote:
> >>>> On 19/06/2018 4:50 AM, Jeremy Manson wrote:
> >>>>> Yup! The paragraph meanders a bit. How about something like:
> >>>>
> >>>> I'm not sure some of the change quite works. The original text
> >>>> considers there to be three kinds of methods that can cause
> >>>> allocation when executed:
> >>>> - Java (bytecode) methods
> >>>> - JNI methods
> >>>> - VM methods
> >>>>
> >>>> but you've turned this into three kinds of allocation: via
> >>>> bytecode, via JNI, and via the VM. You then refer to "triggering"
> >>>> an allocation when we tend to use triggering for events. You also
> >>>> refer to an allocation being "executed directly by the VM" (a
> >>>> phrase previously applied when the subject was a 'method') - but
> >>>> you don't really execute allocations.
> >>>>
> >>>> IIUC the problem with the existing text is just that it considers
> >>>> VM allocation events as being undetectable other than by this "VM
> >>>> object allocation event" - but that's no longer true. So how
> >>>> about something minimally changed like this:
> >>>>
> >>>> ---
> >>>> Sent when a method causes the virtual machine to directly
> >>>> allocate an
> >>>> Object visible to Java programming language code.
> >>>> Generally object allocation can be detected by instrumenting
> >>>> the bytecodes of allocating methods.
> >>>> Object allocation generated in native code by JNI function
> >>>> calls can be detected using
> >>>> <internallink id="jniIntercept">JNI function
> >>>> interception</internallink>.
> >>>> Some methods might not have associated bytecodes and are not
> >>>> native methods, they instead are executed directly by the
> >>>> VM. These methods should send this event.
> >>>> Virtual machines which are incapable of bytecode
> >>>> instrumentation
> >>>> for some or all of their methods can send this event.
> >>>>
> >>>> Note that the <internallink
> >>>> id="SampledObjectAlloc">SampledObjectAlloc</internallink>
> >>>> event is triggered on all Java object allocations, including
> >>>> those
> >>>> caused by bytecode method execution, JNI method execution, and
> >>>> directly by VM methods.
> >>>> ---
> >>>>
> >>>> Thanks,
> >>>> David
> >>>>
> >>>>> Sent when the virtual machine allocates an
> >>>>> Object visible to Java programming language code without using a
> >>>>> <code>new</code> bytecode variant or a JNI method.
> >>>>> Many approaches to tracking object allocation use a
> >>>>> combination of
> >>>>> bytecode-based instrumentation and <internallink
> >>>>> id="jniIntercept">JNI function
> >>>>> interception</internallink> to intercept allocations. However,
> >>>>> this
> >>>>> approach can leave a number of allocations undetected.
> >>>>> Allocations that are neither
> >>>>> triggered by bytecode nor JNI are executed directly by the VM.
> >>>>> When those allocations occur, the VM should send this event.
> >>>>> Virtual machines that are incapable of bytecode instrumentation
> >>>>> for some or all of their methods may also send this event.
> >>>>> <p/>
> >>>>> Note that the <internallink
> >>>>> id="SampledObjectAlloc">SampledObjectAlloc</internallink>
> >>>>> event is triggered on all Java object allocations, including
> >>>>> those triggered by bytecode,
> >>>>> JNI methods, and VM events.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mon, Jun 18, 2018 at 12:57 AM David Holmes
> >>>>> <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
> >>>>> <mailto:david.holmes at oracle.com>
> >>>>> <mailto:david.holmes at oracle.com>> wrote:
> >>>>>
> >>>>> 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>
> >>>>> <mailto:david.holmes at oracle.com> <mailto:david.holmes at oracle.com
> >
> >>>>> > <mailto:david.holmes at oracle.com
> >>>>> <mailto: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/
> >>>>> <http://cr.openjdk.java.net/%7Ejmanson/8205113/webrev.00/>
> >>>>> > >
> >>>>> > > Thanks!
> >>>>> > >
> >>>>> > > Jeremy
> >>>>> >
> >>>>>
> >>>
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180619/eb1b5eb6/attachment-0001.html>
More information about the serviceability-dev
mailing list