6 ms·

"I mean, with Unix, most people are running a single implementation: Linux Kernel, and no one really cares about Open Solaris, or Darwin anymore." Nobody cares

by ootachi 15y ago

"I mean, with Unix, most people are running a single implementation: Linux Kernel, and no one really cares about Open Solaris, or Darwin anymore." Nobody cares about Darwin? Really? I mean, in terms of hacking the kernel, sure, but tons of people are running Darwin. The POSIX standard is more important than ever. "On mobile devices, loading a lot of Javascript is expensive" I keep seeing this assertion that bytecode would be smaller than gzipped, minified JavaScript source. I'm actually somewhat skeptical. Has anyone actually tested this? "could be atleast partially statically optimized for a particular device platform" I don't want this at all. That's too close to ActiveX for comfort. "wasting precious battery performing tasks that could be done on the server for it (like executing a parse and eval)" You realize that Java requires a nontrivial bytecode verifier too, right? IIRC the bytecode verifier, and certainly the compiler, require abstract interpretation to convert the stack-oriented bytecode to a virtual register-based one.

jasonmc 15y ago
"You realize that Java requires a nontrivial bytecode verifier too, right? IIRC the bytecode verifier, and certainly the compiler, require abstract interpretation to convert the stack-oriented bytecode to a virtual register-based one." It seems like you are talking about Dalvik VM (Android). Java class files (stack bytecode) are actually converted to Dakvik's register bytecode ahead of time. (Before installation on the mobile device.) I'm unsure if Dalvik bytecode is verified or not.
- ootachi 15y ago
  No, I'm talking about the verifier [1]. In particular: "There are no operand stack overflows or underflows." That requires abstract interpretation. And every performant Java interpreter is required to convert the stack machine to vregs in order to perform register allocation. That requires abstract interpretation too. [1]: http://java.sun.com/docs/white/langenv/Security.doc3.html http://java.sun.com/docs/white/langenv/Security.doc3.html
  - jasonmc 15y ago
    Sure, but I'd be willing to bet that performance impact of the the verifier is insignificant for all but the most trivial of programs.
cromwellian 15y ago
Who said anything about Java bytecode? Java bytecode != bytecode. "I don't want this at all. That's too close to ActiveX for comfort." It has nothing to do with ActiveX. It has everything to do with dead-stripping code and targeting particular browsers the way GWT and Closure Compiler do today. In particular, Javascript VMs today always parse JS even if it's already been cached, hasn't changed, and is loaded from the cache. They must also retain the original source as well as the parsed AST representations due to other semantics (toString()), which wastes gobs of memory on memory constrained devices. As for size, I believe there's a Microsoft paper floating around somewhere where they use a custom tokenized AST byte code format to achieve significant wire savings. The reality is, Java on Android already starts up faster than Android and runs faster than JS, so there is ample evidence that JS is underperforming other environments, meanwhile, Android APKs are not any bigger than comparable JS apps from my anecdotal observations.
- rictic 15y ago
  I don't know about GWT, but in my experience closure compiler does not produce different output for different browsers (though it does strip dead code).
  - cromwellian 15y ago
    It has the ability, but doesn't not part of the default IIRC unlike GWT which is built around permutations. GMail I think varies permutations. However, there are sound reasons for wanting to do so besides differing DOM capabilities, namely, that different JS VMs have different performance characteristics and what may be an optimal pattern for one, isn't for another.
- ootachi 15y ago
  "They must also retain the original source as well as the parsed AST representations due to other semantics (toString()), which wastes gobs of memory on memory constrained devices." Wrong. SpiderMonkey doesn't. It retains the bytecode only, throws away the original source, and uses a decompiler when toString() is used. V8 saves the original source, but that's its problem :)

by ootachi 15y ago

jasonmc 15y ago

"You realize that Java requires a nontrivial bytecode verifier too, right? IIRC the bytecode verifier, and certainly the compiler, require abstract interpretation to convert the stack-oriented bytecode to a virtual register-based one." It seems like you are talking about Dalvik VM (Android). Java class files (stack bytecode) are actually converted to Dakvik's register bytecode ahead of time. (Before installation on the mobile device.) I'm unsure if Dalvik bytecode is verified or not.

ootachi 15y ago
No, I'm talking about the verifier [1]. In particular: "There are no operand stack overflows or underflows." That requires abstract interpretation. And every performant Java interpreter is required to convert the stack machine to vregs in order to perform register allocation. That requires abstract interpretation too. [1]: http://java.sun.com/docs/white/langenv/Security.doc3.html http://java.sun.com/docs/white/langenv/Security.doc3.html
- jasonmc 15y ago
  Sure, but I'd be willing to bet that performance impact of the the verifier is insignificant for all but the most trivial of programs.

cromwellian 15y ago

Who said anything about Java bytecode? Java bytecode != bytecode. "I don't want this at all. That's too close to ActiveX for comfort." It has nothing to do with ActiveX. It has everything to do with dead-stripping code and targeting particular browsers the way GWT and Closure Compiler do today. In particular, Javascript VMs today always parse JS even if it's already been cached, hasn't changed, and is loaded from the cache. They must also retain the original source as well as the parsed AST representations due to other semantics (toString()), which wastes gobs of memory on memory constrained devices. As for size, I believe there's a Microsoft paper floating around somewhere where they use a custom tokenized AST byte code format to achieve significant wire savings. The reality is, Java on Android already starts up faster than Android and runs faster than JS, so there is ample evidence that JS is underperforming other environments, meanwhile, Android APKs are not any bigger than comparable JS apps from my anecdotal observations.

rictic 15y ago
I don't know about GWT, but in my experience closure compiler does not produce different output for different browsers (though it does strip dead code).
- cromwellian 15y ago
  It has the ability, but doesn't not part of the default IIRC unlike GWT which is built around permutations. GMail I think varies permutations. However, there are sound reasons for wanting to do so besides differing DOM capabilities, namely, that different JS VMs have different performance characteristics and what may be an optimal pattern for one, isn't for another.
ootachi 15y ago
"They must also retain the original source as well as the parsed AST representations due to other semantics (toString()), which wastes gobs of memory on memory constrained devices." Wrong. SpiderMonkey doesn't. It retains the bytecode only, throws away the original source, and uses a decompiler when toString() is used. V8 saves the original source, but that's its problem :)