If it's not a joke, then it's a remarkable breakthrough. However, it seems
to claim to do several things that are impossible when taken together.
Support C++ raw pointer, unions, bit-fields and hidden pointers.
By definition, a "hidden pointer" is a pointer that the GC does not
Even conducting an accurate tracing, the system does not require
any special information from compiler. Application can use any
standard C++ compiler, such as Visual C++ 8 and GCC.
This isn't consistent with being able to support raw pointers and unions.
The way compilers like VC++ and GCC compile code that uses unions, for
instance, means that there simply isn't sufficient information to do
accurate tracing: the indication of which branch of the union is currently
valid is not stored anywhere, and the branches differ in which locations
If there is no concurrently running scavenging action, there is no
write-barrier overhead, no strong memory ordering requirement, no
There would have to at least be a write barrier that detects whether or
not the collector is running. (Well, unless you run completely different
code when the collector is not running, but that wouldn't necessarily be
The memory usage is very efficient, acyclic garbage is reclaimed
when the last reference to it is removed. [...]
It is a fully accurate tracing garbage collector. [...]
The runtime cost of application threads is far less than a normal
reference counting. [...]
TANSTAAFL. If you want to do tracing *and* immediate reclamation of
garbage when the last reference is removed, then the only known ways of
doing that incur the overheads of both tracing and reference counting.
In general, the list reads as if someone (with a pretty good knowledge of
the field) had imagined what a feature list would look like if all of the
hard problems in memory management were all solved at once, without having
to make any trade-offs.
It could be that I'm wrong about the incompatibility of some of these features,
but in that case, I would expect that there would be a series of theoretical
papers solving individual problems, leading up to a practical implementation
after several years.
Having said that, if you drop the ability to use standard compilers,
accept some overhead for write barriers and to support deterministic
finalization, and allow deviations from standard C++ semantics for some
of the features it inherited from C, then the rest could be possible
(although still difficult). It's not clear that the value of deterministic
finalization is worth the necessary performance cost, in an otherwise
GC'd language, though.
David Hopwood < XXXX@XXXXX.COM >