Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Extending C with GC? Date: Wed, 03 Aug 2016 15:26:42 -0700 Organization: None to speak of Lines: 57 Message-ID: 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="10304"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Ij0uQVzSXBXesnZ056l7/" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:0nBHglkCdjY01ly9meaOAI1tSl0= sha1:B3M1Q/gcYvhbcXyYeMC3jbXmpmw= Xref: csiph.com comp.lang.c:91628 Keith Thompson writes: > luser droog 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. [snip discussion of ways a pointer value can be "hidden" from a GC system] There's also an inverse problem, though it's not as severe. A GC system that depends on scanning memory and registers looking for in-use addresses can also get false positives. A GC-aware program might build, say, a large binary tree in memory. Let's say the root node is allocated at (void*)0xdeadbeef, and the rest of the tree is accessible only via the root. The program might then set its only copy of the root pointer to NULL with the expectation that the whole tree will then be garbage-collected. But if something that looks like the address of the root node happens to be stored elsewhere, it might never be collected, resulting in a memory leak. I believe that GC systems for some languages other than C can deal with this, but I don't know how a C garbage collector could avoid this problem in all cases. Perhaps a compiler could provide information that the GC can access at run time that tells it which objects are actually pointers -- but I don't know (a) whether compilers actually do this, or (b) whether it's even possible in general. I'm fairly sure this is a well known issue. Perhaps there are solutions I don't know about. -- Keith Thompson (The_Other_Keith) kst-u@mib.org 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"