<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hello,</div><div class="gmail_quote"><br></div><div class="gmail_quote">2013/12/13 Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">
On Fri, Dec 13, 2013 at 1:07 PM, askoh <span dir="ltr"><<a href="mailto:askoh@askoh.com" target="_blank">askoh@askoh.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
I am not a VM guy. But, is the Smalltalk in a C World article compiling<br>
Smalltalk to machine code to run without the VM?<br>
<a href="http://www.cl.cam.ac.uk/~dc552/papers/SmalltalkInACWorld.pdf" target="_blank">http://www.cl.cam.ac.uk/~dc552/papers/SmalltalkInACWorld.pdf</a><br>
<br>
He talks about the VM being a relic of the past. Is that true?<br></blockquote><div><br></div><div>Is the Java VM a relic of the past? Given portable devices is compiled code a relic of the past? Is a safe development environment with fast compile times a thing of the past? Their own conclusions imply that the answer is not yet:</div>
</div></div></div></blockquote><div><br></div><div>What do you mean by not yet ? Do you think that in a 10 or 20 years VMs will be obsolete ? </div><div><br></div><div>There's 1 detail I am not sure. By JIT in this article (<a href="http://m.pocketnow.com/2013/11/13/dalvik-vs-art" target="_blank" style="font-size:13px;font-family:arial,sans-serif">http://m.pocketnow.com/2013/11/13/dalvik-vs-art</a>), does he mean the bytecode to native code generator only or the native code generator + inline cache management + adaptive recompiler. </div>
<div><br></div><div>I'm wondering, even if they have their code stored as native code instead of byte code, do they have some kind of native code generator for adaptive recompilation to reach such a performance ? </div>
<div><br></div><div>And how do they manage their inline caches ? As all methods are native, some monomorphic inline caches could be promoted to PIC due to 1 very rare case and then as they always keep the same n-code this send site would be slower forever. Does this mean they would need to empty inline caches sometimes ?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><br></div><div>"Our current approach lacks some of the advantages of Smalltalk. The most obvious of these is debugging. Our current implementation emits very sparse DWARF debugging information and so is fairly limited in terms of debugging support even in comparison to C, and therefore a long way behind the state of the art for Smalltalk circa 1980. This is currently the focus of ongoing work. Once this is done, then implementing things like thisContext making use of debug metadata become possible. In our current implementation, run-time introspection is only available for objects and variables bound to blocks, not for activation records.</div>
<p>Closely related is the rest of the IDE. In traditional Smalltalk implementations, the IDE is closely integrated with the execution environment. GNU Smalltalk is the major exception, and provides a model close to ours. Building a good IDE and debugger is beyond the scope of the LanguageKit project, but building these tools on top of LanguageKit is a goal of E ́toile ́."</p>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
All the best,<br>
Aik-Siong Koh<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://forum.world.st/Dalvik-vs-ART-Android-virtual-machines-and-the-battle-for-better-performance-Pocketnow-tp4729727p4729982.html" target="_blank">http://forum.world.st/Dalvik-vs-ART-Android-virtual-machines-and-the-battle-for-better-performance-Pocketnow-tp4729727p4729982.html</a><br>
Sent from the Squeak VM mailing list archive at Nabble.com.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>
<br></blockquote></div><br></div></div>