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@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