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

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.

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