Hello.. I'm pretty sure that squeak fairly severely overinlines, in that
in some places, its a good idea to inline a function and in other places
it is not a good idea, because inlining in the other places leads to code
bloat.


As my first attempt at it, I've attempted to build an interpreter with NO
inlining. I have succeeded, although, with three problems:
  1. A lot more compiler warnings from casting from int to pointer.
  2. ../src/unix/util/gnuify  has a check for no inlining, and fails. This
had to be removed.

  3. The following function, the '******' line is wrong. I'm not sure how
to fix this; I just hacked the generated C file.

context: thisCntx hasSender: aContext
	"Does thisCntx have aContext in its sender chain?"
	| s nilOop |
	self inline: true.
	thisCntx == aContext
		ifTrue: [^ false].
	nilOop _ nilObj.
	s _ self fetchPointer: SenderIndex ofObject: thisCntx.
	[s == nilOop]
		whileFalse: [s == aContext
				ifTrue: [^ true].
			s _ s self fetchPointer: SenderIndex ofObject: s].
                           ***********************************************
	^ false

-- 

The slowdown is almost 20x, but it does give a lot of detail. The good
news:  I don't think squeak is doing too much overinlining, there are only
a dozen functions which I saw in the profile looked like they could be
overinlined, maybe 20-40 times between them:

  assertClassOf fetchClassOf fetchClassOfNonInt lengthOf
  lengthOfbaseHeaderformat firstIndexableField stackObjectValue
  storePointerofObjectwithValue isBytes

Most of the overinlining sites are where these are called by extra
plugins.

The other good news is that you do not have to declare everything in the
interpreter to be inlined.

The bad news was that I didn't find anything glaringly bad with it. I wish
I had; it would be useful.

--

Oh, BTW, I did a 20 minute session with my new methodcache code (published
earlier) With 8192 slots, the first probe has a hit rate of 90%, and the
cache itself has an overall hit rate of 99.85.