RFC: reference counted Throwable
Andrei Alexandrescu via Digitalmars-d
digitalmars-d at puremagic.com
Sat Sep 20 10:17:06 PDT 2014
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
More information about the Digitalmars-d
mailing list