Should optimizations be observable for JVMTI agents?

Reingruber, Richard richard.reingruber at sap.com
Wed Sep 25 09:46:25 UTC 2019 

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.

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.

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