RFR(XS): 8193521: glibc wastes memory with default configuration

Andrew Dinn adinn at redhat.com
Fri Dec 15 15:11:42 UTC 2017

On 15/12/17 12:31, Doerr, Martin wrote:
> We are testing the change and didn't see performance regressions,
> yet. But we have to run more benchmarks, especially with G1 (see mail
> from Thomas Schatzl). Large server tests will be interesting as
> well.
> I can't really estimate the risk for native libs and I can understand
> the concern. Maybe it would be acceptable if the change gets
> switchable.

Well, I think Andrew Haley's point was that it already is switchable --
by setting MALLOC_ARENA_MAX to 1.

Of course, there is still a position between that status quo and your
patch where the JVM makes the config call to the malloc library unless
the user explicitly inhibits it e.g. via a new command line -XX option
or using an alternative env setting.

That would allow a get-out for any users affected. However, the get-out
also assumes they know this change is responsible and how to undo it. I
am not sure our support org would enjoy fielding the calls this might
give rise to.

We (Red Hat) are indeed considering setting MALLOC_ARENA_MAX=1 in some
of our cloud deployments so as to avoid this allocation cost. It might
be appropriate where, say, -Xmx is set under some low threshold.
However, if we were to do that it would be under control of the script
launching the JVM rather than OpenJDK and would not reverse any prior
setting by our users. I don't see why others cannot follow a similar path.


Andrew Dinn
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

More information about the hotspot-runtime-dev mailing list