> Dear all,
> Can you do me a favor to review this patch. This patch use `ldp` to
> implement String.compareTo.
>
> * We add a JMH test case
> * Here is the result of this test case
>
> Benchmark|(size)| Mode| Cnt|Score | Error |Units
>
On Wed, 14 Jul 2021 08:27:36 GMT, Nick Gasson wrote:
>> Wang Huang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> refact codes
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4990:
>
>> 4988: __ lsrv(tmp2, tmp2,
On Tue, 8 Jun 2021 13:37:10 GMT, Thomas Stuefe wrote:
>> Henry Jen 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
>>
On Wed, 14 Jul 2021 16:50:39 GMT, Andy Herrick wrote:
>> JDK-8269387: jpackage --add-launcher should have option to not create
>> shortcuts for additional launchers
>
> Andy Herrick has updated the pull request incrementally with one additional
> commit since the last revision:
>
>
On Wed, 14 Jul 2021 21:35:34 GMT, Jesper Wilhelmsson
wrote:
> Forwardport JDK 17 -> JDK 18
This pull request has now been integrated.
Changeset: 7d0edb57
Author:Jesper Wilhelmsson
URL:
https://git.openjdk.java.net/jdk/commit/7d0edb5743aacfc22f76ee8aa7b03d7dc0f90dca
Stats: 328
On Wed, 14 Jul 2021 16:50:39 GMT, Andy Herrick wrote:
>> JDK-8269387: jpackage --add-launcher should have option to not create
>> shortcuts for additional launchers
>
> Andy Herrick has updated the pull request incrementally with one additional
> commit since the last revision:
>
>
On Wed, 14 Jul 2021 20:52:54 GMT, Naoto Sato wrote:
>> src/java.base/share/classes/java/io/Console.java line 587:
>>
>>> 585: try {
>>> 586: cs = Charset.forName(csname);
>>> 587: } catch (Exception ignored) { }
>>
>> A separate
On Wed, 14 Jul 2021 21:03:53 GMT, Roger Riggs wrote:
>> That was intentional. Only those two are supported, others continue to work
>> as before (but not supported).
>
> Still it leaves an uncomfortable feeling, perhaps remedied by an "other
> values have unspecified behavior"
> or the "other
> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of
> the changes is `Charset.defaultCharset()` returning `UTF-8` and
> `file.encoding` system property being added in the spec, but another notable
> modification is in `java.io.PrintStream` where it continues to use the
Forwardport JDK 17 -> JDK 18
-
Commit messages:
- Merge
- 8270422: Test build/AbsPathsInImage.java fails after JDK-8259848
- 8266313: (JEP-356) - RandomGenerator spec implementation requirements
tightly coupled to JDK internal classes
- 8270075: SplittableRandom extends
On Tue, 18 May 2021 20:55:10 GMT, Brent Christian wrote:
> Please review this enhancement to add a new JFR event, generated whenever a
> finalizer is run.
> (The makeup is similar to the Deserialization event,
> [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).)
>
> The event's
On Wed, 14 Jul 2021 20:53:34 GMT, Naoto Sato wrote:
>> src/java.base/share/classes/java/io/FileReader.java line 41:
>>
>>> 39: * @see InputStreamReader
>>> 40: * @see FileInputStream
>>> 41: * @see java.nio.charset.Charset#defaultCharset()
>>
>> The @ see duplicates the link above, the
On Wed, 14 Jul 2021 16:20:28 GMT, Jesse Glick
wrote:
>> src/java.base/share/classes/java/io/PrintStream.java line 49:
>>
>>> 47: * All characters printed by a {@code PrintStream} are converted
>>> into
>>> 48: * bytes using the given encoding or charset, or the default
>>> 49: * console
> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of
> the changes is `Charset.defaultCharset()` returning `UTF-8` and
> `file.encoding` system property being added in the spec, but another notable
> modification is in `java.io.PrintStream` where it continues to use the
On Wed, 14 Jul 2021 14:55:39 GMT, Roger Riggs wrote:
>> Naoto Sato 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 three additional
>> commits
On Wed, 14 Jul 2021 12:39:46 GMT, Giacomo Baso
wrote:
> > Consider an application that creates a java.io.FileWriter with its
> > one-argument constructor and then uses it to write some text to a file. The
> > resulting file will contain a sequence of bytes encoded using the default
> >
On Wed, 14 Jul 2021 16:45:20 GMT, Joe Darcy wrote:
> Are there examples in the JDK or its tests where a method with this
> definition would be used?
I have not identified any as yet. I did verify however that there are no uses
in `open/src/**/*.java` of either `absExact()` or `negateExact()`,
On Wed, 14 Jul 2021 16:43:32 GMT, Joe Darcy wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8075806: Separate div-by-0 verbiage; change impl
>
> src/java.base/share/classes/java/lang/Math.java line 1008:
>
>>
> Please consider this proposal to add `divideExact()` methods for integral
> data types to `java.lang.Math` thereby rounding out "exact" support to all
> four basic arithmetic operations.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last
Mysteries of JIT compilation...
On 2021-07-14 21:53, Brian Burkhalter wrote:
On Tue, 13 Jul 2021 17:21:52 GMT, Brian Burkhalter wrote:
Please consider this proposal to add `divideExact()` methods for integral data types to
`java.lang.Math` thereby rounding out "exact" support to all four
On Tue, 13 Jul 2021 17:21:52 GMT, Brian Burkhalter wrote:
> Please consider this proposal to add `divideExact()` methods for integral
> data types to `java.lang.Math` thereby rounding out "exact" support to all
> four basic arithmetic operations.
@rgiulietti Actually your trick is the
On Tue, 13 Jul 2021 17:21:52 GMT, Brian Burkhalter wrote:
> Please consider this proposal to add `divideExact()` methods for integral
> data types to `java.lang.Math` thereby rounding out "exact" support to all
> four basic arithmetic operations.
Thanks. I was thinking of leveraging the
Sorry, typo
int q = x / y;
if ((x & y & q) >= 0) {
return q; // q, not r
}
throw new ArithmeticException("integer overflow");
On 2021-07-14 21:26, Raffaello Giulietti wrote:
One could also divide first and then check the result:
int q = x / y;
if ((x & y & q) >= 0) {
return r;
}
One could also divide first and then check the result:
int q = x / y;
if ((x & y & q) >= 0) {
return r;
}
throw new ArithmeticException("integer overflow");
No idea about relative perf.
On 2021-07-13 19:32, Brian Burkhalter wrote:
Please consider this proposal to add `divideExact()`
On Fri, 2 Jul 2021 06:20:29 GMT, Markus KARG
wrote:
>> This PR-*draft* is **work in progress** and an invitation to discuss a
>> possible solution for issue
>> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
>> yet* intended for a final review.
>>
>> As proposed
On Fri, 2 Jul 2021 06:20:29 GMT, Markus KARG
wrote:
>> This PR-*draft* is **work in progress** and an invitation to discuss a
>> possible solution for issue
>> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
>> yet* intended for a final review.
>>
>> As proposed
> JDK-8269387: jpackage --add-launcher should have option to not create
> shortcuts for additional launchers
Andy Herrick has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8269387: jpackage --add-launcher should have option to not create
On Tue, 13 Jul 2021 17:21:52 GMT, Brian Burkhalter wrote:
> Please consider this proposal to add `divideExact()` methods for integral
> data types to `java.lang.Math` thereby rounding out "exact" support to all
> four basic arithmetic operations.
Are there examples in the JDK or its tests
On Tue, 13 Jul 2021 23:29:38 GMT, Joe Darcy wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8211002: Change so that Tests.testUlpDiff() handles the NaNs and accepts a
>> ulp tolerance of 2
>
>
> Please consider this proposal to add some test coverage comparing `Math` and
> `StrictMath` results of `pow()`.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8211002: Change so that Tests.testUlpDiff() handles the NaNs and
On Wed, 14 Jul 2021 15:09:41 GMT, Roger Riggs wrote:
>> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of
>> the changes is `Charset.defaultCharset()` returning `UTF-8` and
>> `file.encoding` system property being added in the spec, but another notable
>> modification
On Wed, 7 Jul 2021 20:28:37 GMT, Brian Burkhalter wrote:
> Please consider this change to make the `float` and `double` versions of
> `java.lang.Math.abs()` branch-free.
This pull request has now been integrated.
Changeset: c0d4efff
Author:Brian Burkhalter
URL:
On Thu, 8 Jul 2021 21:23:00 GMT, Naoto Sato wrote:
> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of
> the changes is `Charset.defaultCharset()` returning `UTF-8` and
> `file.encoding` system property being added in the spec, but another notable
> modification is in
On Mon, 12 Jul 2021 17:59:32 GMT, Brian Burkhalter wrote:
>> Please consider this change to make the `float` and `double` versions of
>> `java.lang.Math.abs()` branch-free.
>
> Brian Burkhalter has refreshed the contents of this pull request, and
> previous commits have been removed. The
On Wed, 14 Jul 2021 08:47:56 GMT, Nick Gasson wrote:
> I tried that on N1 and it's very slightly slower than with the 16B alignment
Sorry, ignore that, the result is actually the other way round. Not sure what's
going on there, but there's no significant difference.
-
PR:
> There is a few JDK classes duplicating the contents of Long.hashCode() for
> hash code calculation. They should explicitly delegate to Long.hashCode().
Сергей Цыпанов has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated
On Thu, 8 Jul 2021 21:23:00 GMT, Naoto Sato wrote:
> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of
> the changes is `Charset.defaultCharset()` returning `UTF-8` and
> `file.encoding` system property being added in the spec, but another notable
> modification is in
On Tue, 13 Jul 2021 13:04:36 GMT, Attila Szegedi wrote:
>> src/java.base/share/classes/java/util/BitSet.java line 1040:
>>
>>> 1038: h ^= words[i] * (i + 1);
>>> 1039:
>>> 1040: return Long.hashCode(h);
>>
>> Here `>>` instead of `>>>` in original code seems to be a typo
>
On Fri, 25 Jun 2021 18:53:59 GMT, Jim Laskey wrote:
> The wording of the @implSpec referred to internal methods in the description.
> The patch rewords the @implSpec to be more descriptive of the algorithm than
> the methods used.
This pull request has now been integrated.
Changeset:
On Mon, 12 Jul 2021 14:26:23 GMT, Jim Laskey wrote:
> Random.AbstractSplittableGenerator is an internal class that should not be
> exposed in a public API.
This pull request has now been integrated.
Changeset: 3bbd2332
Author:Jim Laskey
URL:
On Wed, 30 Jun 2021 11:02:41 GMT, Jatin Bhateja wrote:
>> Current VectorAPI Java side implementation expresses rotateLeft and
>> rotateRight operation using following operations:-
>>
>> vec1 = lanewise(VectorOperators.LSHL, n)
>> vec2 = lanewise(VectorOperators.LSHR, n)
>> res =
On Tue, 13 Jul 2021 07:37:31 GMT, Wang Huang wrote:
>> Dear all,
>> Can you do me a favor to review this patch. This patch use `ldp` to
>> implement String.compareTo.
>>
>> * We add a JMH test case
>> * Here is the result of this test case
>>
>> Benchmark
42 matches
Mail list logo
