CompiledMethod source access cleanups, questions on #trailer etc

tim Rowledge tim at rowledge.org
Sat Oct 14 00:30:05 UTC 2006


I'm trying to do a minimal cleanup on how compiled methods access  
source as stage one of getting towards a new compiled method format.  
So far it has been somewhat painful due in no small part to the  
horrors of how many bits of code explicitly assume the sources being  
in files.

I've moved all the source pointer stuff from the 'stick some extra  
bytes at the end of the method' approach to a 'have a proper oop in  
properties' one. This is nicer and will allow us to have 256Mb  
sources and changes files. Given the apparent propensity for the  
changes file to get overloaded with doit text (see recent mails on  
that problem) this might be quite useful! With further cleanups we  
can get away from the nasty assumption about files and use well  
encapsulated source accessors instead of excapsulated ones.

Right now I'm trying to do some cleanup of all the peripheral grunge  
to do with this change. For example the users of #trailer, #generate:  
etc. So far as I can work out new methods are compiled with a default  
trailer of #(0 0 0 0) and then the source pointer is set shortly  
after; this is easy to change. It looks like assorted recompiles use  
a shortcut of grabbing the old CM trailer bytes and passing those to  
#generate: directly. That I can change to grab source pointer and set  
in new CM instance.

The question I need to feel I have a good answer to is whether anyone  
is doing other nasty things with method trailers?  I hope not, I  
think not, but I'm not sure not.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: DO: Deadstart Operator





More information about the Squeak-dev mailing list