[jdk17u-dev] RFR: 8292989: Avoid dynamic memory in AsyncLogWriter [v2]

[Xin Liu]

On Mon, 7 Aug 2023 09:20:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert resourceHash.hpp and use functor instead of C++ lambda.
>
> Hi Xin :)
> 
>> Hi, Thomas,
>> 
>> Thanks you for the comments. I was told that it is better reducing memory footprint of UL in jdk17u, a LTS Java.
> 
> Interesting, I'm curious about the effectiveness of your patch. Do you see good results? I would have thought that a lot of these interleaving memory requests are just taken from and handed back into fastbins or tcache, and therefore don't make the arena grow. Also, the glibc attempts to reclaim memory automatically are quite limited (see PR description https://github.com/openjdk/jdk/pull/14781#issue-1790932923)
> 
>> May I learn more about glibc autotrim? Is it a glibc feature or a new feature of hotspot?
>> 
>> I found [JDK-8268893](https://bugs.openjdk.org/browse/JDK-8268893) on JBS. It itself is a very useful feature! It is not an automatic trimmer, is it?
> 
> Its https://bugs.openjdk.org/browse/JDK-8293114. You have to manually enable it, it is still marked as experimental. Also not in 17 yet, but Aleksey is preparing things to get it down quickly once it has baked in head a bit.
> 
> Essentially, what the trimmer does is run periodically a malloc_trim() operation. malloc_trim() will reclaim memory that has been free'd and that is in page granularity (so, it will also reclaim memory in the middle of an arena).
> 
> Cheers, Thomas

hi, @tstuefe, 

I think we need both of them. This patch refrains from using any malloc/free in the first place. It also helps avoid the fragmentation issue.  Autotrimmer is a general solution for glibc overprovision.  

Should we still consider to include this patch in jdk17u?

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

PR Comment: https://git.openjdk.org/jdk17u-dev/pull/1630#issuecomment-1671961761