|
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.
Thanks,
Serguei
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>>
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>>>
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/
> >
> > Thanks!
> >
> > Jeremy
>
|
