RFR: 8330076: [NMT] add/make a mandatory MEMFLAGS argument to family of os::reserve/commit/uncommit memory API

Thomas Stuefe stuefe at openjdk.org
Thu Apr 11 16:10:11 UTC 2024


On Thu, 11 Apr 2024 15:54:38 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> `MEMFLAGS flag` is used to hold/show the type of the memory regions in NMT. Each call of NMT API requires a search through the list of memory regions.
> The Hotspot code reserves/commits/uncommits memory regions and later calls explicitly NMT API with a specific memory type (e.g., `mtGC`, `mtJavaHeap`) for that region.  Therefore, there are two search in the list of regions per reserve/commit/uncommit operations, one for the operation and another for setting the type of the region.  
> When the memory type is passed in during reserve/commit/uncommit operations, NMT can use it and avoid the extra search for setting the memory type.
> 
> Tests: tiers1-5 passed on linux-x64, macosx-aarch64 and windows-x64 for debug and non-debug builds.

The general thrust of this is okay, and I think it makes sense. It also combines nicely with the VMATree work Johan does.

One question though, why do you want to abolish default values for MEMFLAGS? Allowing default values would reduce this patch by quite a bit, and make backporting less painful.

Another idea: To alleviate the need to pass MEMFLAGS all the time, could we have something like a "active MEMFLAGS" state per Thread, and set that stack-based with a XXMark object? That way, one could say at the entrance of Metaspace, for instance, "whatever is allocated under the scope of this function, please mark with mtMetaspace".

Just an idea. Otherwise, I think this is good, and thanks for doing this onerous work.

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

PR Comment: https://git.openjdk.org/jdk/pull/18745#issuecomment-2050037989


More information about the shenandoah-dev mailing list