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

[Mandy Chung]

On 10/1/19 3:24 PM, David Holmes wrote:
> 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.
>

Right.

If a weak class HC1 is being strongly reachable by another class HC2, 
the drawback is that it keeps HC1's lifetime longer until HC2 is 
unreachable.

Mandy