[Vm-dev] What happens with named primitives in CM ?
Andreas Raab
andreas.raab at gmx.de
Mon May 23 12:07:45 UTC 2011
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
More information about the Vm-dev
mailing list