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

[Thomas Stuefe]

On Mon, 24 Jun 2024 09:54:00 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:

> > The include guards should be placed before the includes.
> 
> Thanks!
> 
> > Would it make sense to put this in utilities/ instead of nmt/.
> 
> Do we have anyone else that wants to use this? The threshold in terms of API quality is typically higher for something in utilities/ than a local utility. I'm working on some improvements to this allocator already, maybe we can take a move to utilities/ together with those improvements?

Yes, I will use it to replace some code in Metaspace at least, but for that I need some more features (placing this thing atop of an existing memory range, and templatized index type). 

Can all be done in a follow-up RFE.

> 
> > Could we try another round of coming up with a better name for this utility? HomogenousObjectArray is eerily similar to G1's humongous object arrays. It's also not clear to me what makes this array an homogenous array. Is our other arrays non-homogenous?
> 
> I agree on the name part. We could call it a `HomogenousAllocator`, that does differentiate it meaningfully from something like `Arena` which can allocate anything. @tstuefe , arenas are also an example of the storage/lifetime of the objects from an allocator being bound to the lifetime of that allocator, so I think this makes sense.

Names are hard.

We already have two types of arenas in hotspots, plus glibc has arenas, so "arena" is not ideal either. Arena does usually not imply a free list either, nor homogenous sizes.

Thinking about it, Array already sort of implies homogeneous sizes, so maybe "homogeneous" is redundant.

ArrayWithFreeList? Unsexy but precise.

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

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