<div dir="ltr"><div dir="ltr"><div dir="ltr"><br><br>On Wed, Sep 9, 2020 at 5:49 AM Stéphane Ducasse <<a href="mailto:stephane.ducasse@inria.fr">stephane.ducasse@inria.fr</a>> wrote:<br>><br>> Hi <br>><br>> I would to be able to see when an incremental GC is happening.<br><br>You can't.  All GC activity happens while the mutator (the rest of the Smalltalk VM) has stopped executing.  i.e. GC does not occur in parallel with the rest of the VM.<br> <br>> is there a way to know when a GC is happening?<br><br>It is impossible, because effectively GCs happen between sends, and even between bytecodes.  But the VM collects statistics that show how many GCs of the various kinds have occurred and how much time has been sent in them  The statistics are made available through the vm parameterAt: primitives.  They are typically displayed in a SystemReporter dialog.  Here's an example from a Squeak image:<div class="gmail_quote"><div><br></div><div><font face="comic sans ms, sans-serif">Virtual Machine Statistics</font></div><div><font face="comic sans ms, sans-serif">--------------------------</font></div><div><font face="comic sans ms, sans-serif">uptime<span class="gmail-Apple-tab-span" style="white-space:pre">          </span>2d 5h 9m 56s<span class="gmail-Apple-tab-span" style="white-space:pre">  </span>(runtime 10h 27m 28s, idletime 1d 18h 42m 28s)</font></div><div><font face="comic sans ms, sans-serif">memory<span class="gmail-Apple-tab-span" style="white-space:pre">               </span>238,690,304 bytes</font></div><div><font face="comic sans ms, sans-serif"><span class="gmail-Apple-tab-span" style="white-space:pre">  </span>old<span class="gmail-Apple-tab-span" style="white-space:pre">                   </span>229,738,272 bytes (96.2%)</font></div><div><font face="comic sans ms, sans-serif"><span class="gmail-Apple-tab-span" style="white-space:pre">  </span>young<span class="gmail-Apple-tab-span" style="white-space:pre">         </span>7,190,528 bytes (3%)</font></div><div><font face="comic sans ms, sans-serif"><span class="gmail-Apple-tab-span" style="white-space:pre">       </span>used<span class="gmail-Apple-tab-span" style="white-space:pre">          </span>198,213,464 bytes (83%)</font></div><div><font face="comic sans ms, sans-serif"><span class="gmail-Apple-tab-span" style="white-space:pre">    </span>free<span class="gmail-Apple-tab-span" style="white-space:pre">          </span>32,454,736 bytes (13.6%)</font></div><div><font face="comic sans ms, sans-serif">GCs<span class="gmail-Apple-tab-span" style="white-space:pre">                        </span>110,155 (1737.5 ms between GCs 341.8 ms runtime between GCs)</font></div><div><font face="comic sans ms, sans-serif"><span class="gmail-Apple-tab-span" style="white-space:pre">       </span>full<span class="gmail-Apple-tab-span" style="white-space:pre">          </span>115 totalling 17,644 ms (0.05% runtime), avg 153.4 ms</font></div><div><font face="comic sans ms, sans-serif"><span class="gmail-Apple-tab-span" style="white-space:pre">                              </span>marking<span class="gmail-Apple-tab-span" style="white-space:pre">               </span>6,600 ms (37.4%) avg 57.4 ms,</font></div><div><font face="comic sans ms, sans-serif"><span class="gmail-Apple-tab-span" style="white-space:pre">                              </span>compacting<span class="gmail-Apple-tab-span" style="white-space:pre">    </span>11,044 ms (62.6%) avg 96 ms</font></div><div><font face="comic sans ms, sans-serif"><span class="gmail-Apple-tab-span" style="white-space:pre">        </span>scavenges<span class="gmail-Apple-tab-span" style="white-space:pre">     </span>110,040 totalling 68,213 ms (0.18% runtime), avg 0.6 ms</font></div><div><font face="comic sans ms, sans-serif"><span class="gmail-Apple-tab-span" style="white-space:pre">    </span>tenures<span class="gmail-Apple-tab-span" style="white-space:pre">               </span>82,870,154 (avg 753 tenures per scavenge)</font></div><div><font face="comic sans ms, sans-serif">Code compactions<span class="gmail-Apple-tab-span" style="white-space:pre">  </span></font></div><div><font face="comic sans ms, sans-serif"><span class="gmail-Apple-tab-span" style="white-space:pre">   </span>699 totalling 625 ms (0.002% runtime), avg 0.9 ms</font></div><div><br></div>These times were collected on a 2.9 GHz Intel Core i9 MacBook Pro.</div><div class="gmail_quote"><br></div><div class="gmail_quote">A different question is can one be informed when a GC just happened?  The current answer is no, but it would be very easy to add.  In VisualWorks, for example, a WeakArray is primed with an Object instance, and this gets collected every scavenge.  So the WeakArray is notified.  From this VW builds a notification system.  I would engineer it differently.  If there is a Semaphore in either of two slots in the specialObjectsArray the VM could signal one Semaphore whenever a scavenge occurs and signal the other when a full GC occurs.</div><div class="gmail_quote"><br></div><div class="gmail_quote">P.S>  can we please stop using the term "incremental GC" for a young space collection?  In Spur the young space GC is a classic Ungar-style scavenger, so I like to call these GCs scavenges.  Soon I hope that the Spur VM will have a proper incremental global GC. This will comprise a mark-sweep collector and a compactor fort old space, but both will operate incrementally.  The mark phase will be done in increments, allowing very small pause times as marking proceeds.  Likewise sweeping to free objects and especially compacting, to coalesce storage, will be done in small increments.  So there will be pause times of the order of 2 or 3 millisecondes due to the incremental collector and overall the system will avoid the relatively long pauses the global GC causes.</div><div class="gmail_quote"><br></div><div class="gmail_quote">HTH<br>_,,,^..^,,,_<br>best, Eliot</div></div></div></div>