Review Request: Add ClassOption.STRONG and default is unspecified
mandy.chung at oracle.com
Tue Mar 17 20:41:43 UTC 2020
The javadoc is updated per offline discussion with Alex.
I pushed this version to the sandbox to get the new ClassOption::STRONG
in. We can continue to improve the javadoc per any feedback.
On 3/13/20 4:28 PM, Alex Buckley wrote:
> On 3/13/2020 3:37 PM, Mandy Chung wrote:
>> Please take a look the `Lookup::defineHiddenClass` spec and
> 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."
More information about the valhalla-dev