Why does every method get sent a #methodClass:

I'm guessing this is related to Traits but I'd be very interested to  
know why it is neccessary to add to the size of *every* method in the  
system.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: RBR: Remove Bits Randomly

> I'm guessing this is related to Traits but I'd be very interested to
> know why it is neccessary to add to the size of *every* method in the
> system.

No, it has nothing to do with Traits. It is there to make the system
much faster. All the senders of #who and related methods (the
refactoring browser is one of the heavy users) used to be utterly
slow.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

Equally important, the method class normalizes the format of
CompiledMethod with respect to method properties. Before adding the
method class for each method, methods with super-sends would store their
properties in the next-to-last literal, those without in the last. Which
is a pain to maintain. Plus, there are some situations where the ability
to reason about the origin of a loose compiled method (e.g., one not
stored in any method dictionary due to recompilation) is critical for
being able to persist them correctly (like when you try to determine
whether that compiled method will crash your system after loading it
back in since it accesses iVars beyond the end of the object). All in
all, I'm a big fan of these particular changes - they make many things
trivial that would be somewhere between hard to near impossible
otherwise. At the cost of four  (if you could method properties eight)
bytes per compiled method which -to me- seems a reasonable tradeoff in
this case.

Cheers,
   - Andreas

Lukas Renggli wrote:

Tx!
This makes a lot of code much simpler and faster (the usual speed/
complexity/memory tradeoff).

Fair enough; so why not include the class in the properties?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
A computer's attention span is only as long as its extension cord.

On 27.09.2006, at 17:19, tim Rowledge wrote:

> Fair enough; so why not include the class in the properties?
>

because we need a place to store the properties... and CompiledMethods
are strange objects (there was a patch from you almost 10 years ago that
fixed that, yes... "Kids first", I guess). So we need to save the  
properties in some
entry of the literal frame. Now the first is already used in some  
methods (when
they have named prims), the last is used sometimes (when there is a  
super).

So we can use either the 1st/2nd or the 2nd last/last, depending on the
layout. Both would need a runtime check, in case of the super-send even
one that has to iterate over all bytecode. So not good.

So Andreas suggested to just put a class binding in the last literal,
regardless if there is a super send ot not. And indeed, this was a  
clever
idea: 1) we have now a fixed offset for the properties (they are  
always in the
2nd last literal and 2) it even costs nothing in space, as we would  
have wanted
to have the method know it's class anyways, so we would have put it  
in a property,
as you suggested.

This now is not the case, which might be not 100% nice, but good  
enough. In a real
OO design, we would have instVars for class and selector in  
CompiledMethod. Having
them as properties is not really a goal in itself.

Properties are nice, but if Morphic told us one lesson: Don't use  
them too much, as
they hide the Design completely and make thus the code un-
maintainable (they
are like dynamicallky bound variables, just for instVars, not Temps...)
Or does anyone claim to understand BookMorph?

So... next step would be to actually fix the VM to make  
CompiledMethods normal
Objects and clean the mess up even more.


     Marcus