I've known people who have such a policy (in the real world). And then
they wonder why they can't find anything...
Paul
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.
Rick DeNatale wrote:
In my day they were called libraries. Now its called "wikipedia".
I hadn't seen this article before, a quick skim and I'd say it looks
like a decent survey, although I'd like to see a little more credit
given to some of the GC innovators:Henry Baker,
Dave Ungar
Eliot Miranda ?
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/20/08, Eliot Miranda <eliotm@pacbell.net> wrote:
--
The surest sign that intelligent life exists elsewhere in Calvin &
the universe is that none of it has tried to contact us. Hobbes.
--
Eliot ,^..^, Smalltalk - scene not herd
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.
This tends to lead to large working sets and the attendant swapping.
On 2/21/08, Eliot Miranda <eliotm@pacbell.net> 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.
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
Hi,
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.
In message "Re: GC error ?" on Fri, 22 Feb 2008 05:17:03 +0900, "Rick DeNatale" <rick.denatale@gmail.com> 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?
Regards,
Dan
On Feb 21, 1:51 pm, Yukihiro Matsumoto <m...@ruby-lang.org> wrote:
Hi,
In message "Re: GC error ?" > on Fri, 22 Feb 2008 05:17:03 +0900, "Rick DeNatale" <rick.denat...@gmail.com> 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.[1]http://izumi.plan99.net/blog/index.php/2008/01/14/making-ruby��%9\.\.\.
Hi,
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.
[1] http://www.rubyist.net/~matz/a/cow-friendly.diff
In message "Re: GC error ?" on Fri, 22 Feb 2008 06:18:00 +0900, Daniel Berger <djberg96@gmail.com> writes: