n-api: render finalizers as env cleanup hooks #28428

gabrielschulhof · 2019-06-25T19:54:35Z

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
tests and/or benchmarks are included
commit message follows commit guidelines

addaleax

This might technically be considered a breaking change, although I’d 100 % agree that this is the right thing to do. Do we have a list of known or at least a list of relevant N-API packages, so that we can run more test suites against it than what CITGM provides?

src/js_native_api_v8.cc

addaleax · 2019-06-25T21:06:30Z

src/js_native_api_v8.cc

+  inline void SetWeak() {
+    _persistent.SetWeak(
+        this, FinalizeCallback, v8::WeakCallbackType::kParameter);
+    _env->track_finalizer(EnvCleanupHook, this);


I’d go further and suggest the behaviour that Node.js itself uses (via BaseObject): Always call finalizers at the end of the current Environment, not just when they’re weak references.

I think we have to work these kinds of changes through the whole code base. For example, I still need to add this to v8impl::CallbackBundle as well. I'd like to make that a subclass of Reference.

addaleax · 2019-06-25T21:10:27Z

src/js_native_api_v8.h

@@ -25,6 +25,9 @@ struct napi_env__ {

  virtual bool can_call_into_js() const { return true; }

+  virtual void track_finalizer(void (*finalizer)(void*), void* data) {}
+  virtual void untrack_finalizer(void (*finalizer)(void*), void* data) {}


style nit that can totally be ignored: These methods would more typically be called TrackFinalizer and UntrackFinalizer since they aren’t simple getters/setters.

Going even further, I think every implementor of N-API should support napi_add_env_cleanup_hook() and napi_remove_env_cleanup_hook(); they could totally be no-ops for some non-Node.js variants that do follow a one-env-per-process model like Node.js formerly did, but the concept of “end of execution of the current runtime instance” is not specific to Node.js and addons should handle it properly, regardless of the choice of the runtime.

If those methods are moved to js_native_api.h, we could use them directly instead, which might be nice.

I guess the separation between node_api.h and js_native_api.h is not 100% clear. The initial thrust was to separate APIs related to JS values from ones related to the environment. Runtime-specific things like AsyncWorker and TSFN have thus also ended up in node_api.h.

The initial thrust was to separate APIs related to JS values from ones related to the environment.

I get that, but I would argue that because Agents are defined in ECMA-262, management of an Agent’s lifetime is also implicitly part of JS ;) Also, like I said, if runtimes don’t support any kind of cleanup, that’s fine and they can just make the functions have empty bodies.

@addaleax I'll talk it over with @nodejs/n-api and make that into a separate PR.

gabrielschulhof · 2019-06-25T22:20:54Z

@addaleax should I include the change whereby I make the CallbackBundle a subclass of Reference so as to obtain env cleanup tracking into this PR?

addaleax · 2019-06-25T22:35:32Z

@addaleax should I include the change whereby I make the CallbackBundle a subclass of Reference so as to obtain env cleanup tracking into this PR?

I think that makes sense, yes, if it’s not too much work

gabrielschulhof · 2019-06-26T01:17:02Z

@addaleax why would this be considered a breaking change? If you provide a finalizer, you'd expect it to be called, right? So, as long as we call it within a valid environment, this should not break anything. What it might do though is expose bugs.

BTW: I have now changed CallbackBundle to manage its life cycle via a Reference.

mhdawson · 2019-06-26T14:56:09Z

@gabrielf what are your thoughts in terms of performance implications?

Related, we had talked about excluding the main thread for performance reasons. Can you comment on the rational if this did not end up making sense?

src/js_native_api_v8.cc

gabrielschulhof · 2019-06-26T20:22:09Z

@mhdawson I have turned off tracking for the main thread, and untracking if the finalizer is being called from the env cleanup.

gabrielschulhof · 2019-07-04T06:09:54Z

@mhdawson I added some counters to see how often an object gets tracked/untracked by having an env cleanup hook added/removed:

diff --git a/src/js_native_api_v8.cc b/src/js_native_api_v8.cc
index 5fe79f75bc..df4bd2e745 100644
--- a/src/js_native_api_v8.cc
+++ b/src/js_native_api_v8.cc
@@ -341,6 +341,7 @@ class Reference : private Finalizer {
   static void EnvCleanupHook(void* data) {
     Reference* reference = static_cast<Reference*>(data);
     reference->_persistent.Reset();
+    reference->_env->track_off_cleanup++;
     reference->RunFinalizer(false);
   }
 
diff --git a/src/js_native_api_v8.h b/src/js_native_api_v8.h
index fffa4ba8df..732a170fe3 100644
--- a/src/js_native_api_v8.h
+++ b/src/js_native_api_v8.h
@@ -33,6 +33,11 @@ struct napi_env__ {
   int open_handle_scopes = 0;
   int open_callback_scopes = 0;
   int refs = 1;
+
+  bool track_hook_added = false;
+  size_t track_off = 0;
+  size_t track_on = 0;
+  size_t track_off_cleanup = 0;
 };
 
 static inline napi_status napi_clear_last_error(napi_env env) {
diff --git a/src/node_api.cc b/src/node_api.cc
index b3f7234a1e..d3ec223f18 100644
--- a/src/node_api.cc
+++ b/src/node_api.cc
@@ -26,10 +26,12 @@ struct node_napi_env__ : public napi_env__ {
   }
 
   void TrackFinalizer(void (*finalizer)(void*), void* data) override {
+    track_on++;
     node_env()->AddCleanupHook(finalizer, data);
   }
 
   void UntrackFinalizer(void (*finalizer)(void*), void* data) override {
+    track_off++;
     node_env()->RemoveCleanupHook(finalizer, data);
   }
 };
@@ -106,6 +108,16 @@ static inline napi_env GetEnv(v8::Local<v8::Context> context) {
         static_cast<void*>(result));
   }
 
+  if (!result->track_hook_added) {
+    result->track_hook_added = true;
+    result->node_env()->AddCleanupHook([](void* arg) {
+      napi_env env = static_cast<napi_env>(arg);
+      fprintf(stderr, "track_on: %lu\n", env->track_on);
+      fprintf(stderr, "track_off: %lu\n", env->track_off);
+      fprintf(stderr, "track_off_cleanup: %lu\n", env->track_off_cleanup);
+    }, result);
+  }
+
   return result;
 }

