[Vm-dev] About primitive for cleaning compiled method cache

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Mar 13 23:56:20 UTC 2013


2013/3/14 Eliot Miranda <eliot.miranda at gmail.com>:
>
> Hi Nicolas,
>
> On Tue, Mar 12, 2013 at 4:54 AM, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
>>
>>
>> As I understand it, there is a nuclear weapon
>> - primitive 89 for cleaning all caches
>> and more chirurgical tools:
>> - primitive 116 for cleaning method cache of a single CompiledMethod
>> - primitive 119 for cleaning method cache for all CompiledMethod
>> corresponding to a given selector
>>
>> Currently, when we replace a CompiledMethod in some MethodDictionary,
>> we call both primitive 116 then primitive 119.
>> As I understand it from image code comments, this was to support old
>> VM that would support either one or the other form.
>> Modern VM (interpreter VM4.x serie, Stack or Cog) are mandatory to run
>> a modern image all implement both forms, so backward support argument
>> is gone.
>> I think it's time to clean some dust.
>> So my question is which one is necessary ?
>>
>> Nicolas
>
>
>
>
> Primitive 119.  Primitive 116 will give bugs.  For example, if we have
>
> Object subclass: #A
>
> A subclass: #B
>
> A foo
>     ^#A
>
> A bar
>     ^self foo
>
> and we evaluate
>     B new bar
>
> then there is an inline cache entry in A>>#bar and an entry in the first-level method lookup cache that says instances of B receiving #foo should execute A>>#foo.  If we add
>
> B foo
>    ^#B
>
> then we haven't changed A>>#foo but the cache entries in A>>#bar and the first-level method cache for B #foo => A>>#foo must still be flushed.  Make sense?
> --
> best,
> Eliot
>

Yes, that's what I suspected and what I wanted to know, because my
ClassBuilder mutation fix allowing redefinition of Parser does use
primitive 116 exclusively.

So 3 more questions to be sure i understood:

1) Do you confirm that primitive 116 does not have to be called at all
if we allways invoke primitive 119?
Since we allways invoke 119 from
Behavior>>basicAddSelector:withMethod: and basicRmoveMethod, that
would mean we can avoid 116

2) Or would primitive 116 allways be enough in case we modify an
already existing compiledMethod, and primitive 119 could be avoided in
this case?
Note that 116 is currently invoked from MethodDictionary at:put: in
this case, but then Behavior>>basicAddSelector:withMethod: calls 116
again and 119.

3) Do 1) and 2) apply to a VM interpreter? (I would say yes, it's
simpler, but I prefer to be cautious).

Nicolas


More information about the Vm-dev mailing list