RFR: 8335091: NMT: VMATree reserve_mapping and commit_mapping APIs need MEMFLAGS while un/-committing API has no MEMFLAGS arg [v3]
Johan Sjölen
jsjolen at openjdk.org
Sun Jul 28 08:25:36 UTC 2024
On Thu, 25 Jul 2024 14:51:50 GMT, Afshin Zafari <azafari at openjdk.org> wrote:
>> In committing a region, it is not mandatory to provide a MEMFLAGS flag where the committed region inherits the flag from the main region it resides in.
>> In un-committing there is no need to a MEMFLAGS at all.
>> The `register_mapping` API of the VMATree *requires* a MEMFLAGS (via metadata arg) in both of these two operations. To do the flag inheriting, it is possible to copy the flag of the left node in the tree to the newly inserted ones.
>>
>> An optional bool arg (default is false) is added to VMATree API to copy the existing flag of the left node to the new nodes.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>
> reserve always use the flag in metadata
Alright, I think this is OK.
One thing that worries me a bit is the fact that we take the `leq` value without checking if it's equal to the `A` address. This means that if we only have a range 0-100 with mtTest and I reserve with `copy_flag` at 1000-1100, then that range will receive `mtTest`. That's a bit spooky. Perhaps the `copy_flag` should only be used if there's a range starting at exactly that address? That seems less surprising to me.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20330#issuecomment-2254391638
More information about the hotspot-runtime-dev
mailing list