[squeak-dev] The method trailer format
Michael van der Gulik
mikevdg at gmail.com
Tue Dec 15 20:55:49 UTC 2009
On Tue, Dec 15, 2009 at 9:16 PM, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> 2009/12/15 Michael van der Gulik <mikevdg at gmail.com>:
>> On Sun, Dec 13, 2009 at 4:17 AM, Igor Stasenko <siguctua at gmail.com> wrote:
>>> Here is my proposal for changing the method trailer in order to be
>>> able to encode various stuff to trailer.
>>> Any corrections, suggestions are welcome.
>>> The kind of compiled method trailer is determined by the last byte of
>>> compiled method.
>>> The format is following:
>> Er... yuck.
>> If I were doing this (which, cooincidently, I am at the moment), I
>> would completely separate source code management from CompiledMethod.
>> Trash the CompiledMethod trailer and ignore the temp names. Instead,
>> add a second dictionary to Class which stores the source code pointers
>> ("sourceDictionary" or something). If you don't want source code for a
>> class, you can make it nil.
>> What I'm currently working on is a bit more radical. I'm completely
>> separating source code from it's compiled form. I have PackageSource,
>> NamespaceSource, ClassSource and MethodSource classes which store
>> source code (in the image, not using source files) and contain methods
>> for compiling code, managing code, etc. Then I have Package,
>> Namespace, Class and CompiledMethod classes which only contain what is
>> necessary to run the code and relink themselves into a new image.
> It is not uncommon to have some CompiledMethod not installed in any
> CompiledMethod allInstances reject: [:e | e isInstalled]
> Accessing associated source would become impossible in this scheme
Where would these exist? How would they be used?
More information about the Squeak-dev