On Sat 20 Feb, Andrew C. Greenberg wrote:
> Tim suggests:
> 
> > There are some bits available in the method headers
[snip]
> 
> Isn't the idea to avoid things that increase the overhead of message 
> send?  Is the feature of precluding primitives at runtime (since 
> compile-time is relatively straightforward) so valuable a feature 
> that it justifies a separate check against a method header flag for 
> EVERY uncached message send?
Definitely we avoid adding unneccessary cycles to message sending.
I'm not quite sure about your 'precluding primitives at runtime' snetence
means, so forgive me if I get the wrong end of the stick!

My suggestion would add a simple check to the code that already checks
the method header, and if the flag(s) is set, it would ORR in an extra bit
to any primitive index from the header. Thus primitive 71 might be put in
the cache as primIndex 16r10047 instead. Indeed, since my
NewCompiledMethod images have cleaned up the arrangement of primitive bits
in the header, this change would probably cost nothing overall! The the
exectureNewMethod routine would include a test for the 16r10000 bit and
check the equality of sender and receiver if required - which would cost a
couple of cycles per send on average.
This would work equally well for methods with primitives or without, even
for special return primitives.

So, it is as always a balance between function and performance. Is enforcable
runtime privacy worth a couple of cycles added to a two or three hundred
cycle send routine? What do people think?

The VM changes are trivial; couple of hours work at most, but it would be
a bit more thinking to do a clean image/parser/compiler interface.
tim

-- 
Useful random insult:- Has nothing to say, but delights in saying it.
Tim Rowledge:  rowledge at interval.com (w)  +1 (650) 842-6110 (w)
 tim at sumeru.stanford.edu (h)  <http://sumeru.stanford.edu/tim>