On Friday, 21 January 2022 at 20:17:16 UTC, Guillaume Piolat wrote:

But it only stops the wren-code, so it does not affect real time properties of the main program? I think this is the better approach for system level programming. Have dedicated memory management where you get to control the properties and priorities, and also have the ability to add new mechanisms (like purging cached objects).

IIRC, the author of the audio-oriented GC suggested implementing the collector as a coroutine, so that you could execute it when the CPU is idle in a controlled manner.

Many ways to be inventive here, if you focus on adapting to the specifics of the application. There is no-size-fits-all solution.

So, the main issue is not GV vs no-GC, but whether the language/libraries lock you to the specifics of a generic runtime.

On Saturday, 22 January 2022 at 13:19:57 UTC, rikki cattermole wrote:

I think some language adjustments are needed, but it could be a dialect. Doesn't have to apply to DMD, as it seems to be locked down at this point.

You basically need some room to experiment to get it right, and that requires freedom (which will never happen if everyone in the forums are going to have their say).

So whether you want to focus on ARC, actors/fibers with local GC or concurrent GC, you should be able to adjust the language so that your vision can be enabled in a clean fashion.

I don't think having dialects is a big issue. I think it is the only way forward for automatic memory management + system level programming. You can design your dialect such that most straight forward single-threaded code run with next to no changes.

It is either that or another language will grab the user base that wants it.

On Saturday, 22 January 2022 at 13:03:26 UTC, Ola Fosheim Grøstad wrote:

No because (roughly speaking) UI callbacks are in event loops / timers separated from audio callbacks, and wren is called from these UI callbacks.

So you can take as much time as you want to process a click, or in WM_PAINT, it will never affect audio playback (well, it will if you spawn many demanding threads from there).

To support that windowing in desktop OSes separates invalidation from repaint.

On Thursday, 20 January 2022 at 23:56:42 UTC, Chris Katko wrote:

Are you kidding? The incremental GC based on the train algorithm (see https://wiki.c2.com/?TheTrainAlgorithm) that earlier was part of the JVM has meanwhile been removed from it since there are newer better ones.

On Thursday, 20 January 2022 at 23:56:42 UTC, Chris Katko wrote:

Just to add to this for completeness sake: a while ago I spent a few hours digging through Uneal Engine source code to understand their GC algorithm. It's a peculiar and interesting take on iterative, precise, conservative garbage collection:

• First of all, UE4 has precise runtime reflection information for all data types that are handled via the GC (everything derived from UObject - which is mostly game logic code). Heap scans are optimized aggressively based on this data. Pointers are regular naked C++ pointers without any additional magic. They need to be annotated for the custom preprocessor that generates the reflection data, but that's it. The C++ code touching these pointers is plain old code using naked pointers. No hidden wrappers there.

• The algorithm is basically mark and sweep with a couple of awful situational hacks that stem from weird engine subsystem interactions. I'll gloss over those. The GC performs a multistep GC process. Each frame, the engine prompts the GC to run one step in a stop-the-world fashion.

• Each step, the GC can either run an entire mark phase or a single step of the sweep phase. The mark step is always run in its entirety, never in multiple steps. The sweep phase is broken up into steps that free a limited number of marked objects in each step. The rest is deferred to the next step. When sweep phase is done, the next GC step will be a new mark phase.

IMO, this is a very pragmatic approach. But for the runtime to be truly bounded, the heap size needs to be bounded, too. I assume that this works for UE4 because for most games using the engine, the number of objects involved in the game logic at any point is fairly small (mostly ~ a few hundred). Stopping the world for the mark phase is also a major simplification. This avoids the overhead typically incurred by GC algorithms that do incremental marking. Also, GC references can be treated just like regular pointers.

I don't know how the D garbage collector runtime is split between mark and sweep phases. If the sweep phase is indeed the slower phase, an option to have that run iteratively might be enticing. I would naively assume that this would be lower hanging fruit compared to a generational and/or concurrent GC. But then again, I don't have a need for any of that at the moment.