Re: RFR: 8282274: Compiler implementation for Pattern Matching for switch (Third Preview) [v13]
> 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 incrementally with one additional commit since the last revision: Fixing test - restoring accidentally removed condition. - Changes: - all: https://git.openjdk.java.net/jdk/pull/8182/files - new: https://git.openjdk.java.net/jdk/pull/8182/files/e903084a..22991958 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8182=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8182=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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: 8285097: Duplicate XML keys in XPATHErrorResources.java and XSLTErrorResources.java [v8]
On Fri, 13 May 2022 18:51:47 GMT, Joe Wang wrote: >> Shruthi has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental views will show differences >> compared to the previous content of the PR. The pull request contains one >> new commit since the last revision: >> >> Modify copyright year > > Did you mean the failure (Pre-submit tests - Linux x86 - Test (tier1) ) > above? That's not related to your change. @JoeWang-Java Yes. Shall I comment as **integrate** then? - PR: https://git.openjdk.java.net/jdk/pull/8318
Re: RFR: 8284950: CgroupV1 detection code should consider memory.swappiness [v18]
On Thu, 12 May 2022 13:46:11 GMT, xpbob wrote: >> set memory.swappiness to 0,swap space will not be used >> determine the value of memory.swappiness >> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt >> >> >> Memory Limit: 50.00M >> Memory Soft Limit: Unlimited >> Memory & Swap Limit: 100.00M >> Maximum Processes Limit: 4194305 >> >> => >> >> Memory Limit: 50.00M >> Memory Soft Limit: Unlimited >> Memory & Swap Limit: 50.00M >> Maximum Processes Limit: 4194305 > > xpbob has updated the pull request incrementally with one additional commit > since the last revision: > > rename method LGTM - Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8285
Re: RFR: 8286368: Cleanup problem lists after loom integration [v2]
On Mon, 16 May 2022 02:25:26 GMT, Leonid Mesnik wrote: >> test/hotspot/jtreg/ProblemList-Xcomp.txt line 38: >> >>> 36: serviceability/sa/TestJhsdbJstackMixed.java 8248675 linux-aarch64 >>> 37: >>> 38: compiler/c2/irTests/TestSkeletonPredicates.java 8286361 generic-all >> >> @lmesnik This line should not have been removed! > > It might be a merge problem. My PR was submitted before 8286442. I remereged > changes, however my merge commit also doesn't have removal of this line: > https://github.com/openjdk/jdk/pull/8604/commits/8255e760ff1a2ff616f00f559de29e66d7036b39 > > So I am really confused and can't understand how I managed to introduce this > problem. That is really bizarre. No individual commit shows the line being deleted, yet in the final commit it is. - PR: https://git.openjdk.java.net/jdk/pull/8604
Re: RFR: 8286368: Cleanup problem lists after loom integration [v2]
On Mon, 16 May 2022 01:23:09 GMT, David Holmes wrote: >> Leonid Mesnik has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains two commits: >> >> - Merge >> - 8286368: Cleanup problem lists after loom integration > > test/hotspot/jtreg/ProblemList-Xcomp.txt line 38: > >> 36: serviceability/sa/TestJhsdbJstackMixed.java 8248675 linux-aarch64 >> 37: >> 38: compiler/c2/irTests/TestSkeletonPredicates.java 8286361 generic-all > > @lmesnik This line should not have been removed! It might be a merge problem. My PR was submitted before 8286442. I remereged changes, however my merge commit also doesn't have removal of this line: https://github.com/openjdk/jdk/pull/8604/commits/8255e760ff1a2ff616f00f559de29e66d7036b39 So I am really confused and can't understand how I managed to introduce this problem. - PR: https://git.openjdk.java.net/jdk/pull/8604
Re: RFR: 8284950: CgroupV1 detection code should consider memory.swappiness
On Wed, 20 Apr 2022 06:53:39 GMT, Ioi Lam wrote: >> set memory.swappiness to 0,swap space will not be used >> determine the value of memory.swappiness >> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt >> >> >> Memory Limit: 50.00M >> Memory Soft Limit: Unlimited >> Memory & Swap Limit: 100.00M >> Maximum Processes Limit: 4194305 >> >> => >> >> Memory Limit: 50.00M >> Memory Soft Limit: Unlimited >> Memory & Swap Limit: 50.00M >> Maximum Processes Limit: 4194305 > > I changed the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8284900) > summary to "CgroupV1 detection code should consider memory.swappiness" @iklam , are you also fine with the latest change? Thanks. - PR: https://git.openjdk.java.net/jdk/pull/8285
Re: RFR: 8286368: Cleanup problem lists after loom integration [v2]
On Tue, 10 May 2022 19:16:34 GMT, Leonid Mesnik wrote: >> 8286368: Cleanup problem lists after loom integration > > Leonid Mesnik has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains two commits: > > - Merge > - 8286368: Cleanup problem lists after loom integration test/hotspot/jtreg/ProblemList-Xcomp.txt line 38: > 36: serviceability/sa/TestJhsdbJstackMixed.java 8248675 linux-aarch64 > 37: > 38: compiler/c2/irTests/TestSkeletonPredicates.java 8286361 generic-all @lmesnik This line should not have been removed! - PR: https://git.openjdk.java.net/jdk/pull/8604
Re: RFR: JDK-8286783: Expand use of @inheritDoc in InputStream and OutputStream subclasses
On Sun, 15 May 2022 18:36:07 GMT, Joe Darcy wrote:
> Make the javadoc in the InputStream and OutputStream subclasses in core libs
> DRY-er by use of inheritDoc. (Any analagous changes to AudioInputStream in
> client libs will be done another a separate bug.) When the time comes, will
> do any necessary merging for the changes in[JDK-8286200.
>
> Please also review the CSR to cover the introduction of implspec and implNote
> tags: https://bugs.openjdk.java.net/browse/JDK-8286784
1. One the one hand, it's not clear to me what criterion was used for adding
`@Override` annotations. On the other hand, the more `@Override` annotations a
codebase has, the better.
2. Have you compared the resulting documentation before and after the change?
Aside from added `@implSpec` and `@implNote`, were there anything anything
different?
3. I wonder if it makes sense to also reduce the size of the doc comments by
changing explicit documentation inheritance for the `@param` and `@return` tags
to implicit one, i.e. removing the tags on the overrider's side.
src/java.base/share/classes/java/io/SequenceInputStream.java line 217:
> 215: * before the {@code close} method returns.
> 216: *
> 217: * @throws IOException {@inheritDoc}
Unexpected re-indentation; other similar cases do not have it.
-
PR: https://git.openjdk.java.net/jdk/pull/8717
Re: RFR: JDK-8286783: Expand use of @inheritDoc in InputStream and OutputStream subclasses
On Sun, 15 May 2022 18:36:07 GMT, Joe Darcy wrote: > Make the javadoc in the InputStream and OutputStream subclasses in core libs > DRY-er by use of inheritDoc. (Any analagous changes to AudioInputStream in > client libs will be done another a separate bug.) When the time comes, will > do any necessary merging for the changes in[JDK-8286200. > > Please also review the CSR to cover the introduction of implspec and implNote > tags: https://bugs.openjdk.java.net/browse/JDK-8286784 Picking FileInputStream at random, I wonder if the `@inheritDoc` on transferTo is needed. Also, I think you've attempted to add `@Override` to all overridden methods but some may have been missed (e.g. readAllBytes and readNBytes). - PR: https://git.openjdk.java.net/jdk/pull/8717
RFR: JDK-8286783: Expand use of @inheritDoc in InputStream and OutputStream subclasses
Make the javadoc in the InputStream and OutputStream subclasses in core libs DRY-er by use of inheritDoc. (Any analagous changes to AudioInputStream in client libs will be done another a separate bug.) When the time comes, will do any necessary merging for the changes in[JDK-8286200. Please also review the CSR to cover the introduction of implspec and implNote tags: https://bugs.openjdk.java.net/browse/JDK-8286784 - Commit messages: - JDK-8286783: Expand use of @inheritDoc in InputStream and OutputStream subclasses Changes: https://git.openjdk.java.net/jdk/pull/8717/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8717=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286783 Stats: 190 lines in 13 files changed: 49 ins; 45 del; 96 mod Patch: https://git.openjdk.java.net/jdk/pull/8717.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8717/head:pull/8717 PR: https://git.openjdk.java.net/jdk/pull/8717
Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v12]
On Mon, 14 Mar 2022 19:12:29 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on >> int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single >> element >> - minor javadoc and comment changes >> >> Testing: >> - add new data inputs in tests for sorting >> - add min/max/infinity values to float/double testing >> - add tests for radix sort > > iaroslavski has updated the pull request incrementally with one additional > commit since the last revision: > > JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) > > * Improved mixed insertion sort > * Optimized insertion sort > * Improved merging sort > * Optimized soring tests i think it would make much more sense to have the extra buffer size limit in bytes, not in elements. for single-threaded sorting the limit should be low, e.g. 1/64 of the heap, not 1/8 (in case of sorting e.g. longs as each long is 8 byte long). multi-threaded sorting could be more aggressive when it comes to resource usage as it's less likely to be used in resource constrained environment. - PR: https://git.openjdk.java.net/jdk/pull/3938
Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v12]
On Mon, 14 Mar 2022 19:12:29 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on >> int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single >> element >> - minor javadoc and comment changes >> >> Testing: >> - add new data inputs in tests for sorting >> - add min/max/infinity values to float/double testing >> - add tests for radix sort > > iaroslavski has updated the pull request incrementally with one additional > commit since the last revision: > > JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) > > * Improved mixed insertion sort > * Optimized insertion sort > * Improved merging sort > * Optimized soring tests I checked the latest code: line 128: Max length of additional buffer, limited by max_heap / 64 or 256mb elements (2gb max). private static final int MAX_BUFFER_LENGTH = (int) Math.min(Runtime.getRuntime().maxMemory() >> 6, 256L << 20); So the current upper limit concerns the max length = max_heap_bytes / 64 (max heap/8) or 2gb (if heap is huge). - PR: https://git.openjdk.java.net/jdk/pull/3938
Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v12]
On Fri, 13 May 2022 17:48:50 GMT, Piotr Tarsa wrote: > allocating extra buffers and catching OOME when sorting primitives is rather > unsatisfactory. you're not giving a reliable option for sorting under low > memory conditions. IMO at least the single-threaded primitives (ints, longs, > floats, etc all non-objects) sorting should be frugal when it comes to memory > usage. > > just my 2 cents. DPQS uses several sorting algorithms, merge sort & new radix sort need an extra buffer in contrary to isort, mixed isort, single and dual pivot quick sort. In this PR an upper limit on the heap usage is in use min(max heap / 16, 128mb) to reduce the memory footprint. Anyway catching OOME now permits DPQS to use in-place but slower algorithms if the extra buffer can not be allocated. Possibly the upper limit could be made configurable using system properties if it is really critical. To sum up, low allocations are now under control in this PR. - PR: https://git.openjdk.java.net/jdk/pull/3938
Re: RFR: 8285519: Change usages of TimeUnit.convert to TimeUnit.toXXX [v2]
> TimeUnit.toMillis/toNanos/toMicros/toSeconds is shorter and a bit faster.
> Compared via JMH benchmark: 150ns -> 125ns/op
>
> Benchamark adapted from
> http://cr.openjdk.java.net/~shade/8152083/TimeUnitBench.java
>
>
> @Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
> @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
> @Fork(1)
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class TimeUnitBench {
>
> static final int SIZE = TimeUnit.values().length * 10;
>
> @Param({"0", "1", "2", "3", "4", "5", "6", "-1"})
> int bias;
>
> TimeUnit[] mod;
>
> @Setup
> public void setup() {
> mod = new TimeUnit[SIZE];
>
> TimeUnit[] vals = TimeUnit.values();
> for (int c = 0; c < SIZE; c++) {
> if (bias == -1) {
> // megamorphic
> mod[c] = vals[c % vals.length];
> } else {
> mod[c] = vals[bias];
> }
> }
>
> Random r = new Random();
> for (int c = 0; c < 1; c++) {
> int i = r.nextInt();
> for (int o = 0; o < vals.length; o++) {
> if (vals[o].toNanos(i) != TimeUnit.NANOSECONDS.convert(i,
> vals[o]))
> throw new IllegalStateException("switch " + o);
> }
> }
> }
>
> @Benchmark
> public void const_convert(Blackhole bh) {
> for (TimeUnit tu : mod) {
> bh.consume(do_convert(tu));
> }
> }
>
> @Benchmark
> public void value_convert(Blackhole bh) {
> for (TimeUnit tu : mod) {
> bh.consume(do_convert(tu, 1L));
> }
> }
>
> @Benchmark
> public void const_toNanos(Blackhole bh) {
> for (TimeUnit tu : mod) {
> bh.consume(do_toNanos(tu));
> }
> }
>
> @Benchmark
> public void value_toNanos(Blackhole bh) {
> for (TimeUnit tu : mod) {
> bh.consume(do_toNanos(tu, 1L));
> }
> }
>
> @CompilerControl(CompilerControl.Mode.DONT_INLINE)
> private long do_toNanos(TimeUnit tu) {
> return tu.toNanos(1L);
> }
>
> @CompilerControl(CompilerControl.Mode.DONT_INLINE)
> private long do_toNanos(TimeUnit tu, long value) {
> return tu.toNanos(value);
> }
>
> @CompilerControl(CompilerControl.Mode.DONT_INLINE)
> private long do_convert(TimeUnit tu) {
> return TimeUnit.NANOSECONDS.convert(1L, tu);
> }
>
> @CompilerControl(CompilerControl.Mode.DONT_INLINE)
> private long do_convert(TimeUnit tu, long value) {
> return TimeUnit.NANOSECONDS.convert(value, tu);
> }
> }
>
> Results:
>
> Benchmark(bias) Mode CntScoreError Units
> TimeUnitBench.const_convert 0 avgt5 151,856 ± 28,595 ns/op
> TimeUnitBench.const_convert 1 avgt5 150,720 ± 23,863 ns/op
> TimeUnitBench.const_convert 2 avgt5 151,432 ± 23,184 ns/op
> TimeUnitBench.const_convert 3 avgt5 150,959 ± 24,726 ns/op
> TimeUnitBench.const_convert 4 avgt5 150,966 ± 25,280 ns/op
> TimeUnitBench.const_convert 5 avgt5 150,976 ± 25,542 ns/op
> TimeUnitBench.const_convert 6 avgt5 151,118 ± 25,254 ns/op
> TimeUnitBench.const_convert -1 avgt5 152,673 ± 29,861 ns/op
> TimeUnitBench.const_toNanos 0 avgt5 121,296 ± 25,236 ns/op
> TimeUnitBench.const_toNanos 1 avgt5 121,707 ± 25,364 ns/op
> TimeUnitBench.const_toNanos 2 avgt5 121,736 ± 25,726 ns/op
> TimeUnitBench.const_toNanos 3 avgt5 121,822 ± 25,491 ns/op
> TimeUnitBench.const_toNanos 4 avgt5 121,867 ± 26,090 ns/op
> TimeUnitBench.const_toNanos 5 avgt5 121,927 ± 25,611 ns/op
> TimeUnitBench.const_toNanos 6 avgt5 121,821 ± 25,843 ns/op
> TimeUnitBench.const_toNanos -1 avgt5 121,923 ± 25,206 ns/op
> TimeUnitBench.value_convert 0 avgt5 150,525 ± 25,439 ns/op
> TimeUnitBench.value_convert 1 avgt5 151,098 ± 24,024 ns/op
> TimeUnitBench.value_convert 2 avgt5 151,259 ± 25,381 ns/op
> TimeUnitBench.value_convert 3 avgt5 151,030 ± 25,548 ns/op
> TimeUnitBench.value_convert 4 avgt5 151,290 ± 25,998 ns/op
> TimeUnitBench.value_convert 5 avgt5 151,006 ± 25,448 ns/op
> TimeUnitBench.value_convert 6 avgt5 150,945 ± 25,314 ns/op
> TimeUnitBench.value_convert -1 avgt5 151,186 ± 25,814 ns/op
> TimeUnitBench.value_toNanos 0 avgt5 121,556 ± 25,745 ns/op
> TimeUnitBench.value_toNanos 1 avgt5 123,410 ± 22,323 ns/op
> TimeUnitBench.value_toNanos 2 avgt5 125,452 ± 26,575 ns/op
> TimeUnitBench.value_toNanos 3 avgt5 125,297 ± 26,204 ns/op
> TimeUnitBench.value_toNanos 4 avgt5 125,357 ± 26,085 ns/op
>
