-
Notifications
You must be signed in to change notification settings - Fork 30.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
node-api: run finalizers directly from GC #42651
Conversation
Review requested:
|
Hi @nodejs/node-api , Can team members take a look at this PR and provide feedback to @vmoroz so he can understand if this approach works well before he continues going through unit tests and other implementation details? Thanks. |
As we discussed today in Node-API meeting, one of the changes in this PR is the grouping of parameters inside of a new |
babb75d
to
71277e0
Compare
We discussed this in the 20 May Node-API meeting. This PR should be rebased and revalidated after #36510 has been merged since both PRs touch finalizer code. |
As discussed in the last node-api meeting, it would be worth exploring the possibility of introducing behavior flags to the initialization of an addon to invoke the finalizers in a more eager manner and disallow JavaScript evaluations in the finalizers. In this way, users can still have one single type of finalizer and don't need to distinguish them. We also don't need to introduce a bunch of new apis just for different finalizers. |
We discussed in the 7 Oct Node API meeting that this PR is dependent on the feature-flags implementation inside #42557. Instead of adding the new methods (in PRs first post), we would be able to modify existing API behavior for object finalization. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As currently implemented, AFAICT this change is not dependent on feature flags, since it implements all new APIs. LGTM.
I forgot that we were gonna force finalizers to be eager with a behaviour change and then provide an API to execute the JS portions immediately.
71277e0
to
1391400
Compare
The latest commit changes the PR based on the latest discussions that we had in Node-API meetings:
|
Changed status to DRAFT until I have the full set of tests and changes for the docs. |
ff681e7
to
82dd3e6
Compare
b7f91b9
to
25bfcaf
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
PR-URL: #42651 Reviewed-By: Gabriel Schulhof <gabrielschulhof@gmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com>
Landed in b38e312 |
Congrats @vmoroz on getting this PR landed! This has been a long time in the making with several users wanting this type of functionality 😄 |
PR-URL: nodejs#42651 Reviewed-By: Gabriel Schulhof <gabrielschulhof@gmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com>
PR-URL: #42651 Reviewed-By: Gabriel Schulhof <gabrielschulhof@gmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com>
PR-URL: #42651 Reviewed-By: Gabriel Schulhof <gabrielschulhof@gmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com>
PR-URL: nodejs#42651 Reviewed-By: Gabriel Schulhof <gabrielschulhof@gmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com>
PR-URL: nodejs/node#42651 Reviewed-By: Gabriel Schulhof <gabrielschulhof@gmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com>
PR-URL: nodejs/node#42651 Reviewed-By: Gabriel Schulhof <gabrielschulhof@gmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com>
The issue
Currently
Reference
finalizers are run inside ofSetImmediate
.In case if user code creates a lot of native objects in the main script, it could cause a significant memory pressure, even if the objects are properly released. This is because they are "collected" only inside of
SetImmediate
that follows the script run.See the issue: nodejs/node-addon-api#1140
In the a74a6e3 commit the processing of finalizers was moved from the GC second pass to the
SetImmediate
because:The solution
In this PR we are introducing new experimental behavior where the finalizers are run directly from the GC but they are not allowed to run JS code and must only call native code. Since the finalizers cannot affect the running JS code in any way, they are safe to run at any point.
If a finalizer must run JS code, then it can do it by calling the new
node_api_post_finalizer
method which schedules the finalizer run inSetImmediate
as it was before. The main difference is that previously we always scheduled finalizer runs inSetImmediate
implicitly, and now code must do it explicitly.