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:
A
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: https://git.openjdk.java.
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 R18
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 cha
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
>
> test/hotspot/jtreg/runtime/cds/appcds/
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: https://git.openjdk.java.net/
> 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 c
> 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 con
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: [cg
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 [jv
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
> need
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 enco
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 [jvm.dll+0x1db
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: https://git.openjdk.java.net/jdk/commit/8
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 a
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 en
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
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: https://git.openjdk
> 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 o
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 gre
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: tools/jl
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
>>>
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: https://g
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 l
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
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
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
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 cha
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: [cg
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
- Simplified
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
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
> 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 for
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 commit
> 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
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 t
> 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 for
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 o
> 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 for
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 fro
> 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 b
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 o
42 matches
Mail list logo