-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Use QuickJS as a Javascript Engine #4448
Comments
Great initiative @nickva! According to its web site, the last release of QuickJS was almost 2 years ago. Would not it cause problems or is this actually an advantage (because it suggests stability)? |
@pgj a stable and simple API geared for embedding would be an advantage as opposed chasing a fast moving API made for Web browsers. |
https://gist.github.com/nickva/08f6100af20d23cde6dbdd65911c02e0 A very quick and dirty benchmark of basic startup and init differences between QuickJS and SM 91. It just times initializing an empty runtime and context. then free-ing and exiting the process. Some example runs from the gist (see that for actual patches) and more run times: SM91
QuickJS
Time-wise it looks about 2x as fast to initialize and takes about 3x less memory so at least is shows some promise there. |
fsync times can vary widely, especially on a remote block storage, so add a histogram and count for fsync calls. At a higher level, we can coalesce similar update doc requests from multiple clients, so add metrics to track that as well. Improving couch_proc_manager, and experimenting with quickjs js engine [1], noticed we lacked metrics in that area. Add metrics to track query process acquires, start/stops (including crashes) as well as how many prompt and prompt errors we have. These should help gain some confidence when upgrading to a new engine version or engine type by comparng the before and after metrics output. Trying to test some of these new metrics, noticed couch_file tests did most of the test logic in the setup part, which resulted in plenty of log noise during the test runs about started/stopped applications, so updated a few tests which were affected by this PR to use the ?TDEF_FE macro. That should make test output a bit smaller and neater. [1] #4448 (comment)
fsync times can vary widely, especially on a remote block storage, so add a histogram and count for fsync calls. At a higher level, we can coalesce similar update doc requests from multiple clients, so add metrics to track that as well. Improving couch_proc_manager, and experimenting with quickjs js engine [1], noticed we lacked metrics in that area. Add metrics to track query process acquires, start/stops (including crashes) as well as how many prompt and prompt errors we have. These should help gain some confidence when upgrading to a new engine version or engine type by comparing the before and after metrics output. Trying to test some of these new metrics, noticed couch_file tests did most of the test logic in the setup part, which resulted in plenty of log noise during the test runs about started/stopped applications, so updated a few tests which were affected by this PR to use the ?TDEF_FE macro. That should make test output a bit smaller and neater. [1] #4448 (comment)
fsync times can vary widely, especially on a remote block storage, so add a histogram and count for fsync calls. At a higher level, we can coalesce similar update doc requests from multiple clients, so add metrics to track that as well. Improving couch_proc_manager, and experimenting with quickjs js engine [1], noticed we lacked metrics in that area. Add metrics to track query process acquires, start/stops (including crashes) as well as how many prompt and prompt errors we have. These should help gain some confidence when upgrading to a new engine version or engine type by comparing the before and after metrics output. Trying to test some of these new metrics, noticed couch_file tests did most of the test logic in the setup part, which resulted in plenty of log noise during the test runs about started/stopped applications, so updated a few tests which were affected by this PR to use the ?TDEF_FE macro. That should make test output a bit smaller and neater. [1] #4448 (comment)
fsync times can vary widely, especially on a remote block storage, so add a histogram and count for fsync calls. At a higher level, we can coalesce similar update doc requests from multiple clients, so add metrics to track that as well. Improving couch_proc_manager, and experimenting with quickjs js engine [1], noticed we lacked metrics in that area. Add metrics to track query process acquires, start/stops (including crashes) as well as how many prompt and prompt errors we have. These should help gain some confidence when upgrading to a new engine version or engine type by comparing the before and after metrics output. Trying to test some of these new metrics, noticed couch_file tests did most of the test logic in the setup part, which resulted in plenty of log noise during the test runs about started/stopped applications, so updated a few tests which were affected by this PR to use the ?TDEF_FE macro. That should make test output a bit smaller and neater. [1] #4448 (comment)
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/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 ``` Only tested on MacOS and Linux. All `make check` tests pass there. Issue: #4448
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/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 ``` Only tested on MacOS and Linux. All `make check` tests pass there. Issue: #4448
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/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 ``` Only tested on MacOS and Linux. All `make check` tests pass there. Issue: #4448
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/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 ``` Only tested on MacOS and Linux. All `make check` tests pass there. Issue: #4448
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/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 ``` Only tested on MacOS and Linux. All `make check` tests pass there. Issue: #4448
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/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 ``` Only tested on MacOS and Linux. All `make check` tests pass there. Issue: #4448
Updated PR #4627 with a wip skeleton of a
|
To avoid managing a new data state directory (config option, checking for disk space, handling read-only or other errors), it would be a lot simpler to manage the checkpoints as simple _local docs in _dbs. There is precedent for using that exact mechanism for shard splitting job management. The general idea is that there is a general mechanism to traverse databases and ddocs. Periodically it will update its checkpoint in Then, as the traversal happens, a call is made to each of the configured callback modules( The configuration could look something like: [scanner]
enable = true | false
schedule_period = once | every_week | every_day | ...
[scanner.$module] ...
enable = true | false
... $module specific settings ... For instance: [scanner.quickjs_compat_check]
enable = true | false
sample_docs = 100
check_reduce = true | false
log_report_level = warning |
The callback API for each scanner module might look like: {ok, Ctx} = start_scan(#{session_id => Uuid, start_timestamp => UnixTs})
{ok, Ctx1} = start_db(Ctx, DbName)
{ok, Ctx1} = ddoc(Ctx, DbName, DDoc = #doc{})
{ok, Ctx1} = shard(Ctx, Db)
{ok, Ctx1} = end_db(Ctx, DbName)
ok = end_scan(Ctx) This flow would be initialized and kept for each module individually. The scanner server process would hold a context that looks like: #state{modstates = #{Module1 => Ctx1, Module2 => Ctx2} ....} The scan would be run on all the nodes. During scanning only the dbs with the first shard copy on that node would be scanned. The API doesn't call per-document callback. The idea would be that each plugin them may choose to sample only some docs or process all the docs or simply return A few events might stop or pause scanning:
|
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/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 ``` Only tested on MacOS and Linux. All `make check` tests pass there. Issue: #4448
https://bellard.org/quickjs https://fuchsia.googlesource.com/third_party/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 ``` Tested on MacOS and Linux. All `make check` tests pass there. Issue: #4448
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 view, without making the default use the `javascript_quickjs` language in design docs. Tested on MacOS and Linux. All `make check` tests pass there. Issue: #4448
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. Tested on MacOS and Linux. All `make check` tests pass there. Issue: #4448
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. Tested on MacOS and Linux. All `make check` tests pass there. Issue: #4448
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. Tested on MacOS and Linux. All `make check` tests pass there. Issue: #4448
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
mozjs-91 does not support python 3.12.x, thus couchdb for meta-erlang can't usemozjs-91 anymore. So, this commit is trying to use (an under development branch) quickjs as an alternative [1] to mozjs. 1: apache/couchdb#4448
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Some benefits over Mozilla Spidermonkey: * 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 [1]. * 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 [2]. * 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. * 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 [1] #4154 [2] #4305
Some benefits over Mozilla Spidermonkey: * 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 [1]. * 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 [2]. * 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. * 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 [1] #4154 [2] #4305
The couchdb build is broken because the version of mozjs supported by couchdb is not compatible with python 3.12.x ar greater. That brings a difficult situation where the best thing for now is to remove couchdb and wait couchdb developers to integrate a new JS engine [1]. In meta-erlang, patches exist in order to bring back couchdb with new JS engine [2]. But it's not time to integrate it yet. 1: apache/couchdb#4448 Use QuickJS as a Javascript Engine 2: #293 couchdb: move to main branch and remove mozjs
The couchdb build is broken because the version of mozjs supported by couchdb is not compatible with python 3.12.x ar greater. That brings a difficult situation where the best thing for now is to remove couchdb and wait couchdb developers to integrate a new JS engine [1]. In meta-erlang, patches exist in order to bring back couchdb with new JS engine [2]. But it's not time to integrate it yet. 1: apache/couchdb#4448 Use QuickJS as a Javascript Engine 2: #293 couchdb: move to main branch and remove mozjs
The couchdb build is broken because the version of mozjs supported by couchdb is not compatible with python 3.12.x ar greater. That brings a difficult situation where the best thing for now is to remove couchdb and wait couchdb developers to integrate a new JS engine [1]. In meta-erlang, patches exist in order to bring back couchdb with new JS engine [2]. But it's not time to integrate it yet. 1: apache/couchdb#4448 Use QuickJS as a Javascript Engine 2: #293 couchdb: move to main branch and remove mozjs
https://bellard.org/quickjs/
It might a be a nice fallback, at least, if SM is missing or cannot be built for a particular OS/arch combination. RHEL 9 had stopped including the SM package, so we'd be back into building and maintained our own separate RPM for it. #4154
Moreover, SM keeps deprecating versions fairly aggressively and new stable versions keep changing the C++ API, which makes it unfriendly for embedding. For instance: #4305
QuickJS has a few nice things going for it:
The text was updated successfully, but these errors were encountered: