[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    RE: Should optimizations be observable for JVMTI agents?
From:       "Reingruber, Richard" <richard.reingruber () sap ! com>
Date:       2019-09-26 14:10:53
Message-ID: VI1PR02MB48291530D03658A38ED7E06B9B860 () VI1PR02MB4829 ! eurprd02 ! prod ! outlook ! com
[Download RAW message or body]

Vladimir and Andrew, thanks for the feedback. Even if it is -1 so far ;)

I think I should clarify what my intend and motivation are.

Clearly it is not my intend to hinder optimization in the (potential) presence of \
JVMTI agents. It probably looks like it, though, as I'm opening all those bugs \
requesting to disable EA.

All the bugs are split off the RFE JDK-8227745. Vladimir has asked me to do so. This \
way we can discuss the issues I see one-by-one and we're also able to selectively \
downport conservative fixes, i.e. disabling EA in some scenarios.

**My actual intend** is to enable EA independently of JVMTI agents, reconstructing \
the high level state just before it is inspected.

**Main motivation** behind RFE JDK-8227745 is to be able to start a production system \
in a mode that allows to initiate a debugging session anytime later if necessary or \
desired. In most cases debugging will never be activated and the production systems \
should run at the best possible performance while still being ready for debugging.

Besides this the enhancement will improve performance when a debugger has attached to \
the vm.

Note that the cost for this is virtually zero when you don't make JVMTI calls. You'll \
get the full speed-up of EA. Note also that most of the required debuginfo is there \
already. It is needed to switch from compiled to interpreted execution.

If your agent actually performs JVMTI calls, then I would estimate the costs of \
reconstructing the state, i.e. reallocating/relocking and saving the objects for \
later deoptimization as relatively small. Also you have to do that just once. The \
next time the agent inspects the same part of the app state it will be there already.

Thanks, Richard.

PS: I'll be out-of-office for a week and therefore unresponsive.

-----Original Message-----
From: Vladimir Kozlov <vladimir.kozlov@oracle.com> 
Sent: Mittwoch, 25. September 2019 18:53
To: Andrew Dinn <adinn@redhat.com>; Reingruber, Richard <richard.reingruber@sap.com>; \
David Holmes <david.holmes@oracle.com>; hotspot-compiler-dev@openjdk.java.net; \
                serviceability-dev@openjdk.java.net
Subject: Re: Should optimizations be observable for JVMTI agents?

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
> 


[prev in list] [next in list] [prev in thread] [next in thread]