Can V8 be installed in an embedded chip?

Question

In a channel I frequent someone asked the following question:

This company thats trying to hire me is doing vanilla javascript and jquery. No react, or any other frameworks. JQuery is know for being the hackiest shit and isn't it weird that in 2020 they're still not using anything better? Would you pick up such offer? [1]

This got me thinking: surely, if a company is doing anything in vanilla, it has a good reason for that and it's pretty popular to shove javascript into places that do not make sense to run it. Point of Sale systems, embedded systems, they don't have many resources to spare. As a result you cut every corner possible to get more performance out of the chip you're trying to use. Such thought reminded me of the time when Mark Zuckerberg said that "Facebook wasted too much time trying to implement mobile applications in javascript and HTML5 instead of native" [2]. I can't seem to find the source, but I did hear some rumors that he was promptly proven wrong by some company which knew ins and outs of how javascript works on mobile devices. And that thought caused me to start pondering about the following:

1. How much code can the embedded chips contain?
2. Would it be possible to embed an entire V8 engine into a chip to get javascript running on them at "on par" (or near on par) performance that you would with C/C++?
3. Is it really that much of a stigma to do vanilla javascript nowadays?

The last question is more of a rhetorical one. But I will appreciate any input.

---

1. The question of course is edited to suit the audience.
2. https://techcrunch.com/2012/09/11/mark-zuckerberg-our-biggest-mistake-with-mobile-was-betting-too-much-on-html5/

Answer 1

V8 developer here. As commenters have pointed out, this question is a bit too vague to have a solid answer (and is probably also not really on topic here), but I can offer a few thoughts.

V8 has certain hard requirements, eg:

• it needs a couple of megabytes of memory just to start up, so it won't run on microcontrollers that have less than that
• for normal operation, it needs permission (from the OS/kernel) to allocate executable memory. Recent versions support "jitless" mode, which avoids this, at the cost of a performance penalty (no generation of optimized code) -- how much that matters depends on your workload.
• the code it generates targets certain minimum CPU features, eg SSE2 on x86 and armv6+vfpv2 on ARM. This minimum applies even to "jitless" mode, because that executes code that V8 generated at build time and included in its binary. (With sufficient engineering investment, it would be technically possible to modify its code generation backend to target lower hardware requirements.)
• it officially supports running on Windows, MacOS, Linux, Android, Fuchsia; and there's community support for a few other operating systems. If your embedded device has a different OS, or no kernel at all, you'd have to make adaptations.

Aside from that, it's just a question of how fast you want things to be. Platform compatibility requirements aside, almost any software runs on almost any hardware, if you're willing to wait long enough. Ever seen a Raspberry Pi boot a regular Linux distro, or Windows XP on a Pentium-133? It works, but it's slow; There's a reason people spend lots of money on faster hardware ;-)

A few more considerations in this regard:

• In many cases, raw execution speed does not matter so much. For example, when the heavy lifting is done in native modules, it's often fine to use a relatively slow scripting language as "glue" between those modules.
• V8 is not targeted at severely resource-constrained environments, but there are other JavaScript engines that specifically target microcontrollers. Many of them only support a limited feature set (eg only ES3 or ES5, no modern EcmaScript features) in order to save memory and complexity.
• If a given use case does have strict performance requirements on weak hardware, then it makes sense to use low-level languages. Many microcontrollers are programmed in C dialects (ie subsets of C) for this reason.

Speaking of C/C++ vs JavaScript: it's hard to compare. The short answer is that C is faster, but it depends. You can craft microbenchmarks where dynamically compiled code is at an advantage, so JavaScript will be faster. Usually, language features like automatic garbage collection cost a few percent of performance compared to manual memory management. Mitigating the slowness of dynamic languages by JIT-compiling them similarly costs a bit of time, just because it's extra work that the CPU has to do. On sufficiently fast hardware, all these overheads are typically small enough not to matter, but when you're running against the limits of what your hardware can do at all (while still meeting user expectations about performance), then that assessment might change.

Answer 2

This is too many questions in one for a complete answer but.

2. Would it be possible to embed an entire V8 engine into a chip to get javascript running on them at "on par" (or near on par) performance that you would with C/C++?

No V8 can't run on a microcontroller. Maybe a microprocessor. But YES you can run javascript on a microcontroller. Espruino is a great example of that. I don't know about the speed of it but it seems to be capable of filling the hobbyist space for programming microcontrollers. Just as micropython does.