No subject

What can’t it do?
• Reclaim     memory or invoke finalizers/destructors
  immediately.
   • Like all tracing garbage collectors, it only checks for
     unreachable memory occasionally.
   • And synchronous heap finalizers are broken anyway ...
• Reclaim     “all” unreachable objects.
   • Generally a few will still have pointers to them stored
     somewhere.
   • The GC doesn’t know which registers will be referenced.
   • And there are other issues ...
   • And “unreachable” isn’t well-defined anyway...
   • But we generally avoid growing leaks.

And if you read through the slides it gets worse and worse.

Also comments like:

"Note that an object may become inaccessible before client code is done
operating on objects referenced by its fields. Suitable synchronization
is usually required."

It's going to need threads to work well without halting the process.

And this is crazy talk:
"The allocator allocates objects of different kinds. Different kinds are
handled somewhat differently by certain parts of the garbage collector.
Certain kinds are scanned for pointers, others are not. "

"scanned for pointers" !

"...it is very likely that most C clients of the collector currently use
at most two kinds: NORMAL and PTRFREE objects. The gcj runtime also
makes heavy use of a kind (allocated with GC_gcj_malloc) that stores
type information at a known offset in method tables. "

It multiplies everything bad about talloc and then boasts about it.

I'm sad about Perl 6's garbage collection but even it knows a real
pointer when it sees one and doesn't go around guessing, requiring the
author to remember to leave clues all over the place.

Sam