RFR: 8342504: Remove NMT header and footer canaries [v2]

[Thomas Stuefe]

On Wed, 26 Feb 2025 17:29:56 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> > > > As I said in preparation of this work, I don't oppose it, but I am not happy.
> 
> > > > ASAN is not a replacement. ASAN is a special build, slow, needs tons of additional memory, stops at the first (often false) positive, and is often bitrotted since, to my knowledge, no vendor builds ASAN-enabled JVMs regularly. More importantly, if you have a problem in the field, it is easy to convince a customer to switch on NMT. You will not convince a customer to switch their production JVMs against an ASAN-enabled one.
> 
> > > > But okay, let's remove it. I hope the capabilities this will enable are worth the loss of this capability.
> 
> > > 
> 
> > > 
> 
> > > Do you have any recent examples of NMT canaries helping out "in the field"? I do feel a little uneasy about loosing this feature, assuming it still helps out in the field.
> 
> > 
> 
> > Nothing I can share, but I had two customers using Unsafe.AllocateMemory (which atm are the only allocations from outside the JVM that are tracked), and they overwrote the boundaries. Took a while to find this, but the canaries added by NMT (mainly the hex dump outputs) were helpful.
> 
> > 
> 
> > I wonder, do we have to completely throw this feature away? Even a single byte as canary would be better than nothing?
> 
> 
> 
> Or make the feature optional for those devs, who are willing to pay the price?
> 
> 
> 
> I would be OK with this being a dynamic, optional feature that can be turned OFF/ON.
> 
> 

increases complexity, though. malloc header is 16 byte, we could use eg the most significant byte of the size field. Heck, we could use the topmost four bytes, since probably Nobody ever allocates more than 4g with malloc. But certainly the topmost byte. 56 bit are larger than most addrss spaces.

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

PR Comment: https://git.openjdk.org/jdk/pull/21560#issuecomment-2685987511