Integrated: 8284950: CgroupV1 detection code should consider memory.swappiness

2022-05-15 Thread xpbob
On Mon, 18 Apr 2022 09:07:31 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 & Sw

Re: RFR: 8284950: CgroupV1 detection code should consider memory.swappiness [v18]

2022-05-15 Thread xpbob
On Thu, 12 May 2022 15:56:51 GMT, Severin Gehwolf wrote: >> xpbob has updated the pull request incrementally with one additional commit >> since the last revision: >> >> rename method > > LGTM. Thanks @jerboaa and @iklam . :) - PR: https://git.openjdk.java.net/jdk/pull/8285

Re: RFR: 8282274: Compiler implementation for Pattern Matching for switch (Third Preview) [v13]

2022-05-15 Thread Jan Lahoda
> 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.htm

Re: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and XSLTErrorResources.java [v8]

2022-05-15 Thread Shruthi
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

Re: RFR: 8284950: CgroupV1 detection code should consider memory.swappiness [v18]

2022-05-15 Thread Ioi Lam
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 >> Mem

Re: RFR: 8286368: Cleanup problem lists after loom integration [v2]

2022-05-15 Thread David Holmes
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

Re: RFR: 8286368: Cleanup problem lists after loom integration [v2]

2022-05-15 Thread Leonid Mesnik
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/

Re: RFR: 8284950: CgroupV1 detection code should consider memory.swappiness

2022-05-15 Thread xpbob
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 >> M

Re: RFR: 8286368: Cleanup problem lists after loom integration [v2]

2022-05-15 Thread David Holmes
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 probl

Re: RFR: JDK-8286783: Expand use of @inheritDoc in InputStream and OutputStream subclasses

2022-05-15 Thread Pavel Rappo
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

Re: RFR: JDK-8286783: Expand use of @inheritDoc in InputStream and OutputStream subclasses

2022-05-15 Thread Alan Bateman
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

RFR: JDK-8286783: Expand use of @inheritDoc in InputStream and OutputStream subclasses

2022-05-15 Thread Joe Darcy
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 als

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v12]

2022-05-15 Thread Piotr Tarsa
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 javad

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v12]

2022-05-15 Thread Laurent Bourgès
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 javad

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v12]

2022-05-15 Thread Laurent Bourgès
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, > float

Re: RFR: 8285519: Change usages of TimeUnit.convert to TimeUnit.toXXX [v2]

2022-05-15 Thread Andrey Turbanov
> 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) > @Measurem