Re: native threads

To the best of my knowledge, CCL's GC is kicked off by whichever thread 
calls a storage allocator that triggers a garbage collection.
The GC then stops all (other) "mutator" threads while it "does its 
thing," where "stop" includes single-stepping through any in-line 
consing vinsns. This means that the GC needs to be able to /parse/ 
compiled code to detect whether a mutator thread is in an atomic consing 
operation without the need for any expensive locking mechanism. For all 
you ITS historians, look up "PCLSRing."  Same deal, except I don't think 
CCL ever backs out of a code sequence, it just pushes forward. ITS had 
the option of backing out of a machine instruction that "hadn't gotten 
very far."

On 1/5/24 1:39 PM, David McClain wrote:
>> However in this case it looks mostly like the SBCL GC is doing better: CCL is spending 85% of the time in GC, SBCL somewhat less (about 65%).
>>
> In systems that are SMP capable, I would think that one thread could be dedicated, if needed, to GC duties. The amount of time spent in GC would then depend on how productive the rest of the system is. And I wouldn’t necessarily think ill of a high GC percentage.
>
>