Re: Object/Memory Management

* Sean O'Dell ([e-mail]) wrote:

> "Jim Weirich" <[e-mail]> wrote in message
> news:[e-mail]...

[SNIP]

> I just know that being able to call a finalize method *before* the
> object is one of the great things about OOP.  You can encapsulate
> activities inside an object without the outside world knowing
> everything going on inside, and they can use it safely.

Look at http://www.rubygarden.org/ruby?DiscussionOnUsingFinalizers for
how finalizers work in the Ruby scheme of things.

Basically you define finalizers for resources inside your object, not
your object itself; if you need to do a @file.close, you define a
finalizer for @file itself, rather than for your object, which then
needs to access self.file, which of course no longer exists (yes, I know
that's a really, really bad example, never mind, it's 3am :)

Also it appears Matz had some trouble implimenting it, so he made it
ugly to discourage it ;)

> >  1) To recover memory
> >  2) To release non-memory resources
> >  3) To use the "resource allocation is acquisition" idiom (RAIA)

> > With GC, (1) isn't much of a motivator.  A good GC collector will
> > generally outperform most manual allocation/destruction schemes.
> > With the inherit dangers involved with explicit destruction
> > (dangling pointers, etc), it just doesn't seem worth it.
>
> I don't know enough about garbage collection, but that's what everyone
> is saying so I'm accepting that on faith right now.

Well, the thing with 1) is you don't gain much destroying objects
aggressively (i.e. deleting them explicitly) since Ruby's process size
never shrinks (that's a common feature of malloc()/free() anyway,
maybe that's why, *shrug*); all you gain is being able to release a few
external resources slightly earlier.

Otherwise you're just asking the system to destroy your objects, having
them gc'd straight away (after a nice run around the system to make sure
nobody references it) and getting nothing but a few extra entries on the
free list in Ruby.

So all you end up doing with explicit object deleting is some wasted CPU
and maybe dropping a few external resources; not a big motivator
concidering the complexities involved in implimenting it with the GC and
the performance hit it produces.

> > If (2) is your concern, there is nothing stopping you from doing an
> > explicit release of your non-memory resources.  For example, if you
> > want to make sure a file is closed when you are done with it, then
> > close it.  Don't depend on object destruction to close the file.

I'd recommend this anyway; if you want your object to save it's state on
exit, wrap access to it's state in blocks and have a begin .. yield ..
ensure <save state> .. end block, or have an explicit call to commit the
state of the object.  Better to have these things fail when the object
is in a healthy state and be able to do anything with it, such as maybe
Marshal it to disk if your original state saving stuff failed, than be
inside a finalizer and have to avoid talking about the object itself.

-- 
Thomas 'Freaky' Hurst  -  [e-mail]  -  http://www.aagh.net/
-
The hidden flaw never remains hidden.