On Mon, 10 Jun 2024 03:51:40 GMT, Glavo wrote:
>> Things have changed since https://github.com/openjdk/jdk/pull/14636 was
>> closed, so let me reopen it.
>>
>> https://github.com/openjdk/jdk/pull/15386 confirmed that `VarHandle` in BALE
>> caused a startup regression. In order to not have any
On Mon, 10 Jun 2024 03:51:40 GMT, Glavo wrote:
>> Things have changed since https://github.com/openjdk/jdk/pull/14636 was
>> closed, so let me reopen it.
>>
>> https://github.com/openjdk/jdk/pull/15386 confirmed that `VarHandle` in BALE
>> caused a startup regression. In order to not have any
On Mon, 10 Jun 2024 03:51:40 GMT, Glavo wrote:
>> Things have changed since https://github.com/openjdk/jdk/pull/14636 was
>> closed, so let me reopen it.
>>
>> https://github.com/openjdk/jdk/pull/15386 confirmed that `VarHandle` in BALE
>> caused a startup regression. In order to not have any
On Mon, 10 Jun 2024 03:51:40 GMT, Glavo wrote:
>> Things have changed since https://github.com/openjdk/jdk/pull/14636 was
>> closed, so let me reopen it.
>>
>> https://github.com/openjdk/jdk/pull/15386 confirmed that `VarHandle` in BALE
>> caused a startup regression. In order to not have any
> Things have changed since https://github.com/openjdk/jdk/pull/14636 was
> closed, so let me reopen it.
>
> https://github.com/openjdk/jdk/pull/15386 confirmed that `VarHandle` in BALE
> caused a startup regression. In order to not have any more revert patches, it
> makes sense to optimize BAL
On Mon, 10 Jun 2024 02:12:11 GMT, Glavo wrote:
> Things have changed since https://github.com/openjdk/jdk/pull/14636 was
> closed, so let me reopen it.
>
> https://github.com/openjdk/jdk/pull/15386 confirmed that `VarHandle` in BALE
> caused a startup regression. In order to not have any more
> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can
> be used in many places to performance tuning.
>
> Currently they are implemented by `VarHandle`, so using them may have some
> impact on startup time.
>
> This PR reimplements them using `Unsafe`, which reduces th
On Thu, 13 Jul 2023 23:05:48 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>> Th
On Fri, 21 Jul 2023 15:14:23 GMT, Maurizio Cimadamore
wrote:
>> So have you thought of making this low-level classes public so we outside
>> users no longer need to deal with VarHandles?
> I believe this is beyond the scope of this PR.
Sure, I brought this up here but yes, it is not really th
On Fri, 21 Jul 2023 09:43:43 GMT, Uwe Schindler wrote:
>
> So have you thought of making this low-level classes public so we outside
> users no longer need to deal with VarHandles?
>
I believe this is beyond the scope of this PR.
As for what do we do in the JDK, I can see few options:
1. We
On Thu, 20 Jul 2023 21:43:49 GMT, Maurizio Cimadamore
wrote:
>>> By the way, I ran `LoopOverNonConstantHeap` on the 3700x platform, and the
>>> performance of ByteBuffer was also poor:
>>
>> I finally see it.
>>
>>
>> Benchmark (polluteProfile) Mode Cnt Score
On Thu, 20 Jul 2023 17:27:58 GMT, Maurizio Cimadamore
wrote:
> Is there any benchmark for DataInput/Output stream that can be used? I mean,
> it would be interesting to understand how these numbers translate when
> running the stuff that is built on top.
I've tried to run the benchmark in tes
On Thu, 20 Jul 2023 16:58:44 GMT, Glavo wrote:
> By the way, I ran `LoopOverNonConstantHeap` on the 3700x platform, and the
> performance of ByteBuffer was also poor:
I finally see it.
Benchmark (polluteProfile) Mode Cnt Score Error
Units
LoopOverNonConstantHe
On Thu, 20 Jul 2023 16:47:14 GMT, Maurizio Cimadamore
wrote:
>> On a newer processor/OS (Alder Lake/Ubuntu 22.04) I see a bit more
>> difference:
>>
>>
>> Benchmark Mode Cnt Score Error Units
>> ByteArray.readBytethrpt5 680397.046 ± 27504.0
On Thu, 20 Jul 2023 16:39:59 GMT, Maurizio Cimadamore
wrote:
>>> Here's with the same parameters as the one you are using:
>>
>> I don't understand why there is such a difference. I have replicated similar
>> results on several other devices:
>>
>> Apple M1:
>>
>> Benchmark
On Thu, 20 Jul 2023 16:39:31 GMT, Glavo wrote:
>> Here's with the same parameters as the one you are using:
>>
>> Benchmark Mode Cnt Score Error Units
>> ByteArray.readBytethrpt5 268722.378 ± 5979.787 ops/ms
>> ByteArray.readByteFromBuffer
On Thu, 20 Jul 2023 16:24:09 GMT, Maurizio Cimadamore
wrote:
> Here's with the same parameters as the one you are using:
I don't understand why there is such a difference. I have replicated similar
results on several other devices:
Apple M1:
Benchmark Mode CntSc
On Thu, 20 Jul 2023 16:12:12 GMT, Glavo wrote:
>> I just ran your benchmark above - which is similar as I said to the ones we
>> already have in the JDK. Results:
>>
>> Benchmark Mode Cnt Score Error Units
>> ByteArray.readByteavgt 30 3.619 ± 0.051 ns/op
On Thu, 20 Jul 2023 16:01:27 GMT, Maurizio Cimadamore
wrote:
> I don't see 2x slowdown. Which JDK are you using? Which platform?
I tried running the benchmarks with OpenJDK 20.0.1 and my own jdk built from
master and the results were similar. The test platform is based on Ubuntu
23.04, and th
On Thu, 20 Jul 2023 15:55:18 GMT, Glavo wrote:
>>> In this result, ByteBuffer is much slower than VarHandle. Am I doing
>>> something wrong? What conditions are needed to make the performance of
>>> ByteBuffer close to that of Unsafe?
>>
>> These are some benchmarks we have in the JDK:
>>
>>
On Thu, 20 Jul 2023 15:49:10 GMT, Maurizio Cimadamore
wrote:
>>> > it's likely to introduce non-trivial additional overhead
>>>
>>> What do you mean? E.g. where would the overhead come from?
>>
>> You suggested changes stored the ByteBuffer into a field. I measured
>> throughput with JMH, and
On Thu, 20 Jul 2023 15:43:01 GMT, Glavo wrote:
>>> it's likely to introduce non-trivial additional overhead
>>
>> What do you mean? E.g. where would the overhead come from?
>
>> > it's likely to introduce non-trivial additional overhead
>>
>> What do you mean? E.g. where would the overhead come
On Thu, 20 Jul 2023 15:34:33 GMT, Maurizio Cimadamore
wrote:
> > it's likely to introduce non-trivial additional overhead
>
> What do you mean? E.g. where would the overhead come from?
You suggested changes stored the ByteBuffer into a field. I measured throughput
with JMH, and it shows that
On Thu, 20 Jul 2023 15:16:36 GMT, Glavo wrote:
> it's likely to introduce non-trivial additional overhead
What do you mean? E.g. where would the overhead come from?
-
PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269643645
On Thu, 20 Jul 2023 14:53:36 GMT, Glavo wrote:
>> @mcimadamore I compared the performance of `ByteBuffer` and `VarHandle`
>> using a JMH benchmark:
>>
>>
>> public class ByteArray {
>>
>> private byte[] array;
>> private ByteBuffer byteBuffer;
>>
>> private static final VarHandle
On Thu, 20 Jul 2023 14:49:48 GMT, Glavo wrote:
>> Also, note that ByteBuffer exposes its backing array (at least if the buffer
>> is not read only) via ByteBuffer::array. This does no copy. So in all the
>> various stream implementations, I believe we can really just use a
>> ByteBuffer instea
On Thu, 20 Jul 2023 14:15:15 GMT, Maurizio Cimadamore
wrote:
>>> Also... `Integer::toString` seems to be `@IntrinsicCandidate` ?
>>
>> It's just a bytecode intrinsics, it is only replaced when used in a
>> fluent-chain of StringBuilder/Buffer.
>
> Also, note that ByteBuffer exposes its backing
On Thu, 20 Jul 2023 13:57:04 GMT, Glavo wrote:
>> Also... `Integer::toString` seems to be `@IntrinsicCandidate` ?
>
>> Also... `Integer::toString` seems to be `@IntrinsicCandidate` ?
>
> It's just a bytecode intrinsics, it is only replaced when used in a
> fluent-chain of StringBuilder/Buffer.
On Thu, 13 Jul 2023 23:05:48 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>> Th
On Thu, 20 Jul 2023 13:46:10 GMT, Maurizio Cimadamore
wrote:
> Also... `Integer::toString` seems to be `@IntrinsicCandidate` ?
It's just a bytecode intrinsics, it is only replaced when used in a
fluent-chain of StringBuilder/Buffer.
-
PR Review Comment: https://git.openjdk.org/jd
On Thu, 13 Jul 2023 23:05:48 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>> Th
On Thu, 20 Jul 2023 13:38:14 GMT, Maurizio Cimadamore
wrote:
>>> The Unsafe-based writing will be used by `Integer.toString` and
>>> `Long.toString` as well; in those cases, will creating a ByteBuffer wrapper
>>> be overkill?
>>
>> Integer/Long are very core classes so I assume they can use U
On Thu, 20 Jul 2023 13:34:25 GMT, Alan Bateman wrote:
> in those cases, will creating a ByteBuffer wrapper be overkill?
Perhaps - but do we have any benchmark to back up that claim (or backing up the
fact that Integer.toString would benefit from using ByteArray in the first
place) ? It is like
On Thu, 20 Jul 2023 10:29:25 GMT, Chen Liang wrote:
> The Unsafe-based writing will be used by `Integer.toString` and
> `Long.toString` as well; in those cases, will creating a ByteBuffer wrapper
> be overkill?
Integer/Long are very core classes so I assume they can use Unsafe if needed,
they
On Thu, 20 Jul 2023 09:39:09 GMT, Maurizio Cimadamore
wrote:
>> Actually, a byte buffer is big endian, so some extra code would be required.
>> But maybe that's another helper function:
>>
>>
>> @ForceInline
>> ByteBuffer asBuffer(byte[] array) { return
>> ByteBuffer.wrap(array).order(ByteOr
On Thu, 20 Jul 2023 09:51:49 GMT, Maurizio Cimadamore
wrote:
> Is `BufWriterImpl` what you are looking to refactor using this class? Any
> reason why that implementation doesn't internally rely on a ByteBuffer,
> rather than a plain array?
Good point. Not only that, `ClassReaderImpl` should b
On Sat, 24 Jun 2023 09:02:59 GMT, Chen Liang wrote:
> The reimplementation allows parts that invoke package depend on to utilize
> faster byte array access, namely bytecode generation and Classfile API; which
> IMO is more important than the reduction on startup time.
Is `BufWriterImpl` what y
On Thu, 20 Jul 2023 09:33:15 GMT, Maurizio Cimadamore
wrote:
>> src/java.base/share/classes/jdk/internal/util/ByteArray.java line 54:
>>
>>> 52:
>>> 53: @ForceInline
>>> 54: static long arrayOffset(byte[] array, int typeBytes, int offset) {
>>
>> IMHO, this is the really interesting t
On Thu, 20 Jul 2023 09:25:31 GMT, Maurizio Cimadamore
wrote:
>> Glavo has updated the pull request with a new target base due to a merge or
>> a rebase. The incremental webrev excludes the unrelated changes brought in
>> by the merge/rebase. The pull request contains 15 additional commits sinc
On Thu, 13 Jul 2023 23:05:48 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>> Th
On Thu, 13 Jul 2023 23:05:48 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>> Th
On Thu, 13 Jul 2023 23:05:48 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>> Th
On Thu, 13 Jul 2023 23:05:48 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>> Th
On Thu, 13 Jul 2023 23:05:48 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>> Th
On Thu, 13 Jul 2023 23:05:48 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>> Th
On Thu, 13 Jul 2023 23:05:48 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>> Th
> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can
> be used in many places to performance tuning.
>
> Currently they are implemented by `VarHandle`, so using them may have some
> impact on startup time.
>
> This PR reimplements them using `Unsafe`, which reduces th
On Tue, 27 Jun 2023 20:29:36 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>> Th
On Thu, 29 Jun 2023 07:59:42 GMT, Glavo wrote:
> I understand the original reason for retaining it before, but this discussion
> is outdated for this PR.
>
> `Unsafe` does not provide `getFloatUnaligned`/`getDoubleUnaligned` and
> `putFloatUnaligned`/`putDoubleUnaligned`, so we must convert fl
On Thu, 29 Jun 2023 07:41:29 GMT, Alan Bateman wrote:
> You'll need to go back through the discussion in the original PRs (there was
> more than one) as there was lengthy discussion this already.
https://github.com/openjdk/jdk/pull/11840#discussion_r1064489163
Are you referring to this discuss
On Thu, 29 Jun 2023 07:42:21 GMT, Alan Bateman wrote:
> What issue are you running into at startup that require this change?
I wish to use this too before java.lang.invoke is ready, such as reading
unaligned in the Classfile API.
-
PR Comment: https://git.openjdk.org/jdk/pull/1463
On Wed, 28 Jun 2023 19:32:44 GMT, Glavo wrote:
> Can someone review this PR?
What issue are you running into at startup that require this change?
-
PR Comment: https://git.openjdk.org/jdk/pull/14636#issuecomment-1612568927
On Mon, 26 Jun 2023 07:09:11 GMT, Glavo wrote:
> I deleted some incorrect comments.
>
> The original author of these two classes misunderstood the behavior of
> `intBitsToFloat` and `longBitsToDouble`. These two methods never collapse NaN
> values to a "canonical" NaN value, so the comments is
On Tue, 27 Jun 2023 20:29:36 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>> Th
On Tue, 27 Jun 2023 20:29:36 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>> Th
> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can
> be used in many places to performance tuning.
>
> Currently they are implemented by `VarHandle`, so using them may have some
> impact on startup time.
>
> This PR reimplements them using `Unsafe`, which reduces th
> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can
> be used in many places to performance tuning.
>
> Currently they are implemented by `VarHandle`, so using them may have some
> impact on startup time.
>
> This PR reimplements them using `Unsafe`, which reduces th
> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can
> be used in many places to performance tuning.
>
> Currently they are implemented by `VarHandle`, so using them may have some
> impact on startup time.
>
> This PR reimplements them using `Unsafe`, which reduces th
On Mon, 26 Jun 2023 07:03:22 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>> Th
> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can
> be used in many places to performance tuning.
>
> Currently they are implemented by `VarHandle`, so using them may have some
> impact on startup time.
>
> This PR reimplements them using `Unsafe`, which reduces th
> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can
> be used in many places to performance tuning.
>
> Currently they are implemented by `VarHandle`, so using them may have some
> impact on startup time.
>
> This PR reimplements them using `Unsafe`, which reduces th
> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can
> be used in many places to performance tuning.
>
> Currently they are implemented by `VarHandle`, so using them may have some
> impact on startup time.
>
> This PR reimplements them using `Unsafe`, which reduces th
On Sat, 24 Jun 2023 09:16:38 GMT, Chen Liang wrote:
> Do the Unsafe methods throw NPE on null array argument?
No, but `arrayOffset` will throw.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1240681104
> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can
> be used in many places to performance tuning.
>
> Currently they are implemented by `VarHandle`, so using them may have some
> impact on startup time.
>
> This PR reimplements them using `Unsafe`, which reduces th
> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can
> be used in many places to performance tuning.
>
> Currently they are implemented by `VarHandle`, so using them may have some
> impact on startup time.
>
> This PR reimplements them using `Unsafe`, which reduces th
On Sat, 24 Jun 2023 06:42:18 GMT, Glavo wrote:
> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can
> be used in many places to performance tuning.
>
> Currently they are implemented by `VarHandle`, so using them may have some
> impact on startup time.
>
> This PR r
On Sat, 24 Jun 2023 06:42:18 GMT, Glavo wrote:
> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can
> be used in many places to performance tuning.
>
> Currently they are implemented by `VarHandle`, so using them may have some
> impact on startup time.
>
> This PR r
On Sat, 24 Jun 2023 06:42:18 GMT, Glavo wrote:
> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can
> be used in many places to performance tuning.
>
> Currently they are implemented by `VarHandle`, so using them may have some
> impact on startup time.
>
> This PR r
68 matches
Mail list logo
