From mz1999 at gmail.com Mon Sep 15 09:29:03 2025 From: mz1999 at gmail.com (ma zhen) Date: Mon, 15 Sep 2025 17:29:03 +0800 Subject: Inquiry: Handling Unix sockets created by glibc/NSS during checkpoint Message-ID: Hi CRaC developers, I am currently working on adapting a Java application to support CRaC. I've encountered a specific challenge related to a Unix socket that is preventing successful checkpoint creation. During the checkpoint process, I consistently receive a CheckpointOpenSocketException for a specific file descriptor, which lsof identifies as a Unix socket. I have conducted a detailed investigation to trace the origin of this socket and found that it is not created directly by my Java application code. Instead, it is created by the underlying glibc library as part of the Name Service Switch (NSS) framework. The call stack, captured using BCC, clearly shows that the socket() call originates from glibc's __nscd_* functions. This happens when the JVM or application triggers a name service lookup (e.g., resolving a user ID). In my specific environment, this results in a Unix socket connection from the Java process to the lwsmd daemon for authentication. Because this socket is created and managed within the native C library, the standard approach of implementing a Java-level org.crac.Resource to close and restore it doesn't seem applicable, as my application code has no direct handle or control over its lifecycle. I have documented the full analysis, including the error, lsof output, and BCC stack traces, in a detailed write-up which you can find here: https://github.com/mz1999/blog/blob/master/docs/trace_java_socket_creation-en.md My question is: What is the recommended approach for handling such file descriptors that are opened by underlying native libraries without direct control from the Java application? Are there any existing mechanisms, perhaps through advanced file descriptor policies, or any planned features that might address this common scenario? Or is there another workaround that the team would suggest? Thank you for your time and for developing this fantastic project. Any guidance you can provide would be greatly appreciated. Best regards, mazhen -------------- next part -------------- An HTML attachment was scrubbed... URL: From rvansa at azul.com Mon Sep 15 15:12:08 2025 From: rvansa at azul.com (Radim Vansa) Date: Mon, 15 Sep 2025 17:12:08 +0200 Subject: Inquiry: Handling Unix sockets created by glibc/NSS during checkpoint In-Reply-To: References: Message-ID: <40425d19-68cc-4a80-8976-1b8937ca2a2d@azul.com> Hi Ma Zhen, we are aware of similar issue where an application has `/var/cache/nscd/passwd` mapped despite not having the priviledge to open() this file - the application can receive a file descriptor through a socket and then is able to mmap it. Another case are files under `/var/lib/sss/mc/` opened by getpwuid_r, getpwname_r, getgrgid_r, getgrname_r or similar functions. You're right that File Descriptor Policies cannot be applied here, these work on a Java level (the FD must have an associated Java object). There is a VM option `-XX:CRaCAllowedOpenFilePrefixes` that lets the checkpoint to proceed if a file from this path is opened; in most cases CRIU can reopen a regular file without issues (and it should be able to handle sockets as well). I have not tested if the path matching works with sockets, but shouldn't be too difficult to fix up for Unix sockets. Besides this there's no Resource-handling on native level (you cannot register a native hook), though it might be possible to find an open FD and close it from Java - I wouldn't recommend such hacky way. To be honest on systems where we've encountered this issue we rather disabled NSCD service completely. If you can't control the environment, you can run the application in a container that won't be configured with these services. Cheers, Radim On 9/15/25 11:29, ma zhen wrote: > > Hi CRaC developers, > > I am currently working on adapting a Java application to support CRaC. > I've encountered a specific challenge related to a Unix socket that is > preventing successful checkpoint creation. > > During the checkpoint process, I consistently receive a > CheckpointOpenSocketException for a specific file descriptor, which > lsof identifies as a Unix socket. > > I have conducted a detailed investigation to trace the origin of this > socket and found that it is not created directly by my Java > application code. Instead, it is created by the underlying glibc > library as part of the Name Service Switch (NSS) framework. The call > stack, captured using BCC, clearly shows that the socket() call > originates from glibc's __nscd_* functions. This happens when the JVM > or application triggers a name service lookup (e.g., resolving a user > ID). In my specific environment, this results in a Unix socket > connection from the Java process to the lwsmd daemon for authentication. > > Because this socket is created and managed within the native C > library, the standard approach of implementing a Java-level > org.crac.Resource to close and restore it doesn't seem applicable, as > my application code has no direct handle or control over its lifecycle. > > I have documented the full analysis, including the error, lsof output, > and BCC stack traces, in a detailed write-up which you can find here: > https://github.com/mz1999/blog/blob/master/docs/trace_java_socket_creation-en.md > > My question is: What is the recommended approach for handling such > file descriptors that are opened by underlying native libraries > without direct control from the Java application? > > Are there any existing mechanisms, perhaps through advanced file > descriptor policies, or any planned features that might address this > common scenario? Or is there another workaround that the team would > suggest? > > Thank you for your time and for developing this fantastic project. Any > guidance you can provide would be greatly appreciated. > > Best regards, > mazhen From mz1999 at gmail.com Tue Sep 16 09:42:02 2025 From: mz1999 at gmail.com (ma zhen) Date: Tue, 16 Sep 2025 17:42:02 +0800 Subject: Inquiry: Handling Unix sockets created by glibc/NSS during checkpoint In-Reply-To: <40425d19-68cc-4a80-8976-1b8937ca2a2d@azul.com> References: <40425d19-68cc-4a80-8976-1b8937ca2a2d@azul.com> Message-ID: Hi Radim, Thank you so much for the detailed and insightful response. I followed your advice and set the parameter `-XX:CRaCAllowedOpenFilePrefixes=socket:`. This successfully bypassed CRaC's own validation check, and the log confirmed this with the following message: `JVM: FD fd=4 type=socket path="socket:[11012921],port=29295" OK: allowed in -XX:CRaCAllowedOpenFilePrefixes` However, this then revealed an underlying issue, seemingly within CRIU. During the dump process, CRIU first reported: `Error (criu/sk-unix.c:865): unix: External socket is used. Consider using --ext-unix-sk option.` Following CRIU's advice, I passed this option using the `CRAC_CRIU_OPTS` environment variable (`CRAC_CRIU_OPTS="--ext-unix-sk"`). Unfortunately, this led to a different error from CRIU: `Error (criu/sk-unix.c:871): unix: Can't dump half of stream unix connection.` My initial interpretation of this final error is that CRIU may have a limitation in handling a process that holds only one end of an external, stream-oriented (`SOCK_STREAM`) Unix socket connection. However, I'm not entirely certain about this, and I plan to look into CRIU's documentation and code to confirm this behavior. In the meantime, I was wondering if this aligns with your experience? Perhaps you've encountered this specific CRIU error before. This experience certainly reinforces your other recommendation of running the application in a minimal container to avoid creating the socket in the first place. It seems like the most reliable path forward for now. Thank you again for your guidance. It's been extremely valuable. Best regards, mazhen Radim Vansa ?2025?9?15??? 23:12??? > Hi Ma Zhen, > > we are aware of similar issue where an application has > `/var/cache/nscd/passwd` mapped despite not having the priviledge to > open() this file - the application can receive a file descriptor through > a socket and then is able to mmap it. Another case are files under > `/var/lib/sss/mc/` opened by getpwuid_r, getpwname_r, getgrgid_r, > getgrname_r or similar functions. > > You're right that File Descriptor Policies cannot be applied here, these > work on a Java level (the FD must have an associated Java object). > > There is a VM option `-XX:CRaCAllowedOpenFilePrefixes` that lets the > checkpoint to proceed if a file from this path is opened; in most cases > CRIU can reopen a regular file without issues (and it should be able to > handle sockets as well). I have not tested if the path matching works > with sockets, but shouldn't be too difficult to fix up for Unix sockets. > > Besides this there's no Resource-handling on native level (you cannot > register a native hook), though it might be possible to find an open FD > and close it from Java - I wouldn't recommend such hacky way. > > To be honest on systems where we've encountered this issue we rather > disabled NSCD service completely. If you can't control the environment, > you can run the application in a container that won't be configured with > these services. > > Cheers, > > Radim > > On 9/15/25 11:29, ma zhen wrote: > > > > Hi CRaC developers, > > > > I am currently working on adapting a Java application to support CRaC. > > I've encountered a specific challenge related to a Unix socket that is > > preventing successful checkpoint creation. > > > > During the checkpoint process, I consistently receive a > > CheckpointOpenSocketException for a specific file descriptor, which > > lsof identifies as a Unix socket. > > > > I have conducted a detailed investigation to trace the origin of this > > socket and found that it is not created directly by my Java > > application code. Instead, it is created by the underlying glibc > > library as part of the Name Service Switch (NSS) framework. The call > > stack, captured using BCC, clearly shows that the socket() call > > originates from glibc's __nscd_* functions. This happens when the JVM > > or application triggers a name service lookup (e.g., resolving a user > > ID). In my specific environment, this results in a Unix socket > > connection from the Java process to the lwsmd daemon for authentication. > > > > Because this socket is created and managed within the native C > > library, the standard approach of implementing a Java-level > > org.crac.Resource to close and restore it doesn't seem applicable, as > > my application code has no direct handle or control over its lifecycle. > > > > I have documented the full analysis, including the error, lsof output, > > and BCC stack traces, in a detailed write-up which you can find here: > > > https://github.com/mz1999/blog/blob/master/docs/trace_java_socket_creation-en.md > > > > My question is: What is the recommended approach for handling such > > file descriptors that are opened by underlying native libraries > > without direct control from the Java application? > > > > Are there any existing mechanisms, perhaps through advanced file > > descriptor policies, or any planned features that might address this > > common scenario? Or is there another workaround that the team would > > suggest? > > > > Thank you for your time and for developing this fantastic project. Any > > guidance you can provide would be greatly appreciated. > > > > Best regards, > > mazhen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rvansa at azul.com Tue Sep 16 14:48:54 2025 From: rvansa at azul.com (Radim Vansa) Date: Tue, 16 Sep 2025 16:48:54 +0200 Subject: Inquiry: Handling Unix sockets created by glibc/NSS during checkpoint In-Reply-To: References: <40425d19-68cc-4a80-8976-1b8937ca2a2d@azul.com> Message-ID: <8c72e932-a929-4121-850a-437f491814b8@azul.com> Hi Ma Zhen, I have to admit that I mistook sockets for named pipes when I was thinking about this the first time. The problem seems to be mentioned in CRIU docs [1]. Since you describe a connection to daemon (not a named unix socket) I guess there would be a path forward if the socket is idle & stateless: open another connection to the daemon and inherit this (note that you would have to use `-XX:CRaCIgnoredFileDescriptors` to prevent automatically closed inherited FDs). However, while a technical solution might exist, this is really not up to CRaC philosophy. The process *should* isolate itself from the rest of the system; from CRaC POV the inability to do that in glibc is a deficiency (if there was API for that the native part of CRaC in JVM would call it). It might be possible to lookup & call `__nss_disable_nscd` early on during boot, but given that this is not a public API I don't think this belongs to the general JVM code. The application has cooperate with CRaC a bit. Hopefully it is a reasonable requirement to deploy in an environment that does not inject FDs to the application like NSCD does. Googling around it doesn't seem to have the best reputation. In these cases, I would love to provide more guidance in the first error the user gets, but IIUC this socket is not easy to classify as NSCD socket without tracing its origin. I am glad that the containerized solution works for you. Radim [1] https://criu.org/External_UNIX_socket On 9/16/25 11:42, ma zhen wrote: > > Hi Radim, > > Thank you so much for the detailed and insightful response. > > I followed your advice and set the parameter > `-XX:CRaCAllowedOpenFilePrefixes=socket:`. This successfully bypassed > CRaC's own validation check, and the log confirmed this with the > following message: > > `JVM: FD fd=4 type=socket path="socket:[11012921],port=29295" OK: > allowed in -XX:CRaCAllowedOpenFilePrefixes` > > However, this then revealed an underlying issue, seemingly within > CRIU. During the dump process, CRIU first reported: > > `Error (criu/sk-unix.c:865): unix: External socket is used. Consider > using --ext-unix-sk option.` > > Following CRIU's advice, I passed this option using the > `CRAC_CRIU_OPTS` environment variable > (`CRAC_CRIU_OPTS="--ext-unix-sk"`). Unfortunately, this led to a > different error from CRIU: > > `Error (criu/sk-unix.c:871): unix: Can't dump half of stream unix > connection.` > > My initial interpretation of this final error is that CRIU may have a > limitation in handling a process that holds only one end of an > external, stream-oriented (`SOCK_STREAM`) Unix socket connection. > However, I'm not entirely certain about this, and I plan to look into > CRIU's documentation and code to confirm this behavior. > > In the meantime, I was wondering if this aligns with your experience? > Perhaps you've encountered this specific CRIU error before. > > This experience certainly reinforces your other recommendation of > running the application in a minimal container to avoid creating the > socket in the first place. It seems like the most reliable path > forward for now. > > Thank you again for your guidance. It's been extremely valuable. > > Best regards, > > mazhen > > Radim Vansa ?2025?9?15??? 23:12??? > > Hi Ma Zhen, > > we are aware of similar issue where an application has > `/var/cache/nscd/passwd` mapped despite not having the priviledge to > open() this file - the application can receive a file descriptor > through > a socket and then is able to mmap it. Another case are files under > `/var/lib/sss/mc/` opened by getpwuid_r, getpwname_r, getgrgid_r, > getgrname_r or similar functions. > > You're right that File Descriptor Policies cannot be applied here, > these > work on a Java level (the FD must have an associated Java object). > > There is a VM option `-XX:CRaCAllowedOpenFilePrefixes` that lets the > checkpoint to proceed if a file from this path is opened; in most > cases > CRIU can reopen a regular file without issues (and it should be > able to > handle sockets as well). I have not tested if the path matching works > with sockets, but shouldn't be too difficult to fix up for Unix > sockets. > > Besides this there's no Resource-handling on native level (you cannot > register a native hook), though it might be possible to find an > open FD > and close it from Java - I wouldn't recommend such hacky way. > > To be honest on systems where we've encountered this issue we rather > disabled NSCD service completely. If you can't control the > environment, > you can run the application in a container that won't be > configured with > these services. > > Cheers, > > Radim > > On 9/15/25 11:29, ma zhen wrote: > > > > Hi CRaC developers, > > > > I am currently working on adapting a Java application to support > CRaC. > > I've encountered a specific challenge related to a Unix socket > that is > > preventing successful checkpoint creation. > > > > During the checkpoint process, I consistently receive a > > CheckpointOpenSocketException for a specific file descriptor, which > > lsof identifies as a Unix socket. > > > > I have conducted a detailed investigation to trace the origin of > this > > socket and found that it is not created directly by my Java > > application code. Instead, it is created by the underlying glibc > > library as part of the Name Service Switch (NSS) framework. The > call > > stack, captured using BCC, clearly shows that the socket() call > > originates from glibc's __nscd_* functions. This happens when > the JVM > > or application triggers a name service lookup (e.g., resolving a > user > > ID). In my specific environment, this results in a Unix socket > > connection from the Java process to the lwsmd daemon for > authentication. > > > > Because this socket is created and managed within the native C > > library, the standard approach of implementing a Java-level > > org.crac.Resource to close and restore it doesn't seem > applicable, as > > my application code has no direct handle or control over its > lifecycle. > > > > I have documented the full analysis, including the error, lsof > output, > > and BCC stack traces, in a detailed write-up which you can find > here: > > > https://github.com/mz1999/blog/blob/master/docs/trace_java_socket_creation-en.md > > > > My question is: What is the recommended approach for handling such > > file descriptors that are opened by underlying native libraries > > without direct control from the Java application? > > > > Are there any existing mechanisms, perhaps through advanced file > > descriptor policies, or any planned features that might address > this > > common scenario? Or is there another workaround that the team would > > suggest? > > > > Thank you for your time and for developing this fantastic > project. Any > > guidance you can provide would be greatly appreciated. > > > > Best regards, > > mazhen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Thu Sep 18 09:21:56 2025 From: duke at openjdk.org (duke) Date: Thu, 18 Sep 2025 09:21:56 GMT Subject: git: openjdk/crac: created branch 8367975_checkpoint_pattern based on the branch crac containing 1 unique commit Message-ID: <6a75b946-1e67-4ebe-a7d8-5f4eceb0ae11@openjdk.org> The following commits are unique to the 8367975_checkpoint_pattern branch: ======================================================== 7c23d813: 8367975: Pattern in CRaCCheckpointTo From rvansa at openjdk.org Thu Sep 18 09:29:27 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Thu, 18 Sep 2025 09:29:27 GMT Subject: [crac] RFR: 8367975: Pattern in CRaCCheckpointTo Message-ID: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com> Add support for pattern in `CRaCCheckpointTo` VM option. ------------- Commit messages: - 8367975: Pattern in CRaCCheckpointTo Changes: https://git.openjdk.org/crac/pull/264/files Webrev: https://webrevs.openjdk.org/?repo=crac&pr=264&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367975 Stats: 441 lines in 7 files changed: 398 ins; 28 del; 15 mod Patch: https://git.openjdk.org/crac/pull/264.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/264/head:pull/264 PR: https://git.openjdk.org/crac/pull/264 From tpushkin at openjdk.org Tue Sep 23 10:08:47 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 23 Sep 2025 10:08:47 GMT Subject: [crac] RFR: 8367975: [CRaC] Pattern in CRaCCheckpointTo In-Reply-To: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com> References: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com> Message-ID: On Thu, 18 Sep 2025 09:22:03 GMT, Radim Vansa wrote: > Add support for pattern in `CRaCCheckpointTo` VM option. The patterns should be documented in `java.md` and maybe mentioned in `globals.hpp`. Also since the patterns are handled in shared code it would make sense to have OS pattern too. src/hotspot/cpu/x86/vm_version_x86.hpp line 615: > 613: } > 614: > 615: int print_numbers_hexonly(char *buf_orig, size_t buflen) const { Can be merged into `print_numbers` with a parameter like `bool hex_only` (false by default, true where this was used), but I don't insist src/hotspot/share/runtime/crac.cpp line 107: > 105: if (iso8601) { > 106: if (width >= 0 || zero_pad) { > 107: log_warning(crac)("CRaCCheckpointTo=%s cannot set zero_pad or width for ISO-8601 time", CRaCCheckpointTo); `zero_pad` is a name of a variable not known to the user. Suggestion: log_warning(crac)("CRaCCheckpointTo=%s cannot zero-pad or set width for ISO-8601 time", CRaCCheckpointTo); I would also write "Cannot in CRaCCheckpointTo=%s" here and in other similar places below but that is a personal preference. src/hotspot/share/runtime/crac.cpp line 112: > 110: time_t time = timeMillis / 1000; > 111: struct tm tms; > 112: if (gmtime_r(&time, &tms) == NULL) { There is `os::gmtime_pd` which is `gmtime_r` on POSIX and `gmtime` on Windows. Not sure why it exists but I would suggest to use it just in case. src/hotspot/share/runtime/crac.cpp line 112: > 110: time_t time = timeMillis / 1000; > 111: struct tm tms; > 112: if (gmtime_r(&time, &tms) == NULL) { Suggestion: if (gmtime_r(&time, &tms) == nullptr) { src/hotspot/share/runtime/crac.cpp line 129: > 127: return snprintf(buf, buflen, "%*zu", width, size); > 128: } else { > 129: const char *suffixes[] = { "k", "M", "G" }; I believe without `static` this is put on stack Suggestion: static constexpr const char *suffixes[] = { "k", "M", "G" }; src/hotspot/share/runtime/crac.cpp line 139: > 137: } > 138: > 139: #define check_no_width() do { \ Suggestion: // Also implies no zero-padding #define check_no_width() do { \ src/hotspot/share/runtime/crac.cpp line 148: > 146: int ret = statement; \ > 147: if (ret < 0 || (size_t) ret > buflen) { \ > 148: log_error(crac)("Error interpolating CRaCCheckpointTo=%s (@%zu, buffer size %zu)", CRaCCheckpointTo, si, buflen); \ To me it is not completely obvious what @ means here, if it is the position in the interpreted string then I would prefer "position"/"location" src/hotspot/share/runtime/crac.cpp line 155: > 153: } while (false) > 154: > 155: bool crac::resolve_image_location(char *buf, size_t buflen, bool *fixed) { I expect "resolve" to access the filesystem somehow. Also it is only meant for the checkpoint location. So how about `interpolate_checkpoint_image_location`? src/hotspot/share/runtime/crac.cpp line 155: > 153: } while (false) > 154: > 155: bool crac::resolve_image_location(char *buf, size_t buflen, bool *fixed) { `buflen` is not checked when we write to the buffer directly, not via stdlib functions src/hotspot/share/runtime/crac.cpp line 159: > 157: for (size_t si = 0; ; si++) { > 158: char c = CRaCCheckpointTo[si]; > 159: if (c == '%') { I would suggest handling the simple case first with continue to reduce the nesting: if (c != '%') { *(buf++) = c; --buflen; if (c == '\0') { break; } else { continue; } } // handle % with reduce nesting src/hotspot/share/runtime/crac.cpp line 168: > 166: } > 167: size_t width_start = si; > 168: while (CRaCCheckpointTo[si] >= '1' && CRaCCheckpointTo[si] <= '9') { Since 0 is not allowed, I believe currently it is not possible to specify width 10, for example? src/hotspot/share/runtime/crac.cpp line 177: > 175: } else if (si > width_start) { > 176: width = atoi(&CRaCCheckpointTo[width_start]); > 177: } Since width is not set in the first case: Suggestion: if (zero_pad && width_start == si) { log_error(crac)("CRaCCheckpointTo=%s contains a pattern with zero padding but no length", CRaCCheckpointTo); return false; } const int width = si > width_start ? atoi(&CRaCCheckpointTo[width_start]) : -1; src/hotspot/share/runtime/crac.cpp line 188: > 186: check_no_width(); > 187: #ifndef ARCHPROPNAME // defined by build scripts > 188: # define ARCHPROPNAME "unknown" Why not assert it is defined? Suggestion: #error ARCHPROPNAME macro must be defined src/hotspot/share/runtime/crac.cpp line 192: > 190: check_retval(snprintf(buf, buflen, "%s", ARCHPROPNAME)); > 191: break; > 192: case 'f': { // CPU features Should check no width/padding src/hotspot/share/runtime/crac.cpp line 198: > 196: buf += ret; > 197: buflen -= ret; > 198: } // otherwise just empty string I think we should print a warning otherwise src/hotspot/share/runtime/crac.cpp line 203: > 201: case 'u': { // Random UUID (v4) > 202: check_no_width(); > 203: *fixed = false; // FIXME? Looks correct to me, what would you want to fix? src/hotspot/share/runtime/crac.cpp line 208: > 206: check_retval(snprintf(buf, buflen, "%08x-%04x-4%03x-a%03x-%04x%08x", > 207: static_cast(os::random()), time_mid_high >> 16, time_mid_high & 0xFFF, > 208: seq_and_node_low & 0xFFF, seq_and_node_low >> 16, static_cast(os::random()))); Not that it matters much, but I believe the 4th part does not always have to start with "a" according to the spec Suggestion: check_retval(snprintf(buf, buflen, "%08x-%04x-4%03x-%04x-%04x%08x", static_cast(os::random()), time_mid_high >> 16, time_mid_high & 0xFFF, (seq_and_node_low & 0x3FFF | 0x8000), seq_and_node_low >> 16, static_cast(os::random()))); src/hotspot/share/runtime/crac.cpp line 225: > 223: check_retval(append_time(buf, buflen, c == 'r', zero_pad, width, > 224: os::javaTimeMillis() - 1000 * (os::elapsed_counter_since_restore() / os::elapsed_frequency()))); > 225: break; Shouldn't we use the native implementations of `RuntimeMXBean.getStartTime()` and `CRaCMXBean.getRestoreTime()` respectively? I think it is reasonable to expect these to be consistent. But if there are reasons not to do that it is ok with me to leave this as is, we just won't document them to be consistent in such case. src/hotspot/share/runtime/crac.cpp line 257: > 255: #undef check_retval > 256: > 257: static bool ensure_image_location(const char *path, bool rm) { Since this is checkpoint-specific: Suggestion: static bool ensure_checkpoint_image_location(const char *path, bool rm) { Or maybe make it also handle the restore case have this in one place. src/hotspot/share/runtime/crac.cpp line 294: > 292: if (!_engine->configure_image_location(image_location)) { > 293: return JVM_CHECKPOINT_ERROR; > 294: } Is there a reason we do this and CPU features recording below so late instead of at the beginning `crac::checkpoint`, for example? The only reason I see is that the timestamps in `crac::record_time_before_checkpoint` and `%t` would be further away in that case (BTW, if we leave this as is we could use the recorded time for the pattern for consistency). If we did not clear the recorded user data on checkpoint, CPU features could be recorded just once on VM initialization instead of on every checkpoint (though not in `prepare_checkpoint` ? that is too early, I believe). And just to have it more compact since the calls are very closely related Suggestion: // Note that CRaCEngine and CRaCEngineOptions are not updated (as documented) // so we don't need to re-init the whole engine handle. if (!resolve_image_location(image_location, sizeof(image_location), &ignored) || !ensure_image_location(image_location, false) || !_engine->configure_image_location(image_location)) { return JVM_CHECKPOINT_ERROR; } src/hotspot/share/runtime/crac_engine.hpp line 42: > 40: class CracEngine : public CHeapObj { > 41: public: > 42: explicit CracEngine(); `explicit` is not needed now. It was there to adhere to https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rc-explicit. test/jdk/jdk/crac/PathPatternTest.java line 78: > 76: long pid = runCheckpoints("foo/cr_%%_%a_%p_%05c_%3m_%m_%g", false); > 77: File f = new File(String.format("foo/cr_%%_%s_%d_%05d_%d_1G_1", > 78: Platform.getOsArch(), pid, Runtime.getRuntime().availableProcessors(), 1024 * 1024 * 1024)); FYI there's `jdk.test.lib.Unit.G` which has `size == 1024 * 1024 * 1024`, and there's other common units test/jdk/jdk/crac/PathPatternTest.java line 79: > 77: File f = new File(String.format("foo/cr_%%_%s_%d_%05d_%d_1G_1", > 78: Platform.getOsArch(), pid, Runtime.getRuntime().availableProcessors(), 1024 * 1024 * 1024)); > 79: assertTrue(f.exists(), "Expect" + f); Suggestion: assertTrue(f.exists(), "Expect " + f); test/jdk/jdk/crac/PathPatternTest.java line 144: > 142: } > 143: > 144: private static void deleteDir(String dir) throws IOException { `clearDir` would fit better. Also it would be simpler to use `jdk.test.lib.util.FileUtils.deleteFileTreeWithRetry(Path)` and re-create the directory itself. test/jdk/jdk/crac/PathPatternTest.java line 170: > 168: > 169: > 170: } Suggestion: } } ------------- PR Review: https://git.openjdk.org/crac/pull/264#pullrequestreview-3252522721 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2368185546 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2368563445 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2368381612 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2368382210 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2368494050 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2371467010 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2368611060 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2368636997 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2368724681 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2368709528 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2368833005 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2368769679 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2368871268 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2368888060 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2368883542 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2371543305 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2371537367 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2371599384 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2371634172 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2371661130 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2368240041 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2371769977 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2371772080 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2371776032 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2371797448 From rvansa at openjdk.org Tue Sep 23 12:24:36 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 23 Sep 2025 12:24:36 GMT Subject: [crac] RFR: 8367975: [CRaC] Pattern in CRaCCheckpointTo In-Reply-To: References: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com> Message-ID: On Mon, 22 Sep 2025 14:59:55 GMT, Timofei Pushkin wrote: >> Add support for pattern in `CRaCCheckpointTo` VM option. > > src/hotspot/share/runtime/crac.cpp line 188: > >> 186: check_no_width(); >> 187: #ifndef ARCHPROPNAME // defined by build scripts >> 188: # define ARCHPROPNAME "unknown" > > Why not assert it is defined? > Suggestion: > > #error ARCHPROPNAME macro must be defined I had the `define` here mostly to avoid IDE errors, but OK... ------------- PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2372139319 From rvansa at openjdk.org Tue Sep 23 12:29:50 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 23 Sep 2025 12:29:50 GMT Subject: [crac] RFR: 8367975: [CRaC] Pattern in CRaCCheckpointTo In-Reply-To: References: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com> Message-ID: On Mon, 22 Sep 2025 15:02:24 GMT, Timofei Pushkin wrote: >> Add support for pattern in `CRaCCheckpointTo` VM option. > > src/hotspot/share/runtime/crac.cpp line 198: > >> 196: buf += ret; >> 197: buflen -= ret; >> 198: } // otherwise just empty string > > I think we should print a warning otherwise I don't think so; `cpu_features_binary` will return false on `aarch64`, and I don't think the user has to use different patterns to checkpoint on different architectures. > src/hotspot/share/runtime/crac.cpp line 203: > >> 201: case 'u': { // Random UUID (v4) >> 202: check_no_width(); >> 203: *fixed = false; // FIXME? > > Looks correct to me, what would you want to fix? The UUID could be generated once on the first pattern interpolation. Probably needs to be reset on restore, then, to keep the semantic (UUID should change on each checkpoint - that shall be documented, too). ------------- PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2372146904 PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2372154917 From tpushkin at openjdk.org Tue Sep 23 12:34:15 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 23 Sep 2025 12:34:15 GMT Subject: [crac] RFR: 8367975: [CRaC] Pattern in CRaCCheckpointTo In-Reply-To: References: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com> Message-ID: <3SYaX2l2tRU1Up0b0F1Xxyyq8MT_DLbhXae44H0GemA=.4b81964a-7c84-43da-a49b-f1703c42116f@github.com> On Tue, 23 Sep 2025 12:24:43 GMT, Radim Vansa wrote: >> src/hotspot/share/runtime/crac.cpp line 198: >> >>> 196: buf += ret; >>> 197: buflen -= ret; >>> 198: } // otherwise just empty string >> >> I think we should print a warning otherwise > > I don't think so; `cpu_features_binary` will return false on `aarch64`, and I don't think the user has to use different patterns to checkpoint on different architectures. >From the other hand, it can be confusing to get absolutely nothing in the place of this pattern. But if we explicitly document that this is possible, I am OK with leaving it as is. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2372166780 From rvansa at openjdk.org Tue Sep 23 12:34:17 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 23 Sep 2025 12:34:17 GMT Subject: [crac] RFR: 8367975: [CRaC] Pattern in CRaCCheckpointTo In-Reply-To: References: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com> Message-ID: On Tue, 23 Sep 2025 08:17:06 GMT, Timofei Pushkin wrote: >> Add support for pattern in `CRaCCheckpointTo` VM option. > > src/hotspot/share/runtime/crac.cpp line 208: > >> 206: check_retval(snprintf(buf, buflen, "%08x-%04x-4%03x-a%03x-%04x%08x", >> 207: static_cast(os::random()), time_mid_high >> 16, time_mid_high & 0xFFF, >> 208: seq_and_node_low & 0xFFF, seq_and_node_low >> 16, static_cast(os::random()))); > > Not that it matters much, but I believe the 4th part does not always have to start with "a" according to the spec > > Suggestion: > > check_retval(snprintf(buf, buflen, "%08x-%04x-4%03x-%04x-%04x%08x", > static_cast(os::random()), time_mid_high >> 16, time_mid_high & 0xFFF, > (seq_and_node_low & 0x3FFF | 0x8000), seq_and_node_low >> 16, static_cast(os::random()))); We're using RFC 4122 variant, with Msb0 = 1 and Msb1 = 0: https://datatracker.ietf.org/doc/html/rfc4122#section-4.1.1 ------------- PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2372162682 From tpushkin at openjdk.org Tue Sep 23 12:42:56 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 23 Sep 2025 12:42:56 GMT Subject: [crac] RFR: 8367975: [CRaC] Pattern in CRaCCheckpointTo In-Reply-To: References: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com> Message-ID: On Tue, 23 Sep 2025 12:30:01 GMT, Radim Vansa wrote: >> src/hotspot/share/runtime/crac.cpp line 208: >> >>> 206: check_retval(snprintf(buf, buflen, "%08x-%04x-4%03x-a%03x-%04x%08x", >>> 207: static_cast(os::random()), time_mid_high >> 16, time_mid_high & 0xFFF, >>> 208: seq_and_node_low & 0xFFF, seq_and_node_low >> 16, static_cast(os::random()))); >> >> Not that it matters much, but I believe the 4th part does not always have to start with "a" according to the spec >> >> Suggestion: >> >> check_retval(snprintf(buf, buflen, "%08x-%04x-4%03x-%04x-%04x%08x", >> static_cast(os::random()), time_mid_high >> 16, time_mid_high & 0xFFF, >> (seq_and_node_low & 0x3FFF | 0x8000), seq_and_node_low >> 16, static_cast(os::random()))); > > We're using RFC 4122 variant, with Msb0 = 1 and Msb1 = 0: https://datatracker.ietf.org/doc/html/rfc4122#section-4.1.1 Yes, and IIUC it fixes only two bits, allowing the other two to change: 1000 = 8, 1001 = 9, 1010 = a, 1011 = b. Or am I reading it wrong? ------------- PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2372182155 From rvansa at openjdk.org Tue Sep 23 12:42:58 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 23 Sep 2025 12:42:58 GMT Subject: [crac] RFR: 8367975: [CRaC] Pattern in CRaCCheckpointTo In-Reply-To: References: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com> Message-ID: On Tue, 23 Sep 2025 08:58:01 GMT, Timofei Pushkin wrote: >> Add support for pattern in `CRaCCheckpointTo` VM option. > > src/hotspot/share/runtime/crac.cpp line 257: > >> 255: #undef check_retval >> 256: >> 257: static bool ensure_image_location(const char *path, bool rm) { > > Since this is checkpoint-specific: > Suggestion: > > static bool ensure_checkpoint_image_location(const char *path, bool rm) { > > > Or maybe make it also handle the restore case have this in one place. I don't follow the second part - restore should not attempt to create the directory. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2372187587 From rvansa at openjdk.org Tue Sep 23 12:49:42 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 23 Sep 2025 12:49:42 GMT Subject: [crac] RFR: 8367975: [CRaC] Pattern in CRaCCheckpointTo In-Reply-To: References: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com> Message-ID: On Tue, 23 Sep 2025 09:09:23 GMT, Timofei Pushkin wrote: >> Add support for pattern in `CRaCCheckpointTo` VM option. > > src/hotspot/share/runtime/crac.cpp line 294: > >> 292: if (!_engine->configure_image_location(image_location)) { >> 293: return JVM_CHECKPOINT_ERROR; >> 294: } > > Is there a reason we do this and CPU features recording below so late instead of at the beginning `crac::checkpoint`, for example? The only reason I see is that the timestamps in `crac::record_time_before_checkpoint` and `%t` would be further away in that case (BTW, if we leave this as is we could use the recorded time for the pattern for consistency). > > If we did not clear the recorded user data on checkpoint, CPU features could be recorded just once on VM initialization instead of on every checkpoint (though not in `prepare_checkpoint` ? that is too early, I believe). > > And just to have it more compact since the calls are very closely related > Suggestion: > > // Note that CRaCEngine and CRaCEngineOptions are not updated (as documented) > // so we don't need to re-init the whole engine handle. > if (!resolve_image_location(image_location, sizeof(image_location), &ignored) || > !ensure_image_location(image_location, false) || > !_engine->configure_image_location(image_location)) { > return JVM_CHECKPOINT_ERROR; > } In this PR I have merely reused the place; I don't see much incentive to move it earlier on. I think this is up to preference between 1) doing some (reversible) work on checkpoint and then (possibly) failing due to no access to the directory, vs. 2) creating the directory, (possibly) failing during checkpoint and leaving the filesystem tainted (or implementing cleanup) I don't have a strong preference, but I agree that we can collapse the two `if`s. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2372213659 From tpushkin at openjdk.org Tue Sep 23 12:53:06 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 23 Sep 2025 12:53:06 GMT Subject: [crac] RFR: 8367975: [CRaC] Pattern in CRaCCheckpointTo In-Reply-To: References: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com> Message-ID: On Tue, 23 Sep 2025 12:40:06 GMT, Radim Vansa wrote: >> src/hotspot/share/runtime/crac.cpp line 257: >> >>> 255: #undef check_retval >>> 256: >>> 257: static bool ensure_image_location(const char *path, bool rm) { >> >> Since this is checkpoint-specific: >> Suggestion: >> >> static bool ensure_checkpoint_image_location(const char *path, bool rm) { >> >> >> Or maybe make it also handle the restore case have this in one place. > > I don't follow the second part - restore should not attempt to create the directory. Yes, we would need to add a parameters like `bool is_checkpoint` which will define whether we need to create a directory or just check for existence ------------- PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2372222013 From rvansa at openjdk.org Tue Sep 23 13:11:42 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 23 Sep 2025 13:11:42 GMT Subject: [crac] RFR: 8367975: [CRaC] Pattern in CRaCCheckpointTo In-Reply-To: References: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com> Message-ID: On Tue, 23 Sep 2025 12:37:54 GMT, Timofei Pushkin wrote: >> We're using RFC 4122 variant, with Msb0 = 1 and Msb1 = 0: https://datatracker.ietf.org/doc/html/rfc4122#section-4.1.1 > > Yes, and IIUC it fixes only two bits, allowing the other two to change: 1000 = 8, 1001 = 9, 1010 = a, 1011 = b. Or am I reading it wrong? Sorry, you're right. My mind flipped binary `10` to hexadecimal `a` as if it was decimal `10`. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2372278344 From tpushkin at openjdk.org Tue Sep 23 14:15:29 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 23 Sep 2025 14:15:29 GMT Subject: [crac] RFR: 8367975: [CRaC] Pattern in CRaCCheckpointTo In-Reply-To: References: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com> Message-ID: On Tue, 23 Sep 2025 12:47:27 GMT, Radim Vansa wrote: >> src/hotspot/share/runtime/crac.cpp line 294: >> >>> 292: if (!_engine->configure_image_location(image_location)) { >>> 293: return JVM_CHECKPOINT_ERROR; >>> 294: } >> >> Is there a reason we do this and CPU features recording below so late instead of at the beginning `crac::checkpoint`, for example? The only reason I see is that the timestamps in `crac::record_time_before_checkpoint` and `%t` would be further away in that case (BTW, if we leave this as is we could use the recorded time for the pattern for consistency). >> >> If we did not clear the recorded user data on checkpoint, CPU features could be recorded just once on VM initialization instead of on every checkpoint (though not in `prepare_checkpoint` ? that is too early, I believe). >> >> And just to have it more compact since the calls are very closely related >> Suggestion: >> >> // Note that CRaCEngine and CRaCEngineOptions are not updated (as documented) >> // so we don't need to re-init the whole engine handle. >> if (!resolve_image_location(image_location, sizeof(image_location), &ignored) || >> !ensure_image_location(image_location, false) || >> !_engine->configure_image_location(image_location)) { >> return JVM_CHECKPOINT_ERROR; >> } > > In this PR I have merely reused the place; I don't see much incentive to move it earlier on. I think this is up to preference between > 1) doing some (reversible) work on checkpoint and then (possibly) failing due to no access to the directory, vs. > 2) creating the directory, (possibly) failing during checkpoint and leaving the filesystem tainted (or implementing cleanup) > I don't have a strong preference, but I agree that we can collapse the two `if`s. Even with the current code we can still fail after creating the directory, without writing anything and AFAIK without cleaning up, so I do not think moving it earlier will make this much worse. But yes, for now let's leave it here. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/264#discussion_r2372478553 From rmarchenko at openjdk.org Wed Sep 24 15:24:07 2025 From: rmarchenko at openjdk.org (Roman Marchenko) Date: Wed, 24 Sep 2025 15:24:07 GMT Subject: [crac] RFR: 8368570: [CRaC] Improve JdwpTransportTest Message-ID: JdwpTransportTest sometimes hangs, so it'd be good to dump Java threads, and create a corefile if possible. Also improved reading from output stream. ------------- Commit messages: - remove copyright - test improvements Changes: https://git.openjdk.org/crac/pull/265/files Webrev: https://webrevs.openjdk.org/?repo=crac&pr=265&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368570 Stats: 144 lines in 3 files changed: 130 ins; 5 del; 9 mod Patch: https://git.openjdk.org/crac/pull/265.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/265/head:pull/265 PR: https://git.openjdk.org/crac/pull/265 From tpushkin at openjdk.org Mon Sep 29 09:39:28 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 29 Sep 2025 09:39:28 GMT Subject: [crac] RFR: 8368570: [CRaC] Improve JdwpTransportTest In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 15:18:35 GMT, Roman Marchenko wrote: > JdwpTransportTest sometimes hangs, so it'd be good to dump Java threads, and create a corefile if possible. > > Also improved reading from output stream. test/jdk/jdk/crac/jdwp/JdwpTransportTest.java line 2: > 1: /* > 2: * Copyright (c) 2023-2025, Azul Systems, Inc. All rights reserved. I believe the convention is to write it like this, not sure if there are any legally significant differences Suggestion: * Copyright (c) 2023, 2025, Azul Systems, Inc. All rights reserved. test/jdk/jdk/crac/jdwp/JdwpTransportTest.java line 112: > 110: CracProcess process = builder.captureOutput(true).startCheckpoint(); > 111: var errReader = new AsyncStreamReader(process.errOutput()); > 112: var reader = new AsyncStreamReader(process.output()); Not that it matters much in this test, but I believe `AsyncStreamReader` should be made `AutoCloseable` (on close, close the buffer, maybe also stop the reading thread) and these should be treated as resources in the try below test/jdk/jdk/crac/jdwp/JdwpTransportTest.java line 150: > 148: System.err.println("reader.isRunning()=" + reader.isRunning()); > 149: CracProcess.printThreadDump(process.pid()); > 150: CracProcess.dumpProcess(process.pid()); If we end up always taking the PID from `CracProcess` itself why making these two static? test/jdk/jdk/crac/jdwp/JdwpTransportTest.java line 168: > 166: public void exec() throws Exception { > 167: System.out.println(STARTED + ", pid=" + ProcessHandle.current().pid()); > 168: System.out.flush(); AFAIK `System.out` is auto-flushed when `\n` is written, so `println` should be sufficient test/lib/jdk/test/lib/crac/AsyncStreamReader.java line 1: > 1: package jdk.test.lib.crac; Missing copyright header test/lib/jdk/test/lib/crac/CracProcess.java line 236: > 234: } > 235: > 236: public static void dumpProcess(long pid) throws IOException, InterruptedException { `JdwpTransportTest` runs on all platforms and I believe this is not going to work on non-Linux test/lib/jdk/test/lib/crac/CracProcess.java line 254: > 252: } > 253: if (exitCode == 0) { > 254: System.out.println("Core dump seems created successfully for pid=" + pid); Suggestion: System.out.println("Core dump seems to be created successfully for pid=" + pid); ------------- PR Review Comment: https://git.openjdk.org/crac/pull/265#discussion_r2387173852 PR Review Comment: https://git.openjdk.org/crac/pull/265#discussion_r2387200475 PR Review Comment: https://git.openjdk.org/crac/pull/265#discussion_r2387272950 PR Review Comment: https://git.openjdk.org/crac/pull/265#discussion_r2387268144 PR Review Comment: https://git.openjdk.org/crac/pull/265#discussion_r2387195030 PR Review Comment: https://git.openjdk.org/crac/pull/265#discussion_r2387311754 PR Review Comment: https://git.openjdk.org/crac/pull/265#discussion_r2387314760 From rmarchenko at openjdk.org Mon Sep 29 10:34:51 2025 From: rmarchenko at openjdk.org (Roman Marchenko) Date: Mon, 29 Sep 2025 10:34:51 GMT Subject: [crac] RFR: 8368570: [CRaC] Improve JdwpTransportTest [v2] In-Reply-To: References: Message-ID: > JdwpTransportTest sometimes hangs, so it'd be good to dump Java threads, and create a corefile if possible. > > Also improved reading from output stream. Roman Marchenko has updated the pull request incrementally with two additional commits since the last revision: - Update test/lib/jdk/test/lib/crac/CracProcess.java fix grammar Co-authored-by: Timofei Pushkin - Update test/jdk/jdk/crac/jdwp/JdwpTransportTest.java fix copyright Co-authored-by: Timofei Pushkin ------------- Changes: - all: https://git.openjdk.org/crac/pull/265/files - new: https://git.openjdk.org/crac/pull/265/files/c4fede95..9573ebf9 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=265&range=01 - incr: https://webrevs.openjdk.org/?repo=crac&pr=265&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/crac/pull/265.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/265/head:pull/265 PR: https://git.openjdk.org/crac/pull/265 From rmarchenko at openjdk.org Mon Sep 29 10:37:02 2025 From: rmarchenko at openjdk.org (Roman Marchenko) Date: Mon, 29 Sep 2025 10:37:02 GMT Subject: [crac] RFR: 8368570: [CRaC] Improve JdwpTransportTest [v2] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 08:55:45 GMT, Timofei Pushkin wrote: >> Roman Marchenko has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update test/lib/jdk/test/lib/crac/CracProcess.java >> >> fix grammar >> >> Co-authored-by: Timofei Pushkin >> - Update test/jdk/jdk/crac/jdwp/JdwpTransportTest.java >> >> fix copyright >> >> Co-authored-by: Timofei Pushkin > > test/lib/jdk/test/lib/crac/AsyncStreamReader.java line 1: > >> 1: package jdk.test.lib.crac; > > Missing copyright header There is no copyright header for all files in in `test/jdk/jdk/crac/` folder, so I thought it's intended to be so. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/265#discussion_r2387473746 From rmarchenko at openjdk.org Mon Sep 29 10:44:15 2025 From: rmarchenko at openjdk.org (Roman Marchenko) Date: Mon, 29 Sep 2025 10:44:15 GMT Subject: [crac] RFR: 8368570: [CRaC] Improve JdwpTransportTest [v2] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 09:21:08 GMT, Timofei Pushkin wrote: >> Roman Marchenko has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update test/lib/jdk/test/lib/crac/CracProcess.java >> >> fix grammar >> >> Co-authored-by: Timofei Pushkin >> - Update test/jdk/jdk/crac/jdwp/JdwpTransportTest.java >> >> fix copyright >> >> Co-authored-by: Timofei Pushkin > > test/jdk/jdk/crac/jdwp/JdwpTransportTest.java line 150: > >> 148: System.err.println("reader.isRunning()=" + reader.isRunning()); >> 149: CracProcess.printThreadDump(process.pid()); >> 150: CracProcess.dumpProcess(process.pid()); > > If we end up always taking the PID from `CracProcess` itself why making these two static? For this test, yes. But these two methods may be useful for tests when Java changes its PID on restore. I will change this, if you doesn't think so. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/265#discussion_r2387489336 From tpushkin at openjdk.org Mon Sep 29 10:44:17 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 29 Sep 2025 10:44:17 GMT Subject: [crac] RFR: 8368570: [CRaC] Improve JdwpTransportTest [v2] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 10:34:43 GMT, Roman Marchenko wrote: >> test/lib/jdk/test/lib/crac/AsyncStreamReader.java line 1: >> >>> 1: package jdk.test.lib.crac; >> >> Missing copyright header > > There is no copyright header for all files in in `test/jdk/jdk/crac/` folder, so I thought it's intended to be so. I think that is an oversight as other files in `test/lib` have them. We have an internal issue to bring all the missing license headers to CRaC code. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/265#discussion_r2387484991 From tpushkin at openjdk.org Mon Sep 29 10:52:39 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 29 Sep 2025 10:52:39 GMT Subject: [crac] RFR: 8368570: [CRaC] Improve JdwpTransportTest [v2] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 10:41:32 GMT, Roman Marchenko wrote: >> test/jdk/jdk/crac/jdwp/JdwpTransportTest.java line 150: >> >>> 148: System.err.println("reader.isRunning()=" + reader.isRunning()); >>> 149: CracProcess.printThreadDump(process.pid()); >>> 150: CracProcess.dumpProcess(process.pid()); >> >> If we end up always taking the PID from `CracProcess` itself why making these two static? > > For this test, yes. But these two methods may be useful for tests when Java changes its PID on restore. > > I will change this, if you doesn't think so. I'd make it non-static for now and change to static when/if we need that but I don't insist ------------- PR Review Comment: https://git.openjdk.org/crac/pull/265#discussion_r2387504794 From rmarchenko at openjdk.org Mon Sep 29 10:52:41 2025 From: rmarchenko at openjdk.org (Roman Marchenko) Date: Mon, 29 Sep 2025 10:52:41 GMT Subject: [crac] RFR: 8368570: [CRaC] Improve JdwpTransportTest [v2] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 09:34:35 GMT, Timofei Pushkin wrote: >> Roman Marchenko has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update test/lib/jdk/test/lib/crac/CracProcess.java >> >> fix grammar >> >> Co-authored-by: Timofei Pushkin >> - Update test/jdk/jdk/crac/jdwp/JdwpTransportTest.java >> >> fix copyright >> >> Co-authored-by: Timofei Pushkin > > test/lib/jdk/test/lib/crac/CracProcess.java line 236: > >> 234: } >> 235: >> 236: public static void dumpProcess(long pid) throws IOException, InterruptedException { > > `JdwpTransportTest` runs on all platforms and I believe this is not going to work on non-Linux I think it should work on linuxes, macos, and cygwin. cygwin doesn't produce a core file of course. For other cases, the command will fail with a message. I don't think this is important as it will be triggered when process hangs only. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/265#discussion_r2387501097 From rmarchenko at openjdk.org Mon Sep 29 12:06:08 2025 From: rmarchenko at openjdk.org (Roman Marchenko) Date: Mon, 29 Sep 2025 12:06:08 GMT Subject: [crac] RFR: 8368570: [CRaC] Improve JdwpTransportTest [v2] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 08:57:48 GMT, Timofei Pushkin wrote: >> Roman Marchenko has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update test/lib/jdk/test/lib/crac/CracProcess.java >> >> fix grammar >> >> Co-authored-by: Timofei Pushkin >> - Update test/jdk/jdk/crac/jdwp/JdwpTransportTest.java >> >> fix copyright >> >> Co-authored-by: Timofei Pushkin > > test/jdk/jdk/crac/jdwp/JdwpTransportTest.java line 112: > >> 110: CracProcess process = builder.captureOutput(true).startCheckpoint(); >> 111: var errReader = new AsyncStreamReader(process.errOutput()); >> 112: var reader = new AsyncStreamReader(process.output()); > > Not that it matters much in this test, but I believe `AsyncStreamReader` should be made `AutoCloseable` (on close, close the buffer, maybe also stop the reading thread) and these should be treated as resources in the try below Autocloseable is ok for me, but these two cannot be used in catch and finally blocks in case they are resources. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/265#discussion_r2387693792 From tpushkin at openjdk.org Mon Sep 29 12:13:04 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 29 Sep 2025 12:13:04 GMT Subject: [crac] RFR: 8368570: [CRaC] Improve JdwpTransportTest [v3] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 12:03:16 GMT, Roman Marchenko wrote: >> test/jdk/jdk/crac/jdwp/JdwpTransportTest.java line 112: >> >>> 110: CracProcess process = builder.captureOutput(true).startCheckpoint(); >>> 111: var errReader = new AsyncStreamReader(process.errOutput()); >>> 112: var reader = new AsyncStreamReader(process.output()); >> >> Not that it matters much in this test, but I believe `AsyncStreamReader` should be made `AutoCloseable` (on close, close the buffer, maybe also stop the reading thread) and these should be treated as resources in the try below > > Autocloseable is ok for me, but these two cannot be used in catch and finally blocks in case they are resources. Oh, yes, then there should be either another wrapping try-with-resources or explicit `close` calls in the existing `finally` ------------- PR Review Comment: https://git.openjdk.org/crac/pull/265#discussion_r2387703725 From rmarchenko at openjdk.org Mon Sep 29 12:13:01 2025 From: rmarchenko at openjdk.org (Roman Marchenko) Date: Mon, 29 Sep 2025 12:13:01 GMT Subject: [crac] RFR: 8368570: [CRaC] Improve JdwpTransportTest [v3] In-Reply-To: References: Message-ID: > JdwpTransportTest sometimes hangs, so it'd be good to dump Java threads, and create a corefile if possible. > > Also improved reading from output stream. Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision: fix review comments ------------- Changes: - all: https://git.openjdk.org/crac/pull/265/files - new: https://git.openjdk.org/crac/pull/265/files/9573ebf9..c40c1be7 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=265&range=02 - incr: https://webrevs.openjdk.org/?repo=crac&pr=265&range=01-02 Stats: 45 lines in 3 files changed: 36 ins; 1 del; 8 mod Patch: https://git.openjdk.org/crac/pull/265.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/265/head:pull/265 PR: https://git.openjdk.org/crac/pull/265 From rmarchenko at openjdk.org Mon Sep 29 12:13:12 2025 From: rmarchenko at openjdk.org (Roman Marchenko) Date: Mon, 29 Sep 2025 12:13:12 GMT Subject: [crac] RFR: 8368570: [CRaC] Improve JdwpTransportTest [v3] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 09:19:17 GMT, Timofei Pushkin wrote: >> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision: >> >> fix review comments > > test/jdk/jdk/crac/jdwp/JdwpTransportTest.java line 168: > >> 166: public void exec() throws Exception { >> 167: System.out.println(STARTED + ", pid=" + ProcessHandle.current().pid()); >> 168: System.out.flush(); > > AFAIK `System.out` is auto-flushed when `\n` is written, so `println` should be sufficient done ------------- PR Review Comment: https://git.openjdk.org/crac/pull/265#discussion_r2387708053 From rmarchenko at openjdk.org Mon Sep 29 12:13:09 2025 From: rmarchenko at openjdk.org (Roman Marchenko) Date: Mon, 29 Sep 2025 12:13:09 GMT Subject: [crac] RFR: 8368570: [CRaC] Improve JdwpTransportTest [v3] In-Reply-To: References: Message-ID: <4XIJhAtPy7Eavg0qgJxvaE7i2ptV6n60BF0vgbr6zXs=.16ae4c3c-1ed1-4aea-9885-bcdfa3850a47@github.com> On Mon, 29 Sep 2025 10:48:05 GMT, Timofei Pushkin wrote: >> For this test, yes. But these two methods may be useful for tests when Java changes its PID on restore. >> >> I will change this, if you doesn't think so. > > I'd make it non-static for now and change to static when/if we need that but I don't insist done >> There is no copyright header for all files in in `test/jdk/jdk/crac/` folder, so I thought it's intended to be so. > > I think that is an oversight as other files in `test/lib` have them. We have an internal issue to bring all the missing license headers to CRaC code. done ------------- PR Review Comment: https://git.openjdk.org/crac/pull/265#discussion_r2387709797 PR Review Comment: https://git.openjdk.org/crac/pull/265#discussion_r2387708831 From rmarchenko at openjdk.org Mon Sep 29 12:17:33 2025 From: rmarchenko at openjdk.org (Roman Marchenko) Date: Mon, 29 Sep 2025 12:17:33 GMT Subject: [crac] RFR: 8368570: [CRaC] Improve JdwpTransportTest [v4] In-Reply-To: References: Message-ID: > JdwpTransportTest sometimes hangs, so it'd be good to dump Java threads, and create a corefile if possible. > > Also improved reading from output stream. Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision: fix review comments (cont.) ------------- Changes: - all: https://git.openjdk.org/crac/pull/265/files - new: https://git.openjdk.org/crac/pull/265/files/c40c1be7..1628f33a Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=265&range=03 - incr: https://webrevs.openjdk.org/?repo=crac&pr=265&range=02-03 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/crac/pull/265.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/265/head:pull/265 PR: https://git.openjdk.org/crac/pull/265 From rmarchenko at openjdk.org Mon Sep 29 12:17:33 2025 From: rmarchenko at openjdk.org (Roman Marchenko) Date: Mon, 29 Sep 2025 12:17:33 GMT Subject: [crac] RFR: 8368570: [CRaC] Improve JdwpTransportTest [v4] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 12:07:38 GMT, Timofei Pushkin wrote: >> Autocloseable is ok for me, but these two cannot be used in catch and finally blocks in case they are resources. > > Oh, yes, then there should be either another wrapping try-with-resources or explicit `close` calls in the existing `finally` OK, I've done this. However, in this particular case, it seems like `process.destroyForcibly()` should guarantee the streams are closed from the prosess' side. ------------- PR Review Comment: https://git.openjdk.org/crac/pull/265#discussion_r2387728563 From tpushkin at openjdk.org Mon Sep 29 13:49:22 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 29 Sep 2025 13:49:22 GMT Subject: [crac] RFR: 8368570: [CRaC] Improve JdwpTransportTest [v4] In-Reply-To: References: Message-ID: <2mvuTK6WdgPJb10VHi8V5zierWjwO7qhMhsgkCVDQrE=.8e612d79-784a-4107-8942-f24a3e8aba25@github.com> On Mon, 29 Sep 2025 12:17:33 GMT, Roman Marchenko wrote: >> JdwpTransportTest sometimes hangs, so it'd be good to dump Java threads, and create a corefile if possible. >> >> Also improved reading from output stream. > > Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision: > > fix review comments (cont.) test/lib/jdk/test/lib/crac/CracProcess.java line 236: > 234: } > 235: > 236: public static void dumpProcess(long pid) throws IOException, InterruptedException { I believe it does not actually throw these Suggestion: public static void dumpProcess(long pid) { ------------- PR Review Comment: https://git.openjdk.org/crac/pull/265#discussion_r2388054564 From rmarchenko at openjdk.org Mon Sep 29 13:57:16 2025 From: rmarchenko at openjdk.org (Roman Marchenko) Date: Mon, 29 Sep 2025 13:57:16 GMT Subject: [crac] RFR: 8368570: [CRaC] Improve JdwpTransportTest [v5] In-Reply-To: References: Message-ID: > JdwpTransportTest sometimes hangs, so it'd be good to dump Java threads, and create a corefile if possible. > > Also improved reading from output stream. Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision: fix review comment ------------- Changes: - all: https://git.openjdk.org/crac/pull/265/files - new: https://git.openjdk.org/crac/pull/265/files/1628f33a..8433b882 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=265&range=04 - incr: https://webrevs.openjdk.org/?repo=crac&pr=265&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/crac/pull/265.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/265/head:pull/265 PR: https://git.openjdk.org/crac/pull/265 From rmarchenko at openjdk.org Mon Sep 29 13:57:18 2025 From: rmarchenko at openjdk.org (Roman Marchenko) Date: Mon, 29 Sep 2025 13:57:18 GMT Subject: [crac] RFR: 8368570: [CRaC] Improve JdwpTransportTest [v5] In-Reply-To: <2mvuTK6WdgPJb10VHi8V5zierWjwO7qhMhsgkCVDQrE=.8e612d79-784a-4107-8942-f24a3e8aba25@github.com> References: <2mvuTK6WdgPJb10VHi8V5zierWjwO7qhMhsgkCVDQrE=.8e612d79-784a-4107-8942-f24a3e8aba25@github.com> Message-ID: On Mon, 29 Sep 2025 13:47:00 GMT, Timofei Pushkin wrote: >> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision: >> >> fix review comment > > test/lib/jdk/test/lib/crac/CracProcess.java line 236: > >> 234: } >> 235: >> 236: public static void dumpProcess(long pid) throws IOException, InterruptedException { > > I believe it does not actually throw these > Suggestion: > > public static void dumpProcess(long pid) { done ------------- PR Review Comment: https://git.openjdk.org/crac/pull/265#discussion_r2388078620 From tpushkin at openjdk.org Mon Sep 29 15:04:59 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Mon, 29 Sep 2025 15:04:59 GMT Subject: [crac] RFR: 8368570: [CRaC] Improve JdwpTransportTest [v5] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 13:57:16 GMT, Roman Marchenko wrote: >> JdwpTransportTest sometimes hangs, so it'd be good to dump Java threads, and create a corefile if possible. >> >> Also improved reading from output stream. > > Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision: > > fix review comment LGTM. It would be cool if sometime we would extend [the test failure handler](https://github.com/openjdk/crac/tree/crac/test/failure_handler) to gather this info from the child process then we would not need to do this on a per-test basis. But I am not very familiar with that code. ------------- Marked as reviewed by tpushkin (Committer). PR Review: https://git.openjdk.org/crac/pull/265#pullrequestreview-3280347720 From duke at openjdk.org Tue Sep 30 06:27:41 2025 From: duke at openjdk.org (duke) Date: Tue, 30 Sep 2025 06:27:41 GMT Subject: [crac] RFR: 8368570: [CRaC] Improve JdwpTransportTest [v5] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 13:57:16 GMT, Roman Marchenko wrote: >> JdwpTransportTest sometimes hangs, so it'd be good to dump Java threads, and create a corefile if possible. >> >> Also improved reading from output stream. > > Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision: > > fix review comment @wkia Your change (at version 8433b882b9d67acce46c05f1bb5c52e8037e3b9e) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/crac/pull/265#issuecomment-3350151802 From tpushkin at openjdk.org Tue Sep 30 06:46:24 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Tue, 30 Sep 2025 06:46:24 GMT Subject: [crac] RFR: 8368570: [CRaC] Improve JdwpTransportTest [v5] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 13:57:16 GMT, Roman Marchenko wrote: >> JdwpTransportTest sometimes hangs, so it'd be good to dump Java threads, and create a corefile if possible. >> >> Also improved reading from output stream. > > Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision: > > fix review comment `jdk/crac/RemoteJmxTest` failed ? I doubt it is related but please check and file an issue if not related ------------- PR Comment: https://git.openjdk.org/crac/pull/265#issuecomment-3350213323 From duke at openjdk.org Tue Sep 30 08:55:55 2025 From: duke at openjdk.org (duke) Date: Tue, 30 Sep 2025 08:55:55 GMT Subject: git: openjdk/crac: 8367975_checkpoint_pattern: Address review comments Message-ID: <00d72e3c-3532-4c09-8585-469146ecb86d@openjdk.org> Changeset: f6be8b42 Branch: 8367975_checkpoint_pattern Author: Radim Vansa Date: 2025-09-30 10:54:20 +0000 URL: https://git.openjdk.org/crac/commit/f6be8b4281c7100799fc90b4ded0989bba9a64bb Address review comments ! src/hotspot/cpu/x86/vm_version_x86.hpp ! src/hotspot/share/runtime/crac.cpp ! src/hotspot/share/runtime/crac.hpp ! src/hotspot/share/runtime/crac_engine.hpp ! test/jdk/jdk/crac/PathPatternTest.java From rvansa at openjdk.org Tue Sep 30 08:58:33 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 30 Sep 2025 08:58:33 GMT Subject: [crac] RFR: 8367975: [CRaC] Pattern in CRaCCheckpointTo [v2] In-Reply-To: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com> References: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com> Message-ID: > Add support for pattern in `CRaCCheckpointTo` VM option. Radim Vansa has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/crac/pull/264/files - new: https://git.openjdk.org/crac/pull/264/files/7c23d813..f6be8b42 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=264&range=01 - incr: https://webrevs.openjdk.org/?repo=crac&pr=264&range=00-01 Stats: 259 lines in 5 files changed: 112 ins; 119 del; 28 mod Patch: https://git.openjdk.org/crac/pull/264.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/264/head:pull/264 PR: https://git.openjdk.org/crac/pull/264 From duke at openjdk.org Tue Sep 30 09:18:36 2025 From: duke at openjdk.org (duke) Date: Tue, 30 Sep 2025 09:18:36 GMT Subject: git: openjdk/crac: 8367975_checkpoint_pattern: Add docs Message-ID: <6a01e6d9-11dc-4990-bd5b-cd6f351c7dec@openjdk.org> Changeset: b02f242e Branch: 8367975_checkpoint_pattern Author: Radim Vansa Date: 2025-09-30 11:14:11 +0000 URL: https://git.openjdk.org/crac/commit/b02f242e83c4d9ab89c6712b6444b5e035407272 Add docs ! src/hotspot/share/runtime/globals.hpp ! src/java.base/share/man/java.md From rvansa at openjdk.org Tue Sep 30 09:18:38 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 30 Sep 2025 09:18:38 GMT Subject: [crac] RFR: 8367975: [CRaC] Pattern in CRaCCheckpointTo [v3] In-Reply-To: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com> References: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com> Message-ID: > Add support for pattern in `CRaCCheckpointTo` VM option. Radim Vansa has updated the pull request incrementally with one additional commit since the last revision: Add docs ------------- Changes: - all: https://git.openjdk.org/crac/pull/264/files - new: https://git.openjdk.org/crac/pull/264/files/f6be8b42..b02f242e Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=264&range=02 - incr: https://webrevs.openjdk.org/?repo=crac&pr=264&range=01-02 Stats: 23 lines in 2 files changed: 22 ins; 0 del; 1 mod Patch: https://git.openjdk.org/crac/pull/264.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/264/head:pull/264 PR: https://git.openjdk.org/crac/pull/264 From duke at openjdk.org Tue Sep 30 09:32:43 2025 From: duke at openjdk.org (duke) Date: Tue, 30 Sep 2025 09:32:43 GMT Subject: git: openjdk/crac: 8367975_checkpoint_pattern: Notice about empty %f Message-ID: <62895465-bb38-4a69-942a-c82c573e046b@openjdk.org> Changeset: c4e81fd2 Branch: 8367975_checkpoint_pattern Author: Radim Vansa Date: 2025-09-30 11:27:42 +0000 URL: https://git.openjdk.org/crac/commit/c4e81fd2f0fda595561bfefcadf6bdead5ed00a1 Notice about empty %f ! src/java.base/share/man/java.md From rvansa at openjdk.org Tue Sep 30 09:32:44 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 30 Sep 2025 09:32:44 GMT Subject: [crac] RFR: 8367975: [CRaC] Pattern in CRaCCheckpointTo [v4] In-Reply-To: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com> References: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com> Message-ID: > Add support for pattern in `CRaCCheckpointTo` VM option. Radim Vansa has updated the pull request incrementally with one additional commit since the last revision: Notice about empty %f ------------- Changes: - all: https://git.openjdk.org/crac/pull/264/files - new: https://git.openjdk.org/crac/pull/264/files/b02f242e..c4e81fd2 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=264&range=03 - incr: https://webrevs.openjdk.org/?repo=crac&pr=264&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/crac/pull/264.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/264/head:pull/264 PR: https://git.openjdk.org/crac/pull/264 From rvansa at openjdk.org Tue Sep 30 09:35:24 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 30 Sep 2025 09:35:24 GMT Subject: [crac] RFR: 8367975: [CRaC] Pattern in CRaCCheckpointTo [v4] In-Reply-To: References: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com> Message-ID: On Tue, 23 Sep 2025 10:05:23 GMT, Timofei Pushkin wrote: >> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision: >> >> Notice about empty %f > > The patterns should be documented in `java.md` and maybe mentioned in `globals.hpp`. > > Also since the patterns are handled in shared code it would make sense to have OS pattern too. @TimPushkin Thank you for the review, I've addressed all your comments, I think. I've considered adding `%o` for OS name matching `os.name` property, but turns out this is non-trivial outside POSIX systems where `struct utsname.sysname` (from `uname`) is used: on Mac's this is hardcoded, on Windows there's a complex switch and this is not exposed in VM code through some `os::name()` adapter. So I won't go the extra miles to get the value; I don't think that in practice this will be used on non-Linux systems anyway. ------------- PR Comment: https://git.openjdk.org/crac/pull/264#issuecomment-3350957686 From rvansa at openjdk.org Tue Sep 30 13:04:29 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 30 Sep 2025 13:04:29 GMT Subject: [crac] RFR: 8367975: [CRaC] Pattern in CRaCCheckpointTo [v4] In-Reply-To: References: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com> Message-ID: On Tue, 30 Sep 2025 09:32:44 GMT, Radim Vansa wrote: >> Add support for pattern in `CRaCCheckpointTo` VM option. > > Radim Vansa has updated the pull request incrementally with one additional commit since the last revision: > > Notice about empty %f Looks like when I've created the PR from a branch in this repository the GHA with tests is not executed. Pushed the code to my repo, too, tests running here: https://github.com/rvansa/crac/actions/runs/18130706409 ------------- PR Comment: https://git.openjdk.org/crac/pull/264#issuecomment-3352012424 From duke at openjdk.org Tue Sep 30 13:39:16 2025 From: duke at openjdk.org (duke) Date: Tue, 30 Sep 2025 13:39:16 GMT Subject: git: openjdk/crac: 8367975_checkpoint_pattern: Fix build Message-ID: Changeset: d5f1cc35 Branch: 8367975_checkpoint_pattern Author: Radim Vansa Date: 2025-09-30 15:36:04 +0000 URL: https://git.openjdk.org/crac/commit/d5f1cc35281ea9d436be1d4c880bc70d016bba86 Fix build ! src/hotspot/cpu/aarch64/vm_version_aarch64.hpp ! src/hotspot/cpu/arm/vm_version_arm.hpp ! src/hotspot/cpu/ppc/vm_version_ppc.hpp ! src/hotspot/cpu/riscv/vm_version_riscv.hpp ! src/hotspot/cpu/s390/vm_version_s390.hpp ! src/hotspot/cpu/zero/vm_version_zero.hpp From rvansa at openjdk.org Tue Sep 30 13:39:59 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 30 Sep 2025 13:39:59 GMT Subject: [crac] RFR: 8367975: [CRaC] Pattern in CRaCCheckpointTo [v5] In-Reply-To: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com> References: <5hY56jMiKIEQhceFqID5EOTlA9csr4sZ3iN4cqMne5I=.1d0f0117-5b80-4626-8986-fba83e9b289b@github.com> Message-ID: > Add support for pattern in `CRaCCheckpointTo` VM option. Radim Vansa has updated the pull request incrementally with one additional commit since the last revision: Fix build ------------- Changes: - all: https://git.openjdk.org/crac/pull/264/files - new: https://git.openjdk.org/crac/pull/264/files/c4e81fd2..d5f1cc35 Webrevs: - full: https://webrevs.openjdk.org/?repo=crac&pr=264&range=04 - incr: https://webrevs.openjdk.org/?repo=crac&pr=264&range=03-04 Stats: 18 lines in 6 files changed: 12 ins; 0 del; 6 mod Patch: https://git.openjdk.org/crac/pull/264.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/264/head:pull/264 PR: https://git.openjdk.org/crac/pull/264 From rvansa at openjdk.org Tue Sep 30 13:45:51 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 30 Sep 2025 13:45:51 GMT Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine Message-ID: Right now the logic checking if CPU features used before checkpoint match current CPU features is in VM code. VM stores and retrieves CPU features through C/R API's user_data extension. This is convenient when we have a single image that can be either accepted or rejected, but does not offer the flexibility for C/R engine to select the best image for current execution environment. The goal of this issue is to move to a declarative API that will express the requirements using more abstract means, labels (for CPU architecture) and bitmaps (for CPU features). ------------- Commit messages: - tabs -> spaces - 8368929: [CRaC] Move CPUFeatures check to C/R engine Changes: https://git.openjdk.org/crac/pull/266/files Webrev: https://webrevs.openjdk.org/?repo=crac&pr=266&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368929 Stats: 841 lines in 14 files changed: 672 ins; 80 del; 89 mod Patch: https://git.openjdk.org/crac/pull/266.diff Fetch: git fetch https://git.openjdk.org/crac.git pull/266/head:pull/266 PR: https://git.openjdk.org/crac/pull/266 From rvansa at openjdk.org Tue Sep 30 13:45:52 2025 From: rvansa at openjdk.org (Radim Vansa) Date: Tue, 30 Sep 2025 13:45:52 GMT Subject: [crac] RFR: 8368929: [CRaC] Move CPUFeatures check to C/R engine In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 13:17:54 GMT, Radim Vansa wrote: > Right now the logic checking if CPU features used before checkpoint match current CPU features is in VM code. VM stores and retrieves CPU features through C/R API's user_data extension. This is convenient when we have a single image that can be either accepted or rejected, but does not offer the flexibility for C/R engine to select the best image for current execution environment. > > The goal of this issue is to move to a declarative API that will express the requirements using more abstract means, labels (for CPU architecture) and bitmaps (for CPU features). @jankratochvil Please give this a review, since you've authored most of the modified code. ------------- PR Comment: https://git.openjdk.org/crac/pull/266#issuecomment-3352114136