[Vm-dev] Powerful JIT optimization

[Florin Mateoc]

On 11/4/2013 9:05 PM, Eliot Miranda wrote:
>  
>
>
> Hi Florin,
>
> On Mon, Nov 4, 2013 at 12:30 PM, Florin Mateoc <florin.mateoc at gmail.com <mailto: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 <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
>
>
> 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.
>

Can't compiler technology (coupled with type inference) also be applied, in the image, to stack
allocation/pretenuring/automatic pool allocation... to simplify the garbage collector and potentially obviating the need
for a performant one in the vm? If it can, why doesn't the same argument apply? And why did you implement inline caches
in the VM if they were better done in the image?

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