Refactor async_hooks initTriggerId

[AndreasMadsen]

• The first commit just renames initTriggerId to defaultTriggerAsyncId. I think default is much more descriptive and we try to never use just id in async_hooks but instead asyncId.
• The second commit changes the magic value from 0 to -1. This is because 0 in the executionAsyncId context refers to a missing context, while 0 in defaultTriggerAsyncId previously meant default context. This allows the defaultTriggerAsyncId to mean missing context too.
• The third commit is the main change. It changes defaultTriggerAsyncId from being set by the setter and reset by the getter, to instead have defaultTriggerAsyncId be bound to a scope. The getter then doesn't change the value. This is much more intuitive than getters mutating its own value. This is actually related to the work done by @refack in async-hooks: internalize setInitTriggerId #14302 but this is a much more complete version of that.

Note: All this is internal logic. However, in node v8.x and v9.x the initTriggerId is unfortunately exported (although deprecated), so properly we need to do a manual backport for those versions.

edit: Oh, the entire motivation behind this is that I want to improve some of our set triggerAsyncIds. However, in those cases, it is not transparent if a new handle is always created thus the kDefaultTriggerAsyncId value might leak. Binding kDefaultTriggerAsyncId to a scope prevents a leak.

Checklist

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

Affected core subsystem(s)

async_hooks

[AndreasMadsen]

/cc @nodejs/async_hooks

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

[Fishrock123]

Seems reasonable in concept but I don't understand the fine details enough to give a review.

[AndreasMadsen]

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

/cc @addaleax @jasnell could you review this?

[AndreasMadsen]

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

/cc @addaleax – please view :)
/cc @nodejs/async_hooks – in general.

[mcollina]

I would add an opaque parameter here that we pass back to block(opaque), so that we can avoid to allocate closures where it was not needed before.

[mcollina]

I would rewrite this as:

err = defaultTriggerAsyncIdScope(self[async_id_symbol], { self, addressType, req, address, port }, connectByType)

where connectByType is defined in the top level as:

function connectByType({ self, addressType, req, address, port }) {
  if (addressType === 4)
    return self._handle.connect(req, address, port);
  else
    return self._handle.connect6(req, address, port);
}

[AndreasMadsen]

@mcollina Thanks. Ended up doing something slightly different to prevent the extra closures.

[mcollina]

Can you move this to a top-level function?

[AndreasMadsen]

@mcollina Done :) Are there any benefits of using destructuring assignments versus good old .apply(null, args)?

[mcollina]

I don't think you can use .apply here, but you could use .bind(). By passing an opaque object/array, we avoid bind()  altogether, and we can leverage the escape analysis in V8 that we are going to get in V8 6.3. Destructuring is just syntactic sugar, you can remove it if you want.
I have no data to say which of the approaches is better in respect to performance: my intent is to remove the closure allocations.

cc @bmeurer

[AndreasMadsen]

Removed the dgram closure. This also makes the triggerAsyncId more consistent, as it doesn't make sense to have triggerAsyncId set to self[async_id_symbol] in only some error conditions :D

[mcollina]

LGTM

[AndreasMadsen]

CI: https://ci.nodejs.org/job/node-test-pull-request/11943/
Benchmark CI (dgram): https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/72/ – Just because I'm curious.

[AndreasMadsen]

@addaleax Could you take a look?

[AndreasMadsen]

@refack Could you take a look. Forgot that you opened the original PR #14302