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