<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 4, 2013 at 8:42 PM, Florin Mateoc <span dir="ltr"><<a href="mailto:florin.mateoc@gmail.com" target="_blank">florin.mateoc@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
<div bgcolor="#FFFFFF" text="#000000">
<div>On 11/4/2013 9:05 PM, Eliot Miranda
wrote:<br>
</div>
<blockquote type="cite">
<pre> </pre>
<br>
<fieldset></fieldset>
<br>
<div dir="ltr">Hi Florin,<br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Nov 4, 2013 at 12:30 PM,
Florin Mateoc <span dir="ltr"><<a href="mailto:florin.mateoc@gmail.com" target="_blank">florin.mateoc@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
<div bgcolor="#FFFFFF" text="#000000">
<div>On 11/4/2013 3:07 PM, Eliot Miranda wrote:</div>
<blockquote type="cite">
<div dir="ltr">Hi Florin,<br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Nov 4, 2013 at
7:09 AM, Florin Mateoc <span dir="ltr"><<a href="mailto:florin.mateoc@gmail.com" target="_blank">florin.mateoc@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Eliot,<br>
<br>
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,<br>
since you were also talking about powerful new
optimizations and this seems a very good
one... I was toying with the<br>
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<br>
level and then communicating somehow with the
VM (this aspect becomes moot if the JIT code
is generated from Smalltalk),<br>
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:<br>
<br>
"On thing that trace based JIT has shown is
that a loop or function are valid optimization
entry points. So like you can<br>
have an inlining cache for function at
callsite, you should have a kind of inlining
cache at the start of a loop."<br>
<br>
This was in the context of a blog entry by
Cliff Click:<br>
<a href="http://www.azulsystems.com/blog/cliff/2011-04-04-fixing-the-inlining-problem" target="_blank">http://www.azulsystems.com/blog/cliff/2011-04-04-fixing-the-inlining-problem</a><br>
The comments also contain other useful
suggestions.<br>
<br>
And, the loop inlining cache could also
specialize not just on the receiver block, but
also on the types of the<br>
arguments (this is true for methods as well,
but, in the absence of profiling information,
loops are more likely to be<br>
"hot", plus we can easily detect nested loops
which reinforce the "hotness")<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>thanks.</div>
<div>e.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Regards,<br>
Florin<br>
</blockquote>
</div>
<br>
-- <br>
best,
<div>Eliot</div>
</div>
</div>
</blockquote>
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<br>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
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?</div></blockquote><div><br></div><div>I doubt it. It already is used to e.g. create clean blocks. This certainly isn't enough of a win to be able to live with a poor GC.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"> If it can, why
doesn't the same argument apply? </div></blockquote><div><br></div><div>It can't so the argument doesn't apply.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">And why did you implement inline
caches in the VM if they were better done in the image?<br></div></blockquote><div><br></div><div>Because they're not better-done in the image. In fact, adaptive optimization is heavily dependent on online caches. That's where it gets its type information form.</div>
<div><br></div><div>This doesn't feel like a productive conversation.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
Regards,<br>
Florin<br>
</div>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>