Call for Discussion: New Project: Leyden

[Ioi Lam]

On 6/3/20 7:22 AM, Mike Hearn wrote:
> 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.

The current way for AppCDS for archiving heap objects is certainly too 
restricted. I think we'll probably allow a subset of classes to be 
initialized ahead of time, and the static fields of those classes will 
be archived into the heap. There are challenges -- picking the 
correct/optimal subset many require substantial work; we also need to 
make sure we don't archive the wrong things (ephemeral resources, 
environment dependencies, etc).

Thanks
- Ioi

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