July 2021 - core-libs-dev

[jdk17] RFR: 8270025: DynamicCallSiteDesc::withArgs doesn't throw NPE
by Vicente Romero 13 Jul '21

13 Jul '21

Please review this PR that is fixing a mismatch between the implementation for method `java.lang.constant.DynamicCallSiteDesc::withArgs` and its implementation. I made a mistake while working on a recent CSR [JDK-8224985](https://bugs.openjdk.java.net/browse/JDK-8224985) and fixed the API but mistakenly thought that the implementation was in sync with the spec. This is why this change is also including a unit test of the API for `java.lang.constant.DynamicCallSiteDesc` module for method `resolveCallSiteDesc` which is covered in test `IndyDescTest` in the same test suite. Also this change needs a CSR while fixing the implementation of method `::withArgs` I realized that the API of the varargs overloaded version of method `::of` needed some rewording too as it is invoking the same private constructor `::withArgs` is invoking. So it didn't make sense for the API of one method to be more restrictive than the other. Please review also the accompanying CSR. Thanks, Vicente ------------- Commit messages: - 8270025: DynamicCallSiteDesc.withArgs doesn't throw NPE Changes: https://git.openjdk.java.net/jdk17/pull/242/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=242&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270025 Stats: 212 lines in 2 files changed: 210 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk17/pull/242.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/242/head:pull/242 PR: https://git.openjdk.java.net/jdk17/pull/242

3 8

[jdk17] RFR: 8269281: java/foreign/Test{Down,Up}call.java time out
by Maurizio Cimadamore 13 Jul '21

13 Jul '21

After some more investigation, I have been able to at least partially reproduce on my Linux box. While I can't get to same slowdown as we're seeing in test machines, I did notice that in fastdebug mode, TestUpcall is a lot slower than in release mode. The underlying issue is that these tests are generating a lot of "throwaway" method handles. Method handles are typically stored in fields - when that happens, creating a method handle with same shape as one that has already been created typically works ok, w/o overhead, because there's a cache in the MethodType class which stores already generated lambda forms (by method handle kind). This cache is a SofteReference cahce, so, if the system is under memory pressure, the GC is of course free to null out all these cached values, in which case a new lambda form will be generated, and a new class will be loaded. When looking at both TestDowncall and TestUpcall, in their current form, it is possible to observe a fairly large amount of classes being loaded and unloaded. Since the test generates many garbage, the GC is under pressure, and that causes entries in the lambda form cache to be evicted. The fact that one of the tests also explicitly calls out to `System::gc` doesn't help, and probably adds to the churn. Since it is very hard, if not impossible, to fix the test so that all the required method handle are retained for the entire duration of the test (since we create different variations of same handles, based on the test being run), I believe the best solution would be to reduce the number of test combinations being executed. This patch adds the ability to specify a sampling factor - which reduces the size of the test combinations being executed. Note that we also have a fuller test (which is never run automatically, but can be ran by hand: `TestMatrix`) - this test does not specify any sampling factor, so when developers run this stress test manually they will still run the whole shebang (which is what you want if you are tweaking the logic in the foreign support). ------------- Commit messages: - * Remove calls to System.gc() Changes: https://git.openjdk.java.net/jdk17/pull/238/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=238&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269281 Stats: 17 lines in 3 files changed: 6 ins; 7 del; 4 mod Patch: https://git.openjdk.java.net/jdk17/pull/238.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/238/head:pull/238 PR: https://git.openjdk.java.net/jdk17/pull/238

2 2

RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible
by Yi Yang 13 Jul '21

13 Jul '21

After JDK-8265518, it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. ------------- Commit messages: - use checkIndex globally Changes: https://git.openjdk.java.net/jdk/pull/4507/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268698 Stats: 206 lines in 34 files changed: 31 ins; 111 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/4507.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507 PR: https://git.openjdk.java.net/jdk/pull/4507

8 42

RFR: 8270056: Generated lambda class can not access protected static method of target class
by Yi Yang 13 Jul '21

13 Jul '21

Generated lambda class can not access protected static method of the target class. The following exception is thrown when executing the attached reproducible program: Exception in thread "main" java.lang.IllegalAccessError: class AccessProtectedStaticMethodFromSuper$B$$Lambda$15/0x0000000800b8ea48 tried to access protected method 'void AccessProtectedStaticMethodFromSuper$A.func()' (AccessProtectedStaticMethodFromSuper$B$$Lambda$15/0x0000000800b8ea48 is in unnamed module of loader AccessProtectedStaticMethodFromSuper$1Loader @71dac704; AccessProtectedStaticMethodFromSuper$A is in unnamed module of loader AccessProtectedStaticMethodFromSuper$1Loader @39ed3c8d) at AccessProtectedStaticMethodFromSuper.main(AccessProtectedStaticMethodFromSuper.java:51) This issue is similar to JDK-8254975(#767) with slight differences: generated lambda proxy calls static protected method rather than protected member method. The proposed fix 1) tries to use MethodHandle instead of invoking forwarded directly(since the lambda class has no access to the resolved method) and 2) does not force accepting an implClass as the first argument when invoking a static method. ------------- Commit messages: - proposed fix Changes: https://git.openjdk.java.net/jdk/pull/4714/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4714&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270056 Stats: 102 lines in 2 files changed: 100 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4714.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4714/head:pull/4714 PR: https://git.openjdk.java.net/jdk/pull/4714

2 7

RFR: 8266578: Disambiguate BigDecimal description of scale
by Ignasi Marimon-Clos 12 Jul '21

12 Jul '21

The API Docs for `BigDecimal` introduce the meaning of `scale`. The current writeup can be missleading when presenting the meaning of a `scale` value that's negative. Hopefully, with this PR, the sentence is more clear. The ambiguity is on this sentence: > If negative, the unscaled value of the number is ... Instead, I suggest the more verbose: > If the scale is negative, the unscaled value of the number is ... To keep symmetry, I've also reviewed the positive case from: > If zero or positive, the scale is the number of digits ... to: > If the scale is zero or positive, the scale is the number of digits ... ------------- Commit messages: - Merge branch 'master' into minor-disambiguation - Disambiguate the BigDecimal docs Changes: https://git.openjdk.java.net/jdk/pull/582/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=582&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266578 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/582.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/582/head:pull/582 PR: https://git.openjdk.java.net/jdk/pull/582

4 14

RFR: Merge jdk17
by Jesper Wilhelmsson 10 Jul '21

10 Jul '21

Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8268826: Cleanup Override in Context-Specific Deserialization Filters - 8261147: C2: Node is wrongly marked as reduction resulting in a wrong execution due to wrong vector instructions - 8270151: IncompatibleClassChangeError on empty pattern switch statement case - 8269146: Missing unreported constraints on pattern and other case label combination - 8269952: compiler/vectorapi/VectorCastShape*Test.java tests failed on avx2 machines - 8269840: Update Platform.isDefaultCDSArchiveSupported() to return true for aarch64 platforms The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4748&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4748&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/4748/files Stats: 691 lines in 29 files changed: 544 ins; 66 del; 81 mod Patch: https://git.openjdk.java.net/jdk/pull/4748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4748/head:pull/4748 PR: https://git.openjdk.java.net/jdk/pull/4748

1 1

[jdk17] RFR: JDK-8268826: Cleanup Override in Context-Specific Deserialization Filters
by Roger Riggs 09 Jul '21

09 Jul '21

Remove the unnecessary special case "OVERRIDE" in jdk.serialFilterFactory property. Fix description in the example of a filter allowing platform classes. Suppress some warnings about use of SecurityManager in tests. ------------- Commit messages: - JDK-8268827: Cleanup Implement Context-Specific Deserialization Filters Changes: https://git.openjdk.java.net/jdk17/pull/85/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=85&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268826 Stats: 29 lines in 4 files changed: 10 ins; 13 del; 6 mod Patch: https://git.openjdk.java.net/jdk17/pull/85.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/85/head:pull/85 PR: https://git.openjdk.java.net/jdk17/pull/85

3 18

[jdk17] RFR: 8269840: Update Platform.isDefaultCDSArchiveSupported() to return true for Linux-aarch64
by Mikhailo Seledtsov 09 Jul '21

09 Jul '21

Now that "JDK-8268212 Build linux-aarch64 natively" added support for default CDS archive, time to update test configuration for this platform. This is a very small one-line change. ------------- Commit messages: - 8269840: Update Platform.isDefaultCDSArchiveSupported() to return true for Linux-aarch64 Changes: https://git.openjdk.java.net/jdk17/pull/229/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=229&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269840 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk17/pull/229.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/229/head:pull/229 PR: https://git.openjdk.java.net/jdk17/pull/229

3 6

RFR: Merge jdk17
by Jesper Wilhelmsson 08 Jul '21

08 Jul '21

Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8269722: NPE in HtmlDocletWriter - 8270109: ProblemList 4 SA tests on macOS-aarch64 - 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF - 8269738: AssertionError when combining pattern matching and function closure - 8269828: corrections in some instruction patterns for KNL x86 platform - 8268766: Desugaring of pattern matching enum switch should be improved - 8270006: Switches with 'case null:' should be exhaustive - 8269746: C2: assert(!in->is_CFG()) failed: CFG Node with no controlling input? The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4734&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4734&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/4734/files Stats: 675 lines in 22 files changed: 514 ins; 69 del; 92 mod Patch: https://git.openjdk.java.net/jdk/pull/4734.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4734/head:pull/4734 PR: https://git.openjdk.java.net/jdk/pull/4734

1 2

[jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF
by Brian Burkhalter 08 Jul '21

08 Jul '21

Modify the specification of `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is returned instead of `0` when the stream is at its end and the third parameter, `len`, is zero. ------------- Commit messages: - 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF Changes: https://git.openjdk.java.net/jdk17/pull/189/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=189&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6766844 Stats: 18 lines in 2 files changed: 12 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk17/pull/189.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/189/head:pull/189 PR: https://git.openjdk.java.net/jdk17/pull/189

4 14