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

[Thomas Stuefe]

On Mon, 8 Feb 2021 16:26:59 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.
>
>> 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.

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

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