Should removed classes become Undeclared?

stéphane ducasse wrote:

> Hi
>
> I wanted to know how this was relating to the way VW treats blocks:  
> clean block [:each | each zork], copy blocks and full blocks.
> Does anybody able to compare?

These are different things. The optimized blocks in VW still require
full context activations, they just avoid issues with references to
their creating context:
A clean block is completely independent of its context, so VW creates
the block at compile time and stores it in the literal frame of the method.
A copying block needs some values from the context which are known not
to be changeable after the block has been created (method receiver and
arguments and variables which are never assigned to after the block's
creation), so these values can be copied into the newly created block,
but the block does not need a reference to its creating context, so that
context does not have to be stabilized when the method returns.
A full block needs a reference to its context, either because it
contains a return or because it reads variables which may change after
its creation, or writes into temporaries outside of its own scope.

In contrast, Dan's scheme does not deal with blocks but activations in
general, and it tries to avoid creating a stack frame if possible. IMO
it is an optimization that should be investigated.

Cheers,
Hans-Martin

Dan Ingalls writes:
 > Bryce Kampjes <[hidden email]> wrote...
 >
 > >My plan current to introduce dynamic method inlining based heavily on
 > >Urs Holzle's Self work to Exupery after finishing a 1.0. That will
 > >completely remove the context creation costs from the most frequently
 > >used sends. Dynamic method inlining has the advantage that it can
 > >eliminate the sends from #do: loops as well as from leaf methods.
 >
 > I agree that inlining is the ultimate way to go here.  You can see lazy activation as a sort of lazy approach to inlining, but inlining is better because it eliminates the lookup and context switch times completely (when possible (which is typically very often)).

Thanks Dan,
Inlining is definitely a key optimisation. For Exupery another
advantage is that it creates large native methods that have enough
code to be able to be classically optimised. Small methods get in
the way of many optimisations. Inlining will provide both a great
speed improvement and also make later optimisations possible.

The lazy activation approach you describe is orthogonal to
inlining. Both ideally would be best. Especially if the lazy context
creation is done along the lines Jecel described by moving the context
creation code forward to the first send. A truly dynamic approach
which lazily creates a context like lazy initialisation risks spending
more time evaluating the context creation checks than was spent
creating the context.

The idea of cloning contexts is effectively the same as creating
custom machine code to generate the context. The advantage of custom
machine code is there is no loop overhead and no branch mispredict
when exiting the loop.

For the interpreter this may be a decent win. The biggest issue is the
speed improvement that Exupery has over the interpreter indicates that
most of the time during sends is being spent outside of context
creation. But if you're after a 10% gain or you've got an engine with
different performance characteristics it could be worth trying.

Bryce

Tx

On 23 mars 06, at 19:44, Hans-Martin Mosner wrote: