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.<br>
<br>So, it is correct so assume that the safest approach is to put a zero as function index ? this way it will always work?<br><br>Thanks!<br><br>Mariano<br><br><div class="gmail_quote">On Mon, May 23, 2011 at 10:09 AM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <br>
<div bgcolor="#ffffff" text="#000000">
See the comment in Interpreter>>primitiveExternalCall.<br>
<br>
primitiveExternalCall<br>
"Call an external primitive. The external primitive methods <br>
contain as first literal an array consisting of: <br>
* The module name (String | Symbol) <br>
* The function name (String | Symbol) <br>
* The session ID (SmallInteger) [OBSOLETE] <br>
* The function index (Integer) in the externalPrimitiveTable <br>
For fast failures the primitive index of any method where the <br>
external prim is not found is rewritten in the method cache <br>
with zero. This allows for ultra fast responses as long as the <br>
method stays in the cache. <br>
The fast failure response relies on lkupClass being properly <br>
set. This is done in <br>
#addToMethodCacheSel:class:method:primIndex: to <br>
compensate for execution of methods that are looked up in a <br>
superclass (such as in primitivePerformAt). <br>
With the latest modifications (e.g., actually flushing the <br>
function addresses from the VM), the session ID is obsolete. <br>
But for backward compatibility it is still kept around. Also, a
<br>
failed lookup is reported specially. If a method has been <br>
looked up and not been found, the function address is stored <br>
as -1 (e.g., the SmallInteger -1 to distinguish from <br>
16rFFFFFFFF which may be returned from the lookup). <br>
It is absolutely okay to remove the rewrite if we run into any <br>
problems later on. It has an approximate speed difference of <br>
30% per failed primitive call which may be noticable but if, <br>
for any reasons, we run into problems (like with J3) we can <br>
always remove the rewrite. <br>
"<br>
<br>
<br>
On 5/23/2011 10:03, Mariano Martinez Peck wrote:
<blockquote type="cite">
<pre> </pre>
<br>
<fieldset></fieldset>
<br>
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)<br>
<br clear="all">
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.<br>
<br>
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.<br>
<br>
Thanks in advance,<br clear="all">
<br>
-- <br>
Mariano<br>
<a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br>
<br>
</blockquote>
</div>
<br></blockquote></div><br><br clear="all"><br>-- <br>Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br><br>