RFR 8205113: Update JVMTI doc references to object allocation tracking
Jeremy Manson
jeremymanson at google.com
Fri Jun 22 15:22:57 UTC 2018
Hey folks -
With the window closing soon for 11, I feel that we should get this
revision in (just so that the spec is clear). That said, I don't feel
strongly about the wording. Who gets to make the decision?
Jeremy
On Wed, Jun 20, 2018 at 9:41 AM Jeremy Manson <jeremymanson at google.com>
wrote:
> FWIW, I'm also okay with David's version, with the caveat that "These
> methods should send this event" should probably read "Invocations of these
> methods should trigger this event".
>
> Jeremy
>
> On Wed, Jun 20, 2018 at 4:11 AM David Holmes <david.holmes at oracle.com>
> wrote:
>
>> On 20/06/2018 4:48 PM, serguei.spitsyn at oracle.com wrote:
>> > On 6/19/18 23:29, Jeremy Manson wrote:
>> >> Maybe we should make that clarification.
>> >>
>> >> Also, the reason I danced around that in my revision is that
>> >
>> > Understand that.
>> > But it is not a good style to clarify about SampledObjectAlloc in the
>> > spec of VMObjectAlloc.
>> > Would be nice to find a way to keep it simple.
>> >
>> > We could keep the original spec as it is but add that all this does not
>> > apply to the SampledObjectAlloc events.
>>
>> I don't think that really presents a coherent spec. I still like my
>> suggestion :)
>>
>> David
>>
>> >
>> > Something like below:
>> >
>> > Note, the above does not apply to the <internallink
>> > id="SampledObjectAlloc">SampledObjectAlloc</internallink>
>> > event as it is triggered on all Java object allocations, including
>> > those caused by bytecode method execution,
>> > JNI method execution, and directly by VM methods.*
>> > *
>> >
>> >> if you set the sampling rate to 0, you get unconditional sampling.
>> > A correction.
>> >
>> > I wrote:
>> > > It is still possible to sample every allocation with the
>> SamplingRate
>> > == 1.
>> >
>> > but had write: SamplingRate == 0
>> >
>> > Thanks,
>> > Serguei
>> >
>> >
>> >>
>> >> Jeremy
>> >>
>> >> On Tue, Jun 19, 2018 at 10:41 PM serguei.spitsyn at oracle.com
>> >> <mailto:serguei.spitsyn at oracle.com> <serguei.spitsyn at oracle.com
>> >> <mailto: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
>> >> <mailto: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>
>> >> >>> <mailto:serguei.spitsyn at oracle.com
>> >> <mailto:serguei.spitsyn at oracle.com>> <serguei.spitsyn at oracle.com
>> >> <mailto:serguei.spitsyn at oracle.com>
>> >> >>> <mailto: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>>
>> >> >>>>> <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:
>> >> >>>>>
>> >> >>>>> 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
>> >> <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
>> >> <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/>
>> >> >>>>> <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/20180622/40c6cef1/attachment-0001.html>
More information about the serviceability-dev
mailing list