async_hooks: callback trampoline for MakeCallback#33801
Conversation
2096bab to
8942366
Compare
|
I added a commit which removes the last vestiges of native domain code, moving the domain hook callback to be registered directly with async_hooks internals. Eventually I hope to generalize that as a feature for other hook mechanisms like fs hooks, audit hooks, etc. to be able to hook more deeply into the callback execution flow. For now, this domain-specific function storing should be enough. |
|
Here's a full run of all the async_hooks benchmarks. |
a0fd282 to
410acd0
Compare
With the async_hooks callback trampoline, domains no longer need any native code. With this, domains can exist in pure JavaScript.
410acd0 to
27276c3
Compare
|
I've run https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/604/ |
|
Switched to ready to review. It's functional as it is and seems to provide a bit of improvement already. I still intend to follow this up with some more changes I'm working on now to move the resource stack management to JS, but I'm less certain about that part due to the current need to always track the resources, even when async_hooks is disabled. |
This is the start of an effort to eliminate the additional two native-to-JavaScript barrier crosses for the before and after events when async_hooks is active. It also moves the domain callback to be triggered within the trampoline rather than on the native side, when there are before/after events to trigger.
I plan to work on making the domain callback trigger fully JavaScript-side tomorrow which should eliminate the need to even have native-side code for domains. Currently the only native code we have for domains is storing the callback in the environment so it can be triggered from this single location in
callback.cc. With that no longer being triggered on the native side there's actually no reason to even store it on the native side so that could be easily eliminated to allow domains to live entirely on the JS side.I'm also hoping to move the execution async resource stack to be managed purely on the JS side too, through this trampoline. This should eliminate the need for the extra state synchronization code needed in #33575 for the performance gains it aims to make.
Side note: There's no try/catch in the trampoline because it currently relies on
InternalCallbackScopeto catch errors and handle them appropriately. It's also relying onInternalCallbackScopefor other things like timer and microtask management, so some deeper modifications will need to be made if we want to move any of that to the JS side too. Personally, I think it's worth considering, and I plan to continue investigating that idea.Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passes