Should removed classes become Undeclared?

> "Cees De Groot" <[hidden email]> wrote:
>
>> On 2/14/06, Bert Freudenberg <[hidden email]> wrote:
>>> Also, I'd prefer directly publishing to a MC repository rather than
>>> uploading to Mantis.
>>>
>> Absolutely. I'd publish that sort of stuff in my own repository in
>> such a case and add pointers to Mantis.
>
> Er, so should I save the in-image package MCZs to the inbox
> repository? Or
> will whoever manages the inbox grab the MCZs from the Mantis bug
> report?
>
> frank
>
>
>

> stéphane ducasse wrote:
>> Sure cees
>> this is working well for simple package oriented fixes.
>> But now it would be good that we get the changes! Look at the Network
>> team for example. Should frank stack that in the team and we get  
>> something
>> in the future (instead of now and getting done).
>
> Given that this code does neither have any cross-cutting  
> requirements and doesn't even fix anything that's broken I don't  
> see why you have the urge to push this in right now. As a matter of  
> fact, I'm somewhat concerned about these changes and would like  
> them to be reviewed - there are various places where the pattern  
> "foo == 0" is absolutely appropriate and where #= should *not* be  
> used and I wonder whether these places have been taken into account  
> properly.

> > Lazy Activation
>
>I included a slightly related idea in a 4 bit Smalltalk:
>
>http://www.merlintec.com:8080/Hardware/dietST
>
>This had an "enter" bytecode for explicitly creating a new context and a
>"grabArg" bytecode from moving stuff from the sender's bytecode to the
>newly created one. The idea was that the compiler would generate the
>bytecodes for this as late in a method as possible (in the best cases -
>never). This was inspired by the Smalltalks that defer the creation of
>temporary variables until their first assignment. This static solution
>is not as powerful as your dynamic one, but it does have a few things in
>common.

>This project only got as far as a SmaCC compiler for these bytecodes in
>Squeak, so I never got any dynamic statistics for this;
>
>> Cloned Activation
>
>This is what I did in NeoLogo:
>
>http://www.merlintec.com/pegasus2000/e_neologo.html
>
>NeoLogo was just a paper design but this feature was also present in the
>"SuperLogo" which I implemented in 1983 in TI99/4A Extended BASIC. It
>worked great and actually makes the run time simpler at the cost of
>slightly complicating the parser.

>Hi -
>
>I've got my little Squeak in Java running (hope to send out a link soon),
>and I've been pondering how to make it run faster.  In the process, I've
>thought of two techniques, one of which is new (to me) and the other
>occurred to me years ago, but I never tried it out.
>
>Since neither would really be all that hard to do in Squeak, I thought I'd
>mention them here for those folks who delight in such things, and with the
>further hope that someone might actually try them out.
>
>
>Lazy Activation
>This was the next thing I was going to do for Apple Smalltalk back when I
>got drafted to the hotel business back in 1987.  The essence of the idea
>is that the purpose of activating a context is to save the execution state
>in case you have to do a send and, conversely, you don't really need an
>activation if you never need to do a real send.
>
>I had a lot of fun instrumenting the VM to figure out just how many
>activations could be avoided in this way, and my recollection is that it
>was roughly 50%.  I believe the statistics were better dynamically than
>statically, because there are a lot of methods that, in general need to be
>activated, but they may begin with a test such as
>         position > limit ifTrue: [^ false]
>and for every time that this test succeeds, you can get away without ever
>needing an activation.
>
>But, you say, you still need a pointer to the method bytes and a stack
>frame, and this is true, but you don't need to allocate and initialize a
>full context, nor to transfer the arguments.  The idea is that, when you
>hit the send, you do the lookup, find the method, and then jump to a
>*separate copy* of the interpreter that has  a different set of bytecode
>service routines.  For instance, 'loadTemp' will, depending on the
>argument count, load from the stack of the calling method (which is still
>the "active" context).  'Push', since there is no allocated stack, pushes
>into a static array and, eg, 'plus' does the same old add, but it gets its
>args from the static array, and puts its result back there.  And if
>anything fancy, such as a real send, does occur, then a special routine is
>called to do a real activation, copy this static state into it
>appropriately, and retry the bytecode in the normal interpreter.
>
>It's probably worth confirming the results that I remember, but I wouldn't
>be surprised if one could almost double the speed of Squeak in this manner.
>
>
>Cloned Activation
>This one I just thought of, but I can't believe someone hasn't already
>tried it, either in squeak or some similar system.  The idea here is to
>provide a field in the method cache for an extra copy of a properly
>initialized context for the method (ie, correct frame size, method
>installed, pc and stack pointer set, etc).  Then, when a send occurs, all
>you have to do is an array copy into blank storage, followed by a short
>copy of receiver and args from the calling stack.
>
>There's a space penalty for carrying all the extra context templates, of
>course, but I think it's not unreasonable.  Also, one could avoid it for
>all one-time code by only allocating the extra clone on the second call
>(ie, first call gets it into the method cache; second call allocates clone
>for the cache).
>
>I have little sense of how much this might help these days -- I haven't
>looked in detail at the activation code for quite a while. Obviously the
>worse it si right now, the more this technique might help.
>
>
>Mainly I just like to think about this stuff, and it occurred to me that,
>if someone were looking for a fun experiment or two, it might turn out to
>have some practical value.  I haven't looked at Exupery to know whether
>these things are already being done, or whether they might fit well with
>the other techniques there, but I'm sure Bryce could say right off the bat.
>
>         - Dan

