Question about JEP 371 and unloading Lambdas
mandy.chung at oracle.com
Wed Jun 10 17:39:09 UTC 2020
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
> 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  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  can be specified to keep the hidden class
strongly linked with its defining loader. Lambda proxy
class is defined by calling Lookup::defineHiddenClass with
Hidden classes are Java SE feature that cannot be backport to older
> - 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
More information about the hotspot-runtime-dev