You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Weldon Washburn <we...@gmail.com> on 2006/11/07 18:32:59 UTC
[drlvm] vote on class unloading design (was Class unloading support - tested one approach)
All,
It looks like the debate on class unloading has concluded.
Let's vote on implementing Robin's proposal.
+1
Weldon
PS -- When class unloading gets implemented and committed is a seperate
issue.
---------- Forwarded message ----------
From: Robin Garner <ro...@anu.edu.au>
Date: Nov 2, 2006 6:16 PM
Subject: Re: [drlvm] Class unloading support - tested one approach
To: harmony-dev@incubator.apache.org
Xiao-Feng Li wrote:
> Robin, good idea.
>
> I understand the main difference between your design and Aleksey's
> proposal 1 is, the tracing in your design stops as vtable, but
> Aleksey's continues to classloader. On the other hand, your approach
> requires an extra step to sweep the vtables in order to determine the
> classloaders' reachability.
Actually there are quite a few more differences:
- This mark phase is built into the standard GC trace, like Aleksey's
automatic class unloading proposal.
- This approach requires no additional fields in headers or objects
(except maybe something to allow enumeration of vtables if this doesn't
already exist)
- The additional mark comes at an extremely low cost as discussed
previously.
The operation to sweep vtables is very cheap, and only needs to be done
when you believe there are classloaders that can be unloaded, rather
than at every GC. You might for example trigger class unloading every
time a new classloader is loaded.
> If this is true, why not just let the tracing to continue as a
> complete step to determine the classloaders' reachability?
Because that adds a large overhead to every GC, and requires vtables and
classloader structures to be traced at every GC. While the numbers of
vtables is not large, the number of pointers to them is. The particular
flavour of mark in my proposal is much cheaper than the standard test
and mark operation.
> Another difference is to mark the reachability with an unconditional
> write instead of a bit mask write. I think this can be applied to
> either approach.
Not really.
If you use an unconditional mark, you lose the ability to test whether
any particular mark is the first, and therefore enqueue an object for
scanning only once, and therefore the heap trace can never complete.
You can only use unconditional marks to process 'leaf' objects in the heap.
You can always turn a bit map into a byte map and avoid synchronized
update, but you can't eliminate the dependent load in a standard trace
algorithm. The difference in performance between a load-test-write and
a load-test-mask-write is insignificant.
Of course a separate trace of the heap is an attractive operation - in
MMTk, this is simple to build because the transitive closure code can
simply be subclassed (eg the sanity checker is ~250 lines of code).
Depending on how reusable the DRLVM heap trace code is, this may or may
not be a good option.
cheers,
Robin
> Thanks,
> xiaofeng
>
> On 11/1/06, Robin Garner <ro...@anu.edu.au> wrote:
>> Actually, just thinking about how I would implement this in JikesRVM, I
>> would use the reachability based algorithm, but piggyback on the
>> existing GC mechanisms:
>>
>> - Allocate a byte (or word) in each vtable for the purpose of tracking
>> class reachability.
>> - Periodically, at a time when no GC is running (even the most
>> aggressive concurrent GC algorithms have these, I believe), zero this
>> flag across all vtables. This is the beginning of a class-unloading
>> epoch.
>> - During each GC, when the GC is fetching the GC map for an object,
>> *unconditionally* write a value to the class reachability byte. It may
>> make sense for this byte to be in either the first cache-line of the
>> vtable, or the cache line that points to the GC map - just make sure the
>> mark operation doesn't in general fetch an additional cache line.
>> - At a point in the sufficiently far future, when all reachable objects
>> are known to have been traced by the GC, sweep the vtables and check the
>> reachability of the classloaders.
>>
>> The features of this approach are:
>>
>> - Minimal additional work at GC time. The additional write will cause
>> some additional memory traffic, but a) it's to memory that is already
>> guaranteed to be in L1 cache, and b) it's an unconditional independent
>> write, and c) multiple writes to common classes will be absorbed by the
>> write buffer.
>>
>> - Space cost of at most 1 word per vtable.
>>
>> - This works whether vtables are objects or VM structures
>>
>> - If the relationship between a class and a vtable is not 1:1, this only
>> need affect the periodic sweep process, which should be infrequent and
>> small compared to a GC.
>>
>> - shouldn't need a stop-the-world at any point.
>>
>> I've implemented and tested the GC-relevant part of this in JikesRVM,
>> and the GC time overhead appears to be just under 1% in the MMTk
>> MarkSweep collector.
>>
>> cheers,
>> Robin
>>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [drlvm] vote on class unloading design (was Class unloading support
- tested one approach)
Posted by Etienne Gagnon <eg...@sablevm.org>.
Rana Dasgupta wrote:
> It's worth a lot, since you have implemented this in SableVM yourself.
But I haven't! I was simply discussing the general design so that I
could suggest it as a term project in SableVM for my Virtual Machine
course, next term. :-)
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: [drlvm] vote on class unloading design (was Class unloading support
- tested one approach)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Robin Garner wrote:
> Weldon Washburn 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.
>>
>
> Could I also suggest that maybe the mailing list isn't the most ideal
> place to keep draft design documents ? Isn't there a wiki or some other
> web page where it could be kept and referred to ?
Does anyone ever keep design documents on a mail list?
We have wiki, website and svn. I'd suggest wiki for now until it
solidifies, and then into SVN w/ a view from the website.
geir
Re: [drlvm] vote on class unloading design (was Class unloading
support - tested one approach)
Posted by Robin Garner <ro...@anu.edu.au>.
Weldon Washburn 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.
>
Could I also suggest that maybe the mailing list isn't the most ideal
place to keep draft design documents ? Isn't there a wiki or some other
web page where it could be kept and referred to ?
--
Robin Garner
Dept. of Computer Science
Australian National University
http://cs.anu.edu.au/people/Robin.Garner/
Re: [drlvm] vote on class unloading design (was Class unloading support
- tested one approach)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Yeah, I was going to point that out this morning, but decided to let it go.
There is really nothing technical to vote on here yet. This is more of
a "poll" to get discussion going about preferred approaches, and see if
we can drive to consensus on how to move forward. So for that, it was
good that weldon kicked that off
So this is a good discussion, driving us towards an approach, but in the
end, we'll really be choosing an implementation.
That said, anyone would be free to work on alternatives if they didn't
agree with the rest of the group, but they would still need to
demonstrate why that solution was better...
geir
Rana Dasgupta 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
>>
>>
>
Re: [drlvm] vote on class unloading design (was Class unloading
support - tested one approach)
Posted by Robin Garner <ro...@anu.edu.au>.
Etienne Gagnon wrote:
> Aleksey Ignatenko wrote:
>> So the list is:
>> [...]
>> 2. per heap space/generation boolean marker on the classloader instance(
>> Etienne )
>> 3. class reachability marker byte in vtable (Robin )
>> [...]
>
> Unless Robin disagrees(?), I would say that 2 and 3 have evolved into a
> single merged proposal that comes with various minor variations for
> different collection needs: simple "stop the world" (stw), generational
> stw, concurrent, etc. You could call it the "epoch-based vtable
> marking" approach.
>
> So, that bring us back to 3.
>
> Robin: Do you agree? :-)
>
> Etienne
I agree.
--
Robin Garner
Dept. of Computer Science
Australian National University
http://cs.anu.edu.au/people/Robin.Garner/
Re: [drlvm] vote on class unloading design (was Class unloading support
- tested one approach)
Posted by Etienne Gagnon <eg...@sablevm.org>.
Aleksey Ignatenko wrote:
> So the list is:
> [...]
> 2. per heap space/generation boolean marker on the classloader instance(
> Etienne )
> 3. class reachability marker byte in vtable (Robin )
> [...]
Unless Robin disagrees(?), I would say that 2 and 3 have evolved into a
single merged proposal that comes with various minor variations for
different collection needs: simple "stop the world" (stw), generational
stw, concurrent, etc. You could call it the "epoch-based vtable
marking" approach.
So, that bring us back to 3.
Robin: Do you agree? :-)
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: [drlvm] vote on class unloading design (was Class unloading support - tested one approach)
Posted by Weldon Washburn <we...@gmail.com>.
Salikh,
I read the wiki page. Good summary. Regarding writes to the mark bit in
vtable. I think there was also conversation on cache line invalidate
traffic causing a problem on SMP. That is, the mark bit of a popular class
(like maybe String?) bouncing between caches. I recall someone suggesting a
thread-specific data struct to hold the mark bits.
On 11/10/06, Salikh Zakirov <Sa...@intel.com> wrote:
>
> 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.
>
> I've started a wiki page http://wiki.apache.org/harmony/ClassUnloading
> to summarize all discussed approaches. I hope we will eventually come
> up with the detailed end-to-end design description.
>
> I'm going now to fill in all ideas that I can pick up from the discussion,
> but I encourage all interested parties to review and correct if I get
> something incorrectly.
>
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [drlvm] vote on class unloading design (was Class unloading support
- tested one approach)
Posted by Salikh Zakirov <Sa...@Intel.com>.
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.
I've started a wiki page http://wiki.apache.org/harmony/ClassUnloading
to summarize all discussed approaches. I hope we will eventually come
up with the detailed end-to-end design description.
I'm going now to fill in all ideas that I can pick up from the discussion,
but I encourage all interested parties to review and correct if I get
something incorrectly.
Re: [drlvm] vote on class unloading design (was Class unloading support
- tested one approach)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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 <rd...@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
>>>>
>>>>
>>>
>
Re: [drlvm] vote on class unloading design (was Class unloading support
- tested one approach)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Etienne Gagnon wrote:
> Salikh Zakirov wrote:
>> Etienne Gagnon wrote:
>>> The http://wiki.apache.org/harmony/ClassUnloading wiki page is
>>> "Immutable". How can I contribute to it?
>> It is immutable for "anonymous" guests, you need to register and login somewhere.
>> All pages are editable by all registered users.
>
> Silly me! I must have missed some FM (as in RTFM) where this is written...
it's a fairly common model for wikis....
>
> Thanks,
>
> Etienne
>
Re: [drlvm] vote on class unloading design (was Class unloading support
- tested one approach)
Posted by Etienne Gagnon <eg...@sablevm.org>.
Salikh Zakirov wrote:
> Etienne Gagnon wrote:
>>The http://wiki.apache.org/harmony/ClassUnloading wiki page is
>>"Immutable". How can I contribute to it?
>
> It is immutable for "anonymous" guests, you need to register and login somewhere.
> All pages are editable by all registered users.
Silly me! I must have missed some FM (as in RTFM) where this is written...
Thanks,
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: [drlvm] vote on class unloading design (was Class unloading support
- tested one approach)
Posted by Salikh Zakirov <Sa...@Intel.com>.
Etienne Gagnon wrote:
> The http://wiki.apache.org/harmony/ClassUnloading wiki page is
> "Immutable". How can I contribute to it?
It is immutable for "anonymous" guests, you need to register and login somewhere.
All pages are editable by all registered users.
> Do I have to submit JIRA bugs? If yes, how do I make the patches? (svn
> diff?)
We use JIRA to submit code patches.
'svn diff from the root of the workspace' is a (one of) correct way to create a patch.
(Root of the workspace is one of the enhanced/drlvm/trunk, enhanced/classlib/trunk etc.)
Some hints for contributors, including patch creation, are available at
http://incubator.apache.org/harmony/get-involved.html
Re: [drlvm] vote on class unloading design (was Class unloading support
- tested one approach)
Posted by Etienne Gagnon <eg...@sablevm.org>.
The http://wiki.apache.org/harmony/ClassUnloading wiki page is
"Immutable". How can I contribute to it?
[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?)
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 <rd...@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
>> >
>> >
>>
>>
>
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: [drlvm] vote on class unloading design (was Class unloading support - tested one approach)
Posted by Aleksey Ignatenko <al...@gmail.com>.
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 <rd...@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
> >
> >
>
>
Re: [drlvm] vote on class unloading design (was Class unloading support - tested one approach)
Posted by Rana Dasgupta <rd...@gmail.com>.
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
>
>
Re: [drlvm] vote on class unloading design (was Class unloading support - tested one approach)
Posted by Weldon Washburn <we...@gmail.com>.
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 <ro...@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
Re: [drlvm] vote on class unloading design (was Class unloading
support - tested one approach)
Posted by Robin Garner <ro...@anu.edu.au>.
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
Re: [drlvm] vote on class unloading design (was Class unloading support - tested one approach)
Posted by Pavel Pervov <pm...@gmail.com>.
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.
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.
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.
With the best regards,
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
Re: [drlvm] vote on class unloading design (was Class unloading
support - tested one approach)
Posted by Robin Garner <ro...@anu.edu.au>.
My proposal is purely for the performance critical operation of marking
the classes that have live objects - as far as I'm aware, 90% of
Etienne's design still stands.
cheers
Xiao-Feng Li wrote:
> Yes, I think the discussion on class unloading is one the successful
> examples of open community in coming up with a good design and making
> design decision. Although the final design can be one person's
> proposal, but it's based on or enlightened by all the participants'
> opinions. Eitenne's proposal is a big stride over the original one.
>
> Cheers,
> xiaofeng
>
> On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
>> It's worth a lot, since you have implemented this in SableVM yourself.
>> Thanks.
>>
>> On 11/7/06, Etienne Gagnon <eg...@sablevm.org> wrote:
>> >
>> > For what it's worth, I'll add my humble +1.
>> >
>> > Etienne
>> >
>> > Xiao-Feng Li wrote:
>> > > Agreed, so plus me.
>> > >
>> > > Thanks,
>> > > xiaofeng
>> > >
>> > > On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
>> > >
>> > >> On 11/7/06, Weldon Washburn <we...@gmail.com> wrote:
>> > >> >
>> > >> > All,
>> > >> >
>> > >> > It looks like the debate on class unloading has concluded.
>> > >> >
>> > >> > Let's vote on implementing Robin's proposal.
>> > >> >
>> > >> > +1
>> > >> >
>> > >> > Weldon
>> > >> >
>> > >> > PS -- When class unloading gets implemented and committed is a
>> > seperate
>> > >> > issue.
>> > >> >
>> > >> >
>> > >> >
>> > >> > +1 I think it's the best proposal among those that were discuussed
>> > >>
>> > >>
>> > >
>> >
>> > --
>> > Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
>> > SableVM: http://www.sablevm.org/
>> > SableCC: http://www.sablecc.org/
>> >
>> >
>> >
>>
>>
--
Robin Garner
Dept. of Computer Science
Australian National University
Re: [drlvm] vote on class unloading design (was Class unloading support - tested one approach)
Posted by Xiao-Feng Li <xi...@gmail.com>.
Yes, I think the discussion on class unloading is one the successful
examples of open community in coming up with a good design and making
design decision. Although the final design can be one person's
proposal, but it's based on or enlightened by all the participants'
opinions. Eitenne's proposal is a big stride over the original one.
Cheers,
xiaofeng
On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
> It's worth a lot, since you have implemented this in SableVM yourself.
> Thanks.
>
> On 11/7/06, Etienne Gagnon <eg...@sablevm.org> wrote:
> >
> > For what it's worth, I'll add my humble +1.
> >
> > Etienne
> >
> > Xiao-Feng Li wrote:
> > > Agreed, so plus me.
> > >
> > > Thanks,
> > > xiaofeng
> > >
> > > On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
> > >
> > >> On 11/7/06, Weldon Washburn <we...@gmail.com> wrote:
> > >> >
> > >> > All,
> > >> >
> > >> > It looks like the debate on class unloading has concluded.
> > >> >
> > >> > Let's vote on implementing Robin's proposal.
> > >> >
> > >> > +1
> > >> >
> > >> > Weldon
> > >> >
> > >> > PS -- When class unloading gets implemented and committed is a
> > seperate
> > >> > issue.
> > >> >
> > >> >
> > >> >
> > >> > +1 I think it's the best proposal among those that were discuussed
> > >>
> > >>
> > >
> >
> > --
> > Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
> > SableVM: http://www.sablevm.org/
> > SableCC: http://www.sablecc.org/
> >
> >
> >
>
>
Re: [drlvm] vote on class unloading design (was Class unloading support - tested one approach)
Posted by Rana Dasgupta <rd...@gmail.com>.
It's worth a lot, since you have implemented this in SableVM yourself.
Thanks.
On 11/7/06, Etienne Gagnon <eg...@sablevm.org> wrote:
>
> For what it's worth, I'll add my humble +1.
>
> Etienne
>
> Xiao-Feng Li wrote:
> > Agreed, so plus me.
> >
> > Thanks,
> > xiaofeng
> >
> > On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
> >
> >> On 11/7/06, Weldon Washburn <we...@gmail.com> wrote:
> >> >
> >> > All,
> >> >
> >> > It looks like the debate on class unloading has concluded.
> >> >
> >> > Let's vote on implementing Robin's proposal.
> >> >
> >> > +1
> >> >
> >> > Weldon
> >> >
> >> > PS -- When class unloading gets implemented and committed is a
> seperate
> >> > issue.
> >> >
> >> >
> >> >
> >> > +1 I think it's the best proposal among those that were discuussed
> >>
> >>
> >
>
> --
> Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
> SableVM: http://www.sablevm.org/
> SableCC: http://www.sablecc.org/
>
>
>
Re: [drlvm] vote on class unloading design (was Class unloading support
- tested one approach)
Posted by Etienne Gagnon <eg...@sablevm.org>.
For what it's worth, I'll add my humble +1.
Etienne
Xiao-Feng Li wrote:
> Agreed, so plus me.
>
> Thanks,
> xiaofeng
>
> On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
>
>> On 11/7/06, Weldon Washburn <we...@gmail.com> wrote:
>> >
>> > All,
>> >
>> > It looks like the debate on class unloading has concluded.
>> >
>> > Let's vote on implementing Robin's proposal.
>> >
>> > +1
>> >
>> > Weldon
>> >
>> > PS -- When class unloading gets implemented and committed is a seperate
>> > issue.
>> >
>> >
>> >
>> > +1 I think it's the best proposal among those that were discuussed
>>
>>
>
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: [drlvm] vote on class unloading design (was Class unloading support - tested one approach)
Posted by Xiao-Feng Li <xi...@gmail.com>.
Agreed, so plus me.
Thanks,
xiaofeng
On 11/8/06, Rana Dasgupta <rd...@gmail.com> wrote:
> On 11/7/06, Weldon Washburn <we...@gmail.com> wrote:
> >
> > All,
> >
> > It looks like the debate on class unloading has concluded.
> >
> > Let's vote on implementing Robin's proposal.
> >
> > +1
> >
> > Weldon
> >
> > PS -- When class unloading gets implemented and committed is a seperate
> > issue.
> >
> >
> >
> > +1 I think it's the best proposal among those that were discuussed
>
>
Re: [drlvm] vote on class unloading design (was Class unloading support - tested one approach)
Posted by Rana Dasgupta <rd...@gmail.com>.
On 11/7/06, Weldon Washburn <we...@gmail.com> wrote:
>
> All,
>
> It looks like the debate on class unloading has concluded.
>
> Let's vote on implementing Robin's proposal.
>
> +1
>
> Weldon
>
> PS -- When class unloading gets implemented and committed is a seperate
> issue.
>
>
>
> +1 I think it's the best proposal among those that were discuussed