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

Eliot Miranda eliot.miranda at gmail.com
Wed Mar 13 23:13:44 UTC 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130313/ea3fcb93/attachment.htm


More information about the Vm-dev mailing list