Call for Discussion: New Project: Leyden

[Mike Hearn]

Thanks.

I didn't quite follow the question about seconds or minutes. When iterating
on code that's easily unit tested the JVM manages to provide a turnaround
time of a few seconds, at least it does for me when incremental compilation
is available. It gets more painful with app servers of course, hence the
popularity of JRebel.

Yes partitioning the app sounds like a great balance. It's the only way I
can see for AppCDS/AOT type optimisations to be applicable during
development, where otherwise JITC will continue to dominate despite that
developers probably start their app more than anyone else! Usually only a
tiny part of the app is changing and all the libraries are static, so build
systems could figure out a semi-static set of modules pretty easily. Just
assume anything pulled from a repository is static and eligible for
optimisations.

Heap archiving can be seen as a serialisation scheme, just one with an
unusually unstable data format. I wonder if it helps to look at it like
that - perhaps a lot of the logic can be moved into Java? For instance, do
the AppCDS archives *have* to be generated by C++ looking for magic
annotations/iterating the heap, or could some privileged Java code just
walk the graph, doing whatever checks are considered useful and building a
simple Object[] which is then passed into the VM for the GC to format a
heap region and return it as a byte buffer? Then build system authors, app
containers etc can take over management of AppCDS files, like deciding when
to [re]generate them and for which modules it's worth doing.

I've tried using the DCEVM in the past, which has better edit and continue.
It sounds good but I found that I very rarely edited *only*
post-initialisation code and so editing classes in place just ended up
being kind of useless, as there was no way to force re-construction and no
obvious semantics for how it could work. Especially problematic for GUI
apps, which is the kind of app where you really benefit from fast iteration
times but most of the iteration is in the code that constructs the GUI.

I looked a bit at how to resolve that. I toyed a bit with adding a
notification queue to classloaders, that lets app code learn when a class
has been redefined, and some APIs on top that would automatically track
dependencies and trigger re-construction of object graphs at various
user-defined points. Because DCEVM uses a rather large and complex patch I
ended up looking more into whether it'd be possible to do this with just
classloaders, perhaps in combination with a much smaller JVM patch, as if
you're rebuilding object graphs anyway then most of the magic class
redefinition does isn't actually useful.