Hi,

  As I wrote in the previous email, I made a version of VM
which records (almost) all memory access the VM performs.

  If you are interested in it, please read the following and
check the correctness of the implementation.  I didn't do
any serious analysis of the result, but I'm personally
interested in the difference from the some tables in the
part 3 of the Green Book.

-----------------
How It Works

  The basic tactics of it comes from two observations.
The first is that the objects in the old space never move
during two full GCs.  This means that the address of a
object can be used as the identifie of the object.  The
second is that the memory access are performed by calling a
small number of methods (or function or macro).  So
"hooking" the calls is possible.

  The memory access is performed by calling the two
categories of methods:
  (1) longAt:, longAt:put:, byteAt:, or byteAtput:
  (2) at: or at:put:

  In the InterpreterSimlator, the methods in category 2
eventually call the methods in category 1, so modifying the
methods in the category 1 is enough to make it.

  In the translated Interpreter, the methods in category 1
are implemented as macro and the methods in category 2 are
implemented by the array reference ('[]').  Hooking the
category 1 is straightforward.  Hooking category 2 is done
by modifying the CCodeGenerator and write two macros which
use 'typeof' and expression statement extensions of GCC.

  Note that the accesses to the objects in the young space
are counted altogether.

  Note also that it doesn't handle the accesses in the OS
interface functions written in C nor plugins: So it doesn't
have 100% accuracy.

-----------------
What It Does

  The interpreter creates a file named 'access<n>.dump' for
each full GC invocation where '<n>' represents the number of
full GC since the VM startup.  Each file contains the
statistics of the memory accesses between two full GCs.

  The file consists of three part. the first part show the
allocation count since the last full GC, the incr GC count
since the last full GC, and the size of young space.  The
third part shows the access count to the objects in the
young space and the access count to "unknown" location
(incuding forwarding table, method cache etc.)

  The second part shows the stats for each object in the old
space one per line.  Each line consists of 7 fields: they are
  the read count to the base header
  the write count to the base header
  the read count to the fields and extra headers
  the write count to the fields and extra headers
  the string representation
  the word-wrapped size
  the oop
of the object.

-------------
How to Try It

  1. Get the change set.  The change set is available at:
     http://www.is.titech.ac.jp/~ohshima/squeak/memoryStats/memoryStats.19Jun133am.cs

  2. File it in to the vanilla 2.4c image.

  3. If you just want to see it works, try to run it on the
     InterpreterSimulator by evaluating
        intSim _ (InterpreterSimulator new openOn: 'some.image' extraMemory: 1000000).
        Smalltalk garbageCollect.
        intSim test.
     Wait with patience, the screen of the simulated
interpreter will come up.  Invoking the full GC will
create a statistics file.

  If you want to check it more practically, you should
compile the interpreter.  I did it only on a Solaris
machine, but as long as your compiler supports standard IO
library and 'typeof' and expression statement, the following
should work.

  4. Generate interp.c by
         Interpreter translate: 'interp.c' doInlining: false.
     (somehow the definitions of two methods will miss in
     case the inlining is on.)

  5. Generate the support code by
         InterpreterSupportCode writeSupportFiles.

  6. Get the UNIX source files from
     http://www-sor.inria.fr/~piumarta/squeak/

  7. Merge interp.c and the support code into the UNIX
     source tree by executing the following on a shell:
       sqcat interp.c > 2.4c/interp.c
       foreach f (*.[ch])
         sqcat $f > 2.4c/src/$f
       end

  8. Compile it with
       gmake -f GNUmakefile nognu

  9. Run the resulting VM with some image.  When a full GC
     is invoked, the VM will produce the statistics dump.

  Thank you!

                                             OHSHIMA Yoshiki
                Dept. of Mathematical and Computing Sciences
                               Tokyo Institute of Technology