> Hi Dan --
>
> Wrt your first optimization ... The SCHEME guys used similar  
> arguments in one or more of the SCHEME papers to show that there  
> are many cases in which no stack has to be allocated or popped (so  
> a simple goto in the code will do the job). Someone on the Squeak  
> list probably has a reference to the paper or papers I'm talking  
> about. Sounds like a good idea, and should work pretty well. The  
> second idea sounds like it should work very well also.
>
> Cheers,
>
> Alan
>
> At 06:11 AM 3/22/2006, Dan Ingalls wrote:
>> Hi -
>>
>> I've got my little Squeak in Java running (hope to send out a link  
>> soon), and I've been pondering how to make it run faster.  In the  
>> process, I've thought of two techniques, one of which is new (to  
>> me) and the other occurred to me years ago, but I never tried it out.
>>
>> Since neither would really be all that hard to do in Squeak, I  
>> thought I'd mention them here for those folks who delight in such  
>> things, and with the further hope that someone might actually try  
>> them out.
>>
>>
>> Lazy Activation
>> This was the next thing I was going to do for Apple Smalltalk back  
>> when I got drafted to the hotel business back in 1987.  The  
>> essence of the idea is that the purpose of activating a context is  
>> to save the execution state in case you have to do a send and,  
>> conversely, you don't really need an activation if you never need  
>> to do a real send.
>>
>> I had a lot of fun instrumenting the VM to figure out just how  
>> many activations could be avoided in this way, and my recollection  
>> is that it was roughly 50%.  I believe the statistics were better  
>> dynamically than statically, because there are a lot of methods  
>> that, in general need to be activated, but they may begin with a  
>> test such as
>>         position > limit ifTrue: [^ false]
>> and for every time that this test succeeds, you can get away  
>> without ever needing an activation.
>>
>> But, you say, you still need a pointer to the method bytes and a  
>> stack frame, and this is true, but you don't need to allocate and  
>> initialize a full context, nor to transfer the arguments.  The  
>> idea is that, when you hit the send, you do the lookup, find the  
>> method, and then jump to a *separate copy* of the interpreter that  
>> has  a different set of bytecode service routines.  For instance,  
>> 'loadTemp' will, depending on the argument count, load from the  
>> stack of the calling method (which is still the "active"  
>> context).  'Push', since there is no allocated stack, pushes into  
>> a static array and, eg, 'plus' does the same old add, but it gets  
>> its args from the static array, and puts its result back there.  
>> And if anything fancy, such as a real send, does occur, then a  
>> special routine is called to do a real activation, copy this  
>> static state into it appropriately, and retry the bytecode in the  
>> normal interpreter.
>>
>> It's probably worth confirming the results that I remember, but I  
>> wouldn't be surprised if one could almost double the speed of  
>> Squeak in this manner.
>>
>>
>> Cloned Activation
>> This one I just thought of, but I can't believe someone hasn't  
>> already tried it, either in squeak or some similar system.  The  
>> idea here is to provide a field in the method cache for an extra  
>> copy of a properly initialized context for the method (ie, correct  
>> frame size, method installed, pc and stack pointer set, etc).  
>> Then, when a send occurs, all you have to do is an array copy into  
>> blank storage, followed by a short copy of receiver and args from  
>> the calling stack.
>>
>> There's a space penalty for carrying all the extra context  
>> templates, of course, but I think it's not unreasonable.  Also,  
>> one could avoid it for all one-time code by only allocating the  
>> extra clone on the second call (ie, first call gets it into the  
>> method cache; second call allocates clone for the cache).
>>
>> I have little sense of how much this might help these days -- I  
>> haven't looked in detail at the activation code for quite a while.  
>> Obviously the worse it si right now, the more this technique might  
>> help.
>>
>>
>> Mainly I just like to think about this stuff, and it occurred to  
>> me that, if someone were looking for a fun experiment or two, it  
>> might turn out to have some practical value.  I haven't looked at  
>> Exupery to know whether these things are already being done, or  
>> whether they might fit well with the other techniques there, but  
>> I'm sure Bryce could say right off the bat.
>>
>>         - Dan
>
>
>

