GC and static data (Was: Projects)

Mon May 1 18:28:00 GMT 2000

Here are some numbers regarding write barriers you may find useful.
For a single run of the SpecJVM98 benchmarks, I counted the following
number of writes that would require a write barrier in a generational
or incremental collector.
Benchmark & Barriers 
\hline
compress & 0.017M 
jess & 7.9M 
db & 33.0M 
javac & 15.5M 
mpegaudio & 5.5M 
mtrt & 3.0M 
jack & 11.6M
I don't have numbers about how many writes would cause a generational
segfault (which is where it really hurts when you use hardware support).
Nevertheless, I believe that there is hope that there may be no need
to resort to hardware-supported write barriers. If I recall Jon Olson's
mail right, he was able to implement software write barriers in a few 
instructions while no gc was taking place.
Multiply the numbers above by a guess how many cycles the avg common case 
takes, and you get a total overhead in the single percents (my half-educated
guess - of course, this ratio will change in the future).
This small overhead should be something you're willing to pay for the 
increased responsiveness of an incremental scheme, or something easily offset 
and surpassed by the reduced gc time a generational collector offers.
Of course, hardware support may still be better for certain applications 
where there is a mature generation that quickly stabilizes. However, as
Hans hinted, there's a lot of sometimes hairy machine specific code 
to write (extracting fault addresses from sigcontexts that change in
every OS release, possibly inspection of faulting instructions etc. pp.)
with the resulting potential decrease in portability.
	- Godmar