self send inliner (was: [Enh][VM] primitiveApplyToFromTo for the heart of theenumeration of collections?)

Bryce Kampjes bryce at kampjes.demon.co.uk
Mon Sep 18 22:48:49 UTC 2006


Avi Bryant writes:
 > 
 > On Sep 18, 2006, at 12:48 PM, Jecel Assumpcao Jr wrote:
 > 
 > > Avi Bryant wrote:
 > >> Has anyone ever played with a simple self-sends inliner?  No de-
 > >> inlining when debugging, no post-inlining optimization, no attempt to
 > >> deal with polymorphism, just inlining monomorphic self-sends...
 > >
 > > Due to inheritance you do have to deal with polymorphism before you  
 > > can
 > > inline self sends. Unless you want to add Java silliness like "final".
 > 
 > No, of course we don't want "final", but we can always recompile  
 > (without inlining) when someone overrides something we've inlined.   
 > There are enough cases that are never overridden to make the inlining  
 > worthwhile, I think.

>From where I stand it, inlining self sends is almost identical to
inlining general sends with a type test (jump the other way if it's
not the right type).

Type feedback is not hard. You could do it just using the normal
profiler. The profiler does not see primitives though. That's one
reason Exupery has PICs now. At one point I wanted to leave PICs until
after full message inlining.

The hard task is will be figuring out what the stack does across
inlined messages. It's the optimisation of ifTrue:, ifFalse:, and
whileTrue: that makes this hard. The code to do this in Exupery used
to all be in ByteCodeReader. Figuring out what the stack does is not
a hard analysis. Optimisations can make later optimisations harder.

The biggest commercial cost to a stripped down inliner is you loose
the ability to debug in production. That can be a major competitive
advantage. You will also interfere with reflection on contexts unless
you also provide dynamic de-optimisation. 

How-ever inlining byte-code is not going to be that much easier than
inlining intermediate code. Add an inliner to Exupery and it is
architecturally comparable to Strongtalk. The type feedback is all
there now. There is even primitive inlining. (*)

Bryce

(*) Exupery will not get inlining until after 1.0. 1.0 is everything
needed to usefully use inlining except inlining. 1.0 also has to be
useful.



More information about the Squeak-dev mailing list