RFR: 8365165: Zap C-heap memory at delete/free
Aleksey Shipilev
shade at openjdk.org
Thu Aug 14 10:25:00 UTC 2025
We sometimes have a lifecycle problem with C-heap allocated objects. The most recent I dealt with is [JDK-8364501](https://bugs.openjdk.org/browse/JDK-8364501). It would be convenient to have diagnostic code to zap the memory that is freed on C heap. We already do this for alloc/realloc. When NMT is enabled (which it is for debug builds), we can also do this for frees, as NMT tells us the size of the free-ed block.
This PR introduces a new diagnostic flag to match other `Zap*` flags we already have, puts the zapping on free path, and wraps alloc/realloc zapping with the flag as well. The last part is not really necessary, but it is nicer to wrap zapping code with a flag like this, so we can disable it for testing performance. JCStress routinely opts-out of most of the zapping to gain higher sampling throughput on fastdebug builds.
Additional testing:
- [x] Linux AArch64 server fastdebug, selectively rolling back [JDK-8364501](https://bugs.openjdk.org/browse/JDK-8364501) -- starts to immediately crash on reproducer
- [ ] Linux AArch64 server fastdebug, `all` (no new crashes)
- [ ] Linux x86_64 server fastdebug, `all` (no new crashes)
-------------
Commit messages:
- More flag uses
- Fix
Changes: https://git.openjdk.org/jdk/pull/26775/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26775&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8365165
Stats: 12 lines in 3 files changed: 9 ins; 0 del; 3 mod
Patch: https://git.openjdk.org/jdk/pull/26775.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/26775/head:pull/26775
PR: https://git.openjdk.org/jdk/pull/26775
More information about the hotspot-runtime-dev
mailing list