On Fri, 23 Jun 2006 11:44:05 +0200, Edgar wrote:
> Klaus D. Witzel puso en su mail :
>
>> That output is from a non 3.9 image. On a 3.9 image you would see that  
>> the
>> debugger benefits from the implementation of traits, it has better means
>> for finding out which class and selector a method is actually used at
>> run-time. Here's the difference:
>
> Karl, here is the same on new 7035.

Looks good :)

> I have a question now.
> Could be possible have something like your exercise on non Traits image ?

Sure. The demo only *looks* nicer on images with 3.9 traits. The  
functionality does not depend on traits.

> What is needed on image if VM what follows Blue Book have this unknown  
> (to
> me) power ?

Three things:

1 - a way to access " thisContext sender ", " thisContext sender method ",  
" thisContext sender method literals " (this is in #switchSenderToParent:  
in my examples). inspect the three quoted expressions on Squeak and on the  
other VM and compare for differences. the literals must be accessible for  
read and write. this is usually the case when, since Smalltalk/2.x,  
support for the debugger is present (can do stack manipulation, code  
execution simulation, etc, all needed in support of a decent debugger). so  
these base functions exist for us for being reused :-)

2 - a guarantee that the VM does indeed follow the Blue Book for super  
sends. the compiler knows this and puts the class in which a method was  
compiled into the method's last literal (you should have seen that when  
you inspected the above expressions), from where the VM then starts lookup  
when it interpretes the super send bytecode.

3 - a means to make use of " [...] onDNU: #symbol do: [...] ". this is the  
classic #doesNotUnderstand: aMessage case wrapped into a convenient  
#onDNU:do: which either is already available in some form on the other VM  
or can be implemented to have the same functionality. my examples do not  
make use of any specific features of the exception passed to #onDNU:do:,  
so an implementation on another VM shouldn't be impossible.

> Very, very thanks

:)

> Edgar

Thank you Edgar for the feedback.

/Klaus

>  - 757 tallies, 764 msec.
>
> **Tree**
> 99.7% {762ms} CaffeeWithMilk>>veryMuchSugar
>   64.2% {490ms} CaffeeWithMilk(SugarService)>>sugar
>     |63.5% {485ms} ProcessorScheduler>>nextReadyProcess
>     |  32.0% {244ms} LinkedList>>isEmpty
>     |  29.2% {223ms} Array(SequenceableCollection)>>reverseDo:
>   18.8% {144ms} CaffeeWithMilk(Object)>>doesNotUnderstand:
>     |14.5% {111ms} MessageNotUnderstood(Exception)>>signal
>     |  |13.1% {100ms} MethodContext(ContextPart)>>handleSignal:
>     |  |  4.1% {31ms} MethodContext>>tempAt:
>     |  |  2.8% {21ms} MessageNotUnderstood class(Exception  
> class)>>handles:
>     |  |  2.4% {18ms} BlockContext>>ensure:
>     |  |    2.1% {16ms} primitives
>     |2.5% {19ms} primitives
>   9.8% {75ms} CaffeeWithMilk(SuperclassX)>>internalSwitchSenderToParent:
>     |2.8% {21ms} CompiledMethod>>numLiterals
>     |2.2% {17ms} UndefinedObject(Object)>>->
>     |2.2% {17ms} primitives
>   5.5% {42ms} BlockContext>>onDNU:do:
> 
> **Leaves**
> 32.2% {246ms} LinkedList>>isEmpty
> 29.2% {223ms} Array(SequenceableCollection)>>reverseDo:
> 4.1% {31ms} MethodContext>>tempAt:
> 3.0% {23ms} BlockContext>>ensure:
> 2.5% {19ms} CaffeeWithMilk(Object)>>doesNotUnderstand:
> 2.2% {17ms} CaffeeWithMilk(SuperclassX)>>internalSwitchSenderToParent:
>
> **Memory**
>     old            +0 bytes
>     young        -31,428 bytes
>     used        -31,428 bytes
>     free        +31,428 bytes
>
> **GCs**
>     full            0 totalling 0ms (0.0% uptime)
>     incr        85 totalling 86ms (11.0% uptime), avg 1.0ms
>     tenures        0
>     root table    0 overflows
>