[portable-cr] RFR: Portable C/R [v2]

[Charles Oliver Nutter]

On Tue, 4 Jun 2024 17:20:59 GMT, Timofei Pushkin <duke at openjdk.org> wrote:

>> Implements a proof-of-concept "portable mode" for CRaC: a checkpoint-restore mechanism that does not rely on platform-dependent tools like CRIU instead saving VM state in terms of the Java specification (with some HotSpot specifics) — this allows to restore the saved state on machines with different CPU architecture and OS. A demo is available [here](https://github.com/TimPushkin/portable-crac-demo).
>> 
>> Expected downsides compared to the traditional CRaC are restrictions on platform-dependent code usage (e.g. at the moment of checkpoint no native methods can be executing, off-heap memory obtained via `sun.misc.Unsafe` should be released) and somewhat slower restoration speeds (because platform-dependent state, including JIT-compiled code, should be re-created). In the future, Project Leyden may help with the latter.
>> 
>> The mechanism is implemented as an internal part of HotSpot, it gets activated when an empty `CREngine` VM option is passed (i.e. `-XX:CREngine=""`, this is a temporary solution). Main implementation details are described in [this doc](https://github.com/TimPushkin/crac/blob/portable-cr/trimmed/doc/portable-cr.md).
>> 
>> Since this is a proof-of-concept implementation, it currently lacks some important features. E.g. at the moment some early-initialized classes are not restored, most of JDK classes have not yet been properly adapted, checkpointing via `jcmd` is not fully supported, additional tests and optimizations are needed.
>
> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update full name

I am excited to see this land!

As a test case, may I propose JRuby?

The JRuby startup story is very complex. We are an implementation of Ruby on the JVM, and since Ruby applications start from source we must boot up our pure-Java parser, compiler, and interpreter every time. Portions of JRuby itself are written in Ruby and must be parsed and loaded, and even the base "hello world" startup loads a large amount of Ruby code to bootstrap the standard library. On top of it all, we load thousands of classes at boot and generate hundreds more for invokedynamic method handle chains and early JIT-to-bytecode of early-loaded Ruby code.

Bypassing any of this would be a help for us.

I have had good results from using CRaC that bring us within a few times slower than the C implementation of Ruby (which is designed to start quickly), but the limitation of running only on Linux does not help the majority of Ruby developers that use MacOS.

Our other startup-time strategies are to disable all but tier 1 (-XX:TieredStopAtLevel=1, yay C1), or the new winner Leyden EA builds (which give us a 50% reduction in baseline startup).

I am interested in giving this a try, but someone else might get to it first! Running JRuby's baseline startup is easy:

* Download JRuby tarball or zip from [jruby.org](http://jruby.org)
* Run `bin/jruby -e 1`
* Bonus: run `bin/jruby -S gem list` which will list all preinstalled standard library "gems" and takes a couple of seconds on most systems.

Please feel free to reach out to me here or as @headius just about everywhere else!

-------------

PR Comment: https://git.openjdk.org/crac/pull/155#issuecomment-2223733921