crypto: make createXYZ inlineable

[mcollina]

This commit increase by around 10% hot code paths that are hitting
createXYZ functions. Before this change the createXYZ called the XYZ
constructor without new.

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)

crypto

[mcollina]

This is just an example. We should do the same for all the rest of the createXYZ methods in crypto, and maybe in other places as well.

[mscdex]

Yes, I think we should be doing it for the rest as well.

[mcollina]

The reason it was not inlining was with the following output:

Not inlining Hash into etag because call is recursive

[mcollina]

@mscdex do you prefer if we do all of them here, or we do this into separate PRs?

[TimothyGu]

With the understanding that this is going to be done with all the other creation functions, LGTM.

[bmeurer]

LGTM.

For the record: We removed the recursive inlining restriction recently.

[mcollina]

@bmeurer is this worth doing then? In which version of V8 this is going to be part of?
The problem I describe is still present in node master.

[mcollina]

I have ported all the createXYZ functions.

[mscdex]

I think it's worth doing for now, especially for node v8.x which may not see the version of V8 where the fixed is applied.

[mscdex]

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

[bengl]

Please add a quick comment explaining the optimization.

[mcollina]

@bengl done.

[bmeurer]

@mcollina I just noticed that we still disallow direct recursive inlining (as of 08bfcb293cfff2d71bcfb28fae8679d0b29a3d5c), so even though indirect recursion is handled, direct recursion is not.

These changes are in V8 6.2. So for Node 8 it definitely makes sense to land this change.

[mscdex]

Minor nits:

s/function/helper functions/

Also, might use more generic wording like 'These helper functions are needed because the constructors can use new, in which case V8 cannot inline the recursive constructor call' or something along those lines.

[mcollina]

CI before landing: https://ci.nodejs.org/job/node-test-pull-request/10523/

[mcollina]

Landed as 9bc4f86

[MylesBorins]

This does not land cleanly on v8.x

Would someone be willing to backport if it makes sense?

[lpinca]

assert.strictEqual(crypto.createHash,crypto.Hash);

et al. throw with this change, should we backport anyway?

[MylesBorins]

@lpinca if it is breaking than this should likely be tagged semver-major, if not then I don't see why we shouldn't backport

[lpinca]

@MylesBorins yes exactly I'm not sure if it's a breaking change or not.

[MylesBorins]

setting semver-major for right now

/cc @nodejs/tsc to chime in. Feel free to change tag

[mcollina]

According to our doc, this is patch. if people are calling createHash with new, probably they are doing somethig wrong. This can go in 8. Or we can bake it for a bit on 9 and then backport to 8.
Most of the discussion in this issue is about landing it in 8.

[jasnell]

I'm +1 on it being semver-patch.

[lpinca]

Backport in #16446 marked as blocked currently.

[MylesBorins]

dropping semver-major. Thinking we should let this bake in 9.x a bit first