RFR: 8375046: C2: Assertion failed in GrowableArray::remove_till(0) [v4]

[Vladimir Ivanov]

On Wed, 14 Jan 2026 19:18:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Seen this assert in stress CTW runs:
>> 
>> 
>> # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/utilities/growableArray.hpp:498), pid=2972347, tid=2973775
>> # assert(start < end && end <= this->_len) failed: erase called with invalid range (0, 0) for length 0
>> 
>> Stack: [0x00007fd660bea000,0x00007fd660cea000], sp=0x00007fd660ce4fc0, free space=1003k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V [libjvm.so+0xc00a41] Compile::inline_incrementally_one()+0x801 (growableArray.hpp:498)
>> V [libjvm.so+0xc01650] Compile::inline_incrementally(PhaseIterGVN&)+0x2f0 (compile.cpp:2212)
>> V [libjvm.so+0xc04581] Compile::Optimize()+0x7d1 (compile.cpp:2357) 
>> 
>> 
>> It looks innocuous, as `GrowableArray::remove_range` does nothing real on `[0, 0)`. It is still IMO a bug to call it with `[0, 0)`, as it is not clear whether to trust inclusive or exclusive boundary. But for `remove_till`, it looks plausible that `remove_till(0)` should work and be a no-op. Looks like it readily happens in C2 CTW when `_late_inlines` is empty.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, additional new gtest to verify `remove_range` works
>>  - [x]  Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Leave only the C2 fix
>  - Merge branch 'master' into JDK-8375046-growable-array-till-zero
>  - Only clear pos when needed
>  - Handle the C2 side by removing/inlining remove_till
>  - No trailing comma
>  - Fix

The code implicitly assumes that `_late_inlines` is not empty and it's a reasonable assumption. Any particular reason to handle empty case instead of finishing early?

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

PR Comment: https://git.openjdk.org/jdk/pull/29171#issuecomment-3751692289