RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException.

[Stuart Monteith]

Hi,
  Using c_rarg1 and c_rarg2 instead of rscratch1 and overwriting
rscratch2 causes a SIGSEGV.
Using r22 and r23 instead, the test ran successfully.

In c1_CodeStubs_aarch64.cpp
:
 77   if (_index->is_cpu_register()) {
 78     __ mov(r22, _index->as_register());
 79   } else {
 80     __ mov(r22, _index->as_jint());
 81   }
 82   Runtime1::StubID stub_id;
 83   if (_throw_index_out_of_bounds_exception) {
 84     stub_id = Runtime1::throw_index_exception_id;
 85   } else {
 86     assert(_array != NULL, "sanity");
 87     __ mov(r23, _array->as_pointer_register());
 88     stub_id = Runtime1::throw_range_check_failed_id;
 89   }

in c1_Runtime_aarch64.cpp:

 336   if (!has_argument) {
 337     call_offset = __ call_RT(noreg, noreg, target);
 338   } else {
 339     call_offset = __ call_RT(noreg, noreg, target, r22, r23);
 340   }

There is the possibility of overwriting live values though, aren't
there? The registers are saved by call_RT. Should I be concerned about
deopt and debugging going wrong? Furthermore, won't there be issues in
exception handlers?

BR,
  Stuart


On 25 April 2018 at 16:49, Stuart Monteith <stuart.monteith at linaro.org> wrote:
> Indeed - and that is what I am seeing. Usually no parameters are being
> called with this pattern, or rscratch1, with the temporary variable
> being changed to use rscratch2 in such circumstances.
> I'll try c_rarg1 and c_rarg2 - they should pass straight through,if I
> interpret the code correcting.
>
> On 25 April 2018 at 16:26, Andrew Haley <aph at redhat.com> wrote:
>> On 04/25/2018 04:00 PM, Stuart Monteith wrote:
>>> I'm not quite sure to solve this yet - we'll need to use the stack in
>>> some safe way.
>>
>> It's not a great idea to pass arguments in rscratch1 or rscratch2.  These
>> registers are for use in macros and should be treated as volatile.  Given
>> that you're throwing an exception, registers will be clobbered anyway.
>>
>> --
>> Andrew Haley
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. <https://www.redhat.com>
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671