JDK-8345318 : Use custom malloc to expose pointer tagged data to NMT
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2024-12-02
  • Updated: 2025-04-29
  • Resolved: 2025-04-29
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.
Other
tbdResolved
Related Reports
Duplicate :  
Description
We have asked Florian Weimer from RedHat whether malloc could allow clients to access the internal free bits of pointer data, but were told that glibc would rather find a way to give that data back to the application.

Florian suggested to use a custom malloc.

We could take the vanilla glibc malloc and extend it by exposing the internal pointer metadata, which mallloc will always require to store the pointer size, so that "free()" API works.

Having such mechanism built into the malloc would allow NMT to:

- remove its own mechanism for pointer data tagging
- remove NMT pre-init cache
- be able to turn NMT ON/OFF during runtime
- minimize the memory overhead associated with every pointer

Another advantage would be the same behavior/patterns when allocating memory on all platforms (could be a disadvantage assuming that platform specific mallocs are platform optimized - but this deserves to be checked and compared with data based analysis, not assumptions)

I think it deserves serious consideration and at least a prototype.

Comments
This will be addressed by JDK-8352292
29-04-2025