I then ran the leveldown benchmark from https://github.com/Level/bench and found that leveldown uses no weak references so, at least in its case, there is no interaction with the environment cleanup hooks via the new tracking mechanism.

I'll try and find a N-API addon that uses weak references and has a good benchmarking suite to find out what kind of effect the new tracking has.

gabrielschulhof · 2019-07-04T06:40:25Z

I'll keep searching with @NickNaso's help for a N-API addon that uses weak references and that has a good benchmarking suite.

I can't shake the thought though that a performant library would not leave matters of native memory management to the whim of the garbage collector, lest usage balloon out of control in certain cases. That is, in a tight enough loop, it's always better to use strong references with explicit end-of-life than weak references.

mhdawson · 2019-07-04T13:39:52Z

@gabrielschulhof for some reason I was thinking this might have also affected some of the internal N-API infrastructure for calling functions etc. For example AsyncWrap in node-addon-api looks like it uses a Reference. So maybe look at something that uses AsyncWrap with node-addon-api and has a good benchmark suite?

gabrielschulhof · 2019-07-05T06:31:27Z

@mhdawson I ran the async PI estimate which creates a single async worker and lets it self-destruct with the instrumented version of Node.js and it doesn't produce and weak references.

This change does affect the internal N-API and node-addon-api infrastructure for calling functions. For each binding created, a weak reference is created to the resulting JS function (or in the case of accessors to the object on which the accessor is defined). The purpose of the weak reference is to free the v8impl::CallbackBundle in the case of N-API and the Napi::CallbackInfo in the case of node-addon-api. With this change it attaches an env cleanup handler in addition to attaching a weak callback.

In the case of static bindings this will only affect startup and shutdown. However, in cases where we have function factories and the functions start going out of scope this change will bring with it the additional task of removing the env cleanup handler when the weak callback gets called.

@NickNaso do you happen to know any N-API or node-addon-api addons that use function factories?

NickNaso · 2019-07-05T07:03:23Z

@gabrielschulhof I have to search now I’m traveling I will do when I will came back to home on Sunday.

mhdawson · 2019-07-08T15:16:44Z

This change does affect the internal N-API and node-addon-api infrastructure for calling functions

