The VM info string should be a constant, but its value cannot be finalized until after VM arguments have been fully processed. It has been noticed , however, that some code is calling this method before that happens and as a result can use/save the wrong information. By printing out the value when it is called I can see the following for example:
java -Xcomp -version
VM_INFO: mixed mode, sharing
VM_INFO: mixed mode, sharing
VM_INFO: compiled mode, sharing
VM_INFO: compiled mode, sharing
java version "25-internal" 2025-09-16 LTS
Java(TM) SE Runtime Environment (fastdebug build 25-internal-LTS-2025-04-02-0624352.daholme...)
Java HotSpot(TM) 64-Bit Server VM (fastdebug build 25-internal-LTS-2025-04-02-0624352.daholme..., compiled mode, sharing)
java -Xcomp -Xshare:off -version
VM_INFO: mixed mode, sharing
VM_INFO: mixed mode, sharing
VM_INFO: compiled mode, sharing
VM_INFO: compiled mode
java version "25-internal" 2025-09-16 LTS
Java(TM) SE Runtime Environment (fastdebug build 25-internal-LTS-2025-04-02-0624352.daholme...)
Java HotSpot(TM) 64-Bit Server VM (fastdebug build 25-internal-LTS-2025-04-02-0624352.daholme..., compiled mode)
Only the final, fourth call is correct. We need to identify and correct all callers.
java -Xcomp -version
VM_INFO: mixed mode, sharing
VM_INFO: mixed mode, sharing
VM_INFO: compiled mode, sharing
VM_INFO: compiled mode, sharing
java version "25-internal" 2025-09-16 LTS
Java(TM) SE Runtime Environment (fastdebug build 25-internal-LTS-2025-04-02-0624352.daholme...)
Java HotSpot(TM) 64-Bit Server VM (fastdebug build 25-internal-LTS-2025-04-02-0624352.daholme..., compiled mode, sharing)
java -Xcomp -Xshare:off -version
VM_INFO: mixed mode, sharing
VM_INFO: mixed mode, sharing
VM_INFO: compiled mode, sharing
VM_INFO: compiled mode
java version "25-internal" 2025-09-16 LTS
Java(TM) SE Runtime Environment (fastdebug build 25-internal-LTS-2025-04-02-0624352.daholme...)
Java HotSpot(TM) 64-Bit Server VM (fastdebug build 25-internal-LTS-2025-04-02-0624352.daholme..., compiled mode)
Only the final, fourth call is correct. We need to identify and correct all callers.
- relates to
-
JDK-8353189 [ASAN] memory leak after 8352184
-
- Resolved
-