[developers] tuning image size and the garbage collector

Stephan Oepen oe at csli.Stanford.EDU
Mon Jun 5 20:46:15 CEST 2006


hei!

i am wondering about gc() performance: every now and again and recently
with distressing frequency, i experience a global gc() that requires on
the order of seven minutes to complete.  here are some gc() messages:

  [20:18:39] gc-after-hook(): local; new: 911819488; old: 0; efficiency: 81.

  Indexing completescavenging...done
  Mark Pass...done(1,270+0), marked 6303240 objects, overflows = 0, \
    max depth (minus ovflow) = 16.
  Weak-vector Pass...done(0+0).
  Cons-cell swap...done(40+0), 696311 cons cells moved
  Oldarea break chain...done(100+0), 68252 holes totalling 40041472 bytes
  Page-compaction data...done(0+0).
  Address adjustment...done(409,990+50).
  Compacting other objects...done(190+0).
  Page compaction...done(0+0), 0 pages moved
  New rootset...done(500+0), 58773 rootset entries
  Building new pagemap...done(110+0).
  Merging empty oldspaces...done, 0 oldspaces merged.
  global gc recovered 53360048 bytes of old space.
  scavenging...done
   eff: 2%, copy new: 243086224 + old: 0 = 243086224
    Page faults: non-gc = 0 major + 39011 minor, gc = 0 major + 47676 minor

  [20:25:45] gc-after-hook(): global; new: 243086224; old: 0; efficiency: 2.

the one time-consuming step appears to be `address adjustment', so now
i wonder what exactly is done there and how i get it to be so bad?  it
seems ACL while in that phase is interacting badly with my Linux: load
goes up to above 4, even though there is only one active process.  ACL
itself has a process size of around 1.6 gbyte at this point (and there
is lots more physical memory available).

i also have the impression that the number of `cons cells moved' has a
direct impact on the time taken in address adjustment.  furthermore, i
believe that ACL 8.0 made this problem worse.  i have tried a range of
image creation parameters (initial new- and oldspace sizes, lisp heap, 
et al.) but so far to no avail.

at this point, i believe i would benefit from a developer looking over
the gc() messages above and pointing out (a) whether there is anything
odd-looking there and (b) summarizing what exactly goes on in address
adjustment and how i can affect the amount of work done in that phase?

                                        many thanks in advance  -  oe

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Universitetet i Oslo (IFI); Boks 1080 Blindern; 0316 Oslo; (+47) 2285 7989
+++     CSLI Stanford; Ventura Hall; Stanford, CA 94305; (+1 650) 723 0515
+++       --- oe at csli.stanford.edu; oe at ifi.uio.no; stephan at oepen.net ---
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++



More information about the developers mailing list