<!DOCTYPE html>

<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

  </head>

  <body>

    To the best of my knowledge, CCL's GC is kicked off by whichever

    thread calls a storage allocator that triggers a garbage collection.<br>

    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 <i>parse</i>

    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."<br>

    <br>

    <div class="moz-cite-prefix">On 1/5/24 1:39 PM, David McClain wrote:<br>

    </div>

    <blockquote type="cite"

cite="mid:CB5261D3-BB2F-4DC0-B4C0-3EA9926A844C@refined-audiometrics.com">

      <pre class="moz-quote-pre" wrap="">

</pre>

      <blockquote type="cite">

        <pre class="moz-quote-pre" wrap="">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%).

</pre>

      </blockquote>

      <pre class="moz-quote-pre" wrap="">

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.

</pre>

    </blockquote>

    <br>

  </body>

</html>