remove INCLUDE_NMT?

[Aleksei Voitylov]

From a point of view of Minimal VM, based on these numbers I do not
object to unconditional inclusion of NMT.

I still believe we should not go down this path (as in making more
optional technologies unconditional) far too long.

On 21/01/2022 11:39, Thomas Stüfe wrote:
> Hi Alexei,
>
> I built minimal with and without nmt (linux x64). Libjvm file size
> increased from 5.26M -> 5.33M, an increase of 74k.
>
> I tried to measure footprint (HelloWorld with fixed preallocated heap
> and metaspace and AlwaysPreTouch) but could not see a consistent
> result. Numbers were pretty stable for multiple runs and fluctuated
> 100M+-300k, but with no discernable pattern. So whatever NMT costs at
> runtime is hidden by noise.
>
> In theory, having NMT in the libjvm means you pay 64/32 KB on
> 64/32bit platforms for the NMT preinit hash table. That is malloced at
> startup and the only thing that cannot be avoided. The rest of the
> data is or can easily be allocated on demand. Note that the reason the
> preinit hash table was not showing up on RSS may be that even though
> it's malloced it does usually not get used much, so it remains untouched.
>
> Are these numbers worrisome to you? After reading all answers, I am
> leaning toward removing INCLUDE_NMT, but am unemotional. It is mainly
> a cleanup thing, and we could do that differently.
>
> Cheers, Thomas
>
> On Thu, Jan 20, 2022 at 10:17 PM Aleksei Voitylov
> <aleksei.voitylov at bell-sw.com <mailto:aleksei.voitylov at bell-sw.com>>
> wrote:
>
>     Hi,
>
>     we still build and use Minimal in production for constrained
>     environments. What is the impact of unconditional inclusion of NMT in
>     terms of static footprint?
>
>     If it is negligible, I'm fine with it becoming unconditional. If not,
>     maybe it's best to have some weak guarantees where we fix such configs
>     occasionally.
>
>     -Aleksei
>
>     On 20/01/2022 09:58, Thomas Stüfe wrote:
>     > Hi,
>     >
>     > we have NMT, and NMT can be disabled at build time. It can also
>     be disabled
>     > at runtime. NMT disabling at build time causes INCLUDE_NMT to be
>     false.
>     >
>     > So we have four scenarios:
>     >
>     > 1 nmt disabled at build (minimal VM)
>     > 2 nmt enabled, off
>     > 3 nmt enabled, summary mode
>     > 4 nmt enabled, detail mode
>     >
>     > Removing (1) would simplify code and be one less configuration
>     to test. Do
>     > we really need the ability to exclude NMT from build? We have other
>     > facilities which are not strictly necessary either but which we
>     cannot
>     > disable, e.g. UL. So it feels a bit arbitrary to take that much
>     care for
>     > NMT. Was there a reason for that?
>     >
>     > It only matters for minimal builds, since I don't know any real
>     VM out
>     > there which does not come with NMT.
>     >
>     > NMT comes with a few static data, but those are only a few KB
>     and we could
>     > instead allocate them on demand. NMT is not difficult to port
>     either, which
>     > would be another reason to keep it optional.
>     >
>     > What do you think?
>     >
>     > Thanks, Thomas
>