NMTPreInit had been brought into question lately (see JDK-8299196 and JDK-8301811). The points of contention were costs for NMT is off, and complexity.
I believe NMTPreInit is vital, and removing it would be a severe mistake. So let's address the cost problem.
NMTPreInit, in its current form, incurs costs post-init for lookup table lookup to identify pre-init allocations. We can do away with that if we allocate preinit allocations without malloc headers.
That has two advantages:
- costs for NMT off are reduced to the absolute minimum. All that remains is querying NMT tracking level to see if we are pre- or post-init, and we need to query NMT tracking level anyway to see if NMT is switched on, so that cost is not going away unless we get rid of NMT too.
- We can delete the lookup table if NMT is off, since we don't need it nomore, and regain 63352 bytes of memory.
I believe NMTPreInit is vital, and removing it would be a severe mistake. So let's address the cost problem.
NMTPreInit, in its current form, incurs costs post-init for lookup table lookup to identify pre-init allocations. We can do away with that if we allocate preinit allocations without malloc headers.
That has two advantages:
- costs for NMT off are reduced to the absolute minimum. All that remains is querying NMT tracking level to see if we are pre- or post-init, and we need to query NMT tracking level anyway to see if NMT is switched on, so that cost is not going away unless we get rid of NMT too.
- We can delete the lookup table if NMT is off, since we don't need it nomore, and regain 63352 bytes of memory.
- relates to
-
JDK-8303668 Generalize Metachunk header pool and use it for NMT preinit
-
- Closed
-
