Question about JEP 371 and unloading Lambdas

[Mandy Chung]

Hi Thomas,

Thanks for the data and confirmation.

On 6/9/20 11:19 PM, Thomas Stüfe wrote:
>
> :
>
> A reduction in waste from 22% to 4%, mainly due to reduced leftover 
> space in half-eaten chunks. Usage drops from 86M->69M.
> But the saved memory is only part of the story. We save a lot of 
> overhead too, e.g. less CLDs so smaller CLDG. Also we save storage for 
> the CLDs. Also less time spent inside Metaspace critical sections.

Thanks for doing the measurement and analysis.  The overhead is reduced 
from 3.74MB to 86.38KB because we no longer create 
per-VM-anonymous-class CLD.

>
> This is a good thing :) Swarms of anonymous classes have always been 
> an annoyance for Metaspace since as an arena based allocator 
> 1-class-loaders are not exactly its strong side. This has never been a 
> really pressing problem for me since the total waste was usually 
> lowish. But it is nice to see this gone anyway.
>
> I have two followup questions:
>
> - I do not understand how exactly this relates to Hidden Classes. 
> Could we have had this improvement before, by allocating metaspace for 
> anonymous classes for lambda proxies via the CLD of the target class? 
> I ask this because I want to understand if we can bring this 
> improvement into older releases, independent from Hidden Classes.

JDK-8239384 [1] gives you the context what changes are made in 
LambdaMetafactory implementation to use hidden class (see JEP 371). Here 
is a short version:

VM anonymous classes are all weakly linked with their defining loaders 
to allow them going away when it's unused independent of the lifecycle 
of its defining loader.  There is no support for VM anonymous classes to 
be strongly linked with their defining loader.

JEP 371 defines the `Lookup::defineHiddenClass` API to define a hidden 
class which is weakly linked with its defining loader as the default and 
a ClassOption::STRONG [2] can be specified to keep the hidden class 
strongly linked with its defining loader.    Lambda proxy
class is defined by calling Lookup::defineHiddenClass with 
ClassOption::STRONG option.

Hidden classes are Java SE feature that cannot be backport to older 
releases.

>
> - When I was looking at Lambdas, I really was looking for an example 
> case with many Hidden Classes whose life time should be quasi random 
> and not bound to a single class loader. What you describe in the JEP 
> text under unloading. I wanted to look at what this does with 
> Metaspace. But Lambdas are a bad example for that, since their 
> lifetimes are still synchronized with that of the target class. Is 
> there another example or test case for short-lived Hidden Classes?

You could create a benchmark simply calling `Lookup::defineHiddenClass` 
to define many hidden classes with and without STRONG option to compare 
the metaspace usage.

Hope this helps
Mandy

[1] 
https://download.java.net/java/early_access/jdk15/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.ClassOption.html#STRONG

[2] 
https://bugs.openjdk.java.net/browse/JDK-8239384?focusedCommentId=14326140&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14326140