[Vm-dev] Powerful JIT optimization

[Florin Mateoc]

On 11/4/2013 3:07 PM, Eliot Miranda wrote:
>  
>
>
> Hi Florin,
>
>
> On Mon, Nov 4, 2013 at 7:09 AM, Florin Mateoc <florin.mateoc at gmail.com <mailto: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


This is a bit like saying that we don't need garbage collection because we can do liveness/escape analysis in the image.
I think there is a place for both sides

Cheers,
Florin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20131104/9ff6f8d9/attachment-0001.htm