Skip to content

Conversation

legendecas
Copy link
Member

src: clear all linked module caches once instantiated

There are two phases in module linking: link, and instantiate. These
two operations are required to be separated to allow cyclic
dependencies.

v8::Module::InstantiateModule is only required to be invoked on the
root module. The global references created by ModuleWrap::Link are
only cleared at ModuleWrap::Instantiate. So the global references
created for depended modules are usually not cleared because
ModuleWrap::Instantiate is not invoked for each of depended modules,
and caused memory leak.

The change references the linked modules in an object internal slot.

This is not an issue for Node.js ESM support as these modules can not be
off-loaded. However, this could be outstanding for vm.Module.

PR-URL: #59117
Fixes: #50113
Reviewed-By: Joyee Cheung [email protected]
Reviewed-By: Matteo Collina [email protected]

module: allow overriding linked requests for a ModuleWrap

This allows overriding linked requests for a ModuleWrap. The
statusOverride in vm.SourceTextModule could call moduleWrap.link
a second time when statusOverride of linking is set to undefined.

Overriding of linked requests should be no harm but better to be
avoided. However, this will require a follow-up fix on statusOverride
in vm.SourceTextModule.

PR-URL: #59527
Fixes: #59480
Reviewed-By: Joyee Cheung [email protected]
Reviewed-By: Marco Ippolito [email protected]

vm: sync-ify SourceTextModule linkage

Split module.link(linker) into two synchronous step
sourceTextModule.linkRequests() and
sourceTextModule.instantiate(). This allows creating vm modules and
resolving the dependencies in a complete synchronous procedure.

This also makes syntheticModule.link() redundant. The link step for a
SyntheticModule is no-op and is already taken care in the constructor
by initializing the binding slots with the given export names.

PR-URL: #59000
Refs: #37648
Reviewed-By: Joyee Cheung [email protected]

legendecas and others added 3 commits October 8, 2025 00:30
There are two phases in module linking: link, and instantiate. These
two operations are required to be separated to allow cyclic
dependencies.

`v8::Module::InstantiateModule` is only required to be invoked on the
root module. The global references created by `ModuleWrap::Link` are
only cleared at `ModuleWrap::Instantiate`. So the global references
created for depended modules are usually not cleared because
`ModuleWrap::Instantiate` is not invoked for each of depended modules,
and caused memory leak.

The change references the linked modules in an object internal slot.

This is not an issue for Node.js ESM support as these modules can not be
off-loaded. However, this could be outstanding for `vm.Module`.

PR-URL: nodejs#59117
Fixes: nodejs#50113
Reviewed-By: Joyee Cheung <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
This allows overriding linked requests for a `ModuleWrap`. The
`statusOverride` in `vm.SourceTextModule` could call `moduleWrap.link`
a second time when `statusOverride` of `linking` is set to undefined.

Overriding of linked requests should be no harm but better to be
avoided. However, this will require a follow-up fix on `statusOverride`
in `vm.SourceTextModule`.

PR-URL: nodejs#59527
Fixes: nodejs#59480
Reviewed-By: Joyee Cheung <[email protected]>
Reviewed-By: Marco Ippolito <[email protected]>
Split `module.link(linker)` into two synchronous step
`sourceTextModule.linkRequests()` and
`sourceTextModule.instantiate()`. This allows creating vm modules and
resolving the dependencies in a complete synchronous procedure.

This also makes `syntheticModule.link()` redundant. The link step for a
SyntheticModule is no-op and is already taken care in the constructor
by initializing the binding slots with the given export names.

PR-URL: nodejs#59000
Refs: nodejs#37648
Reviewed-By: Joyee Cheung <[email protected]>
@nodejs-github-bot
Copy link
Collaborator

Review requested:

  • @nodejs/loaders
  • @nodejs/startup
  • @nodejs/vm

@nodejs-github-bot nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. lib / src Issues and PRs related to general changes in the lib or src directory. needs-ci PRs that need a full CI run. v22.x Issues that can be reproduced on v22.x or PRs targeting the v22.x-staging branch. labels Oct 7, 2025
@legendecas legendecas added vm Issues and PRs related to the vm subsystem. esm Issues and PRs related to the ECMAScript Modules implementation. labels Oct 7, 2025
@nodejs-github-bot
Copy link
Collaborator

@legendecas
Copy link
Member Author

It seems like the build failure on v22.x-staging branch is caused by #59960

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ Issues and PRs that require attention from people who are familiar with C++. esm Issues and PRs related to the ECMAScript Modules implementation. lib / src Issues and PRs related to general changes in the lib or src directory. needs-ci PRs that need a full CI run. v22.x Issues that can be reproduced on v22.x or PRs targeting the v22.x-staging branch. vm Issues and PRs related to the vm subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants