[gclist] Synchronization of finalization tables

[Ji-Yong D. Chung]

    Hi,
.
    I was thinking about two ways to improve the use of dynamic
hashtable for storing and accessing finalization methods.

    I just wanted to hear what others thought of them.

    If a garbage collector uses a dynamic hashtables for finalization,
it *might* suffer from lock contention  if it is run in multi-threaded mode,
with lots of objects that require finalization. For static tables,
one can lock just a handful of buckets, so that other buckets are free
to be accessed.  For dynamic tables this is not possible,
because, without the locks, the buckets may be
re-malloced during the reads.

    Here are my "improvements" for reducing lock
contention in finalization tables.

(1) If the collector uses object class *type*
as key to finalization methods, finalizing each object
need not remove its finalization method from the table.
This means finalization method lookup is basically a read
operations (no deletes unless the host program is terminating
and the table is being destroyed).

    In such cases, one can reduce the lock contention by
using shared semaphores that distinguish read-locks and
write-locks (I am thinking of databases here).
Reading the table with one thread will not prevent
other threads from reading the table.

    Bad idea?

    (2) if one uses the "type" of object  (not the object reference itself)
to hash the finalization method, one can register all finalization
methods at the beginning of the host application.at runtime.
Generally, one would not need to perform locked inserts and deletes, because
at runtime, one just needs to read-access the methods.

    Look ma! No locks!
.

Take Care
Ji-Yong D. Chung