> Hi -
>
> I've got my little Squeak in Java running (hope to send out a link  
> soon), and I've been pondering how to make it run faster.  In the  
> process, I've thought of two techniques, one of which is new (to  
> me) and the other occurred to me years ago, but I never tried it out.
>
> Since neither would really be all that hard to do in Squeak, I  
> thought I'd mention them here for those folks who delight in such  
> things, and with the further hope that someone might actually try  
> them out.
>
>
> Lazy Activation
> This was the next thing I was going to do for Apple Smalltalk back  
> when I got drafted to the hotel business back in 1987.  The essence  
> of the idea is that the purpose of activating a context is to save  
> the execution state in case you have to do a send and, conversely,  
> you don't really need an activation if you never need to do a real  
> send.
>
> I had a lot of fun instrumenting the VM to figure out just how many  
> activations could be avoided in this way, and my recollection is  
> that it was roughly 50%.  I believe the statistics were better  
> dynamically than statically, because there are a lot of methods  
> that, in general need to be activated, but they may begin with a  
> test such as
> position > limit ifTrue: [^ false]
> and for every time that this test succeeds, you can get away  
> without ever needing an activation.
>
> But, you say, you still need a pointer to the method bytes and a  
> stack frame, and this is true, but you don't need to allocate and  
> initialize a full context, nor to transfer the arguments.  The idea  
> is that, when you hit the send, you do the lookup, find the method,  
> and then jump to a *separate copy* of the interpreter that has  a  
> different set of bytecode service routines.  For instance,  
> 'loadTemp' will, depending on the argument count, load from the  
> stack of the calling method (which is still the "active" context).  
> 'Push', since there is no allocated stack, pushes into a static  
> array and, eg, 'plus' does the same old add, but it gets its args  
> from the static array, and puts its result back there.  And if  
> anything fancy, such as a real send, does occur, then a special  
> routine is called to do a real activation, copy this static state  
> into it appropriately, and retry the bytecode in the normal  
> interpreter.
>
> It's probably worth confirming the results that I remember, but I  
> wouldn't be surprised if one could almost double the speed of  
> Squeak in this manner.
>
>
> Cloned Activation
> This one I just thought of, but I can't believe someone hasn't  
> already tried it, either in squeak or some similar system.  The  
> idea here is to provide a field in the method cache for an extra  
> copy of a properly initialized context for the method (ie, correct  
> frame size, method installed, pc and stack pointer set, etc).  
> Then, when a send occurs, all you have to do is an array copy into  
> blank storage, followed by a short copy of receiver and args from  
> the calling stack.
>
> There's a space penalty for carrying all the extra context  
> templates, of course, but I think it's not unreasonable.  Also, one  
> could avoid it for all one-time code by only allocating the extra  
> clone on the second call (ie, first call gets it into the method  
> cache; second call allocates clone for the cache).
>
> I have little sense of how much this might help these days -- I  
> haven't looked in detail at the activation code for quite a while.  
> Obviously the worse it si right now, the more this technique might  
> help.
>
>
> Mainly I just like to think about this stuff, and it occurred to me  
> that, if someone were looking for a fun experiment or two, it might  
> turn out to have some practical value.  I haven't looked at Exupery  
> to know whether these things are already being done, or whether  
> they might fit well with the other techniques there, but I'm sure  
> Bryce could say right off the bat.
>
> - Dan
>