timers: allow Immediates to be unrefed

[apapirovski]

Slightly refactor the Immediates handling to allow for them to be unrefed, similar to setTimeout, but without extra handles. Adds immediate.ref() and immediate.unref().

There's a roughly 5-10% performance regression on some of the immediate benchmarks, as well as a more substantial regression on clearImmediate. Both are a result of needing to track an extra property on the Immediate class. That said, since 9.0.0 got released we've seen the performance on setImmediate benchmarks grow by roughly 40-50%, so IMO we can afford this slight regression.

CI: https://ci.nodejs.org/job/node-test-pull-request/12523/
Benchmark CI: https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/96/
CitGM: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/1202/

Checklist

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

Affected core subsystem(s)

timers

[fhinkel]

I have a hard time understanding this sentence. Could you re-write it with simpler grammar? 🙏

[apapirovski]

I don't mind rewriting but the current version is basically copy & pasted from Timers. If I'm doing that, I would prefer to do both in the same PR — if you don't mind?

[fhinkel]

That's fine then!

[apapirovski]

Some changes to the performance profile here and also accounting for a few more edge cases around clearImmediate & ref/unref combination.

I need to write a few more tests before this lands but not sure when I'll get around to them.

CI: https://ci.nodejs.org/job/node-test-pull-request/12529/
Benchmark CI: https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/98/
CitGM: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/1203/

[jasnell]

Rather than a bool, I'd prefer an enum type argument here.

[apapirovski]

I didn't want that argument to be used, to be honest (it was solely there to not have to replicate the code within SetUnrefImmediate). Would something like this address the concern (with CreateImmediate being private)? Or would you still prefer enum in this situation?

void Environment::CreateImmediate(native_immediate_callback cb,
                               void* data,
                               v8::Local<v8::Object> obj,
                               bool ref) {
  native_immediate_callbacks_.push_back({
    cb,
    data,
    std::unique_ptr<v8::Persistent<v8::Object>>(obj.IsEmpty() ?
        nullptr : new v8::Persistent<v8::Object>(isolate_, obj)),
    ref
  });
  immediate_info()->count_inc(1);
}

void Environment::SetImmediate(native_immediate_callback cb,
                               void* data,
                               v8::Local<v8::Object> obj) {
  CreateImmediate(cb, data, obj, true);

  if (immediate_info()->ref_count() == 0)
    ToggleImmediateRef(true);
  immediate_info()->ref_count_inc(1);
}

void Environment::SetUnrefImmediate(native_immediate_callback cb,
                                    void* data,
                                    v8::Local<v8::Object> obj) {
  CreateImmediate(cb, data, obj, false);
}

[jasnell]

Since CreateImmediate() is private, it's not a big deal. Just a preference.

[apapirovski]

Thanks everyone! Landed in c123467

[evanlucas]

This does not land cleanly on v9.x-staging. Can you submit a backport PR?

[AndreasMadsen]

Backported in #18488