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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] > 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 < [EMAIL PROTECTED] > 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
