[Vm-dev] Powerful JIT optimization

David Ungar ungar at me.com
Tue Nov 5 03:53:20 UTC 2013


It was different in Self; we originally had no branch bytecodes. Looping was done with a single _Restart primitive, and all control structures were done with blocks. So value methods were always involved. Not so in (Blue Book) Smalltalk.

- David


On Nov 4, 2013, at 9:05 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:

> Hi Florin,
> 
> On Mon, Nov 4, 2013 at 12:30 PM, Florin Mateoc <florin.mateoc at gmail.com> wrote:
>  
> 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> 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
> 
> No it's not.  If you read my design sketch on bytecode-to-bytecode adaptive optimisation you'll understand that it's not.  It's simply that one can do bytecode-to-bytecode adaptive optimisation in the image, and that that's a better place to do adaptive optimisation than in the VM.  But again I've gone into this many times before on the mailing list and I don't want to get into it again.
> 
> Cheers,
> Florin
> 
> -- 
> best,
> Eliot

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20131104/390e2850/attachment.htm


More information about the Vm-dev mailing list