btdu - a sampling disk usage profiler for btrfs (written in D)
thecybershadow.lists at gmail.com
Fri Nov 27 10:20:41 UTC 2020
On Tuesday, 10 November 2020 at 13:55:52 UTC, Ola Fosheim Grøstad
> 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.
More information about the Digitalmars-d