JDK-8361101 : AOTCodeAddressTable::_stubs_addr not initialized/freed properly
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 25
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-06-30
  • Updated: 2025-07-03
  • Resolved: 2025-07-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 25 JDK 26
25Fixed 26 b05Fixed
Related Reports
Causes :  
JDK-8354887 - Preserve runtime blobs in AOT code cache
Description
AOTCodeAddressTable::_stubs_addr is not initialized to nullptr in the constructor, and it is not freed in the destructor.
Comments
A pull request was submitted for review. Branch: jdk25 URL: https://git.openjdk.org/jdk/pull/26095 Date: 2025-07-02 14:56:23 +0000
02-07-2025
Changeset: 3066a67e Branch: master Author: Ashutosh Mehra <asmehra@openjdk.org> Date: 2025-07-02 13:25:00 +0000 URL: https://git.openjdk.org/jdk/commit/3066a67e6279f7e3896ab545bc6c291d279d2b03
02-07-2025
Thanks Vladimir, re-targeting to JDK 25.
02-07-2025
Yes, it should be back ported into JDK 25. It is not critical because we close it only during assembly phase and not in production run. And assembly phase does not run application. But I think we should backport because it is trivial and good fix.
01-07-2025
[~asmehra] I assume the impact is a memory leak? Should this be fixed in JDK 25? ILW = Memory leak, with AOT, no workaround but disable AOT = HLM = P3
01-07-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/26053 Date: 2025-06-30 19:45:49 +0000
30-06-2025