Repository: node
Issue: performance.getEntries and performance.getEntriesByName cause call stack size to be exceeded
Labels: perf_hooks

### Version

v18.14.0 - v22.7.0

### Platform

```text
Darwin x86_64
```


### Subsystem

perf_hooks

### What steps will reproduce the bug?

Executing this script:
```javascript
// Established warning threshold for number of performance entries
// https://github.com/nodejs/node/blob/v22.x/lib/internal/perf/observe.js#L105
const performanceEntryBufferWarnSizeThreshold = 1e6;

for (let numEntries = 1e4; numEntries <= performanceEntryBufferWarnSizeThreshold; numEntries += 1e4) {
  console.log(`Testing ${numEntries} entries`);

  for (let i = 0; i < numEntries; i++) {
    performance.mark(`mark-${i}`);
  }

  performance.getEntriesByName('mark-0')

  performance.clearMarks();
}

console.log('Done');
```

### How often does it reproduce? Is there a required condition?

100% of the time

### What is the expected behavior? Why is that the expected behavior?

The expected behaviour is that the script completes successfully given the number of performance entries at any time is below the [established warning threshold](https://github.com/nodejs/node/blob/v22.x/lib/internal/perf/observe.js#L105):

```
...
Testing 980000 entries
Testing 990000 entries
Testing 1000000 entries
Done
```

### What do you see instead?

With the default stack size of 984kB the script consistently fails at an order of magnitude lower than the [established warning threshold](https://github.com/nodejs/node/blob/v22.x/lib/internal/perf/observe.js#L105):

```
...
Testing 110000 entries
Testing 120000 entries
Testing 130000 entries
node:internal/perf/observe:517
    ArrayPrototypePushApply(bufferList, markEntryBuffer);
    ^

RangeError: Maximum call stack size exceeded
    at filterBufferMapByNameAndType (node:internal/perf/observe:517:5)
    at Performance.getEntriesByName (node:internal/perf/performance:106:12)
    at Object.<anonymous> (test_file.js:12:15)
    at Module._compile (node:internal/modules/cjs/loader:1546:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1691:10)
    at Module.load (node:internal/modules/cjs/loader:1317:32)
    at Module._load (node:internal/modules/cjs/loader:1127:12)
    at TracingChannel.traceSync (node:diagnostics_channel:315:14)
    at wrapModuleLoad (node:internal/modules/cjs/loader:217:24)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:166:5)

Node.js v22.7.0
```

### Additional information

This bug appears to have been introduced in [v18.14.0](https://nodejs.org/en/blog/release/v18.14.0#:~:text=%5B1e32520f72%5D%20%2D%20tools%3A%20add%20ArrayPrototypeConcat%20to%20the%20list%20of%20primordials%20to%20avoid%20(Antoine%20du%20Hamel)%20%2344445) when #44445 added a [usage of the ArrayPrototypePushApply primordial in filterBufferMapByNameAndType](https://github.com/nodejs/node/blob/v22.x/lib/internal/perf/observe.js#L517-L519) as part of an effort to eliminate usages of `ArrayPrototypeConcat`.

`ArrayPrototypePushApply` is a variadic function, which appears to be problematic in this instance because it’s being called with each element in the buffer of performance entries - each passed as individual arguments. The size of the performance entries buffer is effectively unbounded, so at scale the underlying `Array.prototype.push` method is being called with an unbounded number of arguments resulting in massive stack frames which cause the maximum call stack size to be exceeded.

If this is, as it appears, to be a general risk with the usage of variadic primordials with unbounded argument lists it may at least be worth a callout in the [primordials documentation on variadic functions](https://github.com/nodejs/node/blob/main/doc/contributing/primordials.md#variadic-functions).