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

[Eliot Miranda]

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).


> 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...


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



-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120131/639e1581/attachment-0001.htm