Should optimizations be observable for JVMTI agents?

[Vladimir Kozlov]

I had very good discussion yesterday with Serguei Spitsyn from serviceability.
He said that we may not need one solution. Both cases, monitoring and debugging, are important and 
we can use different solutions for them.

As Andrew said, for monitoring you want to observe the same behavior as in production. I think we 
should not restrict JIT and others optimizations in this case. I also agree with Richard that JVMTI 
may report scalar replaced objects and elided monitors in this mode if requested - it is also 
interesting information.

For debugging we may want to see locals and monitors present in compiled code and it is reasonable 
to avoid optimizations which remove them. But even for debugging we may want to use optimized code 
as we do when debugging optimized C code (we don't expect to see all locals in such case).

May be we should check not which JVMTI capabilities are switched on but for what JVMTI is used for. 
Or add API for user to ask what he wants.

As Richard mentioned in some email compiled frame can't be deoptimized (to get objects and monitors 
back) if it is not top frame on stack. So we can't rely on deoptimization here. JIT and Runtime need 
to know what to do with optimizations when agent is attached to JVM.

I don't like suggestion for 8230956 to switch off EA when can_tag_objects is on. Based on 
declaration, can_tag_objects is always on. Which means we will have EA off in all cases including 
monitoring tools (JFR, managment, profiling) which is not acceptable for me.

I share David's concern about missing cases for some JVMTI capabilities which are not checked when 
JIT decides to use optimizations. And I think it will be troublesome to go through all capabilities 
old and new to see if we need to add checks.

For me as JIT compiler engineer it would be much simpler to ask JVMTI should optimizations be 
switched off or not and let JVMTI find in which case it is used and make decision instead of current 
case when JIT checks some JVMTI capabilities.

I agree to provide information in compiled code for JVMTI - we do provide information about scalar 
replaced object already.

And I think it would be much easier to document such relation between JIT and JVMTI.

Thanks,
Vladimir

On 9/25/19 7:32 AM, Andrew Dinn wrote:
> 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
>