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

Thomas Stuefe stuefe at openjdk.org
Tue Apr 30 06:03:16 UTC 2024


On Mon, 15 Apr 2024 16:11:13 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.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   alignment in coding style changed.

src/hotspot/share/cds/metaspaceShared.cpp line 1322:

> 1320:                                        os::vm_page_size(), mtClassShared, (char*)base_address);
> 1321:       class_space_rs   = ReservedSpace(class_space_size, class_space_alignment,
> 1322:                                        os::vm_page_size(), mtClass, (char*)ccs_base);

Note that here, we place two spaces atop of a region that has been previously mapped with mtClass (see e.g. src/hotspot/cpu/aarch64/compressedKlass_aarch64.cpp). I assume this is not a problem?

src/hotspot/share/memory/virtualspace.cpp line 57:

> 55: }
> 56: 
> 57: ReservedSpace::ReservedSpace(size_t size, size_t preferred_page_size, MEMFLAGS flag) : _fd_for_heap(-1), _nmt_flag(flag) {

Small nit: Mixture of styles. As much as I dislike it, current style is to initialize things via dedicated initialize methods. I'd rather stay consistent.

That said, I would be more than happy for someone to give these classes a once-over and convert them to the more usual style - using initializer lists. Then, we also can make members const that should be const, e.g. _nmt_flags. Not in this PR though.

src/hotspot/share/memory/virtualspace.cpp line 623:

> 621:   }
> 622:   // _nmt_flag is used internally by initialize_compressed_heap
> 623:   _nmt_flag = mtJavaHeap;

Nit, we use a mixture of directly accessing _nmt_flag and accessing it via getter. Hotspot seems to prefer getters/setters. Can we use setters here?

src/hotspot/share/memory/virtualspace.hpp line 46:

> 44:   int      _fd_for_heap;
> 45:   bool     _executable;
> 46:   MEMFLAGS _nmt_flag;

See my remark below. This member, and probably others (e.g. page size and size) could and should probably be const. Food for follow up PRs.

src/hotspot/share/memory/virtualspace.hpp line 71:

> 69:  public:
> 70: 
> 71:   MEMFLAGS nmt_flag() { return _nmt_flag; }

const method

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18745#discussion_r1584163635
PR Review Comment: https://git.openjdk.org/jdk/pull/18745#discussion_r1584153176
PR Review Comment: https://git.openjdk.org/jdk/pull/18745#discussion_r1584158038
PR Review Comment: https://git.openjdk.org/jdk/pull/18745#discussion_r1584154689
PR Review Comment: https://git.openjdk.org/jdk/pull/18745#discussion_r1584150480


More information about the shenandoah-dev mailing list