Review Request: Add ClassOption.STRONG and default is unspecified

[Mandy Chung]

The javadoc is updated per offline discussion with Alex.
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/weak-strong-class/

I pushed this version to the sandbox to get the new ClassOption::STRONG 
in.  We can continue to improve the javadoc per any feedback.

Mandy

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 
>> `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