Rejuvenating Autoconf

Posted Oct 26, 2020 13:58 UTC (Mon) by khim (subscriber, #9252)
In reply to: Rejuvenating Autoconf by nix
Parent article: Rejuvenating Autoconf

> The problem here is less GC than anything with a runtime

Nope. Multiple runtimes are not a big deal. Yes, POSIX world usually used that “there are only one libc!” approach, but Windows world didn't.

Usually each DLL comes with it's own runtime (even if they are all just different versions of MSVC runtime they are entirely independent and may support different languages easily).

This works fine — as long as there are no GC in the mix.

Heck, even in POSIX world you may easily link libstdc++-based code and libc++-based code in one process. These are different runtimes, you know.

And yes, you can interpose and replace malloc, but you can't replace its API contract, which among other things specifies that memory blocks can never move.

You don't need to replace it's contract. C can use it's own thing with “frozen” objects, other languages can use “moveable” ones. It's not a big deal as long as there are no requirement to know about all pointers and there exist a way in all languages to create “frozen” objects.

That's why I don't consider ARC, std::unique_ptr and other such constructs “a version of GC”: yes, they may automate certain things, yes, they provide safety to a programs — but they are non-poisonous, they don't infect your whole codebase, they are local.

P.S. There are more types of GC than you may think about. Go have goroutines — that's a concept of GC applied to the thread. And it causes similar amount of pain if you want to mix languages. Yet I'm not even sure if that's a bad thing or not: the issue comes from our attempts to create monstrous binaries with gigabytes of code coupled with GC and other GC-like concepts. But maybe it's not GC that is bad, but, in reality, an attempt to build our apps as monoliths of insane size? Time will tell, I guess.

Rejuvenating Autoconf

Posted Oct 26, 2020 15:33 UTC (Mon) by nix (subscriber, #2304) [Link] (2 responses)

Heck, even in POSIX world you may easily link libstdc++-based code and libc++-based code in one process. These are different runtimes, you know.

You can only do that if you never pass things from one to the other, or if they are cooperating on their internal representations. This is exactly the same problem as the one causing trouble with GC: shared data structures manipulated by multiple things that may not know they have to cooperate with some other project with regard to their design. (If you remember the libc5 to libc6 upgrade, that had problems around wtmp which were exactly the same problem again, except this time the data structure was on disk, not in memory.)

Rejuvenating Autoconf

Posted Oct 26, 2020 22:22 UTC (Mon) by khim (subscriber, #9252) [Link] (1 responses)

Well… singletons of any sort are problematic, true. The issue with GC is that it's:

Very much a singleton — it assumes that it has access to the full graph of objects in your program…
and
It's central part of language design: I don't know about any language where GC is optional (except, maybe, D — and I think that kinda-sorta-optionality caused more harm than good there)

That combo is really toxic.

Rejuvenating Autoconf

Posted Oct 27, 2020 11:21 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

It doesn't have to be a singleton. Lua's GC is attached to the interpreter in use. Though it is also meant to be embedded, so it's a use case they thought of. I don't know if anyone has written a bridge between Lua's GC and any other GC (including another instance of a Lua GC) to allow storing objects of one within the other's purview at all.