harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm] vote on class unloading design (was Class unloading support - tested one approach)
Date Fri, 10 Nov 2006 15:30:03 GMT


Etienne Gagnon wrote:
> The http://wiki.apache.org/harmony/ClassUnloading wiki page is
> "Immutable".  How can I contribute to it?

Do you have a login to the wiki?

> 
> [Among other things, I'd like to add that the design can also
> potentially apply to SableVM and , and make other suggestions / changes.]
> 
> Do I have to submit JIRA bugs?  If yes, how do I make the patches? (svn
> diff?)

svn diff please :)

> 
> Thanks for helping me!
> Etienne
> 
> Aleksey Ignatenko wrote:
>> Actually there is one additional 4-th approach:
>>
>> *Mark and scan based approach *wich I described in the first letter. Java
>> heap trace is performed by VM Core and GC is not affected at all.
>>
>> So the list is:
>> 1. vtable objects( Aleksey )
>> 2. per heap space/generation boolean marker on the classloader instance(
>> Etienne )
>> 3. class reachability marker byte in vtable (Robin )
>> 4. Mark and scan based approach.
>>
>> I agree that we need to structure all appraches somehow, like description
>> for every approach in wiki.
>>
>> Aleksey.
>>
>> On 11/10/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
>>
>>> Identifying an end to end alogirithm is of course necessary, and the
>>> discussions on the other thread are great. But what were we voting on
>>> here?
>>> My understanding was that we were voting on the approach of using:
>>>
>>> 1. vtable objects( Aleksey )
>>> 2. per heap space/generation boolean marker on the classloader instance(
>>> Etienne )
>>> 3. class reachability marker byte in vtable (Robin )
>>>
>>> and not on three end-to-end algorithms since Robin's description was not
>>> one. I am OK if we now want to cancel the vote, but next time we vote
>>> on a
>>> technical issue it may be a good idea for the caller to summarize the
>>> contending solutions on the thread and then call for the vote.
>>>
>>> Thanks,
>>> Rana
>>>
>>> On 11/9/06, Weldon Washburn <weldonwjw@gmail.com > wrote:
>>>> It looks like I called for a vote too soon.  The continuing discussion
>>> on
>>>> class unloading design is uncovering many important issues.  This is
>>>> excellent as it is much better to deal with design issues at this stage
>>>> rather than during implementation.
>>>>
>>>> I propose the following:
>>>>
>>>> 1)
>>>> Cancel the current vote on design.
>>>>
>>>> 2)
>>>> Someone put together a complete class unloading design based on
>>>> Etienne/Robin's approach.  Include pseudo code and post to harmony-dev.
>>>>
>>>> 3)
>>>> We call for a new vote once the comments on the documented design
>>> indicate
>>>> it is ready.
>>>>
>>>>
>>>> On 11/8/06, Robin Garner < robin.garner@anu.edu.au > wrote:
>>>>> Pavel Pervov wrote:
>>>>>> Really BIG -1 from me.
>>>>>>
>>>>>> As Aleksey (Ignatenko) described in original thread, j/l/Class'es
>>> and
>>>>>> j/l/ClassLoader's are always available in rootset, so even if no
>>>> objects
>>>>>> of a class exist, this class will be reachable.
>>>>>>
>>>>>> Actually, some sort of class unloading prototype exists in DRLVM
>>> code,
>>>>>> which
>>>>>> implements the scheme, which is very close to what is currently
>>> voted.
>>>>> It
>>>>>> was integrated with GC v4 and is not supported by other GCs. This
>>>>> prototype
>>>>>> traces up to class loader. Robin's approach is way faster then
>>>> prorotype
>>>>>> is.
>>>>>>
>>>>>> Unfortunately, that approach requires up to 3 GC cycles to complete
>>> in
>>>>>> DRLVM.
>>>>> In a full-heap STW collector, my proposal would require 1 GC to
>>> collect
>>>>> unused classloaders.  In a generational STW collector, 1 full-heap
>>> GC,
>>>>> and would depend on the particular invariants enforced by an
>>>>> incremental/concurrent collector, but would be 1 complete "cycle" of
>>> any
>>>>> of the standard algorithms (I guess up to 3 GCs if the sweeps
>>> happened
>>>>> at the wrong places).
>>>>>
>>>>>> BTW, voted approach does not describe "proof-of-full-collection"
>>>>> algorithm
>>>>>> (at least I didn't find one). The only one I think of is
>>>>>> full-heap-collection, which _requires_ STW.
>>>>> My approach simply requires the underlying collector to have a notion
>>>>> that periodically it can say that 'every reachable object allocated
>>>>> since time 't' is now marked reachable.  If the class-unloader can
>>>>> ensure that one full epoch of this invariant has passed, then it can
>>>>> safely perform unloading.
>>>>>
>>>>>> Although "automatic anloading" brings some additional requirements
>>> for
>>>>> GC
>>>>>> (weak roots (references) support and pinned allocation), it is
>>> proven
>>>> to
>>>>>> work (patch available) and, also, is the most natural algorithm for
>>>>> DRLVM.
>>>>>
>>>>> What is the run-time cost of it ?  And where is it described ?  I was
>>>>> only aware of Etienne's proposal as a full class-unloading scheme.
>>>>>
>>>>>> With the best regards,
>>>>>
>>>>> --
>>>>> Robin Garner
>>>>> Dept. of Computer Science
>>>>> Australian National University
>>>>>
>>>>
>>>>
>>>> --
>>>> Weldon Washburn
>>>> Intel Enterprise Solutions Software Division
>>>>
>>>>
>>>
> 

Mime
View raw message