RFR: 8328944: NMT reports "unknown" memory [v2]
Gerard Ziemski
gziemski at openjdk.org
Tue Nov 19 22:01:14 UTC 2024
On Mon, 18 Nov 2024 10:42:59 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:
> Why should we supplement `mtNone` with `mtAllocated`? Is one indicative of a failure mode?
That is the general idea, if we see `mtNone` in a report we know we missed something. `mtAllocated` would be the one indicating that we are "in transition".
But I put it back into draft mode to experiment and get a better picture on how to proceed.
> src/hotspot/share/nmt/virtualMemoryTracker.hpp line 389:
>
>> 387: static bool remove_released_region (address base_addr, size_t size);
>> 388: static bool remove_released_region (ReservedMemoryRegion* rgn);
>> 389: static void set_reserved_region_type (address addr, MemTag mem_tag);
>
> I don't think that we should remove this API. It may very well need to be used, even if its usage should be minimized.
If there is currently no-one using it, then we should remove it. We can add it back, once we need it.
> src/hotspot/share/runtime/os.hpp line 460:
>
>> 458: // Attempts to reserve the virtual memory at [addr, addr + bytes).
>> 459: // Does not overwrite existing mappings.
>> 460: static char* attempt_reserve_memory_at(char* addr, size_t bytes, bool executable, MemTag mem_tag);
>
> Is it worth adding an overload: `reserve_memory(bytes, mem_tag)` where `executable` is implicitly `false`?
I would want that myself too, but that requires that we put it at the end, which I did in fact had at one point, but didn't like the parameters call order - the mem_tag is usually the very last one.
> test/hotspot/gtest/memory/test_virtualspace.cpp line 374:
>
>> 372: alignment, // alignment
>> 373: page_size, // page size
>> 374: (char *)nullptr, // requested_address
>
> Style fix: Remove space between `char` and `*`
Fixed.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21843#issuecomment-2483404110
PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1847064817
PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1846811525
PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1847065123
More information about the shenandoah-dev
mailing list