RFR 8205113: Update JVMTI doc references to object allocation tracking
David Holmes
david.holmes at oracle.com
Wed Jun 20 11:11:33 UTC 2018
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
>> >>>>> >
>> >>>>>
>> >>>
>> >>
>>
>
More information about the serviceability-dev
mailing list