1870207 - IonMonkey eliminates bigintasuintn in GVN which may throw an exception

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine: JIT, defect)

Description

[2628388509]

Attachment: poc.js

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36

Steps to reproduce:

1. build latest SpiderMonkey: ./mach build
2. run poc.js: ./js --no-threads --blinterp-warmup-threshold=0 --baseline-warmup-threshold=0 --trial-inlining-warmup-threshold=0 --ion-warmup-threshold=3 poc.js

(Attached file is poc.js)

Actual results:

SpiderMonkey prints only one "RangeError: BigInt is too large to allocate".

Expected results:

SpiderMonkey should print two "RangeError: BigInt is too large to allocat". Because poc.js invoke f0 twice.

Comment 1

[Iain Ireland [:iain]]

Thanks for the report, but this is the intended behaviour.

In general, the JS specification pretends that computers have infinite memory, and doesn't put strict requirements on what implementations should do when there isn't enough memory. Code that depends on the maximum size of a BigInt is not guaranteed to be portable between browsers. So the spec is silent on whether we should throw an exception here or not.

This gives us leeway to perform optimizations. In this case, Ion sees that the BigInt is unused and removes the code. In the same way, code running in baseline might throw a stack overflow error that won't happen in Ion because the Ion code made more efficient use of stack space. We could jump through hoops to ensure that we throw resource-exhaustion errors like this in exactly the same way in all tiers, but the spec doesn't require it, it would be a bunch of work, and the end result would be worse code. Real-world code shouldn't depend on this sort of thing anyway.

There are occasional edge-cases. There was a bug a few years ago that I can't find right now where increasing our stack size caused performance regressions on a game website using an obfuscator that deliberately triggered stack overflow over and over again to make it harder to analyze using devtools. Until we see a problem on a real website, though, we will generally let the optimizer do its work, even if it can lead to "missing" exceptions in corner cases.

Comment 2

[2628388509]

All right. Thanks for your reply.