native CompiledMethod format

[bryce at kampjes.demon.co.uk]

Gerardo Richarte writes:
 > Hi, for some time I've been wondering how the native code for
 > CompiledMethods is arranged, and I have a few specific questions. Any
 > pointers to info will be very much welcome
 > 
 > Are the native opcodes maintained in Smalltalk objects or in external
 > memory?

Native machine code is stored in external memory. This avoids the
problem with the GC moving it and also allows the memory to be
allocated as executable.

Machine code is generated in a ByteArray then copied into the code
cache (external memory) then reallocated by Smalltalk.

 > and then:
 > 
 > Generally, how are CompiledMethods fixed after a Garbage Collection?
 > 
 > for example, how are references to other objects handled?
 > are calls to other methods somehow inlined (I mean, direct calls, not
 > through lookups), and if so, how are this inlined direct calls solved
 > when native code moves around (if it's stored in Object Memory)

References directly from native code to the image are restricted to
PICs (Polymorphic Inline Caches). Other objects are accessed through a
few well known lookup objects. For instance references to the
CompiledMethod (to look up literals) are held in an Array which is
registered with VM. Then the code just needs to know where the VM
stores the pointer to the Array and the index of the CompiledMethod.

PICs contain the class pointer. When a global GC occurs then all PICs
are cleared removing these references from native code to the object
memory. Exupery will not compile methods in classes which live in
new space to avoid references from compiled code to new space. 

Bryce