monty-js: allows maxMemory, allocation, recursion depth, and gc interval limits above u32::MAX

[sathish-t]

On the javascript side, max memory was limited to approx 4GB (u32::MAX) whereas the Rust and Python limits were larger I believe. I am interested in HPC applications, so wanted to push this higher. I wrote the code with an agent but I reviewed and am happy with it.

Had to convert max_memory: Option<u32> to Option<f64> as f64s are needed for a clean conversion from the number datatype on the Javascript side. I decided to panic on invalid inputs to maxMemory as that was similar in behaviour to Duration::from_secs_f64 in this part of the codebase. I can change to TryInto, Err etc. and avoid a panic if you want.

What changed

• changed crates/monty-js/src/limits.rs so JsResourceLimits.max_memory is accepted as f64 instead of u32
• continued converting maxMemory into Rust's usize before constructing monty::ResourceLimits
• added explicit checks that maxMemory is:
  • finite
  • non-negative
  • an integer
  • within JS safe integer range (<= 2^53 - 1)
  • representable as Rust usize on the current platform
• kept invalid maxMemory handling as a panic, which is consistent with other host-configuration paths such as Duration::from_secs_f64
• added JS tests showing maxMemory accepts:
  • a value below u32::MAX
  • a value above u32::MAX

Ran successfully

• make test-js
  This includes the new JS coverage for values below and above u32::MAX.

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 2 additional findings.

[codspeed-hq]

Merging this PR will not alter performance

✅ 16 untouched benchmarks
⏩ 15 skipped benchmarks¹

---

_{Comparing sathish-t:monty-js-max-memory-u32-cap (532a5b0) with main (08817fc)}

Footnotes

1. 15 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[codecov]

Codecov Report

❌ Patch coverage is 50.00000% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
crates/monty-python/src/limits.rs	50.00%	0 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[davidhewitt]

Thanks, happy to proceed with this, would like to see the unhappy paths adjusted first.

[sathish-t]

I've also made max allocation, recursion depth and gc intervals able to go above u32::MAX. I have HPC use cases where I may need larger max allocations. For the other two, I just made the JS side code consistent with the Python and Rust side code. I think it is unlikely anyone would want recursion depth to go above u32::MAX, no feeling on gc interval.

[davidhewitt]

Super, thank you. It'd be great to fix the pre-existing panics please.

[sathish-t]

Looks like I bit off more than I could chew! I fixed the two pre-existing panics (the python side and the javascript side Duration::from_secs_f64), and a third instance of the same issue in the CLI. But after fixing the CLI issue by making limits fallible, Devin warned that I did not put back some mounts if the limit parsing fails and I fixed that too. As I am touching the python and CLI limit parsing, the PR scope becomes wider, so the name of the PR is not great! What do you think?