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

[Thomas Stuefe]

On Tue, 9 Feb 2021 10:17:52 GMT, Thomas Stuefe <stuefe 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!
>
>> _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?

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

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