RFR 8205113: Update JVMTI doc references to object allocation tracking
serguei.spitsyn at oracle.com
serguei.spitsyn at oracle.com
Sat Jun 23 21:58:37 UTC 2018
Hi David,
This was your suggestion:
---
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.
---
I've pushed the patch:
diff -r f703d45c5687 src/hotspot/share/prims/jvmti.xml
--- a/src/hotspot/share/prims/jvmti.xml Tue Jun 05 11:55:39 2018 +0200
+++ b/src/hotspot/share/prims/jvmti.xml Sat Jun 23 01:18:57 2018 -0700
@@ -13507,9 +13507,8 @@
<event label="VM Object Allocation"
id="VMObjectAlloc" const="JVMTI_EVENT_VM_OBJECT_ALLOC" num="84">
<description>
- 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 intrumentation mechanisms.
+ Sent when a method causes the virtual machine to directly allocate an
+ Object visible to Java programming language code.
Generally object allocation should be detected by instrumenting
the bytecodes of allocating methods.
Object allocation generated in native code by JNI function
@@ -13520,6 +13519,12 @@
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.
<p/>
Typical examples where this event might be sent:
<ul>
Thanks,
Serguei
On 6/23/18 04:49, David Holmes wrote:
> On 23/06/2018 6:25 PM, serguei.spitsyn at oracle.com wrote:
>> I've pushed the version suggested by David.
>
> But you left out all of Jeremy's other fixups!
>
> David
>
>> Thanks,
>> serguei
>>
>>
>> On 6/22/18 09:00, serguei.spitsyn at oracle.com wrote:
>>> Hi Jeremy,
>>>
>>> Okay, let me look at it once more before making final decision.
>>> We have all suggestions and preferences listed.
>>>
>>> Thanks,
>>> Serguei
>>>
>>>
>>> On 6/22/18 08:22, Jeremy Manson wrote:
>>>> 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
>>>> <jeremymanson at google.com <mailto:jeremymanson at 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.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>>>
>>>> On 20/06/2018 4:48 PM, serguei.spitsyn at oracle.com
>>>> <mailto:serguei.spitsyn at 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.spitsyn at oracle.com <mailto:serguei.spitsyn at oracle.com>
>>>> >> <mailto:serguei.spitsyn at oracle.com
>>>> <mailto:serguei.spitsyn at oracle.com>>
>>>> <serguei.spitsyn at oracle.com
>>>> <mailto:serguei.spitsyn at oracle.com>
>>>> >> <mailto:serguei.spitsyn at oracle.com
>>>> <mailto:serguei.spitsyn at oracle.com>>> wrote:
>>>> >>
>>>> >> On 6/19/18 21:54, David Holmes wrote:
>>>> >> > On 20/06/2018 2:41 PM, serguei.spitsyn at oracle.com
>>>> <mailto:serguei.spitsyn at oracle.com>
>>>> >> <mailto:serguei.spitsyn at oracle.com
>>>> <mailto:serguei.spitsyn at 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.spitsyn at oracle.com <mailto:serguei.spitsyn at oracle.com>
>>>> >> <mailto:serguei.spitsyn at oracle.com
>>>> <mailto:serguei.spitsyn at oracle.com>>
>>>> >> >>> <mailto:serguei.spitsyn at oracle.com
>>>> <mailto:serguei.spitsyn at oracle.com>
>>>> >> <mailto:serguei.spitsyn at oracle.com
>>>> <mailto:serguei.spitsyn at oracle.com>>>
>>>> <serguei.spitsyn at oracle.com
>>>> <mailto:serguei.spitsyn at oracle.com>
>>>> >> <mailto:serguei.spitsyn at oracle.com
>>>> <mailto:serguei.spitsyn at oracle.com>>
>>>> >> >>> <mailto:serguei.spitsyn at oracle.com
>>>> <mailto:serguei.spitsyn at oracle.com>
>>>> >> <mailto:serguei.spitsyn at oracle.com
>>>> <mailto:serguei.spitsyn at 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.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>
>>>> >> <mailto:david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>>
>>>> <mailto:david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>
>>>> >> <mailto:david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>>>
>>>> >> >>>>> <mailto:david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>
>>>> >> <mailto:david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>>>
>>>> >> >>>>> <mailto:david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>
>>>> >> <mailto:david.holmes at oracle.com
>>>> <mailto:david.holmes at 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.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>
>>>> >> <mailto:david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>>
>>>> <mailto:david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>
>>>> >> <mailto:david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>>>
>>>> >> >>>>> <mailto:david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>
>>>> >> <mailto:david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>>>
>>>> <mailto:david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>
>>>> >> <mailto:david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>>>
>>>> >> >>>>> > <mailto:david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>
>>>> >> <mailto:david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>>
>>>> >> >>>>> <mailto:david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>
>>>> >> <mailto:david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>>>
>>>> >> >>>>> <mailto:david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>
>>>> >> <mailto:david.holmes at oracle.com
>>>> <mailto:david.holmes at 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
>>>> >> >>>>> >
>>>> >> >>>>>
>>>> >> >>>
>>>> >> >>
>>>> >>
>>>> >
>>>>
>>>
>>
More information about the serviceability-dev
mailing list