[LLVMdev] Greetings & Javascript -> LLVM...

[Julian Klappenbach]

Not necessarily looking for performance gains from LLVM.  Instead, the
value comes from having a common base platform which can gain language
independence, address security concerns, support common tooling (debugging,
editing, etc), and perhaps even introduce common language features
(annotations / AOP).

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.  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.

And for this purpose, I think LLVM would be well suited.  It really depends
on how much existing work can be leveraged, and how much interest exists
within the community to see this happen.

-jjk

On Sat, Aug 18, 2012 at 9:56 PM, Sean Silva <silvas at purdue.edu> wrote:

> Most of the performance wins for dynamic languages are not from the
> kinds of optimizations that LLVM does; you basically gain performance
> by doing run-time specialization of dynamic language constructs to
> become static, which is something that LLVM really won't help you do,
> and which practically speaking is extremely language-specific.
>
> For example, in JavaScript, all numbers are officially doubles, but in
> many cases it is profitable to runtime-specialize them to be integers,
> on the other hand, Python distinguishes between floats and integers,
> but Python integers overflow into arbitrary-precision integers
> on-demand.
>
> For another example, in Python, dictionaries can have any hashable
> type as their key, but in JavaScript, "objects" (which double as
> hashtables) can only have strings as their keys (although numbers get
> implicitly converted to strings which is another big language-specific
> optimization opportunity). Oh, and in JavaScript "objects" have a
> number of additional semantics which prevent them from being actually
> used as pure hashtables!
>
> --Sean Silva
>
> On Sat, Aug 18, 2012 at 4:39 PM, Julian Klappenbach
> <jklappenbach at gmail.com> wrote:
> > I have a concept for which I'm conducting an initial analysis.  The
> broader
> > idea is to create an LLVM, JIT based runtime that would create a platform
> > amenable to scripting languages, but do so while enforcing an optional
> > sandbox environment when dictated by security concerns (browsers, user
> > preferences).  With this approach, the community would gain language
> > independence for browsers, as well as enabling much needed
> standardization
> > over tooling support for debugging, refactoring, and even general editing
> > concerns.
> >
> > The first language I'd like to tackle is ECMAScript / Javascript.
> >
> > So, aside from all the issues with the strategy (getting buy-in from
> browser
> > / tooling teams, development community), my first concern is that it is
> even
> > possible.  Theoretically, it should be possible to express Javascript in
> > LLVM.  But a quick review of existing projects indicates that, while
> LLVM ->
> > Javascript has been taken on, what I'm seeking has not been done to date.
> >
> > Have I missed anything, or is there any reason not to attempt a project
> like
> > this?
> >
> > Regards,
> >
> > Julian Klappenbach
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120818/c88ef14d/attachment.html>