RFR: 8312132: Add tracking of multiple address spaces in NMT [v5]

[Johan Sjölen]

On Sun, 5 May 2024 09:28:09 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:

>> Ah, I get the confusion. This is not what I meant.
>> 
>> What I mean was:
>> 
>> At the moment you malloc space for NativeCallStack, then keep NativeCallStack* in the hash map. NativeCallStack* now uniquely identifies your stack.
>> 
>> What I meant is to place NativeCallStack in a growable array. Now, you have a 32-bit or even a 16-bit index into that array. That index uniquely identifies the stack. You keep that index the hashmap. The hashmap does not change. Hashmap storage has nothing to do with that array. This is not the bucket array.
>> 
>> Basically, you replace the malloc for the NativeCallStack with a placement-new in a new growable array. The rest stays the same. 
>> 
>> But now, you have a 32-bit or even 16-bit index, and that is smaller than a native pointer, which makes it possible to encode the stack information in a tree node much more succinctively. This makes it possible to encode the whole tree node metainfo very comfortably in a single 64-bit value. You can even get both in- and out-state of the VMATree into a single 64-bit value like this:
>> 
>> bits 0-7 MEMFLAGS in
>> bits 8-16 State in
>> bits 16-31 callstack index in
>> 
>> bits 32-39 MEMFLAGS out
>> bits 40-47 State out
>> bits 48-63 callstack index out
>
> Oh right of course, just store the NCS separately to the closed-addressing hashtable. I'm going for a 32-bit value just because that's the quickest. We can do a further compression round in a future PR.
> 
> If we really wanted to, we could also store the `Link`s in a GA and thus reduce their pointer sizes to 32-bits also. Still, future PR, IMHO.

We're down to a 4-byte `StackIndex`, hooray! Resolving this conversation now, let's go further down this route in a future RFE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18289#discussion_r1592346276