Ahhh, back on the net at last... thank you @home for a wonderful
learning experience in patience and the thrilling 'hold' music repetiore
:-)

 Anthony Hannan <ajh18 at cornell.edu> is widely believed to have
written:

> New CompiledMethod format:
> I did consult Tim's web page about new CompiledMethod format early on
> and as a result included it in my new CompiledMethods.  CompiledMethod
> is now a regular pointer object with 3 inst vars (header, bytecodes,
> trailer) and indexable fields for literals.  bytecodes points to a
> ByteArray.  And trailer points to a ByteArray encoding the source
> pointer as before, but this can easily be renamed and changed to
> something more readable.
Excellent choice. Even better, it saves me having to redo that work
again.
The interesting pointabout having the new compiled method format is that
you can have any one of a wide range of source code handling measures
installed; a simple number that is encoded in the same way as the
trailer bytes now in use, a string-holder that keeps the source
in-image, an object that fetches source from a server somewhere, a
compressed-string-holder, a partial decompiling holder (ie keep the temp
names and decompile the rest), whatever.

Another possible improvement IanP asked for some time ago was to keep
the closure bytecodes in separate 'methods' as VW does. He felt it would
make life somewhat nicer for the jitter stuff.

There is a single awkward part of the new format. One has to make a
decision about the balance between flexibility and performance.

One option is to have the vm work out the offset to the indexable fields
(ie the literals) for each method. This means you can easily add new
instvars and everything keeps working all the time.

The other option is to hard code that offset in the vm and thereby gain
a few points of performance at the costs of being able to add new
instvars easily.

Life's tough, eh?

tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Useful random insult:- Had a head crash.