Portability of checkpoints?

[Anton Kozlov]

On 2/4/22 20:38, Ashutosh Mehra wrote:
> I have done a write-up [1] describing the problems we faced and our
> observations.

Very nice write-up, thank you.

> 1. Portability of a checkpoint is not just a JVM problem. The problems that
> JVM faces may apply to native libraries as well.

I like the separation of the native code on the "lower" level (libc, CRIU) and
the "higher" one above the JVM (JNI code).

For the JNI code, what are our options as platform developers?  Applications
usually provide separate builds of JNI libraries for different operating
systems or flavors like glibc/musl.  Assuming that such kind of burden is
acceptable, maybe the portability is also OK?  Hopefully, not so much native
code cache CPU features, and also hard to fix like glibc.

Regarding libc, is it possible to avoid calls like memset that cache CPU
features? For JVM implementation, we may use our own implementation for
standard functions when the latter is inadequate.  Hotspot has enough memory
operations implemented, that are also optimized for the available CPU feature
set, probably better than the glibc. We already have jio_snprintf -- a portable
replacement for a standard function.

It's a different question if memset, etc are used by the JNI code or
implicitly.  As a wild thought, is it a good idea to provide a library in
LD_PRELOAD that routes some standard functions to JVM's implementation? Just as
a workaround until glibc is fixed.

> 2. Need for an option that would allow Hotspot to generate portable code at
> runtime.

I think an option should accept a set of the target CPU feature set like a C
compiler has a parameter for the target CPU.  It could be a raw CPUID value or
textual representation.  So it will give users the power to choose between
portability and performance.

Thanks,
Anton