> > > 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. > > 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' ;) Richard. -----Original Message----- From: David Holmes <david.hol...@oracle.com> Sent: Mittwoch, 25. September 2019 12:34 To: Reingruber, Richard <richard.reingru...@sap.com>; hotspot-compiler-...@openjdk.java.net; serviceability-dev@openjdk.java.net Subject: Re: Should optimizations be observable for JVMTI agents? On 25/09/2019 7:46 pm, Reingruber, Richard wrote: > 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. 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. We'll just have to agree to disagree here. > > 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. Fine - if the object is used for synchronization it is not a candidate for EA. The point is that EA can be far more selective in how it is applied so that these problems with JVM TI don't arise. Cheers, David ----- > Cheers, Richard. > > -----Original Message----- > From: David Holmes <david.hol...@oracle.com> > Sent: Mittwoch, 25. September 2019 04:08 > To: Reingruber, Richard <richard.reingru...@sap.com>; > hotspot-compiler-...@openjdk.java.net; serviceability-dev@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 >>
