Re: RFR: 8285440: Typo in Collections.addAll method javadoc
On Fri, 22 Apr 2022 08:04:09 GMT, Johnny Lim wrote: >> Hello @izeye, I've created a JBS issue for this change >> https://bugs.openjdk.java.net/browse/JDK-8285440. Please edit the title of >> this PR to "8285440: Typo in Collections.addAll method javadoc" so that it >> triggers the workflow of the official review process. > > @jaikiran Thanks! I updated the title as you guided. @izeye, this is now ready for integration. You will have to add a comment to this PR which says `/integrate`, after which I can sponsor this change to have it merged. - PR: https://git.openjdk.java.net/jdk/pull/6942
Re: RFR: 8285485: Fix typos in corelibs
On Fri, 22 Apr 2022 15:08:51 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on modules owned by core-libs, and accepted those changes > where it indeed discovered real typos. > > I will update copyright years using a script before pushing (otherwise like > every second change would be a copyright update, making reviewing much > harder). > > The long term goal here is to make tooling support for running `codespell`. > The trouble with automating this is of course all false positives. But before > even trying to solve that issue, all true positives must be fixed. Hence this > PR. LGTM src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 188: > 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757 > 187: > 188: main.plugin.category=\u7C7B\u522B what's this? - Marked as reviewed by sundar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8364
Re: RFR: 8285485: Fix typos in corelibs
On Fri, 22 Apr 2022 15:08:51 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on modules owned by core-libs, and accepted those changes > where it indeed discovered real typos. > > I will update copyright years using a script before pushing (otherwise like > every second change would be a copyright update, making reviewing much > harder). > > The long term goal here is to make tooling support for running `codespell`. > The trouble with automating this is of course all false positives. But before > even trying to solve that issue, all true positives must be fixed. Hence this > PR. Looks fine to me. - Marked as reviewed by jpai (Committer). PR: https://git.openjdk.java.net/jdk/pull/8364
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7]
On Tue, 26 Apr 2022 18:58:23 GMT, Daniel Fuchs wrote:
>> Alan Bateman has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
>
> src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java line 770:
>
>> 768: synchronized (p) {
>> 769: DatagramPackets.setLength(p, n);
>> 770: p.setSocketAddress(sender);
>
> Hmmm... For integrity it might be better to call the public
> `DatagramPacket::setData(byte[] buf, int offset, int length)` method here
> now. The additional advantage is that the private access to
> `DatagramPackets.setLength(p, n);` will no longer be needed.
DatagramPackets.setLength is not really new, it's just moved. There's a flaw in
DatagramPacket that forces its usage - the details are in JDK-8232817.
-
PR: https://git.openjdk.java.net/jdk/pull/8166
Re: RFR: 8285295: Need better testing for IdentityHashMap
On Wed, 27 Apr 2022 03:11:58 GMT, liach wrote:
>> Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch
>> in the bug report that breaks `IdentityHashMap` now causes several cases in
>> this new test to fail. There's more that could be done, but the new tests
>> cover most of the core functions of `IdentityHashMap`. Unfortunately it
>> seems difficult to merge this with the existing, comprehensive Collections
>> tests (e.g., MOAT.java) because those tests implicity rely on
>> `equals()`-based contract instead of the special-purpose `==`-based contract
>> used by `IdentityHashMap`.
>
> test/jdk/java/util/IdentityHashMap/Basic.java line 75:
>
>> 73: private void checkContents(Collection c, BiPredicate p,
>> E... given) {
>> 74: @SuppressWarnings("unchecked")
>> 75: E[] contents = (E[]) c.toArray();
>
> Maybe worthy to note that entry set toArray may return entries different from
> what the iterator returns, and some predicates may thus fail.
Yeah I could add a note to caution against checking identity of `Entry`
instances. That doesn't occur anywhere in these tests, does it?
> test/jdk/java/util/IdentityHashMap/Basic.java line 77:
>
>> 75: E[] contents = (E[]) c.toArray();
>> 76:
>> 77: assertEquals(c.size(), given.length);
>
> I believe testng has the expected values in front in the `assertEquals`
> methods, as embodied in the exception messages, so this should be
> `assertEquals(given.length, c.size());`. Applies to other places.
No, TestNG is `assertEquals(actual, expected)` which is irritatingly the
opposite of JUnit.
https://github.com/cbeust/testng/blob/master/testng-asserts/src/main/java/org/testng/asserts/Assertion.java#L151
This will make things quite tedious when/if we convert to JUnit.
-
PR: https://git.openjdk.java.net/jdk/pull/8354
Re: RFR: 8285295: Need better testing for IdentityHashMap
On Fri, 22 Apr 2022 03:37:27 GMT, Stuart Marks wrote: > Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch > in the bug report that breaks `IdentityHashMap` now causes several cases in > this new test to fail. There's more that could be done, but the new tests > cover most of the core functions of `IdentityHashMap`. Unfortunately it seems > difficult to merge this with the existing, comprehensive Collections tests > (e.g., MOAT.java) because those tests implicity rely on `equals()`-based > contract instead of the special-purpose `==`-based contract used by > `IdentityHashMap`. Probably the same file. It would be nice to be able to re-use some general Set and Collection tests, but the identity semantics make this difficult to do without extensive refactoring. ** Oh wait, `removeAll` and `retainAll` use the membership contract of the argument, not those of this collection. The current keySet/values/entrySet tests test `toArray` and `contains`, which seems almost sufficient. Well, maybe tests for `remove` on these view collections would be helpful, but I think that's about it. - PR: https://git.openjdk.java.net/jdk/pull/8354
Re: RFR: 8285295: Need better testing for IdentityHashMap
On Fri, 22 Apr 2022 03:37:27 GMT, Stuart Marks wrote:
> Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch
> in the bug report that breaks `IdentityHashMap` now causes several cases in
> this new test to fail. There's more that could be done, but the new tests
> cover most of the core functions of `IdentityHashMap`. Unfortunately it seems
> difficult to merge this with the existing, comprehensive Collections tests
> (e.g., MOAT.java) because those tests implicity rely on `equals()`-based
> contract instead of the special-purpose `==`-based contract used by
> `IdentityHashMap`.
Just curious, will entrySet/keySet/values tests be here or in a separate file?
They are identity-based collections as well, as shown by their
contains/removeAll/retainAll.
test/jdk/java/util/IdentityHashMap/Basic.java line 75:
> 73: private void checkContents(Collection c, BiPredicate p,
> E... given) {
> 74: @SuppressWarnings("unchecked")
> 75: E[] contents = (E[]) c.toArray();
Maybe worthy to note that entry set toArray may return entries different from
what the iterator returns, and some predicates may thus fail.
test/jdk/java/util/IdentityHashMap/Basic.java line 77:
> 75: E[] contents = (E[]) c.toArray();
> 76:
> 77: assertEquals(c.size(), given.length);
I believe testng has the expected values in front in the `assertEquals`
methods, as embodied in the exception messages, so this should be
`assertEquals(given.length, c.size());`. Applies to other places.
-
PR: https://git.openjdk.java.net/jdk/pull/8354
RFR: 8285295: Need better testing for IdentityHashMap
Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch in the bug report that breaks `IdentityHashMap` now causes several cases in this new test to fail. There's more that could be done, but the new tests cover most of the core functions of `IdentityHashMap`. Unfortunately it seems difficult to merge this with the existing, comprehensive Collections tests (e.g., MOAT.java) because those tests implicity rely on `equals()`-based contract instead of the special-purpose `==`-based contract used by `IdentityHashMap`. - Commit messages: - Refactor contents checking to use checkElements() and checkEntries(). - Rename some tests. - Rename isIdenticalEntry to hasIdenticalKeyValue. - Finish writing all pending tests except remove(k,v) and replace(k,v1,v2). - Some cleanup and more tests. - Initial cut at IdentityHashMap tests. Changes: https://git.openjdk.java.net/jdk/pull/8354/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8354&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285295 Stats: 546 lines in 1 file changed: 546 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8354.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8354/head:pull/8354 PR: https://git.openjdk.java.net/jdk/pull/8354
Re: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces
On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy wrote:
> To enable more complete doclint checking (courtesy @jonathan-gibbons), please
> review this PR to add type-level @param tags where they are missing.
>
> To the maintainers of java.util.concurrent, those changes could be separated
> out in another bug if that would ease maintenance of that code.
>
> Making these library fixes is a blocker for correcting and expanding the
> doclint checks (JDK-8285496).
>
> I'll update copyright years before pushing.
I've looked at the changes in java.util (but not sub packages). They're fine,
modulo some minor wording changes.
src/java.base/share/classes/java/util/AbstractMap.java line 601:
> 599: * {@code Map.entrySet().toArray}.
> 600: *
> 601: * @param the type of keys maintained
Please update to match java.util.Map, which says "the type of keys maintained
by this map"
src/java.base/share/classes/java/util/AbstractMap.java line 748:
> 746: *
> 747: * @param the type of keys maintained
> 748: * @param the type of mapped values
Please update to match Map.Entry, which says simply "the type of key" and "the
type of the value"
src/java.base/share/classes/java/util/Dictionary.java line 44:
> 42: * @param the type of keys
> 43: * @param the type of mapped values
> 44: *
Urgh. This class is obsolete, but it was retrofitted to implement Map and was
subsequently generified, so I'd update these to match java.util.Map.
-
Marked as reviewed by smarks (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/8410
Re: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces
On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy wrote:
> To enable more complete doclint checking (courtesy @jonathan-gibbons), please
> review this PR to add type-level @param tags where they are missing.
>
> To the maintainers of java.util.concurrent, those changes could be separated
> out in another bug if that would ease maintenance of that code.
>
> Making these library fixes is a blocker for correcting and expanding the
> doclint checks (JDK-8285496).
>
> I'll update copyright years before pushing.
src/java.base/share/classes/java/lang/ClassValue.java line 43:
> 41: * it can use a {@code ClassValue} to cache information needed to
> 42: * perform the message send quickly, for each class encountered.
> 43: * @param type of the derived value
stylistically, compared to other comments, you are missing an initial "the"
-
PR: https://git.openjdk.java.net/jdk/pull/8410
Re: RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces
On Tue, 26 Apr 2022 22:24:26 GMT, Joe Darcy wrote: > To enable more complete doclint checking (courtesy @jonathan-gibbons), please > review this PR to add type-level @param tags where they are missing. > > To the maintainers of java.util.concurrent, those changes could be separated > out in another bug if that would ease maintenance of that code. > > Making these library fixes is a blocker for correcting and expanding the > doclint checks (JDK-8285496). > > I'll update copyright years before pushing. The two `java.security` ones LGTM. - Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8410
RFR: JDK-8285676: Add missing @param tags for type parameters on classes and interfaces
To enable more complete doclint checking (courtesy @jonathan-gibbons), please review this PR to add type-level @param tags where they are missing. To the maintainers of java.util.concurrent, those changes could be separated out in another bug if that would ease maintenance of that code. Making these library fixes is a blocker for correcting and expanding the doclint checks (JDK-8285496). I'll update copyright years before pushing. - Commit messages: - JDK-8285676: Add missing @param tags for type parameters on classes and interfaces Changes: https://git.openjdk.java.net/jdk/pull/8410/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8410&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285676 Stats: 76 lines in 40 files changed: 76 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8410.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8410/head:pull/8410 PR: https://git.openjdk.java.net/jdk/pull/8410
Re: RFR: JDK-8236128: Allow jpackage create installers for services [v2]
On Thu, 14 Apr 2022 21:04:52 GMT, Alexey Semenyuk wrote: >> Implementation of [JDK-8275062: "Allow jpackage create installers for >> services"](https://bugs.openjdk.java.net/browse/JDK-8275062) >> CSR > > Alexey Semenyuk has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 121 commits: > > - Merge branch 'master' into JDK-8236128 > - Whitespace cleanup > - Whitespace cleanup > - JDK-8236128: Allow jpackage create installers for services > - Sync l10n files. Fix copyright year > - Minor formatting fix > - Merge fix > - Merge fixed > - Merge branch 'master' into JDK-8236128 > - Merge branch 'JDK-8236128' of https://github.com/alexeysemenyukoracle/jdk > into JDK-8236128 > - ... and 111 more: > https://git.openjdk.java.net/jdk/compare/f4edb59a...1a3d7cf5 Approved - PR: https://git.openjdk.java.net/jdk/pull/7793
Re: RFR: 8284992: Fix misleading Vector API doc for LSHR operator [v2]
On Thu, 21 Apr 2022 04:23:22 GMT, Jie Fu wrote:
>> Hi all,
>>
>> The Current Vector API doc for `LSHR` is
>>
>> Produce a>>>(n&(ESIZE*8-1)). Integral only.
>>
>>
>> This is misleading which may lead to bugs for Java developers.
>> This is because for negative byte/short elements, the results computed by
>> `LSHR` will be different from that of `>>>`.
>> For more details, please see
>> https://github.com/openjdk/jdk/pull/8276#issue-1206391831 .
>>
>> After the patch, the doc for `LSHR` is
>>
>> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral
>> only.
>>
>>
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu 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 since
> the last revision:
>
> - Address review comments
> - Merge branch 'master' into JDK-8284992
> - 8284992: Fix misleading Vector API doc for LSHR operator
After talking with John here's what we think is a better approach than what I
originally had in mind:
1. In the class doc of `VectorOperators` add a definition for `EMASK` occurring
after the definition for `ESIZE`:
* {@code EMASK} — the bit mask of the operand type, where {@code
EMASK=(1<>>(n&(ESIZE*8-1))}. Integral only. */
That more clearly gets across operating in the correct domain for sub-word
operand types, which was the original intention (e.g. the right shift value).
-
PR: https://git.openjdk.java.net/jdk/pull/8291
Re: RFR: 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
On Sun, 24 Apr 2022 09:18:54 GMT, Ichiroh Takiguchi
wrote:
> On JDK19 with Linux ja_JP.eucjp locale,
> System.getenv() returns unexpected value if environment variable has Japanese
> EUC characters.
> It seems this issue happens because of JEP 400.
> Arguments for ProcessBuilder have same kind of issue.
Thanks for fixing the issue.
As to the test, it has lots of redundancy, and too complicated to me. Can you
simplify the test?
src/java.base/unix/classes/java/lang/ProcessImpl.java line 146:
> 144: private static final LaunchMechanism launchMechanism =
> platform.launchMechanism();
> 145: private static final byte[] helperpath =
> toCString(StaticProperty.javaHome() + "/lib/jspawnhelper");
> 146: private static Charset jnuCharset = null;
Can we simply call `jnuCharset()` here?
test/jdk/java/lang/ProcessBuilder/Basic.java line 605:
> 603: String fileEncoding = System.getProperty("file.encoding");
> 604: Charset cs;
> 605: if (nativeEncoding != null &&
> !nativeEncoding.equals(fileEncoding)) {
What's the reason for comparing `file.encoding`? Does
`Charset.forName(nativeEncoding, Charset.defaultCharset())` suffice?
test/jdk/java/lang/System/i18nEnvArg.java line 26:
> 24: /*
> 25: * @test
> 26: * @bug 8285517
If the test should work only on a particular env, should describe here and add
`@requires` tag.
test/jdk/java/lang/System/i18nEnvArg.java line 50:
> 48:
> 49: public static void main(String[] args) throws Exception {
> 50: ProcessBuilder pb = new ProcessBuilder(javeExe,
Can utilize `jdk.test.lib.process.ProcessTools`.
-
PR: https://git.openjdk.java.net/jdk/pull/8378
Re: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v3]
On Thu, 10 Mar 2022 08:52:17 GMT, Сергей Цыпанов wrote: >> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with >> smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when >> called with vararg of size 0, 1, 2. >> >> In general replacement of `Arrays.asList()` with `List.of()` is dubious as >> the latter is null-hostile, however in some cases we are sure that arguments >> are non-null. Into this PR I've included the following cases (in addition to >> those where the argument is proved to be non-null at compile-time): >> - `MethodHandles.longestParameterList()` never returns null >> - parameter types are never null >> - interfaces used for proxy construction and returned from >> `Class.getInterfaces()` are never null >> - exceptions types of method signature are never null > > Сергей Цыпанов has updated the pull request incrementally with one additional > commit since the last revision: > > 8282662: Revert dubious changes in MethodType Let's wait a bit - PR: https://git.openjdk.java.net/jdk/pull/7729
Re: RFR: 8285633: Take better advantage of generic MethodType cache [v2]
On Tue, 26 Apr 2022 19:30:31 GMT, Jorn Vernee wrote: >> Right.. I did a quick experiment and there's a large speed-up in the trivial >> `methodType(obj, obj)` case: >> >> Benchmark Mode Cnt Score Error >> Units >> MethodTypeAcquire.testObjectObjectNonConstant avgt5 30.052 ? 3.440 >> ns/op # baseline >> MethodTypeAcquire.testObjectObjectNonConstant avgt5 1.171 ? 0.001 >> ns/op # patch >> >> >> I'll add a non-constant variant for the multi-arg Object variants, too. It >> should scale linearly and see a gain in the same ballpark. I think we need >> to keep the number of microbenchmarks here somewhat under control, though. > > That sounds good, thanks Added 3 micros I think carry their own weight as they assess some different major pathways through the caching fast-path. Baseline: Benchmark Mode Cnt Score Error Units MethodTypeAcquire.testMultiPType_ObjectAndA_NonConst avgt 15 63.523 ? 2.452 ns/op MethodTypeAcquire.testMultiPType_ObjectOnly_NonConst avgt 15 57.770 ? 0.501 ns/op MethodTypeAcquire.testObjectObject_NonConst avgt 15 30.090 ? 0.251 ns/op Patched: Benchmark Mode Cnt Score Error Units MethodTypeAcquire.testMultiPType_ObjectAndA_NonConst avgt 15 64.570 ? 0.410 ns/op MethodTypeAcquire.testMultiPType_ObjectOnly_NonConst avgt 15 4.735 ? 0.063 ns/op MethodTypeAcquire.testObjectObject_NonConst avgt 15 1.171 ? 0.001 ns/op The relative speed-up diminishes a bit for the loopy 6-arg `methodType` calls, but is still a healthy 12x. Overhead on the negative test might be there but is very much in the noise on my tests (tried doubling warmup time to no avail) - PR: https://git.openjdk.java.net/jdk/pull/8398
Re: RFR: 8285633: Take better advantage of generic MethodType cache [v2]
> The `MethodType.genericMethodType` methods provide convenience methods for > certain common method types and also provide `@Stable` cache that allows for > constant folding. This patch enhances the more generic `methodType` methods > to take advantage of this cache, when possible. This allows calls like > `MethodType.methodType(Object.class, Object.class, ...)` to constant fold, > making them 50x+ faster and allocation-free. > > Baseline: > > BenchmarkMode Cnt Score Error Units > MethodTypeAcquire.baselineRawavgt 15 0.673 ? 0.017 ns/op > MethodTypeAcquire.testGenericObject avgt 15 0.579 ? 0.125 ns/op > MethodTypeAcquire.testMultiPType avgt 15 46.671 ? 1.134 ns/op > MethodTypeAcquire.testMultiPType_Arg avgt 15 27.019 ? 0.437 ns/op > MethodTypeAcquire.testMultiPType_ObjectAndA avgt 15 57.217 ? 0.505 ns/op > MethodTypeAcquire.testMultiPType_ObjectOnly avgt 15 57.114 ? 1.214 ns/op > MethodTypeAcquire.testObjectObject avgt 15 33.380 ? 1.810 ns/op > MethodTypeAcquire.testReturnInt avgt 15 28.043 ? 0.187 ns/op > MethodTypeAcquire.testReturnObject avgt 15 24.313 ? 0.074 ns/op > MethodTypeAcquire.testReturnVoid avgt 15 24.360 ? 0.155 ns/op > MethodTypeAcquire.testSinglePTypeavgt 15 33.572 ? 1.101 ns/op > > > Patched: > > BenchmarkMode Cnt Score Error Units > MethodTypeAcquire.baselineRawavgt 15 0.683 ? 0.024 ns/op > MethodTypeAcquire.testGenericObject avgt 15 0.547 ? 0.047 ns/op > MethodTypeAcquire.testMultiPType avgt 15 48.532 ? 0.982 ns/op > MethodTypeAcquire.testMultiPType_Arg avgt 15 31.390 ? 5.269 ns/op > MethodTypeAcquire.testMultiPType_ObjectAndA avgt 15 60.165 ? 2.756 ns/op > MethodTypeAcquire.testMultiPType_ObjectOnly avgt 15 0.599 ? 0.166 ns/op > MethodTypeAcquire.testObjectObject avgt 15 0.541 ? 0.045 ns/op > MethodTypeAcquire.testReturnInt avgt 15 28.174 ? 0.257 ns/op > MethodTypeAcquire.testReturnObject avgt 15 0.542 ? 0.045 ns/op > MethodTypeAcquire.testReturnVoid avgt 15 24.621 ? 0.202 ns/op > MethodTypeAcquire.testSinglePTypeavgt 15 33.614 ? 1.109 ns/op > > > The cost on method types that don't match are in the noise (0-2ns/op). Even > on a test I constructed to act as a worst case (`testMultiPType_ObjectAndA`) > there's barely any appreciable cost (~3ns/op, with overlapping error). Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Add micros using non-constant arguments to assess performance in absense of constant folding - Changes: - all: https://git.openjdk.java.net/jdk/pull/8398/files - new: https://git.openjdk.java.net/jdk/pull/8398/files/6d2edc59..fcc020e6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8398&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8398&range=00-01 Stats: 18 lines in 1 file changed: 18 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8398.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8398/head:pull/8398 PR: https://git.openjdk.java.net/jdk/pull/8398
Re: Regression after April Java 17 Update (mime types)
Hello Christoph, The actual release notes I initially looked up are the April Release notes from Azul (17.34) for 17.0.3. I already opened a case there. However I then also checked the Oracle Release Notes (I thought they would contain the same 17.0.3 changes). The incompatibility in VFS was actually a shortcoming in VFS: if you want to determine who can handle a file type it would check the mime type or the extension. But it was coded in a way that if it has a mime type but no handler for that type it won’t check for the file extension. This way it could no longer browser URLs ending in .jar or uncompres .go files (or generally all files where there was previously only a file extension handler registered). I would asume this negative consequences is hard to predict, especially since VFS could in this case prevemt it. However for an application it is unfortunate that this breaks (especially when hoping to ship a quarterly security update quickly). Bit generally it’s a noteworthy new feature. Thanks for the reminder of the Shipilev release notes, I did actually not check them after looking at two vendors (and not finding a Release announcement mail like there was one for 17.0.2. Can I asume those are no longer sent after X.0.2 is published? I guess my comment to „not including it in the release notes“ was not valid for the OpenJDK Updates project and I will take it up with Azul to check the source they are using. If you want to look deeper into this: The VFS logic might be a bit hard to follow, it basically works on URLs and it has a filesystem layering mode which checks on mime type and/or extension: https://issues.apache.org/jira/browse/VFS-770 This is the actual fix commit for it: https://github.com/apache/commons-vfs/commit/f3b7a06f28aab2db829806e0e857c05b71a14305 It is retrieving the contentType for a URL here https://github.com/apache/commons-vfs/blob/64da24778ea075ffc5de8588a29a0f50c6c8d94e/commons-vfs2/src/main/java/org/apache/commons/vfs2/impl/FileContentInfoFilenameFactory.java#L41 Gruss Bernd -- http://bernd.eckenfels.net Von: Langer, Christoph Gesendet: Tuesday, April 26, 2022 5:18:38 PM An: Bernd Eckenfels ; jdk-updates-...@openjdk.java.net Cc: core-libs-dev Betreff: RE: Regression after April Java 17 Update (mime types) Hi Bernd, I just noticed your report regarding the regression after JDK-8273655. I'm directing this communication to jdk-updates-dev now as it seems more appropriate. I assume with release notes you're referring to the Oracle 17.0.3 release notes? This change, if you look closely at the backports, was only brought to OpenJDK 17.0.3 and it will hit the OpenJDK 11u update 11.0.16 in July. So, it would not be reflected in Oracle release notes. The best you can get for OpenJDK 17.0.3 release notes is [0], to my knowledge. Do you have some more information regarding the incompatibility? What I'm understanding is that this backport unveils a problem with Apache VFS? Do you have a bug link for that one? If it's just uncovering a bug in another 3rd party software, I assume it doesn't merit a backout, though. Best regards Christoph [0] https://builds.shipilev.net/backports-monitor/release-notes-17.0.3.html > -Original Message- > From: core-libs-dev On Behalf Of Bernd > Eckenfels > Sent: Montag, 25. April 2022 19:39 > To: core-libs-dev > Subject: Regression after April Java 17 Update (mime types) > > Hello, > > We just tried to push out the Java 17 April Update but it failed with some > incompatible behavior. We found out it is caused due to a new mime-type (and > a bug in Apache VFS) that JAR files could no longer be opened in an overlay > (technically a JAR URL suddenly had a mime-type and therefore VFS no longer > looked at the file extension). > > Just wanted to give a heads up in case anybody else has that problem. The > change 8273655 (a backport 828109) was not mentioned in the 17.0.3 release > notes (it is also in 11.0.16) from Oracle and Azul - will it show up in the > OpenJDK announcement? > > This specific case is a changed behavior (even when it has rather unexpected > negative consequences), it would be therefore good to be called out > specifically. > > Gruss > Bernd > > > -- > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbernd.eck > enfels.net%2F&data=05%7C01%7Cchristoph.langer%40sap.com%7C9ca8f > 2471e24471c3d8308da26e286b1%7C42f7676cf455423c82f6dc2d99791af7%7 > C0%7C0%7C637865052069446373%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000 > %7C%7C%7C&sdata=J3kfVCvkDUH9UxiRqkoS9g9o85nB46ksbpUF5HihRP8 > %3D&reserved=0
Integrated: 8285677: ProblemList two tests from JDK-8285671 on macosx-x64
On Tue, 26 Apr 2022 19:35:19 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList two tests from JDK-8285671 on macosx-x64. This pull request has now been integrated. Changeset: e3d714d3 Author:Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/e3d714d37e2679a4f8046d78964292a876bbe3d6 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8285677: ProblemList two tests from JDK-8285671 on macosx-x64 Reviewed-by: dfuchs - PR: https://git.openjdk.java.net/jdk/pull/8406
Re: Integrated: 8285677: ProblemList two tests from JDK-8285671 on macosx-x64
On Tue, 26 Apr 2022 19:39:02 GMT, Daniel Fuchs wrote: >> A trivial fix to ProblemList two tests from JDK-8285671 on macosx-x64. > > LGTM Dan. Thanks for taking care of that! @dfuch - Thanks for the fast review! And no worries about handling the ProblemListing... - PR: https://git.openjdk.java.net/jdk/pull/8406
Re: Integrated: 8285677: ProblemList two tests from JDK-8285671 on macosx-x64
On Tue, 26 Apr 2022 19:35:19 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList two tests from JDK-8285671 on macosx-x64. LGTM Dan. Thanks for taking care of that! - Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8406
Integrated: 8285677: ProblemList two tests from JDK-8285671 on macosx-x64
A trivial fix to ProblemList two tests from JDK-8285671 on macosx-x64. - Commit messages: - 8285677: ProblemList two tests from JDK-8285671 on macosx-x64 Changes: https://git.openjdk.java.net/jdk/pull/8406/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8406&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285677 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8406.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8406/head:pull/8406 PR: https://git.openjdk.java.net/jdk/pull/8406
Re: RFR: 8285633: Take better advantage of generic MethodType cache
On Tue, 26 Apr 2022 17:20:55 GMT, Claes Redestad wrote:
>> test/micro/org/openjdk/bench/java/lang/invoke/MethodTypeAcquire.java line
>> 104:
>>
>>> 102: @Benchmark
>>> 103: public MethodType testMultiPType_ObjectOnly() {
>>> 104: return MethodType.methodType(Object.class, Object.class,
>>> Object.class, Object.class, Object.class, Object.class, Object.class);
>>
>> It might be interesting to add a benchmark where all types are `Object`, but
>> non-constants, to see if that case improves as well.
>
> Right.. I did a quick experiment and there's a large speed-up in the trivial
> `methodType(obj, obj)` case:
>
> Benchmark Mode Cnt Score Error
> Units
> MethodTypeAcquire.testObjectObjectNonConstant avgt5 30.052 ? 3.440
> ns/op # baseline
> MethodTypeAcquire.testObjectObjectNonConstant avgt5 1.171 ? 0.001
> ns/op # patch
>
>
> I'll add a non-constant variant for the multi-arg Object variants, too. It
> should scale linearly and see a gain in the same ballpark. I think we need to
> keep the number of microbenchmarks here somewhat under control, though.
That sounds good, thanks
-
PR: https://git.openjdk.java.net/jdk/pull/8398
Re: RFR: 8282274: Compiler implementation for Pattern Matching for switch (Third Preview) [v7]
> This is a (preliminary) patch for javac implementation for the third preview > of pattern matching for switch (type patterns in switches). > > Draft JLS: > http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html > > The changes are: > -there are no guarded patterns anymore, guards are not bound to the > CaseElement (JLS 15.28) > -a new contextual keyword `when` is used to add a guard, instead of `&&` > -`null` selector value is handled on switch level (if a switch has `case > null`, it is used, otherwise a NPE is thrown), rather than on pattern > matching level. > -total patterns are allowed in `instanceof` > -`java.lang.MatchException` is added for the case where a switch is > exhaustive (due to sealed types) at compile-time, but not at runtime. > > Feedback is welcome! > > Thanks! Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Reference-type pattern is not applicable at a selector of a primitive type - fixing. - Merge branch 'master' into type-patterns-third - Cleanup, fixing tests. - Cleanup - more total -> unconditional pattern renaming. - Adjusting to review feedback. - Cleanup. - Fixing tests. - Adding a test for a NPE from guards. - Cleanup - Merge branch 'master' into type-patterns-third - ... and 8 more: https://git.openjdk.java.net/jdk/compare/82f0ac02...9f290cd2 - Changes: https://git.openjdk.java.net/jdk/pull/8182/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=06 Stats: 888 lines in 52 files changed: 453 ins; 244 del; 191 mod Patch: https://git.openjdk.java.net/jdk/pull/8182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182 PR: https://git.openjdk.java.net/jdk/pull/8182
Re: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0 [v3]
On Mon, 25 Apr 2022 14:26:17 GMT, Harold Seigel wrote: >> Please review this small fix for JDK-8284642. The fix was tested by running >> Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux >> x64. Additionally, the modified test and the test in the bug report were >> run locally. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional > commit since the last revision: > > Fix globals.hpp text Thanks for the reviews! - PR: https://git.openjdk.java.net/jdk/pull/8222
Integrated: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0
On Wed, 13 Apr 2022 12:24:46 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8284642. The fix was tested by running > Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux > x64. Additionally, the modified test and the test in the bug report were run > locally. > > Thanks, Harold This pull request has now been integrated. Changeset: 975a060a Author:Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/975a060ade6e11b021222ae7f7a2de0d0c041308 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0 Reviewed-by: stuefe, dholmes - PR: https://git.openjdk.java.net/jdk/pull/8222
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7]
On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in the HotSpot VM are disabled by default and
>> require running with `--enable-preview` to enable.
>>
>> The patch has support for x64 and aarch64 on the usual operating systems
>> (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for
>> zero and some of the other ports. Additional ports can be contributed via
>> PRs against the fibers branch in the loom repo.
>>
>> There are changes in many areas. To reduce notifications/mails, the labels
>> have been trimmed down for now to hotspot, serviceability and core-libs.
>> We'll add the complete set of labels when the PR is further along.
>>
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from
>> Doug Lea's CVS. These changes will probably be proposed and integrated in
>> advance of this PR.
>>
>> The changes include some non-exposed and low-level infrastructure to support
>> the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to
>> make life a bit easier and avoid having to separate VM changes and juggle
>> branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java line 770:
> 768: synchronized (p) {
> 769: DatagramPackets.setLength(p, n);
> 770: p.setSocketAddress(sender);
Hmmm... For integrity it might be better to call the public
`DatagramPacket::setData(byte[] buf, int offset, int length)` method here now.
The additional advantage is that the private access to
`DatagramPackets.setLength(p, n);` will no longer be needed.
-
PR: https://git.openjdk.java.net/jdk/pull/8166
Re: RFR: 8285658: Fix two typos in the spec of j.u.random.RandomGenerator [v2]
On Tue, 26 Apr 2022 16:55:44 GMT, Raffaello Giulietti
wrote:
>> The spec of the interface `java.util.random.RandomGenerator` is slightly
>> incorrect when it discusses `float` and `double` random values.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8285658: Fix two typos in the spec of j.u.random.RandomGenerator
Marked as reviewed by darcy (Reviewer).
src/java.base/share/classes/java/util/random/RandomGenerator.java line 501:
> 499: *
> 500: * @implSpec The default implementation uses the {@link
> Float#PRECISION}
> 501: * high-order bits from a call to {@link RandomGenerator#nextInt()
> nextInt}().
Typographical nit: please include the "()" inside the link tag for both methods.
-
PR: https://git.openjdk.java.net/jdk/pull/8404
Re: RFR: 8285658: Fix two typos in the spec of j.u.random.RandomGenerator [v2]
On Tue, 26 Apr 2022 16:55:44 GMT, Raffaello Giulietti
wrote:
>> The spec of the interface `java.util.random.RandomGenerator` is slightly
>> incorrect when it discusses `float` and `double` random values.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8285658: Fix two typos in the spec of j.u.random.RandomGenerator
Should we use `{@value }` javadoc tag, which renders the literal in HTML but
includes a link to the constant?
-
PR: https://git.openjdk.java.net/jdk/pull/8404
Re: RFR: 8284932: [Vector API] Incorrect implementation of LSHR operator for negative byte/short elements
On Sun, 17 Apr 2022 14:35:14 GMT, Jie Fu wrote: >> According to the Vector API doc, the LSHR operator computes >> a>>>(n&(ESIZE*8-1)) Documentation is correct if viewed strictly in context of subword vector lane, JVM internally promotes/sign extends subword type scalar variables into int type, but vectors are loaded from continuous memory holding subwords, it will not be correct for developer to imagine that individual subword type lanes will be upcasted into int lanes before being operated upon. Thus both java implementation and compiler handling looks correct. - PR: https://git.openjdk.java.net/jdk/pull/8276
Re: RFR: 8285452: Support new API to replace a file content using FileUtils.java [v3]
On Fri, 22 Apr 2022 14:35:14 GMT, Sibabrata Sahoo wrote: >> A new API to support replacing selective lines with desired content. > > Sibabrata Sahoo has updated the pull request incrementally with one > additional commit since the last revision: > > Update FileUtils.java We have a test that dynamically downloads a source file, patches it, compiles it, and then runs it. We don't want to include a static copy of the file inside the test. - PR: https://git.openjdk.java.net/jdk/pull/8360
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v7]
> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which > JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the > loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and > require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems > (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero > and some of the other ports. Additional ports can be contributed via PRs > against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels > have been trimmed down for now to hotspot, serviceability and core-libs. > We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from > Doug Lea's CVS. These changes will probably be proposed and integrated in > advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support > the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to > make life a bit easier and avoid having to separate VM changes and juggle > branches at this time. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 - Changes: - all: https://git.openjdk.java.net/jdk/pull/8166/files - new: https://git.openjdk.java.net/jdk/pull/8166/files/05781877..0864cb09 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=05-06 Stats: 582 lines in 34 files changed: 285 ins; 128 del; 169 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166
Re: RFR: 8285633: Take better advantage of generic MethodType cache
On Tue, 26 Apr 2022 15:30:41 GMT, Jorn Vernee wrote:
>> The `MethodType.genericMethodType` methods provide convenience methods for
>> certain common method types and also provide `@Stable` cache that allows for
>> constant folding. This patch enhances the more generic `methodType` methods
>> to take advantage of this cache, when possible. This allows calls like
>> `MethodType.methodType(Object.class, Object.class, ...)` to constant fold,
>> making them 50x+ faster and allocation-free.
>>
>> Baseline:
>>
>> BenchmarkMode Cnt Score Error Units
>> MethodTypeAcquire.baselineRawavgt 15 0.673 ? 0.017 ns/op
>> MethodTypeAcquire.testGenericObject avgt 15 0.579 ? 0.125 ns/op
>> MethodTypeAcquire.testMultiPType avgt 15 46.671 ? 1.134 ns/op
>> MethodTypeAcquire.testMultiPType_Arg avgt 15 27.019 ? 0.437 ns/op
>> MethodTypeAcquire.testMultiPType_ObjectAndA avgt 15 57.217 ? 0.505 ns/op
>> MethodTypeAcquire.testMultiPType_ObjectOnly avgt 15 57.114 ? 1.214 ns/op
>> MethodTypeAcquire.testObjectObject avgt 15 33.380 ? 1.810 ns/op
>> MethodTypeAcquire.testReturnInt avgt 15 28.043 ? 0.187 ns/op
>> MethodTypeAcquire.testReturnObject avgt 15 24.313 ? 0.074 ns/op
>> MethodTypeAcquire.testReturnVoid avgt 15 24.360 ? 0.155 ns/op
>> MethodTypeAcquire.testSinglePTypeavgt 15 33.572 ? 1.101 ns/op
>>
>>
>> Patched:
>>
>> BenchmarkMode Cnt Score Error Units
>> MethodTypeAcquire.baselineRawavgt 15 0.683 ? 0.024 ns/op
>> MethodTypeAcquire.testGenericObject avgt 15 0.547 ? 0.047 ns/op
>> MethodTypeAcquire.testMultiPType avgt 15 48.532 ? 0.982 ns/op
>> MethodTypeAcquire.testMultiPType_Arg avgt 15 31.390 ? 5.269 ns/op
>> MethodTypeAcquire.testMultiPType_ObjectAndA avgt 15 60.165 ? 2.756 ns/op
>> MethodTypeAcquire.testMultiPType_ObjectOnly avgt 15 0.599 ? 0.166 ns/op
>> MethodTypeAcquire.testObjectObject avgt 15 0.541 ? 0.045 ns/op
>> MethodTypeAcquire.testReturnInt avgt 15 28.174 ? 0.257 ns/op
>> MethodTypeAcquire.testReturnObject avgt 15 0.542 ? 0.045 ns/op
>> MethodTypeAcquire.testReturnVoid avgt 15 24.621 ? 0.202 ns/op
>> MethodTypeAcquire.testSinglePTypeavgt 15 33.614 ? 1.109 ns/op
>>
>>
>> The cost on method types that don't match are in the noise (0-2ns/op). Even
>> on a test I constructed to act as a worst case (`testMultiPType_ObjectAndA`)
>> there's barely any appreciable cost (~3ns/op, with overlapping error).
>
> test/micro/org/openjdk/bench/java/lang/invoke/MethodTypeAcquire.java line 104:
>
>> 102: @Benchmark
>> 103: public MethodType testMultiPType_ObjectOnly() {
>> 104: return MethodType.methodType(Object.class, Object.class,
>> Object.class, Object.class, Object.class, Object.class, Object.class);
>
> It might be interesting to add a benchmark where all types are `Object`, but
> non-constants, to see if that case improves as well.
Right.. I did a quick experiment and there's a large speed-up in the trivial
`methodType(obj, obj)` case:
Benchmark Mode Cnt Score Error Units
MethodTypeAcquire.testObjectObjectNonConstant avgt5 30.052 ? 3.440 ns/op
# baseline
MethodTypeAcquire.testObjectObjectNonConstant avgt5 1.171 ? 0.001 ns/op
# patch
I'll add a non-constant variant for the multi-arg Object variants, too. It
should scale linearly and see a gain in the same ballpark. I think we need to
keep the number of microbenchmarks here somewhat under control, though.
-
PR: https://git.openjdk.java.net/jdk/pull/8398
Re: RFR: 8285658: Fix two typos in the spec of j.u.random.RandomGenerator [v2]
On Tue, 26 Apr 2022 16:55:44 GMT, Raffaello Giulietti wrote: >> The spec of the interface `java.util.random.RandomGenerator` is slightly >> incorrect when it discusses `float` and `double` random values. > > Raffaello Giulietti has updated the pull request incrementally with one > additional commit since the last revision: > > 8285658: Fix two typos in the spec of j.u.random.RandomGenerator Marked as reviewed by bpb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8404
Re: RFR: 8285452: Support new API to replace a file content using FileUtils.java [v3]
On Fri, 22 Apr 2022 14:35:14 GMT, Sibabrata Sahoo wrote: >> A new API to support replacing selective lines with desired content. > > Sibabrata Sahoo has updated the pull request incrementally with one > additional commit since the last revision: > > Update FileUtils.java Can you elaborate on the use case, what tests would it be used in? The hardcoded `from` and `to` seem very rigid and require knowledge of the exact format. That might lead to very fragile tests. Is this equivalent to looking for a substring aka `String.contains(xxx)` of the input file to replace (with line ending normalization)? - PR: https://git.openjdk.java.net/jdk/pull/8360
Re: RFR: 8285658: Fix two typos in the spec of j.u.random.RandomGenerator [v2]
> The spec of the interface `java.util.random.RandomGenerator` is slightly > incorrect when it discusses `float` and `double` random values. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8285658: Fix two typos in the spec of j.u.random.RandomGenerator - Changes: - all: https://git.openjdk.java.net/jdk/pull/8404/files - new: https://git.openjdk.java.net/jdk/pull/8404/files/b3a802ae..8d4388bd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8404&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8404&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8404.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8404/head:pull/8404 PR: https://git.openjdk.java.net/jdk/pull/8404
Re: RFR: 8285658: Fix two typos in the spec of j.u.random.RandomGenerator
On Tue, 26 Apr 2022 16:38:37 GMT, Raffaello Giulietti wrote: > The spec of the interface `java.util.random.RandomGenerator` is slightly > incorrect when it discusses `float` and `double` random values. This PR fixes the spec and replaces hard-coded literals with static compilation time symbolic expressions. - PR: https://git.openjdk.java.net/jdk/pull/8404
RFR: 8285658: Fix two typos in the spec of j.u.random.RandomGenerator
The spec of the interface `java.util.random.RandomGenerator` is slightly incorrect when it discusses `float` and `double` random values. - Commit messages: - Fix two typos in the spec of j.u.random.RandomGenerator Changes: https://git.openjdk.java.net/jdk/pull/8404/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8404&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285658 Stats: 8 lines in 1 file changed: 1 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/8404.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8404/head:pull/8404 PR: https://git.openjdk.java.net/jdk/pull/8404
Re: RFR: 8285440: Typo in Collections.addAll method javadoc
On Fri, 31 Dec 2021 18:58:43 GMT, Johnny Lim wrote: > This PR fixes a typo. Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6942
Integrated: 8283620: System.out does not use the encoding/charset specified in the Javadoc
On Fri, 15 Apr 2022 20:26:55 GMT, Naoto Sato wrote: > Promoting the internal system properties for `System.out` and `System.err` so > that users can override the encoding used for those streams to `UTF-8`, > aligning to the `Charset.defaultCharset()`. A CSR has also been drafted. This pull request has now been integrated. Changeset: 03bcf7b6 Author:Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/03bcf7b6d196f6c5d851059cb6f580767eee4e94 Stats: 55 lines in 8 files changed: 22 ins; 4 del; 29 mod 8283620: System.out does not use the encoding/charset specified in the Javadoc Reviewed-by: alanb - PR: https://git.openjdk.java.net/jdk/pull/8270
Integrated: 8284930: Re-examine FilterInputStream mark/reset
On Tue, 19 Apr 2022 23:26:44 GMT, Brian Burkhalter wrote: > Remove the `synchronized` keyword from the `mark(int)` and `reset()` methods > of `java.io.FilterInputStream`. This pull request has now been integrated. Changeset: a3b78814 Author:Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/a3b788144ecc37262a3560e9c234bc8fb41ca3df Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod 8284930: Re-examine FilterInputStream mark/reset Reviewed-by: alanb, jpai, dfuchs, lancea - PR: https://git.openjdk.java.net/jdk/pull/8309
Re: RFR: 8285633: Take better advantage of generic MethodType cache
On Tue, 26 Apr 2022 10:57:04 GMT, Claes Redestad wrote:
> The `MethodType.genericMethodType` methods provide convenience methods for
> certain common method types and also provide `@Stable` cache that allows for
> constant folding. This patch enhances the more generic `methodType` methods
> to take advantage of this cache, when possible. This allows calls like
> `MethodType.methodType(Object.class, Object.class, ...)` to constant fold,
> making them 50x+ faster and allocation-free.
>
> Baseline:
>
> BenchmarkMode Cnt Score Error Units
> MethodTypeAcquire.baselineRawavgt 15 0.673 ? 0.017 ns/op
> MethodTypeAcquire.testGenericObject avgt 15 0.579 ? 0.125 ns/op
> MethodTypeAcquire.testMultiPType avgt 15 46.671 ? 1.134 ns/op
> MethodTypeAcquire.testMultiPType_Arg avgt 15 27.019 ? 0.437 ns/op
> MethodTypeAcquire.testMultiPType_ObjectAndA avgt 15 57.217 ? 0.505 ns/op
> MethodTypeAcquire.testMultiPType_ObjectOnly avgt 15 57.114 ? 1.214 ns/op
> MethodTypeAcquire.testObjectObject avgt 15 33.380 ? 1.810 ns/op
> MethodTypeAcquire.testReturnInt avgt 15 28.043 ? 0.187 ns/op
> MethodTypeAcquire.testReturnObject avgt 15 24.313 ? 0.074 ns/op
> MethodTypeAcquire.testReturnVoid avgt 15 24.360 ? 0.155 ns/op
> MethodTypeAcquire.testSinglePTypeavgt 15 33.572 ? 1.101 ns/op
>
>
> Patched:
>
> BenchmarkMode Cnt Score Error Units
> MethodTypeAcquire.baselineRawavgt 15 0.683 ? 0.024 ns/op
> MethodTypeAcquire.testGenericObject avgt 15 0.547 ? 0.047 ns/op
> MethodTypeAcquire.testMultiPType avgt 15 48.532 ? 0.982 ns/op
> MethodTypeAcquire.testMultiPType_Arg avgt 15 31.390 ? 5.269 ns/op
> MethodTypeAcquire.testMultiPType_ObjectAndA avgt 15 60.165 ? 2.756 ns/op
> MethodTypeAcquire.testMultiPType_ObjectOnly avgt 15 0.599 ? 0.166 ns/op
> MethodTypeAcquire.testObjectObject avgt 15 0.541 ? 0.045 ns/op
> MethodTypeAcquire.testReturnInt avgt 15 28.174 ? 0.257 ns/op
> MethodTypeAcquire.testReturnObject avgt 15 0.542 ? 0.045 ns/op
> MethodTypeAcquire.testReturnVoid avgt 15 24.621 ? 0.202 ns/op
> MethodTypeAcquire.testSinglePTypeavgt 15 33.614 ? 1.109 ns/op
>
>
> The cost on method types that don't match are in the noise (0-2ns/op). Even
> on a test I constructed to act as a worst case (`testMultiPType_ObjectAndA`)
> there's barely any appreciable cost (~3ns/op, with overlapping error).
Marked as reviewed by jvernee (Reviewer).
test/micro/org/openjdk/bench/java/lang/invoke/MethodTypeAcquire.java line 104:
> 102: @Benchmark
> 103: public MethodType testMultiPType_ObjectOnly() {
> 104: return MethodType.methodType(Object.class, Object.class,
> Object.class, Object.class, Object.class, Object.class, Object.class);
It might be interesting to add a benchmark where all types are `Object`, but
non-constants, to see if that case improves as well.
-
PR: https://git.openjdk.java.net/jdk/pull/8398
RE: Regression after April Java 17 Update (mime types)
Hi Bernd, I just noticed your report regarding the regression after JDK-8273655. I'm directing this communication to jdk-updates-dev now as it seems more appropriate. I assume with release notes you're referring to the Oracle 17.0.3 release notes? This change, if you look closely at the backports, was only brought to OpenJDK 17.0.3 and it will hit the OpenJDK 11u update 11.0.16 in July. So, it would not be reflected in Oracle release notes. The best you can get for OpenJDK 17.0.3 release notes is [0], to my knowledge. Do you have some more information regarding the incompatibility? What I'm understanding is that this backport unveils a problem with Apache VFS? Do you have a bug link for that one? If it's just uncovering a bug in another 3rd party software, I assume it doesn't merit a backout, though. Best regards Christoph [0] https://builds.shipilev.net/backports-monitor/release-notes-17.0.3.html > -Original Message- > From: core-libs-dev On Behalf Of Bernd > Eckenfels > Sent: Montag, 25. April 2022 19:39 > To: core-libs-dev > Subject: Regression after April Java 17 Update (mime types) > > Hello, > > We just tried to push out the Java 17 April Update but it failed with some > incompatible behavior. We found out it is caused due to a new mime-type (and > a bug in Apache VFS) that JAR files could no longer be opened in an overlay > (technically a JAR URL suddenly had a mime-type and therefore VFS no longer > looked at the file extension). > > Just wanted to give a heads up in case anybody else has that problem. The > change 8273655 (a backport 828109) was not mentioned in the 17.0.3 release > notes (it is also in 11.0.16) from Oracle and Azul - will it show up in the > OpenJDK announcement? > > This specific case is a changed behavior (even when it has rather unexpected > negative consequences), it would be therefore good to be called out > specifically. > > Gruss > Bernd > > > -- > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbernd.eck > enfels.net%2F&data=05%7C01%7Cchristoph.langer%40sap.com%7C9ca8f > 2471e24471c3d8308da26e286b1%7C42f7676cf455423c82f6dc2d99791af7%7 > C0%7C0%7C637865052069446373%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000 > %7C%7C%7C&sdata=J3kfVCvkDUH9UxiRqkoS9g9o85nB46ksbpUF5HihRP8 > %3D&reserved=0
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v6]
On Mon, 25 Apr 2022 13:19:49 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which >> JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the >> loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and >> require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems >> (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for >> zero and some of the other ports. Additional ports can be contributed via >> PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels >> have been trimmed down for now to hotspot, serviceability and core-libs. >> We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from >> Doug Lea's CVS. These changes will probably be proposed and integrated in >> advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support >> the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to >> make life a bit easier and avoid having to separate VM changes and juggle >> branches at this time. > > Alan Bateman has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains ten commits: > > - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1 > - Merge with jdk-19+19 > - Refresh > - Refresh > - Refresh > - Refresh > - Merge with jdk-19+18 > - Refresh > - Initial push I have done a long and extensive hands-on review of most of the JVM code (excluding most of the JVMTI changes). There is still room for improvements, but I think this is in a good enough shape to be integrated now, plus minus some patches in the ether between the fibers branch and this PR which I'm sure will pop up soon. So this looks good to me. Ship it! - Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166
Integrated: 8284779: Test java/util/logging/Logger/logrb/TestLogrbResourceBundle.java fails intermittently with vthreads wrapper
On Mon, 25 Apr 2022 13:30:05 GMT, Daniel Fuchs wrote: > Hi, > > Please find enclosed a patch to fix a rare intermittent failure that was > detected while testing virtual threads. > The issue has nothing to do with virtual threads, the test is simply missing > a reachability fence to make sure that the parent logger is not garbage > collected until its child logger is created. > > best regards, > > -- daniel This pull request has now been integrated. Changeset: 552e1b0b Author:Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/552e1b0b8a0cd49089f58dea92ca96cce86b311f Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod 8284779: Test java/util/logging/Logger/logrb/TestLogrbResourceBundle.java fails intermittently with vthreads wrapper Reviewed-by: alanb - PR: https://git.openjdk.java.net/jdk/pull/8382
RFR: 8285633: Take better advantage of generic MethodType cache
The `MethodType.genericMethodType` methods provide convenience methods for certain common method types and also provide `@Stable` cache that allows for constant folding. This patch enhances the more generic `methodType` methods to take advantage of this cache, when possible. This allows calls like `MethodType.methodType(Object.class, Object.class, ...)` to constant fold, making them 50x+ faster and allocation-free. Baseline: BenchmarkMode Cnt Score Error Units MethodTypeAcquire.baselineRawavgt5 0.673 ? 0.036 ns/op MethodTypeAcquire.testGenericObject avgt5 0.520 ? 0.162 ns/op MethodTypeAcquire.testMultiPType avgt5 47.922 ? 1.778 ns/op MethodTypeAcquire.testMultiPType_Arg avgt5 28.992 ? 0.949 ns/op MethodTypeAcquire.testMultiPType_ObjectAndA avgt5 56.698 ? 0.879 ns/op MethodTypeAcquire.testMultiPType_ObjectOnly avgt5 55.705 ? 0.854 ns/op MethodTypeAcquire.testObjectObject avgt5 31.729 ? 2.204 ns/op MethodTypeAcquire.testReturnInt avgt5 26.171 ? 0.141 ns/op MethodTypeAcquire.testReturnObject avgt5 24.340 ? 0.868 ns/op MethodTypeAcquire.testReturnVoid avgt5 24.793 ? 2.816 ns/op MethodTypeAcquire.testSinglePTypeavgt5 32.653 ? 1.082 ns/op Patched: BenchmarkMode Cnt Score Error Units MethodTypeAcquire.baselineRawavgt5 0.727 ? 0.382 ns/op MethodTypeAcquire.testGenericObject avgt5 0.658 ? 0.655 ns/op MethodTypeAcquire.testMultiPType avgt5 48.066 ? 1.187 ns/op MethodTypeAcquire.testMultiPType_Arg avgt5 27.097 ? 0.745 ns/op MethodTypeAcquire.testMultiPType_ObjectAndA avgt5 58.074 ? 6.299 ns/op MethodTypeAcquire.testMultiPType_ObjectOnly avgt5 0.538 ? 0.195 ns/op MethodTypeAcquire.testObjectObject avgt5 0.520 ? 0.162 ns/op MethodTypeAcquire.testReturnInt avgt5 28.093 ? 0.235 ns/op MethodTypeAcquire.testReturnObject avgt5 0.540 ? 0.204 ns/op MethodTypeAcquire.testReturnVoid avgt5 24.746 ? 0.706 ns/op MethodTypeAcquire.testSinglePTypeavgt5 32.662 ? 1.924 ns/op The cost on method types that don't match are in the noise (0-2ns/op). Even on a test I constructed to act as a worst case (`testMultiPType_ObjectAndA`) there's barely any appreciable cost. - Commit messages: - Copyrights - 8285633: Take better advantage of generic MethodType cache Changes: https://git.openjdk.java.net/jdk/pull/8398/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8398&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285633 Stats: 101 lines in 8 files changed: 78 ins; 1 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/8398.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8398/head:pull/8398 PR: https://git.openjdk.java.net/jdk/pull/8398
