Jeremy
On Tue, Jun 19, 2018 at 10:41 PM serguei.spit...@oracle.com
<mailto:serguei.spit...@oracle.com> <serguei.spit...@oracle.com
<mailto:serguei.spit...@oracle.com>> wrote:
On 6/19/18 21:54, David Holmes wrote:
> On 20/06/2018 2:41 PM, serguei.spit...@oracle.com
<mailto:serguei.spit...@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.spit...@oracle.com
<mailto:serguei.spit...@oracle.com>
>>> <mailto:serguei.spit...@oracle.com
<mailto:serguei.spit...@oracle.com>> <serguei.spit...@oracle.com
<mailto:serguei.spit...@oracle.com>
>>> <mailto:serguei.spit...@oracle.com
<mailto:serguei.spit...@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.hol...@oracle.com
<mailto:david.hol...@oracle.com> <mailto:david.hol...@oracle.com
<mailto:david.hol...@oracle.com>>
>>>>> <mailto:david.hol...@oracle.com
<mailto:david.hol...@oracle.com>>
>>>>> <mailto:david.hol...@oracle.com
<mailto:david.hol...@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.hol...@oracle.com
<mailto:david.hol...@oracle.com> <mailto:david.hol...@oracle.com
<mailto:david.hol...@oracle.com>>
>>>>> <mailto:david.hol...@oracle.com
<mailto:david.hol...@oracle.com>> <mailto:david.hol...@oracle.com
<mailto:david.hol...@oracle.com>>
>>>>> > <mailto:david.hol...@oracle.com
<mailto:david.hol...@oracle.com>
>>>>> <mailto:david.hol...@oracle.com
<mailto:david.hol...@oracle.com>>
>>>>> <mailto:david.hol...@oracle.com
<mailto:david.hol...@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
>>>>> >
>>>>>
>>>
>>
