[Vm-dev] Powerful JIT optimization

Eliot Miranda eliot.miranda at gmail.com
Mon Nov 4 20:07:51 UTC 2013


Hi Florin,


On Mon, Nov 4, 2013 at 7:09 AM, Florin Mateoc <florin.mateoc at gmail.com>wrote:

>
> Hi Eliot,
>
> I am not sure if this is the right moment to bring this up, when you are
> so busy with the new garbage collector, but,
> since you were also talking about powerful new optimizations and this
> seems a very good one... I was toying with the
> idea before, but I did not have the right formulation for it - I was
> thinking of doing it on the image side, at the AST
> level and then communicating somehow with the VM (this aspect becomes moot
> if the JIT code is generated from Smalltalk),
> but now I stumbled upon it on the web and I think it would be better done
> inside the JIT. In Rémi Forax' formulation:
>
> "On thing that trace based JIT has shown is that a loop or function are
> valid optimization entry points. So like you can
> have an inlining cache for function at callsite, you should have a kind of
> inlining cache at the start of a loop."
>
> This was in the context of a blog entry by Cliff Click:
>
> http://www.azulsystems.com/blog/cliff/2011-04-04-fixing-the-inlining-problem
> The comments also contain other useful suggestions.
>
> And, the loop inlining cache could also specialize not just on the
> receiver block, but also on the types of the
> arguments (this is true for methods as well, but, in the absence of
> profiling information, loops are more likely to be
> "hot", plus we can easily detect nested loops which reinforce the
> "hotness")
>

AFAICT this is subsumed under adaptive optimization/speculative inlining.
 i.e. this is one of the potential optimizations in an adaptive optimizing
VM.  Further, I also believe that by for the best place to do this kind of
thing is indeed in the image, and to do it at the bytecode-to-bytecode
level.  But I've said this many times before and don't want to waste cycles
waffling again.

thanks.
e.


> Regards,
> Florin
>



-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20131104/d37d89ae/attachment.htm


More information about the Vm-dev mailing list