|
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.
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
On 6/19/18 21:54, David Holmes
wrote:
> On 20/06/2018 2:41 PM, 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>
<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>>
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>>>
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
>>>>> >
>>>>>
>>>
>>
|
