RFR: JDK-8261238: NMT should not limit baselining by size threshold [v3]

[Thomas Stuefe]

On Thu, 11 Feb 2021 14:39:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at openjdk.java.net):_
>>> 
>>> On 9/02/2021 2:29 am, Thomas Stuefe wrote:
>>> 
>>> > On Mon, 8 Feb 2021 16:03:59 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:
>>> > > The threshold was put in place purely due to memory consumption concerns.
>>> > > There was a memory overhead requirement in original document (prior to JEP, Oracle private). If this is no longer a concern, I am good with this change.
>>> > 
>>> > 
>>> > Great, Zhengyu, thanks!
>>> 
>>> To know if this is still a concern we know to know what the original
>>> concern was.
>>> 
>>> David
>> 
>> Yes, it would be helpful to know what the initial memory requirements were as well as the considerations behind it. NMT tries to be very slim; which is good, but at various places we trade performance for memory footprint (eg. live with a load factor of 5+ in the malloc site table rather than spending an additional 4-12K to broaden the table). Without knowing these requirements and without deciding if they are still valid improving NMT is difficult.
>
> I am currently working on a patch which reduces cost of baselining: https://bugs.openjdk.java.net/browse/JDK-8261491 which should be more than enough to mitigate the modest footprint increase of this patch.
> 
> So, can we get this patch approved please, unless there are other technical considerations I am not seeing?

I split out non-controversial display changes into JDK-8262165.

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

PR: https://git.openjdk.java.net/jdk/pull/2428