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

[Mariano Martinez Peck]

Thanks Andreas. We were putting zeros just by chance and that's why it was
working, but we didn't understand why. Now we do.

Cheers

Mariano

On Mon, May 23, 2011 at 2:07 PM, Andreas Raab <andreas.raab at gmx.de> wrote:

>
>  On 5/23/2011 11:14, Mariano Martinez Peck wrote:
>
>
>
> 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?
>
>
> Yes.
>   - A.
>
>
> 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
>
>
>


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