This commit deprecates the usage of the custom rquickjs fork and pins the rquickjs version to 0.6.1, which is the current version in the fork.
The main motivation behind this change is to avoid relying on a fork, which precludes publishing version 3.0.0 of the javy crates to crates.io, since git dependencies are not supported.
Another motivation, arguably more important than the one stated above, is making sure that we are always relying on the upstream implementation rather than in a fork containing patches maintained out-of-band.
Side-effects:
The fork enabled a slightly more performant execution in Wasm environments, when dealing with short-lived JS programs that don't require garbage collection, more explicitly, it introduced a patch that prevented QuickJS' __JS_FreeValueRT from running. Even though there are no known issues with this approach, __JS_FreeValueRT is an internal method and no guarantees are made regarding its stability, therefore it's preferred to avoid relying on it. Without this custom patch, I'm observing locally, on average a 2% increase in fuel usage outside of the 10% acceptable variance. Note that there are safe mechanisms in place to mitigate the impact of GC in the codebase, namely: (i) using ManuallyDrop where possible (ii) setting the GC threshold to -1 to reduce the possibility of any GC pauses. With that in mind, the 2% increase seems reasonable given all the benefits that we get from this change.
Alternatives considered:
Keeping the fork
Upgrades will be difficult
There's no easy way of publishing the javy crate
Post-processing the generated Wasm code and make JS_FreeValue and JS_FreeContext no-op.
This worked to a certain extent, however, in my opinion, the result is not worth the effort. This approach resulted in minimal performance improvements. Even though JS_FreeValue which is a method from the public API and is invoked by Rust drops will end up calling __JS_FreeValueRT, which is the most expensive of the free variants, not all __JS_FreeValueRT invocations stem from JS_FreeValue, some of them happen automatically from within the JS code.
Checklist
[x] I've updated the relevant CHANGELOG files if necessary. Changes to javy-cli and javy-core do not require updating CHANGELOG files.
This commit deprecates the usage of the custom
rquickjsfork and pins therquickjsversion to 0.6.1, which is the current version in the fork.The main motivation behind this change is to avoid relying on a fork, which precludes publishing version 3.0.0 of the
javycrates to crates.io, since git dependencies are not supported.Another motivation, arguably more important than the one stated above, is making sure that we are always relying on the upstream implementation rather than in a fork containing patches maintained out-of-band.
Side-effects:
The fork enabled a slightly more performant execution in Wasm environments, when dealing with short-lived JS programs that don't require garbage collection, more explicitly, it introduced a patch that prevented QuickJS'
__JS_FreeValueRTfrom running. Even though there are no known issues with this approach,__JS_FreeValueRTis an internal method and no guarantees are made regarding its stability, therefore it's preferred to avoid relying on it. Without this custom patch, I'm observing locally, on average a 2% increase in fuel usage outside of the 10% acceptable variance. Note that there are safe mechanisms in place to mitigate the impact of GC in the codebase, namely: (i) usingManuallyDropwhere possible (ii) setting the GC threshold to-1to reduce the possibility of any GC pauses. With that in mind, the 2% increase seems reasonable given all the benefits that we get from this change.Alternatives considered:
javycrateJS_FreeValueandJS_FreeContextno-op.JS_FreeValuewhich is a method from the public API and is invoked by Rustdrops will end up calling__JS_FreeValueRT, which is the most expensive of thefreevariants, not all__JS_FreeValueRTinvocations stem fromJS_FreeValue, some of them happen automatically from within the JS code.Checklist
javy-cliandjavy-coredo not require updating CHANGELOG files.