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 
> <http://mail.openjdk.java.net/pipermail/mlvm-dev/2014-August/005890.html>
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev