Rejuvenating Autoconf

Posted Oct 28, 2020 5:36 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
In reply to: Rejuvenating Autoconf by dvdeug
Parent article: Rejuvenating Autoconf

> Yet Clojure runs on the JVM.
It's just another GC language without any particular complications, so duh.

> GC may not be trivially separable, but it is portable.
Nope. Nope. Nope.

Look at how modern Java GCs work. For example, GC needs "stop-the-world" pause to scan the GC roots and to achieve this Java instruments all the code so that all methods have checks that boil to something like "if (inGc) stopThread();" on back branches and before nested functions. The GC then simply modifies the inGc variable in each thread's memory and waits for them to stop.

And we haven't yet talked about object repacking, generations and card marking (or other write barriers in general) and other niceties.

There is no way two different GCs can fully interoperate without knowing very intimate details about each other.

Rejuvenating Autoconf

Posted Oct 28, 2020 7:15 UTC (Wed) by dvdeug (subscriber, #10998) [Link]

>For example, GC needs "stop-the-world" pause to scan the GC roots and to achieve this Java instruments all the code so that all methods have checks that boil to something like "if (inGc) stopThread();" on back branches and before nested functions. The GC then simply modifies the inGc variable in each thread's memory and waits for them to stop.

This has nothing to do with Java. If you're running all-Scala code on the JVM, it will still do it. If you're compiling Ada to JVM, the JVM will do that for Ada. And Java compiled via GCJ doesn't do that. This is completely language-independent.

> There is no way two different GCs can fully interoperate without knowing very intimate details about each other.

Which seems irrelevant to the argument that there should be one and only one GC in a process.