Should optimizations be observable for JVMTI agents?

[David Holmes]

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
>