RFR: 8210233: Prepare Klass::is_loader_alive() for concurrent class unloading

Per Liden per.liden at oracle.com
Mon Sep 10 10:20:17 UTC 2018


Hi Erik,

On 09/04/2018 10:14 AM, Erik Österlund wrote:
> Hi Kim,
> 
> Thank you for the review.
> 
> Incremental:
> http://cr.openjdk.java.net/~eosterlund/8210233/webrev.01_02/
> 
> Full:
> http://cr.openjdk.java.net/~eosterlund/8210233/webrev.02/

Looks good to me.

/Per

> 
> On 2018-09-04 05:51, Kim Barrett wrote:
>>> On Sep 3, 2018, at 11:25 AM, Erik Österlund 
>>> <erik.osterlund at oracle.com> wrote:
>>>
>>> Hi Kim,
>>>
>>> You are right. Thank you for catching that.
>>>
>>> Incremental:
>>> http://cr.openjdk.java.net/~eosterlund/8210233/webrev.00_01/
>>>
>>> Full:
>>> http://cr.openjdk.java.net/~eosterlund/8210233/webrev.01/
>>>
>>> Thank you for the review.
>> The comments I was referring to were these:
>>
>> is_loader_alive in klass.hpp
>> 657   // Iff the class loader (or mirror for unsafe anonymous classes) 
>> is alive the
>> 658   // Klass is considered alive.  Has already been marked as 
>> unloading.
> 
> Fixed.
> 
>> classLoaderHierarchyDCmd.cpp
>> 471     // We do not display unloading loaders, for now.
>>
>> I'm once again finding myself confused about the relationship between
>> alive or not and unloading or not. Is the second sentence of the
>> comment for is_loader_alive even true now?
> 
> To me, the term "unloading" refers to a conceptual state the CLD is in 
> from when the marking terminates and the CLD holder is dead, to when it 
> is finally deleted (despite having to go through a number of operations 
> to get there, like (sometimes) reference processing, setting CLD state 
> to _unloading (which is merely a cache for this liveness information), 
> unlinking and deleting.
> 
> So I think the comment looks good (to me), but understand if there are 
> other interpretations by others reading it. Perhaps if we removed the 
> _unloading state altogether, things would be less confusing. It is only 
> a cache of !is_alive(), and its existence builds on the premise that 
> performing a phantom load on the CLD holder is expensive, and that it is 
> therefore worth caching if the result is NULL or not. But I do not think 
> that optimization gives us much. It does however constrain the order in 
> which you can do things, which can be problematic and confusing. But 
> that feels like a separate RFE.
> 
>> The new comment for is_alive is fine.
>>
>> In the new comment for is_unloading, the use of "unloaded" is
>> confusing me.  Is that a typo for "unloading", or am I confused?
> 
> That was a typo indeed. It is fixed now.
> 
>> I think I need to retract my review; I think I need to refresh and
>> de-confuse my understanding of this area.  Don't wait for me if you
>> get a second okay from someone else.
> 
> No worries Kim, there is no rush with this one.
> 
> Thanks,
> /Erik
> 


More information about the hotspot-runtime-dev mailing list