RFR 8205113: Update JVMTI doc references to object allocation tracking
serguei.spitsyn at oracle.com
serguei.spitsyn at oracle.com
Sun Jun 24 05:55:40 UTC 2018
On 6/23/18 16:19, serguei.spitsyn at oracle.com wrote:
>
> On 6/23/18 15:53, David Holmes wrote:
>> On 24/06/2018 7:58 AM, serguei.spitsyn at oracle.com wrote:
>>> Hi David,
>>>
>>> This was your suggestion:
>>
>> There was only one part of the patch being debated! The rest of the
>> patch was still applicable. Jeremy specifically stated
>>
>> "That would be okay with me, assuming that my other corrections are
>> made. I'd also like to fix the spelling of instrumentation in the
>> first sentence."
>
> Yes, I missed the other part - sorry. :(
> Will push it under a separate bug id.
Pushed the fix for typos under:
8205570 fix a number of typos in the JVMTI spec8
Thanks,
Serguei
> Not sure if another review is needed.
>
> Thanks,
> Serguei
>
>> David
>>
>>> ---
>>> 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.
>>> ---
>>>
>>> I've pushed the patch:
>>>
>>> diff -r f703d45c5687 src/hotspot/share/prims/jvmti.xml
>>> --- a/src/hotspot/share/prims/jvmti.xml Tue Jun 05 11:55:39 2018
>>> +0200
>>> +++ b/src/hotspot/share/prims/jvmti.xml Sat Jun 23 01:18:57 2018
>>> -0700
>>> @@ -13507,9 +13507,8 @@
>>> <event label="VM Object Allocation"
>>> id="VMObjectAlloc" const="JVMTI_EVENT_VM_OBJECT_ALLOC" num="84">
>>> <description>
>>> - 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 intrumentation mechanisms.
>>> + Sent when a method causes the virtual machine to directly
>>> allocate an
>>> + Object visible to Java programming language code.
>>> Generally object allocation should be detected by instrumenting
>>> the bytecodes of allocating methods.
>>> Object allocation generated in native code by JNI function
>>> @@ -13520,6 +13519,12 @@
>>> 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.
>>> <p/>
>>> Typical examples where this event might be sent:
>>> <ul>
>>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>>
>>> On 6/23/18 04:49, David Holmes wrote:
>>>> 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