RFC: reference counted Throwable

[Johannes Pfau via Digitalmars-d]

Am Sat, 20 Sep 2014 10:17:06 -0700
schrieb Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:

> On 9/20/14, 9:31 AM, Adam D. Ruppe wrote:
> > On Saturday, 20 September 2014 at 16:15:45 UTC, Andrei Alexandrescu
> > wrote:
> >> We need to explore that. A possibility is to support coexistence
> >> and then have the option to use a tool statically pinpoint the
> >> uses of GC. -- Andrei
> >
> > What, *exactly*, does "uses of GC" mean? In other words, what
> > specifically makes GC.malloc evil that must be avoided at any cost
> > while C malloc (+ GC.addRange most likely) is an acceptable
> > replacement?
> >
> > A few things that come to mind are:
> >
> > 1) Obviously, GC.malloc can trigger a collection. But this can be
> > easily disabled.
> >
> > 2) The GC lock? I don't know how malloc handles this though.
> >
> > 3) Is GC.free substantially different than C's free?
> >
> > 4) Programmers don't typically explicitly free GC memory... but we
> > could.
> >
> > 5) Bookkeeping overhead? I know malloc has some too though, is this
> > really a dealbreaker?
> >
> > 6) Public relations.
> >
> > ....that's all I can think of. What am I missing? Which one of
> > these is actually causing the problem that we're supposed to be
> > fixing here?
> 
> The only problem is that GC.malloc doesn't need to be paired by a
> call to GC.free, whereas malloc must.
> 
> Andrei
> 

You're both missing another obvious point:

7) The GC needs to be implemented in D, in the druntime. Malloc is
   available everywhere. The GC keeps a separate heap IIRC which wastes
   memory if you mix D code and C code which uses malloc. Both are
   important points for embedded systems. A druntime without GC is
   much easier to port and produces smaller binaries.

of course in that case, GC.addRange is not an acceptable replacement.
Here 'use of GC' literally means use of GC ;-)