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

[Doerr, Martin]

Hi Andrew,

> Or are you suggesting that Java is so unusual that it justifies overriding a user's settings?

I think this kind of matches was I thought.
I guess most people don't even know that this malloc related stuff can be configured. (I didn't know much about it before I started to investigate this issue, either.)
And I also assume that most JVM users don't know that the JVM has own arena implementation etc. which makes glibc arenas under the hood useless for these kind of allocations. 
So I think it would be nice if we could help these people.
 
Embedded applications or cloud applications running in containers may suffer from wasting so much virtual memory, which is really significant.

I was not sure if this is the best approach to address the issue, but I'd like to see an improvement, here.

Best regards,
Martin


-----Original Message-----
From: Andrew Haley [mailto:aph at redhat.com] 
Sent: Donnerstag, 14. Dezember 2017 19:02
To: Doerr, Martin <martin.doerr at sap.com>; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR(XS): 8193521: glibc wastes memory with default configuration

On 14/12/17 16:00, Doerr, Martin wrote:
> I'm not aware of performance critical concurrent malloc usages in the JVM. Maybe somebody else is?
> Comments are welcome. I will also need a sponsor if this change is desired.

Is this something that a JVM should decide?  I would have thought it's
for the user of the system to decide policy.  They can set
MALLOC_ARENA_MAX on a system-wide basis if they really need to save
memory, or just for Java.  Or are you suggesting that Java is so
unusual that it justifies overriding a user's settings?

If a user has explicitly set MALLOC_ARENA_MAX, don't futz with it.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671