Any new ideas on JDK-8187338 (Per anonymous class class loader data is costly)?

[Claes Redestad]

Hi,

while non-intrusive and easily attainable improvements to reduce class 
loader metadata is surely welcome, I think the high-level idea is to 
remove the overhead entirely  Isolated Methods, see draft JEP: 
https://bugs.openjdk.java.net/browse/JDK-8158765

Thanks!

/Claes

On 2017-11-23 12:56, Thomas Stüfe wrote:
> Hi Zhengyu and Andrew,
>
> Have you had any new ideas on how to deal with
> https://bugs.openjdk.java.net/browse/JDK-8187338?
>
> I also see this in my tests and I think this will be an issue with our
> customers.
>
> My thoughts are
>
> 1) as a first workaround to provide a threshold switch to change the
> small-chunk-limit - the number of bytes a class loader has to allocate from
> metaspace and classpace to qualify for medium sized chunks. With such a
> switch, one could at least tune a system which shows a pathological
> allocation pattern. E.g., using Zhengyu's new NMT per-classloader trace, if
> I see that the majority of all class loaders stop allocating after 500K,
> I'd set the threshold to 500K.
>
> 2) Future better solutions could involve some kind of self-regulating
> mechanism: Somehow automatically identifying which are "tiny" class loaders
> - loaders which have with a certain probability stopped allocoating while
> still gnawing at their first or second medium chunk. And then, using that
> number, dynamically adjusting the small-chunk-limit for future class
> loaders.
>
> (1) could be quite easily implemented. What do you think?
>
> Kind Regards, Thomas