RFR 8205113: Update JVMTI doc references to object allocation tracking
David Holmes
david.holmes at oracle.com
Sat Jun 23 11:49:14 UTC 2018
On 23/06/2018 6:25 PM, serguei.spitsyn at oracle.com wrote:
> I've pushed the version suggested by David.
But you left out all of Jeremy's other fixups!
David
> Thanks,
> serguei
>
>
> On 6/22/18 09:00, serguei.spitsyn at oracle.com wrote:
>> Hi Jeremy,
>>
>> Okay, let me look at it once more before making final decision.
>> We have all suggestions and preferences listed.
>>
>> Thanks,
>> Serguei
>>
>>
>> On 6/22/18 08:22, Jeremy Manson wrote:
>>> 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 <mailto: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 <mailto:david.holmes at oracle.com>> wrote:
>>>
>>> On 20/06/2018 4:48 PM, serguei.spitsyn at oracle.com
>>> <mailto: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>
>>> >> <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:
>>> >>
>>> >> 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>
>>> >> <mailto: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>>
>>> >> >>> <mailto: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>>
>>> >> >>> <mailto: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>>>
>>> >> >>>>> <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:
>>> >> >>>>>
>>> >> >>>>> 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>
>>> >> <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
>>> <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/>
>>> >> >>>>>
>>> <http://cr.openjdk.java.net/%7Ejmanson/8205113/webrev.00/>
>>> >> >>>>> > >
>>> >> >>>>> > > Thanks!
>>> >> >>>>> > >
>>> >> >>>>> > > Jeremy
>>> >> >>>>> >
>>> >> >>>>>
>>> >> >>>
>>> >> >>
>>> >>
>>> >
>>>
>>
>
More information about the serviceability-dev
mailing list