[DISCUSSION] Is Squeak/Smalltalk able to do this?

John W. Sarkela sarkela at sbcglobal.net
Sat Feb 8 14:41:03 UTC 2003


Sure, though the major caveat is that observation changes things.
The easiest was would be to intercept the message send itself
with a method wrapper. As long as the observation mechanism
doesn't get introspective, Heisenbubbles won't be a problem.
Further, the overhead of the wrapper/intercept mechanism is
deterministic and can be calibrated out of the statistics.

David Caster implemented such an intercept mechanism for
a basic instrumentation framework, I'll see if I can get him to
package this up for Squeak map. Basically, you attach probes
to a set of methods (specified by class and selector). These
probes are attached to an instrument that can capture receiver
and args on the way into the method and return value upon
exit, and do with them what they will. The basic advantages
to this approach is that the code under test has no textual
changes to support observation, nor is the method recompiled.
Further, the implementation has a low overhead that may be calibrated.

I suspect that you would be very interested to read the papers
that Urs Hölze wrote on adaptive optimization based
on his hotspot compiler work, first for Self and subsequently
for Smalltalk and Java.

:-}> John Sarkela


On Friday, February 7, 2003, at 07:59 PM, Doug Clapp wrote:

> Given that Squeak is "reflective," would it be possible
> to write code such that...
>
> -- the system was "watched" as it was exercised, and...
>
> -- attention was paid to which "cases"  (ifTrue/ifFalse)
> were triggered more often, and...
>
> -- the methods were then re-written to have the "most
> likely (often)"if" be placed first in the method, to speed
> up the execution of "most often done things"?
>
> Obviously, this idea could be taken much further...
>
> doug clapp
>



More information about the Squeak-dev mailing list