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

[Andreas Raab]

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 
> <mailto: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/00095083/attachment.htm