Re: A garbage collector for C++

brittanyfoo@xxxxxxxxxxxx wrote:
I do not think so.
Could you tell me the reason why you think it is a April 1st joke?

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.
For example:

Support C++ raw pointer, unions, bit-fields and hidden pointers.

By definition, a "hidden pointer" is a pointer that the GC does not
know about.

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
are pointers.

If there is no concurrently running scavenging action, there is no
write-barrier overhead, no strong memory ordering requirement, no
synchronization overhead.

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

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 <david.nospam.hopwood@xxxxxxxxxxxxxxxx>
.

Relevant Pages

  • Re: Garbage collectable pinned arrays!
    ... The OP is measuring the overhead of a GCHandle.Alloc, ... exactly what is done by GCHandle.Alloc with GCHandleType.Pinned, that's why he is measuring this methods overhead. ... But interop doesn't pin implicitely, it pins the arguments when needed. ... "Pointer Table" together with some ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: strict-aliasing??
    ... I wanted to implement generic reference counting. ... would be implemented by a base class which would always be the first ... that you are counting that both 'd1' and 'd2' are the same pointer. ... In general, if you want to do a reference counting API, I'd recommend ...
    (comp.lang.c)
  • Re: race on multi-processor solaris
    ... Reference counting has a problem that interlocked increment of the reference ... That is a race condition where you fetch a pointer to ... The value of where the refcount used to be is undefined so you ... instruction to segfault on or a more expensive way to clobber some other ...
    (comp.unix.solaris)
  • Re: Ancient history
    ... If a pointer holds origin, ... into one allocation into a pointer into another. ... where languages like Fortran 77 can have reliable ... the situation in C is such that the overhead is generally log ...
    (sci.crypt)
  • Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)
    ... the overhead of conversion is virtually none (at least in ... so std::string::c_strboils down to returning a pointer. ... the GCC implementation writes terminating '\0' every time ... little overhead contrary to what many people suspect - that converting ...
    (comp.lang.ada)