try compiling for sm 102 #4305

nickva · 2022-12-13T17:08:33Z

My local from source build of SM 102 doesn't work with 91 instruction so used Ronny's Git Actions build, which worked great.

There were a few changes to the API which sadly means another copy and past of the whole C++ API bits which makes it hard to see the changes. The main changes I noticed is

SClassOps struct got smaller by one member and csp_allows gets an extra flag.

diff -C4 86/main.cpp 102/main.cpp
*** 86/main.cpp	2022-12-11 00:25:12.000000000 -0500
--- 102/main.cpp	2022-12-13 12:03:02.000000000 -0500
***************
*** 45,53 ****
      nullptr,
      nullptr,
      nullptr,
      nullptr,
-     nullptr,
      JS_GlobalObjectTraceHook
  };

  /* The class of the global object. */
--- 45,52 ----
***************
*** 239,247 ****
  };


  static bool
! csp_allows(JSContext* cx, JS::HandleString code)
  {
      couch_args* args = static_cast<couch_args*>(JS_GetContextPrivate(cx));
      if(args->eval) {
          return true;
--- 238,246 ----
  };


  static bool
! csp_allows(JSContext* cx, JS::RuntimeCode kind, JS::HandleString code)
  {
      couch_args* args = static_cast<couch_args*>(JS_GetContextPrivate(cx));
      if(args->eval) {
          return true;

However during test runs I started getting TypeError {} so that's how far I got only.

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 apache#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 apache#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 trasform 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). * Allow granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microsecond, so we can afford to do that on reset. JSRuntimes cannot share JS data or object between them. For now to make it easy to experiment added it in as a JS "version" enabled at compile time. ``` ./configure --dev --spidermonkey-version quickjs && make ``` Only tested on MacOS and Linux. All `make check` tests pass there. QuickJS Patches: * Disable workers. (Brings in pthread, etc) * Enable spidermonkey 1.8.5 function expression mode

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 apache#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 apache#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 trasform 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). * Allow granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microsecond, 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 Looks like 3x faster than SM 1.8.5 and 4x faster than SM 91. For now to make it easy to experiment added it in as a JS "version" enabled at compile time. ``` ./configure --dev --spidermonkey-version quickjs && make ``` Only tested on MacOS and Linux. All `make check` tests pass there. QuickJS Patches: * Disable workers. (Brings in pthread, etc) * Enable spidermonkey 1.8.5 function expression mode

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 apache#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 apache#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 trasform 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). * Allow granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microsecond, 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: - 3x faster than SM 1.8.5 - 4x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) For now to make it easy to experiment added it in as a JS "version" enabled at compile time. ``` ./configure --dev --spidermonkey-version quickjs && make ``` Only tested on MacOS and Linux. All `make check` tests pass there. QuickJS Patches: * Disable workers. (Brings in pthread, etc) * Enable spidermonkey 1.8.5 function expression mode

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 apache#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 apache#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 trasform 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). * Allow granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microsecond, 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: - 3x faster than SM 1.8.5 - 4x faster than SM 91 - 6x reduced memory usage per couchjs process (5MB vs 30MB) For now to make it easy to experiment added it in as a JS "version" enabled at compile time. ``` ./configure --dev --spidermonkey-version quickjs && make ``` Only tested on MacOS and Linux. All `make check` tests pass there. QuickJS Patches: * Disable workers. (Brings in pthread, etc) * Enable spidermonkey 1.8.5 function expression mode

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 apache#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 apache#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 trasform 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). * Allow granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microsecond, 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: - 3x faster than SM 1.8.5 - 4x 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.

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 apache#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 apache#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 trasform 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). * Allow granular time (reduction) trackign if we wanted to provide a runtime allowance for each function. * Better sandboxing. Creating a whole JSRuntime takes only 300 microsecond, 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.

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 apache#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 apache#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 trasform 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) trackign 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.

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

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

try compiling for sm 102

aa73f3b

nickva force-pushed the spidermonkey-102 branch from f56155f to aa73f3b Compare December 13, 2022 17:14

cho-m mentioned this pull request Jan 15, 2023

gjs 1.74.1 spidermonkey 102.6.0 Homebrew/homebrew-core#120675

Closed

nickva mentioned this pull request Feb 27, 2023

Use QuickJS as a Javascript Engine #4448

Open

lostnet mentioned this pull request May 11, 2023

couchdb3: 3.3.1 -> 3.3.2 NixOS/nixpkgs#231193

Merged

12 tasks

nickva mentioned this pull request May 25, 2023

Add QuickJS as a Javascript engine option #4622

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

try compiling for sm 102 #4305

try compiling for sm 102 #4305

nickva commented Dec 13, 2022

try compiling for sm 102 #4305

Are you sure you want to change the base?

try compiling for sm 102 #4305

Conversation

nickva commented Dec 13, 2022