Const and loop fixes.

[aardvark179]

This is in draft because there are still a couple of legacy kinks I need to work out, and I need to reorder and tidy up the commits, but I almost have something that maintains legacy behaviour and doesn't cause test regressions.

[gbrail]

Do you think this will fix the problems we have with "threejs" in the other two big PRs you have? If so I'll take a look as soon as it's ready. That one benchmark is a doozy, I'm OK with moving forward but my preference would be to keep it working while we work on other new things.

[aardvark179]

I've tried stacking up all the changes, and I still see a failure with three JS. As far as I can tell it used to fall back silently to the interpreter because it overflowed the constant pool. Fixing a bug in the constant pool code stopped it over flowing, so now we try to run the compiled class file and it crashes. I've tried chopping down three.js a bit, and that makes it work, and the boundary is suspiciously close to 65K invoke dynamic instructions.

I will see about putting together some to split large class files at compilation time to avoid this.

[gbrail]

Thanks! I hacked a lot on the build for that rhino-benchmarks project and it should be easier to build now, but if it helps I can make an easier way to reproduce it. I see those benchmarks right now as really handy, giant pieces of tangled JS code to exercise Rhino intensively, and I'm glad we have them. I really do think that we should keep at it until that test at least doesn't break. I agree it'd help a ton if we could split class generation into multiple classfiles so we don't fall back to the interpreter so often, but that's a huge task and we have many more important ones.

…

On Wed, Sep 23, 2026 at 11:35 AM Duncan MacGregor ***@***.***> wrote: *aardvark179* left a comment (mozilla/rhino#2500) <#2500 (comment)> I've tried stacking up all the changes, and I still see a failure with three JS. As far as I can tell it used to fall back silently to the interpreter because it overflowed the constant pool. Fixing a bug in the constant pool code stopped it over flowing, so now we try to run the compiled class file and it crashes. I've tried chopping down three.js a bit, and that makes it work, and the boundary is suspiciously close to 65K invoke dynamic instructions. I will see about putting together some to split large class files at compilation time to avoid this. — Reply to this email directly, view it on GitHub <#2500?email_source=notifications&email_token=AAD7I25CG32TSUFMNJFQGG35QQJXTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOBQGA3DMNRWGIZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5800666622>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7I26J3MBBZGFIAEARICL5QQJXTAVCNFSNUABDKJSXA33TNF2G64TZHMYTOMZZG43DOO2JONZXKZJ3GU2TINJTGM4TSOJSUF3AE> . You are receiving this because you commented.Message ID: ***@***.***>

[aardvark179]

I'm not sure classfile splitting is quite as hard as you think, I think I have enough of a plan to knock up a prototype. Also I might see if I can try reproducing the failure on debug build. It might be quite slow to run the compilation on a debug build, so I'll see if I can provoke the crash with a jack built version.

[aardvark179]

I have a working class splitter, and can now load three.js as compiled code without issue. I'll try and package that up with the other constant pool fixes and tidy it up a bit (it's a little brute force at the moment).

[aardvark179]

Okay, this is now in a state where it's at least worth an initial review. The tests around global function declaration that are now failing are doing so because we don't correctly distinguish between the declaration of functions and variables. According to the spec in non-strict mode a script like this function NaN() {} should throw a type error, but NaN = 1.2; should not throw an error (because NaN is a read only non-configurable property on globalThis not a const). Now we do the correct thing for consts we do the wrong thing for functions. For extra fun (function NaN() {} ) should not throw a an error.

I think this is okay for now, because sorting out the horrors of global function declaration is probably a PR in itself.