That is what I'd thought and was worried about with respect to perf. Having said that I guess in the current form it will only affect worker threads of than the check to see if we are running on the main thread or not.

gabrielschulhof · 2019-07-08T16:47:08Z

@mhdawson please note that this only affects the setup and teardown of bindings. It does not change the way a call from JS is passed through to the N-API addon. That's why I singled out function factories. In the case of function factories the setup/teardown may happen often during the life cycle of the addon, but for static bindings, the setup only happens once at init and the teardown only happens once at env cleanup.

gabrielschulhof · 2019-07-08T16:49:03Z

@mhdawson I guess I misunderstood "internal N-API infrastructure for calling function".

mhdawson · 2019-07-09T22:31:45Z

We might not have our terminology lined up yet but I think we talked about this in the recent N-API team meeting and agree that it's only in more limited cases where the extra cleanup will be invoked and only on worker threads.

addaleax · 2019-07-09T22:39:30Z

We might not have our terminology lined up yet but I think we talked about this in the recent N-API team meeting and agree that it's only in more limited cases where the extra cleanup will be invoked and only on worker threads.

… and embedder scenarios? Ideally, I would also like to see this enabled for a default Node.js main thread, but I can see that as a backwards compatibility concern.

mhdawson · 2019-07-10T19:58:46Z

@addaleax that is a good point about embedder scenarios. Ideally we'd be able to do that only for embedder scenarios, possibly through an opt-in versus by default as that would minimize the potential performance/backward compatibility concerns.

mhdawson

LGTM once suggested additional comment is added about why there are 2 lists.

gabrielschulhof · 2019-10-10T16:52:01Z

@mhdawson I added two comments: One in the destructor where it loops over the reference lists, explaining why it must traverse the list of references containing napi_finalize callbacks first, and another where the two lists are declared, explaining that references with napi_finalize callbacks must be stored separately, and referring the reader to the destructor for the reason why.

nodejs-github-bot · 2019-10-10T16:54:03Z

CI: https://ci.nodejs.org/job/node-test-pull-request/25945/

mhdawson · 2019-10-11T22:08:39Z

@gabrielschulhof thanks, looks good :)

src/js_native_api_v8.cc

src/js_native_api_v8_internals.h

Since worker threads are complete Node.js environments, including the ability to load native addons, and since those native addons can allocate resources to be freed when objects go out of scope, and since, upon worker thread exit, the engine does not invoke the weak callbacks responsible for freeing resources which still have references, this modification introduces tracking for weak references such that a list of outstanding weak references is maintained. This list is traversed during environment teardown. The callbacks for the remaining weak references are called. This change is also relevant for Node.js embedder scenarios, because in those cases the process also outlives the `node::Environment` and therefore weak callbacks should also be rendered as environment cleanup hooks to ensure proper cleanup after native addons. This changes introduces the means by which this can be accomplished. A benchmark is included which measures the time it takes to execute the weak reference callback for a given number of weak references. Re: tc39/proposal-weakrefs#125 (comment)

nodejs-github-bot · 2019-10-13T05:47:42Z

CI: https://ci.nodejs.org/job/node-test-pull-request/25995/

nodejs-github-bot · 2019-10-13T06:38:39Z

CI: https://ci.nodejs.org/job/node-test-pull-request/25996/

Since worker threads are complete Node.js environments, including the ability to load native addons, and since those native addons can allocate resources to be freed when objects go out of scope, and since, upon worker thread exit, the engine does not invoke the weak callbacks responsible for freeing resources which still have references, this modification introduces tracking for weak references such that a list of outstanding weak references is maintained. This list is traversed during environment teardown. The callbacks for the remaining weak references are called. This change is also relevant for Node.js embedder scenarios, because in those cases the process also outlives the `node::Environment` and therefore weak callbacks should also be rendered as environment cleanup hooks to ensure proper cleanup after native addons. This changes introduces the means by which this can be accomplished. A benchmark is included which measures the time it takes to execute the weak reference callback for a given number of weak references. Re: tc39/proposal-weakrefs#125 (comment) PR-URL: #28428 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Michael Dawson <[email protected]>

gabrielschulhof · 2019-10-13T07:09:24Z

Landed in 53ca0b9.

