[Haskell-cafe] STM friendly TreeMap (or similar with range scan api) ? WAS: Best ways to achieve throughput, for large M:N ratio of STM threads, with hot TVar updates?

[Joachim Durchholz]

Am 30.07.20 um 07:31 schrieb Compl Yue via Haskell-Cafe:
> And 
> now I realize what presuring GC in my situation is not only the large 
> number of pointers (TVars), and at the same time, they form many 
> circular structures, that might be nightmare for a GC.

Cycles are relevant only for reference-counting collectors.
As far as I understand 
http://downloads.haskell.org/~ghc/latest/docs/html/users_guide/runtime_control.html, 
GHC offers only tracing collectors, and cycles are irrelevant there.

> I'm still curious why the new non-moving GC in 8.10.1 still don't get 
> obvious business progressing in my situation. I tested it on my Mac 
> yesterday and there I don't know how to see how CPU time is distributed 
> over threads within a process, I'll further test it with some Linux 
> boxes to try understand it better.

Hmm... can GHC's memory management fragment?
If that's the case, you may be seeing GC trying to find free blocks in 
fragmented memory, and having to re-run the GC cycle to free a block so 
there's enough contiguous memory.
It's a bit of a stretch, but it can happen, and testing that hypothesis 
would be relatively quick: Run the program with moving GC, observe 
running time and if it's still slow, check if the GC is actually eating 
CPU, or if it's merely waiting for other threads to respond to the 
stop-the-world signal.

Regards,
Jo