"Sean O'Dell" <sean / celsoft.com> writes:

> Isn't there a way we can *explicitly* destroy objects?  I like to keep
> things tight and clean in my code, 

Why? Depending on what you do and how you do it, GC can be much faster
than explicit free(). Later on this.

> and simply walking away from objects I've
> created absolutely freaks me out.  

It seems that Ruby is your first GC'ed language. Make the
transition. Let the computer does mudane things like freeing memory
and liberate yourself to pursue other more interesting things (like
going fishing more often).

> I don't like leaving my program bloated

Simply restrict your process to have a certain maximum memory size. In
Ruby, limiting the size is an external task: you need to tell the OS
to set the limit, e.g.: in UNIX you can use the command 'limit' before
starting up Ruby. OTOH, Java interpreter does an internal
limiting. Anyway, you set how 'bloated' your program can be, and
forget it.

> Also, a related issue...why isn't there a finalize call?  I don't mean the
> Is that in the works or is that just not the Ruby way?

Finalizer is provided by ObjectSpace#define_finalizer. Look back the
archive to learn more why the finalizer is outside the object
(keyword: define_finalizer).

Now on how GC can be faster. 2 years ago I had to construct a
forgiving HTML parser. I ended up making four versions: 2 Java and 2
C. Of those 4, 1 Java and 1 C use object pooling, 1 Java use GC, and 1
C uses explicit free() which is performed right after a variable is
unused. All 4 use Lex or JLex. The rules for the lexer are all
similar. In brief, here is the performance table for large HTML (> 1
MB) document:

C with object pooling < Java with GC < Java with object pooling < C
with explicit free.

The only time the performance of Java with GC was disappointing was
when running it using the MS JVM. MS's JVM is so damned brain
dead. The initial heap cannot be set to more than 32 MB. Setting the
maximum heap size to 512 MB will not help at all because JLex produces
an incredible amount of very short-lived object (String). For every
object created, if the current heap is full, then MS' JVM performs a
GC and increases the heap usage if necessary. This is as expected from
a Java GC. However, what I want is to postpone GC as late as
possible. Thus, I have to set the initial heap size to some large
values which is possible under other JVM but MS'.

In short, GC is a good idea. Its performance is reasonable and yet it
frees programmer to do interesting things. It's most certainly faster
than reference counting (which is a special case of explicit free()),
and yet easier at the same time.

YS.