RFR: JDK-8326586: Improve Speed of System.map [v3]

[Stefan Karlsson]

On Tue, 27 Feb 2024 07:12:51 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Why `uintx` rather than just `uint`? Is there a reason to have a variable-sized counter for this? Does it even need to be unsigned?
>
> Hmm... I guess that would work.
> 
> Its number of NMT ranges. 
> 
> My original thought was: we have a 64-bit address space, usually 128TB, which would give us 32 billion 4K pages, and with region folding (since you need regions separated by a page) this comes to max. 16 billion 4K regions mapped, which would be more than a 32-bit value can represent.
> 
> OTOH maybe that's overthinking. unsigned gives us 4 billion max, and the largest processes I have ever seen had  ~20 million mappings. I think a lot of other things start failing before we reach 4 billion.
> 
> Okay, I make it an unsigned then.

> > In other parts of HotSpot we have been changed usages of `uintx` to instead use `size_t`.
> 
> Why? size_t implies memory size to me. This is not a memory size, its a counter.
> 
> (If reviewers prefer uintx, I can change it; I just want to understand the reasoning behind choosing size_t)

I don't think it necessarily implies memory sizes. Take a look at the description here:

https://en.cppreference.com/w/cpp/types/size_t

> std::size_t is commonly used for array indexing and loop counting. Programs that use other types, such as unsigned int, for array indexing may fail on, e.g. 64-bit systems when the index exceeds [UINT_MAX](https://en.cppreference.com/w/cpp/types/climits) or if it relies on 32-bit modular arithmetic.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17984#discussion_r1506171207