Path: utzoo!attcan!uunet!peregrine!elroy!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!uicbert.eecs.uic.EDU!wilson
From: wilson@uicbert.eecs.uic.EDU (Paul Wilson)
Newsgroups: comp.lang.scheme
Subject: dynamic compilation for scheme, with inlining, etc?
Message-ID: <8809142159.AA28551@uicbert.eecs.uic.edu>
Date: 14 Sep 88 21:59:11 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 40

I've been thinking about using dynamic compilation for Scheme,
and wondering if anybody else is.  Have people abandoned the idea
of dynamic compilation, and if so, was it premature?

Some of the advantages might be:

   1) portability images could still run fast
   2) an optimizer could be called in to optimize those chunks of
      code that are ACTUALLY executed a bunch of times.
      (rather than just optimizing the time/space tradeoff between
       interpreted and compiled code, it could be used to adjust
       compile time/run time tradeoffs.)
   3) Transparent, automatic compilation and optimization.

   In particular, I'm thinking about a scheme in which inlining would
be done automatically, but dependencies would be recorded.  If somebody
changed the value of an inlined procedure or constant, the code
depending on those values would be invalidated and dynamically
recompiled at runtime.
   (The mechanism for this depends on near-lexical-scoping.  Procedures
that are never redefined in a lexically apparent way could be inlined.
Primitives that can modify things (like first-class environments) in
non-lexically-apparent ways would have to check for dependencies.)

   Anybody care to comment on this idea?  In particular, is there some
irreducible cost of dynamic compilation that I don't know about?  Any
advantages?

   (It seems to me that you might dynamically determine what types of
arguments frequently-executed procedures were frequently called with.
You could then compile special versions for the common combinations.
A large-grained check would dispatch to the proper version, within
which most type checking could be eliminated using type inference.
Would this be workable/worthwhile?)


Paul R. Wilson                         
Human-Computer Interaction Laboratory
U. of Illin. at C. EECS Dept. (M/C 154)   wilson%uicbert@uxc.cso.uiuc.edu
Box 4348   Chicago,IL 60680