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

[Igor Stasenko]

On 12 March 2013 18:43, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
>
> On Mon, Mar 11, 2013 at 7:19 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>>
>>
>> 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.
>
>
> Right.  But the condense sources implementation chose to update in-place and use become, so...  Look, CompiledMethodTrailer generalized adding to methods metadata that needs to be compact very nicely.  But because the data is variable length we need to support become on compiled method, but only in the case where the method is unchanged (literals and bytecodes) up to the start of the trailer data.  And that's what we have now.  So can we rest, smoke a cigarette, have a coffee and move on?

Yes, i was thinking about the same before going to sleep.. condense
sources uses become on CM..
and were one that exposing the bug in become.

> --
> best,
> Eliot
>



-- 
Best regards,
Igor Stasenko.