<br><br>On Monday, August 20, 2012, Dan Gohman wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Aug 18, 2012, at 8:22 PM, Julian Klappenbach <<a href="javascript:;" onclick="_e(event, 'cvml', 'jklappenbach@gmail.com')">jklappenbach@gmail.com</a>> wrote:<br>
><br>
> I'm envisioning a use case where browsers would utilize this runtime to execute not only javascript, but also python, ruby, etc. Language specific interpreters could be downloaded on the fly to support scripts, and security would be ensured due to the fact that it would be based within the LLVM layer.<br>
<br>
It's possible you didn't mean it this way, but it's important to avoid a<br>
common confusion. LLVM IR provides no security. None whatsoever. Code in<br>
LLVM IR has the same level of arbitrary memory access and access to the<br>
enclosing system as C code does. In fact, if anything, LLVM probably<br>
makes the security story worse.<br>
<br>
It is possible to use LLVM within an independent sandbox, and various people<br>
are doing that, but that's not a unique property of LLVM.<br>
<br></blockquote><div><br></div><div>No, I have simply been evaluating LLVM from he perspective of a common, intermediate format for execution. Security would be implemented in terms of the services / APIs that would be made available to the execution context.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> The LLVM layer would also provide the access point for common browser APIs like access to the DOM and HTML nodes, XSLT, and XHR invocations. This would open up both the browser and current HTML5 application platforms to a wide variety of languages. Some may be quite happy with Javascript, but I'm sure others would be excited to see that stranglehold broken.<br>
<br>
I think there's no question that a lot of people want something like this.<br>
However, there are a bunch of challenges. Some of the big ones include:<br>
<br>
How are objects (as in object-oriented programming) going to work? Do you<br>
envision the platform providing a generic object model that all high-level<br>
languages will share, or do you envision every language framework building<br>
its own object model on top of a set of primitive operations? This question,<br>
and questions which follow it, will determine what kinds of languages can<br>
be ported to the platform, as well as play a large role in determining how<br>
hard it'll be to make them run efficiently, and how much cross-language<br>
interoperability you can have.<br>
<br>
Also, how is GC going to work? How is concurrency going to work? How is<br>
security going to work? How are third-party libraries going to work?<br>
<br>
These are some of the big important questions which will form the overall<br>
shape of your design. And it turns out that LLVM itself doesn't provide<br>
any significant help on any of them. So while LLVM may be a useful tool<br>
in the implementation stage, it's probably not where you want to start<br>
in the design stage for your project.<br>
<br>
Dan<br>
<br>
</blockquote><div><br></div><div>All valid points. The interpreter layer, whether it uses LLVM or not, is but one layer of the concept, and one that sits on top of an equally important service layer. But in putting together a stack, I like to take a holistic approach.<span></span></div>
<div><br></div><div>But as it stands, earlier comments were on the mark about LLVM and its viability for JIT interpreters. Tracing JIT interpreters have been demonstrating impressive benchmarks over LLVM implementations, often in excess of 30%. Furthermore, the work on a few of these tracing JIT engines has been well architected, and language independent. The problem of enabling a common tooling interface for supported languages still exists, but that appears minor to the concern of performance.</div>
<div><br></div>I really want to thank those of you who took the time to respond, your input has been invaluable.<div><br></div><div>-jjk</div>