Coding in web browsers

[andrewducker]

robhu has a good point over here.

At the moment we write Javascript in web pages, which is then compiled down by the various JIT methods that Firefox/IE/Webkit use to make it super fast.

Seeing as what's run clearly isn't the actual JS itself, but bytecode, why not have a standardised bytecode that all browsers would support, which would then mean you could write your code in any language you liked, providing there was a compiler to convert it to the standardised bytecode?

At the moment Google uses GWT to convert Java into Javascript that then gets converted into the running code, (And MS used to have something similar) wouldn't it be handy if the intermediate step wasn't necessary?

Comments

[lpetrazickis.livejournal.com]

I would imagine that browsers currently have no defences against malicious bytecode, since they generate it themselves and so don't expect it to be malicious. Their defences against forkbombs, buffer overflows, and the like are likely in the Javascript compiler, not the bytecode interpreter. There'd be huge security issues with giving third parties on the internet direct control of the browser internals as they are.

[andrewducker]

Which is where Google's Native Client stuff comes in - which does sandbox things.

[strawberryfrog.livejournal.com]

The defence against forkbombs is that that Javascipt has little-to-no threading ability. Long-running scripts get shut down within a minute.

Security in bytecode systems is a problem that has been solved more than once, so it doesn't appear to be that hard. JS has no pointers, hence no buffer overflows, and I'd expect the bytecode to be likewise. In Java or .Net bytecode, security is mainly about gating access to the system API by untrusted bytecode.

[lpetrazickis.livejournal.com]

Historically, Javascript used to be capable of things like opening a new window which recursively opens two copies of itself.

The new Javascript worker threads are indeed incapable of fork-bombs due to the low limit on how many can be spawned.

I agree that adding a bytecode interpreter would be feasible, but I see it as a non-trivial task. Also, at least two browser vendors would have to forge ahead with it for the others to follow.

[strawberryfrog.livejournal.com]

I agree that bytecode interpreters aren't trivial, but are they much harder than the things currently being done to JavaScript in V8, tracemonkey, etc?

[figg.livejournal.com]

heh


bytecode intepreters are trivial, but that is their nature.

meanwhile effective just intime compilation as in v8, tracemonkey etc are a little more than a switch() statement.

lua is a bytecode interpreter and it is pretty simple to see how it works

meanwhile v8 uses jit to assembly + polymorphic inline caches + hidden classes to implement speedy dynamic dispatch

meanwhile nitro (or whatever apple is calling it) uses a technique of context threading, a simplified jit/bytecode hybrid that works by ensuring that the virtual machine doesn't get out of whack with the physical machine (i.e cache stalls, pipelining problems...)


you've got the wrong end of the stick: bytecode interpreters are easy, jit efforts like v8 are mammoth projects

[strawberryfrog.livejournal.com]

you've got the wrong end of the stick: bytecode interpreters are easy

My mistake was to go along with the parent poster, lpetrazickis's word usage, which was: I agree that adding a bytecode interpreter would be feasible, but I see it as a non-trivial task

Clearly, in the pedantic sense he is wrong. Bytecode interpreters are pretty simple. Equally clearly, a simple bytecode interpreter would not be sufficient for a theoretical layer under javascript, just as it is not for the JVM or .Net CLR. Jit is needed. I think we can agree that this is not trivial, and probably bears some comparison to V8 or Tracemonkey.

[robhu.livejournal.com]

Why give it access to browser internals? Just provide access to the things JS already has access to, like the DOM.