| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Review requested:
|
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
As we discussed today in Node-API meeting, one of the changes in this PR is the grouping of parameters inside of a new node_api_native_data struct. This struct should allow us to evolve the set of parameters that can be associate with native data. I had also mentioned that we must be able to create a C++ template function that converts C++ lambda to that struct. Such conversion would be difficult to do if the native data and finalizers are passed as function parameters. I am going to add a unit test to demo it. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
There was a problem hiding this comment.
As currently implemented, AFAICT this change is not dependent on feature flags, since it implements all new APIs. LGTM.
Sorry, something went wrong.
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.
|
The latest commit changes the PR based on the latest discussions that we had in Node-API meetings:
|
Sorry, something went wrong.
|
Changed status to DRAFT until I have the full set of tests and changes for the docs. |
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
PR-URL: #42651 Reviewed-By: Gabriel Schulhof <gabrielschulhof@gmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com>
|
Congrats @vmoroz on getting this PR landed! This has been a long time in the making with several users wanting this type of functionality 😄 |
Sorry, something went wrong.
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>
| Back | FazBrowse Home | New Git URL |
The issue
Currently Reference finalizers are run inside of SetImmediate.
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 in SetImmediate as it was before. The main difference is that previously we always scheduled finalizer runs in SetImmediate implicitly, and now code must do it explicitly.