On Thu, 16 Dec 2021 06:33:24 GMT, Stuart Marks wrote:
> A small modification to the Launcher's help text.
LGTM
-
Marked as reviewed by sundar (Reviewer).
PR: https://git.openjdk.java.net/jdk18/pull/34
A small modification to the Launcher's help text.
-
Commit messages:
- Update launcher usage message to mention finalization default
Changes: https://git.openjdk.java.net/jdk18/pull/34/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=34&range=00
Issue: https://bugs.o
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom Cook 3 is a recursive algorithm, it is trivial to
On Thu, 16 Dec 2021 01:01:33 GMT, Paul Sandoz wrote:
>> Inside the constructor would not work, since we do not construct RecursiveOp
>> for all the tasks. However, I have incremented the parameter depth. I don't
>> like changing parameters inside methods, but since I'm doing it where it is
>>
On Thu, 16 Dec 2021 01:33:46 GMT, Paul Sandoz wrote:
> This is looking good. I will create the CSR and propose it. Since the holiday
> season is imminent it's likely no approval of the CSR will happen on until
> the new year.
Thank you so much Paul.
-
PR: https://git.openjdk.java
On Mon, 15 Nov 2021 19:31:09 GMT, Raffaello Giulietti
wrote:
>> Hello,
>>
>> here's a PR for a patch submitted on March 2020
>> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was
>> a thing.
>>
>> The patch has been edited to adhere to OpenJDK code conventions about
On Wed, 15 Dec 2021 20:18:39 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since T
On Wed, 17 Nov 2021 20:04:50 GMT, Martin Balao wrote:
>> Hi Martin,
>>
>> The change looks reasonable to me.
>> I would suggest having a CSR logged for this change due to the following
>> [behavioral
>> incompatibility](https://wiki.openjdk.java.net/display/csr/Kinds+of+Compatibility):
>> Befo
On Wed, 15 Dec 2021 14:31:26 GMT, kabutz wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 2000:
>>
>>> 1998: da1 = a2.add(a0);
>>> 1999: db1 = b2.add(b0);
>>> 2000: var vm1_task = RecursiveOp.multiply(da1.subtract(a1),
>>> db1.subtract(b1), parallel,
On Wed, 15 Dec 2021 14:40:34 GMT, kabutz wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 1909:
>>
>>> 1907: @Override
>>> 1908: public BigInteger compute() {
>>> 1909: return a.multiply(b, true, super.parallel,
>>> super.depth);
>>
>
On Wed, 15 Dec 2021 23:18:45 GMT, Jesper Wilhelmsson
wrote:
> Forwardport JDK 18 -> JDK 19
This pull request has now been integrated.
Changeset: e6b28e05
Author:Jesper Wilhelmsson
URL:
https://git.openjdk.java.net/jdk/commit/e6b28e05c6f7698f230b04199932d4fc81f41a89
Stats: 341 l
> Forwardport JDK 18 -> JDK 19
Jesper Wilhelmsson 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 53 additional commits
since the last revision:
- Me
Forwardport JDK 18 -> JDK 19
-
Commit messages:
- Merge
- 8277964: ClassCastException with no stack trace is thrown with -Xcomp in
method handle invocation
- 8272064: test/jdk/jdk/jfr/api/consumer/TestHiddenMethod.java needs update
for JEP 416
- 8278607: Misc issues in foreign A
On Wed, 15 Dec 2021 20:09:22 GMT, Roger Riggs wrote:
>> A few refactorings to how `java.util.Formatter` sets up `FormatString`s,
>> aligning the implementation with changes explored by the TemplatedStrings
>> JEP and ever so slightly improving performance:
>>
>> - turn `Flags` into an `int` (f
On Wed, 15 Dec 2021 05:59:45 GMT, Vladimir Kozlov wrote:
> A proper fix for this is to use the catchException combination. However, that
> introduces significant cold startup performance regression. JDK-8278447
> tracks the work to address the performance regression using catchException
> and
On Wed, 15 Dec 2021 17:56:23 GMT, Vladimir Kozlov wrote:
>> A proper fix for this is to use the catchException combination. However,
>> that introduces significant cold startup performance regression. JDK-8278447
>> tracks the work to address the performance regression using catchException
>>
On Tue, 14 Dec 2021 00:14:32 GMT, Claes Redestad wrote:
> A few refactorings to how `java.util.Formatter` sets up `FormatString`s,
> aligning the implementation with changes explored by the TemplatedStrings JEP
> and ever so slightly improving performance:
>
> - turn `Flags` into an `int` (few
On Wed, 15 Dec 2021 17:56:23 GMT, Vladimir Kozlov wrote:
>> A proper fix for this is to use the catchException combination. However,
>> that introduces significant cold startup performance regression. JDK-8278447
>> tracks the work to address the performance regression using catchException
>>
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom Cook 3 is a recursive algorithm, it is trivial to
On Wed, 24 Nov 2021 15:20:42 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since T
On Tue, 14 Dec 2021 00:14:32 GMT, Claes Redestad wrote:
> A few refactorings to how `java.util.Formatter` sets up `FormatString`s,
> aligning the implementation with changes explored by the TemplatedStrings JEP
> and ever so slightly improving performance:
>
> - turn `Flags` into an `int` (few
On Wed, 15 Dec 2021 17:56:23 GMT, Vladimir Kozlov wrote:
>> A proper fix for this is to use the catchException combination. However,
>> that introduces significant cold startup performance regression. JDK-8278447
>> tracks the work to address the performance regression using catchException
>>
> A proper fix for this is to use the catchException combination. However, that
> introduces significant cold startup performance regression. JDK-8278447
> tracks the work to address the performance regression using catchException
> and asSpreader combinator. It may require significant work and
On Wed, 15 Dec 2021 08:29:20 GMT, Сергей Цыпанов wrote:
>>> @AlanBateman the benchmark is mine along with the changes for
>>> `translateEscapes` and `newStringUTF8NoRepl`, the change for constructor is
>>> from SO.
>>
>> I don't know how we can progress this PR if the patch includes code copie
On Wed, 15 Dec 2021 17:19:25 GMT, Mandy Chung wrote:
>> @dholmes-ora, thank you for looking on it.
>> I discussed it with Mandy and agreed that we need to narrow down this
>> workaround as much as possible. That is why it is done only for system class
>> loaded by null loader.
>
> David has a g
On Wed, 15 Dec 2021 17:15:46 GMT, Vladimir Kozlov wrote:
>> src/hotspot/share/oops/method.cpp line 827:
>>
>>> 825: */
>>> 826: bool Method::can_omit_stack_trace() {
>>> 827: if
>>> (method_holder()->class_loader_data()->is_boot_class_loader_data()) {
>>
>> Do you actually need to check thi
On Wed, 15 Dec 2021 07:00:17 GMT, David Holmes wrote:
>> A proper fix for this is to use the catchException combination. However,
>> that introduces significant cold startup performance regression. JDK-8278447
>> tracks the work to address the performance regression using catchException
>> and
On Wed, 15 Dec 2021 05:59:45 GMT, Vladimir Kozlov wrote:
> A proper fix for this is to use the catchException combination. However, that
> introduces significant cold startup performance regression. JDK-8278447
> tracks the work to address the performance regression using catchException
> and
On Tue, 30 Nov 2021 23:18:21 GMT, Paul Sandoz wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Made forkOrInvoke() method protected to avoid strange compiler error
>
> src/java.base/share/classes/java/math/BigInteger.java
On Tue, 30 Nov 2021 23:19:37 GMT, Paul Sandoz wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Made forkOrInvoke() method protected to avoid strange compiler error
>
> src/java.base/share/classes/java/math/BigInteger.java
On Tue, 30 Nov 2021 23:45:02 GMT, Paul Sandoz wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Made forkOrInvoke() method protected to avoid strange compiler error
>
> src/java.base/share/classes/java/math/BigInteger.java
On Mon, 13 Dec 2021 21:13:20 GMT, Maurizio Cimadamore
wrote:
> This patch fixes a number of issues and typos in the foreign API javadoc
> following another internal round of reviews.
This pull request has now been integrated.
Changeset: d6b5544e
Author:Maurizio Cimadamore
URL:
htt
On Tue, 14 Dec 2021 10:24:07 GMT, Maurizio Cimadamore
wrote:
>> This patch fixes a number of issues and typos in the foreign API javadoc
>> following another internal round of reviews.
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the las
On Tue, 30 Nov 2021 23:16:20 GMT, Paul Sandoz wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Made forkOrInvoke() method protected to avoid strange compiler error
>
> src/java.base/share/classes/java/math/BigInteger.java
On Tue, 30 Nov 2021 23:10:39 GMT, Paul Sandoz wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Made forkOrInvoke() method protected to avoid strange compiler error
>
> src/java.base/share/classes/java/math/BigInteger.java
On Tue, 14 Dec 2021 13:20:46 GMT, Alan Bateman wrote:
>>> Originally this was spotted by by Amir Hadadi in
>>> https://stackoverflow.com/questions/70272651/missing-bounds-checking-elimination-in-string-constructor
>>
>> Before anyone looks at this, can you confirm that the patch does not includ
On Wed, 15 Dec 2021 05:59:45 GMT, Vladimir Kozlov wrote:
> A proper fix for this is to use the catchException combination. However, that
> introduces significant cold startup performance regression. JDK-8278447
> tracks the work to address the performance regression using catchException
> and
On Tue, 30 Nov 2021 23:03:48 GMT, Paul Sandoz wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Made forkOrInvoke() method protected to avoid strange compiler error
>
> src/java.base/share/classes/java/math/BigInteger.java
38 matches
Mail list logo
