> This is a follow-up to PR #20273, which improves performance when the number
> of parameters exceeds 20.
>
> When the number of parameters is large, the possibility of reuse will be
> lower, so we can use the static concat method and write the length and coder
> directly into the bytecode to
On Fri, 6 Sep 2024 19:33:09 GMT, Shaojin Wen wrote:
>> This is a follow-up to PR #20273, which improves performance when the number
>> of parameters exceeds 20.
>>
>> When the number of parameters is large, the possibility of reuse will be
>> lower, so we can use the static concat method and w
Hi Arhice,
First of all, I want to apologize if I may not have explained things clearly
since English is not my first language. I’m really sorry about that.
Even so, I deeply appreciate your response and taking the time to reply.
First, I would like to confirm whether my understanding is
> This implementation of MutableBigInteger.leftShift(int) optimizes the current
> version, avoiding unnecessary copy of the MutableBigInteger's value content
> and performing the primitive shifting only in the original portion of the
> value array rather than in the value yet extended with trail
September 2, 2024 at 10:36 AM, "Viktor Klang" wrote:
>
> Hi Anthony,
Hi Viktor
> Thank you for your patience, I needed some time to experiment and think about
> your feedback.
>
> >* how realistic is it for type inference to be improved to the point that
> >usage of the Gatherers API wouldn'
Hi Kim,
On Sat, Sep 7, 2024 at 10:36 AM 김민주 wrote:
> Here's a clearer outline of the scenario:
>
>- Threads T1 to T10 are waiting on Condition::await() because the
>queue is full.
>- T11 calls take() and holds the lock via lock.lockInterruptibly().
>- T12 calls queue.put() and en
Hi Viktor,
I hope you're doing well. I apologize for reaching out again so soon, but after
further reflection, I realized that my previous explanation regarding the issue
might have been inaccurate.
In my earlier email, I mentioned that the problem was related to count and
signal, but it seems
On Sat, 7 Sep 2024 14:04:55 GMT, ExE Boss wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> reduce JDKUTF#utflen codeSize
>
> src/java.base/share/classes/java/io/DataOutputStream.java line 382:
>
>> 380: Byte
On Sat, 7 Sep 2024 08:51:25 GMT, Shaojin Wen wrote:
>> PR #20772 introduced an optimization for writeUTF, which can also be used in
>> DataOutputStream::writeUTF.
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since the last revision:
>
> reduce JDKUT
On Fri, 6 Sep 2024 16:28:36 GMT, Aleksei Efimov wrote:
> This PR proposes the following changes to address wrong timeout computations
> in the `com.sun.jndi.dns.DnsClient`:
> - The `DnsClient` has been updated to use a monotonic high-resolution (nano)
> clock. The existing `Timeout` test has al
On Fri, 6 Sep 2024 17:51:15 GMT, Jorn Vernee wrote:
>> As discussed in the JBS issue:
>>
>> FFM upcall stubs embed a `Method*` of the target method in the stub. This
>> `Method*` is read from the `LambdaForm::vmentry` field associated with the
>> target method handle at the time when the upcal
> PR #20772 introduced an optimization for writeUTF, which can also be used in
> DataOutputStream::writeUTF.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
reduce JDKUTF#utflen codeSize
-
Changes:
- all: https://git.o
> PR #20772 introduced an optimization for writeUTF, which can also be used in
> DataOutputStream::writeUTF.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
code style
-
Changes:
- all: https://git.openjdk.org/jdk/pull
PR #20772 introduced an optimization for writeUTF, which can also be used in
DataOutputStream::writeUTF.
-
Commit messages:
- extract to JDKUTF
- code style
- optimize ObjectOutputStream#writeUTF
- optimize DataOutputStream#writeUTF
- add benchmark
Changes: https://git.openjdk.
On Fri, 6 Sep 2024 09:58:58 GMT, Shaojin Wen wrote:
> PR #20772 introduced an optimization for writeUTF, which can also be used in
> DataOutputStream::writeUTF.
Below are the performance numbers running on a MacBook M1 Pro. Both
DataOutputStreamBench::writeUTF and ObjectOutputStream::writeUTF
15 matches
Mail list logo
