On Fri, Feb 22, 2008 at 12:42:36AM +0900, Rick DeNatale wrote:
Yes indeed, unless you want a potentially unpleasant surprise! Far
worse for a GC to throw away non-garbage than not to throw away all
garbage.
I’ve known people who have such a policy (in the real world). And then
they wonder why they can’t find anything…
Paul
Rick DeNatale wrote:
Henry Baker,
Dave Ungar
Eliot M. ?
I wish :) I've never done anything innovative in the GC field.
Just implemeted and/or enhanced a few.
People like Carl Hewitt, L. Peter Deutsch, Hans Boehm, Richard Hudson,
Eliot Moss, Urs Hölzle (and Ungar and Baker) have innovated.
But efore you read up, ask yourself how you think it might work. One
hint. Its paradoxical. To first collect garbage you could identify
everything you don’t wan to throw away.Yes indeed, unless you want a potentially unpleasant surprise! Far
worse for a GC to throw away non-garbage than not to throw away all
garbage.
I meant that most algorithms identify non-garbage, leaving garbage to be
found implicitly (e.g. the space left behind after a scavenging/copying
GC). Only ref counting explicitly identifies garbage, and proves to be
expensive since in OO languages most objects die young.
On 2/21/08, Eliot M. [email protected] wrote:
I meant that most algorithms identify non-garbage, leaving garbage to be
found implicitly (e.g. the space left behind after a scavenging/copying
GC). Only ref counting explicitly identifies garbage, and proves to be
expensive since in OO languages most objects die young.
Yes, and it also suffers from two facts that make it perform
sub-optimally on a virtual memory system (i.e. just about any system
these days)
This tends to lead to large working sets and the attendant swapping.
–
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
On Feb 21, 1:51 pm, Yukihiro M. [email protected] wrote:
|2) It pretty much is guaranteed to visit every memory page at least
|twice per GC cycle.Indeed, we need two visits (one write to mark live objects/one read to
sweep dead objects) per GC. But using bitmap marking technique[1],
objects visit can be reduced to one.[1]http://izumi.plan99.net/blog/index.php/2008/01/14/making-ruby��%9…
When I applied Izumi’s patch to the 1.8.x branch it took a ~20%
performance hit.
Have you benchmarked before and after for 1.9?
Regards,
Dan
Hi,
In message “Re: GC error ?”
on Fri, 22 Feb 2008 05:17:03 +0900, “Rick DeNatale”
[email protected] writes:
|Yes, and it also suffers from two facts that make it perform
|sub-optimally on a virtual memory system (i.e. just about any system
|these days)
|
|1) It fails to compact the live objects
|2) It pretty much is guaranteed to visit every memory page at least
|twice per GC cycle.
Indeed, we need two visits (one write to mark live objects/one read to
sweep dead objects) per GC. But using bitmap marking technique[1],
objects visit can be reduced to one.
There’s an algorithm named “mostly copying GC” to address the former
“fact”, but it is too complex for us to implement.
matz.
Hi,
In message “Re: GC error ?”
on Fri, 22 Feb 2008 06:18:00 +0900, Daniel B.
[email protected] writes:
|When I applied Izumi’s patch to the 1.8.x branch it took a ~20%
|performance hit.
|
|Have you benchmarked before and after for 1.9?
I made a patch[1] against 1.9 which is slightly more efficient than
the original. It is slower than the unpatched 1.9, but performance
hit is less than 20%, maybe 8-10% or so. I am not sure it is
reasonable or not yet. That’s the reason the patch has not been
checked in.
matz.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs