With the reimplementation of MHP.asIFInstance, now it can easily adapt to
abstract classes as well. Repurposed PublicMethods from java.lang to track
method inheritance for MHP to reduce redundancies.
-
Commit messages:
- Merge branch 'master' into explore/mhp-samclass
- Minor spec
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 Wed, 19 Jul 2023 00:12:53 GMT, Mandy Chung wrote:
> `VarForm::getMemberName` currently throws UOE with no information if the
> requested access mode is unsupported. To provide the var handle
> information, move the access mode check to `VarHandle` so that the exception
> message can inclu
On Tue, 11 Jul 2023 17:54:23 GMT, Roger Riggs wrote:
>> In java.time packages, clarify timeline order javadoc to mention "before"
>> and "after" in the value of the `compareTo` method return values.
>> Add javadoc @see tags to isBefore and isAfter methods
>>
>> Replace use of "negative" and po
On Tue, 11 Jul 2023 17:54:23 GMT, Roger Riggs wrote:
>> In java.time packages, clarify timeline order javadoc to mention "before"
>> and "after" in the value of the `compareTo` method return values.
>> Add javadoc @see tags to isBefore and isAfter methods
>>
>> Replace use of "negative" and po
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:53:14 GMT, Mandy Chung wrote:
>> `VarForm::getMemberName` currently throws UOE with no information if the
>> requested access mode is unsupported. To provide the var handle
>> information, move the access mode check to `VarHandle` so that the exception
>> message can i
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:26:51 GMT, Jorn Vernee wrote:
>> I think this is a worthy change: see
>> https://github.com/openjdk/jdk/pull/14943/files#diff-556b309ea2df3f5bfe8229de944183ef19750ce4511d0328cd59af2ce2b61ae2R135
>> that `VarHandle.AccessMode.values()` is called every time a polymorphic VH
> `VarForm::getMemberName` currently throws UOE with no information if the
> requested access mode is unsupported. To provide the var handle
> information, move the access mode check to `VarHandle` so that the exception
> message can include the var handle information. Changes include:
>
> 1
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 15:53:10 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2010:
>>
>>> 2008: static AccessMode valueFromOrdinal(int mode) {
>>> 2009: return VALUES[mode];
>>> 2010: }
>>
>> Also, I'll throw this out there,
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, 1 Jun 2023 18:53:21 GMT, Naoto Sato wrote:
> This is to bring the JLine-based Console implementation as the default, which
> was the initial intention in
> [JDK-8295803](https://bugs.openjdk.org/browse/JDK-8295803). A corresponding
> CSR has also been drafted.
This pull request has no
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:16:33 GMT, Jorn Vernee wrote:
>> Mandy Chung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update copyright header
>
> src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2010:
>
>> 2008: st
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 Mon, 10 Jul 2023 17:07:28 GMT, Joe Darcy wrote:
>> LGTM; I assume the comment about aarch64 perf was a 10% improvement.
>
>> Here's some explanation for the recent commits I've added since @RogerRiggs
>> reviewed this PR.
>>
>> 1. Since `BigInteger.hashCode()` is unspecified, we can chan
> Please review this PR to use modern APIs and language features to simplify
> equals, hashCode, and compareTo for BigInteger. If you have any performance
> concerns, please raise them.
>
> This PR is cherry-picked from a bigger, not-yet-published PR, to test the
> waters. That latter PR will b
On Thu, 20 Jul 2023 01:04:08 GMT, Mandy Chung wrote:
>> `VarForm::getMemberName` currently throws UOE with no information if the
>> requested access mode is unsupported. To provide the var handle
>> information, move the access mode check to `VarHandle` so that the exception
>> message can i
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 01:04:08 GMT, Mandy Chung wrote:
>> `VarForm::getMemberName` currently throws UOE with no information if the
>> requested access mode is unsupported. To provide the var handle
>> information, move the access mode check to `VarHandle` so that the exception
>> message can i
I could create a PR for this if wanted.
I would suggest changing
> The size, isEmpty, get, set, iterator, and listIterator operations
run in constant time. The add operation runs in amortized constant time,
that is, adding n elements requires O(n) time. All of the other
operations run in line
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 01:11:43 GMT, Glavo wrote:
> The changes to `Arrays.hashCode(Object[])` in JDK-8312164 caused its
> performance is reduced by about 80%.
>
> This PR reverts this change.
With a size of `1`, the polymorphic version is not really polymorphic. This
seems to be about profile
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 10:50:30 GMT, Pavel Rappo wrote:
> Please review this PR to use modern APIs and language features to simplify
> equals for BitSet.
>
> I couldn't see how to refactor hashCode using Arrays utility methods in a way
> that preserves its specification. So, aside from refactori
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 Fri, 7 Jul 2023 13:45:25 GMT, Viktor Klang wrote:
>> Doug Lea has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix inverted test assert; improve internal documentation; simplify code
>
> src/java.base/share/classes/java/util/concurrent
On Wed, 19 Jul 2023 12:58:43 GMT, Matthew Donovan wrote:
> This PR removes javax/rmi/ssl/SSLSocketParametersTest.sh from the
> ProblemList. The script was removed in JDK-8298939 and the Java code
> refactored to be a jtreg test.
This pull request has now been integrated.
Changeset: 8d293291
A
On Thu, 20 Jul 2023 10:26:03 GMT, Doug Lea wrote:
>> This update addresses performance issues across both LinkedTransferQueue and
>> SynchronousQueue by creating a common basis for implementation across them
>> (mainly in LinkedTransferQueue). Pasting from internal doc summary of
>> changes:
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 Mon, 17 Jul 2023 14:45:57 GMT, Andrey Turbanov wrote:
>> Doug Lea 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 seven additional commits
>>
> This now uses Thread.isVirtual to distinguish spin vs immediate block cases,
> enabling re-introduction of spin control from the previous version, removing
> anomalies like this one.
Doug Lea has updated the pull request incrementally with one additional commit
since the last revision:
nit
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 Mon, 17 Jul 2023 20:54:25 GMT, Roger Riggs wrote:
>> 温绍锦 has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Integer/Long toString test against compact strings
>>
>> Co-authored-by: liach
>
> src/java.base/share/classes/java/lang/Lo
> javap uses proprietary com.sun.tools.classfile library to parse class files.
>
> This patch converts javap to use Classfile API.
>
> Please review.
>
> Thanks,
> Adam
Adam Sotona has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 227
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 Tue, 23 May 2023 23:16:01 GMT, Justin Lu wrote:
> Please review this PR, which addresses a case where Decimal Format would
> violate certain RoundingMode contracts given the right pattern and double.
>
> For example,
>
>
> DecimalFormat df = new DecimalFormat();
> df.setRoundingMode(Roundi
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 Wed, 19 Jul 2023 12:58:43 GMT, Matthew Donovan wrote:
> This PR removes javax/rmi/ssl/SSLSocketParametersTest.sh from the
> ProblemList. The script was removed in JDK-8298939 and the Java code
> refactored to be a jtreg test.
Looks fine to me.
-
Marked as reviewed by jpai (Rev
On Tue, 18 Jul 2023 20:06:56 GMT, Andrey Turbanov wrote:
> Found opportunity to make static `ServiceLoader.LANG_ACCESS` field `final`.
Marked as reviewed by jpai (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/14926#pullrequestreview-1538660335
58 matches
Mail list logo
