[gclist] ref-counting performance cost

[Manoj Plakal]

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).

	Manoj