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

Reworked this one, see the description. The extra samples come from C2 
expanding the allocation inline, a deopt in the middle makes the interpreter 
redo all six. The test now runs with expansion on and off, each with and 
without DeoptimizeALot, and only the expansion plus deopt id allows extra 
samples. The lower bound stays for all four

-------------

PR Comment: https://git.openjdk.org/jdk/pull/33574#issuecomment-6745706808

Reply via email to