Review Request: Add ClassOption.STRONG and default is unspecified
Alex Buckley
alex.buckley at oracle.com
Fri Mar 13 23:28:39 UTC 2020
On 3/13/2020 3:37 PM, Mandy Chung wrote:
> Please take a look the `Lookup::defineHiddenClass` spec and `ClassOption`:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/weak-strong-class/
We're really writing the JEP here. The API spec should just follow that,
with sentences taken out so it boils down to one paragraph.
Speak about the "relationship" concept only at the top and bottom of the
paragraph, not in the middle where technical statements about
reachability and reclaiming exist. Plus, don't start with the behavior
embodied by STRONG -- we believe that weak is the natural state of
hidden classes. Plus, I want to hold off from saying "loose" if possible
-- usually I'm the person demanding that terminology completely covers
the design space, but right now I want to leave room for us to spin up
text about "weak relationship that may or may not imply weak references".
Start by saying "Every class created by a class loader has a strong
relationship with that class loader. That is, every `Class` object
contains a `reference` to the `ClassLoader` that [defined it](LINK TO
CLASS::GETCLASSLOADER). This means that a class created by a class
loader may be unloaded if and only if its defining loader is not
reachable and thus may be reclaimed by a garbage collector (JLS 12.7)."
Continuing: "By default, however, a hidden class may be unloaded even if
the class loader that is marked as its defining loader is reachable.
This allows <<text heavily paraphrased from John's mail about "go dead
as soon as the last client drops a reference to them" -- this text will
not be easy to write, but it belongs here -- also there used to be text
about libraries who use WEAK needing to take care of their Class objects>>.
Continuing: "In cases where <<durable references / permanently installed
is important>>, the `STRONG` option may be passed in `options`. This
arranges for a hidden class or interface to have the same relationship
with the class loader marked as its defining loader, as a normal class
or interface has with its own defining loader."
Finally: "[A rule about independence of HCs from each other:] The
unloading characteristics are set for each hidden class when it is
defined, and cannot be changed later. [A note about independence of HCs
from CLs] An advantage of allowing hidden classes to be unloaded
independently of the loader deemed as their defining loader is that a
very large number of hidden classes may be created by an application. In
contrast, if STRONG is used, then the JVM may run out of memory, just as
if normal classes were created by class loaders."
Alex
More information about the valhalla-dev
mailing list