[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-serviceability-dev
Subject: Re: RFR 8205113: Update JVMTI doc references to object allocation tracking
From: David Holmes <david.holmes () oracle ! com>
Date: 2018-06-25 5:12:17
Message-ID: 00f5491d-e5b4-9266-2725-04c96ccca5d0 () oracle ! com
[Download RAW message or body]
Thanks Serguei!
David
On 24/06/2018 3:55 PM, serguei.spitsyn@oracle.com wrote:
> On 6/23/18 16:19, serguei.spitsyn@oracle.com wrote:
>>
>> On 6/23/18 15:53, David Holmes wrote:
>>> On 24/06/2018 7:58 AM, serguei.spitsyn@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@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@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@google.com <mailto:jeremymanson@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@oracle.com <mailto:david.holmes@oracle.com>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On 20/06/2018 4:48 PM, serguei.spitsyn@oracle.com
>>>>>>>> <mailto:serguei.spitsyn@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@oracle.com
>>>>>>>> <mailto:serguei.spitsyn@oracle.com>
>>>>>>>> >> <mailto:serguei.spitsyn@oracle.com
>>>>>>>> <mailto:serguei.spitsyn@oracle.com>>
>>>>>>>> <serguei.spitsyn@oracle.com
>>>>>>>> <mailto:serguei.spitsyn@oracle.com>
>>>>>>>> >> <mailto:serguei.spitsyn@oracle.com
>>>>>>>> <mailto:serguei.spitsyn@oracle.com>>> wrote:
>>>>>>>> >>
>>>>>>>> >> On 6/19/18 21:54, David Holmes wrote:
>>>>>>>> >> > On 20/06/2018 2:41 PM, serguei.spitsyn@oracle.com
>>>>>>>> <mailto:serguei.spitsyn@oracle.com>
>>>>>>>> >> <mailto:serguei.spitsyn@oracle.com
>>>>>>>> <mailto:serguei.spitsyn@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@oracle.com
>>>>>>>> <mailto:serguei.spitsyn@oracle.com>
>>>>>>>> >> <mailto:serguei.spitsyn@oracle.com
>>>>>>>> <mailto:serguei.spitsyn@oracle.com>>
>>>>>>>> >> >>> <mailto:serguei.spitsyn@oracle.com
>>>>>>>> <mailto:serguei.spitsyn@oracle.com>
>>>>>>>> >> <mailto:serguei.spitsyn@oracle.com
>>>>>>>> <mailto:serguei.spitsyn@oracle.com>>>
>>>>>>>> <serguei.spitsyn@oracle.com
>>>>>>>> <mailto:serguei.spitsyn@oracle.com>
>>>>>>>> >> <mailto:serguei.spitsyn@oracle.com
>>>>>>>> <mailto:serguei.spitsyn@oracle.com>>
>>>>>>>> >> >>> <mailto:serguei.spitsyn@oracle.com
>>>>>>>> <mailto:serguei.spitsyn@oracle.com>
>>>>>>>> >> <mailto:serguei.spitsyn@oracle.com
>>>>>>>> <mailto:serguei.spitsyn@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@oracle.com
>>>>>>>> <mailto:david.holmes@oracle.com>
>>>>>>>> >> <mailto:david.holmes@oracle.com
>>>>>>>> <mailto:david.holmes@oracle.com>>
>>>>>>>> <mailto:david.holmes@oracle.com
>>>>>>>> <mailto:david.holmes@oracle.com>
>>>>>>>> >> <mailto:david.holmes@oracle.com
>>>>>>>> <mailto:david.holmes@oracle.com>>>
>>>>>>>> >> >>>>> <mailto:david.holmes@oracle.com
>>>>>>>> <mailto:david.holmes@oracle.com>
>>>>>>>> >> <mailto:david.holmes@oracle.com
>>>>>>>> <mailto:david.holmes@oracle.com>>>
>>>>>>>> >> >>>>> <mailto:david.holmes@oracle.com
>>>>>>>> <mailto:david.holmes@oracle.com>
>>>>>>>> >> <mailto:david.holmes@oracle.com
>>>>>>>> <mailto:david.holmes@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@oracle.com
>>>>>>>> <mailto:david.holmes@oracle.com>
>>>>>>>> >> <mailto:david.holmes@oracle.com
>>>>>>>> <mailto:david.holmes@oracle.com>>
>>>>>>>> <mailto:david.holmes@oracle.com
>>>>>>>> <mailto:david.holmes@oracle.com>
>>>>>>>> >> <mailto:david.holmes@oracle.com
>>>>>>>> <mailto:david.holmes@oracle.com>>>
>>>>>>>> >> >>>>> <mailto:david.holmes@oracle.com
>>>>>>>> <mailto:david.holmes@oracle.com>
>>>>>>>> >> <mailto:david.holmes@oracle.com
>>>>>>>> <mailto:david.holmes@oracle.com>>>
>>>>>>>> <mailto:david.holmes@oracle.com
>>>>>>>> <mailto:david.holmes@oracle.com>
>>>>>>>> >> <mailto:david.holmes@oracle.com
>>>>>>>> <mailto:david.holmes@oracle.com>>>
>>>>>>>> >> >>>>> > <mailto:david.holmes@oracle.com
>>>>>>>> <mailto:david.holmes@oracle.com>
>>>>>>>> >> <mailto:david.holmes@oracle.com
>>>>>>>> <mailto:david.holmes@oracle.com>>
>>>>>>>> >> >>>>> <mailto:david.holmes@oracle.com
>>>>>>>> <mailto:david.holmes@oracle.com>
>>>>>>>> >> <mailto:david.holmes@oracle.com
>>>>>>>> <mailto:david.holmes@oracle.com>>>
>>>>>>>> >> >>>>> <mailto:david.holmes@oracle.com
>>>>>>>> <mailto:david.holmes@oracle.com>
>>>>>>>> >> <mailto:david.holmes@oracle.com
>>>>>>>> <mailto:david.holmes@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
>>>>>>>> >> >>>>> >
>>>>>>>> >> >>>>>
>>>>>>>> >> >>>
>>>>>>>> >> >>
>>>>>>>> >>
>>>>>>>> >
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic