<br><br><div class="gmail_quote">On Tue, Jan 31, 2012 at 12:41 PM, Mariano Martinez Peck <span dir="ltr"><<a href="mailto:marianopeck@gmail.com">marianopeck@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><br><div class="gmail_quote">On Tue, Jan 31, 2012 at 9:28 PM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><br><div class="gmail_quote">On Tue, Jan 31, 2012 at 12:19 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com" target="_blank">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
On 31 January 2012 20:50, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Tue, Jan 31, 2012 at 11:22 AM, Mariano Martinez Peck <<a href="mailto:marianopeck@gmail.com" target="_blank">marianopeck@gmail.com</a>> wrote:<br>
>><br>
>><br>
>> Hi Eliot. Me again :) I was checking the changes Igor did some time ago for the fast become where he basically swapped the bytes contents between the objects when they were the same size and same header type. He put such code in separate primtives and some changes in the image side to call them. I have just played with them and they seem to work. I have 2 questions for you:<br>
>><br>
>> 1) Do you think that this new fast become can have problems when becoming CompiledMethods? I am asking because of the JIT/Pic. Maybe I need a flushCache or something?<br>
><br>
><br>
> Yes, almost certainly. You'd want to do a flushCache on both methods.<br>
><br>
</div>are there other object types which we need to be careful with?<br></blockquote><div><br></div><div>There are a few. e.g. the Array literals in named primitives (because they hold target function pointers). CompiledMethods (because they may have associated machine code). Contexts (because they may have associated stack frames).</div>
<div> </div></div></blockquote><div><br>Eliot, I don't understand why we have these problems with the "fast become" but not with the normal one. What happens wich each of your examples with the normal become? how are they solved?<br>
</div></div></blockquote><div><br></div><div>The "slow" become is implemented in terms of the GC's pointer-forwarding mechanism, which is used in normal garbage collection, not just become. This machinery is the ObjectMemory>remap: machinery. The JIT implements the same mapping machinery for literal objects embedded in machine code. These include not just literals but also classes in inline-caches. So it would seem that implementing markObject: and remap: for literals in jitted methods is all one needs to support GC and become:. In fact, life is more complex because there is an optimization in the JIT to avoid scanning all of machine code on incremental GC. The jit maintains a list of those methods that contain references to young objects and only scans this list on an incremental GC, and this list must be maintained correctly. Hence there are three different remap routines in the jit, </div>
<div><br></div><div><div>Cogit>mapObjectReferencesInMachineCodeForIncrementalGC</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>"Update all references to objects in machine code for an incremental gc.</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span> Avoid scanning all code by using the youngReferrers list. In an incremental</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> GC a method referring to young may no longer refer to young, but a method</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span> not referring to young cannot and will not refer to young afterwards."</div></div><div><br></div><div>Cogit>mapObjectReferencesInMachineCodeForFullGC</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>"Update all references to objects in machine code for a full gc. Since</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> the current (New)ObjectMemory GC makes everything old in a full GC</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span> a method not referring to young will not refer to young afterwards"</div><div><br></div><div><br></div><div>Cogit>mapObjectReferencesInMachineCodeForBecome</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>"Update all references to objects in machine code for a become.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> Unlike incrementalGC or fullGC a method that does not refer to young</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span> may refer to young as a result of the become operation."</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>
Sorry for the noob question.<br></div></div></blockquote><div><br></div><div>It's a good question :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div><br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
because i was thinking to just put a check in fast-become prim and<br>
simply fail the prim if object type(s) to be swapped are not<br>
supported, so user will be forced to use slow good-old #become:<br></blockquote><div><br></div><div>I agree. But you can do even better, by checking that the compiled method has a machine-code version, and/or checking that a context is "single" (has no associated stack state). It doesn't need to fail if there isn't any special state. Identifying the named primitive linking literals is more difficult...</div>
<div><br></div></div></blockquote><div><br>Ideally, I would love to be able to do the fast become for all of them, even if that implies doing something extra for special cass (like flushing method cache).<br></div></div>
</blockquote><div><br></div><div>As they say, don't get caught.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail_quote"><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<font color="#888888"><br>
--<br>
Best regards,<br>
Igor Stasenko.<br>
</font></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>
<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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>