4 ms·

The position of Dart guys is simple: by compiling an arbitrary language (Dart in this case) to x86 (or whatever native arch the browser is running on) they can

The position of Dart guys is simple: by compiling an arbitrary language (Dart in this case) to x86 (or whatever native arch the browser is running on) they can get a much faster code than compiling to an abstract VM, like JVM or .NET or parrot. No, their position is against creating a new VM for the Dart language, and they justify it, in part, by saying it would end up with the same limitations as the JVM. Nutter isn't arguing with this position though, he is just countering their assertions about the JVM.

kkowalczyk 15y ago
Except all his argument are by proxy. Is it not true that "the JVM assumes you want classes, single dispatch, inheritance, and primitives. It assumes you don't need 32-bit unsigned math." ? Is it not true that "adding new bytecodes increases the complexity of VM? That to add "all possible languages a VM needs to support a multitude of calling conventions: tail calls, optional arguments, rest arguments, keyed arguments, overloaded methods, and so on" ? Is it not true that "jvm specifies a class file format, a concurrency model (in the case of the JVM threads with shared state), class initialization, and a bunch of other stuff that nails down semantic choices." ? Those are the actual "assertions" made by Dart paper. Which of those facts about jvm Nutter actually countered?
rayiner 15y ago
> by saying it would end up with the same limitations as the JVM No, they were saying that it would end up with a different set of limitations, and gives the JVM as an example. E.g. if you exposed the current Dart VM's feature set as a byte code VM, ML folks would complain it doesn't support tail calls, Haskell folks would complain it doesn't allow them to efficiently encode their TABLES_NEXT_TO_CODE optimization, etc. Java folks would complain it's integer semantics are wrong (overflow to bignum rather than wrap-around), that it lacks support for arbitrary class loading, etc.
- extension 15y ago
  And, as Nutter points out, the JVM isn't nearly as constrictive to other languages as people seem to think it is, despite being designed only for one language. So, with everything we've learned about VM design since then, and with the explicit goal of supporting multiple static and dynamic languages, you would think that we could design a pretty good bytecode VM for the browser today. It may not be the ideal VM for every language, but it could probably be ideal for a lot of them, and adequate for the rest. A Dart source interpreter won't be ideal for any of them. As for their "case for a language VM" i.e. inline code, there's a simple solution to that: support both bytecode and inline code. Source is going to get minified anyway, before it goes into production, so you might as well let them compile it to bytecode. Other languages will support inline code by implementing their compilers for the browser, just like CoffeeScript does.
