On Mon, 9 Nov 2026 16:30:09 GMT, Shiv Shah <[email protected]> wrote: >> With DeoptimizeALot and the scaled thresholds the test gets more samples >> than allocations, 6099 to 6160 instead of 6000. >> >> >> C2 expands new int[5][5] into six separate allocations, and the safepoints >> in between re-execute the whole multianewarray. DeoptimizeALot can >> deoptimize on the way back from one of those allocation calls, after it was >> already sampled. The interpreter then does all six again. With >> -XX:MultiArrayExpandLimit=0 C2 calls the runtime for the whole array >> instead, and a deopt there continues after the bytecode. Nothing is >> allocated twice. >> >> >> The test now has four ids: C2 expansion on and off, each with and without >> DeoptimizeALot. The run lines override the task flags. Only expansion >> together with deopt can see extra samples, at most six per iteration, so >> that id checks for the expected count up to twice that. The other three keep >> the exact check. The deopt ids need a debug build. >> >> >> --- >> >> Testing: >> - [x] All four ids x5 on linux-x64, linux-aarch64, windows-x64 and >> macosx-aarch64 debug and linux-x64 release, in the two failing >> DeoptimizeALot configs and a C1 -Xcomp config, plus tier1-3 on linux x64 and >> aarch64, all clean. >> >> >> >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Shiv Shah has updated the pull request incrementally with one additional > commit since the last revision: > > Test with and without C2 expanding the multi array and with and without > DeoptimizeALot
Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/33574#pullrequestreview-5832615928
