RFC: reference counted Throwable

Adam D. Ruppe via Digitalmars-d digitalmars-d at puremagic.com
Sat Sep 20 09:31:47 PDT 2014


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?


More information about the Digitalmars-d mailing list