CRIU resets j.l.VirtualThread.ForkJoinPool.parallelism after restore

[JasonFengJ9]

CRIU resets j.l.VirtualThread.ForkJoinPool.parallelism after restore

If there is no system property jdk.virtualThreadScheduler.parallelism set at VM startup, j.l.VirtualThread.ForkJoinPool.parallelism value is reset to match Runtime.getRuntime().availableProcessors() after CRIU
restore;
Added VM_VMHelpers methods getStaticFieldObject/findinstanceFieldOffset/setObjectFieldI32;
Changed hashClassTableAt to peekClassHashTable;
Minor refactoring;
Added tests.

Signed-off-by: Jason Feng fengj@ca.ibm.com

[tajila]

Im wondering if we should just use vmconstantpool for this. Im trying to think of a downside, but I think the cost to startup is negligeable

[JasonFengJ9]

Im wondering if we should just use vmconstantpool for this. Im trying to think of a downside, but I think the cost to startup is negligeable

This mimics the earlier modification of java/util/concurrent/atomic/AtomicLong.value. There were discussions about loading it at startup via vmconstantpool #14365 (comment), it was decided not to do so to avoid unnecessary class instances.
In addition, besides minor startup costs, it also adds a dependency on OpenJDK class initialisation at OpenJ9 bootup stage though most of the time is fine.
vmconstantpool does offer a simpler way for the field modification.

[tajila]

I mention it here, because with VirtualThreads ForkJoinPool will certainly be used. I guess it may not be with pre-JDK 21 builds

[tajila]

jenkins compile win jdk8

[tajila]

jenkins test sanity alinux64 jdk21