crypto,tls: fix mutability of return values

[Trott]

If you alter the array returned by tls.getCiphers(),
crypto.getCiphers(), crypto.getHashes(), or crypto.getCurves(), it
will alter subsequent return values from those functions.

'use strict';

const crypto = require('crypto');

var hashes = crypto.getHashes();

hashes.splice(0, hashes.length);

hashes.push('some-arbitrary-value');

console.log(crypto.getHashes()); // "['some-arbitrary-value']"

This is surprising. Change functions to return copy of array instead.

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 tls test util

[Trott]

This reformatting is being done so it matches the formatting in lib/crypto.js so all four functions being talked about here are the same. I can take it out if it's seen as extraneous churn for this change. I'm +0 on including it. /cc @sam-github who flagged this in another PR

[Trott]

Benchmark for this change:

                                         improvement significant      p.value
 crypto/get-ciphers.js v="crypto" n=1       -16.62 %         *** 7.834831e-07
 crypto/get-ciphers.js v="crypto" n=5000    -99.84 %         *** 2.037318e-40
 crypto/get-ciphers.js v="tls" n=1          -10.02 %          ** 5.403611e-03
 crypto/get-ciphers.js v="tls" n=5000       -99.80 %         *** 1.306200e-43

For comparison, here's the benchmark if we remove the caching function entirely instead:

                                         improvement significant      p.value
 crypto/get-ciphers.js v="crypto" n=1       -81.34 %         *** 2.383610e-28
 crypto/get-ciphers.js v="crypto" n=5000    -99.99 %         *** 1.417281e-30
 crypto/get-ciphers.js v="tls" n=1          -76.18 %         *** 1.082342e-30
 crypto/get-ciphers.js v="tls" n=5000       -99.98 %         *** 1.730237e-37

The benchmarks for n=5000 seem like a low priority/concern. Conversation in the original issue where the benchmark/caching was introduced suggests that it was not based on a real-world use case and there was at least one person asking if it was really worth doing. #7225

I'm surprised that there is a perf boost with the caching function when n=1. Not sure if it's a faulty benchmark or some V8 optimization I don't understand or what is going on there. I welcome explanation from any better-informed people.

[Trott]

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

[sam-github]

remove the caching function entirely instead of keeping it but using .slice() to have it return a copy of the array

I think the using slice is included in the benchmark with caching, and the removing the caching function entirely variant does not use slice?

In other words, its faster to cache and slice, then it is to just return the raw value (no caching or slicing)?

In which case, +1 from me for cache+slice. It makes the caching absolutely undetectable by the user, and is still faster than if no caching is done at all.

[Trott]

In other words, its faster to cache and slice, then it is to just return the raw value (no caching or slicing)?

That's right.

( I don't understand why that is the case for n=1, though. Why should caching the result of an action improve performance for an action you only take once?)

[Trott]

Landed in 5695067