RFR 8205113: Update JVMTI doc references to object allocation tracking
David Holmes
david.holmes at oracle.com
Wed Jun 20 04:54:52 UTC 2018
On 20/06/2018 2:41 PM, 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.
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> <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>> 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>>> 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/>
>>>> > >
>>>> > > Thanks!
>>>> > >
>>>> > > Jeremy
>>>> >
>>>>
>>
>
More information about the serviceability-dev
mailing list