I've been looking at this code a while and whilst I congratulate  
Klaus on his valiant attempt to solve the file size problem I think  
we need to take a step back and try to clean things up a bit more.

The problem here is that we have an extraordinary mess in our source  
pointer methods. It mostly stems from 'temporary' attempts to survive  
the problems of having source pointed to by four bytes stuck to the  
end of a nasty design of a hybrid object type that ought to have  
disappeared in 1998 after I first wrote the code to convert them to  
proper objects. If we stick any more patches on top of this nonsense  
we are in danger of looking like a part decomposed ancient egyptian  
mummy.

Let's spend a little time and effort working out what we would like  
to end up with and then a way to get there from here.

I would like to propose a fairly complete overhaul of CompiledMethod  
and its friends. Get rid of the hybrid object format (which would  
simplify the gc code a little too) and define CMs as
bytecodes
literals
sourceaccess
methodClass
...whatever other properties are needed...

ie a plain object with named instance variables. A slight alternative  
that might be considered is for the literals to be indexed vars  
following the named ones (think OrderedCollection if this is not  
familiar to you).

We would lose the algorithmic gymnastics about last literal is the  
class, second to last is the properties, first is the recipe for  
today's soup dish, etc.

The source code access would be through any object understanding a  
small protocol along the lines of 'get source', 'setSourceTo:'  
and .... err, I think that's it. Again, back in '98 I demonstrated a  
system that used this and had example accessors that used a file, an  
encoded file, a plain string, a compressed string and a damp string.  
Using a database or a networked method source server or a connection  
to another image which held the source in some other way would all be  
possible.

The cost is a loss of backwards compatibility for the image. Maybe it  
would be possible to make a vm that would run old images as well as  
new ones but I suspect it would cost some performance and I'm sure it  
would cost some tedious maintenance tax. You may not care about that  
but *I* sure do! Maybe it would be better to just abandon the current  
image lineage and jump ship to build this purely on top of Spoon?  
Maybe nobody cares?

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: SEXI: Sign EXtend Integer