RFR: JDK-8302820: Remove costs for NMTPreInit when NMT is off [v2]

[Thomas Stuefe]

On Wed, 1 Mar 2023 15:44:36 GMT, Justin King <jcking at openjdk.org> wrote:

> My main complaints with NMTPreInit are the CPU and memory overhead it imposes for those who are not using NMT. This change takes care of the first, but still has the latter. 

Yes, sure, but let's keep perspective. We are talking about ~300..500 surviving allocations, which cost "leaked" LU entries of 7..12KB. Are we really worried about that? Even if we are this PR is already a step in the right direction since today NMTPreInit keeps the whole LU table alive.

> I wouldn't mind a slightly more complex approach which used closed-addressing to keep it flat and just re-sized as necessary. Allowing a cheap free on the whole thing when it is disabled.

Table resizing is costly, and may hurt startup. Entry removal for closed-addressing hashmaps is a pain to code, or well at least its complexish. Complex code does not get reviews :-(

If the "leaked" entries really bug people, there are multiple ways out of it:

1) just iterating the LU table and freeing all entries - gain 12 KB at the expense of some CPU work. Maybe I should just do that since its 3 lines of code and avoids arguments.
2) chaining all LU entries together directly, at the cost of one additional next pointer, and walking that chain freeing all entries - saves having to walk the mostly sparse LU table
3) (my preferred solution) letting LU entries live in a heap structure (basically, arena like slab list with freelist atop of it) like we do e.g. in Metaspace. Then just delete the slab(s) in one go.

(3) would be what I would do. But since I keep using this kind of data structure (metaspace, would make sense also for other hash table entry types, e.g. NMT), I would like to add it as generic container; but that raises other questions. So better for a follow up RFE.

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

PR: https://git.openjdk.org/jdk/pull/12642