Re: [8u] RFR backport of JDK-8198423: Improve metaspace chunk allocation

Denghui Dong denghui.ddh at alibaba-inc.com
Tue Sep 24 09:59:23 UTC 2019


Hi Thomas,
   Thank you for your reply,  i agree with you that JDK-8221173 is a better solution,  hope it come soon.

Cheers
Denghui Dong
------------------------------------------------------------------
From:Thomas Stüfe <thomas.stuefe at gmail.com>
Send Time:2019年9月24日(星期二) 17:23
To:jdk8u-dev <jdk8u-dev at openjdk.java.net>; 董登辉(卓昂) <denghui.ddh at alibaba-inc.com>
Subject:[8u] RFR backport of JDK-8198423: Improve metaspace chunk allocation

Hi Denghui,

This is quite a large change and will be a bit of work getting into jdk8. But offhand I think JDK-8198423 should work in 8.

However, it is not the best technical solution. As you mentioned there is currently work going on for https://openjdk.java.net/jeps/8221173, which is a complete rewrite of the metaspace allocator and is quite a bit better than what we have now in 11+. There exists a prototype in the jdk-sandbox repository: http://hg.openjdk.java.net/jdk/sandbox/ , branch "stuefe-new-metaspace-branch". It is stable already and shows quite a bit of promise; in particular it is way more elastic than the current allocator. I plan to bring the new allocator down to 11 when it is done but I cannot say when that will be. My hope is to get it in for jdk15 (14 is probably too late).

So if the matter is not pressing and you can wait a bit, you may skip downporting JDK-8198423 and downport a superior solution, https://openjdk.java.net/jeps/8221173. 

(BTW, I am not sure whether 8221173 will come in the form of a JEP, there is currently a lot of confusion about what needs a JEP and what doesnt.  JDK-8198423 was supposed to be a JEP too but then I just did it as a normal RFE.)

Cheers, Thomas



> Hi all,
>   I'd like to request a backport of JDK-8198423.
>   I found some long-time running application will oom caused by metaspace if 
> the application loads / unloads classes (by different classloaders) frequently,
> even if there are many free chunks in freelist.
>   The root cause is the algorithm of metaspace allocation in 8u didn't support chunk
> split and merge, and if there is no chunk of the same size(except humongous chunk)
> as the request on the free list, the algorithm will commit more memory.
>   So i plan to backport JDK-8198423, this patch imporve metaspace chunk allocation,
> the chunks on freelist can be split and merged.
>   By the way, i also found https://openjdk.java.net/jeps/8221173, but it still be
> a draft.
> Original bug: https://bugs.openjdk.java.net/browse/JDK-8198423
> Original patch:http://hg.openjdk.java.net/jdk/jdk/rev/825f006619e5
>   This patch doesn't apply cleanly to 8u-dev, if you think this backport is reasonable,
> i will provide my webrev.
>   What's your comments? 
> 
> Thanks
> Denghui Dong 


More information about the jdk8u-dev mailing list