Review Request: Add ClassOption.STRONG and default is unspecified

[Mandy Chung]

Thanks Alex.  I updated the javadoc per your feedback.

Webrev updated in place (please reload):
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/weak-strong-class/

Adding to the "unspecified" default discussion, LambdaMetaFactory and 
StringConcatFactory want the performant default and they didn't ask for 
strong or weak while in practice the resolved BSM callsite will keep the 
hidden class alive.

My comment inlined below.

Mandy

On 3/11/20 4:22 PM, Alex Buckley wrote:
> (Responding even though the enum constants are slightly up in the air, 
> because ultimately we need to be able to characterize unloading of a 
> hidden class independently of loader implementation.)
>
> I like how the first paragraph sidesteps how the loader implementation 
> refers to the hidden class. However, the second paragraph needs to 
> keep up the good work when no option is given.
>
> -----
> ***Unloading of the newly created class or interface {@code C} may be 
> controlled via the {@link ClassOption#WEAK WEAK} and {@link 
> ClassOption#STRONG STRONG} options.*** If {@code options} has the 
> {@code WEAK} option, then {@code C} may be unloaded when it [DO WE 
> MEAN ITS CLASS OBJECT?] 

Yes
> becomes unreachable and is ~~~being~~~ reclaimed by the garbage 
> collector***,*** regardless of the <a 
> href="../ref/package.html#reachability">reachability</a> state of 
> {@code C}'s defining class loader. If {@code options} has ***the*** 
> {@code STRONG} option, then {@code C} is guaranteed not to be unloaded 
> when its defining class loader is strongly reachable.
>
> At most one of the options {@code WEAK} and {@code STRONG} may be 
> given. If neither is given, then the relationship between the defining 
> loader's reachability and the hidden class's unloading is unspecified. 
> In this case, the loader implementation [now we can talk about 
> references] may use a strong ...
> -----
>
>
> BTW, the items which determine the nest host of C in the NESTMATE case 
> should look like this: (note the ol):
>
> -----
> <ol>
>
> <li>If the nest host of the lookup class of this {@code Lookup} has 
> previously been determined, then ***let*** {@code H} be the nest host 
> of the lookup class. Otherwise, the nest host of the lookup class is 
> determined using the algorithm in JVMS 5.4.4, yielding {@code H}.</li>
>
> <li>The nest host of {@code C} is determined to be {@code H}, the nest 
> host of the lookup class.</li>
>
> </ol>
> -----
>
> Alex
>