[Vm-dev] Igor's fast become for CompiledMethods in Cog

Tue Jan 31 23:13:29 UTC 2012

On Tue, Jan 31, 2012 at 11:42 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

>
>
>
> On Tue, Jan 31, 2012 at 12:41 PM, Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
>
>>
>>
>>
>> On Tue, Jan 31, 2012 at 9:28 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:
>>
>>>
>>>
>>>
>>> On Tue, Jan 31, 2012 at 12:19 PM, Igor Stasenko <siguctua at gmail.com>wrote:
>>>
>>>>
>>>> On 31 January 2012 20:50, Eliot Miranda <eliot.miranda at gmail.com>
>>>> wrote:
>>>> >
>>>> >
>>>> >
>>>> > On Tue, Jan 31, 2012 at 11:22 AM, Mariano Martinez Peck <
>>>> marianopeck at gmail.com> wrote:
>>>> >>
>>>> >>
>>>> >> 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:
>>>> >>
>>>> >> 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?
>>>> >
>>>> >
>>>> > Yes, almost certainly.  You'd want to do a flushCache on both methods.
>>>> >
>>>> are there other object types which we need to be careful with?
>>>>
>>>
>>> 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).
>>>
>>>
>>
>> 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?
>>
>
> 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,
>
> Cogit>mapObjectReferencesInMachineCodeForIncrementalGC
> "Update all references to objects in machine code for an incremental gc.
>  Avoid scanning all code by using the youngReferrers list.  In an
> incremental
>  GC a method referring to young may no longer refer to young, but a method
>  not referring to young cannot and will not refer to young afterwards."
>
> Cogit>mapObjectReferencesInMachineCodeForFullGC
>  "Update all references to objects in machine code for a full gc.  Since
>  the current (New)ObjectMemory GC makes everything old in a full GC
>  a method not referring to young will not refer to young afterwards"
>
>
> Cogit>mapObjectReferencesInMachineCodeForBecome
>  "Update all references to objects in machine code for a become.
>  Unlike incrementalGC or fullGC a method that does not refer to young
>  may refer to young as a result of the become operation."
>

Aha. Ok. Now I see. So, let me see if I understand. So the problem of
CompiledMethod gets fixed if we flush its cache. Right?
Now...if we always send #mapObjectReferencesInMachineCodeForBecome   after
the "fast become" we will be updating all literals from machine code
methods.
I didn't understand this one "  e.g. the Array literals in named primitives
(because they hold target function pointers)"
What happens with "Contexts (because they may have associated stack
frames)."  ?  should we need to flush somehow or update stack frames?

Thanks!

>
>
>>  Sorry for the noob question.
>>
>
> It's a good question :)
>
>
>>
>>
>>
>>> because i was thinking to just put a check in fast-become prim and
>>>> simply fail the prim if object type(s) to be swapped are not
>>>> supported, so user will be forced to use slow good-old #become:
>>>>
>>>
>>> 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...
>>>
>>>
>> 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).
>>
>
> As they say, don't get caught.
>
>
>>
>>
>>
>>>
>>>> --
>>>> Best regards,
>>>> Igor Stasenko.
>>>>
>>>
>>>
>>>
>>> --
>>> best,
>>> Eliot
>>>
>>>
>>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>>
>>
>
>
> --
> best,
> Eliot
>
>
>

-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120201/2a4d73ff/attachment-0001.htm