tree 651f9a2510df91771d8a30ac1011a14d26659996
parent 2884d67af168d25f4aff83a72474f858f6bcde1d
author Nick Vatamaniuc <vatamane@apache.org> 1669439641 -0500
committer Nick Vatamaniuc <vatamane@gmail.com> 1715035044 -0400
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEC9ephJnEq0HJEO5l/ATfvJZXp44FAmY5W6QACgkQ/ATfvJZX
 p45ZyA//WyLjfoRGVeq2EgxqL7+ADmla7fXApzLeYg01bx2vlQgMeNXbrmzetvI0
 5llN2GWHIiWQM8nuEdDe6UtK5vfaMTJgXgpsfyFyGObOYmwcsv1S48Zidh0BP4Qd
 C83KJGjHVxP68NB+x4R10eTYuqoGHcRmMV6DMWpsUJUYccwtQuguishlKEM+CB0y
 sRQRB3zgdKTrlYaybxrTgShVATDuQDHO3YEYxOuByfemjaHY3SfKqTc0urMfBgRY
 hKvnjh8wdQXj+ELnmDWGBEXhanXMNAhw53k1tlmjOxybbUB0X2H+VkgwFCpdS9LB
 tEa4077L18bSGZPiAy6B1drHNBYmPaTgFWp+T42pnms2bzJyreJfpXclQ9excScM
 Qf1nFAAoeA7MA4nDw+xuHljarRZxOIAjvP+eQIyBdUSBraHqWzlM0tcsJVLVfuPA
 4xX3XkgmY6pqsfes1puP3iqrC1YnrLG4S78CVgkFtWAdwEqQvhhTkPpfX6/hvE4t
 q9j3/a7LXFEzAYDwgVboEYteCmT6NqbQBfNlA+sqtS722CT2P+6gF/Qf3lDh7HtA
 KFS2n0KjD0EYX6FXmlArUyd+u76mrENxBl408L3QERAKzEw/tQ4ubu9di3Hbh3Rz
 p9Kf4wIN1y2BdFsc10E/++jm6XAZFsNer75pCws7TPMTA9oBNqw=
 =7F1w
 -----END PGP SIGNATURE-----

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