Remove usage of the custom rquickjs
fork
#675
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit deprecates the usage of the custom
rquickjs
fork and pins therquickjs
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) usingManuallyDrop
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:
javy
crateJS_FreeValue
andJS_FreeContext
no-op.JS_FreeValue
which is a method from the public API and is invoked by Rustdrop
s will end up calling__JS_FreeValueRT
, which is the most expensive of thefree
variants, not all__JS_FreeValueRT
invocations stem fromJS_FreeValue
, some of them happen automatically from within the JS code.Checklist
javy-cli
andjavy-core
do not require updating CHANGELOG files.