Hacker Newsnew | comments | ask | jobs | submitlogin
rbanffy 1202 days ago | link | parent

> JavaScript JITs are already compiling JavaScript to machine code

The details of how the interpreter works and of what it interprets are irrelevant to this discussion. It's JavaScript code that's being transported, not the compiled binary. While I agree tools like Closure somewhat obscure the resulting JavaScript, it's still source code that's being downloaded to my environment and it's my browser's job to decide how it should be executed.

I would have nothing against a site that sends me source code to be compiled within my computer so it could run inside a sandbox, but I won't like when Facebook starts pushing binaries I should trust won't break out of the sandbox they should respect. You can't easily do static analysis on binaries.

And I would love to be able to browse the web on my SPARC, POWER and MIPS boxes.

One good reason for JavaScript being slower than C is its typing. If we could write type-strict JavaScript code, it should not compile to less efficient binaries than corresponding C. BTW, incremental compiling has been around since the 80's - code can be compiled as quickly as it can be transferred through HTTP.



pohl 1202 days ago | link

You can't easily do static analysis on binaries.

The binary format in question here is LLVM-BC, which is just a compact representation of LLVM-IR, which is a single-static-assignment representation specifically designed for static analysis. SPARC, POWER and MIPS backends already exist, FWIW.

-----

rbanffy 1202 days ago | link

Well... This solves one problem.

-----

chc 1202 days ago | link

It solves the only problem you brought up in the comment he was responding to, AFAIK. If you meant to point to others, I think you need to be more explicit or people will miss them.

-----

rbanffy 1202 days ago | link

So, you would be happy if a banner served through Facebook could push a obfuscated (good guys may well play by the rules, but bad guys will figure out in no time how to circumvent anything LLVM-BC brings to the table) binary blob to be executed in your browser? How much would you trust the LLVM-based sandbox?

Well... I wouldn't.

In fact, I can't understand why taking more or less the same shortcut to a dead-end Java took a decade-and-half ago is suddenly a good idea and why disagreeing with it means dooming the web to failure.

-----

chc 1202 days ago | link

How much would you trust the JavaScript-based sandbox?

I don't see why you'd be more afraid of the blob because it's binary rather than obfuscated plaintext. I mean, heck, they could compile the LLVM bytecode to the exact same JavaScript bytecode they're currently using. If you're not afraid of JavaScript, I don't understand the objection you're raising here.

That's what I'm getting at here. Executing remotely downloaded code is scary, but we already do that.

And the problem with Java was that it had terrible performance. The idea of NaCL is that it will actually perform better than what we have now.

-----

rbanffy 1202 days ago | link

> And the problem with Java was that it had terrible performance.

It had, indeed, terrible performance in 1996.

> The idea of NaCL is that it will actually perform better than what we have now.

Again, I see no reason why an improved JavaScript language/runtime would not perform as well as this LLVM-based solution, with the added benefit of building upon 15 years of knowledge on how to secure (and not to secure) a JavaScript-based sandbox. This is a whole new can of worms we don't have to open. We have something that mostly works, that has been battle-tested for more than a decade, and instead of improving on it, some (very clever) people are pushing a whole new stack. Convince me this is the sane solution.

-----

pohl 1201 days ago | link

Again, I see no reason why an improved JavaScript language/runtime would not perform as well as this LLVM-based solution...

The original article here does an excellent job of explaining why. Did you read it? In particular, his reference to Tom Forsyth's article on Moore's Law versus Duck Typing is very informative. And his reference to the game Supreme Commander makes it pretty clear what level of performance he would like to see web-deployable pieces of code achieve.

with the added benefit of building upon 15 years of knowledge on how to secure (and not to secure) a JavaScript-based sandbox

Those years of experience can be brought to either solution, can't they?

I watched the video that junkbit posted a link to here, and they appear to not trust the llvm-bc. Once the bitcode is translated to a native executable, they run a verifier on the resulting binary, and if the verifier is unable to prove that the only instructions that can execute are those in thi binary, then they have a strict policy of not letting it run. In addition to that, the translator itself runs as a NaCl module so that if a bug is found, it cannot be maliciously used to escalate privileges.

Their approach seems pretty reasonable to me.

-----




Lists | RSS | Bookmarklet | Guidelines | FAQ | DMCA | News News | Feature Requests | Bugs | Y Combinator | Apply | Library

Search: