Repository navigation
idea: detect JS calls at compile time #1367
Description
Recording this idea so it doesn't slip under the radar:
In support of pure finalizers, I'm wondering if it's possible to templetize napi::Environment such that one specialization attaches js-execution-capable finalizers whereas the other attaches pure finalizers. We can use type inference to specialize the right class for a given user-provided finalizer.
That is, if the user's finalizer, after inlining and all, contains no calls to functions that execute JS, then we specialize the environment that attaches pure finalizers, otherwise we specialize the environment that does not. That way, add-on maintainers whose finalizers do not really execute javascript could simply recompile and have their memory leak worries go away without any code changes, once nodejs/node#42651 lands.
The reason I chose napi::Environment as the "probe" which will tell us whether the user's finalizer ends up calling a Node-API that executes JS is that all Node-APIs require an environment, so the type inference will snap to a non-pure napi::Environment if there is even one call to a JS-executing Node-API in the user's code.
We can actually work on this before nodejs/node#42651 lands, but for now we'll attach finalizers the same way whether or not their body calls into JS. Maybe we can use #warning to output compiler messages indicating whether the finalizer would have been pure or not.
Another aspect is this: if there are two napi::Environment classes available and you pass the wrong one to the API that sets up the finalizer, it will fail to compile if you pass a "pure" environment along with a finalizer that does not accept such a "pure" environment.
Activity
gabrielschulhof commentedon Sep 15, 2023
After discussing at today's Node-API meeting, we concluded that, in core, we should guard the new pure env functionality with an additional
NODE_API_EXPERIMENTAL_PURE_ENVflag. The motivation and policy are as follow:NAPI_EXPERIMENTAL, allowing adopters running with NAPI_EXPERIMENTAL to independently adopt each experimental feature.NAPI_EXPERIMENTALwhen we make a new Node-API release.NAPI_EXPERIMENTALflag.gabrielschulhof commentedon Oct 6, 2023
nodejs/node#50060 is the first step. Then we have to turn on
NODE_API_EXPERIMENTAL_PURE_ENVin node-addon-api and plumb the changes through its code base.github-actions commentedon Jan 5, 2024
This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.
github-actions commentedon May 3, 2024
This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.
gabrielschulhof commentedon Jun 24, 2024
There is no way to define
Napi::Envsuch that we can glean from the body of the finalizer whether it calls any APIs that require the execution of JS. #1514 takes us part of the way towards that goal, but the user still has to indicate that their finalizer does not make any calls that require aNapi::Envby providing a finalizer with theNapi::NogcEnvsignature.