Single-Reference-Mark-GC? (or 0-1-many-counter)

[Axel Kittenberger <axkibe@...>]

The last days, I've been thinking about Garbage Collection. However,
I'm not experienced there, so I'd like to hear your opinion on this.

In my last project I'm including a self-written little 2D vectorgraph
library*. Before I always handed around x/y values of pointers around,
but eventually came to the point, it would be far more elegant to
define point as an "object" (table). However, as table, and working by
reference things start to feel kinda differently, or you have to
continously create new objects on the fly that soon are destructured
again. Like adding two points creates a new point where p1 = p1 + p2
is the worst case of an object to be created while p1.add(p2) might
only modify p1.

But what if creating objects on the stack which are hardly referenced
at all would be made cheap, than it would be okay to work like this.
Thinking of the average project, I didn't run any tests yet, but my
gut feeling says, the majority of tables is referenced only once,
isn't it? Couldn't this be used as advantage for the GC? It would be
some variant of a reference counter that only knows, "zero", "one" or
"many" references. When a table reaches "many" its subject to standard
mark and sweep, if its referenced only once and that reference is
voided, it can be destructed right away.

Would it be possible to have a ring left in memory of two tables that
reference each other only once? I suppose one cannot create such ring,
without holding at two refrence at one point of at least one of the
table and thus subjecting it to mark and sweep.

Advantage: creating object on the fly to be used on the stack,
parameter or return value becomes quite cheaper. This might include
the infamous string concation '..' problem, that a bit
counterintuativly calls for table.concat. Disadvantage, like other
reference counters, asignment and destructuion becomes slightly more
expensive, since the reference mark has to be checked. The usual big
problem of reference counting - rings - might not apply with this.
Other disadvantage, you need 1 bit per object. If this is of concerns
depends if a bit in the existing bitfield is free (last I looked at
5.2 there war a bit practically unused)

What do you think? Do you think it might work out? Is really
impossible to make a ring, without holding 2 references? Would it be
really be an advantage for the average code? Have you already heard of
a GC like this? Might it be worth an academic paper if not?

- Axel