Daemon mode for launcher tasks?

[lagergren]

Currently, the two major bottlenecks in XDK and XTC build time seem to be:

1) startup overhead for the Launcher forked JVMs 2) Lots of Java reflection based member name lookup when generering the BAST. (Try for example to breakpoint there and step over the call that builds the BAST, and take a look both at the human noticeable delay (which is partly due to debugging reflection and not that the code is ultra slow outside debug mode, but still shows up as big in the fire graph of the profile, without debuggers)

Would it be possible to set up a launcher broker for compiling (and maybe running) xtc code? It should be possible to have it work with ramdisk / in-memory "repository" or just "mmap in" the existing pnes generated by earlier compilations by the same persistent launcher?

This, I guess, would also easily support not just in memory compilation/ast etc, it could use a "ramdisk" module path with already built xdk (or any xtc) modules.

A trivial implementation could be more stateless than this, but it's hopefully not very hard to cache compile tasks and their results in memory, and use known good ones as xtc modules immediately returned. Even with conservative invalidation, it should be useful. And even without functionality turned on, but with a way to log/browse the history of code built would help me understand what the xtc processing entails. This can also be exported to tooling APIs for ides that can already visualize eg. Java build processes and class loading well.

This may be something that has value outside the XDK build as well, and that seems to be a good candidate for an injectable service to our users.

There seems to be very good abstraction for code "repositories" already, so I may be wrong, but Implementing a simple version of this kind of mechanism seems very pluggable.

[lagergren]

Btw were it not for me wanting to use this for building the XTC, this actually seems like an ideal component to write in XTC.