CRIU resets j.l.VirtualThread.ForkJoinPool.parallelism after restore - #17618
Conversation
4085b76 to
bd167d1
Compare
bd167d1 to
ed5de2d
Compare
a29effa to
a76f932
Compare
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>
a76f932 to
ac50591
Compare
|
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 |
|
I mention it here, because with VirtualThreads ForkJoinPool will certainly be used. I guess it may not be with pre-JDK 21 builds |
|
jenkins compile win jdk8 |
|
jenkins test sanity alinux64 jdk21 |
CRIU resets
j.l.VirtualThread.ForkJoinPool.parallelismafter restoreIf there is no system property
jdk.virtualThreadScheduler.parallelismset at VM startup,j.l.VirtualThread.ForkJoinPool.parallelismvalue is reset to matchRuntime.getRuntime().availableProcessors()after CRIUrestore;
Added
VM_VMHelpersmethodsgetStaticFieldObject/findinstanceFieldOffset/setObjectFieldI32;Changed
hashClassTableAttopeekClassHashTable;Minor refactoring;
Added tests.
Signed-off-by: Jason Feng fengj@ca.ibm.com