[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