Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add QuickJS as a Javascript engine option #5049

Closed
wants to merge 1 commit into from
Closed

Conversation

nickva
Copy link
Contributor

@nickva nickva commented May 10, 2024

This is a test PR to run the full CI to check quickjs on other arches/os versions

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 #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
   #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: #4448
@nickva nickva closed this May 11, 2024
@nickva nickva deleted the jenkins-qjs-1 branch May 11, 2024 05:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant