What happens with named primitives in CM ?

 

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

 

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 <[hidden email]> 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