> 	I now have two additional bytes in the trailer of each 
> compiled method; I'm using one bit for the method activation
> mark I mentioned previously (which supports method unloading),
> and fifteen bits for an ID.

That reminds me of something I have thought about a while ago: The current
"source pointer" encoding is both awkward and far from being optimal as it
uses source code positions and therefore wastes _lots_ of space inbetween
two methods. Considering that a method representation in the changes file
can't be smaller than

! methodsFor: '' stamp: ''!
! !

(which just happens to be 32 ;) it means that we'll be wasting _at least_ 5
bits of the (comparedly) sparse range in the changes file (and this is both
unrealistically small and not counting the waste of bits for the .sources
which we never fill up). Given that this is the case it might _just_ be a
Good Idea (tm) to associate a 16 bit method id (or possibly 15+1) with the
method, and leave it to whatever the associated "method home" is to deal
with handing out (potentially variable length) keys for some method. E.g.,
that (in lack of a better word) MethodHome would hand out a key that should
be associated with the CM and is then responsible to retrieve the source
code accordingly.

While this in itself may not automatically be more compact than the current
source encoding it would open up the ability to use source code repositories
other than the sources and changes file, including (for example) .sar or
.mcv repositories. This would also reduce the currently exploding growth of
the changes file when you load something from SM. I could imagine that
PackageInfo could be a pretty good candidate for that MethodHome.

Cheers,
  - Andreas