K
Ken Awamura
Suppose I create a new object:
p = new Object
How can I kill/destroy this object forever?
p = new Object
How can I kill/destroy this object forever?
T
Tim Hunter
Ken said:
First, it's
p = Object.new
Second, you can't. Ruby automatically cleans up an object when there is
no more references to it.
K
Ken A.
Tim said:
Does ruby's garbage collector really work, or it's as lame as .NET
garbage collector?
T
Tim Hunter
Ken said:
It really works.
T
Tom Metge
it won't be gc'd until all references to the object are gone... if you
want to ensure that it is collected, dereferencing it will guarantee
garbage collection:
p = nil
this isn't as important with instance variables- if wrapped in a
method or class, they will be gc'd on the next gc run after the method
returns. class and other types are more important... but then again,
why use a class variable if you *don't* want it around?
and yes, ruby's gc works quite well, more so when you know precisely
what to expect
you can run garbage collection manually, but italmost never works the way you want it to... especially in light of
ruby's already trustable gc.
S
Sam Smoot
Eh... I'm less a fan of Ruby's GC. As a former c# developer, I'm
actually curious why the comment on .NET's GC?
BTW, objects in Ruby are not guaranteed to be GC'ed when there are no
more references to them. They can easily survive numerous cycles of
the GC and be found in the ObjectSpace. It's actually really
frustrating.
actually curious why the comment on .NET's GC?
BTW, objects in Ruby are not guaranteed to be GC'ed when there are no
more references to them. They can easily survive numerous cycles of
the GC and be found in the ObjectSpace. It's actually really
frustrating.
T
tekwiz
That's not entirely correct. The newest .NET GC uses an algorithm
that is actually more efficient than the inefficient Mark and Sweep GC
algorithm that Ruby uses. However, Ruby's GC is much less buggy
than .NET's in my experience.
M
M. Edward (Ed) Borasky
tekwiz said:
Well ... I think some universities still give degrees for garbage
collector research, although hopefully not PhDs any more.
But seriously, folks, there is so much research out there that
statements like "as lame as .NET" or "the inefficient Mark and Sweep GC"
aren't particularly informative. In any event, there are efficient Mark
Sweep GCs, inefficient Stop Copy GCs, generational GCs, compacting vs.
non-compacting GCs, GCs that attempt to work with the OS memory
management rather than independent of it, etc.
For Ruby, I suspect the jRuby/JVM garbage collector is probably the best
one out there, simply because it has more person-decades invested in it
than the ones in MRI or KRI. So there are indeed "opportunities" for the
GC experts.
K
Ken A.
Sam said:
I'm doing .NET since 2002 (web stuff) and although it really improved
along the years, I always had this feeling of MS not doing the right
thing. GC is not the only thing, there are several other issues:
1. Controls not rendering proper standards html > have to rely on CSS
Friendly Adapters > overloads my web app
2. No true MVC web development > have to use Asp.Net MVC framework >
will take ages to convince Companies to forget about the Post-Back Model
viewstate (another bad idea imho) ... maintenance and migrations will be
a nightmare ...
3. Should I use: Linq, traditional ADO.Net, Enterprise Library?
4. Visual Studio is a great tool, but Bloated :-(
I did an overall study of Ruby on Rails and now I'm studying Ruby
language to really grasp RoR ... sorry MS, but I decided to move on :-(
ps. without all the MS tools in my PC and just [Ruby, RoR and MySql] my
PC is running just wild
R
Ryan Davis
That's conservative GC for ya... *shrug* It has never been much of an
issue for me, but I can see where it can really hose you up.
R
Rick DeNatale
It's a general feature of most GC algorithms, not just conservative*
ones. The basic promise of a GC is that it WON'T reuse the storage
for an object as long as it's possible to be referenced. In general
there's no guarantee of how fast the space for dead objects will be
reclaimed, often this won't happen until some heap runs out of space
when a new object is allocated, and sometimes not all dead objects
will be reclaimed even then. There are various trade-offs between
things like agressiveness and incrementalism (i.e. bounding the time
taken for GC pauses).
This delayed action of most GCs is one reason why it's a BAD idea to
use finalization to implement application logic. You might want to do
something like closing a file in a finalizer, just in case it didn't
get closed otherwise, but you probably don't want to rely on
finalization to close those files.
* In my experience, the meaning of a conservative GC is that it treats
words on, say, the call stack as object pointers as long as they look
like they might be object pointers. The MRI GC does this because it
has lots of C stack frames whose variables aren't all VALUEs but might
look so to the GC.
R
Ryan Davis
It isn't a (usually) failure of GC algorithms, it is (usually) a
failure of GC implementations.
My GC didn't have this problem.
absolutely agreed.
S
Sam Smoot
It isn't a (usually) failure of GC algorithms, it is (usually) a
failure of GC implementations.
My GC didn't have this problem.
Neither does .NET's GC IIRC. Which is why the posts interested me.
R
Rick DeNatale
Neither does .NET's GC IIRC. Which is why the posts interested me.
So both of these GC implementations return the space used by every
object at the instance the last reference to that object is lost?
I've personally not seen a GC like that. Most delay until the space
is needed. Reference counting does return objects to the free-list
immediately when the reference count goes to zero, but are
inefficient, and fail to reclaim objects which are in circular lists,
and most have some limit on the reference count which means that
objects whose reference counts overflow get stuck as well.
R
Ryan Davis
That wasn't what I was claiming of the GC I wrote, nor is that an
attribute of conservative GCs (or any GC I know of). Instantaneous
collection wasn't a part of this thread at all. The complaint (from
Sam), as I interpreted it, was that conservative GCs sometimes NEVER
collect an object (which is what makes them conservative), and that is
all I was addressing.
R
Rick DeNatale
Well NEVER is a long time.
Seriously, my point is that most GCs, conservative or not, tend to
trade off agressiveness, safety, and pragmatics. Every GC approach I'm
familiar with exhibits one or more of the following 'features'
1) They don't guaranteed to reclaim the space for every dead object,
for example, reference counting GCs won't collect circular garbage,
and many have reference counts which go something like 1, 2, 3 ...
2n-1, INFINITY for some usually small value of n, meaning that objects
which reach the maximum reference count (and those reachable by
transitive closure from those objects) will live as long as the
process does.
2) The reclamation of some objects can be delayed, sometimes rather
indefinitely. Most GCs don't even attempt reclamation until space is
needed, and some families of GCs will partition objects into new
objects which are predicted to die soon and others which have lived
longer, get tenured and are considered for reclamation much less
frequently.
Now this happens with conservative and non-conservative GCs alike.
Conservative GCs do also keep 'objects' alive when they encounter a
pointer which might be pointing to an object. These types of pointer
usually are on invocation stacks, and don't necessarily mean that the
objects are kept forever since what's on the stack is volatile, and
those 'pointer' values do tend to get overwritten as the program
executes.
D
Daniel Berger
Take off and nuke it from orbit. It's the only way to be sure.
Regards,
Dan
S
Soh Dubom
Daniel said:
See, it's the same in .NET world ... they have CG.collect, obj.dispose,
etc ... but it just doesn't work ... I guess the best thing to do is :
obj = null and hope GC to collect those null objects.
B
Brian Adkins
Awesome