Weak references to hidden classes - should be the default?
Mandy Chung
mandy.chung at oracle.com
Tue Mar 10 23:55:43 UTC 2020
Brian, John, et al,
Alex has given his feedback on the weak class feature (attached).
Alex recommends to change the default of hidden classes be weak classes
and introduce a ClassOption::STRONG option if it wants to ensure that
the hidden class is not being reclaimed until the class loader becomes
unreachable. See more details below.
We tried to keep a hidden class be a normal class from JVM's point of
view. Classes in the VM implementation have the same lifecycle as the
defining class loader. In addition, LambdaForms and Nashorn are the
only JDK use of hidden weak classes. All others such as lambda
metafactory and string concat use hidden (strong) classes as they are
part of the target class' internal implementation and should be unloaded
altogether. Hence strong reference to hidden classes is the default.
What's your recommendation?
Mandy
-------- Forwarded Message --------
Subject: Weak references to hidden classes
Date: Tue, 10 Mar 2020 16:16:50 -0700
From: Alex Buckley <alex.buckley at oracle.com>
Organization: Oracle Corporation
To: Mandy Chung <mandy.chung at oracle.com>
JEP 371 says that a hidden class may be weakly referenced by its class
loader. Which loader? The only loader with any connection to a hidden
class is the loader nominated to serve as the defining loader by the API
spec of defineHiddenClass. However, that spec doesn't say "The defining
loader holds a strong reference to the hidden class" because no spec
says anything about how a class loader refers to a class.
(The only relationship we do specify is the other way around --
ClassLoader says "Every Class object contains a reference to the
ClassLoader that defined it." -- and happily that relationship holds for
a hidden class too.)
Point is, it's odd for defineHiddenClass to standardize how a class
loader refers to a hidden class when, conceptually, class loaders are
not meant to "know" about hidden classes.
(The connection between a defining loader and a hidden class is a mere
accounting trick done to support the hidden class's own code. No class
loader, not even that defining loader, knows how to respond to a class
load request for the hidden class.)
It's especially odd for defineHiddenClass's default to be a strong
reference. That default aligns with ClassLoader::defineClass, the API
we're trying to avoid, and doesn't align with
Unsafe::defineAnonymousClass, the API we're trying to recreate!
I understand there are performance reasons to want a loader to use a
strong reference rather than a weak reference. Accepting that claim, I
recommend having the implementation use a weak reference by default,
having the spec allow that, then introducing ClassOption.STRONG to force
a strong reference. That is, specify that:
"In the absence of an option, the defining loader's relationship with
the hidden class is unspecified, and the loader implementation may use a
strong reference or a weak reference to keep track of the hidden class.
If a hidden class is not strongly referenced by the class loader which
is deemed to be its defining loader, then the hidden class can be
unloaded when library code no longer refers to it. Library developers
who wish to prevent the hidden class from being unloaded must ensure
that its Class object is never reclaimed, or else use the
ClassOption.STRONG option."
I understand there is a concern that developers would not realize / be
surprised by getting a weak reference as the default implementation.
However, the planet-wide audience for defineHiddenClass is perhaps 500
developers. They already have to know what they're doing because the
features of hidden classes are already more limited than the features of
VM-anonymous classes., e.g., no constant pool patching. The usual "Java
should save developers from making silly mistakes" rule doesn't apply here.
Alex
More information about the valhalla-dev
mailing list