RFR 8205113: Update JVMTI doc references to object allocation tracking
serguei.spitsyn at oracle.com
serguei.spitsyn at oracle.com
Sat Jun 23 23:19:54 UTC 2018
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.
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