RFR(S) 8189688: NMT: Report per-class load metadata information

[Andrew Dinn]

On 23/10/17 15:40, Thomas Stüfe wrote:
> Okay. So this is important for understanding cases where we have a large
> number of miniscule class loaders, each one only having a few numbers of
> chunks. In this case, would it be useful to have a running total of "free"
> and "waste", too? Or even better, also average and peak values of "free"
> and "waste" (to tell apart cases where you have one outlier vs cases where
> just all metaspaces waste a lot of memory).
> 
> Just out of curiosity, I looked at
> http://cr.openjdk.java.net/~zgu/cld_metaspace/wildfly.txt  and it seems
> that "free" is the problem, not "waste"? So I guess what happens is that
> all the little classloaders allocate just enough memory to push them over
> "_small_chunk_limit=4", so they allocate the first medium chunk, from which
> then they take a small bite and leave the rest laying around?

Yes, that is pretty how it works. Only the problem is twice as bad when
you have separate class metadata and non-class metadata (i.e. when using
compressed class oops which is by far the most common case) since this
invariably wastes more space.

Similar behaviour happens when an anonymous class is created because of
a lambda, except that you only get one small allocation before a medium
chunk is created. So, for small lambdas, you almost always end up using
around 50% of 2 1MB chunks and, for more complex lambdas, around 50% of
a 1MB chunk plus less than 50% of a 1MB + 4MB chunk. So, the space waste
for lambdas is really quite spectacular.

regards,


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