On Tue, 16 Nov 2021 21:09:08 GMT, Naoto Sato wrote:
>> Fixing the default charset for PrintWriter/OutputStreamWriter that wraps a
>> PrintStream to its charset. This issue was raised during the conversations
>> in https://github.com/openjdk/jdk/pull/5771
>> A corresponding CSR has also been
On Fri, 5 Nov 2021 13:52:49 GMT, Jaikiran Pai wrote:
>> The commit here is a potential fix for the issue noted in
>> https://bugs.openjdk.java.net/browse/JDK-8258117.
>>
>> The change here repurposes an existing internal interface `ModuleInfoEntry`
>> to keep track of the last modified
On Mon, 15 Nov 2021 19:56:28 GMT, Andy Herrick wrote:
> JDKJDK-8276150: Quarantined jpackage apps are labeled as "damaged"
Looks good. Just fix pull request title.
-
Marked as reviewed by almatvee (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/6396
On Tue, 16 Nov 2021 21:09:08 GMT, Naoto Sato wrote:
>> Fixing the default charset for PrintWriter/OutputStreamWriter that wraps a
>> PrintStream to its charset. This issue was raised during the conversations
>> in https://github.com/openjdk/jdk/pull/5771
>> A corresponding CSR has also been
On Tue, 16 Nov 2021 13:22:46 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 Toom
On Fri, 5 Nov 2021 13:52:49 GMT, Jaikiran Pai wrote:
>> The commit here is a potential fix for the issue noted in
>> https://bugs.openjdk.java.net/browse/JDK-8258117.
>>
>> The change here repurposes an existing internal interface `ModuleInfoEntry`
>> to keep track of the last modified
On Tue, 16 Nov 2021 20:45:05 GMT, Simon Roberts
wrote:
> Is there not also an architectural consideration here? I'm inclined to think
> that just because execution in parallel finishes in less wall time does not
> mean that's the right thing to do. Those CPUs will be unavailable for other
>
On Tue, 16 Nov 2021 20:10:53 GMT, Alan Bateman wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Made PrintStream::charset() public, charset field final, and refined
>> wordings.
>
>
> Fixing the default charset for PrintWriter/OutputStreamWriter that wraps a
> PrintStream to its charset. This issue was raised during the conversations in
> https://github.com/openjdk/jdk/pull/5771
> A corresponding CSR has also been drafted:
> https://bugs.openjdk.java.net/browse/JDK-8277078
On Tue, 9 Nov 2021 15:48:22 GMT, Roger Riggs wrote:
> When set on the command line `jdk.serialFilter` to an invalid value, the
> invalid value is logged but the application is allowed to start without
> setting the filter.
> This leaves the application without the protections of the serial
> This is a draft proposal for how we could improve stream performance for the
> case where the streams are empty. Empty collections are common-place. If we
> iterate over them with an Iterator, we would have to create one small
> Iterator object (which could often be eliminated) and if it is
On Fri, 5 Nov 2021 12:53:46 GMT, kabutz wrote:
> This is a draft proposal for how we could improve stream performance for the
> case where the streams are empty. Empty collections are common-place. If we
> iterate over them with an Iterator, we would have to create one small
> Iterator object
Is there not also an architectural consideration here? I'm inclined to
think that just because execution in parallel finishes in less wall time
does not mean that's the right thing to do. Those CPUs will be unavailable
for other work, and in any multi-user/client type system, that effectively
On Tue, 16 Nov 2021 19:59:49 GMT, Joe Darcy wrote:
> As you cite, there are a few other cases in the JDK API were a second
> "parallelFoo" method is exposed. However, I don't think those precedents
> would necessarily mandate a parallelMultiply method in BigInteger. Without a
> separate
On Tue, 16 Nov 2021 18:08:08 GMT, Naoto Sato wrote:
>> Fixing the default charset for PrintWriter/OutputStreamWriter that wraps a
>> PrintStream to its charset. This issue was raised during the conversations
>> in https://github.com/openjdk/jdk/pull/5771
>> A corresponding CSR has also been
Hello,
as mentioned in [1], the Schubfach writing accompanying JBS issues [2]
and [3] has recently undergone a thorough review by renowned researchers
(in addition to Dmitry Nadezhin back in 2018-19 and myself on a
continuous basis) [4].
For the *code* reviewers of PR [5] this means that
On Tue, 16 Nov 2021 18:52:20 GMT, kabutz wrote:
>
>
> > It isn't clear to me that parallelMultiply should be a public method as
> > opposed to an implementation detail.
>
> Hi Joe, thanks for responding. I would have preferred for it to be an
> implementation detail, but I thought it best
Hi Alan,
Thanks. I appreciate your response.
Yes, I think GB13080 must continue to be GB13080-2000 for now. I was initially
hoping to add a new character set with the name GB13080-2005. But I guess your
suggestion of internally mapping one of the two versions (2000 or 2005) to
"GB13080",
On Tue, 16 Nov 2021 18:42:42 GMT, Joe Darcy wrote:
> It isn't clear to me that parallelMultiply should be a public method as
> opposed to an implementation detail.
Hi Joe, thanks for responding. I would have preferred for it to be an
implementation detail, but I thought it best to keep things
On Tue, 16 Nov 2021 18:08:08 GMT, Naoto Sato wrote:
>> Fixing the default charset for PrintWriter/OutputStreamWriter that wraps a
>> PrintStream to its charset. This issue was raised during the conversations
>> in https://github.com/openjdk/jdk/pull/5771
>> A corresponding CSR has also been
On Tue, 16 Nov 2021 13:22:46 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 Toom
> Fixing the default charset for PrintWriter/OutputStreamWriter that wraps a
> PrintStream to its charset. This issue was raised during the conversations in
> https://github.com/openjdk/jdk/pull/5771
> A corresponding CSR has also been drafted:
> https://bugs.openjdk.java.net/browse/JDK-8277078
On Tue, 16 Nov 2021 17:27:21 GMT, Naoto Sato wrote:
> Also I am tempted to make `PrintStream::charset()` public, as some custom
> `OutputStreamWriter` implementations would also need the charset information.
I think that would be good addition.
-
PR:
On Tue, 16 Nov 2021 05:25:33 GMT, Jaikiran Pai wrote:
>> Fixing the default charset for PrintWriter/OutputStreamWriter that wraps a
>> PrintStream to its charset. This issue was raised during the conversations
>> in https://github.com/openjdk/jdk/pull/5771
>> A corresponding CSR has also been
On Tue, 16 Nov 2021 12:21:20 GMT, Alan Bateman wrote:
>> Fixing the default charset for PrintWriter/OutputStreamWriter that wraps a
>> PrintStream to its charset. This issue was raised during the conversations
>> in https://github.com/openjdk/jdk/pull/5771
>> A corresponding CSR has also been
On Tue, 16 Nov 2021 10:37:12 GMT, Ichiroh Takiguchi
wrote:
> I tested some of java tool commands on #5771 .
>
> > jar.exe, javac.exe, javadoc.exe, javap.exe, jdeps.exe, jlink.exe, jmod.exe,
> > jpackage.exe
>
> It worked fine as expected on CentOS7 (ja_JP.eucjp locale) and Windows 10 Pro
>
On Tue, 16 Nov 2021 05:24:38 GMT, Vicente Romero wrote:
> Please review this PR which aims to optimize the implementation of the
> `toString` method we provide for records. A benchmark comparing the
> implementation we are providing for records with lombok found out that lombok
> is much
On Tue, 16 Nov 2021 05:24:38 GMT, Vicente Romero wrote:
> Please review this PR which aims to optimize the implementation of the
> `toString` method we provide for records. A benchmark comparing the
> implementation we are providing for records with lombok found out that lombok
> is much
On Tue, 16 Nov 2021 05:24:38 GMT, Vicente Romero wrote:
> Please review this PR which aims to optimize the implementation of the
> `toString` method we provide for records. A benchmark comparing the
> implementation we are providing for records with lombok found out that lombok
> is much
On Mon, 15 Nov 2021 18:47:34 GMT, Andrew Leonard wrote:
> Both jar and jmod utilise java.io file operations whose methods define no
> ordering of the return file lists, and in fact rely on OS query file
> ordering, which can differ by underlying OS architecture.
> This PR adds sort processing
JDKJDK-8276150: Quarantined jpackage apps are labeled as "damaged"
-
Commit messages:
- JDKJDK-8276150: Quarantined jpackage apps are labeled as "damaged"
Changes: https://git.openjdk.java.net/jdk/pull/6396/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6396=00
On Tue, 16 Nov 2021 13:03:35 GMT, Jim Laskey wrote:
>> (I'm not reviewer.)
>>
>> I think `.toArray(Class[]::new)` should be better here. `.toList` seems
>> unnecessary.
>
> Class[] types = Stream.of(getters)
> .map(g -> g.type().returnType())
>
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 Tue, 16 Nov 2021 12:48:03 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
On Tue, 16 Nov 2021 12:48:03 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
On Mon, 15 Nov 2021 15:50: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 Toom
On Tue, 16 Nov 2021 10:36:46 GMT, Glavo wrote:
>> src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 264:
>>
>>> 262: .map(g -> g.type().returnType())
>>> 263: .toList()
>>> 264: .toArray(new Class[getters.length]);
>>
>> Why
On Tue, 16 Nov 2021 12:48:03 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
Good afternoon,
BigInteger was changed in Java 8 to have faster multiply algorithms for
large numbers (in the thousands of bits). Since the algorithm uses
recursive decomposition (Toom Cook 3) it is fairly easy to parallelize.
I would like to propose that we add a parallelMultiply() method to
> 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
> 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 Mon, 15 Nov 2021 15:50: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 Toom
> 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 Mon, 15 Nov 2021 15:50: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 Toom
On Mon, 15 Nov 2021 22:43:37 GMT, Naoto Sato wrote:
> Fixing the default charset for PrintWriter/OutputStreamWriter that wraps a
> PrintStream to its charset. This issue was raised during the conversations in
> https://github.com/openjdk/jdk/pull/5771
> A corresponding CSR has also been
On Mon, 15 Nov 2021 12:58:45 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> noted in https://bugs.openjdk.java.net/browse/JDK-8227020?
>
> The linked issue talks about non-normalized paths contributing to the leak.
> However, the root
On Mon, 15 Nov 2021 15:50: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 Toom
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 Mon, 15 Nov 2021 22:43:37 GMT, Naoto Sato wrote:
> Fixing the default charset for PrintWriter/OutputStreamWriter that wraps a
> PrintStream to its charset. This issue was raised during the conversations in
> https://github.com/openjdk/jdk/pull/5771
> A corresponding CSR has also been
On Tue, 16 Nov 2021 09:45:56 GMT, Сергей Цыпанов wrote:
>> Please review this PR which aims to optimize the implementation of the
>> `toString` method we provide for records. A benchmark comparing the
>> implementation we are providing for records with lombok found out that
>> lombok is much
On 15/11/2021 17:53, Pushkar N Kulkarni wrote:
Hi there,
OpenJDK currently supports version 2000 of the GB18030
(https://en.wikipedia.org/wiki/GB_18030) character set viz. GB18030-2000. The
character mappings corresponding to Unicode codepoints '\u1E3F' and '\uE7C7'
were swapped in a new
On Tue, 16 Nov 2021 05:24:38 GMT, Vicente Romero wrote:
> Please review this PR which aims to optimize the implementation of the
> `toString` method we provide for records. A benchmark comparing the
> implementation we are providing for records with lombok found out that lombok
> is much
52 matches
Mail list logo
