lib: rewrite AsyncLocalStorage without async_hooks

[Qard]

I'm working on rewriting AsyncLocalStorage to use v8::SetContinuationPreservedEmbedderData(...) in a similar model to Cloudflare and in anticipation of the upcoming AsyncContext proposal.

This is not done yet but is mostly working as-is. I have not got to benchmarking or writing tests for it yet, but it seems to be passing most of the existing AsyncLocalStorage. 😄

cc @nodejs/diagnostics @nodejs/performance

[nodejs-github-bot]

Review requested:

• @nodejs/gyp
• @nodejs/startup

[Qard]

Also worth considering that as this no longer depends on async_hooks in any way it might make sense to give it a separate module name at some point too and just have async_hooks re-export it.

[Qard]

Some additional notes:

• This will have to be behind a build flag because of a conflict with Chromium using the same single-tenant API in Electron.
• I have not yet wired this up to AsyncWrap. It will need some linkage there to actually work across real async boundaries.
  • current() and exchange() are exposed on the C++ side to make this straightforward but may do some scope helpers for that. We'll see if it's necessary.
• I also need to make a PR to V8 to make it propagate embedder data through thenables.
• There are probably still lots of bugs and the existing tests don't have great coverage. I'll improve those while I'm working on this as I want to be sure we're not breaking any edge cases.

[jasnell]

Woo! Thanks for getting this started. The need for the flag is unfortunate but definitely required given how chromium is using the API and the conflict that causes with electron. But otherwise this should be a major improvement over the current state. Will do a thorough review this weekend.

[Qard]

Another note:

This currently uses a model of building a linked-list of AsyncContextFrames which each contain only the key and value they were constructed with. The alternative which is what was originally proposed was to use a map which is cloned from the parent frame at each frame construction and then the single additional entry for that frame is added but it is considered otherwise immutable.

I went with the current model mostly because it was easier and made debugging simpler but I plan to spend some time benchmarking the two approaches to identify the trade-offs and figure out which approach would be generally better. The one definite downside to the current model is it holds past values for the same store from further up the call graph alive longer which may be undesirable but may only really apply to top-level scopes that will need to be kept alive anyway.

Further analysis should provide some better insight into the behaviour.

[mmarchini]

This is awesome!

Also worth considering that as this no longer depends on async_hooks in any way it might make sense to give it a separate module name at some point too and just have async_hooks re-export it.

That'd be a welcome change. We've been trying to eliminate async_hooks usage in our apps (as we've detected performance issues when async_hooks are misused), and having to import AsyncLocalStorage from the async_hooks module messes with how we detect if an app is using async_hooks or not.

[Qard]

Thenables propagation fix is here: https://chromium-review.googlesource.com/c/v8/v8/+/4674242

[mcollina]

I propose tagging this as semver-major.

[Qard]

@mcollina Could do that. Though the way in which we land it is still not entirely decided. Due to the Electron conflict it needs build-flagging anyway, so this could be landed as a minor if it's by default turned off. It could land off by default and then have a follow-up to turn it on by default as a major. What do you think?

[mcollina]

That works

[Qard]

I've got all but four two of the existing tests passing at this point:

• thenables I have a fix for this here.
• http.Agent, which I haven't yet figured out why my existing AsyncResource patches don't cover it.
• storage.disable(), which currently only blocks propagation after the call but also needs to block for the rest of the tick before the call too in order to pass the existing tests.
• unhandledRejection, which does not match the context of the promise. James said he'll point me at how Cloudflare did it.

[theanarkh]

Hi, @Qard, Can you explain how the API v8::SetContinuationPreservedEmbedderData(...) work ? I have read some docs and code, but I don't understand it very well, thank you ! It looks a bit like SetEmbedderData/GetEmbedderData API.

[Qard]

The SetContinuationPreservedEmbedderData API stores a v8::Value in the v8::Context. Whenever a promise reaction job is created (meaning when it resolves or rejects) it captures the value held at that time and stores it on that reaction job. Whenever the reaction job runs (meaning a then/catch/finally continuation runs) it restores that value as the current stored value and then reverts to the previous value when the job is done.

This is essentially what async_hooks does currently with executionAsyncResource but exclusively for promises. However we can also manipulate that current value externally to capture and restore the value around AsyncWrap, AsyncResource, and any other scope we need to manipulate to match our execution flow.

[Qard]

I'm going to just land this and start a follow-up PR with further improvements. What's here works, and I'd like to get it into users' hands sooner rather than later to start gathering feedback. The remaining suggestions are largely cosmetic, so I will just defer those to the follow-up rather than dealing with yet another round of CI flakiness and endless restarts. 😅

[nodejs-github-bot]

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

[Qard]

I accidentally added the request-ci label rather than the commit-queue label so now I need to wait for the CI again. Hopefully I get lucky and don't get bit by flakes. 🙈

[nodejs-github-bot]

Landed in d1229ee

[kibertoad]

@Qard Hey! Did you ever get to benchmarking the change?

[Qard]

Yep. See: #48528 (comment)

[kibertoad]

@Qard thanks, this looks great!