On 27/07/2024 21:24, Сергей Цыпанов wrote:
Hello,
I've run into a concurrency issue manifested in application becoming frozen due to pinned virtual threads.
Can you bring it to loom-dev as this looks like another case where all
carriers are pinned, there is a mix of object monitors and
j
On Tue, 2 Jul 2024 12:20:17 GMT, Yasumasa Suenaga wrote:
> We cannot pass GNU style options like `--enable-preview` to `jlink
> --add-option`. It is hard to use for complex application.
>
> We have workaround for this issue (see JBS), but I think it is better to fix
> on JDK side.
So how shou
On Fri, 26 Jul 2024 13:17:11 GMT, Chen Liang wrote:
>> src/java.base/share/classes/jdk/internal/classfile/impl/BufferedCodeBuilder.java
>> line 67:
>>
>>> 65: this.maxLocals = Util.maxLocals(methodInfo.methodFlags(),
>>> methodInfo.methodTypeSymbol());
>>> 66: if (original != n
> As discussed in offline meeting, the max stack and locals information are
> part of the code attribute and not meaningful for buffered code elements.
> Computation would be costly and these see no real usage during
> transformations. Thus, the proposed solution is to move these APIs to be
> C
On Fri, 26 Jul 2024 00:00:49 GMT, Shaojin Wen wrote:
> 8337245: Fix wrong comment of StringConcatHelper
This pull request has now been integrated.
Changeset: 2fbdbaca
Author:Shaojin Wen
Committer: Claes Redestad
URL:
https://git.openjdk.org/jdk/commit/2fbdbacad7ad45055a482c764f84da
On Fri, 26 Jul 2024 00:00:49 GMT, Shaojin Wen wrote:
> 8337245: Fix wrong comment of StringConcatHelper
Marked as reviewed by redestad (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/20344#pullrequestreview-2203242433
On Fri, 26 Jul 2024 15:56:14 GMT, Shaojin Wen wrote:
> StringConcatFactory improves startup speed and running performance through
> simpleConcat, but simpleConcat is currently given priority and only supports
> the following scenarios:
>
> // x instanceof Object
> prefix + x
> x = subfix
>
>
On Fri, 26 Jul 2024 00:00:49 GMT, Shaojin Wen wrote:
> 8337245: Fix wrong comment of StringConcatHelper
@wenshao
Your change (at version d453e6c2837cf7d8802f7fea624324361e085edf) is now ready
to be sponsored by a Committer.
-
PR Comment: https://git.openjdk.org/jdk/pull/20344#iss
> I have implemented the Zimmermann's square root algorithm, available in works
> [here](https://inria.hal.science/inria-00072854/en/) and
> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>
> The algorithm is proved to be asymptotically faster than the New
On Sat, 27 Jul 2024 14:44:15 GMT, fabioromano1 wrote:
>> I have implemented the Zimmermann's square root algorithm, available in
>> works [here](https://inria.hal.science/inria-00072854/en/) and
>> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>>
>> The
Hello,
I've run into a concurrency issue manifested in application becoming frozen due
to pinned virtual threads.
Here I've described the reproduction steps in details:
https://stackoverflow.com/questions/78790376/spring-boot-application-gets-stuck-when-virtual-threads-are-used-on-java-21
T
Hello, I've run into a concurrency issue manifested in application becoming frozen due to pinned virtual threads. Here I've described the reproduction steps in details: https://stackoverflow.com/questions/78790376/spring-boot-application-gets-stuck-when-virtual-threads-are-used-on-java-21 The probl
On Fri, 26 Jul 2024 18:03:18 GMT, Roger Riggs wrote:
> > Could you please review [these](https://github.com/openjdk/jdk/pull/11986)
> > proposed changes for instantiation of `Instant` values with already
> > normalized nanos?
>
> @plokhotnyuk Your contribution cannot be acted upon until the OC
On Sat, 27 Jul 2024 14:55:04 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Correct test method name
>> - Updated sqrt speed test benchmark
>
> On my M1 Pro/32 GiB
>
> Current
>
> Be
> `GZIPInputStream` supports reading data from multiple concatenated GZIP data
> streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In
> order to do this, after a GZIP trailer frame is read, it attempts to read a
> GZIP header frame and, if successful, proceeds onward to d
On Sat, 27 Jul 2024 14:44:15 GMT, fabioromano1 wrote:
>> I have implemented the Zimmermann's square root algorithm, available in
>> works [here](https://inria.hal.science/inria-00072854/en/) and
>> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>>
>> The
> I have implemented the Zimmermann's square root algorithm, available in works
> [here](https://inria.hal.science/inria-00072854/en/) and
> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>
> The algorithm is proved to be asymptotically faster than the New
On Sat, 27 Jul 2024 13:46:14 GMT, Raffaello Giulietti
wrote:
>> The benchmark `BigIntegers.java`, on which I based this, has the same
>> problem.
>
> It wasn't the overflow by itself that worried me, but that a later invocation
> of `sqrt*()` could throw.
>
> Again, the "huge" numbers are les
On Sat, 27 Jul 2024 12:18:19 GMT, fabioromano1 wrote:
>> test/micro/org/openjdk/bench/java/math/BigIntegerSquareRoot.java line 74:
>>
>>> 72:
>>> 73: for (int i = 0; i < TESTSIZE; i++) {
>>> 74: int value = Math.abs(r.nextInt());
>>
>> There's a risk of an overflow here if
> We need a String format solution with good performance. String Template was
> once expected, but it has been removed. j.u.Formatter is powerful, but its
> performance is not good enough.
>
> This PR implements a subset of j.u.Formatter capabilities. The performance is
> good enough that it is
> String.format is widely used, and improving its performance is very
> meaningful. This PR can significantly improve the performance of
> String.format. Sorry, there are many changes, which will take a lot of time.
> I hope you can review it patiently.
>
>
> Improved performance includes the
> I have implemented the Zimmermann's square root algorithm, available in works
> [here](https://inria.hal.science/inria-00072854/en/) and
> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>
> The algorithm is proved to be asymptotically faster than the New
> I have implemented the Zimmermann's square root algorithm, available in works
> [here](https://inria.hal.science/inria-00072854/en/) and
> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>
> The algorithm is proved to be asymptotically faster than the New
On Sat, 27 Jul 2024 11:47:23 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> More accurate condition for MBI.safeRightShift()
>
> test/micro/org/openjdk/bench/java/math/BigIntegerSquareRoo
On Sat, 27 Jul 2024 09:40:54 GMT, fabioromano1 wrote:
>> I have implemented the Zimmermann's square root algorithm, available in
>> works [here](https://inria.hal.science/inria-00072854/en/) and
>> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>>
>> The
> StringConcatFactory improves startup speed and running performance through
> simpleConcat, but simpleConcat is currently given priority and only supports
> the following scenarios:
>
> // x instanceof Object
> prefix + x
> x = subfix
>
> // x instanceof Object && z instanceof Object
> x + y
>
> I have implemented the Zimmermann's square root algorithm, available in works
> [here](https://inria.hal.science/inria-00072854/en/) and
> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>
> The algorithm is proved to be asymptotically faster than the New
27 matches
Mail list logo
