btdu - a sampling disk usage profiler for btrfs (written in D)

[Vladimir Panteleev]

On Tuesday, 10 November 2020 at 13:55:52 UTC, Ola Fosheim Grøstad 
wrote:
> On Tuesday, 10 November 2020 at 10:42:09 UTC, Vladimir 
> Panteleev wrote:
>> But, by itself the GC doesn't add much latency to introduce 
>> stutter in the UI - a GC scan is generally quick enough that 
>> the UI doesn't feel laggy or stuttery. The problem is that the 
>> GC is waiting for all threads to finish their ioctls, while 
>> the program otherwise is completely suspended. This affects 
>> not just UI, but throughput.
>
> Would a thread local GC with reference counted shared objects 
> work for your use case?

I don't think there is a simple answer here.

Removing the global GC lock for allocations, and allowing each 
thread to allocate from its own private pool, would greatly 
improve the performance of multi-threaded applications. For 
example, the global GC lock was what was preventing moving more 
processing in Dustmite to worker threads - currently, it's often 
better to keep everything in one thread for GC-dependent code 
instead of using worker threads specifically because of the 
overhead of the global GC lock. I think such a modification would 
be possible without radical changes to the language or GC design, 
but it's possible I'm missing something.

However, that wouldn't help in this case, because the problem 
here doesn't come from allocations, but from the stop-the-world 
aspect of the GC.

A theoretical non-stop-the-world GC would indeed help in this 
situation, but such a GC is only possible if you restrict the 
language to a subset, such that all copies of managed objects are 
always visible to the compiler. It would require all @system / 
extern(C) code to be carefully re-scrutinized. In short, this 
would essentially be a different language (based on D). I don't 
think we can get there from where we are now.