<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 9:05 PM, Eliot Miranda
wrote:<br>
</div>
<blockquote
cite="mid:CAC20JE3MrHDQCp7nGmiu7EQjVbyS4GPZrNBhPOTZhRSAqnwp8w@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>
<div class="gmail_quote">On Mon, Nov 4, 2013 at 12:30 PM,
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>
<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
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">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? 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?<br>
<br>
Regards,<br>
Florin<br>
</body>
</html>