From rvansa at openjdk.org Mon Dec 1 08:30:59 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Mon, 1 Dec 2025 08:30:59 GMT Subject: [crac] RFR: 8371549: [CRaC] Implement C/R in Selector on non-Linux [v2] In-Reply-To: References: Message-ID: > Historically we have an extensive set of tests for java.nio.channels.Selector. However this runs only on Linux (using CRIU) rather than being platform agnostic and tested on all platforms. On Linux, it does not exercise PollSelectorImpl (this can be preferred using a system property) either - just the default EpollSelectorImpl. > > This PR enables testing on all available Selector implementations, cleans up the implementation of those tests and introduces the C/R implementations. Radim Vansa has updated the pull request incrementally with one additional commit since the last revision: Set FD value on Windows, too ------------- Changes: - all: https://git.openjdk.org/crac/pull/276/files - new: https://git.openjdk.org/crac/pull/276/files/69fead7d..8fff09d5 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=276&range=01 - incr: https://webrevs.openjdk.org/?repo=crac&pr=276&range=00-01 Stats: 10 lines in 1 file changed: 7 ins; 0 del; 3 mod Patch: https://git.openjdk.org/crac/pull/276.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/276/head:pull/276 PR: https://git.openjdk.org/crac/pull/276 From jkratochvil at openjdk.org Tue Dec 2 11:02:00 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Tue, 2 Dec 2025 11:02:00 GMT Subject: [crac] RFR: 8372863: [CRaC] Fix glibc IFUNC for AVX_Fast_Unaligned_Load Message-ID: glibc derives `AVX_Fast_Unaligned_Load` from CPU features but it is based on hardware CPU features and so disabling a CPU feature required for `AVX_Fast_Unaligned_Load` will not disable `AVX_Fast_Unaligned_Load` itself and it needs an explicit `GLIBC_TUNABLES` environment variable disabling. There is a whole such category of 'preferred' bits. I hope no other bit causes crash (as they are there primarily for performance benefits) but that should be still verified. ------------- Commit messages: - fix glibc preferred bits Changes: https://git.openjdk.org/crac/pull/277/files Webrev: https://webrevs.openjdk.org/?repo=crac&pr=277&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372863 Stats: 26 lines in 2 files changed: 20 ins; 1 del; 5 mod Patch: https://git.openjdk.org/crac/pull/277.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/277/head:pull/277 PR: https://git.openjdk.org/crac/pull/277 From jkratochvil at openjdk.org Tue Dec 2 13:09:23 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Tue, 2 Dec 2025 13:09:23 GMT Subject: [crac] RFR: 8372863: [CRaC] Fix glibc IFUNC for AVX_Fast_Unaligned_Load [v2] In-Reply-To: References: Message-ID: > glibc derives `AVX_Fast_Unaligned_Load` from CPU features but it is based on hardware CPU features and so disabling a CPU feature required for `AVX_Fast_Unaligned_Load` will not disable `AVX_Fast_Unaligned_Load` itself and it needs an explicit `GLIBC_TUNABLES` environment variable disabling. > > There is a whole such category of 'preferred' bits. I hope no other bit causes crash (as they are there primarily for performance benefits) but that should be still verified. Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: jdk.vm.ci.common.JVMCIError: Missing CPU feature constants: [AVX_Fast_Unaligned_Load] ------------- Changes: - all: https://git.openjdk.org/crac/pull/277/files - new: https://git.openjdk.org/crac/pull/277/files/30290977..ccba8d03 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=277&range=01 - incr: https://webrevs.openjdk.org/?repo=crac&pr=277&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/crac/pull/277.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/277/head:pull/277 PR: https://git.openjdk.org/crac/pull/277 From rvansa at openjdk.org Tue Dec 2 13:09:26 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 2 Dec 2025 13:09:26 GMT Subject: [crac] RFR: 8372863: [CRaC] Fix glibc IFUNC for AVX_Fast_Unaligned_Load [v2] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 13:06:15 GMT, Jan Kratochvil wrote: >> glibc derives `AVX_Fast_Unaligned_Load` from CPU features but it is based on hardware CPU features and so disabling a CPU feature required for `AVX_Fast_Unaligned_Load` will not disable `AVX_Fast_Unaligned_Load` itself and it needs an explicit `GLIBC_TUNABLES` environment variable disabling. >> >> There is a whole such category of 'preferred' bits. I hope no other bit causes crash (as they are there primarily for performance benefits) but that should be still verified. > > Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: > > jdk.vm.ci.common.JVMCIError: Missing CPU feature constants: [AVX_Fast_Unaligned_Load] src/hotspot/cpu/x86/vm_version_x86.cpp line 1164: > 1162: } > 1163: > 1164: static const size_t tunables_size_max = 23; Is this something like `sizeof("AVX_Fast_Unaligned_Load")`? Could we use that instead? ------------- PR Review Comment: https://git.openjdk.org/crac/pull/277#discussion_r2581098844 From jkratochvil at openjdk.org Tue Dec 2 13:16:25 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Tue, 2 Dec 2025 13:16:25 GMT Subject: [crac] RFR: 8372863: [CRaC] Fix glibc IFUNC for AVX_Fast_Unaligned_Load [v3] In-Reply-To: References: Message-ID: > glibc derives `AVX_Fast_Unaligned_Load` from CPU features but it is based on hardware CPU features and so disabling a CPU feature required for `AVX_Fast_Unaligned_Load` will not disable `AVX_Fast_Unaligned_Load` itself and it needs an explicit `GLIBC_TUNABLES` environment variable disabling. > > There is a whole such category of 'preferred' bits. I hope no other bit causes crash (as they are there primarily for performance benefits) but that should be still verified. Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: Use sizeof("AVX_Fast_Unaligned_Load") ------------- Changes: - all: https://git.openjdk.org/crac/pull/277/files - new: https://git.openjdk.org/crac/pull/277/files/ccba8d03..62916ce0 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=277&range=02 - incr: https://webrevs.openjdk.org/?repo=crac&pr=277&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/crac/pull/277.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/277/head:pull/277 PR: https://git.openjdk.org/crac/pull/277 From jkratochvil at openjdk.org Tue Dec 2 13:16:28 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Tue, 2 Dec 2025 13:16:28 GMT Subject: [crac] RFR: 8372863: [CRaC] Fix glibc IFUNC for AVX_Fast_Unaligned_Load [v3] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 13:06:15 GMT, Radim Vansa wrote: >> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: >> >> Use sizeof("AVX_Fast_Unaligned_Load") > > src/hotspot/cpu/x86/vm_version_x86.cpp line 1164: > >> 1162: } >> 1163: >> 1164: static const size_t tunables_size_max = 23; > > Is this something like `sizeof("AVX_Fast_Unaligned_Load")`? Could we use that instead? Yes, done. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/277#discussion_r2581126494 From jkratochvil at openjdk.org Tue Dec 2 13:29:34 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Tue, 2 Dec 2025 13:29:34 GMT Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=0xfoo,0xbar on checkpoint Message-ID: Since [JDK-8368929](https://bugs.openjdk.org/browse/JDK-8368929) the message: Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=0xe14e1805fdfbf7,0xfcc on checkpoint. is wrong as it does not do logical and of both CPUFeatures masks. Yes, I should have caught it during [JDK-8368929](https://bugs.openjdk.org/browse/JDK-8368929) review. @rvansa will probably want to change the API but this is a PoC how it should work. It is in fact untested as I haven't run it with CRIU yet. ------------- Commit messages: - 8372933: [CRaC] Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=0xfoo,0xbar on checkpoint Changes: https://git.openjdk.org/crac/pull/278/files Webrev: https://webrevs.openjdk.org/?repo=crac&pr=278&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372933 Stats: 29 lines in 5 files changed: 18 ins; 0 del; 11 mod Patch: https://git.openjdk.org/crac/pull/278.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/278/head:pull/278 PR: https://git.openjdk.org/crac/pull/278 From rvansa at openjdk.org Tue Dec 2 13:47:47 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 2 Dec 2025 13:47:47 GMT Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=0xfoo, 0xbar on checkpoint In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 13:22:18 GMT, Jan Kratochvil wrote: > Since [JDK-8368929](https://bugs.openjdk.org/browse/JDK-8368929) the message: > > Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=0xe14e1805fdfbf7,0xfcc on checkpoint. > > is wrong as it does not do logical and of both CPUFeatures masks. > > Yes, I should have caught it during [JDK-8368929](https://bugs.openjdk.org/browse/JDK-8368929) review. > > @rvansa will probably want to change the API but this is a PoC how it should work. > > It is in fact untested as I haven't run it with CRIU yet. A test update along with a bugfix would be welcome. src/hotspot/share/include/crlib/crlib_image_constraints.h line 66: > 64: // if multiple images are considered for restore this method should always return false. > 65: // For failed require_bitmap it will copy the expected value to the provided buffer. > 66: bool (*is_failed)(crlib_conf_t *, const char *name, unsigned char *value_return); We should not change the API in a breaking way like this; rather add a new, more suitable method (a size-based check can validate if the method can be used). The change as you add it accommodates (based on type) only bitmaps, not labels, and does not do any checks on the buffer size. src/java.base/share/native/libcrexec/image_constraints.cpp line 286: > 284: print_bitmap("Constraint: ", static_cast(c.data), c.data_size); > 285: print_bitmap("Image: ", static_cast(t->data), t->data_size); > 286: if (c.comparison != EQUALS) { You should rather check that this was really a `SUBSET` comparison - in case of `SUPERSET` the desired value would be logical OR. Not sure if we should call it a 'conjuction' or an 'intersection' since we're talking about set. ------------- PR Review: https://git.openjdk.org/crac/pull/278#pullrequestreview-3530176525 PR Review Comment: https://git.openjdk.org/crac/pull/278#discussion_r2581223249 PR Review Comment: https://git.openjdk.org/crac/pull/278#discussion_r2581247962 From tpushkin at openjdk.org Tue Dec 2 13:54:59 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 2 Dec 2025 13:54:59 GMT Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=0xfoo, 0xbar on checkpoint In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 13:35:28 GMT, Radim Vansa wrote: >> Since [JDK-8368929](https://bugs.openjdk.org/browse/JDK-8368929) the message: >> >> Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=0xe14e1805fdfbf7,0xfcc on checkpoint. >> >> is wrong as it does not do logical and of both CPUFeatures masks. >> >> Yes, I should have caught it during [JDK-8368929](https://bugs.openjdk.org/browse/JDK-8368929) review. >> >> @rvansa will probably want to change the API but this is a PoC how it should work. >> >> It is in fact untested as I haven't run it with CRIU yet. > > src/hotspot/share/include/crlib/crlib_image_constraints.h line 66: > >> 64: // if multiple images are considered for restore this method should always return false. >> 65: // For failed require_bitmap it will copy the expected value to the provided buffer. >> 66: bool (*is_failed)(crlib_conf_t *, const char *name, unsigned char *value_return); > > We should not change the API in a breaking way like this; rather add a new, more suitable method (a size-based check can validate if the method can be used). > > The change as you add it accommodates (based on type) only bitmaps, not labels, and does not do any checks on the buffer size. Have there been any JDK releases since we introduced this API? I think not, then we should still be free to change it, shouldn't we? I haven't looked into the bug, so cannot comment on the change itself, just noticed this message. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/278#discussion_r2581295181 From jkratochvil at openjdk.org Tue Dec 2 13:59:33 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Tue, 2 Dec 2025 13:59:33 GMT Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=0xfoo, 0xbar on checkpoint In-Reply-To: References: Message-ID: <3quObRLXmnFukUm6tXRNGEwbA8sm1iWZ2GHPhvu9zBk=.f9368fc3-8eb1-4c74-9a5d-c678bf7ab2f0@github.com> On Tue, 2 Dec 2025 13:52:49 GMT, Timofei Pushkin wrote: >> src/hotspot/share/include/crlib/crlib_image_constraints.h line 66: >> >>> 64: // if multiple images are considered for restore this method should always return false. >>> 65: // For failed require_bitmap it will copy the expected value to the provided buffer. >>> 66: bool (*is_failed)(crlib_conf_t *, const char *name, unsigned char *value_return); >> >> We should not change the API in a breaking way like this; rather add a new, more suitable method (a size-based check can validate if the method can be used). >> >> The change as you add it accommodates (based on type) only bitmaps, not labels, and does not do any checks on the buffer size. > > Have there been any JDK releases since we introduced this API? I think not, then we should still be free to change it, shouldn't we? > > I haven't looked into the bug, so cannot comment on the change itself, just noticed this message. Maybe there should be `is_failed_label` and `is_failed_bitmap` but I just wanted something to get it running. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/278#discussion_r2581307614 From jkratochvil at openjdk.org Tue Dec 2 13:59:37 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Tue, 2 Dec 2025 13:59:37 GMT Subject: [crac] RFR: 8372933: [CRaC] Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=0xfoo, 0xbar on checkpoint In-Reply-To: References: Message-ID: <5PboUXb56x7EuIXErzusTU6GeLtmTMqkYdmjNTywfrM=.1aedfd80-d8ec-4b27-96a3-321cabe3186c@github.com> On Tue, 2 Dec 2025 13:41:27 GMT, Radim Vansa wrote: >> Since [JDK-8368929](https://bugs.openjdk.org/browse/JDK-8368929) the message: >> >> Restore failed due to incompatible or missing CPU features, try using -XX:CPUFeatures=0xe14e1805fdfbf7,0xfcc on checkpoint. >> >> is wrong as it does not do logical and of both CPUFeatures masks. >> >> Yes, I should have caught it during [JDK-8368929](https://bugs.openjdk.org/browse/JDK-8368929) review. >> >> @rvansa will probably want to change the API but this is a PoC how it should work. >> >> It is in fact untested as I haven't run it with CRIU yet. > > src/java.base/share/native/libcrexec/image_constraints.cpp line 286: > >> 284: print_bitmap("Constraint: ", static_cast(c.data), c.data_size); >> 285: print_bitmap("Image: ", static_cast(t->data), t->data_size); >> 286: if (c.comparison != EQUALS) { > > You should rather check that this was really a `SUBSET` comparison - in case of `SUPERSET` the desired value would be logical OR. Not sure if we should call it a 'conjuction' or an 'intersection' since we're talking about set. I agree it should be just for `SUBSET`. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/278#discussion_r2581309608 From jkratochvil at openjdk.org Wed Dec 3 15:14:33 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Wed, 3 Dec 2025 15:14:33 GMT Subject: [crac] RFR: 8373027: [CRaC] [CRIU] x86: FPU xsave area present, but host cpu doesn't support it Message-ID: <3YbDyW-4mvpp2wilomc_Vo8JBF0I8cOILbk21PHlq6A=.caf7209c-b357-4926-9065-459cbfa741f5@github.com> In some cases (such as AWS `t3.nano` -> `m1.small`) CRIU refuses to restore: x86: FPU xsave area present, but host cpu doesn't support it I think (based on information of @rvansa `xsave` is not needed for the safepoint of JDK checkpoint/restore. ------------- Commit messages: - capnone Changes: https://git.openjdk.org/crac/pull/279/files Webrev: https://webrevs.openjdk.org/?repo=crac&pr=279&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373027 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/crac/pull/279.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/279/head:pull/279 PR: https://git.openjdk.org/crac/pull/279 From jkratochvil at openjdk.org Wed Dec 3 15:20:16 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Wed, 3 Dec 2025 15:20:16 GMT Subject: [crac] RFR: 8372863: [CRaC] Fix glibc IFUNC for AVX_Fast_Unaligned_Load [v4] In-Reply-To: References: Message-ID: > glibc derives `AVX_Fast_Unaligned_Load` from CPU features but it is based on hardware CPU features and so disabling a CPU feature required for `AVX_Fast_Unaligned_Load` will not disable `AVX_Fast_Unaligned_Load` itself and it needs an explicit `GLIBC_TUNABLES` environment variable disabling. > > There is a whole such category of 'preferred' bits. I hope no other bit causes crash (as they are there primarily for performance benefits) but that should be still verified. Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: Add missing "AVX_Fast_Unaligned_Load" ------------- Changes: - all: https://git.openjdk.org/crac/pull/277/files - new: https://git.openjdk.org/crac/pull/277/files/62916ce0..1d3aac02 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=277&range=03 - incr: https://webrevs.openjdk.org/?repo=crac&pr=277&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/crac/pull/277.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/277/head:pull/277 PR: https://git.openjdk.org/crac/pull/277 From jkratochvil at openjdk.org Wed Dec 3 17:57:40 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Wed, 3 Dec 2025 17:57:40 GMT Subject: [crac] RFR: 8373043: [CRaC] remove CPUFeatures qemu-kvm test Message-ID: It did not work well, it was slow and `qemu-kvm -cpu` cannot provide the needed CPU features so it even could not find [JDK-8369729](https://bugs.openjdk.org/browse/JDK-8369729). ------------- Commit messages: - remove test/jdk/jdk/crac/CPUFeatures/CPUFeatures.* Changes: https://git.openjdk.org/crac/pull/280/files Webrev: https://webrevs.openjdk.org/?repo=crac&pr=280&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373043 Stats: 429 lines in 2 files changed: 0 ins; 429 del; 0 mod Patch: https://git.openjdk.org/crac/pull/280.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/280/head:pull/280 PR: https://git.openjdk.org/crac/pull/280 From jkratochvil at openjdk.org Wed Dec 3 18:59:04 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Wed, 3 Dec 2025 18:59:04 GMT Subject: [crac] RFR: 8372863: [CRaC] Fix glibc IFUNC for AVX_Fast_Unaligned_Load [v5] In-Reply-To: References: Message-ID: > glibc derives `AVX_Fast_Unaligned_Load` from CPU features but it is based on hardware CPU features and so disabling a CPU feature required for `AVX_Fast_Unaligned_Load` will not disable `AVX_Fast_Unaligned_Load` itself and it needs an explicit `GLIBC_TUNABLES` environment variable disabling. > > There is a whole such category of 'preferred' bits. I hope no other bit causes crash (as they are there primarily for performance benefits) but that should be still verified. Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: make AVX_Fast_Unaligned_Load lowercase as required ------------- Changes: - all: https://git.openjdk.org/crac/pull/277/files - new: https://git.openjdk.org/crac/pull/277/files/1d3aac02..8951ab0b Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=277&range=04 - incr: https://webrevs.openjdk.org/?repo=crac&pr=277&range=03-04 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/crac/pull/277.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/277/head:pull/277 PR: https://git.openjdk.org/crac/pull/277 From rvansa at openjdk.org Mon Dec 8 08:24:38 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Mon, 8 Dec 2025 08:24:38 GMT Subject: [crac] RFR: 8373027: [CRaC] [CRIU] x86: FPU xsave area present, but host cpu doesn't support it In-Reply-To: <3YbDyW-4mvpp2wilomc_Vo8JBF0I8cOILbk21PHlq6A=.caf7209c-b357-4926-9065-459cbfa741f5@github.com> References: <3YbDyW-4mvpp2wilomc_Vo8JBF0I8cOILbk21PHlq6A=.caf7209c-b357-4926-9065-459cbfa741f5@github.com> Message-ID: On Wed, 3 Dec 2025 15:08:08 GMT, Jan Kratochvil wrote: > In some cases (such as AWS `t3.nano` -> `m1.small`) CRIU refuses to restore: > > x86: FPU xsave area present, but host cpu doesn't support it > > > I think (based on information of @rvansa `xsave` is not needed for the safepoint of JDK checkpoint/restore. While the analysis in JIRA makes sense to me, can you think of a (manual) stress test that could prove this? I would imagine an application being checkpointed while doing heavy FPU calculations. On restore, we would assert that there was not a miscalculation? We should validate such test on machine that is expected to fail, by ignoring CPU features as well as setting `--cpu-cap=none` and see that it really does miscalculate, or fail in a different way... ------------- PR Comment: https://git.openjdk.org/crac/pull/279#issuecomment-3625596940 From rvansa at openjdk.org Mon Dec 8 08:35:44 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Mon, 8 Dec 2025 08:35:44 GMT Subject: [crac] RFR: 8372863: [CRaC] Fix glibc IFUNC for AVX_Fast_Unaligned_Load [v5] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 18:59:04 GMT, Jan Kratochvil wrote: >> glibc derives `AVX_Fast_Unaligned_Load` from CPU features but it is based on hardware CPU features and so disabling a CPU feature required for `AVX_Fast_Unaligned_Load` will not disable `AVX_Fast_Unaligned_Load` itself and it needs an explicit `GLIBC_TUNABLES` environment variable disabling. >> >> There is a whole such category of 'preferred' bits. I hope no other bit causes crash (as they are there primarily for performance benefits) but that should be still verified. > > Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: > > make AVX_Fast_Unaligned_Load lowercase as required Marked as reviewed by rvansa (Committer). ------------- PR Review: https://git.openjdk.org/crac/pull/277#pullrequestreview-3550755363 From duke at openjdk.org Mon Dec 8 08:44:56 2025 From: duke at openjdk.org (duke) Date: Mon, 8 Dec 2025 08:44:56 GMT Subject: [crac] RFR: 8372863: [CRaC] Fix glibc IFUNC for AVX_Fast_Unaligned_Load [v5] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 18:59:04 GMT, Jan Kratochvil wrote: >> glibc derives `AVX_Fast_Unaligned_Load` from CPU features but it is based on hardware CPU features and so disabling a CPU feature required for `AVX_Fast_Unaligned_Load` will not disable `AVX_Fast_Unaligned_Load` itself and it needs an explicit `GLIBC_TUNABLES` environment variable disabling. >> >> There is a whole such category of 'preferred' bits. I hope no other bit causes crash (as they are there primarily for performance benefits) but that should be still verified. > > Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: > > make AVX_Fast_Unaligned_Load lowercase as required @jankratochvil Your change (at version 8951ab0ba009d56810c6e11f2ded4fdfb02d1b12) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/crac/pull/277#issuecomment-3625695799 From jkratochvil at openjdk.org Mon Dec 8 09:10:56 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Mon, 8 Dec 2025 09:10:56 GMT Subject: [crac] Integrated: 8372863: [CRaC] Fix glibc IFUNC for AVX_Fast_Unaligned_Load In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 10:55:28 GMT, Jan Kratochvil wrote: > glibc derives `AVX_Fast_Unaligned_Load` from CPU features but it is based on hardware CPU features and so disabling a CPU feature required for `AVX_Fast_Unaligned_Load` will not disable `AVX_Fast_Unaligned_Load` itself and it needs an explicit `GLIBC_TUNABLES` environment variable disabling. > > There is a whole such category of 'preferred' bits. I hope no other bit causes crash (as they are there primarily for performance benefits) but that should be still verified. This pull request has now been integrated. Changeset: 238aa213 Author: Jan Kratochvil Committer: Radim Vansa URL: https://git.openjdk.org/crac/commit/238aa21340fc1ba2e2777f0e36153abec163c47e Stats: 29 lines in 4 files changed: 21 ins; 1 del; 7 mod 8372863: [CRaC] Fix glibc IFUNC for AVX_Fast_Unaligned_Load Reviewed-by: rvansa ------------- PR: https://git.openjdk.org/crac/pull/277 From rvansa at openjdk.org Mon Dec 15 15:33:44 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Mon, 15 Dec 2025 15:33:44 GMT Subject: [crac] RFR: 8373027: [CRaC] [CRIU] x86: FPU xsave area present, but host cpu doesn't support it In-Reply-To: <3YbDyW-4mvpp2wilomc_Vo8JBF0I8cOILbk21PHlq6A=.caf7209c-b357-4926-9065-459cbfa741f5@github.com> References: <3YbDyW-4mvpp2wilomc_Vo8JBF0I8cOILbk21PHlq6A=.caf7209c-b357-4926-9065-459cbfa741f5@github.com> Message-ID: On Wed, 3 Dec 2025 15:08:08 GMT, Jan Kratochvil wrote: > In some cases (such as AWS `t3.nano` -> `m1.small`) CRIU refuses to restore: > > x86: FPU xsave area present, but host cpu doesn't support it > > > I think (based on information of @rvansa `xsave` is not needed for the safepoint of JDK checkpoint/restore. @jankratochvil ping ^ ? ------------- PR Comment: https://git.openjdk.org/crac/pull/279#issuecomment-3656271951 From rvansa at openjdk.org Mon Dec 15 15:35:55 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Mon, 15 Dec 2025 15:35:55 GMT Subject: [crac] RFR: 8373687: [CRaC] Add metrics through jcmd Message-ID: Enable user adding custom metrics (and labels) through jcmd JDK.checkpoint command, e.g. using jcmd JDK.checkpoint metrics=foo=123,bar=0.456 ------------- Commit messages: - 8373687: [CRaC] Add metrics through jcmd Changes: https://git.openjdk.org/crac/pull/281/files Webrev: https://webrevs.openjdk.org/?repo=crac&pr=281&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373687 Stats: 312 lines in 9 files changed: 298 ins; 0 del; 14 mod Patch: https://git.openjdk.org/crac/pull/281.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/281/head:pull/281 PR: https://git.openjdk.org/crac/pull/281 From jkratochvil at openjdk.org Mon Dec 15 17:39:08 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Mon, 15 Dec 2025 17:39:08 GMT Subject: [crac] RFR: 8373027: [CRaC] [CRIU] x86: FPU xsave area present, but host cpu doesn't support it In-Reply-To: <3YbDyW-4mvpp2wilomc_Vo8JBF0I8cOILbk21PHlq6A=.caf7209c-b357-4926-9065-459cbfa741f5@github.com> References: <3YbDyW-4mvpp2wilomc_Vo8JBF0I8cOILbk21PHlq6A=.caf7209c-b357-4926-9065-459cbfa741f5@github.com> Message-ID: On Wed, 3 Dec 2025 15:08:08 GMT, Jan Kratochvil wrote: > In some cases (such as AWS `t3.nano` -> `m1.small`) CRIU refuses to restore: > > x86: FPU xsave area present, but host cpu doesn't support it > > > I think (based on information of @rvansa `xsave` is not needed for the safepoint of JDK checkpoint/restore. The JVM process may run native threads which are fully out of control JVM `_features`. So the whole CPUFeatures can always fail for CRaC-unaware application. But otherwise I tried it with FPU Java app and it works for me: import jdk.incubator.vector.DoubleVector; import jdk.incubator.vector.VectorSpecies; import jdk.incubator.vector.VectorOperators; import java.util.Random; public class CPUFeaturesAWS { static final int SIZE = 16_000_000; static final double[] array = new double[SIZE]; public static void main(String[] args) { Random rnd = new Random(42); for (int i = 0; i < SIZE; i++) array[i] = rnd.nextDouble(); VectorSpecies SPECIES = DoubleVector.SPECIES_512; while (true) { double sum = 0.0; int i = 0; for (; i + SPECIES.length() <= SIZE; i += SPECIES.length()) { var vec = DoubleVector.fromArray(SPECIES, array, i); sum += vec.reduceLanes(VectorOperators.ADD); } for (; i < SIZE; i++) sum += array[i]; double expected = expectedSum(); if (Math.abs(sum - expected) > 1e-6) { System.err.println("Mismatch! sum=" + sum + " expected=" + expected); System.exit(1); } System.out.println("CPUFeaturesCheck " + 42); } } private static double expectedSum() { double s = 0.0; for (double v : array) s += v; return s; } } ------------- PR Comment: https://git.openjdk.org/crac/pull/279#issuecomment-3656836579 From rvansa at openjdk.org Mon Dec 15 18:40:24 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Mon, 15 Dec 2025 18:40:24 GMT Subject: [crac] RFR: 8373027: [CRaC] [CRIU] x86: FPU xsave area present, but host cpu doesn't support it In-Reply-To: <3YbDyW-4mvpp2wilomc_Vo8JBF0I8cOILbk21PHlq6A=.caf7209c-b357-4926-9065-459cbfa741f5@github.com> References: <3YbDyW-4mvpp2wilomc_Vo8JBF0I8cOILbk21PHlq6A=.caf7209c-b357-4926-9065-459cbfa741f5@github.com> Message-ID: On Wed, 3 Dec 2025 15:08:08 GMT, Jan Kratochvil wrote: > In some cases (such as AWS `t3.nano` -> `m1.small`) CRIU refuses to restore: > > x86: FPU xsave area present, but host cpu doesn't support it > > > I think (based on information of @rvansa `xsave` is not needed for the safepoint of JDK checkpoint/restore. I thought that we +- control native threads through `glibc.cpu.hwcaps`, don't we? Except for hand-written assembly and similar. We should not give up on native threads in general. I think that in order to prove that the test above is efficient, you'd have to verify where are the safepoint injection points (as the executing thread will be stopped on safepoint before proceeding to checkpoint), and that a variable is stored in FPU register (not on stack) across the safepoint/checkpoint. (I don't know what are the current rules for safepoint injection, I hope that it will inject some safepoints even to those counted loops when it sees that these have 16M iterations). ------------- PR Comment: https://git.openjdk.org/crac/pull/279#issuecomment-3657059725 From jkratochvil at openjdk.org Mon Dec 15 18:52:03 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Mon, 15 Dec 2025 18:52:03 GMT Subject: [crac] RFR: 8373027: [CRaC] [CRIU] x86: FPU xsave area present, but host cpu doesn't support it In-Reply-To: <3YbDyW-4mvpp2wilomc_Vo8JBF0I8cOILbk21PHlq6A=.caf7209c-b357-4926-9065-459cbfa741f5@github.com> References: <3YbDyW-4mvpp2wilomc_Vo8JBF0I8cOILbk21PHlq6A=.caf7209c-b357-4926-9065-459cbfa741f5@github.com> Message-ID: On Wed, 3 Dec 2025 15:08:08 GMT, Jan Kratochvil wrote: > In some cases (such as AWS `t3.nano` -> `m1.small`) CRIU refuses to restore: > > x86: FPU xsave area present, but host cpu doesn't support it > > > I think (based on information of @rvansa `xsave` is not needed for the safepoint of JDK checkpoint/restore. `glibc.cpu.hwcaps` controls only glibc functions (like `memset` etc.). For example `libavutil` (of `ffmpeg`) is using `cpuid` instruction to select its CPU-optimized code, it is common also in other high performance libraries. ------------- PR Comment: https://git.openjdk.org/crac/pull/279#issuecomment-3657097651 From rvansa at openjdk.org Tue Dec 16 10:21:09 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 16 Dec 2025 10:21:09 GMT Subject: [crac] RFR: 8373687: [CRaC] Add metrics through jcmd [v2] In-Reply-To: References: Message-ID: > Enable user adding custom metrics (and labels) through jcmd JDK.checkpoint command, e.g. using > > jcmd JDK.checkpoint metrics=foo=123,bar=0.456 Radim Vansa has updated the pull request incrementally with one additional commit since the last revision: Add missing include ------------- Changes: - all: https://git.openjdk.org/crac/pull/281/files - new: https://git.openjdk.org/crac/pull/281/files/2ddc4410..87ac427e Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=281&range=01 - incr: https://webrevs.openjdk.org/?repo=crac&pr=281&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/crac/pull/281.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/281/head:pull/281 PR: https://git.openjdk.org/crac/pull/281 From rvansa at openjdk.org Tue Dec 16 21:05:28 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 16 Dec 2025 21:05:28 GMT Subject: [crac] RFR: 8373687: [CRaC] Add metrics through jcmd [v3] In-Reply-To: References: Message-ID: > Enable user adding custom metrics (and labels) through jcmd JDK.checkpoint command, e.g. using > > jcmd JDK.checkpoint metrics=foo=123,bar=0.456 Radim Vansa has updated the pull request incrementally with one additional commit since the last revision: Fix build on other platforms ------------- Changes: - all: https://git.openjdk.org/crac/pull/281/files - new: https://git.openjdk.org/crac/pull/281/files/87ac427e..b1ce4f41 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=281&range=02 - incr: https://webrevs.openjdk.org/?repo=crac&pr=281&range=01-02 Stats: 18 lines in 3 files changed: 17 ins; 1 del; 0 mod Patch: https://git.openjdk.org/crac/pull/281.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/281/head:pull/281 PR: https://git.openjdk.org/crac/pull/281 From rvansa at openjdk.org Wed Dec 17 08:25:25 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Wed, 17 Dec 2025 08:25:25 GMT Subject: [crac] RFR: 8373687: [CRaC] Add metrics through jcmd [v4] In-Reply-To: References: Message-ID: > Enable user adding custom metrics (and labels) through jcmd JDK.checkpoint command, e.g. using > > jcmd JDK.checkpoint metrics=foo=123,bar=0.456 Radim Vansa has updated the pull request incrementally with two additional commits since the last revision: - Try other header includes on MacOS - Add strsep for Windows ------------- Changes: - all: https://git.openjdk.org/crac/pull/281/files - new: https://git.openjdk.org/crac/pull/281/files/b1ce4f41..ccab9aed Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=281&range=03 - incr: https://webrevs.openjdk.org/?repo=crac&pr=281&range=02-03 Stats: 19 lines in 2 files changed: 19 ins; 0 del; 0 mod Patch: https://git.openjdk.org/crac/pull/281.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/281/head:pull/281 PR: https://git.openjdk.org/crac/pull/281 From rvansa at openjdk.org Wed Dec 17 10:20:14 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Wed, 17 Dec 2025 10:20:14 GMT Subject: [crac] RFR: 8373687: [CRaC] Add metrics through jcmd [v5] In-Reply-To: References: Message-ID: > Enable user adding custom metrics (and labels) through jcmd JDK.checkpoint command, e.g. using > > jcmd JDK.checkpoint metrics=foo=123,bar=0.456 Radim Vansa has updated the pull request incrementally with one additional commit since the last revision: Fix MacOSX ------------- Changes: - all: https://git.openjdk.org/crac/pull/281/files - new: https://git.openjdk.org/crac/pull/281/files/ccab9aed..919393d0 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=281&range=04 - incr: https://webrevs.openjdk.org/?repo=crac&pr=281&range=03-04 Stats: 4 lines in 2 files changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.org/crac/pull/281.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/281/head:pull/281 PR: https://git.openjdk.org/crac/pull/281 From rvansa at openjdk.org Wed Dec 17 10:34:00 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Wed, 17 Dec 2025 10:34:00 GMT Subject: [crac] RFR: 8373781: [CRaC] Permit -XX:CPUFeatures on other platforms Message-ID: Currently `-XX:CPUFeatures` option is available only on `x86_64`. This complicates creating multiarch container images that are meant to be universally runnable (with `-XX:CPUFeatures=generic`). I propose to make this option available on all architectures, with the non-arch specific values: * `generic` * `native` * `ignore` The implementation on non-x86_64 will only validate the sanity of the value. The related option `-XX:+ShowCPUFeatures` will print an informative message (saying that the option does not make much sense). `-XX:+IgnoreCPUFeatures` will be permitted as well, but it will be a no-op on the other architectures. ------------- Commit messages: - 8373781: [CRaC] Permit -XX:CPUFeatures on other platforms Changes: https://git.openjdk.org/crac/pull/282/files Webrev: https://webrevs.openjdk.org/?repo=crac&pr=282&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373781 Stats: 85 lines in 19 files changed: 56 ins; 14 del; 15 mod Patch: https://git.openjdk.org/crac/pull/282.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/282/head:pull/282 PR: https://git.openjdk.org/crac/pull/282