On Mon, 23 Nov 2020 22:35:05 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_compare_exchange` on t
> 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 oth
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
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, as the pro
> 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 oth
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 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 hash style was forced with
On Sat, 5 Sep 2020 20:13:18 GMT, Joe Darcy wrote:
> 8251549: Update docs on building for Git
This pull request has now been integrated.
Changeset: 042734cc
Author:Joe Darcy
URL: https://git.openjdk.java.net/jdk/commit/042734cc
Stats: 68 lines in 1 file changed: 12 ins; 37 del; 19
> 8251549: Update docs on building for Git
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Update doc/building.md
Co-authored-by: Magnus Ihse Bursie
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/21/files
On Mon, 23 Nov 2020 11:23:55 GMT, Magnus Ihse Bursie 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 hash style was fo
On Fri, 20 Nov 2020 17:55:55 GMT, Naoto Sato wrote:
> Hi,
>
> Please review the changes to the subject issue. This is to incorporate the
> latest language subtag registry definition into the JDK.
This pull request has now been integrated.
Changeset: ae0ca743
Author:Naoto Sato
URL:
On Mon, 26 Oct 2020 11:41:16 GMT, Magnus Ihse Bursie wrote:
>> Some notes (perhaps most to myself) about how this ties into the existing
>> hsdis implementation, and with JDK-8188073 (Capstone porting).
>>
>> When printing disassembly from hotspot, the current solution tries to locate
>> and l
On Mon, 23 Nov 2020 15:08:13 GMT, Sean Mullan wrote:
> This change removes five root certificates with 1024-bit RSA public keys from
> the system-wide `cacerts` keystore. These are older VeriSign and Thawte root
> CA certificates which are no longer necessary to retain and should have
> minima
On Mon, 23 Nov 2020 12:37:47 GMT, Magnus Ihse Bursie wrote:
>> .github/workflows/submit.yml line 1367:
>>
>>> 1365: git apply p.patch
>>> 1366: working-directory: jdk
>>> 1367: shell: bash
>>
>> This should be in the mainline repo instead. Yes, the absence of this patc
On Wed, 18 Nov 2020 00:29:36 GMT, Paul Sandoz wrote:
>> Jim Laskey has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 40 commits:
>>
>> - Merge branch 'master' into 8248862
>> - 8248862: Implement Enhanced Pseudo-Random Number Gene
On Mon, 23 Nov 2020 12:01:14 GMT, Aleksey Shipilev 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 be
On Mon, 23 Nov 2020 14:57:59 GMT, Jim Laskey wrote:
>> src/java.base/share/classes/module-info.java line 250:
>>
>>> 248: exports jdk.internal.util.xml.impl to
>>> 249: jdk.jfr;
>>> 250: exports jdk.internal.util.random;
>>
>> Unqualified export, should this be `to jdk.random`?
On Tue, 17 Nov 2020 23:46:12 GMT, Paul Sandoz wrote:
>> Jim Laskey has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 40 commits:
>>
>> - Merge branch 'master' into 8248862
>> - 8248862: Implement Enhanced Pseudo-Random Number Gene
This change removes five root certificates with 1024-bit RSA public keys from
the system-wide `cacerts` keystore. These are older VeriSign and Thawte root CA
certificates which are no longer necessary to retain and should have minimal
compatibility risk if removed.
See the CSR for more details:
On Tue, 17 Nov 2020 21:22:28 GMT, Paul Sandoz wrote:
>> Jim Laskey has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 40 commits:
>>
>> - Merge branch 'master' into 8248862
>> - 8248862: Implement Enhanced Pseudo-Random Number Gene
[Sorry it took so long. Have been on break.]
From Guy:
Thanks for the forward. Here are my thoughts:
Good question from Rémi.
If we consider PRNGs to have started at about the time of von Neumann, circa
1946, then I would say that we have been inventing a new category about once
every 25 yea
On Mon, 23 Nov 2020 11:59:53 GMT, Aleksey Shipilev 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 be
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 Mon, 23 Nov 2020 10:09:08 GMT, Robin Westberg wrote:
>> Yeah, bike-shedding aside, "Linux additional" is probably fine. So if we
>> accept #1379, then it would also add "Windows additional"?
>
> Ah yeah, just saw that one. I guess just one additional column will still
> make the table too wi
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 Sat, 21 Nov 2020 00:12:30 GMT, Erik Joelsson wrote:
> After fixing JDK-8256751, I noticed that the fix-deps-file macro isn't
> actually doing the right thing at all. It seems clang on Macosx is
> inconsistent with outputting relative or absolute paths in the deps files, so
> some files end
On Mon, 23 Nov 2020 11:41:08 GMT, Magnus Ihse Bursie wrote:
>>> Otherwise this looks like something that belong in LIBJVM LIBS. In fact, if
>>> it is _only_ needed for the hotspot build, it is really where it belong.
>>> And even if it's needed in an additional library or two, it should be adde
On Mon, 23 Nov 2020 11:37:14 GMT, Aleksey Shipilev wrote:
>> This is incorrect. The `-l` prefix indicates a library to link with. As
>> such, it belongs to LIBS, not LDFLAGS.
>>
>> I'm not sure if we still have a global LIBS variable that is added to all
>> compile lines. We used to have sinc
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 Wed, 18 Nov 2020 10:35:58 GMT, Magnus Ihse Bursie wrote:
> The microsoft toolchain now supports a new "deterministic" build mode. This
> goes a long way towards building properly deterministic. Another important
> feature is that with the deterministic build mode enabled, the -pathmap flag,
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_compare_exchange` on those paths,
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 hash style was forced with
Hi Bernhard,
just some drive-by comments.
- 40-50 min builds seem to be excessive for just the hotspot build, do you
know what exactly takes that long? Is this for release and debug each or
both combined?
- Is it worth the cycles to build both release *and* debug? How probable is
it that a non-w
On Mon, 23 Nov 2020 09:59:39 GMT, Aleksey Shipilev wrote:
>> I personally think I prefer to just use a single column for the additional
>> cross compile builds, because the table becomes very big otherwise (and the
>> rows get split up). You still see the full name of the build in case
>> anyt
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 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 Fri, 20 Nov 2020 17:31:08 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
>
> .github/workflows/submit.yml line 526:
>
>> 524: echo "CC=${{ mat
On Fri, 20 Nov 2020 17:35:12 GMT, Aleksey Shipilev wrote:
>> Looks good! A few minor nits, if you want to address them.
>
> 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
> 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
> debug builds to run and provide interesting feedback, we shou
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 be downloaded from https://jdk.java.net/16/ and used for that, but then I
saw
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 hash style was forced with
On Sun, 22 Nov 2020 14:47:07 GMT, John Paul Adrian Glaubitz
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 hash styl
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_compare_exchange` on those paths,
43 matches
Mail list logo
