3 ms·

I have to wonder why they chose C++ for writing the VM. Since their architecture is based on compiling Javascript, why not just write the compiler in Javascript

I have to wonder why they chose C++ for writing the VM. Since their architecture is based on compiling Javascript, why not just write the compiler in Javascript to begin with? The most likely reason I can think of is that it makes it easier to interface with the existing WebKit code, but this doesn't seem like a very strong reason to me.

orib 18y ago
Because you would need to bootstrap it every time you want to run it, since Javascript is interpreted. This means you'd need a 3rd party Javascript interpreter to run your Javascript interpreter.
- wmf 18y ago
  You only need to bootstrap it once and write out an image.
  - orib 18y ago
    Ah. So you propose writing a Javascript compiler that spits out a dynamically linkable, PIC executable for multiple architectures using semi-static assembly, and then using that to write V8? Otherwise, if you simply dump a raw image you've got a closed environment that can't really be integrated into a browser very well, or linked into other apps for their use. That's a whole lot of unnecessary -- and nontrivial -- work, when all you want to do is interpret Javascript.
    - wmf 18y ago
      I'm not really proposing anything, since the V8 team has forgotten more about VMs than I know, just pointing out another common design alternative. The post implies that V8 can already perform some sort of AOT compilation: When you build V8 from source, you can have it generate a snapshot of the memory state once the libraries are loaded and this gets packaged in the executable. It makes it slightly bigger but the load time is blazingly fast. There's certainly extra work in this approach, but maybe it would be worth it if it allows the compiler to be written in a more productive language.
- procrastitron 18y ago
  No, the whole point is that they already wrote a compiler, so the in this case Javascript is not interpreted. You only have to bootstrap it once. They would have had to make their compiler provide a batch compilation mode in addition to the incremental compilation mode, but that should not be a pain point. After all, batch compiling is easier to do than incremental compiling.

orib 18y ago

Because you would need to bootstrap it every time you want to run it, since Javascript is interpreted. This means you'd need a 3rd party Javascript interpreter to run your Javascript interpreter.

wmf 18y ago
You only need to bootstrap it once and write out an image.
- orib 18y ago
  Ah. So you propose writing a Javascript compiler that spits out a dynamically linkable, PIC executable for multiple architectures using semi-static assembly, and then using that to write V8? Otherwise, if you simply dump a raw image you've got a closed environment that can't really be integrated into a browser very well, or linked into other apps for their use. That's a whole lot of unnecessary -- and nontrivial -- work, when all you want to do is interpret Javascript.
  - wmf 18y ago
    I'm not really proposing anything, since the V8 team has forgotten more about VMs than I know, just pointing out another common design alternative. The post implies that V8 can already perform some sort of AOT compilation: When you build V8 from source, you can have it generate a snapshot of the memory state once the libraries are loaded and this gets packaged in the executable. It makes it slightly bigger but the load time is blazingly fast. There's certainly extra work in this approach, but maybe it would be worth it if it allows the compiler to be written in a more productive language.
procrastitron 18y ago
No, the whole point is that they already wrote a compiler, so the in this case Javascript is not interpreted. You only have to bootstrap it once. They would have had to make their compiler provide a batch compilation mode in addition to the incremental compilation mode, but that should not be a pain point. After all, batch compiling is easier to do than incremental compiling.