Should optimizations be observable for JVMTI agents?
Reingruber, Richard
richard.reingruber at sap.com
Wed Sep 25 12:31:29 UTC 2019
> > > Not a yes/no question IMO. I certainly don't subscribe to your view that
> > > JVM TI must always expose the "abstract virtual machine" regardless of
> > > what may have been done in the real VM.
> >
> > That's what what the documentation says. Everything refers to the Java VM not to the native
> > platform. An object is allocated on the JVM heap which is distinct from native memory. JVM TI must
> > report an object on the JVM heap regardless wether that virtual allocation was mapped to x86
> > registers, linux thread stack, linux process heap, or to nv ram. This is just an example for
> > the fact that it is the state of the virtual machine which is inspected.
> >
> > Please read again https://docs.oracle.com/en/java/javase/13/docs/specs/jvmti.html#context
> >
> > 'Since this interface provides access to the state of applications running in the Java virtual
> > machine; terminology refers to the Java platform and not the native platform (unless stated
> > otherwise). For example:'
> >
> > "thread" means Java programming language thread.
> > "stack frame" means Java virtual machine stack frame.
> > "class" means Java programming language class.
> > "heap" means Java virtual machine heap. <- note this
> > "monitor" means Java programming language object monitor.
> >
> > These sum up to *the state* to be shown.
>
> The terminology clarification is simply that - a clarification so that
> when the spec says "heap" it means "Java heap", when it says "Thread" it
> means "Java thread" etc without having to spell it out each time. I do
> not read this as meaning anything about an "abstract virtual machine"
> state, it is about the Java Virtual Machine state - which to mean can be
> the concrete state as implemented by Hotspot, not some abstract
> conceptual model state.
It is more than that. It is the glue to the JVM and Java Language specifications. This is important
to accept. Otherwise I would suggest to do your java debugging with gdb and Intel (or AMD??) x86
manuals at your hand.
> We'll just have to agree to disagree here.
Agreed. All I do is offer my points to our audience hoping for a few '+1' ;)
Richard.
-----Original Message-----
From: David Holmes <david.holmes at oracle.com>
Sent: Mittwoch, 25. September 2019 12:34
To: Reingruber, Richard <richard.reingruber at sap.com>; hotspot-compiler-dev at openjdk.java.net; serviceability-dev at openjdk.java.net
Subject: Re: Should optimizations be observable for JVMTI agents?
On 25/09/2019 7:46 pm, Reingruber, Richard wrote:
> Hi David,
>
> thanks for taking part in the discussion.
>
> > Hi Richard,
> >
> > Thanks for continuing the discussion. Some responses below.
> >
> > On 25/09/2019 7:28 am, Reingruber, Richard wrote:
> > > Hi,
> > >
> > > I would like to get comments on the following questions:
> > >
> > > 1. Should optimizations be observable for JVMTI agents in general?
> >
> > Not a yes/no question IMO. I certainly don't subscribe to your view that
> > JVM TI must always expose the "abstract virtual machine" regardless of
> > what may have been done in the real VM.
>
> That's what what the documentation says. Everything refers to the Java VM not to the native
> platform. An object is allocated on the JVM heap which is distinct from native memory. JVM TI must
> report an object on the JVM heap regardless wether that virtual allocation was mapped to x86
> registers, linux thread stack, linux process heap, or to nv ram. This is just an example for
> the fact that it is the state of the virtual machine which is inspected.
>
> Please read again https://docs.oracle.com/en/java/javase/13/docs/specs/jvmti.html#context
>
> 'Since this interface provides access to the state of applications running in the Java virtual
> machine; terminology refers to the Java platform and not the native platform (unless stated
> otherwise). For example:'
>
> "thread" means Java programming language thread.
> "stack frame" means Java virtual machine stack frame.
> "class" means Java programming language class.
> "heap" means Java virtual machine heap. <- note this
> "monitor" means Java programming language object monitor.
>
> These sum up to *the state* to be shown.
The terminology clarification is simply that - a clarification so that
when the spec says "heap" it means "Java heap", when it says "Thread" it
means "Java thread" etc without having to spell it out each time. I do
not read this as meaning anything about an "abstract virtual machine"
state, it is about the Java Virtual Machine state - which to mean can be
the concrete state as implemented by Hotspot, not some abstract
conceptual model state.
We'll just have to agree to disagree here.
>
> You'll see that it is all about the _virtual_ machine.
> Maybe there is room for additional information about the native machine... but first JVMTI must
> show the virtual state to agents.
>
> > This seems potentially too
> > limiting and proscriptive to me. The JLS, as you note, already allows
> > for optimisations that may surprise the "naive". That is currently only
> > stated in terms of reachability and finalization, but it establishes the
> > precedent of being pragmatic about these things. Unfortunately the JLS
> > doesn't define its own interactions with specifications like JVM TI, so
> > we can't expect to find all the answers in the JLS, again IMO. The JVMS
> > also doesn't cover interactions between various specifications. If we
> > look at the JVM TI specification it is defined as:
> >
> > "It provides both a way to inspect the state and to control the
> > execution of applications running in the JavaTM virtual machine (VM). "
> >
> > That's nice and broad to me - its about what is running in the JVM. It
> > explicitly does not say anything about observability or control of
> > things that are visible in the Java source code (which seems to be what
> > your 'abstract virtual machine' maps to). Obviously there's is a lot of
> > correlation between the runtime entities and source code entities, but
> > no requirement to exactly replicate what may be present in the source
> > code. Indeed given there is no specification for how to transform source
> > code to bytecode, it would be very difficult for it to state that.
> >
> > So I think we have to consider each optimisation (or group thereof) on
> > its own merits, considering:
> > - how important it would be to accurately interact with things as
> > expressed at the source level
> > - the cost of disabling or reversing the optimisation when needed; and
> > - the overall cost and complexity it adds to the development and
> > maintenance of the JVM
> >
> > > 2. Should in particular optimzations based on escape analysis be observable?
> > >
> > > (a) Should GetOwnedMonitorInfo() exclude objects with eliminated locking?
> > > Currently it does [1]
> >
> > I certainly don't have a problem with lock-elision really meaning
> > lock-elision. But nor do I insist that is the way it should be.
> >
> > My concern with the current behaviour(?) and proposals in this area is
> > that the approaches are far too coarse-grained**. If we have the
> > can_get_monitor_info capability then we disable all of Escape Analysis
> > for everything! That's harsh. With your proposal for JDK-8227745 IIUC if
> > we are looking for monitors and hit an optimized frame then we deopt
> > incase it may contained an elided monitor. Less harsh but still more
> > coarse-grained than I would like. I would expect EA to be a bit smarter
> > here:
> >
> > - if an object is thread-confined but subject to synchronization, and we
> > can_get_monitor_info, then EA does not perform lock elision (or lock
> > coarsening)
> >
> > That way JVM TI just works as expected without disabling anything
> > unnecessarily, and without needing to preemptively deopt things "just in
> > case". Now full disclosure I am not a JIT person so while what I wrote
> > seems eminently sensible to me, there may be practical reasons why this
> > can't be done (or can't be done at a reasonable cost).
>
> Just disabling lock elimination is not sufficient, scalar replacement needs to be disabled too,
> because otherwise it is currently impossible to return the eliminated owner of a locked monitor.
Fine - if the object is used for synchronization it is not a candidate
for EA. The point is that EA can be far more selective in how it is
applied so that these problems with JVM TI don't arise.
Cheers,
David
-----
> Cheers, Richard.
>
> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: Mittwoch, 25. September 2019 04:08
> To: Reingruber, Richard <richard.reingruber at sap.com>; hotspot-compiler-dev at openjdk.java.net; serviceability-dev at openjdk.java.net
> Subject: Re: Should optimizations be observable for JVMTI agents?
>
> Hi Richard,
>
> Thanks for continuing the discussion. Some responses below.
>
> On 25/09/2019 7:28 am, Reingruber, Richard wrote:
>> Hi,
>>
>> I would like to get comments on the following questions:
>>
>> 1. Should optimizations be observable for JVMTI agents in general?
>
> Not a yes/no question IMO. I certainly don't subscribe to your view that
> JVM TI must always expose the "abstract virtual machine" regardless of
> what may have been done in the real VM. This seems potentially too
> limiting and proscriptive to me. The JLS, as you note, already allows
> for optimisations that may surprise the "naive". That is currently only
> stated in terms of reachability and finalization, but it establishes the
> precedent of being pragmatic about these things. Unfortunately the JLS
> doesn't define its own interactions with specifications like JVM TI, so
> we can't expect to find all the answers in the JLS, again IMO. The JVMS
> also doesn't cover interactions between various specifications. If we
> look at the JVM TI specification it is defined as:
>
> "It provides both a way to inspect the state and to control the
> execution of applications running in the JavaTM virtual machine (VM). "
>
> That's nice and broad to me - its about what is running in the JVM. It
> explicitly does not say anything about observability or control of
> things that are visible in the Java source code (which seems to be what
> your 'abstract virtual machine' maps to). Obviously there's is a lot of
> correlation between the runtime entities and source code entities, but
> no requirement to exactly replicate what may be present in the source
> code. Indeed given there is no specification for how to transform source
> code to bytecode, it would be very difficult for it to state that.
>
> So I think we have to consider each optimisation (or group thereof) on
> its own merits, considering:
> - how important it would be to accurately interact with things as
> expressed at the source level
> - the cost of disabling or reversing the optimisation when needed; and
> - the overall cost and complexity it adds to the development and
> maintenance of the JVM
>
>> 2. Should in particular optimzations based on escape analysis be observable?
>>
>> (a) Should GetOwnedMonitorInfo() exclude objects with eliminated locking?
>> Currently it does [1]
>
> I certainly don't have a problem with lock-elision really meaning
> lock-elision. But nor do I insist that is the way it should be.
>
> My concern with the current behaviour(?) and proposals in this area is
> that the approaches are far too coarse-grained**. If we have the
> can_get_monitor_info capability then we disable all of Escape Analysis
> for everything! That's harsh. With your proposal for JDK-8227745 IIUC if
> we are looking for monitors and hit an optimized frame then we deopt
> incase it may contained an elided monitor. Less harsh but still more
> coarse-grained than I would like. I would expect EA to be a bit smarter
> here:
>
> - if an object is thread-confined but subject to synchronization, and we
> can_get_monitor_info, then EA does not perform lock elision (or lock
> coarsening)
>
> That way JVM TI just works as expected without disabling anything
> unnecessarily, and without needing to preemptively deopt things "just in
> case". Now full disclosure I am not a JIT person so while what I wrote
> seems eminently sensible to me, there may be practical reasons why this
> can't be done (or can't be done at a reasonable cost).
>
> ** This is historical. The typical first-level approach has always been
> "debug on -> optimisation off". At least today we have "fastdebug" VMs,
> but still we have "specific debug capability on -> optimisation off".
>
>> (b) Should GetLocalObject() return null for scalar replaced objects?
>> Currently it does not. EA is disabled if agents can access locals.
>> (c) Should scalar replaced objects be omitted when agents iterate the heap / traverse the
>> object graph.
>> Currently they are omitted [2]
>> (d) Should memory optimizations (caching of reads) be observable?
>> Eg. should field modifications of a NoEscape object O by a JVMTI agent have an effect in
>> a compiled method that optimized field accesses based on EA?
>> Currently memory optimizations can be observed, if the agent uses heap functions only to
>> acquire a reference to the local object, which was not scalar replaced.
>
> I haven't thought enough about the above cases, or know enough about the
> related code to really comment.
>
> Cheers,
> David
> -----
>
>> ...and in the end hopefully an agreement :)
>>
>> 2a was discussed in the code review of JDK-8230677 [3]. David Holmes wished to generalize the
>> discussion and to draw more attention to it to get answers we can rely on.
>>
>> Thanks, Richard.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8230677
>>
>> [2] https://bugs.openjdk.java.net/browse/JDK-8230956
>>
>> [3] Prev. discussion
>> https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-September/029224.html
>>
More information about the serviceability-dev
mailing list