RFR: 8365165: Zap C-heap memory at delete/free
Kim Barrett
kbarrett at openjdk.org
Thu Aug 14 22:36:10 UTC 2025
On Thu, 14 Aug 2025 10:16:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> 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
> - [x] Linux x86_64 server fastdebug, `all` (no new crashes, phew)
> - [x] Linux AArch64 server fastdebug, `all` (no new crashes, phew)
src/hotspot/share/runtime/globals.hpp line 486:
> 484: "Zap filler objects") \
> 485: \
> 486: develop(bool, ZapCHeap, trueInDebug, \
I have this vague recollection that maybe we used to do something like this, and decided to stop
because it really badly hurt performance in some cases. I know debug builds aren't expected to
be performant, but there's slow and then there's really unpleasant to use. Maybe make this
default to false and require explicit opt-in?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26775#discussion_r2277852056
More information about the hotspot-runtime-dev
mailing list