8310843: Reimplement ByteArray and ByteArrayLittleEndian with Unsafe

[Glavo]

Things have changed since #14636 was closed, so let me reopen it.

#15386 confirmed that VarHandle in BALE caused a startup regression. In order to not have any more revert patches, it makes sense to optimize BALE.

The optimization of #16245 allows the traditional expression to have good performance, but BA and BALE save us from having to copy these lengthy expressions everywhere. So it makes sense to keep them.

Now here's the question, should I rewrite this PR without Unsafe? I'll do some research (e.g. does Unsafe have better performance during warmup?), but I'd also like to take some advice.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8310843: Reimplement ByteArray and ByteArrayLittleEndian with Unsafe (Enhancement - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/19616/head:pull/19616
$ git checkout pull/19616

Update a local copy of the PR:
$ git checkout pull/19616
$ git pull https://git.openjdk.org/jdk.git pull/19616/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 19616

View PR using the GUI difftool:
$ git pr show -t 19616

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/19616.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back Glavo! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@Glavo The following label will be automatically applied to this pull request:

• core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 01: Full - Incremental (332bb270)
• 00: Full (b3920c86)

[liach]

No matter if we use unsafe or not, keeping multi-byte write and read operations all to one class so we can update them altogether sounds like a good idea. The only risk is that some operations will happen in early startup, such as ClassFile processing, which prohibits some implementations like VarHandle.

Also feel free to choose another title for this patch, I will update the JBS issue for you.

[minborg]

Would it be possible to add a benchmark for some of the methods here so we can see if there is a difference? Also, it would be interesting to see if startup performance is impacted.

[wenshao]

#16245 combining values ​​into larger store, Instead of using Unsafe, can we implement it as follows, similar to the early versions of java.nio.Bits?

class ByteArrayLittleEndian {
    // ...
    public static void setInt(byte[] array, int offset, int value) {
        array[offset    ] = (byte)  value;
        array[offset + 1] = (byte) (value >> 8);
        array[offset + 2] = (byte) (value >> 16);
        array[offset + 3] = (byte) (value >> 24);
    }

	public static void setLong(byte[] bytes, int off, long value) {
        array[offset]     = (byte)  value;
        array[offset + 1] = (byte) (value >> 8);
        array[offset + 2] = (byte) (value >> 16);
        array[offset + 3] = (byte) (value >> 24);
        array[offset + 4] = (byte) (value >> 32);
        array[offset + 5] = (byte) (value >> 40);
        array[offset + 6] = (byte) (value >> 48);
        array[offset + 7] = (byte) (value >> 56);
    }
    // ...
}

[wenshao]

I submitted a PR #19734 with a set of performance benchmarks for Batch operations that should provide performance numbers that you can use to improve ByteArray and ByteArrayLittleEndian.

[bridgekeeper]

@Glavo This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[bridgekeeper]

@Glavo This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.

[liach]

With merge stores, you can probably reimplement these two classes with direct array writes instead of Unsafe, for ease of maintenance.

[Glavo]

/open

[openjdk]

@Glavo This pull request is now open

[bridgekeeper]

@Glavo This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[bridgekeeper]

@Glavo This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.