Following the [JDK-8255796](https://bugs.openjdk.java.net/browse/JDK-8255796)
improvement that ditched the inline contiguous alloc use from Zero, we can now
rely on GC interface to hook the GCs properly. Epsilon GC does not require
anything else. Other GCs require a bit of fiddling and more test
Following the [JDK-8255796](https://bugs.openjdk.java.net/browse/JDK-8255796)
improvement that ditched the inline contiguous alloc use from Zero, we can now
rely on GC interface to hook the GCs properly. G1 and Shenandoah are a bit
special here, because they require special `Reference.get` handl
On Wed, 18 Nov 2020 09:52:22 GMT, Magnus Ihse Bursie wrote:
>> Following the
>> [JDK-8255796](https://bugs.openjdk.java.net/browse/JDK-8255796) improvement
>> that ditched the inline contiguous alloc use from Zero, we can now rely on
>> GC interface to hook the GCs properly. Epsilon GC does no
On Tue, 17 Nov 2020 19:11:45 GMT, Aleksey Shipilev wrote:
> Following the [JDK-8255796](https://bugs.openjdk.java.net/browse/JDK-8255796)
> improvement that ditched the inline contiguous alloc use from Zero, we can
> now rely on GC interface to hook the GCs properly. Epsilon GC
- [x] Linux x86_64 Zero fastdebug `hotspot_gc_shenandoah` (some lingering
> failures about non-enabled compressed oops)
> - [ ] Linux x86_64 Zero fastdebug `tier1` with `-XX:+UseG1GC`
Aleksey Shipilev has updated the pull request with a new target base due to a
merge or a rebase. The
On Fri, 20 Nov 2020 00:31:17 GMT, Magnus Ihse Bursie wrote:
>> With the new Skara tooling, we can finally enable whitespace testing for
>> build system files (makefiles and autoconf files).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one
> additional commit since the
On Fri, 20 Nov 2020 14:24:12 GMT, Robin Westberg wrote:
> Currently Linux x64 testing in GitHub Actions depends on a few non-relevant
> hotspot build-only jobs (such as zero) that prevents testing from being run
> if those build were to fail. As the tests only require the x64 release and
> deb
On Fri, 20 Nov 2020 16:14:19 GMT, Robin Westberg wrote:
>> Currently Linux x64 testing in GitHub Actions depends on a few non-relevant
>> hotspot build-only jobs (such as zero) that prevents testing from being run
>> if those build were to fail. As the tests only require the x64 release and
>>
On Fri, 20 Nov 2020 16:09:59 GMT, Robin Westberg wrote:
>> .github/workflows/submit.yml line 469:
>>
>>> 467: name: transient_jdk-linux-x64_${{
>>> needs.prerequisites.outputs.bundle_id }}
>>> 468: path: ~/jdk-linux-x64
>>> 469: if: steps.build_restore.outcome == 'fa
On Fri, 20 Nov 2020 17:31:51 GMT, Aleksey Shipilev wrote:
>> Robin Westberg has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Improve naming, fix style issues
>
> Looks good! A few minor nits, if you want to
For fun, I tried to build `linux-mips64el-zero-fastdebug`, and it cannot be
built, because linker complains:
collect2: error: ld returned 1 exit status
I believe it is a regression in 16, as GNU hash style was forced with
[JDK-8200738](https://bugs.openjdk.java.net/browse/JDK-8200738). The way
If you try to build `linux-mipsel-zero-fastdebug`, this happens:
I think it relates to
[JDK-8253970](https://bugs.openjdk.java.net/browse/JDK-8253970) that introduced
`atomic_compare_exchange` on those paths, but maybe the issue exists for
longer.
Various other reports for build failure
On Tue, 17 Nov 2020 19:02:03 GMT, Aleksey Shipilev wrote:
> Following the [JDK-8255796](https://bugs.openjdk.java.net/browse/JDK-8255796)
> improvement that ditched the inline contiguous alloc use from Zero, we can
> now rely on GC interface to hook the GCs properly. G1 and Shenand
On Thu, 19 Nov 2020 09:55:04 GMT, Magnus Ihse Bursie wrote:
>> Aleksey Shipilev has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains three commits:
>>
>> - Merge branch 'master' into JDK-8256497-ze
On Mon, 23 Nov 2020 09:54:52 GMT, Robin Westberg wrote:
>> Ah wait, I now see "Linux additional" is the column name in testing table,
>> because it is the name of the job! Eh... It was nicer to have columns per
>> arch. Does it make sense to split the "Linux x64 (other)" and "Linux
>> Foreign"
On Mon, 23 Nov 2020 09:55:34 GMT, Robin Westberg wrote:
>> .github/workflows/submit.yml line 526:
>>
>>> 524: echo "CC=${{ matrix.gnu-arch }}-linux-gnu${{
>>> matrix.gnu-flavor}}-gcc-10" >> $GITHUB_ENV
>>> 525: echo "CXX=${{ matrix.gnu-arch }}-linux-gnu${{
>>> matrix.gnu-fl
On Mon, 23 Nov 2020 11:28:05 GMT, Magnus Ihse Bursie wrote:
>> If you try to build `linux-mipsel-zero-fastdebug`, this happens:
>>
>>
>>
>>
>>
>>
>>
>> I think it relates to
>> [JDK-8253970](https://bugs.openjdk.java.net/browse/JDK-8253970) that
>> introduced `atomic_compare_exchange` on
On Mon, 23 Nov 2020 09:35:40 GMT, Bernhard Urban-Forster
wrote:
> This adds the cross-compiled build only, as no Windows+Arm64 machines are
> available on GitHub Action that we could use to run the tests.
>
> Due to cross-compilation a build JDK is required. Initially I added EA builds
> to b
On Sun, 22 Nov 2020 14:19:04 GMT, Aleksey Shipilev wrote:
> For fun, I tried to build `linux-mips64el-zero-fastdebug`, and it cannot be
> built, because linker complains:
>
>
> collect2: error: ld returned 1 exit status
>
> I believe it is a regression in 16, as GNU
On Mon, 23 Nov 2020 16:52:07 GMT, Ao Qi wrote:
>> Given that it works on MIPS, it looks good to me. Too bad gnu hash style is
>> not universally accepted. :(
>
> Sorry for the late reply. Monday is a busy day and I used a zero jdk as boot
> jdk, so the test took some time. The native build of
On Mon, 23 Nov 2020 11:37:14 GMT, Aleksey Shipilev wrote:
> So, would adding to `BASIC_JVM_LIBS` at `LIB_SETUP_LIBRARIES` step in
> `make/autoconf/libraries.m4` be a good place then?
This seems to work. It would seem only JVM is needed to be built with
`-latomic`, which makes sense,
S for MIPS, but not any other OpenJDK platform.
>
> The alternative would be to massage the otherwise generic Zero code to
> unimplement the 8-byte CAS.
>
> Attention @DamonFool, who must be running into this problem for their MIPS
> builds?
>
> Testing:
> - [x] Linux mipsel
On Mon, 23 Nov 2020 11:48:27 GMT, John Paul Adrian Glaubitz
wrote:
> As a heads-up. I have a working Loongson 2k board at home now (mips64el). So,
> in case something needs to be tested natively on MIPS, let me know.
Oh, cool! Can it build `mipsel`, not only `mips64el`? If so, please try to
c
S for MIPS, but not any other OpenJDK platform.
>
> The alternative would be to massage the otherwise generic Zero code to
> unimplement the 8-byte CAS.
>
> Attention @DamonFool, who must be running into this problem for their MIPS
> builds?
>
> Testing:
> - [x] Linux mipsel
On Tue, 24 Nov 2020 07:13:27 GMT, Magnus Ihse Bursie wrote:
>> Aleksey Shipilev has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains four commits:
>>
>> - Merge branch 'master' into JDK-8256831-mips
On 11/25/20 9:45 AM, Thomas Stüfe wrote:
"E: Failed to fetch
http://azure.archive.ubuntu.com/ubuntu/pool/main/a/alsa-lib/libasound2-dev_1.2.2-2.1ubuntu2.1_amd64.deb
404 Not Found [IP: 52.147.219.192 80]"
https://github.com/tstuefe/jdk/runs/1452221121
Does anyone have an idea?
I think this
On 11/25/20 9:49 AM, Aleksey Shipilev wrote:
On 11/25/20 9:45 AM, Thomas Stüfe wrote:
"E: Failed to fetch
http://azure.archive.ubuntu.com/ubuntu/pool/main/a/alsa-lib/libasound2-dev_1.2.2-2.1ubuntu2.1_amd64.deb
404 Not Found [IP: 52.147.219.192 80]"
https://github.com/tstuef
For example, current jobs fail with:
Get:13 http://azure.archive.ubuntu.com/ubuntu focal/main amd64 libxtst-dev
amd64 2:1.2.3-1 [15.2 kB]
E: Failed to fetch
http://azure.archive.ubuntu.com/ubuntu/pool/main/a/alsa-lib/libasound2-dev_1.2.2-2.1ubuntu2.1_amd64.deb
404 Not Found [IP: 52.147.219.192
On Wed, 25 Nov 2020 09:11:26 GMT, Robin Westberg wrote:
>> For example, current jobs fail with:
>>
>> Get:13 http://azure.archive.ubuntu.com/ubuntu focal/main amd64 libxtst-dev
>> amd64 2:1.2.3-1 [15.2 kB]
>> E: Failed to fetch
>> http://azure.archive.ubuntu.com/ubuntu/pool/main/a/alsa-lib/lib
On Wed, 25 Nov 2020 08:56:33 GMT, Aleksey Shipilev wrote:
> For example, current jobs fail with:
>
> Get:13 http://azure.archive.ubuntu.com/ubuntu focal/main amd64 libxtst-dev
> amd64 2:1.2.3-1 [15.2 kB]
> E: Failed to fetch
> http://azure.archive.ubuntu.com/ubuntu/po
On Wed, 25 Nov 2020 13:08:59 GMT, Severin Gehwolf wrote:
>> For example, current jobs fail with:
>>
>> Get:13 http://azure.archive.ubuntu.com/ubuntu focal/main amd64 libxtst-dev
>> amd64 2:1.2.3-1 [15.2 kB]
>> E: Failed to fetch
>> http://azure.archive.ubuntu.com/ubuntu/pool/main/a/alsa-lib/li
On Thu, 26 Nov 2020 11:10:43 GMT, Ao Qi wrote:
>> Thanks, I'll wait for either of @glaubitz, @theaoqi or @xiangzhai to confirm
>> this fixes the native `mipsel` builds for them, and then integrate.
>
> The native build of linux-mipsel-zero-release passed. I only have mips64el
> and 64-bit OS, s
On Sun, 22 Nov 2020 14:40:12 GMT, Aleksey Shipilev wrote:
> If you try to build `linux-mipsel-zero-fastdebug`, this happens:
>
>
>
>
>
>
>
> I think it relates to
> [JDK-8253970](https://bugs.openjdk.java.net/browse/JDK-8253970) that
> introduced `atomic
Sample build log sizes:
PPC64 fastdebug, 200 kilobytes:
https://builds.shipilev.net/openjdk-jdk/build-logs/build-linux-ppc64le-fastdebug.log
S390X fastdebug, 20 megabytes!
https://builds.shipilev.net/openjdk-jdk/build-logs/build-linux-s390x-server-fastdebug.log
S390X slowdebug, 200 megab
On Thu, 26 Nov 2020 15:55:52 GMT, Lutz Schmidt wrote:
>> Sample build log sizes:
>>
>> PPC64 fastdebug, 200 kilobytes:
>>
>> https://builds.shipilev.net/openjdk-jdk/build-logs/build-linux-ppc64le-fastdebug.log
>>
>> S390X fastdebug, 20 megabytes!
>>
>> https://builds.shipilev.net/openjd
On Thu, 26 Nov 2020 15:18:04 GMT, Aleksey Shipilev wrote:
> Sample build log sizes:
>
> PPC64 fastdebug, 200 kilobytes:
>
> https://builds.shipilev.net/openjdk-jdk/build-logs/build-linux-ppc64le-fastdebug.log
>
> S390X fastdebug, 20 megabytes!
>
> https://
On Thu, 26 Nov 2020 21:57:58 GMT, Lutz Schmidt wrote:
>> Thanks. Trivial, right? (So I can push now?)
>
> Yes, sure. Push it, if you haven’t already.
> Didn’t Martin give you a review as well?
>
> Sorry, I took a few off-screen (or screen off) hours.
>
> Thanks,
> Lutz
>
> From: Aleksey Shipil
On Tue, 1 Dec 2020 10:09:33 GMT, Magnus Ihse Bursie wrote:
> According to the enhancement request:
>
> It would be nice and convenient to include the configuration name in the
> configuration summary, for example ("Name" being new):
>
> Configuration summary:
> * Name: my-conf
> * Debug level:
On Wed, 2 Dec 2020 10:01:03 GMT, Magnus Ihse Bursie wrote:
> JDK-8251549 updated doc/building.md for building with git, but did not
> include corresponding updates to doc/building.html.
Looks good!
-
Marked as reviewed by shade (Reviewer).
PR: https://git.openjdk.java.net/jdk/pul
On Mon, 7 Dec 2020 19:34:26 GMT, Bernhard Urban-Forster
wrote:
>> This adds the cross-compiled build only, as no Windows+Arm64 machines are
>> available on GitHub Action that we could use to run the tests.
>>
>> Due to cross-compilation a build JDK is required. Initially I added EA
>> builds
On Tue, 8 Dec 2020 06:58:49 GMT, Aleksey Shipilev wrote:
>> Bernhard Urban-Forster has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> merge mistakes
>
> Minor nits.
Also merge from master to get the
On Wed, 9 Dec 2020 07:22:51 GMT, Bernhard Urban-Forster
wrote:
>> This adds the cross-compiled build only, as no Windows+Arm64 machines are
>> available on GitHub Action that we could use to run the tests.
>>
>> Due to cross-compilation a build JDK is required. Initially I added EA
>> builds
Hi,
Thanks for the testing and the report, Matthias!
On 12/11/20 11:29 AM, Magnus Ihse Bursie wrote:
If we need -latomic on certain platforms we should add it on those
platforms, but I would prefer not to add it unconditionally. But then
again, if you want to add it for a bunch of system which
JDK-8256831 added the Zero linkage with libatomic for MIPS, but there are other
32-bit Zero platforms that need the same kind of treatment.
Additional testing:
- [x] linux-mipsel-zero-fastdebug build
-
Commit messages:
- 8259043: More Zero architectures need linkage with libatomi
On Fri, 25 Dec 2020 10:11:13 GMT, Hao Sun
wrote:
> From the error log we can see the root cause is that, develop_pd flag
> 'pd_CICompileOSR' is undeclared in zero build.
>
> Where this flag is used?
> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77
> of 'compiler_globals.
On Tue, 5 Jan 2021 00:12:58 GMT, Ioi Lam wrote:
>>> `#include "runtime/globals_shared.hpp"` should not be removed.
>>> compiler_globals.hpp uses the `DECLARE_FLAGS` macro, which is defined by
>>> globals_shared.hpp.
>>
>> Since globals_shared.hpp is included in compiler_globals_pd.hpp, I think
On Tue, 5 Jan 2021 04:54:32 GMT, Hao Sun
wrote:
> The tests were finished but one of them failed. I found that this failure
> existed for several days (in other PRs) and I suppose it's not related to our
> patch.
Yes, the failure you caught does not look related to this PR.
-
PR
On Tue, 5 Jan 2021 12:06:18 GMT, Hao Sun
wrote:
>> From the error log we can see the root cause is that, develop_pd flag
>> 'pd_CICompileOSR' is undeclared in zero build.
>>
>> Where this flag is used?
>> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77
>> of 'compiler_glo
On Tue, 5 Jan 2021 12:06:18 GMT, Hao Sun
wrote:
>> From the error log we can see the root cause is that, develop_pd flag
>> 'pd_CICompileOSR' is undeclared in zero build.
>>
>> Where this flag is used?
>> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77
>> of 'compiler_glo
On Tue, 5 Jan 2021 14:28:14 GMT, Hao Sun
wrote:
>> Marked as reviewed by jiefu (Committer).
>
> Thanks for your reviews! @DamonFool @iklam @shipilev
>
> The pre-submit tests were passed except the GC one which is not related to
> this patch. I suppose this patch is ready to be merged now.
Sp
On Mon, 4 Jan 2021 18:42:05 GMT, Erik Joelsson wrote:
>> JDK-8256831 added the Zero linkage with libatomic for MIPS, but there are
>> other 32-bit Zero platforms that need the same kind of treatment.
>>
>> Additional testing:
>> - [x] linux-mipsel-zero-fastdebug build
>
> Marked as reviewed b
On Mon, 4 Jan 2021 08:34:02 GMT, Aleksey Shipilev wrote:
> JDK-8256831 added the Zero linkage with libatomic for MIPS, but there are
> other 32-bit Zero platforms that need the same kind of treatment.
>
> Additional testing:
> - [x] linux-mipsel-zero-fastdebug build
This p
On Tue, 12 Jan 2021 06:46:33 GMT, liach
wrote:
> Though this content seems simple, it would be extremely frustrating to
> newcomers, especially when the build stalls at "cannot find valid visual
> studio installation" for no clear reason in logs at all.
Marked as reviewed by shade (Reviewer).
Current Windows GH Actions fails with:
configure: using
/cygdrive/c/progra~2/micros~1/2019/Enterprise/vc/auxiliary/build/vcvarsx86_amd64.bat
configure: Setting extracted environment variables for x86_64
checking that Visual Studio variables have been correctly extracted... ok
checking for cl... [
When `libc6*:i386` packages are installed as the dependency of other packages,
they seem to run into configure problems. It helps to install them ahead of the
bulk of the packages to resolve this.
-
Commit messages:
- 8259924: GitHub actions fail on Linux x86_32 with "Could not con
ure 'libc6:i386'.
> E: Could not perform immediate configuration on 'libgcc-s1:i386'. Please see
> man 5 apt.conf under APT::Immediate-Configure for details. (2)
Aleksey Shipilev has updated the pull request with a new target base due to a
merge or a rebase. The incremental
On Mon, 18 Jan 2021 13:02:59 GMT, Aleksey Shipilev wrote:
> Current Windows GH Actions fails with:
>
> configure: using
> /cygdrive/c/progra~2/micros~1/2019/Enterprise/vc/auxiliary/build/vcvarsx86_amd64.bat
> configure: Setting extracted environment variables for x86_64
> ch
On Mon, 18 Jan 2021 13:57:18 GMT, Aleksey Shipilev wrote:
> When `libc6*:i386` packages are installed as the dependency of other
> packages, they seem to run into configure problems. It helps to install them
> ahead of the bulk of the packages to resolve this.
>
> Current Linu
I was following up on performance testing results for some ongoing work, and
realized that there are `ShenandoahMarkContext::mark_strong` calls from
`mark_work_loop`. Those callees were supposed to be inlined. I believe it is a
simple omission after JDK-8255019 moved `mark_work_loop` code to
`s
On Tue, 26 Jan 2021 11:41:52 GMT, Aleksey Shipilev wrote:
> I was following up on performance testing results for some ongoing work, and
> realized that there are `ShenandoahMarkContext::mark_strong` calls from
> `mark_work_loop`. Those callees were supposed to be inlined. I believe i
On Tue, 26 Jan 2021 12:42:10 GMT, Magnus Ihse Bursie wrote:
>> I was following up on performance testing results for some ongoing work, and
>> realized that there are `ShenandoahMarkContext::mark_strong` calls from
>> `mark_work_loop`. Those callees were supposed to be inlined. I believe it is
See for example:
https://github.com/shipilev/jdk/runs/1771453139?check_suite_focus=true
E: Could not configure 'libc6:i386'.
E: Could not perform immediate configuration on 'libgcc-s1:i386'. Please see
man 5 apt.conf under APT::Immediate-Configure for details. (2)
It seems JDK-8259924 helped on
On Wed, 27 Jan 2021 08:18:56 GMT, Magnus Ihse Bursie wrote:
>> See for example:
>> https://github.com/shipilev/jdk/runs/1771453139?check_suite_focus=true
>>
>> E: Could not configure 'libc6:i386'.
>> E: Could not perform immediate configuration on 'libgcc-s1:i386'. Please see
>> man 5 apt.conf
On Tue, 26 Jan 2021 19:08:41 GMT, Aleksey Shipilev wrote:
> See for example:
> https://github.com/shipilev/jdk/runs/1771453139?check_suite_focus=true
>
> E: Could not configure 'libc6:i386'.
> E: Could not perform immediate configuration on 'libgcc-s1:i386'.
On Wed, 27 Jan 2021 10:46:04 GMT, Magnus Ihse Bursie wrote:
>> Okay to push now, as to unbreak the GHA?
>
> Yeah..? What are you waiting for otherwise? The 24 hour rule only apply to
> Hotspot coce.
I believe 24 hour rule is the generic courtesy rule for everything. So I was
asking explicitly
On 2/1/21 4:38 PM, Andrew Haley wrote:
but that doesn't work either. Any ideas? I'm really stuck.
Did you "make clean" after changing any of the configure files and/or configure arguments? I.e. did
AWTIcon32_java_icon16_png actually regenerate?
Prepending the build with "LOG=debug" would tel
Configuration summary:
* Name: linux-alpha-zero-slowdebug
* Debug level: slowdebug
* HS debug level: debug
* JVM variants: zero
* JVM features: zero: 'epsilongc g1gc jni-check jvmti management nmt parallelgc
serialgc services vm-structs zero'
* OpenJDK target: OS: linux, CPU architecture: alpha, a
On Fri, 5 Feb 2021 10:19:18 GMT, Magnus Ihse Bursie wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Drop -Werror
>
> Changes requested by ihse (Reviewer).
> Apparently so. Bu
es
>
> Linux Zero alpha configure now says:
>
> checking if CC supports "-fstack-protector -Werror"... no
> checking if CXX supports "-fstack-protector -Werror"... no
> checking if both CC and CXX support "-fstack-protector -Werror"... no
>
>
On Fri, 5 Feb 2021 11:13:19 GMT, John Paul Adrian Glaubitz
wrote:
> I think you should just add a hack to your CI to work around this issue until
> OpenJDK has moved to gcc-10.
Right. `--disable-warnings-as-errors` seems to be working as the workaround.
I'll close this issue as WNF, instead o
On Fri, 5 Feb 2021 09:38:03 GMT, Aleksey Shipilev wrote:
> Configuration summary:
> * Name: linux-alpha-zero-slowdebug
> * Debug level: slowdebug
> * HS debug level: debug
> * JVM variants: zero
> * JVM features: zero: 'epsilongc g1gc jni-check jvmti management nmt
On 2/23/21 2:37 PM, Chris W. Johnson wrote:
I'm experiencing an OpenJDK build failure on macOS 10.15.7 with OpenJDK 15.0.2
(15.0.2+7-27) and Xcode 12.4 installed. Specifically, a compilation error on line 2849 of
"src/hotspot/share/runtime/sharedRuntime.cpp" (see below).
I'm finishing-up a (wo
Current cross-compilation configurations require adding the whole lot of
configure options to make it find the dependencies: freetype and X11 libs are
the only problematic dependencies. We should be able to specify just the
`--with-sysroot`, and get everything else autodetected.
After this patc
On Thu, 4 Mar 2021 19:34:16 GMT, Erik Joelsson wrote:
>> make/autoconf/lib-freetype.m4 line 201:
>>
>>> 199: if test "x$FOUND_FREETYPE" != "xyes" ; then
>>> 200: LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include],
>>> 201:
>>> [$FREETYPE_BASE_DIR/lib/$OPEN
On Fri, 5 Mar 2021 07:06:24 GMT, Aleksey Shipilev wrote:
>> I think that value should be accessible from OPENJDK_TARGET_AUTOCONF_NAME.
>
> Yes, original `openjdk-target` would be enough. Unfortunately,
> `AUTOCONF_NAME` seems to be the quadruplet generated from original
>
cross-target `powerpc64-linux-gnu`
> - [x] Configure with cross-target `powerpc64le-linux-gnu`
> - [x] Configure with cross-target `m68k-linux-gnu`
> - [x] Configure with cross-target `sh4-linux-gnu`
Aleksey Shipilev has updated the pull request incrementally with one additional
commit
cross-target `powerpc64-linux-gnu`
> - [x] Configure with cross-target `powerpc64le-linux-gnu`
> - [x] Configure with cross-target `m68k-linux-gnu`
> - [x] Configure with cross-target `sh4-linux-gnu`
Aleksey Shipilev has updated the pull request incrementally with one additional
On Fri, 5 Mar 2021 14:06:05 GMT, Erik Joelsson wrote:
>> What I can do is parse the ABI from the original string, and then
>> reconstruct the triplet as `$OPENJDK_TARGET_CPU-linux-$OPENJDK_TARGET_ABI`.
>> See the update.
>
> This is certainly much better. Would it make sense to replace "linux"
On Thu, 4 Mar 2021 18:58:03 GMT, Aleksey Shipilev wrote:
> Current cross-compilation configurations require adding the whole lot of
> configure options to make it find the dependencies: freetype and X11 libs are
> the only problematic dependencies. We should be able to specify
On Mon, 8 Mar 2021 16:11:20 GMT, Magnus Ihse Bursie wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Replace with linux with TARGET_OS
>
> make/autoconf/platform.m4 l
On Mon, 8 Mar 2021 23:29:25 GMT, Magnus Ihse Bursie wrote:
>> I thought we need to declare these as `AC_SUBST` as we define the variables
>> outside this file? I can revert these additions if you think these are
>> incorrect.
>
> No, they are only needed to be able to populate the @FOO@ tags in
On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote:
>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related
>> to Ahead-of-Time Compiler from JDK:
>>
>> - `jdk.aot` module — the `jaotc` tool
>> - `src/hotspot/share/aot` — loads AoT compiled code into VM for execution
After [JDK-8257913](https://bugs.openjdk.java.net/browse/JDK-8257913), we do
not need to set a whole lot of options for cross-compiled builds. Docs should
be updated to reflect that fact. Also put in more configurations that are
buildable with Debian ports: these build routinely at
[builds.ship
On Sun, 18 Apr 2021 17:33:56 GMT, John Paul Adrian Glaubitz
wrote:
>> After [JDK-8257913](https://bugs.openjdk.java.net/browse/JDK-8257913), we do
>> not need to set a whole lot of options for cross-compiled builds. Docs
>> should be updated to reflect that fact. Also put in more configuration
On Fri, 16 Apr 2021 11:57:32 GMT, Aleksey Shipilev wrote:
> After [JDK-8257913](https://bugs.openjdk.java.net/browse/JDK-8257913), we do
> not need to set a whole lot of options for cross-compiled builds. Docs should
> be updated to reflect that fact. Also put in more configurations
On Fri, 16 Apr 2021 11:57:32 GMT, Aleksey Shipilev wrote:
> After [JDK-8257913](https://bugs.openjdk.java.net/browse/JDK-8257913), we do
> not need to set a whole lot of options for cross-compiled builds. Docs should
> be updated to reflect that fact. Also put in more configurations
On Wed, 5 May 2021 07:54:20 GMT, Thomas Stuefe wrote:
> Harfbuzz upgrade broke Linux x64 build on older gccs. For details see JBS
> issue.
>
> I fixed the issue in the harfbuzz sources, but I am not sure of the policy
> here. Do we modify the harfbuzz sources or leave them untouched? Advice is
On Mon, 17 May 2021 13:24:16 GMT, Jie Fu wrote:
> Hi all,
>
> vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our
> many-core machines due to `-XX:MaxRAMPercentage=0`.
> This is because `MaxRAMPercentage` will be always 0 if JTREG_JOBS > 25 [1].
>
> It can be reproduced
On Mon, 17 May 2021 13:24:16 GMT, Jie Fu wrote:
> Hi all,
>
> vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our
> many-core machines due to `-XX:MaxRAMPercentage=0`.
> This is because `MaxRAMPercentage` will be always 0 if JTREG_JOBS > 25 [1].
>
> It can be reproduced
On Mon, 17 May 2021 13:24:16 GMT, Jie Fu wrote:
> Hi all,
>
> vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our
> many-core machines due to `-XX:MaxRAMPercentage=0`.
> This is because `MaxRAMPercentage` will be always 0 if JTREG_JOBS > 25 [1].
>
> It can be reproduced
On 5/17/21 7:30 PM, [email protected] wrote:
Oh, if it's double, we can just switch to using awk to make the
calculation, just like we do for TEST_JOBS. I just did a quick check and
it produces float values.
Oh, cool. Having a more precise MaxRAMPercentage would be nice.
--
Thanks,
-Ale
On Tue, 18 May 2021 03:35:11 GMT, Jie Fu wrote:
>> Hi all,
>>
>> vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our
>> many-core machines due to `-XX:MaxRAMPercentage=0`.
>> This is because `MaxRAMPercentage` will be always 0 if JTREG_JOBS > 25 [1].
>>
>> It can be repr
It seems Ubuntu had bumped the version for GCC, so GHA started to fail with
e.g.:
The following packages have unmet dependencies:
g++-10-s390x-linux-gnu : Depends: gcc-10-s390x-linux-gnu-base (=
10.2.0-5ubuntu1~20.04cross1) but 10.3.0-1ubuntu1~20.04cross1 is to be installed
gcc-10-s390x-linux
On Tue, 22 Jun 2021 17:20:14 GMT, Aleksey Shipilev wrote:
> It seems Ubuntu had bumped the version for GCC, so GHA started to fail with
> e.g.:
>
>
> The following packages have unmet dependencies:
> g++-10-s390x-linux-gnu : Depends: gcc-10-s390x-linux-gnu-base (=
On Tue, 22 Jun 2021 17:20:14 GMT, Aleksey Shipilev wrote:
> It seems Ubuntu had bumped the version for GCC, so GHA started to fail with
> e.g.:
>
>
> The following packages have unmet dependencies:
> g++-10-s390x-linux-gnu : Depends: gcc-10-s390x-linux-gnu-base (=
Hi Matthias,
On 7/1/21 1:28 PM, Matthias Klose wrote:
what's the status of this? Trying to run the tests for 17+29 using jtreg 6+1, I
get:
I saw a similar problem with some custom jtreg builds. IIRC, that happens when jtreg6 source is
built with "old" make/build-all.sh, not with the new "mak
On Thu, 15 Jul 2021 04:04:08 GMT, Ao Qi wrote:
> LoongArch is a new RISC ISA. This issue proposes adding Zero support for
> LoongArch. Only 64-bit support is proposed at present.
>
> linux-loongarch64-zero-{release, fastdebug} build tested:
>
> $ ./build/linux-loongarch64-zero-fastdebug/jdk/bi
On Thu, 15 Jul 2021 07:42:33 GMT, Ao Qi wrote:
>> LoongArch is a new RISC ISA. This issue proposes adding Zero support for
>> LoongArch. Only 64-bit support is proposed at present.
>>
>> linux-loongarch64-zero-{release, fastdebug} build tested:
>>
>> $ ./build/linux-loongarch64-zero-fastdebug/
On Wed, 21 Jul 2021 02:02:06 GMT, Rajan Halade wrote:
> This CA had no code signing certificates issued so it is safe to remove it
> from cacerts truststore.
Looks like a clean removal to me. Approving so this can be backported to JDK
Updates that would be after the cert expiry date.
It is currently at 1.28, and thus misses a bunch of fixes and improvements.
1.32 is the latest version, and probably the last version before enabling the
automatic detection of compiler blackholes (CODETOOLS-7903004), the change that
would affect benchmarks performance.
-
Commit me
1 - 100 of 428 matches
Mail list logo
