<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/4/2013 3:07 PM, Eliot Miranda
wrote:<br>
</div>
<blockquote
cite="mid:CAC20JE3WbR8a_r3ieMm_ykVz4Z-GeYyLrQfG_s1ENY8ZY11agQ@mail.gmail.com"
type="cite">
<pre wrap=""> </pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<div dir="ltr">Hi Florin,<br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Mon, Nov 4, 2013 at 7:09 AM,
Florin Mateoc <span dir="ltr"><<a moz-do-not-send="true"
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 moz-do-not-send="true"
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">
<br>
Regards,<br>
Florin<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
best,
<div>Eliot</div>
</div>
</div>
</blockquote>
<br>
<br>
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>
<br>
Cheers,<br>
Florin<br>
</body>
</html>