[wasm] add a total wasm bytes quota to the jiterpreter; adjust parameters #80266
Conversation
…ay too much code in degenerate cases
kg
requested review from
lambdageek,
lewing,
pavelsavara and
vargaz
as code owners
|
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsThis PR adds a configurable quota to the jiterpreter that will stop it from generating more code once a total number of WASM bytes is hit. For some degenerate cases (like massive test suites) we could otherwise end up generating a truckload of modules and potentially hit corner cases in the browser or exhaust memory. At present System.Runtime.Tests generates around 2 megabytes of WASM in a full run with everything turned on, which is (IMO) pretty reasonable, but also shows how bad it could get. For AOT applications we are way less likely to approach the quota I also adjusted some of the jiterpreter tuning parameters in this PR. The current ones in main (chosen arbitrarily at the time) cause S.T.J's test suite to be slower than w/o the jiterpreter in some cases, and these adjustments bring its execution times back in line with normal. (It should really be faster, but I believe this is a degenerate case and it is faster in browser-bench.) At some point we'll want to more aggressively evaluate what the right values for these parameters are, but for now I think this is an improvement.
|
ghost
added
the
2 participants
This PR adds a configurable quota to the jiterpreter that will stop it from generating more code once a total number of WASM bytes is hit. For some degenerate cases (like massive test suites) we could otherwise end up generating a truckload of modules and potentially hit corner cases in the browser or exhaust memory.
At present System.Runtime.Tests generates around 2 megabytes of WASM in a full run with everything turned on, which is (IMO) pretty reasonable, but also shows how bad it could get. For AOT applications we are way less likely to approach the quota
I also adjusted some of the jiterpreter tuning parameters in this PR. The current ones in main (chosen arbitrarily at the time) cause S.T.J's test suite to be slower than w/o the jiterpreter in some cases, and these adjustments bring its execution times back in line with normal. (It should really be faster, but I believe this is a degenerate case and it is faster in browser-bench.) At some point we'll want to more aggressively evaluate what the right values for these parameters are, but for now I think this is an improvement.