RFR: 8365165: Zap C-heap memory at delete/free

[Aleksey Shipilev]

On Thu, 14 Aug 2025 22:33:35 GMT, Kim Barrett <kbarrett 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?

This is a legitimate concern. We have been optimizing/guarding zapping code over the years, because excessive zapping is sometimes not worth it. That said, the utility for diagnostic zapping lies in being enabled by default. If we had this zapping in place, [JDK-8364501](https://bugs.openjdk.org/browse/JDK-8364501) would have been trivial to find. So we already know it is useful.

To estimate rough costs of doing this extra work, I ran Linux x86_64 server fastdebug `tier1` with and without the patch, and here are the results:


# Before
62589.94s user 5358.93s system 4015% cpu 28:16.24 total
62453.49s user 5388.42s system 3993% cpu 28:18.60 total
62363.92s user 5347.49s system 3976% cpu 28:22.75 total

# After
62803.82s user 5350.01s system 3983% cpu 28:31.05 total
63868.84s user 5415.74s system 3997% cpu 28:33.04 total
63864.74s user 5521.71s system 4051% cpu 28:37.57 total


So there is an impact, but I will hard-pressed to call it really bad. 

The upside for this PR is that we can now summarily turn off malloc/realloc/free zapping, if we want to.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26775#discussion_r2278938398