Since worker threads are complete Node.js environments, including the ability to load native addons, and since those native addons can allocate resources to be freed when objects go out of scope, and since, upon worker thread exit, the engine does not invoke the weak callbacks responsible for freeing resources which still have references, this modification introduces tracking for weak references such that a list of outstanding weak references is maintained. This list is traversed during environment teardown. The callbacks for the remaining weak references are called. This change is also relevant for Node.js embedder scenarios, because in those cases the process also outlives the `node::Environment` and therefore weak callbacks should also be rendered as environment cleanup hooks to ensure proper cleanup after native addons. This changes introduces the means by which this can be accomplished. A benchmark is included which measures the time it takes to execute the weak reference callback for a given number of weak references. Re: tc39/proposal-weakrefs#125 (comment) PR-URL: nodejs#28428 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Michael Dawson <[email protected]>

Since worker threads are complete Node.js environments, including the ability to load native addons, and since those native addons can allocate resources to be freed when objects go out of scope, and since, upon worker thread exit, the engine does not invoke the weak callbacks responsible for freeing resources which still have references, this modification introduces tracking for weak references such that a list of outstanding weak references is maintained. This list is traversed during environment teardown. The callbacks for the remaining weak references are called. This change is also relevant for Node.js embedder scenarios, because in those cases the process also outlives the `node::Environment` and therefore weak callbacks should also be rendered as environment cleanup hooks to ensure proper cleanup after native addons. This changes introduces the means by which this can be accomplished. A benchmark is included which measures the time it takes to execute the weak reference callback for a given number of weak references. Re: tc39/proposal-weakrefs#125 (comment) PR-URL: #28428 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Michael Dawson <[email protected]>

gabrielschulhof requested review from addaleax and mhdawson June 25, 2019 19:54

nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. node-api Issues and PRs related to the Node-API. labels Jun 25, 2019

gabrielschulhof force-pushed the track-all-finalizers branch from 42afad0 to a3955d6 Compare June 25, 2019 20:33

addaleax reviewed Jun 25, 2019

View reviewed changes

gabrielschulhof force-pushed the track-all-finalizers branch 2 times, most recently from af2c2e6 to aafa352 Compare June 26, 2019 01:12

mhdawson reviewed Jun 26, 2019

View reviewed changes

src/js_native_api_v8.cc Outdated Show resolved Hide resolved

gabrielschulhof mentioned this pull request Jul 1, 2019

n-api: add napi_get_module() #28464

Closed

4 tasks

gabrielschulhof force-pushed the track-all-finalizers branch 2 times, most recently from 874bbec to 0b9b0f3 Compare July 4, 2019 05:36

gabrielschulhof mentioned this pull request Jul 6, 2019

New API to store per-addon-instance data nodejs/abi-stable-node#378

Closed

gabrielschulhof mentioned this pull request Jul 8, 2019

Should finalizers run on exit in Node.js? tc39/proposal-weakrefs#125

Closed

mhdawson approved these changes Oct 9, 2019

View reviewed changes

gabrielschulhof mentioned this pull request Oct 10, 2019

implement Object::AddFinalizer nodejs/node-addon-api#551

Closed

gabrielschulhof force-pushed the track-all-finalizers branch from bccf6b3 to 908cc59 Compare October 10, 2019 16:47

addaleax approved these changes Oct 11, 2019

View reviewed changes

src/js_native_api_v8.cc Outdated Show resolved Hide resolved

src/js_native_api_v8_internals.h Outdated Show resolved Hide resolved

gabrielschulhof force-pushed the track-all-finalizers branch from 908cc59 to 4f39a84 Compare October 13, 2019 05:39

gabrielschulhof closed this Oct 13, 2019

gabrielschulhof deleted the track-all-finalizers branch October 13, 2019 07:16

This was referenced Oct 15, 2019

Memory management questions nodejs/node-addon-api#550

Closed

Garbage collection doesn't free values released during garbage collection (via native pointers) jerryscript-project/jerryscript#2253

Closed

Context-aware add-ons? nodejs/node-addon-api#567

Closed

BethGriggs mentioned this pull request Oct 21, 2019

2019-10-22, Version 13.0.0 (Current) #29504

Merged

gabrielschulhof mentioned this pull request Oct 22, 2019

[v12.x] src: render N-API weak callbacks as cleanup hooks #30070

Closed

3 tasks

gabrielschulhof mentioned this pull request Oct 26, 2019

src: create HandleScope for env retrieval #30130