nickik 15y ago
"No, their position is against creating a new VM for the Dart language" This is just WRONG. The will implment some kind of VM for Dart anyway (maybe the put it into V8 but I doute it). The question is if the should open up the bytecode (some IR) so other people can compile to that. There argument is that this VM for Dart would have limitations just like the JVM has them. Therefore opening the VM for other people is not worth it.
- nxn 15y ago
  Google refers to V8 as a VM* despite it taking Javascript straight to native instructions with not bytecode or intermediate step being involved anywhere. What makes you think they would mean something else when they speak of a Dart VM? It would serve them absolutely no purpose to load dart (or JS) programs as text, compile that into bytecode, only to then translate that to native instructions. The only advantage would be in the case of having the dart source pre-compiled into bytecode by the programmer -- but at that point you are exposing it for other languages, and it would mean the complete opposite of what this article is saying. * They even do so on the homepage of the project: http://code.google.com/p/v8/ http://code.google.com/p/v8/
  - nickik 15y ago
    > Google refers to V8 as a VM* despite it taking Javascript straight to native instructions with not bytecode or intermediate step being involved anywhere. What makes you think they would mean something else when they speak of a Dart VM? They are right in calling V8 a VM. Your right too there is no need to have a bytecode befor going to native. Its however pretty comon thing to do. I think its a good idea if a VM builds a good bytecode befor running and I didnt thing about the direct way. (Node: V8 sometimes has intermediate steps. Read this: http://wingolog.org/archives/2011/07/05/v8-a-tale-of-two-compilers http://wingolog.org/archives/2011/07/05/v8-a-tale-of-two-com...) > It would serve them absolutely no purpose to load dart programs as text, compile that into bytecode, only to then translate that to native instructions. Im sorry this is just wrong. To first build a bytecode out of all your code can be a good idea. LuaJit for example always builds bytecode befor going to native. Pretty comon thing to do.

kkowalczyk 15y ago

Except all his argument are by proxy. Is it not true that "the JVM assumes you want classes, single dispatch, inheritance, and primitives. It assumes you don't need 32-bit unsigned math." ? Is it not true that "adding new bytecodes increases the complexity of VM? That to add "all possible languages a VM needs to support a multitude of calling conventions: tail calls, optional arguments, rest arguments, keyed arguments, overloaded methods, and so on" ? Is it not true that "jvm specifies a class file format, a concurrency model (in the case of the JVM threads with shared state), class initialization, and a bunch of other stuff that nails down semantic choices." ? Those are the actual "assertions" made by Dart paper. Which of those facts about jvm Nutter actually countered?

rayiner 15y ago

> by saying it would end up with the same limitations as the JVM No, they were saying that it would end up with a different set of limitations, and gives the JVM as an example. E.g. if you exposed the current Dart VM's feature set as a byte code VM, ML folks would complain it doesn't support tail calls, Haskell folks would complain it doesn't allow them to efficiently encode their TABLES_NEXT_TO_CODE optimization, etc. Java folks would complain it's integer semantics are wrong (overflow to bignum rather than wrap-around), that it lacks support for arbitrary class loading, etc.

extension 15y ago
And, as Nutter points out, the JVM isn't nearly as constrictive to other languages as people seem to think it is, despite being designed only for one language. So, with everything we've learned about VM design since then, and with the explicit goal of supporting multiple static and dynamic languages, you would think that we could design a pretty good bytecode VM for the browser today. It may not be the ideal VM for every language, but it could probably be ideal for a lot of them, and adequate for the rest. A Dart source interpreter won't be ideal for any of them. As for their "case for a language VM" i.e. inline code, there's a simple solution to that: support both bytecode and inline code. Source is going to get minified anyway, before it goes into production, so you might as well let them compile it to bytecode. Other languages will support inline code by implementing their compilers for the browser, just like CoffeeScript does.

nickik 15y ago

"No, their position is against creating a new VM for the Dart language" This is just WRONG. The will implment some kind of VM for Dart anyway (maybe the put it into V8 but I doute it). The question is if the should open up the bytecode (some IR) so other people can compile to that. There argument is that this VM for Dart would have limitations just like the JVM has them. Therefore opening the VM for other people is not worth it.

nxn 15y ago
Google refers to V8 as a VM* despite it taking Javascript straight to native instructions with not bytecode or intermediate step being involved anywhere. What makes you think they would mean something else when they speak of a Dart VM? It would serve them absolutely no purpose to load dart (or JS) programs as text, compile that into bytecode, only to then translate that to native instructions. The only advantage would be in the case of having the dart source pre-compiled into bytecode by the programmer -- but at that point you are exposing it for other languages, and it would mean the complete opposite of what this article is saying. * They even do so on the homepage of the project: http://code.google.com/p/v8/ http://code.google.com/p/v8/
- nickik 15y ago
  > Google refers to V8 as a VM* despite it taking Javascript straight to native instructions with not bytecode or intermediate step being involved anywhere. What makes you think they would mean something else when they speak of a Dart VM? They are right in calling V8 a VM. Your right too there is no need to have a bytecode befor going to native. Its however pretty comon thing to do. I think its a good idea if a VM builds a good bytecode befor running and I didnt thing about the direct way. (Node: V8 sometimes has intermediate steps. Read this: http://wingolog.org/archives/2011/07/05/v8-a-tale-of-two-compilers http://wingolog.org/archives/2011/07/05/v8-a-tale-of-two-com...) > It would serve them absolutely no purpose to load dart programs as text, compile that into bytecode, only to then translate that to native instructions. Im sorry this is just wrong. To first build a bytecode out of all your code can be a good idea. LuaJit for example always builds bytecode befor going to native. Pretty comon thing to do.