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
>
