Sun's HotSpot

Tim Rowledge rowledge at interval.com
Fri Oct 16 17:52:47 UTC 1998


> Oh, you mean cases like doing a #perform:withArguments: where the VM
> relies on certain object representations (e.g., the first argument must
> be a Symbol and the second one an Array)?! Interesting point. But somehow
> I doubt that there are so many cases in which you'd have to get around the
> indirection. Is there any way to check this?!

A quick glance through the Interpreter sources suffices to show:-
	arrayValueOf:
	fetchPointer:ofObject:
	storeWord:ofObject:withValue:
	pushReceiverVariable:
	stObject:at:
	baseHeader:
	commonAt:[put:]
	primitiveAtEnd

along with many others, would all be implicated in various ways, depending on
the level at which you wished to do the checking  and the degree of performance
hit you were willing to accept.

I had to do something like this when I made a version of brouhaha that could
keep its image in ROM for the Active Book, many years ago. Many places had to
check for the object body being in ROM address range and copy it to RAM before
writing to it, so the check was much less pervasive since it only had to be
done when a write was likely. It worked very well, with a performance hit of
about 5%, so I feel fairly sure that having to check before reads as well would
significantly increase the cost.

Of course, it is so easy to change the squeak VM that you really ought to do a
mock up of the work and measure it.
First, change all the routines that you think will need a check.
Second, clone an image where every object is indirected, and run it to check
you really have caught all the places needing checking
Third, run a normal VM and measure the performance hit with a decent set of
benchmarks (feel free to try http://sumeru.stanford.
EDU/tim/pooters/SqFiles/deltas/sq20BMarks.zip which is a recast of the Green
Book benchmarks) and decide whether it seems a good idea.

 tim
 
-- 
Strange OpCodes: HCFI: Halt and Catch Fire Immediate
Tim Rowledge:  rowledge at interval.com (w)  +1 (650) 842-6110 (w)
 tim at sumeru.stanford.edu (h)  <http://sumeru.stanford.edu/tim>





More information about the Squeak-dev mailing list