> The commit in this PR implements the proposal for enhancement that was
> discussed in the core-libs-dev mailing list recently[1], for
> https://bugs.openjdk.java.net/browse/JDK-8231640
>
> At a high level - the `store()` APIs in `Properties` have been modified to
> now look for the `SOURCE_DA
Hello Roger,
I've now updated the PR to implement these suggested changes. I think at
this point all suggestions have been implemented and I don't think there
are any open questions.
If the latest PR looks fine, I think the next step will be a CSR creation.
-Jaikiran
On 13/09/21 7:13 pm, Ro
> The commit in this PR implements the proposal for enhancement that was
> discussed in the core-libs-dev mailing list recently[1], for
> https://bugs.openjdk.java.net/browse/JDK-8231640
>
> At a high level - the `store()` APIs in `Properties` have been modified to
> now look for the `SOURCE_DA
Hello Bernd,
On 14/09/21 6:10 am, Bernd Eckenfels wrote:
Is there support for repeatable builds planned? Using the source file might be
acceptable, but the class file timestamp could be changing more likely for
repeated builds?
To clarify the description of my PR, this change uses the timest
On Tue, 14 Sep 2021 00:15:31 GMT, David Holmes wrote:
> Please review this trivial fix to add the missing comma.
>
> Thanks,
> David
This pull request has now been integrated.
Changeset: c54a918a
Author:David Holmes
URL:
https://git.openjdk.java.net/jdk/commit/c54a918a0e526403a395a
On Tue, 14 Sep 2021 00:15:31 GMT, David Holmes wrote:
> Please review this trivial fix to add the missing comma.
>
> Thanks,
> David
Thanks Paul and Ian!
-
PR: https://git.openjdk.java.net/jdk/pull/5504
On Tue, 14 Sep 2021 00:15:31 GMT, David Holmes wrote:
> Please review this trivial fix to add the missing comma.
>
> Thanks,
> David
LGTM. Thanks @dholmes-ora
-
PR: https://git.openjdk.java.net/jdk/pull/5504
On Tue, 14 Sep 2021 00:15:31 GMT, David Holmes wrote:
> Please review this trivial fix to add the missing comma.
>
> Thanks,
> David
Marked as reviewed by psandoz (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5504
Please review this trivial fix to add the missing comma.
Thanks,
David
-
Commit messages:
- 8273691: Missing comma after 2021 in GraphemeTestAccessor.java copyright
notice
Changes: https://git.openjdk.java.net/jdk/pull/5504/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk
Is there support for repeatable builds planned? Using the source file might be
acceptable, but the class file timestamp could be changing more likely for
repeated builds?
--
http://bernd.eckenfels.net
Von: core-libs-dev im Auftrag von
Jaikiran Pai
Gesendet: M
On Wed, 8 Sep 2021 20:24:31 GMT, Ian Graves wrote:
> The duplicate condition in this chain of expressions needs to be shrunk to
> drop a couple of character that are not excluded spacing marks.
This pull request has now been integrated.
Changeset: 3d9dc8f8
Author:Ian Graves
URL:
ht
On Fri, 10 Sep 2021 08:32:02 GMT, Kartik Ohri
wrote:
> Hi all!
>
> Please review this PR to add a benchmark comparing the performance of
> Arrays.mismatch intrinsic in the JDK with that of the Vector API. Kindly
> refer to this [thread] on panama-dev regarding some initial discussion about
>
On Fri, 10 Sep 2021 08:32:02 GMT, Kartik Ohri
wrote:
> Hi all!
>
> Please review this PR to add a benchmark comparing the performance of
> Arrays.mismatch intrinsic in the JDK with that of the Vector API. Kindly
> refer to this [thread] on panama-dev regarding some initial discussion about
>
On Wed, 8 Sep 2021 13:00:17 GMT, Erik Gahlin wrote:
> Hi,
>
> Could I have a review of change that prevents invalid Java identifiers or
> type names in JFR events. For rationale and compatibility issues see the CSR
> request. The only change to java.base is making
> jdk.modules.internal.Check
Hi all!
Please review this PR to add a benchmark comparing the performance of
Arrays.mismatch intrinsic in the JDK with that of the Vector API. Kindly refer
to this [thread] on panama-dev regarding some initial discussion about this
benchmark. I have attached the [results] of the full benchmark
On Wed, 8 Sep 2021 22:00:53 GMT, Brian Burkhalter wrote:
> Modify the class level specification of `java.io.FilterInputStream` to be
> more exact about `java.io.InputStream` methods that it overrides.
This pull request has now been integrated.
Changeset: 6cf5079d
Author:Brian Burkhalter
U
On Fri, 10 Sep 2021 21:16:19 GMT, Pavel Rappo wrote:
> 8273616: Fix trivial doc typos in the java.base module
This pull request has now been integrated.
Changeset: b4b12101
Author:Pavel Rappo
URL:
https://git.openjdk.java.net/jdk/commit/b4b121018d16e531f3a51ff75ae37fdc374d530b
Stats
On Fri, 14 May 2021 17:50:11 GMT, Piotr Tarsa
wrote:
>> I made a JMH test on jdk16 to test count4 (xor) performance:
>> https://github.com/bourgesl/nearly-optimal-mergesort-code/tree/master/sort-bench/results/count_xor
>>
>>
>> Benchmark (size) Mode Cnt Score Error Units
>> ArrayXorBenchmark.a
On Thu, 20 May 2021 08:03:03 GMT, Nils Eliasson wrote:
>> I agree with Laurent (bourgesl), see his comment on May 15 regarding to xor:
>> using Unsafe is only 2% faster, not worth the extra complexity for few
>> percent.
>
> A small update of the XorINodes type calculation makes the bound check
On Tue, 18 May 2021 19:58:35 GMT, iaroslavski
wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8267332
>
> I agree with Laurent (bourgesl), see his comment on May 15 regarding to xor:
> using Unsafe is only 2% faster, not worth the extra complexity for few
> percent.
A small update of the Xo
On Tue, 18 May 2021 18:06:21 GMT, Nils Eliasson wrote:
>> src/java.base/share/classes/java/util/DualPivotQuicksort.java line 672:
>>
>>> 670: count2[(a[i] >>> 8) & 0xFF]--;
>>> 671: count3[(a[i] >>> 16) & 0xFF]--;
>>> 672: count4[(a[i] >>> 24) ^ 0x80]--;
>>
On Sat, 8 May 2021 20:54:48 GMT, iaroslavski
wrote:
> Sorting:
>
> - adopt radix sort for sequential and parallel sorts on int/long/float/double
> arrays (almost random and length > 6K)
> - fix tryMergeRuns() to better handle case when the last run is a single
> element
> - minor javadoc and
On Thu, 20 May 2021 21:21:26 GMT, Nils Eliasson wrote:
>> A small update of the XorINodes type calculation makes the bound check go
>> away. Testing now.
>
> That bounds check shouldn't be there, it's an obvious case and will be fixed:
> https://github.com/openjdk/jdk/pull/4136
Thanks for fixi
On Tue, 11 May 2021 14:37:21 GMT, Jörn Horstmann
wrote:
>> Sorting:
>>
>> - adopt radix sort for sequential and parallel sorts on
>> int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single
>> element
>> - minor j
On Fri, 14 May 2021 13:18:27 GMT, Laurent Bourgès wrote:
>> I don't know Laurent, I find the handling of signed order over-complicated.
>> Subtracting `Integer.MIN_VALUE` is really cheap...
>
> I made a JMH test on jdk16 to test count4 (xor) performance:
> https://github.com/bourgesl/nearly-opti
On Thu, 13 May 2021 20:47:48 GMT, Richard Startin
wrote:
>> Sorting:
>>
>> - adopt radix sort for sequential and parallel sorts on
>> int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single
>> element
>> - minor
On Sat, 8 May 2021 20:54:48 GMT, iaroslavski
wrote:
> Sorting:
>
> - adopt radix sort for sequential and parallel sorts on int/long/float/double
> arrays (almost random and length > 6K)
> - fix tryMergeRuns() to better handle case when the last run is a single
> element
> - minor javadoc and
On Fri, 14 May 2021 07:41:19 GMT, Richard Startin
wrote:
>> Great analysis on C2, richard.
>>
>> maybe (x ^ 0x80) &0xFF would help C2 to eliminate bound checks...
>
> I don't know Laurent, I find the handling of signed order over-complicated.
> Subtracting `Integer.MIN_VALUE` is really cheap..
On Thu, 13 May 2021 09:53:37 GMT, Richard Startin
wrote:
>> Laurent, the date in this class is not the date of our last commit,
>> this date is the date when I have final idea regarding to Radix sort,
>> therefore, I prefer to keep 2020.06.14
>
> Hi @iaroslavski I'm unconvinced that this work wa
On Thu, 13 May 2021 10:22:57 GMT, Laurent Bourgès wrote:
>> Hi @iaroslavski I'm unconvinced that this work was from 14/06/2020 - I
>> believe this work derives from an unsigned radix sort I implemented on
>> 10/04/2021
>> https://github.com/richardstartin/radix-sort-benchmark/commit/ab4da230e1
On Thu, 13 May 2021 21:44:38 GMT, Richard Startin
wrote:
>> For what it's worth, I benchmarked this implementation radix sort ([adapted
>> here to fit in to my
>> harness](https://github.com/richardstartin/radix-sort-benchmark/commit/07169e8e8602152cfda859baa159db165bf5fcab#diff-6c13d3fb74f389
On Fri, 14 May 2021 07:14:27 GMT, Laurent Bourgès wrote:
>> So the issue of not skipping passes was my fault in the translation process,
>> so not something to worry about, though after [fixing
>> that](https://github.com/richardstartin/radix-sort-benchmark/commit/ccbee984c6a0e0f50c30de59e1a5e9
On Thu, 13 May 2021 14:44:28 GMT, Richard Startin
wrote:
>> @iaroslavski I would prefer to discuss this in private than here, but my
>> argument is that the name `skipByte` came from Laurent's code, and that
>> Laurent's code was clearly derived from my own within a fork of my
>> repository.
On Thu, 13 May 2021 20:23:16 GMT, Richard Startin
wrote:
>> In private correspondence with Vladimir, it was explained that where
>> Vladimir's code and Laurent's code are identical, including typos
>> ([Vladimir's
>> code](https://github.com/iaroslavski/sorting/commit/f076073b8b819a9687613903
On Thu, 13 May 2021 11:31:49 GMT, iaroslavski
wrote:
>> Perhaps we can resolve this issue in private - my email address is on my
>> profile (or in the commits in `radix-sort-benchmark`)?
>
> @richardstartin And one more addon: my first version of Radix sort, see my
> github https://github.com/
On Thu, 13 May 2021 11:47:58 GMT, Richard Startin
wrote:
>> @richardstartin And one more addon: my first version of Radix sort, see my
>> github https://github.com/iaroslavski/sorting/tree/master/radixsort uses
>> another name, like skipBytes, then renamed to passLevel.
>> So, the common part
On Thu, 13 May 2021 10:53:48 GMT, Richard Startin
wrote:
>> You misunderstood my approach:
>> - vladimir & tagir discussed radix sorts since previous work on DPQS in 2019
>> - I enjoyed reading your blog post testing the performance of your radix
>> sort vs Arrays.sort()
>> - I tested and forke
On Wed, 12 May 2021 12:20:09 GMT, iaroslavski
wrote:
>> src/java.base/share/classes/java/util/DualPivotQuicksort.java line 47:
>>
>>> 45: * @author Doug Lea
>>> 46: *
>>> 47: * @version 2020.06.14
>>
>> Vladimir, I would update to 2021.05.06 (+your hash)
>
> Laurent, the date in this class
On Wed, 12 May 2021 12:20:09 GMT, iaroslavski
wrote:
>> src/java.base/share/classes/java/util/DualPivotQuicksort.java line 47:
>>
>>> 45: * @author Doug Lea
>>> 46: *
>>> 47: * @version 2020.06.14
>>
>> Vladimir, I would update to 2021.05.06 (+your hash)
>
> Laurent, the date in this class
On Sat, 8 May 2021 20:54:48 GMT, iaroslavski
wrote:
> Sorting:
>
> - adopt radix sort for sequential and parallel sorts on int/long/float/double
> arrays (almost random and length > 6K)
> - fix tryMergeRuns() to better handle case when the last run is a single
> element
> - minor javadoc and
On Wed, 12 May 2021 11:36:09 GMT, Laurent Bourgès wrote:
>> Sorting:
>>
>> - adopt radix sort for sequential and parallel sorts on
>> int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single
>> element
>> - minor j
On Sat, 8 May 2021 20:54:48 GMT, iaroslavski
wrote:
> Sorting:
>
> - adopt radix sort for sequential and parallel sorts on int/long/float/double
> arrays (almost random and length > 6K)
> - fix tryMergeRuns() to better handle case when the last run is a single
> element
> - minor javadoc and
Sorting:
- adopt radix sort for sequential and parallel sorts on int/long/float/double
arrays (almost random and length > 6K)
- fix tryMergeRuns() to better handle case when the last run is a single element
- minor javadoc and comment changes
Testing:
- add new data inputs in tests for sorting
-
On Mon, 13 Sep 2021 11:06:15 GMT, Сергей Цыпанов
wrote:
> Currently the method is implemented like
>
> public List> parameterList() {
> return Collections.unmodifiableList(Arrays.asList(ptypes.clone()));
> }
>
> This seems to be excessive, as three objects are allocated here. Instead we
> c
On Mon, 13 Sep 2021 11:06:15 GMT, Сергей Цыпанов
wrote:
> Currently the method is implemented like
>
> public List> parameterList() {
> return Collections.unmodifiableList(Arrays.asList(ptypes.clone()));
> }
>
> This seems to be excessive, as three objects are allocated here. Instead we
> c
On Mon, 13 Sep 2021 11:22:27 GMT, Pavel Rappo wrote:
>> 8273616: Fix trivial doc typos in the java.base module
>
> Pavel Rappo has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Use "ensure" instead of "insure"
Marked as reviewed by jrose (Re
> Greetings,
>
> Object.finalize() was deprecated in JDK9. There is an ongoing effort to
> replace and mitigate Object.finalize() uses in the JDK libraries; please see
> https://bugs.openjdk.java.net/browse/JDK-8253568 for more information.
>
> We also like to assist users in replacing and mit
On Thu, 19 Aug 2021 15:15:31 GMT, Aleksey Shipilev wrote:
> See the bug report for more details. I would appreciate if people with their
> corporate testing systems would run this through their systems to avoid
> surprises. (ping @RealCLanger, @iignatev).
@ArnoZeller, have your runs identify a
On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For the
> Relaxing some assertion bounds to allow for small error values that still
> show improvement over previous summation method.
Ian Graves has updated the pull request incrementally with one additional
commit since the last revision:
Factoring out Math.pow for squares
-
Changes:
On Mon, 13 Sep 2021 00:08:20 GMT, Joe Darcy wrote:
>> Ian Graves has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Tweaking asserts
>
> test/jdk/java/util/DoubleStreamSums/CompensatedSums.java line 87:
>
>> 85: badParallelStre
On Mon, 13 Sep 2021 11:22:27 GMT, Pavel Rappo wrote:
>> 8273616: Fix trivial doc typos in the java.base module
>
> Pavel Rappo has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Use "ensure" instead of "insure"
Marked as reviewed by lancea (R
On Thu, 2 Sep 2021 19:26:12 GMT, Naoto Sato wrote:
> Simple spec clarification. A CSR has also been drafted
> (https://bugs.openjdk.java.net/browse/JDK-8273296).
This pull request has now been integrated.
Changeset: 4cfa230e
Author:Naoto Sato
URL:
https://git.openjdk.java.net/jdk/c
On Mon, 13 Sep 2021 11:22:27 GMT, Pavel Rappo wrote:
>> 8273616: Fix trivial doc typos in the java.base module
>
> Pavel Rappo has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Use "ensure" instead of "insure"
Marked as reviewed by iris (Rev
On Mon, 13 Sep 2021 11:06:15 GMT, Сергей Цыпанов
wrote:
> Currently the method is implemented like
>
> public List> parameterList() {
> return Collections.unmodifiableList(Arrays.asList(ptypes.clone()));
> }
>
> This seems to be excessive, as three objects are allocated here. Instead we
> c
Hi Jaikiran,
"Editing" the value of the comment property, to remove or ignore blanks
for other special
characters makes the code more complex and adds a bunch of conditions.
Dropping
the comment if it doesn't have the allowed format is hard to track down,
because there's
no way to report it w
On Mon, 13 Sep 2021 11:22:27 GMT, Pavel Rappo wrote:
>> 8273616: Fix trivial doc typos in the java.base module
>
> Pavel Rappo has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Use "ensure" instead of "insure"
Marked as reviewed by rriggs (R
On Mon, 13 Sep 2021 11:06:15 GMT, Сергей Цыпанов
wrote:
> Currently the method is implemented like
>
> public List> parameterList() {
> return Collections.unmodifiableList(Arrays.asList(ptypes.clone()));
> }
>
> This seems to be excessive, as three objects are allocated here. Instead we
> c
On Mon, 13 Sep 2021 11:22:27 GMT, Pavel Rappo wrote:
>> 8273616: Fix trivial doc typos in the java.base module
>
> Pavel Rappo has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Use "ensure" instead of "insure"
LGTM
-
Marked as
On Fri, 10 Sep 2021 23:20:11 GMT, Pavel Rappo wrote:
>> 8273616: Fix trivial doc typos in the java.base module
>
> Pavel Rappo has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Revert two fixes
Thanks to those who reviewed this PR. Since I p
> 8273616: Fix trivial doc typos in the java.base module
Pavel Rappo has updated the pull request incrementally with one additional
commit since the last revision:
Use "ensure" instead of "insure"
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/5475/files
- new: https
Currently the method is implemented like
public List> parameterList() {
return Collections.unmodifiableList(Arrays.asList(ptypes.clone()));
}
This seems to be excessive, as three objects are allocated here. Instead we can
use `List.of(ptypes)` which doesn't allocate anything for empty array an
On Wed, 8 Sep 2021 17:37:20 GMT, Coleen Phillimore wrote:
>> Markus Grönlund has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - localize
>> - cleanup
>> - FinalizerStatistics
>
> src/hotspot/share/services/classLoadingService.cpp line
Hi,
Could I have a review of change that prevents invalid Java identifiers or type
names in JFR events. For rationale and compatibility issues see the CSR
request. The only change to java.base is making
jdk.modules.internal.Checks::isJavaIdentifier(String) public, so it can be
reused by the jd
On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For the
65 matches
Mail list logo
