pending 64bit version of squeak

Bryce Kampjes bryce at kampjes.demon.co.uk
Fri Jul 4 09:29:57 UTC 2003


John M McIntosh writes:
 > Nope, you forget as I did (and Tim then reminded me) that you just fall  
 > back to a reference counting GC.
 > 
 > a) you've got quite a few more bits around for making the header bigger  
 > (32bits would be enough)

A performance problem with reference counting is you need to both read
the reference count then write it for each change. With a generational
collector a single write can update the write barrier.

Reads and writes are going to bottleneck on memory bandwidth. The
performance penalty of memory access is growing as CPUs increase in
speed faster than memory.

It's worse, when creating a new object and filling it's instance
variables the write barrier will have good locality while the
reference counter will modify several objects, most likely in separate
cache lines. The Athlon will combine several small writes into a
single large write. So a generational system would optimally end up
with a single write while a reference counter would need a read and a
write for each variable stored.

 > b) 64bit machines usually have quite a few extra integer execution  
 > engines and you can hide the
 > reference counting math in the regular execution of the reference  
 > update, so there is no cost.

It's not the math that will hurt.

 > c) Mmm I wonder if you forget to do GC compaction how long you could  
 > run?  You just keep allocating new
 > pages from OS virtual memory.

Does the Mac provide easy useful access to the memory management unit?
Using the MMU to handle the write barrier could allow an efficient
background collector of oldspace. I think this is described in a paper
by Appel from the mid eighties.

Hmm but then doesn't Squeak record writes rather than use a card
table? That would make background collection with a "patch up" after
each incremental collect possible.

Bryce



More information about the Squeak-dev mailing list