A couple garbage collector questions

[Hannah Schroeter]

Hello!

In article <3ADFE49E.92B32558 at bayarea.net>,
Frank Mitchell  <frankm at bayarea.net> wrote:
>[...]

>the pauses for collection.  (OTOH, hard real-time or distributed systems
>may be happier with sophisticated refcounting, and for slowly-changing
>data structures refcounts are perfectly acceptable.  With the extensive
>compiler support described by Ms.[?] Schroeter, refcounts would be at
                               ^^ yes (why the '?')
>least competitive ... but how many compilers actually use that
>technique?)

Now, you'd have to do incremental freeing if you want a DECREF with
predictable time behaviour. I.e. you'd have DECREF just enqueue
the object on a "refcount to be decremented queue", and in each VM
"step" you work off at most 'n' (some parameter) decrement queue
entries.

If VM instructions can create only one reference each at most,
I'd believe that with n = 1, the system will be stable, however, slightly
larger n (2 or 3, e.g.) could be memory friendlier.

There remains an unpredictability if you have arrays of potentially
large size as objects: The run_decref_queue operation would have
to at least enter all contained object pointers to the decref queue
in one step.

Surely, it'd be possible to put even more sophistication in, but then,
there's the question if that complexity will not be finally higher than
that of a sophisticated incremental/concurrent GC.

Kind regards,

Hannah.