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

[Thomas Stuefe]

On Fri, 15 Aug 2025 12:52:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> 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.

+1. Ideally, `os::malloc` and friends should not be terribly hot. That's why we have custom allocators for heavy fine-grained use cases like C2. 

`ZapCHeap` may be a bit misleading as a name, since all it does is zap on free. 

Zap on malloc would also be useful. If we are worried about speed, zapping the 1-2 words would already give 95% of effect, since that is in high likelyhood the later location for some important struct members. And there is some probability that the libc touches memory in the vicinity of the block start during allocation, so it's probably already paged in.

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

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