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 From rvansa at openjdk.org Wed Dec 17 14:10:58 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Wed, 17 Dec 2025 14:10:58 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. OK. So there is a chance that native thread will use invalid instruction and fail later after restore - while this would be unfortunate, I think that possibility of such crashes is still outweighed by ability to restore in the CPU combos you mention. In other worse, we allow obviously detectable crashes to ignore some false positives. What I am worried about is miscalculation; if (a part of) the xsave area is not restored correctly, can this produce a calculation error without triggering SIGILL? ------------- PR Comment: https://git.openjdk.org/crac/pull/279#issuecomment-3665530137 From rvansa at openjdk.org Wed Dec 17 15:04:26 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Wed, 17 Dec 2025 15:04:26 GMT Subject: [crac] RFR: 8373687: [CRaC] Add metrics through jcmd [v5] In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 10:20:14 GMT, Radim Vansa wrote: >> 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 Looks like the macos builds have just been made defunct - we probably will have to sync with upstream & new images: GitHub change: https://github.com/actions/runner-images/issues/13046 Upstream JDK commit: https://github.com/openjdk/jdk/commit/1ea8cfa6dc8e6f96fd87553331abaae17ec173ea ------------- PR Comment: https://git.openjdk.org/crac/pull/281#issuecomment-3665752461 From jkratochvil at openjdk.org Wed Dec 17 16:03:00 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Wed, 17 Dec 2025 16:03:00 GMT Subject: [crac] RFR: 8373027: [CRaC] [CRIU] x86: FPU xsave area present, but host cpu doesn't support it In-Reply-To: References: <3YbDyW-4mvpp2wilomc_Vo8JBF0I8cOILbk21PHlq6A=.caf7209c-b357-4926-9065-459cbfa741f5@github.com> Message-ID: On Wed, 17 Dec 2025 14:08:16 GMT, Radim Vansa wrote: > What I am worried about is miscalculation; if (a part of) the xsave area is not restored correctly, can this produce a calculation error without triggering SIGILL? This can occur in native libraries (such as ffmpeg), but there is nothing we can do about it. It is unrelated to this patch and is a general JDK CPUFeatures issue. For Java code, the CPUFeatures subsystem already prevents such crashes. When `--cpu-cap=none` is used, CRIU does not check the `XSAVE` and `OSXSAVE` flags. These flags are required to enable `CPU_AVX`, `CPU_AVX2`, and similar features in the JDK. Therefore, if the JVM being restored lacks `XSAVE`, it will also lack `CPU_AVX`, and the checkpointed image will not use `CPU_AVX`; otherwise, the CPUFeatures code would refuse to restore the image. In other words, the JDK CPUFeatures code already verifies compatibility, so CRIU does not need to perform duplicate checks with `--cpu-cap`. ------------- PR Comment: https://git.openjdk.org/crac/pull/279#issuecomment-3666014658 From rvansa at openjdk.org Thu Dec 18 06:52:28 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Thu, 18 Dec 2025 06:52:28 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. Marked as reviewed by rvansa (Committer). ------------- PR Review: https://git.openjdk.org/crac/pull/279#pullrequestreview-3591067895 From duke at openjdk.org Thu Dec 18 08:40:02 2025 From: duke at openjdk.org (duke) Date: Thu, 18 Dec 2025 08:40:02 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 Your change (at version 140cd6345603f4601aaa620ca44439ecf5bc9a3d) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/crac/pull/279#issuecomment-3669063334 From jkratochvil at openjdk.org Thu Dec 18 13:03:55 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Thu, 18 Dec 2025 13:03:55 GMT Subject: [crac] Integrated: 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. This pull request has now been integrated. Changeset: 311dafdb Author: Jan Kratochvil Committer: Radim Vansa URL: https://git.openjdk.org/crac/commit/311dafdbf25423bbc1732097d0632b210eacf60b Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8373027: [CRaC] [CRIU] x86: FPU xsave area present, but host cpu doesn't support it Reviewed-by: rvansa ------------- PR: https://git.openjdk.org/crac/pull/279 From tpushkin at openjdk.org Mon Dec 22 14:43:36 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 22 Dec 2025 14:43:36 GMT Subject: [crac] RFR: 8373687: [CRaC] Add metrics through jcmd [v5] In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 10:20:14 GMT, Radim Vansa wrote: >> 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 We should introduce a Java API for setting labels too at some point src/hotspot/share/runtime/crac.cpp line 714: > 712: // silently ignoring this > 713: return true; > 714: } I think we should at least print a warning in such case. I.e. expose a method for the JCMD code to check for support and print the warning to the JCMD stream if there's none. Then here we should fail in such case. Same for `record_image_score`. src/hotspot/share/runtime/crac.cpp line 726: > 724: // silently ignoring this > 725: return true; > 726: } Not a part of this PR and we should've discussed this earlier, but why don't we fail here? We provide `is_image_score_supported` for Java to check, so we could make `Score.record()` not call this at all in such case. Same for the user-facing code: `Score.setScore` could throw `UnsupportedOperationException` when `Score.isSupported` returns `false`. src/hotspot/share/runtime/crac_engine.cpp line 488: > 486: bool CracEngine::set_label(const char* label, const char* value) { > 487: return _image_constraints_api->set_label(_conf, label, value); > 488: } Nitpick: would be better to group this together with the rest of the `_image_constraints_api` code src/hotspot/share/services/diagnosticCommand.cpp line 1090: > 1088: void CheckpointDCmd::execute(DCmdSource source, TRAPS) { > 1089: > 1090: const char *metrics = _metrics.value(); Suggestion: void CheckpointDCmd::execute(DCmdSource source, TRAPS) { const char *metrics = _metrics.value(); src/hotspot/share/services/diagnosticCommand.cpp line 1092: > 1090: const char *metrics = _metrics.value(); > 1091: if (metrics != nullptr) { > 1092: LocaleGuard lg; What is the problem with locales? Why is this needed for metrics but not labels? src/hotspot/share/services/diagnosticCommand.cpp line 1171: > 1169: > 1170: #ifdef _WINDOWS > 1171: static char *strsep(char **strp, const char *delim) { We have this in two places now, we could move it to `src/hotspot/share/utilities/stringUtils.hpp` for example. src/hotspot/share/services/diagnosticCommand.cpp line 1250: > 1248: } > 1249: > 1250: Suggestion: src/hotspot/share/services/diagnosticCommand.hpp line 862: > 860: static const char* name() { return "JDK.checkpoint"; } > 861: static const char* description() { > 862: return "Checkpoint via jdk.crac.checkpointRestore()."; Not caused by to this PR, but `jdk.crac.checkpointRestore()` is a strange reference. It should just say "Initiates a CRaC checkpoint." probably. test/jdk/jdk/crac/JcmdArgsTest.java line 94: > 92: } > 93: > 94: private static Path createTemp(String metrics, String text) throws IOException { `metrics` should be `name` ------------- PR Review: https://git.openjdk.org/crac/pull/281#pullrequestreview-3604120559 PR Review Comment: https://git.openjdk.org/crac/pull/281#discussion_r2639944216 PR Review Comment: https://git.openjdk.org/crac/pull/281#discussion_r2639951121 PR Review Comment: https://git.openjdk.org/crac/pull/281#discussion_r2639920120 PR Review Comment: https://git.openjdk.org/crac/pull/281#discussion_r2640024276 PR Review Comment: https://git.openjdk.org/crac/pull/281#discussion_r2640059792 PR Review Comment: https://git.openjdk.org/crac/pull/281#discussion_r2640041110 PR Review Comment: https://git.openjdk.org/crac/pull/281#discussion_r2640052385 PR Review Comment: https://git.openjdk.org/crac/pull/281#discussion_r2639986172 PR Review Comment: https://git.openjdk.org/crac/pull/281#discussion_r2640092774 From tpushkin at openjdk.org Mon Dec 22 14:58:05 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 22 Dec 2025 14:58:05 GMT Subject: [crac] RFR: 8373781: [CRaC] Permit -XX:CPUFeatures on other platforms In-Reply-To: References: Message-ID: <_n1jc-oGio4Z5Aoh5-vkSf62L9KPS0ZAPeWdyhSKzQc=.40ce23ee-0b17-4546-81c7-9ebff738ef9f@github.com> On Wed, 17 Dec 2025 10:26:55 GMT, Radim Vansa wrote: > 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. Implementation LGTM, but we have non-x86 machines in CI so it makes sense to add a test for this src/hotspot/share/runtime/abstract_vm_version.cpp line 414: > 412: } > 413: if (!FLAG_IS_DEFAULT(ShowCPUFeatures)) { > 414: tty->print_cr("This architecture does not support any arch-specific strings."); I think the message should indicate that it is about CPU features. Otherwise it is not obvious. Suggestion: tty->print_cr("Showing and controlling CPU features is not supported on this architecture."); src/java.base/share/man/java.md line 1886: > 1884: `-XX:CPUFeatures=`*features* > 1885: : Limit set of CPU features to make the CRaC image compatible for running > 1886: on a machine with different CPU: Nitpicking: "Limit **the** set of CPU features to make the CRaC image compatible for running on a machine with **a** different CPU:" ------------- PR Review: https://git.openjdk.org/crac/pull/282#pullrequestreview-3604360310 PR Review Comment: https://git.openjdk.org/crac/pull/282#discussion_r2640111675 PR Review Comment: https://git.openjdk.org/crac/pull/282#discussion_r2640130178 From tpushkin at openjdk.org Mon Dec 22 14:58:27 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 22 Dec 2025 14:58:27 GMT Subject: [crac] RFR: 8373043: [CRaC] remove CPUFeatures qemu-kvm test In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 17:50:32 GMT, Jan Kratochvil wrote: > 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). Marked as reviewed by tpushkin (Committer). ------------- PR Review: https://git.openjdk.org/crac/pull/280#pullrequestreview-3604388830 From tpushkin at openjdk.org Mon Dec 22 15:02:24 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 22 Dec 2025 15:02:24 GMT Subject: [crac] RFR: 8371549: [CRaC] Implement C/R in Selector on non-Linux [v2] In-Reply-To: References: Message-ID: <8e2EU0eraaKwzZRn2pocGvLS1-KRwMYHep2fIj8pNRc=.dca57698-eabe-485a-959d-22701600d4d8@github.com> On Mon, 1 Dec 2025 08:30:59 GMT, Radim Vansa wrote: >> 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 Sorry, the change is big and I haven't had enough spare time to review it recently. Hopefully will get to it in upcoming weeks, if nobody else will. I believe this is not a priority and does not block anything? ------------- PR Comment: https://git.openjdk.org/crac/pull/276#issuecomment-3682418700 From duke at openjdk.org Mon Dec 22 15:02:55 2025 From: duke at openjdk.org (duke) Date: Mon, 22 Dec 2025 15:02:55 GMT Subject: [crac] RFR: 8373043: [CRaC] remove CPUFeatures qemu-kvm test In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 17:50:32 GMT, Jan Kratochvil wrote: > 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). @jankratochvil Your change (at version a53ac9a53f754e2ba9f98a2172dac36bb64c9bb6) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/crac/pull/280#issuecomment-3682421774 From jkratochvil at openjdk.org Mon Dec 22 15:22:58 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Mon, 22 Dec 2025 15:22:58 GMT Subject: [crac] Integrated: 8373043: [CRaC] remove CPUFeatures qemu-kvm test In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 17:50:32 GMT, Jan Kratochvil wrote: > 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). This pull request has now been integrated. Changeset: 6fa1e418 Author: Jan Kratochvil Committer: Timofei Pushkin URL: https://git.openjdk.org/crac/commit/6fa1e4189dbb60dd0cbed7dc773149db8cab6251 Stats: 429 lines in 2 files changed: 0 ins; 429 del; 0 mod 8373043: [CRaC] remove CPUFeatures qemu-kvm test Reviewed-by: tpushkin ------------- PR: https://git.openjdk.org/crac/pull/280 From rvansa at openjdk.org Mon Dec 22 19:23:30 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Mon, 22 Dec 2025 19:23:30 GMT Subject: [crac] RFR: 8371549: [CRaC] Implement C/R in Selector on non-Linux [v2] In-Reply-To: <8e2EU0eraaKwzZRn2pocGvLS1-KRwMYHep2fIj8pNRc=.dca57698-eabe-485a-959d-22701600d4d8@github.com> References: <8e2EU0eraaKwzZRn2pocGvLS1-KRwMYHep2fIj8pNRc=.dca57698-eabe-485a-959d-22701600d4d8@github.com> Message-ID: <8jt5gGN2j_m1V7YdaZdgG4RWmC_gi9gschjmfaIxKZ8=.11a22931-5ab4-4ea8-98a8-216146dc7fa3@github.com> On Mon, 22 Dec 2025 14:58:56 GMT, Timofei Pushkin wrote: >> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision: >> >> Set FD value on Windows, too > > Sorry, the change is big and I haven't had enough spare time to review it recently. Hopefully will get to it in upcoming weeks, if nobody else will. I believe this is not a priority and does not block anything? @TimPushkin I think we had it pop somewhere but it's not a high priority. Ideally if you can review in early January. ------------- PR Comment: https://git.openjdk.org/crac/pull/276#issuecomment-3683808895 From rvansa at openjdk.org Mon Dec 22 19:27:30 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Mon, 22 Dec 2025 19:27:30 GMT Subject: [crac] RFR: 8373687: [CRaC] Add metrics through jcmd [v5] In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 13:53:26 GMT, Timofei Pushkin wrote: >> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix MacOSX > > src/hotspot/share/runtime/crac.cpp line 726: > >> 724: // silently ignoring this >> 725: return true; >> 726: } > > Not a part of this PR and we should've discussed this earlier, but why don't we fail here? We provide `is_image_score_supported` for Java to check, so we could make `Score.record()` not call this at all in such case. Same for the user-facing code: `Score.setScore` could throw `UnsupportedOperationException` when `Score.isSupported` returns `false`. I would think that most of the time the score calculation is quite cheap, and in that case the code would always look like if (Score.isSupported()) { Score.record(...); } One line is better from code clarity, and one native call is better than two (assuming that it is supported when you're already in the CRaC resource that calls this). ------------- PR Review Comment: https://git.openjdk.org/crac/pull/281#discussion_r2640989970 From rvansa at openjdk.org Mon Dec 22 19:31:33 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Mon, 22 Dec 2025 19:31:33 GMT Subject: [crac] RFR: 8373687: [CRaC] Add metrics through jcmd [v5] In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 14:28:11 GMT, Timofei Pushkin wrote: >> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix MacOSX > > src/hotspot/share/services/diagnosticCommand.cpp line 1092: > >> 1090: const char *metrics = _metrics.value(); >> 1091: if (metrics != nullptr) { >> 1092: LocaleGuard lg; > > What is the problem with locales? Why is this needed for metrics but not labels? The problem I've faced with my (czech) locale is that we use comma `,` for decimal point, rather than `.`. Printing and parsing `double` values was using my locale, then, despite from the info I found JDK should setup the C locale at boottime and use that.... ------------- PR Review Comment: https://git.openjdk.org/crac/pull/281#discussion_r2640999985 From rvansa at openjdk.org Mon Dec 22 20:35:35 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Mon, 22 Dec 2025 20:35:35 GMT Subject: [crac] RFR: 8373687: [CRaC] Add metrics through jcmd [v5] In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 13:51:40 GMT, Timofei Pushkin wrote: >> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix MacOSX > > src/hotspot/share/runtime/crac.cpp line 714: > >> 712: // silently ignoring this >> 713: return true; >> 714: } > > I think we should at least print a warning in such case. I.e. expose a method for the JCMD code to check for support and print the warning to the JCMD stream if there's none. Then here we should fail in such case. > > Same for `record_image_score`. I agree that an explicit command like `jcmd` should print a warning if part of the command line is ignored, but I don't want any warnings the be emitted when using the `Score` methods. And for that I'd like to keep the symmetry with the `record_image_score`. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/281#discussion_r2641161012 From rvansa at openjdk.org Mon Dec 22 21:20:06 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Mon, 22 Dec 2025 21:20:06 GMT Subject: [crac] RFR: 8373687: [CRaC] Add metrics through jcmd [v6] 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: Address review ------------- Changes: - all: https://git.openjdk.org/crac/pull/281/files - new: https://git.openjdk.org/crac/pull/281/files/919393d0..2f595fdd Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=281&range=05 - incr: https://webrevs.openjdk.org/?repo=crac&pr=281&range=04-05 Stats: 100 lines in 7 files changed: 42 ins; 45 del; 13 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 Mon Dec 22 21:20:08 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Mon, 22 Dec 2025 21:20:08 GMT Subject: [crac] RFR: 8373687: [CRaC] Add metrics through jcmd [v5] In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 20:33:12 GMT, Radim Vansa wrote: >> src/hotspot/share/runtime/crac.cpp line 714: >> >>> 712: // silently ignoring this >>> 713: return true; >>> 714: } >> >> I think we should at least print a warning in such case. I.e. expose a method for the JCMD code to check for support and print the warning to the JCMD stream if there's none. Then here we should fail in such case. >> >> Same for `record_image_score`. > > I agree that an explicit command like `jcmd` should print a warning if part of the command line is ignored, but I don't want any warnings the be emitted when using the `Score` methods. And for that I'd like to keep the symmetry with the `record_image_score`. I've added the warning, but there's no simple way to test: all engines support metrics & labels. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/281#discussion_r2641262252 From tpushkin at openjdk.org Tue Dec 23 07:00:33 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 23 Dec 2025 07:00:33 GMT Subject: [crac] RFR: 8373687: [CRaC] Add metrics through jcmd [v5] In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 19:25:14 GMT, Radim Vansa wrote: >> src/hotspot/share/runtime/crac.cpp line 726: >> >>> 724: // silently ignoring this >>> 725: return true; >>> 726: } >> >> Not a part of this PR and we should've discussed this earlier, but why don't we fail here? We provide `is_image_score_supported` for Java to check, so we could make `Score.record()` not call this at all in such case. Same for the user-facing code: `Score.setScore` could throw `UnsupportedOperationException` when `Score.isSupported` returns `false`. > > I would think that most of the time the score calculation is quite cheap, and in that case the code would always look like > > if (Score.isSupported()) { > Score.record(...); > } > > One line is better from code clarity, and one native call is better than two (assuming that it is supported when you're already in the CRaC resource that calls this). I would prefer the explicit checks rather than silent ignoring, but I won't push. Regarding performance, we could cache VM's return value inside `Score.isSupported()` ? it is not supposed to change. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/281#discussion_r2642188701 From tpushkin at openjdk.org Tue Dec 23 07:15:04 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 23 Dec 2025 07:15:04 GMT Subject: [crac] RFR: 8373687: [CRaC] Add metrics through jcmd [v5] In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 19:28:56 GMT, Radim Vansa wrote: >> src/hotspot/share/services/diagnosticCommand.cpp line 1092: >> >>> 1090: const char *metrics = _metrics.value(); >>> 1091: if (metrics != nullptr) { >>> 1092: LocaleGuard lg; >> >> What is the problem with locales? Why is this needed for metrics but not labels? > > The problem I've faced with my (czech) locale is that we use comma `,` for decimal point, rather than `.`. Printing and parsing `double` values was using my locale, then, despite from the info I found JDK should setup the C locale at boottime and use that.... Thanks, a comment here would be nice (I see there's one in `image_score.cpp?` but it won't be trivial to find) ------------- PR Review Comment: https://git.openjdk.org/crac/pull/281#discussion_r2642214680 From tpushkin at openjdk.org Tue Dec 23 07:21:36 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 23 Dec 2025 07:21:36 GMT Subject: [crac] RFR: 8373687: [CRaC] Add metrics through jcmd [v6] In-Reply-To: References: Message-ID: <3V3YIcFxczse38VPSzR-7ez2ypvg5EnEka5QSJyoRRE=.60a33794-fcf9-4939-b60a-3e90fd146cdc@github.com> On Mon, 22 Dec 2025 21:20:06 GMT, Radim Vansa wrote: >> 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: > > Address review Marked as reviewed by tpushkin (Committer). src/hotspot/share/utilities/stringUtils.hpp line 48: > 46: *strp += len + 1; > 47: return str; > 48: } Why not put the implementation in .cpp? src/hotspot/share/utilities/stringUtils.hpp line 50: > 48: } > 49: #endif // _WINDOWS > 50: Redundant newline added ------------- PR Review: https://git.openjdk.org/crac/pull/281#pullrequestreview-3606903419 PR Review Comment: https://git.openjdk.org/crac/pull/281#discussion_r2642227071 PR Review Comment: https://git.openjdk.org/crac/pull/281#discussion_r2642228931 From rvansa at openjdk.org Tue Dec 23 09:18:03 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 23 Dec 2025 09:18:03 GMT Subject: [crac] RFR: 8373687: [CRaC] Add metrics through jcmd [v5] In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 06:57:08 GMT, Timofei Pushkin wrote: >> I would think that most of the time the score calculation is quite cheap, and in that case the code would always look like >> >> if (Score.isSupported()) { >> Score.record(...); >> } >> >> One line is better from code clarity, and one native call is better than two (assuming that it is supported when you're already in the CRaC resource that calls this). > > I would prefer the explicit checks rather than silent ignoring, but I won't push. > > Regarding performance, we could cache VM's return value inside `Score.isSupported()` ? it is not supposed to change. Hmm, in fact `Score.setScore()` which is the 'main' to-be-API will be still silently ignored even if image score is not supported. On checkpoint, we check `isSupported()` anyway, and the default metrics are recorded already past the check, so changing this to return false won't cause any code bloat. Let's return false, then. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/281#discussion_r2642509290 From rvansa at openjdk.org Tue Dec 23 09:47:50 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 23 Dec 2025 09:47:50 GMT Subject: [crac] RFR: 8373687: [CRaC] Add metrics through jcmd [v7] 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: Second round ------------- Changes: - all: https://git.openjdk.org/crac/pull/281/files - new: https://git.openjdk.org/crac/pull/281/files/2f595fdd..85be39e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=281&range=06 - incr: https://webrevs.openjdk.org/?repo=crac&pr=281&range=05-06 Stats: 42 lines in 5 files changed: 20 ins; 17 del; 5 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 23 09:51:31 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 23 Dec 2025 09:51:31 GMT Subject: [crac] RFR: 8373687: [CRaC] Add metrics through jcmd [v7] In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 09:47:50 GMT, Radim Vansa wrote: >> 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: > > Second round One of the things that might need some refinement is naming things 'score' vs. 'metric'. When I speak about score, I mean one final value calculated from the individual metrics. But it can also mean the process of calculating the score (and that's why the `Score` class) - but then I see that the `Score.setScore()` method should be `Score.setMetric()` (this is still not exposed to user code so we have a chance to revise this). ------------- PR Comment: https://git.openjdk.org/crac/pull/281#issuecomment-3685974864 From rvansa at openjdk.org Tue Dec 23 14:47:41 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 23 Dec 2025 14:47:41 GMT Subject: [crac] Integrated: 8373687: [CRaC] Add metrics through jcmd In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 15:29:20 GMT, Radim Vansa wrote: > Enable user adding custom metrics (and labels) through jcmd JDK.checkpoint command, e.g. using > > jcmd JDK.checkpoint metrics=foo=123,bar=0.456 This pull request has now been integrated. Changeset: 15dcf3b6 Author: Radim Vansa URL: https://git.openjdk.org/crac/commit/15dcf3b64e9ee3cb4ce0435c9850126e142fedf6 Stats: 386 lines in 12 files changed: 352 ins; 18 del; 16 mod 8373687: [CRaC] Add metrics through jcmd Reviewed-by: tpushkin ------------- PR: https://git.openjdk.org/crac/pull/281 From rvansa at openjdk.org Tue Dec 23 15:48:48 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 23 Dec 2025 15:48:48 GMT Subject: [crac] RFR: 8373781: [CRaC] Permit -XX:CPUFeatures on other platforms [v2] In-Reply-To: References: 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. Radim Vansa has updated the pull request incrementally with two additional commits since the last revision: - Replace shell-based test with Java test & add other checks - Fix wording ------------- Changes: - all: https://git.openjdk.org/crac/pull/282/files - new: https://git.openjdk.org/crac/pull/282/files/1e92e5ec..2a0aecd1 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=282&range=01 - incr: https://webrevs.openjdk.org/?repo=crac&pr=282&range=00-01 Stats: 172 lines in 4 files changed: 119 ins; 49 del; 4 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 From rvansa at openjdk.org Tue Dec 23 15:48:49 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 23 Dec 2025 15:48:49 GMT Subject: [crac] RFR: 8373781: [CRaC] Permit -XX:CPUFeatures on other platforms In-Reply-To: References: Message-ID: <76cPaWJ0V_ZcMARwskcN8YlHmI7atPcIZ8_Nt0FjF_E=.b18e33ed-314b-4f1a-b689-34f2c8b6c045@github.com> On Wed, 17 Dec 2025 10:26:55 GMT, Radim Vansa wrote: > 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. I've replaced the shell-based CPUFeatures test, and added test cases. ------------- PR Comment: https://git.openjdk.org/crac/pull/282#issuecomment-3687086644 From rvansa at openjdk.org Tue Dec 23 16:55:32 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 23 Dec 2025 16:55:32 GMT Subject: [crac] RFR: 8373781: [CRaC] Permit -XX:CPUFeatures on other platforms [v3] In-Reply-To: References: 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. Radim Vansa has updated the pull request incrementally with one additional commit since the last revision: Fix CPUFeatures check ------------- Changes: - all: https://git.openjdk.org/crac/pull/282/files - new: https://git.openjdk.org/crac/pull/282/files/2a0aecd1..a58eee1e Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=282&range=02 - incr: https://webrevs.openjdk.org/?repo=crac&pr=282&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 From rvansa at openjdk.org Tue Dec 23 17:05:09 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 23 Dec 2025 17:05:09 GMT Subject: [crac] RFR: 8373781: [CRaC] Permit -XX:CPUFeatures on other platforms [v4] In-Reply-To: References: 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. Radim Vansa has updated the pull request incrementally with one additional commit since the last revision: Refine non-Linux behaviour ------------- Changes: - all: https://git.openjdk.org/crac/pull/282/files - new: https://git.openjdk.org/crac/pull/282/files/a58eee1e..e4849639 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=282&range=03 - incr: https://webrevs.openjdk.org/?repo=crac&pr=282&range=02-03 Stats: 12 lines in 1 file changed: 9 ins; 0 del; 3 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