[Help-smalltalk] Re: GNU smalltalk - Garbage collection

[Vimal Reddy]

Hello Paolo,
I'm including the previous email conversation I had with you about garbage
collection. 
My cache simulations are giving results different from expectation (I'm using
Shade simulator on Sun Solaris). Basically, I'm counting the number of
references made to new space, survivor space and the other spaces (old+fixed).
Here's a run for intmath.st:

Number of references to eden space = 48,943
Number of references to surv space 0 = 2
Number of references to surv space 1 = 2
Number of references to tenq space   = 2
Total references to new space (eden, surv's, tenq) = 48,949
Number of references to other spaces(old+fixed) = 29,827,066 <--

The num references to old+fixed are really large compared to new space.
Considering that most objects are used up fast ie die young in smalltalk,
should'nt the new space be getting the most references? Is there something I'm
missing? 
My method of collecting this data is I make a note of the allocated addresses
for new space and surv spaces (from the respective C structures after memory
initialization _gst_init_mem). In my simulator, I count references to addresses
lying within these regions. 

I get similar results on the other programs. Also, I was wondering if there
were any real benchmarking programs available for GST. The ones I'm using now
don't run long enough to capture true cache behavior. 

Thanks in advance,
-Vimal

Date: Tue, 29 Apr 2003 17:20:47 -0400 (EDT)
From: Vimal Reddy <address@hidden>
To: Bonzini <address@hidden>
Cc: Vimal K Reddy <address@hidden>
Subject: Re: GNU smalltalk - Garbage collection

P> One thing comes to mind.  Generational garbage collection is only supported
if your
P> architecture is supported by libsigsegv.  The porting is not very complex,
take a look
P> at the parts that implements the check for Alpha/OSF in
libsigsegv/configure.in, for
P> example, which is one of the simplest.  Otherwise you are not using true
generational
P> GC as the old generation will all be scanned for roots to the new one.

Thanks. I looked at the configure.in file. I use Sun Ultrasparc with
solaris and x86 with Linux. It looks like both architectures are
supported.

P> Why not use oprofile or cachegrind on a standard x86 to do cache
simulations?
This was my opinion as well. But when I discussed it on use groups, I got
the feeling that there are 2 levels we are dealing with here. One, the
virtual machine which manages its heap, and second the underlying machine
which it is being run on.  Which level's addresses should I be interested
in? Depends on what I want, right?
What I want to do is "pin down" all memory between the lo and hi addresses
of the youngest generation in the cache (L1 or L2). Then I want to see how
the GC performance is effected and so also the VM performance.

IMHO, tracing at the machine level should be ok. But some others felt I
must trace data references in the interpreter. Are'nt they the same?

I tried profiling with Cachegrind (with the Valgrind core and on Linux
x86). When a garbage collection is invoked in GST, valgrind comes out with an
Abort signal. If you've tried valgrind, it intercepts signals, does its stuff
and then hands it back to the client's (here GST) signal handler. Something is
going wrong there. I have'nt looked into it much. But I plan on doing it.
Without any GC, it works fine. If you are interested, please give it a try.

-Vimal

Date: Tue, 29 Apr 2003 16:28:03 +0200
From: Bonzini <address@hidden>
To: Vimal Reddy <address@hidden>
Cc: Vimal K Reddy <address@hidden>
Subject: Re: GNU smalltalk - Garbage collection

p>One thing comes to mind.  Generational garbage collection is only supported
p>if your architecture is supported by libsigsegv.  The porting is not very
p>complex, take a look at the parts that implements the check for Alpha/OSF in
p>libsigsegv/configure.in, for example, which is one of the simplest. 
p>Otherwise you are not using true generational GC as the old generation will
p>all be scanned for roots to the new one.
p>Why not use oprofile or cachegrind on a standard x86 to do cache simulations?


Date: Wed, 23 Apr 2003 00:25:03 -0400 (EDT)
From: Vimal Reddy <address@hidden>
To: Paolo Bonzini <address@hidden>
Cc: Vimal K Reddy <address@hidden>
Subject: Re: GNU smalltalk - Garbage collection

v>Hello again,
v>I'm trying to pursure my efforts of studying garbage collection using GNU
v>smalltalk. Let me update you of what I'm trying. Basically, I trying to
v>see if new cache strategies (like pinning the youngest generation in
v>cache) would work good for garbage collection. So I'm trying to collect
v>data references for Smalltalk programs, which I would then use on cache
v>simulators for studies.

v>Now stuff for which I need your help. I've been reading the GST code
v>to figure out a way to augment the VM code to get data reference traces.
v>Do you think the VM can be augmented to print out every data
v>reference that is made while running a smalltalk program. By data
v>reference, I mean the address of the location referenced in the heap, not
v>the object table. Please let me know which file and function is the best
v>place to insert such code. I was thinking the interpreter is suitable for
v>it.

Thanks,
Vimal


=====
Vimal Reddy
Graduate Student, ECE
North Carolina State University
Raleigh, NC
Ph: (919) 836-8254 Web: http://www4.ncsu.edu/~vkreddy

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com