web-tooling-benchmark error

[bnoordhuis]

https://github.com/quickjs-ng/web-tooling-benchmark no longer runs with master:

$ ../quickjs/build/release/qjs --script dist/cli.js
Running Web Tooling Benchmark v0.5.3…
-------------------------------------
         acorn:  0.42 runs/s
         babel:  1.07 runs/s
  babel-minify:  1.05 runs/s
       babylon:  0.77 runs/s
         buble:  1.39 runs/s
          chai:  2.07 runs/s
        espree:  0.30 runs/s
Encountered error running benchmark esprima, aborting…
    at <anonymous> (dist/cli.js:147221:27)
    at <anonymous> (dist/cli.js:145250:30)
    at call (native)
    at <anonymous> (dist/cli.js:145221:37)
    at <anonymous> (dist/cli.js:145835:51)
    at call (native)
    at <anonymous> (dist/cli.js:145221:37)
    at <anonymous> (dist/cli.js:145940:26)
    at <anonymous> (dist/cli.js:145984:26)
    at call (native)
    at <anonymous> (dist/cli.js:145221:37)
    at <anonymous> (dist/cli.js:145990:26)
    at call (native)
    at <anonymous> (dist/cli.js:145221:37)
    at <anonymous> (dist/cli.js:146025:26)
    at call (native)

It's unclear to me why that happens, or when it started, but it definitely ran to completion in the past. web-tooling-benchmark hasn't changed so it must be something on quickjs-ng's side.

[bnoordhuis]

Passes with --stack-size 2048:

$ ../quickjs/build/release/qjs --stack-size 2048 --script dist/cli.js
Running Web Tooling Benchmark v0.5.3…
-------------------------------------
         acorn:  0.40 runs/s
         babel:  1.06 runs/s
  babel-minify:  1.06 runs/s
       babylon:  0.76 runs/s
         buble:  1.37 runs/s
          chai:  2.07 runs/s
        espree:  0.30 runs/s
       esprima:  0.53 runs/s
        jshint:  1.20 runs/s
         lebab:  1.09 runs/s
       postcss:  0.65 runs/s
       prepack:  1.25 runs/s
      prettier:  0.72 runs/s
    source-map:  0.73 runs/s
        terser:  3.14 runs/s
    typescript:  0.81 runs/s
     uglify-js:  0.84 runs/s
-------------------------------------
Geometric mean:  0.91 runs/s

[bnoordhuis]

I'm chalking this one up to "worked by accident before" for now.

[saghul]

Perhaps is a side-effect of the change in the stack size unit? At any rate, does it make sense to revisit the current default stack size of 256Kb?

[bnoordhuis]

V8 defaults to ~900k and that's sufficient to run web-tooling-benchmark in qjs, so, one the one hand, yes, good idea; on the other hand, maybe that breaks existing users? I can't really come up with a credible example though.

On a side note: with glibc, you can:

pthread_attr_t attr;
void *stack_top;
size_t stack_size;
pthread_attr_np(pthread_self(), &attr);
pthread_attr_getstack(&attr, &stack_top, &stack_size);

Where stack_top is in fact the lowest possible address because stacks grow downward.

That's a fairly reliable way of detecting how much stack space is available in JS_Eval but it's not very portable and means taking on a dependency on pthreads in quickjs.c, which not everyone will appreciate.

(No real conclusion here, just me musing out aloud.)

[saghul]

We could try and bump it, not sure what would break TBH.

I'm wondering why 900k? 1M is right there and is a nice power of 2 😅

Edit: yeah I'd try to avoid depending on pthreads like that...

[bnoordhuis]

I'm wondering why 900k? 1M is right there and is a nice power of 2

That's exactly what the Windows kernel team thought and is why the main stack is a nice round 1 MiB :)

For V8/Chromium, it's actually quite a bit more complicated than that. The default is 984k but they drop down to 864k on 32 bits Windows because of parasitic third-party integration software that gobbles up ~100k stack space, the kind of closed-source trash oldnewthing's Raymond Chen regularly writes about.

WASM is another environment where the stack is (usually) exactly 1 MiB.

[saghul]

Here is a PR: #756