Nest host validation vs NestHost attribute performed by Lookup::defineHiddenClass

[David Holmes]

Hi Peter,

On 2/10/2019 7:55 am, Peter Levart wrote:
> On 10/1/19 8:04 PM, Mandy Chung wrote:
>>
>>
>> On 10/1/19 3:11 AM, Peter Levart wrote:
>>> Imagine a situation where a hidden class HC1 is defined in it's own 
>>> nest. Then this HC1 is used as a LC in a Lookup to define another 
>>> hidden class HC2 to be part of this nest (HC1, HC2). What should 
>>> HC2.getNestHost() return? If it returns HC1, then HC2 is effectively 
>>> preventing HC1 to be unloaded.
>>>
>>
>> There is no restriction what a hidden class can call, for example, 
>> using lambda or method reference, which may call a framework library 
>> to generate HC2.  HC1 and HC2 should be unloaded when both classes 
>> become unreachable.   Do I miss the issue you tried to point out?
> 
> I was trying to point out that a hidden class added to a nest that has a 
> hidden nest host class will retain the nest host class (in order to be 
> able to return it from getNestHost() method). Which may not be desirable.

I see this as no different to any other case where a strong reference is 
kept to something that is only weakly referenced elsewhere. The "weak" 
aspect only relates to the relationship between the defining classloader 
and the class, it doesn't imply that every use of the class must itself 
be weak.

Cheers,
David
-----

>>
>> (Note that defineHiddenClass takes an enum constant to specify if the 
>> hidden is a dynamic nestmate and/or a weak class to specify if it's 
>> weakly referenced by the class loader.  In other words, a dynamic 
>> nestmate has the same lifecycle as its defining class loader if not 
>> specified weak.)
> 
> Ok, so suppose the 1st hidden class HC1 is defined in its own nest and 
> specified to be weak. Then another hidden class HC2 is defined to be 
> part of the same nest, this time specified to not be weak (to be 
> retained by the classloader). Because HC2.getNestHost() returns HC1, HC1 
> is now "trapped" too, since it has to be retained by the HC2 class to be 
> returned by HC2.getNestHost() and therefore can't be unloaded until HC2 
> can be.
> 
> I'm questioning the purpose of multi member nests composed solely of 
> hidden classes. Being part of nest means that you can access private 
> members of other nestmates, but how do you access a private member of a 
> hidden class from another class if you can not refer to the hidden class 
> symbolically? You could perhaps use reflection or MH.Lookup to obtain 
> direct MHs. Is that an important usecase?
> 
> Regards, Peter
> 
>>
>> Mandy
>