From: nobu.nokada@...
Date: 2005-06-20T02:06:38+09:00
Subject: Re: GC.disable not working?

Hi,

At Mon, 20 Jun 2005 00:30:59 +0900,
Eric Mahurin wrote in [ruby-talk:145818]:
> > Finailizers don't run immediately after the corresponding
> > objects get collected.  The `finalizer' runs at the process
> > termination.
> 
> This is what the documentation says about define_finalizer:
> 
> ---
> Adds aProc as a finalizer, to be called when obj is about to be
> destroyed.
> ---

The documentation is inaccurate or improper.  Finalizers have
never be called before the destruction.

> I catch the RangeError (recycled object) exceptions and
> Thread.critical is still true ("E" gets printed), but the
> finalizer still happily runs.  I guess GC and the finalizer are
> still considered to be part of the same thread even though
> functionally it seems like a different one.

That guess is right.  But I didn't see "E" nor "e" from your
new example, because GC.start does run finalizers.  Commenting
the line out, "E" was printed.

> I realize that catching RangeError's would fix 99% of the
> problems.  But, I would still be concerned about the case where
> the object would be GCed and then the space reclaimed by an
> object that looks just like it.  Is it guaranteed that
> finalizers of the orginal object be run before its space is
> reclaimed?

They are called after all destruction has done.

> a. When are object finalizers called?  The docs don't reflect
> the behavior.

Within evaluation loop after a method implemented in C ended.
It is possible to change it more frequently (e.g., for each
instructions), but I've not measured how it affects the
performance.

> b. What does GC.disable do?

Prohibits running GC.  If free slots are exhausted while GC is
disabled, the interpreter just tries to allocate new slots with
malloc().

> c. Is GC and/or calling object finalizers considered another
> thread?  It sure seems like they should.

Well, though the current implementation doesn't, I guess so.

-- 
Nobu Nakada