May 2021 - core-libs-dev

RFR: 8267321: Use switch expression for VarHandle$AccessMode lookup
by Claes Redestad 19 May '21

19 May '21

Using a switch expression instead of a (read-only) static `HashMap` reduces initialization overhead of `VarHandle$AccessMode`. This gets loaded earlier after JDK-8265079, so it started showing up in a few lambda startup tests. This also obsoletes a jtreg test that only verified that this map was optimally sized. ------------- Commit messages: - Remove obsolete test - Transform AccessMode name map into switch expression Changes: https://git.openjdk.java.net/jdk/pull/4102/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4102&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267321 Stats: 90 lines in 2 files changed: 31 ins; 56 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4102.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4102/head:pull/4102 PR: https://git.openjdk.java.net/jdk/pull/4102

2 3

RFR: 8267357: build breaks with -Werror option on micro benchmark added for JDK-8256973
by Jatin Bhateja 19 May '21

19 May '21

Relevant declarations modified and tested with -Werror, no longer see unchecked conversion warnings. Kindly review and approve. ------------- Commit messages: - 8267357: build breaks with -Werror option on micro benchmark added for JDK-8256973 Changes: https://git.openjdk.java.net/jdk/pull/4108/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4108&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267357 Stats: 10 lines in 1 file changed: 0 ins; 1 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/4108.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4108/head:pull/4108 PR: https://git.openjdk.java.net/jdk/pull/4108

4 4

Re: [External] : Re: JEP draft: Scope Locals
by Andrew Haley 19 May '21

19 May '21

On 5/18/21 3:19 AM, Mike Rettig wrote: > With the current proposal I can't simply flush and close at the > end of the scope because there might be a child scope that is still active. Yes, that's true. I think that what you have in mind is a more elaborate mechanism than what is proposed here, which does no more than bind values to names over a scope. There needs to be more discussion in the JEP of what this proposal isn't intended to do, and how we might cope with mutability of a scope local's values. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

2 1

RFC: Add a --validate option to the jar tool
by Jorn Vernee 18 May '21

18 May '21

Hi, I see that the jar tool has validation logic for multi-release jars that is triggered when creating or updating a jar that has a versioned file as an input. I wanted to ask what people think about the idea of exposing this validation logic directly under a --validate command line flag as well. Malformed multi-release jars can cause compilation and runtime problems because the API exposed by the jar is different across different Java versions. Exposing the validation logic directly would allow for easy validation of jar files that are suspected of being malformed multi-release jars. The validation logic is already cleanly separated into a separate Validator class in the source code, and adding a command line flag that exposes it directly is a relatively minimal change [1]. It seems like maybe the intent in the past was also to expose this validation logic directly? What's the history here? Any opinions about exposing this validation logic through a command line option? Thanks, Jorn [1] : https://github.com/openjdk/jdk/pull/3971

2 3

RFR: 8264777: Overload optimized FileInputStream::readAllBytes
by Brian Burkhalter 17 May '21

17 May '21

