JDK-8318446 : C2: optimize stores into primitive arrays by combining values into larger store
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 22
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2023-10-18
  • Updated: 2024-11-06
  • Resolved: 2024-04-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 23
23 b20Fixed
Related Reports
Blocks :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
[~redestad] and [~rriggs] have recently been asking if patterns like below can be improved in C2.

- Storing a sequence of byte constants:
        a[0] = 't';
        a[1] = 'r';
        a[2] = 'u';
        a[3] = 'e';
- Storing a int-value:
        a[1] = (byte)v;
        a[2] = (byte)(v >> 8 );
        a[3] = (byte)(v >> 16);
        a[4] = (byte)(v >> 24);

An alternative is to use Unsafe or "BALE":
UNSAFE.putIntUnaligned
ByteArrayLittleEndian.setInt

However, [~redestad] has pointed out that using ByteArrayLittleEndian can slow down initialization of the JVM, because of varHandle overheads. And we would like to avoid using Unsafe - or rather move away from it when possible.
Comments
Changeset: 3ccb64c0 Author: Emanuel Peter <epeter@openjdk.org> Date: 2024-04-24 06:44:14 +0000 URL: https://git.openjdk.org/jdk/commit/3ccb64c0216c72008578b904d0e7e5bba5e11134
24-04-2024

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/16245 Date: 2023-10-18 13:04:35 +0000
16-01-2024

PR Draft https://github.com/openjdk/jdk/pull/16245/files
24-10-2023

ByteArray/ByteArrayLittleEndian and Unsafe are all internal APIs, the only public API alternative is to use VarHandle and things like MethodHandles.byteArrayViewVarHandle which might be fine for more advanced use-cases, but adds quite a bit of complexity and responsibility to user code. Achieving parity on at least some simple, idiomatic patterns reduce the need to contort user code, and may also improve legacy code where users may be either unaware of the performance opportunity or unable to rewrite it to take advantage of VarHandles.
18-10-2023