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

Mariano Martinez Peck marianopeck at gmail.com
Tue Jan 31 20:41:29 UTC 2012


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?
Sorry for the noob 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).



>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>
>
>
> --
> best,
> Eliot
>
>
>


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


More information about the Vm-dev mailing list