summaryrefslogtreecommitdiff
path: root/core/runtime.rs
AgeCommit message (Collapse)Author
2023-03-18perf(core): use static specifier in ExtensionFileSource (#18271)Bartek Iwańczuk
Relanding #18264 ------- Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
2023-03-18Revert "perf(core): use static specifier in ExtensionFileSource (#182… ↵Bartek Iwańczuk
(#18270) …64)" This reverts commit 8af0c8351935ea7c6c0441055d5164908322c9d6. Causes bench stage to fail on CI.
2023-03-18Revert "perf(core): preserve ops between snapshots (#18080)" (#18267)Bartek Iwańczuk
This reverts commit 4b6305f4f25fc76f974bbdcc9cdb139d5ab8f5f4.
2023-03-18perf(core): use static specifier in ExtensionFileSource (#18264)Divy Srivastava
Closes #18085 --------- Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
2023-03-18perf(core): preserve ops between snapshots (#18080)Bartek Iwańczuk
This commit changes the build process in a way that preserves already registered ops in the snapshot. This allows us to skip creating hundreds of "v8::String" on each startup, but sadly there is still some op registration going on startup (however we're registering 49 ops instead of >200 ops). This situation could be further improved, by moving some of the ops from "runtime/" to a separate extension crates. --------- Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
2023-03-17perf(core) Reduce copying and cloning in extension initialization (#18252)Matt Mastracci
Follow-up to #18210: * we are passing the generated `cfg` object into the state function rather than passing individual config fields * reduce cloning dramatically by making the state_fn `FnOnce` * `take` for `ExtensionBuilder` to avoid more unnecessary copies * renamed `config` to `options`
2023-03-17feat(core) deno_core::extension! macro to simplify extension registration ↵Matt Mastracci
(#18210) This implements two macros to simplify extension registration and centralize a lot of the boilerplate as a base for future improvements: * `deno_core::ops!` registers a block of `#[op]`s, optionally with type parameters, useful for places where we share lists of ops * `deno_core::extension!` is used to register an extension, and creates two methods that can be used at runtime/snapshot generation time: `init_ops` and `init_ops_and_esm`. --------- Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
2023-03-16refactor(core): op initialization and snapshot creator (#18221)Bartek Iwańczuk
This PR cleans up APIs related to snapshot creation and how ops are initialized. Prerequisite for #18080 --------- Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
2023-03-15chore(core): don't print cargo directives if not creating snapshot (#18205)Bartek Iwańczuk
2023-03-13Revert "feat(core): prevent isolate drop for CLI main worker (#18059)" (#18157)Ryan Dahl
Fixes https://github.com/denoland/deno/issues/18120 https://github.com/denoland/deno/issues/18137 https://github.com/denoland/fresh/issues/1073 This reverts commit 0cce9c2bcc9667935a571d30847e66ef5d01a196.
2023-03-09refactor(core): remove RuntimeOptions::extensions_with_js (#18099)Bartek Iwańczuk
This commit removes "deno_core::RuntimeOptions::extensions_with_js". Now it's embedders' responsibility to properly register extensions that will not contains JavaScript sources when running from an existing snapshot. Prerequisite for https://github.com/denoland/deno/pull/18080
2023-03-09perf(core): over-allocate in ModuleMap when running from snapshot (#18083)Bartek Iwańczuk
This commit changes "ModuleMap" initialization to over-allocate by 16 for vectors storing module information and module V8 handles. In 99% cases there's gonna be at least one additional module loaded, so it's very wasteful to have to reallocate when the module is executed (IIRC Rust will double the size of the vector) and move all of the elements.
2023-03-08feat(core): prevent isolate drop for CLI main worker (#18059)Divy Srivastava
``` Benchmark 1: deno run -A ../empty.js Time (mean ± σ): 20.5 ms ± 0.5 ms [User: 13.4 ms, System: 5.1 ms] Range (min … max): 19.8 ms … 24.0 ms 119 runs Benchmark 2: target/release/deno run -A ../empty.js Time (mean ± σ): 18.8 ms ± 0.3 ms [User: 13.0 ms, System: 4.9 ms] Range (min … max): 18.3 ms … 19.9 ms 129 runs ``` --------- Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
2023-03-08refactor: rename InternalModuleLoader to ExtModuleLoader, use ext: scheme ↵Bartek Iwańczuk
for snapshotted modules (#18041) This commit renames "deno_core::InternalModuleLoader" to "ExtModuleLoader" and changes the specifiers used by the modules loaded from this loader to "ext:". "internal:" scheme was really ambiguous and it's more characters than "ext:", which should result in slightly smaller snapshot size. Closes https://github.com/denoland/deno/issues/18020
2023-03-07refactor(core): don't use Result in ExtensionBuilder::state (#18066)Bartek Iwańczuk
There's no point for this API to expect result. If something fails it should result in a panic during build time to signal to embedder that setup is wrong.
2023-03-06refactor: use v8::String::new_external_onebyte_static where appropriate (#18051)Bartek Iwańczuk
2023-02-23fix(core): remove async op inlining optimization (#17899)Divy Srivastava
Runtime generation of async op wrappers contributed to increased startup time and core became unusable with `--disallow-code-generation-from-strings` flag. The optimization only affects very small microbenchmarks so this revert will not cause any regressions.
2023-02-22fix(core): rebuild when JS sources for snapshotting change (#17876)Bartek Iwańczuk
2023-02-22perf(core, runtime): Further improve startup time (#17860)Bartek Iwańczuk
This commit further improves startup time by: - no relying on "JsRuntime::execute_script" for runtime bootstrapping, this is instead done using V8 APIs directly - registering error classes during the snapshot time, instead of on startup Further improvements can be made, mainly around removing "core.initializeAsyncOps()" which takes around 2ms. This commit should result in ~1ms startup time improvement.
2023-02-21refactor(core): More efficient serde for ES modules in snapshot (#17856)Bartek Iwańczuk
Instead of relying on "serde_v8" which is very inefficient in serializing enums, I'm hand rolling serde for "ModuleMap" data that is stored in the V8 snapshot to make ES modules snapshottable. ``` // this branch Benchmark #2: ./target/release/deno run empty.js Time (mean ± σ): 21.4 ms ± 0.9 ms [User: 15.6 ms, System: 6.4 ms] Range (min … max): 20.2 ms … 24.4 ms // main branch Benchmark #2: ./target/release/deno run empty.js Time (mean ± σ): 23.1 ms ± 1.2 ms [User: 17.0 ms, System: 6.2 ms] Range (min … max): 21.0 ms … 26.0 ms ```
2023-02-20build: add "include_js_files_for_snapshotting" Cargo feature (#17826)Bartek Iwańczuk
This allows to not include source code into the binary (because it will already be included in the V8 snapshot). Nothing changes for the embedders - everything should still build the same. This commit brings the binary size from 87Mb to 82Mb on M1. Alternative to https://github.com/denoland/deno/pull/17820 and https://github.com/denoland/deno/pull/17653 --------- Co-authored-by: Leo Kettmeir <crowlkats@toaxl.com>
2023-02-20refactor(core): definition of "ExtensionFileSource" (#17823)Bartek Iwańczuk
This commit changes definition of "ExtensionFileSource", by changing "code" field to being "ExtensionFileSourceCode" enum. Currently the enum has only a single variant "IncludedInBinary". It is done in preparation to allow embedders to decide if they want to include the source code in the binary when snapshotting (in most cases they shouldn't do that). In the follow up commit we'll add more variants to "ExtensionFileSourceCode". "include_js_files_dir!" macro was removed in favor "include_js_files!" macro which can now accept "dir" option.
2023-02-16test: add unit tests from std/node (#17794)Bartek Iwańczuk
Adds two test files: "cli/tests/unit_node/process_test.ts" and "cli/tests/unit_node/child_process_test.ts" --------- Co-authored-by: Yoshiya Hinosawa <stibium121@gmail.com>
2023-02-15feat: wire up ext/node to the Node compatibility layer (#17785)Bartek Iwańczuk
This PR changes Node.js/npm compatibility layer to use polyfills for built-in Node.js embedded in the snapshot (that are coming from "ext/node" extension). As a result loading `std/node`, either from "https://deno.land/std@<latest>/" or from "DENO_NODE_COMPAT_URL" env variable were removed. All code that is imported via "npm:" specifiers now uses code embedded in the snapshot. Several fixes were applied to various modules in "ext/node" to make tests pass. --------- Co-authored-by: Yoshiya Hinosawa <stibium121@gmail.com> Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
2023-02-14feat(core): allow to specify entry point for snapshotted ES modules (#17771)Bartek Iwańczuk
This commit adds "ExtensionBuilder::esm_entry_point()" function that allows to specify which of the extension files should be treated as an entry point. If the entry point is not provided all modules are loaded and evaluated, but if it is provided then only the entry point is explicitly loaded and evaluated. Co-authored-by: Leo Kettmeir <crowlkats@toaxl.com>
2023-02-08refactor: internal runtime code TS support (#17672)Leo Kettmeir
This is a proof of concept for being able to snapshot TypeScript files. Currently only a single runtime file is authored in TypeScript - "runtime/js/01_version.ts". Not needed infrastructure was removed from "core/snapshot_util.rs". --------- Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
2023-02-08fix(core): don't allow to import internal code is snapshot is loaded (#17694)Bartek Iwańczuk
Addressing Luca concerns from https://github.com/denoland/deno/pull/17648#discussion_r1099352286
2023-02-08refactor(core): change SourcePair to ExtensionFileSource (#17686)Bartek Iwańczuk
2023-02-07refactor: Use ES modules for internal runtime code (#17648)Leo Kettmeir
This PR refactors all internal js files (except core) to be written as ES modules. `__bootstrap`has been mostly replaced with static imports in form in `internal:[path to file from repo root]`. To specify if files are ESM, an `esm` method has been added to `Extension`, similar to the `js` method. A new ModuleLoader called `InternalModuleLoader` has been added to enable the loading of internal specifiers, which is used in all situations except when a snapshot is only loaded, and not a new one is created from it. --------- Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
2023-02-07chore: upgrade rusty_v8 to 0.62.2 (#17604)Bartek Iwańczuk
Co-authored-by: Bert Belder <bertbelder@gmail.com>
2023-02-06refactor: create JsRuntime outside of run_in_task (#17667)Leo Kettmeir
2023-02-05 refactor: rename `deno` specifiers to `internal` (#17655)Leo Kettmeir
2023-02-03Revert "chore(core): remove have_unpolled_ops on rt state (#17601)" (#17631)Bartek Iwańczuk
This reverts commit e85ca8be0dafdab28e6283aed64c8ee0eb3a338d. This commit caused a huge spike in various benchmarks we track at https://deno.land/benchmarks
2023-01-31chore(core): remove have_unpolled_ops on rt state (#17601)Luca Casonato
It's not needed - `!state.have_unpolled_ops.is_empty()` does the same thing. Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
2023-01-27chore: upgrade to Rust 1.67 (#17548)David Sherret
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
2023-01-26chore(core): fix typo in runtime.rs (#17537)Ikko Eltociear Ashimine
determinstic -> deterministic
2023-01-25Revert "chore: upgrade rusty_v8 to 0.62.0 (#17200)" (#17523)Bartek Iwańczuk
This reverts commit e2d75491d5fc6fbac67da89c7350c4c9ca99d8e9.
2023-01-25chore: upgrade rusty_v8 to 0.62.0 (#17200)Bartek Iwańczuk
2023-01-19refactor: cleanup ModuleMap (#17469)Leo Kettmeir
- changes module id to be usize & 0 based instead of 1 based - merges `ids_by_handle` & `handles_by_id` to be a single `handles` vector - removes `next_module_id`, as vector is used - turns `info` into a vector
2023-01-19feat: ES module snapshotting (#17460)Leo Kettmeir
This commit adds support for snapshotting ES modules. This is done by adding an ability to serialize and deserialize a "ModuleMap" and attach it to the snapshot, using "add_context_data" API. This has been tested with 400 modules and seems to not have a limit on the number of modules that might be snapshotted. Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
2023-01-16refactor(core): Move `pending_promise_rejections` to `ContextState` (#17447)Andreu Botella
This is a requirement before supporting modules in realms.
2023-01-16refactor(core): rename pending_promise_exception to ↵Bartek Iwańczuk
pending_promise_rejection (#17441) These are technically rejections - a rejection can then raise an exception.
2023-01-14chore: use rustfmt imports_granularity option (#17421)Divy Srivastava
Closes https://github.com/denoland/deno/issues/2699 Closes https://github.com/denoland/deno/issues/2347 Uses unstable rustfmt features. Since dprint invokes `rustfmt` we do not need to switch the cargo toolchain to nightly. Do we care about formatting stability of our codebase across Rust versions? (I don't)
2023-01-15refactor(core): Move optional callbacks from `JsRuntimeState` to ↵Andreu Botella
`ContextState` (#17422) The `JsRuntimeState` struct stores a number of JS callbacks that are used either in the event loop or when interacting with V8. Some of these callback fields are vectors of callbacks, and therefore could plausibly store at least one callback per realm. However, some of those fields are `Option<v8::Global<v8::Function>>`, which would make the callbacks set by a realm override the one that might have been set by a different realm. As it turns out, all of the current such optional callbacks (`js_promise_reject_cb`, `js_format_exception_cb` and `js_wasm_streaming_cb`) are only used from inside a realm, and therefore this change makes it so such callbacks can only be set from inside a realm, and will only affect that realm. This is a reland of #15599. Towards #13239.
2023-01-14feat(core): Reland support for async ops in realms (#17204)Andreu Botella
Currently realms are supported on `deno_core`, but there was no support for async ops anywhere other than the main realm. The main issue is that the `js_recv_cb` callback, which resolves promises corresponding to async ops, was only set for the main realm, so async ops in other realms would never resolve. Furthermore, promise ID's are specific to each realm, which meant that async ops from other realms would result in a wrong promise from the main realm being resolved. This change takes the `ContextState` struct added in #17050, and adds to it a `js_recv_cb` callback for each realm. Combined with the fact that that same PR also added a list of known realms to `JsRuntimeState`, and that #17174 made `OpCtx` instances realm-specific and had them include an index into that list of known realms, this makes it possible to know the current realm in the `queue_async_op` and `queue_fast_async_op` methods, and therefore to send the results of promises for each realm to that realm, and prevent the ID's from getting mixed up. Additionally, since promise ID's are no longer unique to the isolate, having a single set of unrefed ops doesn't work. This change therefore also moves `unrefed_ops` from `JsRuntimeState` to `ContextState`, and adds the lengths of the unrefed op sets for all known realms to get the total number of unrefed ops to compare in the event loop. This PR is a reland of #14734 after it was reverted in #16366, except that `ContextState` and `JsRuntimeState::known_realms` were previously relanded in #17050. Another significant difference with the original PR is passing around an index into `JsRuntimeState::known_realms` instead of a `v8::Global<v8::Context>` to identify the realm, because async op queuing in fast calls cannot call into V8, and therefore cannot have access to V8 globals. This also simplified the implementation of `resolve_async_ops`. Co-authored-by: Luis Malheiro <luismalheiro@gmail.com>
2023-01-10fix(npm): allow to read package.json if permissions are granted (#17209)Bartek Iwańczuk
This commit changes signature of "deno_core::ModuleLoader::resolve" to pass an enum indicating whether or not we're resolving a specifier for dynamic import. Additionally "CliModuleLoader" was changes to store both "parent permissions" (or "root permissions") as well as "dynamic permissions" that allow to check for permissions in top-level module load an dynamic imports. Then all code paths that have anything to do with Node/npm compat are now checking for permissions which are passed from module loader instance associated with given worker.
2023-01-08feat(core): allow specifying name and dependencies of an Extension (#17301)Leo Kettmeir
2023-01-02chore: update copyright year to 2023 (#17247)David Sherret
Yearly tradition of creating extra noise in git.
2022-12-26chore(core): Make `OpCtx` instances be realm-specific (#17174)Andreu Botella
2022-12-23fix(core): run macrotasks and next ticks after polling dynamic imports (#17173)Bartek Iwańczuk
This commit fixes handling of rejected promises in dynamic imports evaluation. Previously we were running callbacks for next ticks and macrotasks _before_ polling dynamic imports and checked for unhandled rejections immediately after. This is wrong, as `unhandledrejection` event is dispatched and its callbacks are run as macrotasks. This commit changes order of actions performed by the event loop to following: - poll async ops - poll dynamic imports - run next tick callbacks - run macrotask callbacks - check for unhandled promise rejections