RFR: 8333658: NMT: Use an allocator with 4-byte pointers to save memory in NativeCallStackStorage [v16]

[Johan Sjölen]

On Thu, 13 Jun 2024 08:16:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>But for that, I would have needed the numerical value of the stack index. But that is hidden away in NativeCallStackStorage::StackIndex. Apart from giving me RSI from typing, I cannot just extract the integer from NativeCallStackStorage::StackIndex since its sole purpose in life is to hide that integer. Of course, I can declare yet another friend class. But that's ugly and does not scale.

Alright, I've crumbled. I changed it to `using I = int32_t;`. Feel free to do the same with `StackIndex`.

>I can kind of see the point with test classes, but even then, a better way would be to make the test class an inner class.

Noo, it's so painful to have test code embedded within prod code.

>I would remove/not bother with the Allocators. There isn't much of a point, and small code is good code. The arena version is particularly questionable since Arenas don't really support arbitrary deallocation. I would not want anyone to use this allocator in real code.

That's fine, I've removed the performance testing.

>I would like to have a non-growing version. Optionally, one where I can hand in an address range, and that gets used. Could possibly be combined for simplicity (if you specify a range, its a non-growing array). Reason: I want to be able to place stuff that needs to be address-stable, and I often need to do this in pre-allocated ranges.

I see the value in that, but can we do that as a separate PR? Is this a Metaspace thing, by the way?

**Note:** We still have no checks for double-frees. That'll need some baking in my head.

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

PR Comment: https://git.openjdk.org/jdk/pull/18979#issuecomment-2166774789