Closed

2 tasks

targos mentioned this pull request Nov 10, 2019

v12.13.1 release proposal #30352

Merged

addaleax mentioned this pull request Dec 7, 2019

src: migrated to new V8 ArrayBuffer API #30782

Closed

4 tasks

vweevers mentioned this pull request Jan 4, 2020

fix: leveldb iterator memory leak ipfs/js-datastore-level#26

Merged

FauxFaux mentioned this pull request Dec 24, 2020

Segfault on process shutdown with vm.createContext node-ffi-napi/weak-napi#31

Open

vweevers mentioned this pull request Jan 31, 2021

Multiple Assertion Failed !! Level/leveldown#755

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

n-api: render finalizers as env cleanup hooks #28428

n-api: render finalizers as env cleanup hooks #28428

gabrielschulhof commented Jun 25, 2019

addaleax left a comment

addaleax Jun 25, 2019

gabrielschulhof Jun 25, 2019 •

edited

Loading

addaleax Jun 25, 2019

gabrielschulhof Jun 25, 2019 •

edited

Loading

addaleax Jun 25, 2019

gabrielschulhof Jun 25, 2019

gabrielschulhof commented Jun 25, 2019

addaleax commented Jun 25, 2019

gabrielschulhof commented Jun 26, 2019

mhdawson commented Jun 26, 2019

gabrielschulhof commented Jun 26, 2019

gabrielschulhof commented Jul 4, 2019

gabrielschulhof commented Jul 4, 2019

mhdawson commented Jul 4, 2019

gabrielschulhof commented Jul 5, 2019

NickNaso commented Jul 5, 2019 •

edited

Loading

mhdawson commented Jul 8, 2019

gabrielschulhof commented Jul 8, 2019

gabrielschulhof commented Jul 8, 2019

mhdawson commented Jul 9, 2019

addaleax commented Jul 9, 2019

mhdawson commented Jul 10, 2019

mhdawson left a comment

gabrielschulhof commented Oct 10, 2019

nodejs-github-bot commented Oct 10, 2019

mhdawson commented Oct 11, 2019

nodejs-github-bot commented Oct 13, 2019

nodejs-github-bot commented Oct 13, 2019

gabrielschulhof commented Oct 13, 2019

n-api: render finalizers as env cleanup hooks #28428

n-api: render finalizers as env cleanup hooks #28428

Conversation

gabrielschulhof commented Jun 25, 2019

Checklist

addaleax left a comment

Choose a reason for hiding this comment

addaleax Jun 25, 2019

Choose a reason for hiding this comment

gabrielschulhof Jun 25, 2019 • edited Loading

Choose a reason for hiding this comment

addaleax Jun 25, 2019

Choose a reason for hiding this comment

gabrielschulhof Jun 25, 2019 • edited Loading

Choose a reason for hiding this comment

addaleax Jun 25, 2019

Choose a reason for hiding this comment

gabrielschulhof Jun 25, 2019

Choose a reason for hiding this comment

gabrielschulhof commented Jun 25, 2019

addaleax commented Jun 25, 2019

gabrielschulhof commented Jun 26, 2019

mhdawson commented Jun 26, 2019

gabrielschulhof commented Jun 26, 2019

gabrielschulhof commented Jul 4, 2019

gabrielschulhof commented Jul 4, 2019

mhdawson commented Jul 4, 2019

gabrielschulhof commented Jul 5, 2019

NickNaso commented Jul 5, 2019 • edited Loading

mhdawson commented Jul 8, 2019

gabrielschulhof commented Jul 8, 2019

gabrielschulhof commented Jul 8, 2019

mhdawson commented Jul 9, 2019

addaleax commented Jul 9, 2019

mhdawson commented Jul 10, 2019

mhdawson left a comment

Choose a reason for hiding this comment

gabrielschulhof commented Oct 10, 2019

nodejs-github-bot commented Oct 10, 2019

mhdawson commented Oct 11, 2019

nodejs-github-bot commented Oct 13, 2019

nodejs-github-bot commented Oct 13, 2019

gabrielschulhof commented Oct 13, 2019

gabrielschulhof Jun 25, 2019 •

edited

Loading

gabrielschulhof Jun 25, 2019 •

edited

Loading

NickNaso commented Jul 5, 2019 •

edited

Loading