Re: The Great Startup Problem, redux

[Claes Redestad]

Hi,

thanks for the pointer... :-)

However, while it's true that SVM (in its current form) imposes severe 
limits to dynamicity, it'd be a bug if jaotc, jlink or any other of the 
startup efforts (such as AppCDS) in the OpenJDK project changed 
semantics or imposed limits to indy-style dynamicity in any way:


- jaotc compiles code ahead of time, but do anything crazy like 
replacing indy callsites with something else. The bootstrap methods and 
machinery to spin bytecode may be AOT-compiled, of course, but the end 
result should be indistinguishable from running without AOT, semantically.
- jlink should be neutral in most aspects w.r.t dynamicity, and all of 
the plumbing for indy lives in the java.base module (which can't be 
removed by jlink).
- jlink *does* include a plugin to generate some of the runtime 
invariant building blocks used by indy statically at link-time based on 
profiling information. This is a speculative optimization that doesn't 
remove any capabilities: if the LFs, BMH species etc that have been 
pre-generated exists, they'll be used and the JVM might spend a bit less 
time setting things up. If they don't exist code will be spun up 
dynamically. Again, users shouldn't notice any difference other than 
slightly faster ramp-up time.


With regards to opportunities I think there are plenty of improvements 
that could be explored, both in the implementation and in the APIs. 
Coincidentally, I've recently been looking at a bunch of ISC stress 
tests as a tool to explore optimization opportunities in the MH API, and 
proposed one rather general optimization in this space mere hours 
ago[1]. Might be able to find some more in that general area..


Condy is another recent improvement that can likely be used for a lot of 
things, adding dynamicity and laziness in places where indy might not be 
the best fit. One example of that here: 
https://bugs.openjdk.java.net/browse/JDK-8186216


/Claes

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056480.html 



On 2018-11-07 18:01, Ghadi Shayban wrote:
The Great Startup Problem [1] was a wonderful read highlighting the 
problems surrounding the early life of a JVM application. In-flight 
efforts that allow (to a limited extent) better startup 
characteristics include jaotc, substrateVM, jlink. These efforts all 
trade away dynamicity of some sort, and dynamicity is one of the 
magical powers of the JVM.  What sort of opportunities exist for 
improving startup that don't trade away the capability to run indy or 
impose whole-program analysis? As a user of Clojure, I value how 
dynamic the JVM is along several dimensions.


[1]http://mail.openjdk.java.net/pipermail/mlvm-dev/2014-August/005890.html 




___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

The Great Startup Problem, redux

[Ghadi Shayban]

The Great Startup Problem [1] was a wonderful read highlighting the
problems surrounding the early life of a JVM application. In-flight efforts
that allow (to a limited extent) better startup characteristics include
jaotc, substrateVM, jlink. These efforts all trade away dynamicity of some
sort, and dynamicity is one of the magical powers of the JVM.  What sort of
opportunities exist for improving startup that don't trade away the
capability to run indy or impose whole-program analysis? As a user of
Clojure, I value how dynamic the JVM is along several dimensions.

[1] http://mail.openjdk.java.net/pipermail/mlvm-dev/2014-August/005890.html
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev