<div dir="ltr"><br><br><div class="gmail_quote">On Fri, Sep 5, 2008 at 1:30 PM, Stephen Pair <span dir="ltr"><<a href="mailto:stephen@pairhome.net">stephen@pairhome.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 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="Ih2E3d"><div class="gmail_quote">On Fri, Sep 5, 2008 at 3:17 PM, David Griswold <span dir="ltr"><<a href="mailto:david.griswold.256@gmail.com" target="_blank">david.griswold.256@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_quote"><div><br>Yes, it's becoming clear that V8 doesn't do anything that radically new or magical, and that it was specifically designed for JavaScript, not as any kind of universal dynamic language VM. I'm especially disappointed at Eliot's observation that it doesn't have a bytecode intermediate form, although they may do mixed-mode execution by first interpreting the AST.<br>
</div></div></div></blockquote></div><br></div><div>Why is that a bad thing? I actually thought that was one of the most interesting aspects. Bytecodes can provide you a concise portable format, but you could also do that by compressing or otherwise condensing source code (which I guess one way of condensing is to map to bytecode). I'm not saying bytecodes wouldn't be desirable, but there's something appealing (to me) about a direct translation from source to machine code and I'm curious what other advantages bytecodes might have.</div>
<div></div></div></blockquote><div><br></div><div>Bytecodes can have two completely independent purposes: an external format for transporting code, and an internal format for executing code. I am talking about the second purpose. For dynamic languages with tagging, compiled code is much more verbose than in languages like C. If you have to compile a large body of such code, it can use a huge amount of space, especially if you don't have a good optimizer. </div>
<div><br></div><div>That is why VisualWorks keeps only a cache of the current working set of compiled code, not all of the code that has been compiled. That is also why Strongtalk uses mixed-mode execution, i.e. only compiles hotspots, and interprets the rest of the code. For an example of what happens when you try to compile everything that runs, see Self, which sucked down at least 64MB to run the image back in the day (I don't know if that has changed).</div>
<div><br></div><div>Also, compiling code that isn't in a hotspot is a waste of time, since you spend much longer compiling the code than you would have spent interpreting it, and can cause big compile pauses if the compiler does much optimization.</div>
</div></div>