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@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
