JS backend: Using BigInt-literals for long-emulation

[tryone144]

Since the legacy long-emulation layer has been removed (9f12917), TeaVM assumes BigInt to be available for the JS backend.

Under this assumption, the JS environment should be able to parse source code that includes BigInt-literals (e.g. 1n in addition to BigInt(1)) without errors. I could not find any documentation of (common) JS runtimes that support BigInts while not accepting literal notation.

Some preliminary tests showed that using the literal syntax when translating Java's long literals can significantly improve the performance. Is there interest in a PR incorporating these changes?

[konsoletyper]

I'm not sure. For me there's one use case: I also run TeaVM-generated JS in Rhino. I'm not sure that Rhino supports BigInt literals.

Some preliminary tests showed that using the literal syntax when translating Java's long literals can significantly improve the performance

Can you should your benchmarks with your changes?

[tryone144]

You can find the actual benchmark code as a teavm sample here. This is work-in-progress and might take a while to run.

The most up to date changes to the long-emulation runtime are in the long-emulation branch. These have been rebased multiple times already and still include some changes that turned out to be worse than before.
I have a bunch of table-like results and graphs for each commit in that branch from running the benchmark in both chrome and firefox on my machine. But this is a bit much for a GitHub issue/PR.

IIRC, HEAD currently points to using a global BigInt64Array initialized with BigInt-literals (similar to the string-pool). This kind of pooling yields some improvement over manual BigInt() constructors, especially for literals that don't fit into a 32-bit int — but is most likely slower than using BigInt-literals directly.

Regarding Rhino: mozilla/rhino#837 appears to have implemented BigInt support for version 1.7.14+, including BigInt-literals in this commit.

[tryone144]

But this is a bit much for a GitHub issue/PR.

Managed to merge at least the result graphs into a single PDF: tests.pdf