Should optimizations be observable for JVMTI agents?

[Andrew Dinn]

On 25/09/2019 13:31, Reingruber, Richard wrote:
>   > 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' ;)
Sorry, but I'm going to throw in a -1 here, not on any grounds of
textual exegesis of the JVM spec rather those of simple pragmatism --
grounds that David already alluded to in his mention of finalization.

The path you want to go down is to force disabling of optimizations as
needed in order to ensure that JVMTI agents see a 'pure' version of the
/abstract/ machine state as defined in the Java Virtual Machine spec.
This is in many ways laudable:

1) such a 'pure' view is one that can be mapped fairly directly back to
the original Java application code state (assuming you factor in enough
knowledge of how javac translates code to bytecode and relying on the
fact that javac does not do anything very tricksy by way of optimization
during that translation) i.e. it is clear.

2) this pure view is going to be unchanged by whatever tricks the JIT
and/or JVM might have up their sleeves i.e. it is consistent/repeatable.

That latter point of consistency is, perhaps, more significant than the
former one of clarity since for most programmers bytecode is only ever
observed 'through a glass darkly'.

The downside comes when you consider why you might want to use an agent.
Primarily, JVMTI was provided for monitoring actual program execution.
Agents can also be used to modify program execution, making program
transformations that result in locally and/or globally variant
behaviour. Well, actually, I guess some monitoring operations falls into
that latter camp.

In order to pursue your proposed path it is going to be necessary to
disable, either piecemeal or wholesale, a variety of JIT optimizations.
This would mean that use of an agent might involve a cost that is
prohibitive.

Primarily, that's a cost in performance (whether measured in space or
time). When it comes to monitoring it is also the extra cost in the
accuracy of any report of what is being monitored -- if installation of
an agent or use of a montoring capability means you run different code
in a different way then you can end up measuring apples not pears.

That possible inaccuracy has to be weighed against other inaccuracies
that arise when the JIT invalidates or changes notifications of all the
events the idealized version of the abstract machine would imply. Where
the balance lies depends on the specifics of which optimizations are
disabled and the needs/behaviour of the app.

I believe that was what David was talking about when he mentioned as an
example the case of finalizers being run 'early' for non-reachable
objects. The optimization here allows early reclamation of objects and
reuse of stack slots. The cost is that object appear to go out of scope
'before' their fields are read -- at least as far as the source/abstract
machine view of 'before' is defined. How much that cost imposes on users
is unclear but the cost was discounted because finalization is already a
highly unreliable mechanism -- i.e. who cares?

So, I agree with David's general argument that we have to be pragmatic
about these things as he said taking into account

"  - 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"

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander