Re: 8251989: Unified Hex formatting and parsing utility

2020-09-28 Thread Brian Goetz
Minor nit:     Appendable foo(Appendable bar) should be     A foo(A bar) That way, if you say     hex.formatHex(aStringBuilder, bytes)    .foo() where foo() is a method on StringBuilder but not on Appendable, it will still work as expected. On 9/28/2020 11:32 AM, Roger Riggs wrote:

Re: RFR: 8253714: [cgroups v2] Soft memory limit incorrectly using memory.high

2020-09-28 Thread Bob Vandette
On Mon, 28 Sep 2020 16:00:57 GMT, Severin Gehwolf wrote: > @bobvandette Could you please take a look? Thanks! I just verified that using --memory-reservation using my crun version 0.11.42 does result in memory.low being set to the reservation value. - PR:

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10]

2020-09-28 Thread Vladimir Kempik
On Mon, 28 Sep 2020 14:07:16 GMT, Monica Beckwith wrote: >> This is a continuation of >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around

Re: RFR: 8253714: [cgroups v2] Soft memory limit incorrectly using memory.high [v2]

2020-09-28 Thread Bob Vandette
On Mon, 28 Sep 2020 17:34:54 GMT, Severin Gehwolf wrote: >> Tests using `--memory-reservation` started to fail with newer `crun` cgroups >> v2-capable runtime. It turns out it was >> incorrectly setting `memory.high` in an early version and got fixed to set >> `memory.low` now instead. This

Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive [v3]

2020-09-28 Thread Yumin Qi
On Fri, 25 Sep 2020 21:45:13 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 8247536: Support for pre-generated java.lang.invoke classes in CDS static >> archive > >

Re: RFR: 8253714: [cgroups v2] Soft memory limit incorrectly using memory.high

2020-09-28 Thread Severin Gehwolf
On Mon, 28 Sep 2020 16:06:22 GMT, Severin Gehwolf wrote: > Note that due to JDK-8253727 not all tests are passing with newer crun > runtime (0.8 was last working for me). All cgroups v2 container tests pass with #384 and this one on `crun 0.15`. - PR:

Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive [v6]

2020-09-28 Thread Yumin Qi
> This patch is reorganized after 8252725, which is separated from this patch > to refactor jlink glugin code. The previous > webrev with hg can be found at: > http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 > integrated, the > regeneration of holder classes is simply to

Re: RFR: 8253714: [cgroups v2] Soft memory limit incorrectly using memory.high [v2]

2020-09-28 Thread Severin Gehwolf
> Tests using `--memory-reservation` started to fail with newer `crun` cgroups > v2-capable runtime. It turns out it was > incorrectly setting `memory.high` in an early version and got fixed to set > `memory.low` now instead. This change > accounts for that. Severin Gehwolf has refreshed the

RFR: 8253727: [cgroups v2] Memory and swap limits reported incorrectly

2020-09-28 Thread Severin Gehwolf
Account for interface files for swap and memory being reported independently. The cgroup v1-like value is now reported by adding the memory.max value to the memory.swap.max value. Testing: Container tests on Linux x86_64 on cgroups v2 with crun 0.15 - Commit messages: - 8253727:

Re: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding

2020-09-28 Thread CoreyAshford
On Mon, 28 Sep 2020 16:35:59 GMT, CoreyAshford wrote: >> AOT support needs an update: >> # Internal Error (jdk/src/hotspot/share/aot/aotCodeHeap.cpp:557), >> pid=345656, tid=364316 >> # guarantee(adr != NULL) failed: AOT Symbol not found >> _aot_stub_routines_base64_decodeBlock >> >> V

Re: RFR: 8159746: (proxy) Support for default methods

2020-09-28 Thread Mandy Chung
On Mon, 28 Sep 2020 16:26:17 GMT, Peter Levart wrote: > @AlanBateman you meant to say throwing CCE for mismatching parameter case > would make it **inconsistent** with > Method.invoke, right? That's easy to change. We just catch CCE (and NPE?) and > re-throw them wrapped in IAE. We don't >

Re: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding

2020-09-28 Thread CoreyAshford
On Fri, 25 Sep 2020 13:45:15 GMT, Roger Riggs wrote: >> This patch set encompasses the following commits: >> >> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - >> decodeBlock(), and provides a flexible API for >> the intrinsic. The API is similar to the existing

Re: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding

2020-09-28 Thread CoreyAshford
On Sat, 26 Sep 2020 15:33:29 GMT, Martin Doerr wrote: > AOT support needs an update: > # Internal Error (jdk/src/hotspot/share/aot/aotCodeHeap.cpp:557), pid=345656, > tid=364316 > # guarantee(adr != NULL) failed: AOT Symbol not found > _aot_stub_routines_base64_decodeBlock > > V

Integrated: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64

2020-09-28 Thread Daniel D . Daugherty
On Mon, 28 Sep 2020 16:05:48 GMT, Daniel D. Daugherty wrote: > 8253667: ProblemList tools/jlink/JLinkReproducible{,3}Test.java on > linux-aarch64 This pull request has now been integrated. Changeset: 821bd08c Author:Daniel D. Daugherty URL:

Re: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64 [v2]

2020-09-28 Thread Daniel D . Daugherty
On Mon, 28 Sep 2020 16:16:08 GMT, Daniel Fuchs wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update existing entry for tools/jlink/JLinkReproducibleTest.java instead >> of creating a new one. > > Marked

Re: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64 [v2]

2020-09-28 Thread Igor Ignatyev
On Mon, 28 Sep 2020 16:32:52 GMT, Daniel D. Daugherty wrote: >> 8253667: ProblemList tools/jlink/JLinkReproducible{,3}Test.java on >> linux-aarch64 > > Daniel D. Daugherty has updated the pull request incrementally with one > additional commit since the last revision: > > Update existing

Re: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64 [v2]

2020-09-28 Thread Yumin Qi
On Mon, 28 Sep 2020 16:17:21 GMT, Igor Ignatyev wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update existing entry for tools/jlink/JLinkReproducibleTest.java instead >> of creating a new one. > > Marked

Re: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64 [v2]

2020-09-28 Thread Daniel D . Daugherty
On Mon, 28 Sep 2020 16:28:48 GMT, Yumin Qi wrote: >> Marked as reviewed by iignatyev (Reviewer). > > Should we put this for all platforms? Nope. We're currently seeing these failures on linux-aarch64 so that's what started this ProblemListing adventure... - PR:

Re: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64 [v2]

2020-09-28 Thread Daniel D . Daugherty
> 8253667: ProblemList tools/jlink/JLinkReproducible{,3}Test.java on > linux-aarch64 Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: Update existing entry for tools/jlink/JLinkReproducibleTest.java instead of creating a new

Re: RFR: 8159746: (proxy) Support for default methods

2020-09-28 Thread Peter Levart
On Mon, 28 Sep 2020 13:47:04 GMT, Alan Bateman wrote: >> Hi Mandy, >> In general this looks good but one thing. The Proxy::invokeDefaultMethod >> does a lot of checks (creating derived method >> handles just to check parameters etc.) for every invocation and that means >> performance is not

Re: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64

2020-09-28 Thread Igor Ignatyev
On Mon, 28 Sep 2020 16:16:52 GMT, Igor Ignatyev wrote: >> 8253667: ProblemList tools/jlink/JLinkReproducible{,3}Test.java on >> linux-aarch64 > > test/jdk/ProblemList.txt line 859: > >> 857: tools/jlink/JLinkReproducibleTest.java 8217166 >> windows-all >> 858:

Re: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64

2020-09-28 Thread Daniel D . Daugherty
On Mon, 28 Sep 2020 16:22:17 GMT, Igor Ignatyev wrote: >> test/jdk/ProblemList.txt line 859: >> >>> 857: tools/jlink/JLinkReproducibleTest.java >>> 8217166 windows-all >>> 858: tools/jlink/plugins/CompressorPluginTest.java >>> 8247407 generic-all >>>

Re: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64

2020-09-28 Thread Daniel D . Daugherty
On Mon, 28 Sep 2020 16:05:48 GMT, Daniel D. Daugherty wrote: > 8253667: ProblemList tools/jlink/JLinkReproducible{,3}Test.java on > linux-aarch64 @AlanBateman - not sure if 'core-libs' was the right label to add so I figured I would ping you directly for a review. - PR:

RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64

2020-09-28 Thread Daniel D . Daugherty
8253667: ProblemList tools/jlink/JLinkReproducible{,3}Test.java on linux-aarch64 - Commit messages: - Merge branch 'master' into JDK-8253667 - Also ProblemList tools/jlink/JLinkReproducible3Test.java due to 8253688. - 8253667: ProblemList tools/jlink/JLinkReproducibleTest.java on

Re: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64

2020-09-28 Thread Daniel Fuchs
On Mon, 28 Sep 2020 16:05:48 GMT, Daniel D. Daugherty wrote: > 8253667: ProblemList tools/jlink/JLinkReproducible{,3}Test.java on > linux-aarch64 Marked as reviewed by dfuchs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/382

Re: RFR: 8253667: ProblemList tools/jlink/JLinkReproducible{, 3}Test.java on linux-aarch64

2020-09-28 Thread Igor Ignatyev
On Mon, 28 Sep 2020 16:05:48 GMT, Daniel D. Daugherty wrote: > 8253667: ProblemList tools/jlink/JLinkReproducible{,3}Test.java on > linux-aarch64 Marked as reviewed by iignatyev (Reviewer). test/jdk/ProblemList.txt line 859: > 857: tools/jlink/JLinkReproducibleTest.java

Re: RFR: 8253714: [cgroups v2] Soft memory limit incorrectly using memory.high

2020-09-28 Thread Severin Gehwolf
On Mon, 28 Sep 2020 15:59:35 GMT, Severin Gehwolf wrote: > Tests using `--memory-reservation` started to fail with newer `crun` cgroups > v2-capable runtime. It turns out it was > incorrectly setting `memory.high` in an early version and got fixed to set > `memory.low` now instead. This change

Re: RFR: 8253714: [cgroups v2] Soft memory limit incorrectly using memory.high

2020-09-28 Thread Severin Gehwolf
On Mon, 28 Sep 2020 16:00:57 GMT, Severin Gehwolf wrote: >> Tests using `--memory-reservation` started to fail with newer `crun` cgroups >> v2-capable runtime. It turns out it was >> incorrectly setting `memory.high` in an early version and got fixed to set >> `memory.low` now instead. This

RFR: 8253714: [cgroups v2] Soft memory limit incorrectly using memory.high

2020-09-28 Thread Severin Gehwolf
Tests using `--memory-reservation` started to fail with newer `crun` cgroups v2-capable runtime. It turns out it was incorrectly setting `memory.high` in an early version and got fixed to set `memory.low` now instead. This change accounts for that. - Commit messages: - 8253714:

Re: 8251989: Unified Hex formatting and parsing utility

2020-09-28 Thread Roger Riggs
After some reflection on the comments, suggestions, and other advice offered the Hex format API has undergone a significant rewrite. The improvements include:  - Merged format and parse classes into a single class HexFormat that holds parameters and has methods for all conversions  -

Re: RFR(S): 8252407: Build failure with gcc-8+ and asan

2020-09-28 Thread Eric Liu
Hi, Thanks for looking at this. For gcc-10, it's hard to make 'strncpy' all right with asan enabled (approaches we talked previous don't work). I'm trying to find a better way to avoid using compile pragma. I suppose it would be better to use 'memcpy' to replace 'strncpy'. Thanks, Eric

Re: [Lambda]parallel sort stream slow than series sort

2020-09-28 Thread Simon Roberts
Hi Tony, At this point, I would venture 1) This is still the wrong forum. I would think that stackoverflow is a far more appropriate place for discussions about how to use an api. This one, as best I understand it, is about *developing* those libraries. 2) Concurrency inevitably *increases* the

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10]

2020-09-28 Thread Monica Beckwith
> This is a continuation of > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will > be enabled

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6]

2020-09-28 Thread Bernhard Urban-Forster
On Thu, 24 Sep 2020 15:43:10 GMT, Chris Plummer wrote: >> Monica Beckwith 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 17 additional

Re: RFR: 8218685: jlink --list-plugins needs to be readable and tidy [v4]

2020-09-28 Thread Ian Graves
> These changes update the jlink plugin command line documentation to tidy them > up into a more canonical form. > > The output generated by jlink from this change appears as follows: > >> build/macosx-x64/images/jdk/bin/jlink --list-plugins > > List of available plugins: > --strip-debug

Re: RFR: 8159746: (proxy) Support for default methods

2020-09-28 Thread Alan Bateman
On Sun, 27 Sep 2020 17:09:03 GMT, Peter Levart wrote: >> This proposes a new static `Proxy::invokeDefaultMethod` method to invoke >> the given default method on the given proxy instance. >> >> The implementation looks up a method handle for `invokespecial` instruction >> as if called from with

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v9]

2020-09-28 Thread Monica Beckwith
> This is a continuation of > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will > be enabled

Re: RFR: 8252537: Updated @exception with @throws [v4]

2020-09-28 Thread Roger Riggs
On Sun, 27 Sep 2020 12:46:21 GMT, Vipin Sharma wrote: >> Updated @exception with @throws for core-libs, it fixes all open sub-tasks >> of JDK-8252536. >> >> Open Subtasks part of this fix are: >> 1. JDK-8252537 >> 2. JDK-8252539 >> 3. JDK-8252540 >> 4. JDK-8252541 >> >> Previous conversation

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v8]

2020-09-28 Thread Monica Beckwith
> This is a continuation of > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will > be enabled

Re: RFR: 8253426: jpackage is unable to generate working EXE for add-launcher … [v3]

2020-09-28 Thread Alexander Zuev
On Fri, 25 Sep 2020 21:05:23 GMT, Andy Herrick wrote: >> 8253426: jpackage is unable to generate working EXE for add-launcher >> configurations. >> secondary launchers ignored module, main-jar, and main-class in launcher >> properties file because the LAUNCHER_DATA >> param was not removed

Re: RFR: 8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions [v6]

2020-09-28 Thread Jatin Bhateja
> Summary: > > 1) New AVX3 optimized stubs for both conjoint and disjoint arraycopy. > 2) Special instruction sequence blocks for copy sizes b/w 32-192 bytes. > 3) Block copy operation above 192 bytes is performed using destination > address aligned PRE-MAIN-POST loop. Main loop > copies 192

Re: RFR: 8252537: Updated @exception with @throws [v4]

2020-09-28 Thread Lance Andersen
On Sun, 27 Sep 2020 12:46:21 GMT, Vipin Sharma wrote: >> Updated @exception with @throws for core-libs, it fixes all open sub-tasks >> of JDK-8252536. >> >> Open Subtasks part of this fix are: >> 1. JDK-8252537 >> 2. JDK-8252539 >> 3. JDK-8252540 >> 4. JDK-8252541 >> >> Previous conversation