[Vm-dev] What happens with named primitives in CM ?

[Mariano Martinez Peck]

Excellent point. Thanks Andreas. I am serializing to disk a CM and I want to
be sure it will work when I materialize it and load back later on in an
image (it can be even a different image). So, I guess that the
externalPrimitiveTable can change and even more the module of such named
primitive may not be loaded at that time.

So, it is correct so assume that the safest approach is to put a zero as
function index ?  this way it will always work?

Thanks!

Mariano

On Mon, May 23, 2011 at 10:09 AM, Andreas Raab <andreas.raab at gmx.de> wrote:

>
>  See the comment in Interpreter>>primitiveExternalCall.
>
> primitiveExternalCall
>     "Call an external primitive. The external primitive methods
>     contain as first literal an array consisting of:
>     * The module name (String | Symbol)
>     * The function name (String | Symbol)
>     * The session ID (SmallInteger) [OBSOLETE]
>     * The function index (Integer) in the externalPrimitiveTable
>     For fast failures the primitive index of any method where the
>     external prim is not found is rewritten in the method cache
>     with zero. This allows for ultra fast responses as long as the
>     method stays in the cache.
>     The fast failure response relies on lkupClass being properly
>     set. This is done in
>     #addToMethodCacheSel:class:method:primIndex: to
>     compensate for execution of methods that are looked up in a
>     superclass (such as in primitivePerformAt).
>     With the latest modifications (e.g., actually flushing the
>     function addresses from the VM), the session ID is obsolete.
>     But for backward compatibility it is still kept around. Also, a
>     failed lookup is reported specially. If a method has been
>     looked up and not been found, the function address is stored
>     as -1 (e.g., the SmallInteger -1 to distinguish from
>     16rFFFFFFFF which may be returned from the lookup).
>     It is absolutely okay to remove the rewrite if we run into any
>     problems later on. It has an approximate speed difference of
>     30% per failed primitive call which may be noticable but if,
>     for any reasons, we run into problems (like with J3) we can
>     always remove the rewrite.
>     "
>
>
> On 5/23/2011 10:03, Mariano Martinez Peck wrote:
>
>
>
> Hi folks. I was inspecting for example the CM of  Integer >> #bitAnd:   and
> the first literal is an array like this: #(#LargeIntegers #primDigitBitAnd 0
> 17)
>
> I understand the first and the second elements, but I don't the third and
> the fourth. What are they? (0 and 17) because then even seem to change their
> value.
>
> I am asking because I am serializing CompiledMethod and then at
> materialization time I am putting just two zeros for the moment. But I am
> not sure what they mean.
>
> Thanks in advance,
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110523/65d289f7/attachment-0001.htm