> > My only concern was that how were the numbers arrived at for things
>> like:
>
> >		int atCache[65];

Well, I just thought about what it was doing and guessed at what it would take.  You could try doubling it and halving it.  I think it will provide most of its benefit with only one entry.

What it does is to note the case when a receiver responds primitively to at: and, when it does, it saves a few useful bits of information like its size and element format (and, of course, the fact that you don't have to look it up next time).  This allows subsequent sends of at: and next (and store counterparts) to go a lot faster.

>AFAIK, This is an optimization; it doesn't affect correctness.  But,
>experimentation for different sizes might be fruitful.  Anyone know how
>much the atCache affects the runtime? I may get a chance to look at it.

It helped a lot when I put it in.  I think it was the biggest improvement in the last go-round of changes to the interpreter.  Just defeat it and run tinyBenchmarks.  [If you want to do this without changing a lot of code, I think you have to allow it to load the cache, but you can make it fail each time it looks there.  Probably the simplest thing to do would be to store -1 in the AtCacheOop field when you load the cache, then it will never match, but the entry can still be used by code that has a valid atIndex].


> >		int remapBuffer[26];
>
>I know nothing about this.

It doesn't help at all to make this bigger than necessary, but it's disastrous if it isn't big enough.  It holds a stack (that is not checked for overflow!) of oops to handle code patterns like...

	interpreterProxy pushRemappableOop: ffiRetClass.
	retOop _ self ffiCreateReturnOop: retVal.
	ffiRetClass _ interpreterProxy popRemappableOop.

In this case ffiCreateReturnOop could cause a GC, and thus invalidate the value of ffiRetClass.  By pushing it into this buffer and then popping it back out, one is assured that if a GC does take place, an updated opp will be returned by the pop.

[In reviewing this code I think I'd figure some low-overhead way to check for overflow here.  I don't think there are many places where this is time-critical and it would be an *awful* bug to track down].

Hope this helps.

	- Dan