Re: forcing userdata to be gc'd?

[Francisco Olarte <folarte@...>]

On Thu, Mar 30, 2017 at 9:01 PM, Florian Weimer <fw@deneb.enyo.de> wrote:
> Unfortunately, there doesn't seem to be an efficient way to spot when
> references go away immediately and still deal with cycles.  Even
> ignoring the cycle problem, reference counting tends to have a higher
> overhead than tracing collectors (at least for heaps of smaller
> sizes).

Reference counting typically has the size overhead of storing the
reference count plus the time overhead of maintaning it, vs the cost
of the gc. But it has the advantage of keeping thight control of
memory consumption which can be beneficial in many cases ( as, for
what I know, gc work bests when you let them eat more memory than
needed, about 1.5 or 2 times, but I'm not current on state of the art
gc ).

Also, for me, the possibility of using RAII offsets many
inconveniences, I divide the languages on whether they NEED
try/finally or not ( not wheteher they HAVE it ). And ref counting
also aids you in situations more difficult to solve than exhausted
file handles, like mutex locking.


 I've never had a problem with pure ref counting systems, and, until I
had to program in Java for somehow biggy systems, I normally never
generated cycles ( programs in perl with runtime measured in months or
years processing nearly a million transactions a day prove it ).
The only ones where I did it where data analysis programs wich either
needed to free everything at end ( so just exit ) or allocated data
for each run from a 'memory arena' freed as a whole ( that was using
C/C++, where this is easy to do ).

OTOH gc can coexist with refcounts, you manage the refcount, if it
hits 0 free, and if memory usage grows you do a gc pass and free as
usual in gc. There are some runtimes around with this approach,
C-python and duktape at least IIRC, and I think it's great for my kind
of work ( I've never need any kind of data which needed cycles AND
allocated anything other than memory ). This may be, as you point,
more ineficient, but it does not double the cost ( having ref-count
means typically few live objects, cycled or not, and smaller memory
areas,  in many programs, which leads to very fast collections ).

Francisco Olarte.