RFR: 8256585: Remove in-place conversion vector operators from Vector API
Remove partially implemented in-place conversion vector operators from Vector API: ofNarrowing, ofWidening, INPLACE_XXX - Commit messages: - 8256585: Remove in-place conversion vector operators from Vector API Changes: https://git.openjdk.java.net/jdk/pull/1305/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1305=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256585 Stats: 121 lines in 1 file changed: 0 ins; 118 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1305.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1305/head:pull/1305 PR: https://git.openjdk.java.net/jdk/pull/1305
RFR: 8037384: Fix wording in Javadoc of java.io.Serializable
8231547: Serializable class doc should link to serialization specification Rewrite a couple confusing sentences in the Serializable class doc. This does affect normative text, but the edits are primarily to focus and clarify the text, not to make any semantic changes. Thus, a CSR request shouldn't be required for this change. Also add and adjust some links and link markup to the Java Object Serialization Specification. - Commit messages: - 8037384: Fix wording in Javadoc of java.io.Serializable Changes: https://git.openjdk.java.net/jdk/pull/1306/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1306=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8037384 Stats: 27 lines in 5 files changed: 5 ins; 1 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/1306.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1306/head:pull/1306 PR: https://git.openjdk.java.net/jdk/pull/1306
Re: RFR: 8256487: Handle disableEagerInitialization for archived lambda proxy classes
On Thu, 19 Nov 2020 00:50:52 GMT, Claes Redestad wrote: >> Before this change, the setting of the >> `jdk.internal.lambda.disableEagerInitialization` property was not captured >> during dumping of lambda proxy classes. There's a workaround in >> `LambdaProxyClassArchive.find`, it won't call `findFromArchive` if the above >> property is set. >> >> This change adds handling of the >> `jdk.internal.lambda.disableEagerInitialization` property, specifically: >> >> - remove the above workaround; >> >> - capture the setting of the property in the archive header during CDS dump >> time; >> >> - during runtime when finding an archived lambda proxy class, the setting of >> the property will be compared with the stored value in the archive header. >> If the values don't match, the archived lambda proxy class won't be used. >> >> Tests: >> >> - [x] ran all cds tests locally on linux-x64 >> >> - [x] ran the `hotspot_appcds_dynamic` test group with >> `-Dtest.dynamic.cds.archive=true` on linux-x64 >> >> - [x] mach5 tiers 1,2,3 (in progress) > > I'm not sure if this is a good idea, TBH. The disableEagerInitialization > setting is for native-image pre-generation purposes and the less CDS cares > about it, the better. I'd prefer it if there's no trace of the property in > hotspot sources. Hi Claes, Thanks for taking a look. So should I keep the following `!initialize` check in LambdaProxyClassArchive? 109 if (!loadedByBuiltinLoader(caller) || !initialize || 110 !CDS.isSharingEnabled() || isSerializable || markerInterfaces.length > 0 || additionalBridges.length > 0) 111 return null; If we keep the above code, I think we don't need to pass the `initialize` to `findFromArchive` and eventually to `JVM_LookupLambdaProxyClassFromArchive`. Let me know if the above is what you have in mind? thanks, Calvin - PR: https://git.openjdk.java.net/jdk/pull/1301
Re: RFR: 8251317: Support for CLDR version 38
On Tue, 17 Nov 2020 23:19:23 GMT, Naoto Sato wrote: > Hi, > > Please review the changes for upgrading the CLDR data to version 38. The vast > majority of the changes are simply the changes in CLDR upstream, and others > are mainly test changes due to the locale data change. Looks good to me. - Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1279
RFR: 8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem
Hi, Please review this simple change that catches UncheckedIOException that can occur if /proc/self/cgroup or /proc/self/mountinfo files don't exist on the system, or if there is an interrupt while these are being read. Testing: Tier1, Tier2 and Tier3. Thanks, Poonam - Commit messages: - 8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem Changes: https://git.openjdk.java.net/jdk/pull/1303/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1303=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255908 Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1303.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1303/head:pull/1303 PR: https://git.openjdk.java.net/jdk/pull/1303
Re: RFR: 8253299: Manifest bytes are read twice when verifying a signed JAR
On Wed, 18 Nov 2020 21:59:01 GMT, Hai-May Chao wrote: > Small change to retrieve the raw bytes of manifest during verifying signed > JAR. The changes looks good. I am assuming that we do not need an additional test for this and if so, please add a noreg label such as noreg-trivial to the bug - PR: https://git.openjdk.java.net/jdk/pull/1299
Re: RFR: JDK-8256475: Fix Behavior when Installer name differs from applicatio…
On Wed, 18 Nov 2020 22:17:07 GMT, Andy Herrick wrote:
> …n name.
src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java line
312:
> 310: Path appDir;
> 311: if (appName == null) {
> 312: // this can only happen when no name is given and using
> forign app-image
forign -> foreign
test/jdk/tools/jpackage/share/MultiNameTwoPhaseTest.java line 34:
> 32:
> 33: /**
> 34: */
Needs description for test.
-
PR: https://git.openjdk.java.net/jdk/pull/1300
Re: RFR: 8227400: Adjust jib profiles to make 3rd party tools for creating installers available on Mach5 test machines
On Wed, 18 Nov 2020 21:57:13 GMT, Alexey Semenyuk wrote: > Fix test failures. They didn't fail in Mach5 test runs as WiX was not > available on test machines and these tests were not executed. Marked as reviewed by almatvee (Committer). - PR: https://git.openjdk.java.net/jdk/pull/1298
RFR: 8256581: Refactor vector conversion tests
Refactor the vector conversions tests to improve performance and reduce explicit test methods (using data providers). - Commit messages: - 8256581: Refactor vector conversion tests Changes: https://git.openjdk.java.net/jdk/pull/1302/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1302=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256581 Stats: 37231 lines in 6 files changed: 212 ins; 36768 del; 251 mod Patch: https://git.openjdk.java.net/jdk/pull/1302.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1302/head:pull/1302 PR: https://git.openjdk.java.net/jdk/pull/1302
Re: RFR: 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly [v13]
> The `java.util.Formatter` format specifies support for field widths, argument > indexes, or precision lengths of a field that relate to the variadic > arguments supplied to the formatter. These numbers are specified by integers, > sometimes negative. For argument index, it's specified in the documentation > that the highest allowed argument is limited by the largest possible index of > an array (ie the largest possible variadic index), but for the other two it's > not defined. Moreover, what happens when a number field in a string is too > large or too small to be represented by a 32-bit integer type is not defined. > > This fix adds documentation to specify what error behavior occurs during > these cases. Additionally it adds an additional exception type to throw when > an invalid argument index is observed. > > A CSR will be required for this PR. Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Comment cleanup - Changes: - all: https://git.openjdk.java.net/jdk/pull/516/files - new: https://git.openjdk.java.net/jdk/pull/516/files/223282d4..78fc8176 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=516=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk=516=11-12 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/516.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516 PR: https://git.openjdk.java.net/jdk/pull/516
Re: RFR: 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly [v12]
On Thu, 19 Nov 2020 00:38:49 GMT, Stuart Marks wrote:
>> Ian Graves has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 'unrepresentable' to 'not representable'
>
> test/jdk/java/util/IllegalFormatException/TestFormatSpecifierBounds.java line
> 48:
>
>> 46: String r = String.format("%2147483648$s", "A", "B");
>> 47: });
>> 48: //assertEquals(e.getMessage(), "Illegal format argument index =
>> " + Integer.MIN_VALUE);
>
> Extraneous comment?
So it would seem!
-
PR: https://git.openjdk.java.net/jdk/pull/516
Re: RFR: 8256487: Handle disableEagerInitialization for archived lambda proxy classes
On Wed, 18 Nov 2020 23:58:25 GMT, Calvin Cheung wrote: > Before this change, the setting of the > `jdk.internal.lambda.disableEagerInitialization` property was not captured > during dumping of lambda proxy classes. There's a workaround in > `LambdaProxyClassArchive.find`, it won't call `findFromArchive` if the above > property is set. > > This change adds handling of the > `jdk.internal.lambda.disableEagerInitialization` property, specifically: > > - remove the above workaround; > > - capture the setting of the property in the archive header during CDS dump > time; > > - during runtime when finding an archived lambda proxy class, the setting of > the property will be compared with the stored value in the archive header. > If the values don't match, the archived lambda proxy class won't be used. > > Tests: > > - [x] ran all cds tests locally on linux-x64 > > - [x] ran the `hotspot_appcds_dynamic` test group with > `-Dtest.dynamic.cds.archive=true` on linux-x64 > > - [x] mach5 tiers 1,2,3 (in progress) I'm not sure if this is a good idea, TBH. The disableEagerInitialization setting is for native-image pre-generation purposes and the less CDS cares about it, the better. I'd prefer it if there's no trace of the property in hotspot sources. - PR: https://git.openjdk.java.net/jdk/pull/1301
Re: RFR: 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly [v12]
On Wed, 18 Nov 2020 22:57:19 GMT, Ian Graves wrote:
>> The `java.util.Formatter` format specifies support for field widths,
>> argument indexes, or precision lengths of a field that relate to the
>> variadic arguments supplied to the formatter. These numbers are specified by
>> integers, sometimes negative. For argument index, it's specified in the
>> documentation that the highest allowed argument is limited by the largest
>> possible index of an array (ie the largest possible variadic index), but for
>> the other two it's not defined. Moreover, what happens when a number field
>> in a string is too large or too small to be represented by a 32-bit integer
>> type is not defined.
>>
>> This fix adds documentation to specify what error behavior occurs during
>> these cases. Additionally it adds an additional exception type to throw when
>> an invalid argument index is observed.
>>
>> A CSR will be required for this PR.
>
> Ian Graves has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 'unrepresentable' to 'not representable'
Marked as reviewed by smarks (Reviewer).
test/jdk/java/util/IllegalFormatException/TestFormatSpecifierBounds.java line
48:
> 46: String r = String.format("%2147483648$s", "A", "B");
> 47: });
> 48: //assertEquals(e.getMessage(), "Illegal format argument index = "
> + Integer.MIN_VALUE);
Extraneous comment?
-
PR: https://git.openjdk.java.net/jdk/pull/516
RFR: 8256487: Handle disableEagerInitialization for archived lambda proxy classes
Before this change, the setting of the `jdk.internal.lambda.disableEagerInitialization` property was not captured during dumping of lambda proxy classes. There's a workaround in `LambdaProxyClassArchive.find`, it won't call `findFromArchive` if the above property is set. This change adds handling of the `jdk.internal.lambda.disableEagerInitialization` property, specifically: - remove the above workaround; - capture the setting of the property in the archive header during CDS dump time; - during runtime when finding an archived lambda proxy class, the setting of the property will be compared with the stored value in the archive header. If the values don't match, the archived lambda proxy class won't be used. Tests: - [x] ran all cds tests locally on linux-x64 - [x] ran the `hotspot_appcds_dynamic` test group with `-Dtest.dynamic.cds.archive=true` on linux-x64 - [x] mach5 tiers 1,2,3 (in progress) - Commit messages: - Merge branch 'master' into 8256487-disableEagerInit - 8256487: Handle disableEagerInitialization for archived lambda proxy classes Changes: https://git.openjdk.java.net/jdk/pull/1301/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1301=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256487 Stats: 263 lines in 15 files changed: 246 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/1301.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1301/head:pull/1301 PR: https://git.openjdk.java.net/jdk/pull/1301
Re: RFR: 8256480: Refactor ObjectInputStream field reader implementation
Hi, Roger.
The change looks good. I just noticed a couple small things:
2324 for (int i = 0; i < slots.length-1; i++) {
2325 new FieldValues(slots[i].desc, true);
The slots[i].hasData check is no longer performed here.
2561 primValues = new byte[desc.getPrimDataSize()];
2562 objValues = new Object[desc.getNumObjFields()];
In defaultReadFields(), the arrays would remain null in the case of a 0
from getPrimDataSize() or getNumObjFields(). In the new code, 0-length
arrays are created.
Thanks,
-Brent
On 11/18/20 9:39 AM, Roger Riggs wrote:
ObjectInputStream has nearly identical but separate implementations to read
values from the stream.
Both implementations read primitive and object values from the stream and
return an object holding the values.
OIS.readFields() uses the internal class GetFieldImpl while
OIS.defaultReadObject and reading records uses the internal class FieldValues.
The behavioral difference between the two is whether dependencies are tracked
in the object handle table or not.
The classes are merged, retaining the internal FieldValues name and the
behavior to track dependencies or not.
The constructor is passed the class descriptor and flag to track or not; it
reads and saves the values from the stream.
The callers are updated to call the merge FieldValues methods.
There is no change in behavior; all current tests pass.
-
Commit messages:
- 8256480: Refactor ObjectInputStream field reader implementation
Changes: https://git.openjdk.java.net/jdk/pull/1296/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1296=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8256480
Stats: 157 lines in 1 file changed: 26 ins; 78 del; 53 mod
Patch: https://git.openjdk.java.net/jdk/pull/1296.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/1296/head:pull/1296
PR: https://git.openjdk.java.net/jdk/pull/1296
Re: RFR: 8253299: Manifest bytes are read twice when verifying a signed JAR
On Wed, 18 Nov 2020 21:59:01 GMT, Hai-May Chao wrote: > Small change to retrieve the raw bytes of manifest during verifying signed > JAR. This seems like a good optimization. I think comparing the manifest name case insensitively might be preferable - e.g. using String.equalsIgnoreCase - but if the worst that can happen is that a non-conventionally cased is read twice then I think what you have here is good. - Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1299
Re: RFR: 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly [v12]
On Wed, 18 Nov 2020 22:57:19 GMT, Ian Graves wrote: >> The `java.util.Formatter` format specifies support for field widths, >> argument indexes, or precision lengths of a field that relate to the >> variadic arguments supplied to the formatter. These numbers are specified by >> integers, sometimes negative. For argument index, it's specified in the >> documentation that the highest allowed argument is limited by the largest >> possible index of an array (ie the largest possible variadic index), but for >> the other two it's not defined. Moreover, what happens when a number field >> in a string is too large or too small to be represented by a 32-bit integer >> type is not defined. >> >> This fix adds documentation to specify what error behavior occurs during >> these cases. Additionally it adds an additional exception type to throw when >> an invalid argument index is observed. >> >> A CSR will be required for this PR. > > Ian Graves has updated the pull request incrementally with one additional > commit since the last revision: > > 'unrepresentable' to 'not representable' Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/516
Re: RFR: 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly [v12]
> The `java.util.Formatter` format specifies support for field widths, argument > indexes, or precision lengths of a field that relate to the variadic > arguments supplied to the formatter. These numbers are specified by integers, > sometimes negative. For argument index, it's specified in the documentation > that the highest allowed argument is limited by the largest possible index of > an array (ie the largest possible variadic index), but for the other two it's > not defined. Moreover, what happens when a number field in a string is too > large or too small to be represented by a 32-bit integer type is not defined. > > This fix adds documentation to specify what error behavior occurs during > these cases. Additionally it adds an additional exception type to throw when > an invalid argument index is observed. > > A CSR will be required for this PR. Ian Graves has updated the pull request incrementally with one additional commit since the last revision: 'unrepresentable' to 'not representable' - Changes: - all: https://git.openjdk.java.net/jdk/pull/516/files - new: https://git.openjdk.java.net/jdk/pull/516/files/36e8d3a3..223282d4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=516=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk=516=10-11 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/516.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516 PR: https://git.openjdk.java.net/jdk/pull/516
Re: RFR: 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly [v11]
On Wed, 18 Nov 2020 22:30:21 GMT, Roger Riggs wrote:
>> Ian Graves has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Exception message tweak
>
> src/java.base/share/classes/java/util/IllegalFormatArgumentIndexException.java
> line 66:
>
>> 64:
>> 65: if (index == Integer.MIN_VALUE) {
>> 66:return "Format argument index: (unrepresentable as int)";
>
> Perhaps "(not representable as int)" is more readable.
After reading it a few times, I agree.
-
PR: https://git.openjdk.java.net/jdk/pull/516
Re: RFR: 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly [v11]
On Wed, 18 Nov 2020 22:09:21 GMT, Ian Graves wrote:
>> The `java.util.Formatter` format specifies support for field widths,
>> argument indexes, or precision lengths of a field that relate to the
>> variadic arguments supplied to the formatter. These numbers are specified by
>> integers, sometimes negative. For argument index, it's specified in the
>> documentation that the highest allowed argument is limited by the largest
>> possible index of an array (ie the largest possible variadic index), but for
>> the other two it's not defined. Moreover, what happens when a number field
>> in a string is too large or too small to be represented by a 32-bit integer
>> type is not defined.
>>
>> This fix adds documentation to specify what error behavior occurs during
>> these cases. Additionally it adds an additional exception type to throw when
>> an invalid argument index is observed.
>>
>> A CSR will be required for this PR.
>
> Ian Graves has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Exception message tweak
Marked as reviewed by rriggs (Reviewer).
src/java.base/share/classes/java/util/IllegalFormatArgumentIndexException.java
line 66:
> 64:
> 65: if (index == Integer.MIN_VALUE) {
> 66:return "Format argument index: (unrepresentable as int)";
Perhaps "(not representable as int)" is more readable.
-
PR: https://git.openjdk.java.net/jdk/pull/516
RFR: JDK-8256475: Fix Behavior when Installer name differs from applicatio…
…n name. - Commit messages: - JDK-8256475: Fix Behavior when Installer name differs from application name. Changes: https://git.openjdk.java.net/jdk/pull/1300/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1300=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256475 Stats: 207 lines in 18 files changed: 167 ins; 13 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/1300.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1300/head:pull/1300 PR: https://git.openjdk.java.net/jdk/pull/1300
Re: RFR: 8180352: Add Stream.toList() method [v3]
> This change introduces a new terminal operation on Stream. This looks like a > convenience method for Stream.collect(Collectors.toList()) or > Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this > method directly on Stream enables it to do what can't easily by done by a > Collector. In particular, it allows the stream to deposit results directly > into a destination array (even in parallel) and have this array be wrapped in > an unmodifiable List without copying. > > In the past we've kept most things from the Collections Framework as > implementations of Collector, not directly on Stream, whereas only > fundamental things (like toArray) appear directly on Stream. This is true of > most Collections, but it does seem that List is special. It can be a thin > wrapper around an array; it can handle generics better than arrays; and > unlike an array, it can be made unmodifiable (shallowly immutable); and it > can be value-based. See John Rose's comments in the bug report: > > https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065 > > This operation is null-tolerant, which matches the rest of Streams. This > isn't specified, though; a general statement about null handling in Streams > is probably warranted at some point. > > Finally, this method is indeed quite convenient (if the caller can deal with > what this operation returns), as collecting into a List is the most common > stream terminal operation. Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: Adjust List.copyOf to null-check and copy allowNulls lists. Fix equals, hashCode, indexOf, lastIndexOf to handle nulls properly. Add MOAT tests for new lists; add equals and hashCode tests. - Changes: - all: https://git.openjdk.java.net/jdk/pull/1026/files - new: https://git.openjdk.java.net/jdk/pull/1026/files/cf849755..15beacd2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1026=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1026=01-02 Stats: 136 lines in 3 files changed: 104 ins; 22 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/1026.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1026/head:pull/1026 PR: https://git.openjdk.java.net/jdk/pull/1026
Re: RFR: 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly [v11]
> The `java.util.Formatter` format specifies support for field widths, argument > indexes, or precision lengths of a field that relate to the variadic > arguments supplied to the formatter. These numbers are specified by integers, > sometimes negative. For argument index, it's specified in the documentation > that the highest allowed argument is limited by the largest possible index of > an array (ie the largest possible variadic index), but for the other two it's > not defined. Moreover, what happens when a number field in a string is too > large or too small to be represented by a 32-bit integer type is not defined. > > This fix adds documentation to specify what error behavior occurs during > these cases. Additionally it adds an additional exception type to throw when > an invalid argument index is observed. > > A CSR will be required for this PR. Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Exception message tweak - Changes: - all: https://git.openjdk.java.net/jdk/pull/516/files - new: https://git.openjdk.java.net/jdk/pull/516/files/03d55944..36e8d3a3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=516=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk=516=09-10 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/516.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516 PR: https://git.openjdk.java.net/jdk/pull/516
Integrated: 8256152: tests fail because of ambiguous method resolution
On Tue, 17 Nov 2020 20:01:37 GMT, Stuart Marks wrote: > Added a cast in the right place, thanks to @jonathan-gibbons. This pull request has now been integrated. Changeset: 646c2002 Author:Stuart Marks URL: https://git.openjdk.java.net/jdk/commit/646c2002 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8256152: tests fail because of ambiguous method resolution Reviewed-by: psandoz - PR: https://git.openjdk.java.net/jdk/pull/1274
RFR: 8253299: Manifest bytes are read twice when verifying a signed JAR
Small change to retrieve the raw bytes of manifest during verifying signed JAR. - Commit messages: - 8253299: Manifest bytes are read twice when verifying a signed JAR Changes: https://git.openjdk.java.net/jdk/pull/1299/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1299=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253299 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1299.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1299/head:pull/1299 PR: https://git.openjdk.java.net/jdk/pull/1299
Integrated: 8256427: Test com/sun/jndi/dns/ConfigTests/PortUnreachable.java does not work on AIX
On Mon, 16 Nov 2020 22:28:08 GMT, Christoph Langer wrote: > The test com/sun/jndi/dns/ConfigTests/PortUnreachable.java is not working on > AIX. > > It tests that when a DNS server is unreachable it fails quickly with a > PortUnreachableException due to ICMP Destination Unreachable packets received > and not having to wait for the full timeout interval. > Unfortunately, on AIX such ICMP packets are not received, so the only > exception cause will be the timeout. Hence, this test can't work on AIX, so > it should not be executed there. > > At SAP, we had this test excluded for a long time already in our private > exclude list for AIX. I suggest this test update to be the final solution. This pull request has now been integrated. Changeset: 5912df24 Author:Christoph Langer URL: https://git.openjdk.java.net/jdk/commit/5912df24 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8256427: Test com/sun/jndi/dns/ConfigTests/PortUnreachable.java does not work on AIX Reviewed-by: jiefu, mbaesken - PR: https://git.openjdk.java.net/jdk/pull/1241
RFR: 8227400: Adjust jib profiles to make 3rd party tools for creating installers available on Mach5 test machines
Fix test failures. They didn't fail in Mach5 test runs as WiX was not available on test machines and these tests were not executed. - Commit messages: - 8227400: Adjust jib profiles to make 3rd party tools for creating installers available on Mach5 test machines Changes: https://git.openjdk.java.net/jdk/pull/1298/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1298=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8227400 Stats: 21 lines in 4 files changed: 16 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1298.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1298/head:pull/1298 PR: https://git.openjdk.java.net/jdk/pull/1298
Re: RFR: 8256427: Test com/sun/jndi/dns/ConfigTests/PortUnreachable.java does not work on AIX [v2]
On Wed, 18 Nov 2020 07:46:33 GMT, Matthias Baesken wrote: >> Christoph Langer has updated the pull request with a new target base due to >> a merge or a rebase. The pull request now contains one commit: >> >> Test jdk/com/sun/jndi/dns/ConfigTests/PortUnreachable.java does not work >> on AIX > > looks good, thanks for doing the change. Thanks for the reviews! - PR: https://git.openjdk.java.net/jdk/pull/1241
Re: RFR: 8180352: Add Stream.toList() method [v2]
On Tue, 17 Nov 2020 20:04:58 GMT, Stuart Marks wrote: >>> @plevart wrote: >>> >>> > But the question is how does having a separate CollSer.IMM_LIST_NULLS >>> > type prevent that from happening? >>> >>> When a serialized list with IMM_LIST_NULLS is deserialized on an older JDK, >>> it'll throw InvalidObjectException since that tag isn't valid on older >>> JDKs. Obviously this is still an error, but it's a fail-fast approach that >>> avoids letting nulls leak into a data structure where they might cause a >>> problem some arbitrary time later. >>> >> >> Yes, but that is JDK16+ vs. JDK15- and not App V1 vs. App V2 thing. If both >> apps run on JDK16+, there will be no exception. >> >> What I'm trying to say is that the same problem of injecting unexpected >> nulls via serialization/deserialization can happen also if App V2 starts >> using ArrayList to construct the data structure and serialize it while App >> V1 deserializes it and expects non-null values only. App V1 would already >> have to guard against null values during deserialization in that case, >> because possibility of null values in deserialized data structure is nothing >> new for App V1. > > @plevart wrote: >> Yes, but that is JDK16+ vs. JDK15- and not App V1 vs. App V2 thing. If both >> apps run on JDK16+, there will be no exception. > > Sure, the IMM_LIST_NULLS tag only helps with serialization compatibility > across JDK releases. There are lots of ways an app can make incompatible > changes to the serialized forms of its objects that we have no way of > detecting. >> Sure, the IMM_LIST_NULLS tag only helps with serialization compatibility >> across JDK releases. > I would say it goes the other way - it worsens the serialization compatibility. OK, I was imprecise. The IMM_LIST_NULLS tag has an effect only on serialization across JDK releases, not changes to the application's serialization format using the same JDK release, or even on many changes to the app's serialization format across JDK releases. By "helps with serialization compatibility" I meant that this new serialized form helps the general issue of serialization compatibility (really, incompatibility) by failing fast in certain cases, instead of possibly allowing polluted data to leak into the receiving application and causing some arbitrary exception later during the run. But as you noted last, this is a different kind of object, and it has different behavior, so it needs a different encoding in the serialized form. I'll update this PR shortly with changes to fix null handling and other issues. - PR: https://git.openjdk.java.net/jdk/pull/1026
Re: RFR: 8247402: Documentation for Map::compute contains confusing implementation requirements
On Wed, 18 Nov 2020 14:16:03 GMT, Pavel Rappo wrote: >> @dfuch May I ask how can I create a CSR? I checked >> https://wiki.openjdk.java.net/display/csr/CSR+FAQs and it says: >> >>> Q: How do I create a CSR ? >>> A: Do not directly create a CSR from the Create Menu. JIRA will let you do >>> this right up until the moment you try to save it and find your typing was >>> in vain. >>> Instead you should go to the target bug, select "More", and from the drop >>> down menu select "Create CSR". This is required to properly associate the >>> CSR with the main bug, just as is done for backports. >> >> However, I don't have an account at https://bugs.openjdk.java.net/ yet. >> Therefore, I don't see the "More" button on >> https://bugs.openjdk.java.net/browse/JDK-8247402. Could you please tell me >> how do I proceed? Thank you. > > @johnlinp, you cannot create a CSR by yourself at the moment. Someone else > will have to do that for you. Might as well be me. So here's my proposal: > come up with the meat, then I'll help you with the paperwork. > > For starters, have a look at existing CSRs (you don't need a JBS account for > that). For example, > https://bugs.openjdk.java.net/issues/?jql=issuetype%3DCSR%20and%20Subcomponent%3Djava.util%3Acollections%20 > > Fill in an informal CSR template inline in this thread, and we'll proceed > from that point. Is that okay? @pavelrappo Thank you for your kind help and great proposal. I'll write up a draft CSR in this thread. - PR: https://git.openjdk.java.net/jdk/pull/714
Re: RFR: 8251317: Support for CLDR version 38
On Tue, 17 Nov 2020 23:19:23 GMT, Naoto Sato wrote: > Hi, > > Please review the changes for upgrading the CLDR data to version 38. The vast > majority of the changes are simply the changes in CLDR upstream, and others > are mainly test changes due to the locale data change. Changes seem fine to me. - Marked as reviewed by bchristi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1279
Re: RFR: 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly [v10]
> The `java.util.Formatter` format specifies support for field widths, argument > indexes, or precision lengths of a field that relate to the variadic > arguments supplied to the formatter. These numbers are specified by integers, > sometimes negative. For argument index, it's specified in the documentation > that the highest allowed argument is limited by the largest possible index of > an array (ie the largest possible variadic index), but for the other two it's > not defined. Moreover, what happens when a number field in a string is too > large or too small to be represented by a 32-bit integer type is not defined. > > This fix adds documentation to specify what error behavior occurs during > these cases. Additionally it adds an additional exception type to throw when > an invalid argument index is observed. > > A CSR will be required for this PR. Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Docfixes, exception messages, formatting and moving tests to testng - Changes: - all: https://git.openjdk.java.net/jdk/pull/516/files - new: https://git.openjdk.java.net/jdk/pull/516/files/aaa35af2..03d55944 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=516=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk=516=08-09 Stats: 177 lines in 5 files changed: 77 ins; 98 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/516.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516 PR: https://git.openjdk.java.net/jdk/pull/516
Integrated: 8256189: Exact VarHandle tests should test withInvokeBehavior() works as expected
On Tue, 17 Nov 2020 18:32:30 GMT, Jorn Vernee wrote: > This PR sharpens the testing done by > test/jdk/java/lang/invoke/VarHandles/VarHandleTestExact.java after > @mcimadamore reported that the test was not catching an issue with memory > access var handles; namely that the implementation of withInvokeBehavior was > incorrect. > > After some debugging it turned out that the test never actually tested: > (1) going back to invoke behavior from a var handle with invoke exact behavior > (2) the memory access handle implementation of withInvoke(Exact)Behavior, due > to memory handles always being adapted. > > The patch adds testing for (1), and adds a flag to jdk.internal.foreign.Utils > to turn off the adaptation, so that we can test the 'naked' memory access var > handles as well for (2). > > I've also tried to reduce some of the code duplication by creating the higher > order doTest function, that does most of the testing (besides setting up var > handles and test values). This pull request has now been integrated. Changeset: 03e84ef7 Author:Jorn Vernee URL: https://git.openjdk.java.net/jdk/commit/03e84ef7 Stats: 173 lines in 3 files changed: 48 ins; 80 del; 45 mod 8256189: Exact VarHandle tests should test withInvokeBehavior() works as expected Reviewed-by: mcimadamore, chegar - PR: https://git.openjdk.java.net/jdk/pull/1267
Re: RFR: 8230501: Class data support for hidden classes [v4]
On Wed, 18 Nov 2020 17:26:02 GMT, Paul Sandoz wrote: >> Mandy Chung has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix the name passed to condy calling classData > > IIUC `classData` can be used for an original lookup that is not produced by > the result of `defineHiddenClassWithClassData`, but in such cases the class > data will always be null. > > Since `defineHiddenClassWithClassData` rejects null values for class data, we > could detect such usage and throw in the bootstrap methods. That would > require a special constant assignment for hidden classes with no class data. > Probably not worth it. > > Recommend an API note. @PaulSandoz @JornVernee can you please review CSR: https://bugs.openjdk.java.net/browse/JDK-8256214 - PR: https://git.openjdk.java.net/jdk/pull/1171
Re: RFR: 8230501: Class data support for hidden classes [v4]
On Wed, 18 Nov 2020 17:26:02 GMT, Paul Sandoz wrote:
> IIUC classData can be used for an original lookup that is not produced by the
> result of defineHiddenClassWithClassData, but in such cases the class data
> will always be null.
Yes that's the case. I see some clarification would help.I added the
following in the spec of `classData` and `classDataAt`:
* A hidden class created by {@link Lookup#defineHiddenClass(byte[],
boolean, Lookup.ClassOption...)
* Lookup::defineHiddenClass} and non-hidden classes have no class data.
* {@code null} is returned if this method is called on the lookup object
* on these classes.
-
PR: https://git.openjdk.java.net/jdk/pull/1171
Re: RFR: 8230501: Class data support for hidden classes [v4]
On Wed, 18 Nov 2020 16:51:47 GMT, Paul Sandoz wrote:
>> Mandy Chung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix the name passed to condy calling classData
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 342:
>
>> 340: } catch (ClassCastException e) {
>> 341: throw e;
>> 342: } catch (Throwable e) {
>
> The following might be more appropriate so, in general, errors and runtime
> exceptions are not explicitly wrapped:
>
> try {
> return BootstrapMethodInvoker.widenAndCast(classdata, type);
> }
> catch (RuntimeException | Error e) {
> throw e;
> }
> catch (Throwable e) {
> throw new InternalError("Unexpected exception", e);
> }
>
> same applies to `classDataAt` and `ConstantBootstraps.explicitCast`.
> Refinement of the runtime exceptions is also possible, but i think the key
> thing here is to let errors pass through and any possibly expected runtime
> exceptions will get wrapped in `BootstrapMethodError`.
Yes a good refinement.
diff --git
a/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java
b/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java
index 71cae83e160..27d74284dc6 100644
--- a/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java
+++ b/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java
@@ -413,8 +413,8 @@ public final class ConstantBootstraps {
MethodHandle conv = MethodHandles.explicitCastArguments(id, mt);
try {
return conv.invoke(value);
-} catch (ClassCastException e) {
-throw e; // specified, let CCE through
+} catch (RuntimeException|Error e) {
+throw e; // let specified CCE and other runtime exceptions/errors
through
} catch (Throwable throwable) {
throw new InternalError(throwable); // Not specified, throw
InternalError
}
diff --git a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
index cd9bdbaf5a3..368948ab5a8 100644
--- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
+++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
@@ -337,8 +342,8 @@ public class MethodHandles {
try {
return BootstrapMethodInvoker.widenAndCast(classdata, type);
- } catch (ClassCastException e) {
- throw e;
+ } catch (RuntimeException|Error e) {
+ throw e; // let CCE and other runtime exceptions through
} catch (Throwable e) {
throw new InternalError(e);
}
@@ -409,8 +414,8 @@ public class MethodHandles {
try {
Object element = classdata.get(index);
return BootstrapMethodInvoker.widenAndCast(element, type);
-} catch
(ClassCastException|NullPointerException|IndexOutOfBoundsException e) {
-throw e;
+} catch (RuntimeException|Error e) {
+throw e; // let specified exceptions and other runtime
exceptions/errors through
} catch (Throwable e) {
throw new InternalError(e);
}
> test/jdk/java/lang/invoke/MethodHandles/classData/ClassDataTest.java line 77:
>
>> 75: */
>> 76: @Test
>> 77: public void noClassData() throws Throwable {
>
> `throws Throwable` needed on this and other method declarations?
`noClassData` only needs `IllegalACcessException`. `assertClassData` throws
Throwable because it unwraps from `InvocationTargetException`. I can take a
pass to clean this up further.
-
PR: https://git.openjdk.java.net/jdk/pull/1171
RFR: 8256480: Refactor ObjectInputStream field reader implementation
ObjectInputStream has nearly identical but separate implementations to read values from the stream. Both implementations read primitive and object values from the stream and return an object holding the values. OIS.readFields() uses the internal class GetFieldImpl while OIS.defaultReadObject and reading records uses the internal class FieldValues. The behavioral difference between the two is whether dependencies are tracked in the object handle table or not. The classes are merged, retaining the internal FieldValues name and the behavior to track dependencies or not. The constructor is passed the class descriptor and flag to track or not; it reads and saves the values from the stream. The callers are updated to call the merge FieldValues methods. There is no change in behavior; all current tests pass. - Commit messages: - 8256480: Refactor ObjectInputStream field reader implementation Changes: https://git.openjdk.java.net/jdk/pull/1296/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1296=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256480 Stats: 157 lines in 1 file changed: 26 ins; 78 del; 53 mod Patch: https://git.openjdk.java.net/jdk/pull/1296.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1296/head:pull/1296 PR: https://git.openjdk.java.net/jdk/pull/1296
Re: RFR: 8230501: Class data support for hidden classes [v4]
On Wed, 18 Nov 2020 00:50:22 GMT, Mandy Chung wrote: >> Provide the `Lookup::defineHiddenClassWithClassData` API that allows live >> objects >> be shared between a hidden class and other classes. A hidden class can load >> these live objects as dynamically-computed constants via this API. >> >> Specdiff >> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/overview-summary.html >> >> With this class data support and hidden classes, >> `sun.misc.Unsafe::defineAnonymousClass` >> will be deprecated for removal. Existing libraries should replace their >> calls to `sun.misc.Unsafe::defineAnonymousClass` with >> `Lookup::defineHiddenClass` >> or `Lookup::defineHiddenClassWithClassData`. >> >> This patch also updates the implementation of lambda meta factory and >> `MemoryAccessVarHandleGenerator` to use class data. No performance >> difference >> observed in the jdk.incubator.foreign microbenchmarks. A side note: >> `MemoryAccessVarHandleGenerator` is removed in the upcoming integration of >> JDK-8254162 but it helps validating the class data support. >> >> Background >> -- >> >> This is an enhancement following up JEP 371: Hidden Classes w.r.t. >> "Constant-pool patching" in the "Risks and Assumption" section. >> >> A VM-anonymous class can be defined with its constant-pool entries already >> resolved to concrete values. This allows critical constants to be shared >> between a VM-anonymous class and the language runtime that defines it, and >> between multiple VM-anonymous classes. For example, a language runtime will >> often have `MethodHandle` objects in its address space that would be useful >> to newly-defined VM-anonymous classes. Instead of the runtime serializing >> the objects to constant-pool entries in VM-anonymous classes and then >> generating bytecode in those classes to laboriously `ldc` the entries, >> the runtime can simply supply `Unsafe::defineAnonymousClass` with references >> to its live objects. The relevant constant-pool entries in the newly-defined >> VM-anonymous class are pre-linked to those objects, improving performance >> and reducing footprint. In addition, this allows VM-anonymous classes to >> refer to each other: Constant-pool entries in a class file are based on >> names. >> They thus cannot refer to nameless VM-anonymous classes. A language runtime >> can, >> however, easily track the live Class objects for its VM-anonymous classes and >> supply them to `Unsafe::defineAnonymousClass`, thus pre-linking the new >> class's >> constant pool entries to other VM-anonymous classes. >> >> This extends the hidden classes to allow live objects to be injected >> in a hidden class and loaded them via condy. >> >> Details >> --- >> >> A new `Lookup::defineHiddenClassWithClassData` API takes additional >> `classData` argument compared to `Lookup::defineHiddenClass`. >> Class data can be method handles, lookup objects, arbitrary user objects >> or collections of all of the above. >> >> This method behaves as if calling `Lookup::defineHiddenClass` to define >> a hidden class with a private static unnamed field that is initialized >> with `classData` at the first instruction of the class initializer. >> >> `MethodHandles::classData(Lookup lookup, String name, Class type)` and >> `MethodHandles::classDataAt(Lookup lookup, String name, Class type, int >> index)` >> are the bootstrap methods to load the class data of the given lookup's >> lookup class. >> The hidden class will be initialized when `classData` method is called if >> the hidden class has not been initialized. >> >> For a class data containing more than one single element, libraries can >> create their convenience method to load a single live object via condy. >> >> Frameworks sometimes want to dynamically create a hidden class (HC) and add >> it >> it the lookup class nest and have HC to carry secrets hidden from that nest. >> In this case, frameworks should not to use private static finals (in the HCs >> they spin) to hold secrets because a nestmate of HC may obtain access to >> such a private static final and observe the framework's secret. It should >> use >> condy. In addition, we need to differentiate if a lookup object is created >> from >> the original lookup class or created from teleporting e.g. `Lookup::in` >> and `MethodHandles::privateLookupIn`. >> >> This proposes to add a new `ORIGINAL` bit that is only set if the lookup >> object is created by `MethodHandles::lookup` or by bootstrap method >> invocation. >> The operations only apply to a Lookup object with original access are: >>- create method handles for caller-sensitve methods >>- obtain class data associated with the lookup class >> >> No change to `Lookup::hasFullPrivilegeAccess` and `Lookup::toString` which >> ignores the ORIGINAL bit. >> >> >> Compatibility Risks >> --- >> >> `Lookup::lookupModes` includes a new `ORIGINAL` bit. Most lookup operations >> ignore this
Re: RFR: 8256152: tests fail because of ambiguous method resolution [v2]
On Tue, 17 Nov 2020 23:34:23 GMT, Stuart Marks wrote: >> Added a cast in the right place, thanks to @jonathan-gibbons. > > Stuart Marks has updated the pull request incrementally with one additional > commit since the last revision: > > cast to double instead of Object Marked as reviewed by psandoz (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1274
Re: RFR: 8247402: Documentation for Map::compute contains confusing implementation requirements
On Wed, 21 Oct 2020 00:11:42 GMT, John Lin wrote: >> Hi Jon, >> >> Can you explain what this change is about: e.g. something like: >> >>> Updates the documentation of `Map::compute` to match its default >>> implementation: >>> The documentation of the default implementation of `Map::compute` was both >>> wrong and confusing. >>> This change updates the documentation to match the behaviour of the >>> implementation. >> >> because now I am confused. I believe what you are trying to do is what I >> have written above. Can you confirm? >> This will need a CSR. >> >> And are you going to withdraw https://github.com/openjdk/jdk/pull/451 now? >> >> best regards, >> -- daniel > > @dfuch May I ask how can I create a CSR? I checked > https://wiki.openjdk.java.net/display/csr/CSR+FAQs and it says: > >> Q: How do I create a CSR ? >> A: Do not directly create a CSR from the Create Menu. JIRA will let you do >> this right up until the moment you try to save it and find your typing was >> in vain. >> Instead you should go to the target bug, select "More", and from the drop >> down menu select "Create CSR". This is required to properly associate the >> CSR with the main bug, just as is done for backports. > > However, I don't have an account at https://bugs.openjdk.java.net/ yet. > Therefore, I don't see the "More" button on > https://bugs.openjdk.java.net/browse/JDK-8247402. Could you please tell me > how do I proceed? Thank you. @johnlinp, you cannot create a CSR by yourself at the moment. Someone else will have to do that for you. Might as well be me. So here's my proposal: come up with the meat, then I'll help you with the paperwork. For starters, have a look at existing CSRs (you don't need a JBS account for that). For example, https://bugs.openjdk.java.net/issues/?jql=issuetype%3DCSR%20and%20Subcomponent%3Djava.util%3Acollections%20 Fill in an informal CSR template inline in this thread, and we'll proceed from that point. Is that okay? - PR: https://git.openjdk.java.net/jdk/pull/714
RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html old PR: https://github.com/openjdk/jdk/pull/1273 - Commit messages: - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862; Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - ... and 15 more: https://git.openjdk.java.net/jdk/compare/f7517386...2b3e4ed7 Changes: https://git.openjdk.java.net/jdk/pull/1292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1292=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248862 Stats: 13319 lines in 25 files changed: 0 ins; 2132 del; 77 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292
Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]
On Wed, 18 Nov 2020 13:18:30 GMT, Jim Laskey wrote: >> I am unsure if the intent is also to support external libraries providing >> `RandomGenerator` implementations. Currently there is an implicit contract >> for properties (reflectively invoking a method returning a map with a set of >> entries with known keys). Since the service provider implementation is the >> `RandomGenerator` itself, rather than `RandomGeneratorFactory` it is harder >> expose the meta-data with a clearer contract. > > Need rebase Created new PR because of forced push: https://github.com/openjdk/jdk/pull/1292 - PR: https://git.openjdk.java.net/jdk/pull/1273
Re: RFR: 8251317: Support for CLDR version 38
On Tue, 17 Nov 2020 23:19:23 GMT, Naoto Sato wrote: > Hi, > > Please review the changes for upgrading the CLDR data to version 38. The vast > majority of the changes are simply the changes in CLDR upstream, and others > are mainly test changes due to the locale data change. Looks fine from a build point of view. - Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1279
Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]
On Wed, 18 Nov 2020 00:51:43 GMT, Paul Sandoz wrote: >> Jim Laskey has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 40 commits: >> >> - Merge branch 'master' into 8248862 >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >>Update package-info.java >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >>Updated RandomGeneratorFactory javadoc. >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >>Updated documentation for RandomGeneratorFactory. >> - Merge branch 'master' into 8248862 >> - Merge branch 'master' into 8248862 >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >>Move RandomGeneratorProperty >> - Merge branch 'master' into 8248862 >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >>Clear up javadoc >> - 8248862; Implement Enhanced Pseudo-Random Number Generators >> >>remove RandomGeneratorProperty from API >> - ... and 30 more: >> https://git.openjdk.java.net/jdk/compare/f7517386...6fe94c68 > > I am unsure if the intent is also to support external libraries providing > `RandomGenerator` implementations. Currently there is an implicit contract > for properties (reflectively invoking a method returning a map with a set of > entries with known keys). Since the service provider implementation is the > `RandomGenerator` itself, rather than `RandomGeneratorFactory` it is harder > expose the meta-data with a clearer contract. Need rebase - PR: https://git.openjdk.java.net/jdk/pull/1273
Withdrawn: 8248862: Implement Enhanced Pseudo-Random Number Generators
On Tue, 17 Nov 2020 19:58:47 GMT, Jim Laskey wrote: > This PR is to introduce a new random number API for the JDK. The primary API > is found in RandomGenerator and RandomGeneratorFactory. Further description > can be found in the JEP https://openjdk.java.net/jeps/356 . This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/1273
Re: RFR: 8180352: Add Stream.toList() method [v2]
- Mail original - > De: "Florian Weimer" > À: "Peter Levart" > Cc: "Stuart Marks" , "core-libs-dev" > > Envoyé: Mercredi 18 Novembre 2020 12:55:02 > Objet: Re: RFR: 8180352: Add Stream.toList() method [v2] > * Peter Levart: > >> But I see that the new IMM_LIST_NULLS type is needed for one other >> thing - the immutable list implementation of that type has different >> behavior of indexOf and lastIndexOf methods (it doesn't throw NPE when >> null is passed to those methods) so this behavior has to be preserved in >> the deserialized instance and there is not way to achieve that on old >> JDK with existing serialization format, so there has to be an >> incompatible change in the serialization format for that matter. > > I think it's also needed for an efficient null element check in > List::copyOf. I have a hunch that with the posted implementation, it > would incorrectly produce an immutable list that contains null > elements. yes ! Rémi
Re: RFR: 8180352: Add Stream.toList() method [v2]
* Peter Levart: > But I see that the new IMM_LIST_NULLS type is needed for one other > thing - the immutable list implementation of that type has different > behavior of indexOf and lastIndexOf methods (it doesn't throw NPE when > null is passed to those methods) so this behavior has to be preserved in > the deserialized instance and there is not way to achieve that on old > JDK with existing serialization format, so there has to be an > incompatible change in the serialization format for that matter. I think it's also needed for an efficient null element check in List::copyOf. I have a hunch that with the posted implementation, it would incorrectly produce an immutable list that contains null elements.
Re: RFR: 8180352: Add Stream.toList() method [v2]
On 11/17/20 9:08 PM, Stuart Marks wrote: @plevart wrote: Yes, but that is JDK16+ vs. JDK15- and not App V1 vs. App V2 thing. If both apps run on JDK16+, there will be no exception. Sure, the IMM_LIST_NULLS tag only helps with serialization compatibility across JDK releases. I would say it goes the other way - it worsens the serialization compatibility. You are introducing a serialization format that is incompatible with older JDK releases. OTOH the problem of introducing nulls into List(s) in serializable data structures already exists because serializable List implementations that allow nulls already exist, so by introducing another one that is able to be deserialized on older JDK would not worsen the situation. There are lots of ways an app can make incompatible changes to the serialized forms of its objects that we have no way of detecting. So why bother with making the result of serialized stream.toList() not de-serializable on older JDK(s)? By making a favor to a hypothetical app that runs on older JDK and does not expect nulls in Lists of a data structure, you are also preventing an app that allows nulls in similar data structure from deserializing the datastructure on older JDK when the serialized form was produced with serializing stream.toList() on newer JDK. But I see that the new IMM_LIST_NULLS type is needed for one other thing - the immutable list implementation of that type has different behavior of indexOf and lastIndexOf methods (it doesn't throw NPE when null is passed to those methods) so this behavior has to be preserved in the deserialized instance and there is not way to achieve that on old JDK with existing serialization format, so there has to be an incompatible change in the serialization format for that matter. Peter
Re: RFR: 8256477: Specialize heap memory segment implementations [v2]
On Wed, 18 Nov 2020 10:08:20 GMT, Maurizio Cimadamore wrote: >> The current memory segment implementation defines a hierarchy with 3 >> concrete classes: one for heap segments, one for native segments and one for >> mapped segments. >> >> Since there can be many kinds of heap segments (e.g. created from a byte[] >> or from a float[]) the current implementation is prone to type profile >> pollution problems: if enough heap segments are created (of different >> kinds), the JIT compiler will give up on speculating on the heap segment >> kind, which will then result in poor performances. >> >> This issue can be reproduced in one of the existing benchmark, by adding >> some initialization code which is enough to pollute the types profiles. When >> that happens, performance numbers look like the following: >> >> Benchmark (polluteProfile) Mode Cnt Score >> Error Units >> LoopOverNonConstantHeap.segment_loop false avgt 10 0.285 ± >> 0.003 ms/op >> LoopOverNonConstantHeap.segment_loop true avgt 10 5.540 ± >> 0.143 ms/op >> >> (Thanks to Vlad for coming up for the exact incantation which leads to >> profile pollution :-) ) >> >> The solution is to create a sharp subclass for each heap segment case. With >> this, C2 has always a sharp Unsafe *base* to work with, and performances are >> stable regardless of profile pollution attempts. >> >> This patch also tweaks the benchmark for heap segments so that it checks it >> with and without profile pollution. > > Maurizio Cimadamore has updated the pull request incrementally with one > additional commit since the last revision: > > Fix typo Marked as reviewed by sundar (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1259
Integrated: 8256477: Specialize heap memory segment implementations
On Tue, 17 Nov 2020 14:55:07 GMT, Maurizio Cimadamore wrote: > The current memory segment implementation defines a hierarchy with 3 concrete > classes: one for heap segments, one for native segments and one for mapped > segments. > > Since there can be many kinds of heap segments (e.g. created from a byte[] or > from a float[]) the current implementation is prone to type profile pollution > problems: if enough heap segments are created (of different kinds), the JIT > compiler will give up on speculating on the heap segment kind, which will > then result in poor performances. > > This issue can be reproduced in one of the existing benchmark, by adding some > initialization code which is enough to pollute the types profiles. When that > happens, performance numbers look like the following: > > Benchmark (polluteProfile) Mode Cnt Score > Error Units > LoopOverNonConstantHeap.segment_loop false avgt 10 0.285 ± > 0.003 ms/op > LoopOverNonConstantHeap.segment_loop true avgt 10 5.540 ± > 0.143 ms/op > > (Thanks to Vlad for coming up for the exact incantation which leads to > profile pollution :-) ) > > The solution is to create a sharp subclass for each heap segment case. With > this, C2 has always a sharp Unsafe *base* to work with, and performances are > stable regardless of profile pollution attempts. > > This patch also tweaks the benchmark for heap segments so that it checks it > with and without profile pollution. This pull request has now been integrated. Changeset: d2ddf074 Author:Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/d2ddf074 Stats: 187 lines in 4 files changed: 140 ins; 4 del; 43 mod 8256477: Specialize heap memory segment implementations Reviewed-by: jvernee, chegar - PR: https://git.openjdk.java.net/jdk/pull/1259
Re: RFR: 8256477: Specialize heap memory segment implementations [v2]
> The current memory segment implementation defines a hierarchy with 3 concrete > classes: one for heap segments, one for native segments and one for mapped > segments. > > Since there can be many kinds of heap segments (e.g. created from a byte[] or > from a float[]) the current implementation is prone to type profile pollution > problems: if enough heap segments are created (of different kinds), the JIT > compiler will give up on speculating on the heap segment kind, which will > then result in poor performances. > > This issue can be reproduced in one of the existing benchmark, by adding some > initialization code which is enough to pollute the types profiles. When that > happens, performance numbers look like the following: > > Benchmark (polluteProfile) Mode Cnt Score > Error Units > LoopOverNonConstantHeap.segment_loop false avgt 10 0.285 ± > 0.003 ms/op > LoopOverNonConstantHeap.segment_loop true avgt 10 5.540 ± > 0.143 ms/op > > (Thanks to Vlad for coming up for the exact incantation which leads to > profile pollution :-) ) > > The solution is to create a sharp subclass for each heap segment case. With > this, C2 has always a sharp Unsafe *base* to work with, and performances are > stable regardless of profile pollution attempts. > > This patch also tweaks the benchmark for heap segments so that it checks it > with and without profile pollution. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix typo - Changes: - all: https://git.openjdk.java.net/jdk/pull/1259/files - new: https://git.openjdk.java.net/jdk/pull/1259/files/2366b69e..e892bc75 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1259=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1259=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1259.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1259/head:pull/1259 PR: https://git.openjdk.java.net/jdk/pull/1259
Re: RFR: 8256189: Exact VarHandle tests should test withInvokeBehavior() works as expected
On Tue, 17 Nov 2020 18:32:30 GMT, Jorn Vernee wrote: > This PR sharpens the testing done by > test/jdk/java/lang/invoke/VarHandles/VarHandleTestExact.java after > @mcimadamore reported that the test was not catching an issue with memory > access var handles; namely that the implementation of withInvokeBehavior was > incorrect. > > After some debugging it turned out that the test never actually tested: > (1) going back to invoke behavior from a var handle with invoke exact behavior > (2) the memory access handle implementation of withInvoke(Exact)Behavior, due > to memory handles always being adapted. > > The patch adds testing for (1), and adds a flag to jdk.internal.foreign.Utils > to turn off the adaptation, so that we can test the 'naked' memory access var > handles as well for (2). > > I've also tried to reduce some of the code duplication by creating the higher > order doTest function, that does most of the testing (besides setting up var > handles and test values). Marked as reviewed by chegar (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1267
Re: RFR: 8256477: Specialize heap memory segment implementations
On Tue, 17 Nov 2020 14:55:07 GMT, Maurizio Cimadamore
wrote:
> The current memory segment implementation defines a hierarchy with 3 concrete
> classes: one for heap segments, one for native segments and one for mapped
> segments.
>
> Since there can be many kinds of heap segments (e.g. created from a byte[] or
> from a float[]) the current implementation is prone to type profile pollution
> problems: if enough heap segments are created (of different kinds), the JIT
> compiler will give up on speculating on the heap segment kind, which will
> then result in poor performances.
>
> This issue can be reproduced in one of the existing benchmark, by adding some
> initialization code which is enough to pollute the types profiles. When that
> happens, performance numbers look like the following:
>
> Benchmark (polluteProfile) Mode Cnt Score
> Error Units
> LoopOverNonConstantHeap.segment_loop false avgt 10 0.285 ±
> 0.003 ms/op
> LoopOverNonConstantHeap.segment_loop true avgt 10 5.540 ±
> 0.143 ms/op
>
> (Thanks to Vlad for coming up for the exact incantation which leads to
> profile pollution :-) )
>
> The solution is to create a sharp subclass for each heap segment case. With
> this, C2 has always a sharp Unsafe *base* to work with, and performances are
> stable regardless of profile pollution attempts.
>
> This patch also tweaks the benchmark for heap segments so that it checks it
> with and without profile pollution.
Marked as reviewed by chegar (Reviewer).
src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/HeapMemorySegmentImpl.java
line 44:
> 42: * sharp type information, as well as sharp null-check information. For
> this reason, many concrete subclasses
> 43: * of {@link HeapMemorySegmentImpl} are defined (e.g. {@link OfFloat}, so
> that each subclass can override the
> 44: * {@link HeapMemorySegmentImpl#base()} method so that it returns an
> array ogf the correct (sharp) type.
minor typo "ogf" -> "of"
-
PR: https://git.openjdk.java.net/jdk/pull/1259
