Suppose I create a new object:
p = new Object
How can I kill/destroy this object forever?
···
--
Posted via http://www.ruby-forum.com/.
Ken Awamura wrote:
Suppose I create a new object:
p = new Object
How can I kill/destroy this object forever?
First, it's
p = Object.new
Second, you can't. Ruby automatically cleans up an object when there is no more references to it.
···
--
RMagick: http://rmagick.rubyforge.org/
Take off and nuke it from orbit. It's the only way to be sure.
Regards,
Dan
···
On Dec 26, 9:09 am, Ken Awamura <ken.awam...@gmail.com> wrote:
Suppose I create a new object:
p = new Object
How can I kill/destroy this object forever?
Tim Hunter wrote:
Ken Awamura wrote:
Suppose I create a new object:
p = new Object
How can I kill/destroy this object forever?
First, it's
p = Object.new
Second, you can't. Ruby automatically cleans up an object when there is
no more references to it.
Does ruby's garbage collector really work, or it's as lame as .NET
garbage collector?
···
--
Posted via http://www.ruby-forum.com/\.
Daniel Berger wrote:
···
On Dec 26, 9:09�am, Ken Awamura <ken.awam...@gmail.com> wrote:
Suppose I create a new object:
p = new Object
How can I kill/destroy this object forever?Take off and nuke it from orbit. It's the only way to be sure.
Regards,
Dan
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.
--
Posted via http://www.ruby-forum.com/\.
Awesome 
···
On Dec 31 2007, 3:57 pm, Daniel Berger <djber...@gmail.com> wrote:
On Dec 26, 9:09 am, Ken Awamura <ken.awam...@gmail.com> wrote:
> How can I kill/destroy this object forever?Take off and nuke it from orbit. It's the only way to be sure.
Regards,
Dan
Ken A. wrote:
Tim Hunter wrote:
Ken Awamura wrote:
Suppose I create a new object:
p = new Object
How can I kill/destroy this object forever?
First, it's
p = Object.new
Second, you can't. Ruby automatically cleans up an object when there is
no more references to it.Does ruby's garbage collector really work, or it's as lame as .NET garbage collector?
It really works.
···
--
RMagick: http://rmagick.rubyforge.org/
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 it almost never works the way you want it to... especially in light of ruby's already trustable gc.
···
On Dec 26, 2007, at 10:18 AM, Tim Hunter wrote:
Ken A. wrote:
Tim Hunter wrote:
Ken Awamura wrote:
Suppose I create a new object:
p = new Object
How can I kill/destroy this object forever?
First, it's
p = Object.new
Second, you can't. Ruby automatically cleans up an object when there is
no more references to it.Does ruby's garbage collector really work, or it's as lame as .NET garbage collector?
It really works.
--
RMagick: http://rmagick.rubyforge.org/
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.
···
On Dec 26, 11:18 am, Tim Hunter <TimHun...@nc.rr.com> wrote:
Ken A. wrote:
> Tim Hunter wrote:
>> Ken Awamura wrote:
> Does ruby's garbage collector really work, or it's as lame as .NET
> garbage collector?It really works.
--
Travis
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.
tekwiz wrote:
Ken A. wrote:
Tim Hunter wrote:
Ken Awamura wrote:
Does ruby's garbage collector really work, or it's as lame as .NET
garbage collector?It really works.
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.--
Travis
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.
···
On Dec 26, 11:18 am, Tim Hunter <TimHun...@nc.rr.com> wrote:
Sam Smoot wrote:
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?
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
developers will have to re-learn asp.net, forget page self-postbacks,
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
···
--
Posted via http://www.ruby-forum.com/\.
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.
···
On Dec 26, 2007, at 12:05 , Sam Smoot wrote:
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.
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.
···
On Dec 27, 2007 5:55 AM, Ryan Davis <ryand-ruby@zenspider.com> wrote:
On Dec 26, 2007, at 12:05 , Sam Smoot wrote:
> 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.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.
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
It's a general feature of most GC algorithms, not just conservative*
ones.
It isn't a (usually) failure of GC algorithms, it is (usually) a failure of GC implementations.
My GC didn't have this problem. 
This delayed action of most GCs is one reason why it's a BAD idea to
use finalization to implement application logic. [...]
absolutely agreed.
···
On Dec 27, 2007, at 07:21 , Rick DeNatale wrote:
Neither does .NET's GC IIRC. Which is why the posts interested me.
···
On Dec 27, 12:54 pm, Ryan Davis <ryand-r...@zenspider.com> wrote:
On Dec 27, 2007, at 07:21 , Rick DeNatale wrote:
> It's a general feature of most GC algorithms, not just conservative*
> ones.It isn't a (usually) failure of GC algorithms, it is (usually) a
failure of GC implementations.My GC didn't have this problem.
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.
···
On Dec 30, 2007 1:44 AM, Sam Smoot <ssmoot@gmail.com> wrote:
On Dec 27, 12:54pm, Ryan Davis <ryand-r...@zenspider.com> wrote:
> On Dec 27, 2007, at 07:21 , Rick DeNatale wrote:
>
> > It's a general feature of most GC algorithms, not just conservative*
> > ones.
>
> 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.
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
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.
···
On Dec 30, 2007, at 09:46 , Rick DeNatale wrote:
So both of these GC implementations return the space used by every
object at the instance the last reference to that object is lost?
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.
···
On Dec 31, 2007 3:14 AM, Ryan Davis <ryand-ruby@zenspider.com> wrote:
On Dec 30, 2007, at 09:46 , Rick DeNatale wrote:
> So both of these GC implementations return the space used by every
> object at the instance the last reference to that object is lost?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.
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/