Open Bug 1838887 Opened 1 year ago Updated 7 months ago

Support larger BigInt values for compatibility with Chromium


(Core :: JavaScript Engine, enhancement, P3)





(Reporter: tdulcet, Unassigned)


(Blocks 1 open bug)


(Keywords: parity-chrome)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/114.0

Steps to reproduce:

Create a large BigInt:

const huge = 1n << 1048576n;

Actual results:

Firefox throws a RangeError: BigInt is too large to allocate error.

Expected results:

Firefox should instead create the huge BigInt. This works as expected in Chrome/Chromium.

Here is a simple program to test this:

for (let i = 1n; ; i <<= 1n) {
  1n << i;

When running this program Chrome/Chromium, it does not throw an error until i is 1073741824, which is 1024 times larger than Firefox, making the resulting value 2^1024 times larger. I am working on an extension that needs to operate on large Mersenne and Fermat numbers, which are larger than this current Firefox BitInt limit.

While there is a clear location, as well as part of the reasoning:

Fixing this bug would imply looking at all locations of potential performance issues.

Jan, in addition to the existing comment, do you happen to know which code path should we watch for performance issue if the previous limit is bump? Would be nice to have it next to the existing comment or in bugzilla if possible.

Blocks: sm-runtime
Severity: -- → N/A
Flags: needinfo?(jdemooij)
Priority: -- → P3

I think we'd need to add back the maximum BigInt check in ToIntlMathematicalValue which was removed in

The maximum length for JSC and SpiderMonkey is 1024 * 1024 bits, about one million or 1 << 20.

V8's limit is 1 << 30 or about one billion.

Let me see what it'd take to increase this...

I don't have time to work on this atm. It's doable but will need some careful auditing, for example for the issue anba mentioned in comment 2.

Flags: needinfo?(jdemooij)
You need to log in before you can comment on or make changes to this bug.