[gclist] why malloc/free instead of GC?
Thu, 20 Feb 2003 00:12:46 -0500
I believe the short answer is "no". The paper you refer to deals with
discovering cyclic reference loops and dealing with them, especially in
What I'm referring to is reference counting under Microsoft's COM (using
the IUnknown interface), and the nearly-mandatory implementation of
using interlocked integer access. The environment I'm referring to is a
common one -- a single process hosting multiple threads, executing on
multiple processors, in which all threads may discover, use, and release
Also note that implementations of the "weighted reference counting"
described in the paper would suffer the same performance problem, if you
allow for multiple threads to alter the same weighted reference. The
threads will necessarily need to synchronize access to the weighted
reference field. On most current SMP x86 systems, this can only be
accomplished using some form of interlocked access, or techniques that
boil down to the same.
Basically, they are totally different problems.
From: firstname.lastname@example.org [mailto:email@example.com]
On Behalf Of Larry Evans
Sent: Wednesday, February 19, 2003 10:09 PM
Subject: Re: [gclist] why malloc/free instead of GC?
Arlie Davis wrote:
> Also, in environments that mix reference counting with unmanaged
> heaps, such as COM development on Win32, you must also account for the
> time spent in AddRef and Release. Most thread-safe implementations
> use interlocked integer primitives, which are quite costly on SMP
> I've done a fair amount of profiling of real-world server apps on
> Win32, and in many implementations, SMP scalability is severely
> hindered by the very high frequency of interlocked operations. In
> services that make heavy use of COM interfaces, reference counting is
> often one of the biggest users of interlocked access.
If smart pointers were used, wouldn't weighted reference counting [
Richard E. Jones and Rafael D. Lins. _Cyclic weighted reference counting
Technical Report 28-92, Computing Laboratory, The University of Kent
at Canterbury, December 1992 ] alleviate this at the cost of more memory
being used by the smart pointers?