Reference counting

What challenges would be involved in modifying Neko to use
reference 
counting instead of or in addition to GC?  Could it be done
without 
modifying the C FFI?  I suppose that the use of
setjmp/longjmp for error 
handling would pose a significant challenge, though if
reference 
counting is used in conjunction with GC, then a possible
compromise 
would be to let GC reclaim no-longer-used resources when an
error occurs.

I am aware that the merits of reference counting versus GC
have been 
debated for years (decades?), and GC seems to have
prevailed.  I amalso 
aware that the classic problem with reference counting is
inability to 
detect reference cycles.  However, reference counting has
the advantage 
(undisputed, AFAIK) that in the normal case, resources are
reclaimed as 
soon as they're no longer used.  I don't care much about
memory here; 
I'm more concerned about open files, COM objects (I know
there is no COM 
library for Neko yet), and the like.  So my preference would
be a VM 
that does both reference counting and GC, as the C
implementation of 
Python does.

Thoughts?

Matt

-- 
Neko : One VM to run them all
(http://nekovm.org)

1. Immediate reclamation can be part of an interface to the
resource
instead of performed in the finalization step, so that's
not
necessarily a ref-counting advantage.

2. "A Pure Reference Counting Garbage Collector",
ie. one that can
even collect cycles without an additional GC:
http://citese
er.ist.psu.edu/539023.html

3. From prior discussions, it seems to me that Neko doesn't
want
reference counting because one of its primary purposes is
direct
interfacing and easy interoperability with C. The Boehm
conservative
GC is thus the only viable choice I know of at the moment.

Sandro

On 8/20/07, Matt Campbell <mattcampbellpobox.com> wrote:
> What challenges would be involved in modifying Neko to
use reference
> counting instead of or in addition to GC?  Could it be
done without
> modifying the C FFI?  I suppose that the use of
setjmp/longjmp for error
> handling would pose a significant challenge, though if
reference
> counting is used in conjunction with GC, then a
possible compromise
> would be to let GC reclaim no-longer-used resources
when an error occurs.
>
> I am aware that the merits of reference counting versus
GC have been
> debated for years (decades?), and GC seems to have
prevailed.  I amalso
> aware that the classic problem with reference counting
is inability to
> detect reference cycles.  However, reference counting
has the advantage
> (undisputed, AFAIK) that in the normal case, resources
are reclaimed as
> soon as they're no longer used.  I don't care much
about memory here;
> I'm more concerned about open files, COM objects (I
know there is no COM
> library for Neko yet), and the like.  So my preference
would be a VM
> that does both reference counting and GC, as the C
implementation of
> Python does.
>
> Thoughts?
>
> Matt
>
> --
> Neko : One VM to run them all
> (http://nekovm.org)
>

-- 
Neko : One VM to run them all
(http://nekovm.org)

Matt Campbell a écrit :
> What challenges would be involved in modifying Neko to
use reference
> counting instead of or in addition to GC?  Could it be
done without
> modifying the C FFI?  

No I don't think it would be possible, it's not been
designed for that.

Nicolas


-- 
Neko : One VM to run them all
(http://nekovm.org)

Matt Campbell wrote:
> I'm more concerned about open files, COM objects (I
know there is no COM
> library for Neko yet), and the like.  

In this case, I would try to mimic a try...finally
construct.  I'm
certainly a novice here, however Neko supports try...catch
with rethrow
so an ugly version of try...finally:


//open file
try
{
  //...
}
catch e
{
  //close file
  $rethrow(e);
}
//close file

I wonder if this will work:

//open file
try
{
  //...
  $goto(closefile);
}
catch e
{
  closefile:
  //close the file;
  $rethrow(e);
}

-Brian

-- 
Neko : One VM to run them all
(http://nekovm.org)