[gclist] ref-counting performance cost
Wed, 6 Sep 2000 13:13:15 -0500
Bill Birch wrote (Thu, Sep 07, 2000 at 11:39:50PM +1000) :
> I never understood why there is a need in traditional RC to adjust the
> refcount on every pointer value change. So I don't, I always assume that a
> memory cell is garbage so the default state is refcount = 0. Whole trees are
> constructed like this until a side effect occurs (e.g. binding to argument).
> Then the ref counts are adjusted across the tree. So in my Lisp, (READ) can
> return entire trees with zero refcounts. This does mean that referencing is
> a recursive operation, however it only recurses on zero count nodes. This
> gives me complete freedom to manipulate pointers without reffing and
> dereffing everywhere.
I wonder whether what you suggest is specific to functional
languages, or more specifically LISP interpreters that spend
most of their term operating on unshared trees. Could you
do something similar for a Java GC that operated on more
general data structures like DAGs and hashtables?
> As a further 'optimisation', functions which are guaranteed to return a tree
> containing every argument do no reffiing of their arguments. So for example
> CONS, LIST do NO reference increment of their arguments on entry nor deref
> on exit.
Yes, if the compiler is automatically inserting the RC maintenance
code, then it could optimize the amount of instrumentation it has
to do. But can it do a decent job with a procedural language
that has side-effects, such as Java?
Actually looking at an object profile of a Java application,
especially at the objects that could not be RC-collected
due to stuck counters and cycles, it looks like it would be a big
win to special-case java.lang.String/StringBuffer and java.lang.Hashtable
since they occur so frequently in all applications (well, SPECjvm98).