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

[Thomas Stuefe]

On Fri, 15 Aug 2025 14:34:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> +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.
>
>> Zap on malloc would also be useful.
> 
> I don't understand. `ZapCHeap`, as implement in current PR, zaps on malloc as well. Well, actually, it just wraps the already existing zapping code with flag guards. I used to call the flag `ZapFreeCHeap`, but then realized we do malloc/realloc side already, so it just claimed those to be a part of the same zapping feature.

Okay, I see. So it's the other way around, we zap newly allocated memory, but not free memory. I thought you were doing that, according to your comment:

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

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

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