RFR: 8364198: NMT should have a better corruption message
Thomas Stuefe
stuefe at openjdk.org
Tue Jul 29 05:41:55 UTC 2025
On Mon, 28 Jul 2025 23:42:44 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:
> Looks good.
>
> @jdksjolen is it possible to give more information in output? For example, where address is located: metaspace, code cache, arena, some C heap allocations (Does NMT keep track of such?).
Note that we already print out hexdump and whatnot for the broken block.
Getting more information, for mmaped areas, should be relatively simple now that we have changed the mmap backend to use an interval tree (VMATree). We should be able to search for memory areas very quickly. But this malloc header change affects malloc only.
Here, we could write out the allocation call stack of the broken block if we run with NMT detail mode - the malloc header contains a reference to the malloc site table entry. This only works if the malloc header is uncorrupted enough (and can be safely recognized as such). If it ain't, we would need to track memory ranges for malloc using the new VMATree, but that opens a much bigger can of worms (malloc performance, concurrency etc).
-------------
PR Comment: https://git.openjdk.org/jdk/pull/26507#issuecomment-3130765260
More information about the hotspot-runtime-dev
mailing list