RFR: 8312495: assert(0 <= i && i < _len) failed: illegal index after JDK-8287061 on big endian platforms [v2]
Richard Reingruber
rrich at openjdk.org
Mon Jul 24 20:24:43 UTC 2023
On Mon, 24 Jul 2023 16:49:11 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:
>
> > * differences in the handling of `Location::dbl` and `lng` in `reassign_fields_by_klass` and `reassign_type_array_elements`
>
> What difference you talking about?
`reassign_fields_by_klass` falls through to the `T_LONG` and `T_DOUBLE` case
https://github.com/openjdk/jdk/blob/8008e27c55030b397e2040bc3cf8408e47edf412/src/hotspot/share/runtime/deoptimization.cpp#L1518
where the intptr is fed as-is into a simple `long_field_put`
https://github.com/openjdk/jdk/blob/2bdfa836adbeba3319bee4ee61017907d6d84d58/src/hotspot/share/runtime/deoptimization.cpp#L1528
`reassign_type_array_elements` extracts the halfs from the intptr value and stores them separately
https://github.com/openjdk/jdk/blob/8008e27c55030b397e2040bc3cf8408e47edf412/src/hotspot/share/runtime/deoptimization.cpp#L1383-L1384
Instead of the 2 stores with the complex casts just one `long_at_put` could be done. Or is there a reason not to do that?
> > * Should the logic of `StackValueCollection::float_at` and similar be moved to `StackValue`?
>
> I think this is the case for separate RFE.
Ok.
> > * what to do with `byte_array_put`?
>
> Explain please
Well, it has very similar patterns like the locations I changed so far. I guess it is better to leave it alone for now.
> > * Should `get_jint` be implemented as a simple (jint) cast of `_integer_value` on little endian platforms?
>
> No. The code you suggest works for all case - there is no need to complicate it.
Sure.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/14976#issuecomment-1648550468
More information about the hotspot-compiler-dev
mailing list