[snip]
My proposal has been measured at ~1% overhead in GC time, or 0.1% in
execution time (caveats as above). If there is some complexity in
establishing classloader reachability from this basis, I would assume it
can easliy be absorbed.
Sorry if it was already discussed, but I
Etienne Gagnon wrote:
Alexey Varlamov wrote:
Sorry if it was already discussed, but I believe this approach also
requires marking vtable bit/byte on each object allocation, unitl the
unloading GC pass is strictly stop-the-world full-heap collection.
Robin, did you include this particular
Robin Garner wrote:
Etienne Gagnon wrote:
3- Why would it be so hard to add an unconditional write operation
during collection (e.g. during copying or marking of an object) in
drlvm? A detailed technical explanation is welcome. :-)
I actually believe that this should be implementable in a
Salikh Zakirov wrote:
Technically, it should not be too difficult to add an additional field to the
VTable
structure, and require GC to write 1 there during object scanning.
However, if the VTable mark is located in the same cache line as gcmap,
it may severely hit parallel GC performance on
Alexey Varlamov wrote:
2006/11/9, Robin Garner [EMAIL PROTECTED]:
Etienne Gagnon wrote:
Alexey Varlamov wrote:
Sorry if it was already discussed, but I believe this approach also
requires marking vtable bit/byte on each object allocation, unitl the
unloading GC pass is strictly
OK. My latest proposal (a few messages ago) was assuming that the
nursery was empty when the end of epoch collection is launched.
If it is not, you can do 2 things:
a) do a minor collection to empty it, or
b) i - use a finalization-like list of references to class loader
Etienne Gagnon wrote:
My proposal already argued that vtable bit/byte/word marking is
unnecessary for nursery allocations. You only need to mark the
vtable
of objects that survive collection and pretenured objects.
Alexey Varlamov wrote:
I may have missed it, but I only recall you
Etienne Gagnon wrote:
OK. My latest proposal (a few messages ago) was assuming that the
nursery was empty when the end of epoch collection is launched.
If it is not, you can do 2 things:
a) do a minor collection to empty it, or
b) i - use a finalization-like list of references to class
Salikh Zakirov wrote:
I have another concern though:
just before starting final unloading collection, we scan vtable marks and
identify
the candidates for unloading. During the final unloading collection, the
candidate classloader roots are reported as week. At the end of the trace,
we
Etienne Gagnon wrote:
Salikh Zakirov wrote:
I have another concern though:
just before starting final unloading collection, we scan vtable marks and
identify
the candidates for unloading. During the final unloading collection, the
candidate classloader roots are reported as week. At the end
Etienne Gagnon wrote:
Revival is only needed if you use the finalization-like approach. If
you only do class-unloading GC when the nursery is empty, then no
revival is needed.
Ah, I think I got it.
You mean running a minor collection, and then class unloading full heap
collection
Salikh Zakirov wrote:
Ah, I think I got it.
Yep.
3) trace the heap
4) scan vtable marks and revive marked class unloaders, by adding the
strong root
from the previously collected unload list. Remove the revived
classloaders from unload list.
5) repeat steps (3) and (4) until
On 11/9/06, Etienne Gagnon [EMAIL PROTECTED] wrote:
Salikh Zakirov wrote:
Technically, it should not be too difficult to add an additional field to the
VTable
structure, and require GC to write 1 there during object scanning.
However, if the VTable mark is located in the same cache line as
Ivan Volosyuk wrote:
We will get rid of false sharing. That's true. But it still be quite
expensive to write those '1' values, because of ping-ponging of the
cache line between processors. I see only one solution to this: use
separate mark bits in vtable per GC thread which should reside in
Etienne Gagnon wrote:
3) trace the heap
4) scan vtable marks and revive marked class unloaders, by adding the
strong root
from the previously collected unload list. Remove the revived
classloaders from unload list.
5) repeat steps (3) and (4) until there is no classloaders to
Salikh Zakirov wrote:
7) let the GC finish collection and reclaim unreachable objects -- this
reclaims java objects
Just a bit of a warning... This should be integrated within the
weak/soft/phantom + finalization framework. We definitely don't want
the native resources of a class loader to
Ivan Volosyuk wrote:
We will get rid of false sharing. That's true. But it still be quite
expensive to write those '1' values, because of ping-ponging of the
cache line between processors. I see only one solution to this: use
separate mark bits in vtable per GC thread which should reside in
Etienne Gagnon wrote:
Ivan Volosyuk wrote:
We will get rid of false sharing. That's true. But it still be quite
expensive to write those '1' values, because of ping-ponging of the
cache line between processors. I see only one solution to this: use
separate mark bits in vtable per GC thread
Etienne Gagnon wrote:
Salikh Zakirov wrote:
7) let the GC finish collection and reclaim unreachable objects -- this
reclaims java objects
Just a bit of a warning... This should be integrated within the
weak/soft/phantom + finalization framework. We definitely don't want
the native
On 11/9/06, Etienne Gagnon [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
We will get rid of false sharing. That's true. But it still be quite
expensive to write those '1' values, because of ping-ponging of the
cache line between processors. I see only one solution to this: use
separate mark
Ivan Volosyuk wrote:
On 11/9/06, Etienne Gagnon [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
We will get rid of false sharing. That's true. But it still be quite
expensive to write those '1' values, because of ping-ponging of the
cache line between processors. I see only one solution to
[snip]
Alexey,
it looks like what you are thinking about is *concurrent* collector,
and concurrent garbage collections brings substantial complexity
even without class unloading.
Salikh,
You are correct. Maybe I'm running ahead of the train, but my concern
is that scalability of unloading
Aleksey Ignatenko wrote:
Hi, Robin.
I do really like this proposed idea of marking VTables from objects via
additional word field in VTable.
But I have one question about detecting reachability of the classloaders
(sweep the vtables and check the reachability of the classloaders).
Possibly I
Robin,
The kind of model I had in mind was along the lines of:
- VM maintains a linked list (or other collection type) of the currently
loaded classloaders, each of which in turn maintains the collection of
classes loaded by that type. The sweep of classloaders goes something
like:
for
Robin.
OK, well how about keeping a weak reference to the j.l.ClassLoader
object instead of a strong one. When the reference becomes (strong)ly
unreachable, invoke the class-unloading phase.
If you have weak reference to j.l.Classloader - GC will collect it (with all
appropriate jlClasses)
Aleksey Ignatenko wrote:
Robin.
OK, well how about keeping a weak reference to the j.l.ClassLoader
object instead of a strong one. When the reference becomes (strong)ly
unreachable, invoke the class-unloading phase.
If you have weak reference to j.l.Classloader - GC will collect it (with
Robin Garner wrote:
Aleksey Ignatenko wrote:
Robin.
OK, well how about keeping a weak reference to the j.l.ClassLoader
object instead of a strong one. When the reference becomes (strong)ly
unreachable, invoke the class-unloading phase.
If you have weak reference to j.l.Classloader - GC
Robin,
thank you for detailed description of the algorithm. IMHO, this was
the most complicated place of the whole story: how to have a weak
reference to classloader and still be able to get it alive again. This
shouldn't be performance critical part and is quite doable. I
absolutely agree with
On Thu, 2006-11-09 at 02:01 +0300, Ivan Volosyuk wrote:
Robin,
thank you for detailed description of the algorithm. IMHO, this was
the most complicated place of the whole story: how to have a weak
reference to classloader and still be able to get it alive again. This
shouldn't be
[First, let me say that, as I am not contributing a class unloading
*implementation* to drlvm, I will understand if the project was more
inclined to chose an actually contributed piece of code over a design
without contributed implementation. :-)]
There was a -1 vote... Hmmm... As I voted +1,
I was making it more complex than it needs...
Here's an improvement...
1- During normal operation, the VM keeps hard references to all class
loader instances. [This prevents any premature class loader death].
2- At the start of an epoch (or just before), all vtable bits (or byte
or word) are
Note: For preventing collection of class loaders related to active
method frames, there are various solutions. One could simply walk all
method frame stacks just before the end of epoch collection (my
preferred approach) and mark the bit of related vtables. Another
approach would be to add an
Etienne Gagnon wrote:
I was making it more complex than it needs...
Here's an improvement...
1- During normal operation, the VM keeps hard references to all class
loader instances. [This prevents any premature class loader death].
2- At the start of an epoch (or just before), all vtable bits
Etienne Gagnon wrote:
3- Why would it be so hard to add an unconditional write operation
during collection (e.g. during copying or marking of an object) in
drlvm? A detailed technical explanation is welcome. :-)
I actually believe that this should be implementable in a GC-neutral
way,
2006/11/8, Robin Garner [EMAIL PROTECTED]:
Robin Garner wrote:
Aleksey Ignatenko wrote:
Robin.
OK, well how about keeping a weak reference to the j.l.ClassLoader
object instead of a strong one. When the reference becomes (strong)ly
unreachable, invoke the class-unloading phase.
If you
Uhm, Etienne overtook me with earlier posts.
Seems we are beginning to converge with design.
2006/11/9, Alexey Varlamov [EMAIL PROTECTED]:
2006/11/8, Robin Garner [EMAIL PROTECTED]:
Robin Garner wrote:
Aleksey Ignatenko wrote:
Robin.
OK, well how about keeping a weak reference to the
Hi, Robin.
I do really like this proposed idea of marking VTables from objects via
additional word field in VTable.
But I have one question about detecting reachability of the classloaders
(sweep the vtables and check the reachability of the classloaders).
Possibly I missed something, but here
On 11/2/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
Robin, thanks for all the clarifications. Now it seems clear to me and
I am convinced by this proposal. :-)
Yes, this proposal is the simplest and has the least perf impact. Thanks
Robin.
+1 for this approach. It will give us some kind of class unloading
without much performance impact on GC.
--
Ivan
On 11/1/06, Robin Garner [EMAIL PROTECTED] wrote:
Actually, just thinking about how I would implement this in JikesRVM, I
would use the reachability based algorithm, but piggyback
Robin Garner wrote:
- Allocate a byte (or word) in each vtable for the purpose of tracking
class reachability.
Yep, there's no reason to keep the bits (or words, for performance) in
the class loader, even in the approach I've proposed. They could be
moved to the vtable.
Etienne
--
Etienne
Interesting idea! It seems the real issue is marking and sweeping the
vtables. A stab at categorizing the approaches:
a)
Force vtables to be as similar to ordinary java objects as possible. The
upside: existing GC algorithms will work unaltered. The downside is
vtables
of vtables of
On 11/1/06, Robin Garner [EMAIL PROTECTED] wrote:
Interesting idea! It seems the real issue is marking and sweeping
the
vtables. A stab at categorizing the approaches:
a)
Force vtables to be as similar to ordinary java objects as
possible. The
upside: existing GC algorithms will work
Robin,
The basic difference of this with Etienne's method is that the flag is
on the vtable, instead of the CL instance. Do I understand correctly ? The
GC perf impact is therefore reduced because you need to lookup
object-vtable instead of object-class-CLinstancewhen tracing the heap.
The
Rana Dasgupta wrote:
Robin,
The basic difference of this with Etienne's method is that the flag is
on the vtable, instead of the CL instance. Do I understand correctly ? The
GC perf impact is therefore reduced because you need to lookup
object-vtable instead of object-class-CLinstancewhen
On 11/1/06, Robin Garner [EMAIL PROTECTED] wrote:
Rana Dasgupta wrote:
Robin,
The basic difference of this with Etienne's method is that the flag
is
on the vtable, instead of the CL instance. Do I understand correctly ?
The
GC perf impact is therefore reduced because you need to lookup
Weldon Washburn wrote:
Its probably in the noise but it might be possible to
even reduce the overhead of clearing the vtable mark by using a epoch
number instead of a boolean. The idea is that after every major GC,
increment the value used for the mark. When sweeping the
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
Interesting idea! It seems the real issue is marking and sweeping the
vtables. A stab at categorizing the approaches:
a)
Force vtables to be as similar to ordinary java objects as possible. The
upside: existing GC algorithms will work unaltered. The downside is vtables
of vtables of
48 matches
Mail list logo
