Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: Extending C with GC?
Date: Sun, 31 Jul 2016 15:52:34 -0700
Organization: None to speak of
Lines: 68
Message-ID: <lninvl5sjx.fsf@kst-u.example.com>
References: <60b33d17-71b7-4ecf-a821-dc641e2673ba@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="15374"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19TVkoVqilzw/LbRkWcuHtX"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:lFTrL9+iee5Uk+VmwpOZkVXqv2w= sha1:T1606jvXk42Pp+xbC7W8EsXGTzs=
Xref: csiph.com comp.lang.c:91440

luser droog <luser.droog@gmail.com> writes:
> In a recent thread that touched upon closures, it was made apparent
> that automatic storage reclamation would be a practical necessity
> to support closures. 
>
> So how would C work with a garbage collector? How do existing 
> extensions work? Is there a new allocator function to allow a
> "mixed" style, where you manually free the things that are easy
> and rely on the GC for the things that are hard? Or does it 
> take-over malloc(), if so what does free() do?
>
> Since I use C primarily as the implementation language for other
> programming languages, I'd love to stop writing gc code.

There is a narrow technical point that implies that garbage
collection is incompatible with conformance to the C standard.

GC depends on the ability to detect that a chunk of memory is no
longer in use, and can be recovered.  There are various methods
to do this, but basically if there's currently nothing pointing to
a chunk of memory, it's considered safe to assume that that chunk
can be reclaimed.

In standard C, it's perfectly legal to take a pointer value, write
it to a file, set the pointer variable to NULL, and later read the
original pointer value back from the file.

    void *ptr = malloc(some_size);
    assert(ptr != NULL);
    fprintf(some_file, "%p\n", (void*)ptr);
    ptr = NULL;
    /* Now nothing in memory refers to the allocated memory, but a
     * pointer value has been saved in the file.
     */
    ...
    fscanf("%p", &ptr);
    /* Now we have a valid pointer to the allocated chunk of memory */

Or you can break a pointer value down into a sequence of bytes,
scatter those bytes into separate objects, and then collect them
back into a valid pointer value.

A GC system cannot track all possible ways to store a pointer value,
and therefore cannot always know that a given chunk of memory can
never be used again.

Does this mean that GC can't be used with C?  No.  There are
real-world implementations of GC for C, such as Boehm GC.
If you're using such a system, you just have make sure that you
have an active in-memory pointer to any memory you don't want to
be garbage-collected.  This usually doesn't cause any problems.

Would this be a barrier to including GC in a future C standard?  No.
If a future C standard included some form of GC, it could change
the rules to allow for it.

Another point: Some GC implementations will occasionally (and
unpredictably) require a significant amount of time to scan
memory and look for garbage.  This could be unacceptable in some
applications, such as real-time systems where such a delay can be
literally deadly.  There needs to be a way to disable GC to avoid
that kind of problem.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"