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
<jeremyman...@google.com <mailto:jeremyman...@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.hol...@oracle.com <mailto:david.hol...@oracle.com>> wrote:
On 20/06/2018 4:48 PM, serguei.spit...@oracle.com
<mailto:serguei.spit...@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.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:
>>
>> 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>
>> <mailto: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>>
>> >>> <mailto: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>>
>> >>> <mailto: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>>>
>> >>>>> <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:
>> >>>>>
>> >>>>> 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>
>> <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
<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/>
>> >>>>>
<http://cr.openjdk.java.net/%7Ejmanson/8205113/webrev.00/>
>> >>>>> > >
>> >>>>> > > Thanks!
>> >>>>> > >
>> >>>>> > > Jeremy
>> >>>>> >
>> >>>>>
>> >>>
>> >>
>>
>
