Add QuickJS as a Javascript engine option
https://bellard.org/quickjs
Some benefits over SM:
* Small. We're using 6 or so C files vs 700+ SM91 C++ files.
* Built with Apache CouchDB as opposed having to maintain a separate SM
package, like for RHEL9, for instance, where they dropped support for SM
already. (see https://github.com/apache/couchdb/issues/4154).
* Embedding friendly. Designed from ground-up for embedding. SM has been
updating the C++ API such that we have to keep copy-pasting new versions of
our C++ code every year or so. (see
https://github.com/apache/couchdb/pull/4305).
* Easy to modify to accept Spidermonkey 1.8.5 top level functions for
map/reduce code so we don't have have to parse the JS, AST transform it, and
then re-compile it.
* Configurable runtime feature set - can disable workers, promises and other
API and features which may not work well in a backend JS environment. Some
users may want more, some may want to disable even Date(time) features to
hedge again Spectre-style attacks (spectreattack.com).
* Allows granular time (reduction) tracking if we wanted to provide a runtime
allowance for each function.
* Better sandboxing. Creating a whole JSRuntime takes only 300 microseconds, so
we can afford to do that on reset. JSRuntimes cannot share JS data or object
between them.
* Seems to be faster in preliminary benchmarking with small
concurrent VDU and view builds:
https://gist.github.com/nickva/ed239651114794ebb138b1f16c5f6758
Results seem promising:
- 4x faster than SM 1.8.5
- 5x faster than SM 91
- 6x reduced memory usage per couchjs process (5MB vs 30MB)
* Allows compiling JS bytecode ahead of time a C array of bytes.
QuickJS can be built alongside Spidermonkey and toggled on/off at runtime:
```
./configure --dev --js-engine=quickjs
```
This makes it the default engine. But Spidermonkey can still be set in the
config option.
```
[couchdb]
js_engine = spidermonkey | quickjs
```
To test individual views, without switching the default use the
`javascript_quickjs` language in the design docs. To keep using Spidermonkey
engine after switching the default, can use `javascript_spidermonkey` language
in design docs. However, language selection will reset the view and the view
will have to be rebuilt.
It's also possible to build without Spidermonkey support completely by using:
```
./configure --disable-spidermonkey
```
Issue: https://github.com/apache/couchdb/issues/4448
61 files changed
