[Vm-dev] When Cog should deoptimize CM and when its not?

[Igor Stasenko]

On 11 March 2013 23:19, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> On Fri, Mar 8, 2013 at 2:34 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>>
>> Hi, Eliot & all
>>
>> I was looking at #become: code
>> and did not found the place where it deoptimizing compiled methods to
>> throw away the jited version of it (if it has one),
>> before even trying to do anything with it.
>>
>> i know it pricey, because it should:
>>
>>  - remove CogMethod from JIT zone
>>  - walk the stack and look for all activations of it, and replace
>> native code instruction pointer with bytecode instruction pointer
>>  - fix the compiled method's header
>> (another alternative, if method has activations, i would fail
>> primitive actually, because this is too hard to do things right and
>> very dangerous
>> to play with, as well as it makes little sense )
>>
>> IMO, if we add that, then we could minimize the impact of JIT
>> complexity on #become: and make things work
>> in same way as in stack vm (which is stable ;).
>
> Yes, but I don't want to do this, precisely because it's so expensive
> and complex, /and/ shouldn't happen.  I mean, if you become: a method
> in the interpreter and you change the code there's a good chance it's
> going to break, because the VM can't do anything to map the execution
> state in a context from old method to new.  In other words, it's not
> worth doing anything other than exiting with a useful error message,
> and that's what the VM does now.
>
>
> So I came to the conclusion that it's just not worth the effort to
> deoptimize.  Instead, the VM checks that the code hasn;t changed (e.g.
> only trailer bytes have changed) and if so does the become, and if not
> exits with an error message.  If you really want to do become or
> destructive update on a method (as I do with my breakpoint
> implementation at Cadence) you can use CompiledMethod>voidVMState.
>
> Does that make sense?
>

It does, but still, i think it is safe to #become method which has no
activations,
of course to check that you need to scan stack and void it's cached state..
And if you don't do that, then i would just ban #become operation on
compiled methods
by failing primitive.
I would leave only forward-become <not compiled method> -> <compiled
method> for things like proxies.

At image level, i think it makes no sense to use become <cm>-><cm>
because instead you can install new method in corresponding class +
clearing inline caches, and so, next activation will be on new method,
but existing activations still can keep using old method.

-- 
Best regards,
Igor Stasenko.