RFR: JDK-8293114: GC should trim the native heap [v10]

[Thomas Stuefe]

On Fri, 30 Jun 2023 13:12:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Okay, cool. The reason I am asking it that glibc "memory leaks" are not uncommon in production cases. There are quite a few libraries that churn native memory (looks at Netty), even with internal pooling. Having something that is backportable to 21u and 17u would be a plus.

Thanks, nice to see a confirmation that this is useful.

This patch started out simple, and then I fear I started to seriously over-engineer the GC part of it. I'll give it a look next week to see if I can dumb it down.

> So I see that `malloc_trim` actually has the parameter `pad`:
> 
> ```
>        The pad argument specifies the amount of free space to leave
>        untrimmed at the top of the heap.  If this argument is 0, only
>        the minimum amount of memory is maintained at the top of the heap
>        (i.e., one page or less).  A nonzero argument can be used to
>        maintain some trailing space at the top of the heap in order to
>        allow future allocations to be made without having to extend the
>        heap with [sbrk(2)](https://man7.org/linux/man-pages/man2/sbrk.2.html).
> ```
> 
> Does current glibc honor that argument at all? Can we use that to control the incrementality of the trim? Since `malloc_trim` return value also describes if trimming was successful, we could probably come up with the adaptive scheme that guesses which pad to use, so that we don't trim the entirety of the memory, but still trim something.

This was one of the first things I tried last year. Does have very little impact. IIRC it only applies to the main arena (the one using sbrk) and limits the amount by which the break was lowered? I may remember the details wrong, but my tests also showed very little effect.

The bulk of memory reclamation comes from the glibc MADV_DONTNEED'ing free chunks. I think it does that without any bookkeeping, so for subsequent trims, it has no idea of how much memory of that range was paged in. So I think there is no way to implement a limiting trim via the size parameter.

I though about that and I think the only way to implement a limited trim would be to add a new API, since you cannot use the existing one without breaking compatibility. I always meant to ask Florian about this. I will tomorrow.

In any case, this would only be a solution for future glibcs, not for the ones that are around.

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

PR Comment: https://git.openjdk.org/jdk/pull/10085#issuecomment-1614843984
PR Comment: https://git.openjdk.org/jdk/pull/10085#issuecomment-1622178112