Please consider this request to override the `java.io.InputStream` methods `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more performant implementations. The method overrides attempt to read all requested bytes into a single array of the required size rather than composing the result from a sequence of smaller arrays. An example of the performance improvements is as follows. **readAllBytes** Before Benchmark (length) Mode Cnt Score Error Units ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 2412.031 ± 7.309 ops/s ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 212.181 ± 0.369 ops/s ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 19.860 ± 0.048 ops/s ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.298 ± 0.183 ops/s After Benchmark (length) Mode Cnt Score Error Units ReadAllBytes.readAllBytesFileInputStream 1000000 thrpt 20 8218.473 ± 43.425 ops/s ReadAllBytes.readAllBytesFileInputStream 10000000 thrpt 20 302.781 ± 1.273 ops/s ReadAllBytes.readAllBytesFileInputStream 100000000 thrpt 20 22.461 ± 0.084 ops/s ReadAllBytes.readAllBytesFileInputStream 1000000000 thrpt 20 1.502 ± 0.003 ops/s **readNBytes** `N = file_size / 2` Before Benchmark (length) Mode Cnt Score Error Units ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 5585.500 ± 153.353 ops/s ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 436.164 ± 1.104 ops/s ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 40.167 ± 0.141 ops/s ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 3.291 ± 0.211 ops/s After Benchmark (length) Mode Cnt Score Error Units ReadAllBytes.readHalfBytesFileInputStream 1000000 thrpt 20 15463.210 ± 66.045 ops/s ReadAllBytes.readHalfBytesFileInputStream 10000000 thrpt 20 561.752 ± 0.951 ops/s ReadAllBytes.readHalfBytesFileInputStream 100000000 thrpt 20 45.043 ± 0.102 ops/s ReadAllBytes.readHalfBytesFileInputStream 1000000000 thrpt 20 4.629 ± 0.035 ops/s ------------- Commit messages: - 8264777: Overload optimized FileInputStream::readAllBytes Changes: https://git.openjdk.java.net/jdk/pull/3845/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3845&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264777 Stats: 221 lines in 4 files changed: 215 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3845/head:pull/3845 PR: https://git.openjdk.java.net/jdk/pull/3845

6 27

Re: [External] : Re: JEP draft: Scope Locals
by Brian Goetz 17 May '21

17 May '21

> Let's try again: why is that important? What decisions would you > make differently if you had this information? What benefit would > come from those decisions? > > Threading is hard. Gee, thanks MIke for pointing that out to me, obviously I'm new to the topic :) > Scoped variables are also hard to get right. Combining the two without > an explicit api ignores the complexity that will arise as scoped > variables are passed to other threads. OK, now we're getting to the actual question; you obviously have some assumptions about the degree of sharing expected, that might be skipping a few steps (and then skipping some more steps by jumping to a solution). So to ask again: what patterns of access / sharing are you assuming, what risks are you anticipating, etc?

1 0

Re: [External] : Re: JEP draft: Scope Locals
by Brian Goetz 17 May '21

17 May '21

> Let's back up a lot of steps; you're deep in proposing a solution > when you've not even explained what problem you think you're > solving. So control question, which I hope will start to expose > the assumptions: > > Why do you think its important to know that a snapshot of a > variable has occurred? > > > From the JEP: > "In addition, a |Snapshot()| operation that captures the current set > of inheritable scope locals is provided. This allows context > information to be shared with asynchronous computations." > > As the provider of the scoped variable, I'd certainly like to know > that my scoped variable is being passed into a new scope. Let's try again: why is that important? What decisions would you make differently if you had this information? What benefit would come from those decisions?

1 0

RFR: 8264561: javap get NegativeArraySizeException on bad instruction
by Adam Sotona 17 May '21

17 May '21

Actual javap implementation reacts on corrupted TABLESWITCH or LOOKUPSWITCH bytecode instructions resulting to negative array allocation with NegativeArraySizeException, which is reported to user with stack trace and as serious internal error. The fix in c.s.t.classfile.Instruction is checking for negative array size of corrupted TABLESWITCH or LOOKUPSWITCH bytecode and throwing j.l.IllegalStateException instead of the NegativeArraySizeException. Another part of the fix in c.s.t.javap.CodeWriter is catching j.l.IllegalStateException and reporting it as error in the analyzed bytecode, instead of passing it up and causing serious internal javap error. ------------- Commit messages: - 8264561: javap get NegativeArraySizeException on bad instruction Changes: https://git.openjdk.java.net/jdk/pull/4061/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4061&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264561 Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4061.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4061/head:pull/4061 PR: https://git.openjdk.java.net/jdk/pull/4061

2 2

Re: [External] : Re: JEP draft: Scope Locals
by Brian Goetz 17 May '21

17 May '21

> How so? How do I know if a snapshot of my variable has occurred? Let's back up a lot of steps; you're deep in proposing a solution when you've not even explained what problem you think you're solving. So control question, which I hope will start to expose the assumptions: Why do you think its important to know that a snapshot of a variable has occurred?

1 0

Re: JEP draft: Scope Locals
by Andrew Haley 15 May '21

15 May '21

On 5/15/21 10:10 AM, Alex Otenko wrote: > ScopeLocal.where(...).run(...).finally(...) would be nice. Is that different from try ... run ... finally ? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

1 0