On Wed, 23 Jul 2025 16:20:52 GMT, Aleksey Shipilev wrote:
> I have noticed that GHA jobs started to fail when creating ppc64el sysroot.
> We are using Debian bullseye as the base for sysroots. Debian bullseye is LTS
> release. Perhaps counter-intuitively, LTS platform support shrinks
On Wed, 23 Jul 2025 16:20:52 GMT, Aleksey Shipilev wrote:
> I have noticed that GHA jobs started to fail when creating ppc64el sysroot.
> We are using Debian bullseye as the base for sysroots. Debian bullseye is LTS
> release. Perhaps counter-intuitively, LTS platform support shrinks
On Wed, 23 Jul 2025 16:20:52 GMT, Aleksey Shipilev wrote:
> I have noticed that GHA jobs started to fail when creating ppc64el sysroot.
> We are using Debian bullseye as the base for sysroots. Debian bullseye is LTS
> release. Perhaps counter-intuitively, LTS platform support shrinks
On Mon, 28 Jul 2025 08:43:25 GMT, Fei Gao wrote:
>> Marked as reviewed by aph (Reviewer).
>
> Thanks for your approval @theRealAph @shipilev !
@fg1417 -- want to pull it to `jdk25u`? I think it is not a showstopper for JDK
25 GA, so we can get it into `25.0.1`.
-
PR Comment: https
On Fri, 25 Jul 2025 08:12:51 GMT, Aleksey Shipilev wrote:
> Thanks! More reviews, please?
Ping :)
-
PR Comment: https://git.openjdk.org/jdk/pull/26447#issuecomment-3126292006
On Wed, 23 Jul 2025 16:20:52 GMT, Aleksey Shipilev wrote:
> I have noticed that GHA jobs started to fail when creating ppc64el sysroot.
> We are using Debian bullseye as the base for sysroots. Debian bullseye is LTS
> release. Perhaps counter-intuitively, LTS platform support shrinks
On Thu, 24 Jul 2025 16:02:41 GMT, Fei Gao wrote:
> This patch fixes a typo introduced in
> [JDK-8353217](https://github.com/openjdk/jdk/commit/130b0cdaa6604da47a893e5425547acf3d5253f4),
> which incorrectly disabled SVE vector math symbols. As a result, some vector
> math test cases such as `jd
On Wed, 23 Jul 2025 16:20:52 GMT, Aleksey Shipilev wrote:
> I have noticed that GHA jobs started to fail when creating ppc64el sysroot.
> We are using Debian bullseye as the base for sysroots. Debian bullseye is LTS
> release. Perhaps counter-intuitively, LTS platform support shrinks
On Mon, 7 Jul 2025 09:24:20 GMT, Aleksey Shipilev wrote:
> Installing MSYS2 takes considerable time in our Windows workflows.
> Fortunately, GHA runners currently ship with MSYS2 bundled! The docs for
> setup-msys2 step say it is enough to say `release: false` to use those:
On Wed, 23 Jul 2025 16:20:52 GMT, Aleksey Shipilev wrote:
> I have noticed that GHA jobs started to fail when creating ppc64el sysroot.
> We are using Debian bullseye as the base for sysroots. Debian bullseye is LTS
> release. Perhaps counter-intuitively, LTS platform support shrinks
I have noticed that GHA jobs started to fail when creating ppc64el sysroot. We
are using Debian bullseye as the base for sysroots. Debian bullseye is LTS
release. Perhaps counter-intuitively, LTS platform support shrinks over the LTS
lifetime. Debian wiki: https://wiki.debian.org/LTS/Using -- sa
On Mon, 7 Jul 2025 09:24:20 GMT, Aleksey Shipilev wrote:
> Installing MSYS2 takes considerable time in our Windows workflows.
> Fortunately, GHA runners currently ship with MSYS2 bundled! The docs for
> setup-msys2 step say it is enough to say `release: false` to use those:
se
>
> Also bumping the action version to gain access to the actual installed path.
>
> Additional testing:
> - [x] GHA
Aleksey Shipilev 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
On Fri, 18 Jul 2025 08:03:19 GMT, Aleksey Shipilev wrote:
> I have now seen GHA runs where we spend more than 24 hours for a testing
> workflow. The practical effect of this is that bundles that we current carry
> with `retention-days: 1` gets purged before jobs can use them.
On Fri, 18 Jul 2025 08:03:19 GMT, Aleksey Shipilev wrote:
> I have now seen GHA runs where we spend more than 24 hours for a testing
> workflow. The practical effect of this is that bundles that we current carry
> with `retention-days: 1` gets purged before jobs can use them.
On Fri, 18 Jul 2025 08:03:19 GMT, Aleksey Shipilev wrote:
> I have now seen GHA runs where we spend more than 24 hours for a testing
> workflow. The practical effect of this is that bundles that we current carry
> with `retention-days: 1` gets purged before jobs can use them.
On Fri, 18 Jul 2025 08:19:12 GMT, Thomas Stuefe wrote:
> :-( What tests are those, are they special runs? Or the standard ones?
No, just normal ones. @GoeLin showed me
https://github.com/openjdk-bots/jdk21u-dev/actions/runs/16302821665/job/46063676040
this morning, but I see there are others i
I have now seen GHA runs where we spend more than 24 hours for a testing
workflow. The practical effect of this is that bundles that we current carry
with `retention-days: 1` gets purged before jobs can use them. This then fails
the test jobs that e.g. unable to pull jtreg.
This seems to happen
On Mon, 7 Jul 2025 09:24:20 GMT, Aleksey Shipilev wrote:
> Installing MSYS2 takes considerable time in our Windows workflows.
> Fortunately, GHA runners currently ship with MSYS2 bundled! The docs for
> setup-msys2 step say it is enough to say `release: false` to use those:
On Tue, 8 Jul 2025 11:35:26 GMT, Julian Waters wrote:
> I recall there were some issues with using MSYS2 that comes with Actions.
> That was a long time ago though, are they no longer a problem with current
> Actions and MSYS2 versions?
We used to have a problem building jtreg, so we pinned an
Installing MSYS2 takes considerable time in our Windows workflows. Fortunately,
GHA runners currently ship with MSYS2 bundled! The docs for setup-msys2 step
say it is enough to say `release: false` to use those:
https://github.com/msys2/setup-msys2?tab=readme-ov-file#release
Also bumping the ac
On Fri, 4 Jul 2025 15:30:56 GMT, Aleksey Shipilev wrote:
>> In our current GHA workflows, we only run workflows in branches in personal
>> forks. GHA isolation rules say that workflow caches from the parent branches
>> can be used by descendant branches. For our branches, t
On Fri, 4 Jul 2025 15:30:56 GMT, Aleksey Shipilev wrote:
>> In our current GHA workflows, we only run workflows in branches in personal
>> forks. GHA isolation rules say that workflow caches from the parent branches
>> can be used by descendant branches. For our branches, t
On Fri, 4 Jul 2025 13:21:40 GMT, Aleksey Shipilev wrote:
> In our current GHA workflows, we only run workflows in branches in personal
> forks. GHA isolation rules say that workflow caches from the parent branches
> can be used by descendant branches. For our branches, the usual
On Fri, 4 Jul 2025 14:24:00 GMT, Severin Gehwolf wrote:
> > GHA isolation rules say that workflow caches from the parent branches can
> > be used by descendant branches.
>
> Is a corollary of that that one ought to keep one's fork `master` branch in
> sync with the main repo's (`openjdk/jdk`)
.
> (If you want to make this experiment in current GHA, trigger the existing
> workflow on `master` branch in your fork, it would do roughly the same, but
> with all builds/tests).
>
> A sample "dry-run" can be seen here:
> https://github.com/shipilev/jdk/a
On Thu, 3 Jul 2025 11:00:28 GMT, Jan Kratochvil wrote:
>> https://github.com/jankratochvil/jdk21u-dev/actions/runs/16026488095/job/45215623689
>> [build.sh][INFO] Downloading
>> https://archive.apache.org/dist/ant/binaries/apache-ant-1.10.8-bin.zip to
>> /home/runner/work/jdk21u-dev/jdk21u-dev/
In our current GHA workflows, we only run workflows in branches in personal
forks. GHA isolation rules say that workflow caches from the parent branches
can be used by descendant branches. For our branches, the usual parent is
`master`. Since we do not run workflows on `master`, this means every
On Thu, 3 Jul 2025 12:39:23 GMT, Aleksey Shipilev wrote:
> Not each time, once per PR, then it gets cached :) It is a small consolation,
> though. It would be better once I have enough mental fortitude to complete
> [JDK-8343546](https://bugs.openjdk.org/browse/JDK-8343546) -- t
On Thu, 3 Jul 2025 10:55:50 GMT, Magnus Ihse Bursie wrote:
> A recent run in the Oracle CI produced the following:
>
> Creating ct.sym classes
> /bin/bash: $WS/build/linux-aarch64-open/jdk/bin/java: No such file or
> directory
> modules/jdk.compiler/Gendata.gmk:72: recipe for target
> '$WS/bui
On Thu, 3 Jul 2025 10:19:15 GMT, Magnus Ihse Bursie wrote:
> It's really a bummer that we need to build jtreg each time we run a GHA test.
> :-(
Not each time, once per PR, then it gets cached :) It is a small consolation,
though. It would be better once I have enough mental fortitude to compl
On Thu, 3 Jul 2025 11:00:28 GMT, Jan Kratochvil wrote:
>> https://github.com/jankratochvil/jdk21u-dev/actions/runs/16026488095/job/45215623689
>> [build.sh][INFO] Downloading
>> https://archive.apache.org/dist/ant/binaries/apache-ant-1.10.8-bin.zip to
>> /home/runner/work/jdk21u-dev/jdk21u-dev/
On Mon, 23 Jun 2025 16:43:47 GMT, Aleksey Shipilev wrote:
> Fixes GHA for jdk25 branch as well, following the switch to windows-2025
> runners in late JDK 25.
>
> Additional testing:
> - [ ] GHA
This pull request has now been integrated.
Changeset: 7cc1f82b
Author:Alekse
On Mon, 23 Jun 2025 16:43:47 GMT, Aleksey Shipilev wrote:
> Fixes GHA for jdk25 branch as well, following the switch to windows-2025
> runners in late JDK 25.
>
> Additional testing:
> - [ ] GHA
Thanks!
-
PR Comment: https://git.openjdk.org/jdk/pull/259
Fixes GHA for jdk25 branch as well, following the switch to windows-2025
runners in late JDK 25.
Additional testing:
- [ ] GHA
-
Commit messages:
- Backport 72679c94ee00c87b9b51233938e5ffa97ef825b1
Changes: https://git.openjdk.org/jdk/pull/25939/files
Webrev: https://webrevs.op
On Mon, 23 Jun 2025 08:09:14 GMT, Aleksey Shipilev wrote:
>> See the bug for extended details about this little mess.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains one commit:
>
> Try
On Fri, 20 Jun 2025 08:36:30 GMT, Aleksey Shipilev wrote:
> See the bug for extended details about this little mess.
This pull request has now been integrated.
Changeset: 72679c94
Author: Aleksey Shipilev
URL:
https://git.openjdk.org/jdk/com
On Fri, 20 Jun 2025 08:36:30 GMT, Aleksey Shipilev wrote:
> See the bug for extended details about this little mess.
Looks like `20250617.1.0` runner image have been deployed. We can go in with
this PR now. Please review.
-
PR Comment: https://git.openjdk.org/jdk/pull/25
> See the bug for extended details about this little mess.
Aleksey Shipilev has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains one commit:
Try 14.44
-
Changes: https://git.openjdk.org/jdk/pull/25912/files
Webrev: ht
On Fri, 20 Jun 2025 11:16:52 GMT, Antonio Vieiro wrote:
>> See the bug for extended details about this little mess.
>
> Looks like [it cannot find a C
> compiler](https://github.com/openjdk/jdk/blob/8f121a173ca2534c706682f6c68fbbb0b94ec057/make/autoconf/toolchain.m4#L469)
> on `windows-x64`...
On Fri, 20 Jun 2025 08:36:30 GMT, Aleksey Shipilev wrote:
> See the bug for extended details about this little mess.
Great, I can see that new runner image does _not_ like `14.43`. So we are in
weird spot at the moment:
- Old runner image works with `14.43`, fails with `14.44`
- New run
See the bug for extended details about this little mess.
-
Commit messages:
- Try 14.44
Changes: https://git.openjdk.org/jdk/pull/25912/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25912&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8360042
Stats: 2 lines in 1
On Wed, 4 Jun 2025 17:03:07 GMT, Magnus Ihse Bursie wrote:
>> GitHub is retiring the windows-2019 runner, starting with brownouts now, and
>> complete removal in about a month. We need to upgrade to Windows 2022 or
>> possible Windows 2025.
>
> Magnus Ihse Bursie has updated the pull request in
On Tue, 3 Jun 2025 19:56:37 GMT, Magnus Ihse Bursie wrote:
> GitHub is retiring the windows-2019 runner, starting with brownouts now, and
> complete removal in about a month. We need to upgrade to Windows 2022 or
> possible Windows 2025.
Pretty sure it will just work (tm). I'll hang around for
On Wed, 4 Jun 2025 16:55:12 GMT, Magnus Ihse Bursie wrote:
>> .github/workflows/main.yml line 313:
>>
>>> 311: with:
>>> 312: platform: windows-x64
>>> 313: msvc-toolset-version: '14.43'
>>
>> I wish I understood why `14.43`, since I don't see any reference to it in
>> current
On Tue, 3 Jun 2025 19:56:37 GMT, Magnus Ihse Bursie wrote:
> GitHub is retiring the windows-2019 runner, starting with brownouts now, and
> complete removal in about a month. We need to upgrade to Windows 2022 or
> possible Windows 2025.
.github/workflows/main.yml line 313:
> 311: with:
>
On Mon, 2 Jun 2025 16:24:28 GMT, Magnus Ihse Bursie wrote:
> `make bootcycle-images` broke after JDK-8349665, with the symptom:
>
>
> jdk.internal.md.interim/module-info.java:51: error: module not found:
> jdk.compiler.interim
> requires jdk.compiler.interim;
>
>
> This is since the boo
On Mon, 2 Jun 2025 16:59:15 GMT, Magnus Ihse Bursie wrote:
> Due to user error (I screwed up) the changes in indentation that was
> requested in the review was not included when the PR was integrated.
Marked as reviewed by shade (Reviewer).
-
PR Review: https://git.openjdk.org/jdk
On Mon, 26 May 2025 05:54:10 GMT, Christian Stein wrote:
>> Please review the change to update to using jtreg 7.5.2.
>>
>> The primary change is to the `jib-profiles.js` file, which specifies the
>> version of jtreg to use, for those systems that rely on this file. In
>> addition, the `require
On Wed, 21 May 2025 22:09:15 GMT, Jiangli Zhou wrote:
>> Please review this PR that adds a `test-linux-x64-static` job, which runs
>> tier1 tests on the static-jdk 'release' binary created from the
>> `linux-x64-static` build job in GHA. Following are the details on the
>> changes:
>>
>> .git
On Wed, 21 May 2025 22:09:15 GMT, Jiangli Zhou wrote:
>> Please review this PR that adds a `test-linux-x64-static` job, which runs
>> tier1 tests on the static-jdk 'release' binary created from the
>> `linux-x64-static` build job in GHA. Following are the details on the
>> changes:
>>
>> .git
On Sat, 10 May 2025 22:45:54 GMT, Kim Barrett wrote:
> Please review this change to doc/building.html. The change is the result of
> using `make update-build-docs` to regenerate it from the current building.md
> file.
Marked as reviewed by shade (Reviewer).
-
PR Review: https://gi
On Wed, 30 Apr 2025 17:32:34 GMT, Chen Liang wrote:
> There were a few warnings related to illegal native access in HelloClasslist
> after adding some of the downcall infrastructure. Did a clean build and there
> were no warning associated with the
>
> Compiling up to 2 files for CLASSLIST_JA
On Wed, 9 Apr 2025 10:29:55 GMT, Magnus Ihse Bursie wrote:
>> Analogous with how native warnings can be treated as errors or not using the
>> `--disable-warnings-as-errors` configure flag, this patch introduces a
>> `--disable-javac-warnings-as-errors` flag.
>>
>> The reason that this is not m
On Thu, 10 Apr 2025 12:02:45 GMT, Galder Zamarreño wrote:
> Avoid filtering out xml files at the root of the JMH folder, in order to get
> the `default.instruments.template.xml` file bundled in the JMH core jar to
> support xtrace profiler.
`xtraceasm` was not released yet in any JMH version,
On Tue, 8 Apr 2025 14:36:14 GMT, Magnus Ihse Bursie wrote:
> When building the JDK on GHA, we should use `make -k` to continue building as
> much as possible in case of failure, to avoid having developers resubmitting
> one fix after another.
>
> The additional cost of continuing to build even
On Mon, 7 Apr 2025 11:11:08 GMT, Magnus Ihse Bursie wrote:
> Analogous with how native warnings can be treated as errors or not using the
> `--disable-warnings-as-errors` configure flag, this patch introduces a
> `--disable-javac-warnings-as-errors` flag.
>
> The reason that this is not made p
On Mon, 7 Apr 2025 11:11:08 GMT, Magnus Ihse Bursie wrote:
> Analogous with how native warnings can be treated as errors or not using the
> `--disable-warnings-as-errors` configure flag, this patch introduces a
> `--disable-javac-warnings-as-errors` flag.
>
> The reason that this is not made p
On Tue, 8 Apr 2025 14:50:25 GMT, Magnus Ihse Bursie wrote:
> In libraries.m4, there is a long list of known 32-bit CPU architectures as a
> condition for using libatomic with zero. We should just check the address
> size instead.
All right then.
-
Marked as reviewed by shade (Rev
On Tue, 8 Apr 2025 14:50:25 GMT, Magnus Ihse Bursie wrote:
> In libraries.m4, there is a long list of known 32-bit CPU architectures as a
> condition for using libatomic with zero. We should just check the address
> size instead.
Comprehension check: we get bitness from arch itself somewhere e
ro fastdebug, `make bootcycle-images` (still works)
> - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works)
Aleksey Shipilev has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains five commits:
- Merge branch 'ma
On Fri, 28 Feb 2025 00:37:24 GMT, Calvin Cheung wrote:
>> A simple fix in `os::jvm_path()` so that gtest can be run with CDS
>> (`-Xshare:on`). The fix is just to change the directory name from `hotspot`
>> to `server`.
>> Note that the bug doesn't exist on macOS and thus no change is required
On Sat, 29 Mar 2025 00:58:59 GMT, Vladimir Ivanov wrote:
> Build and use SLEEF library as a backend implementation for Vector API
> trigonometric functions on macosx-aarch64 platform.
>
> It improves raw throughput and eliminates GC overhead of non-intrinsified
> Vector API operation.
>
> PR
On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev wrote:
> This PR implements JEP 503: Remove the 32-bit x86 Port.
>
> The JEP is proposed to target 25, we would not integrate until JEP is ready.
> Reviews are appreciated meanwhile.
>
> This is only the removal of obviou
On Tue, 25 Mar 2025 10:43:32 GMT, Aleksey Shipilev wrote:
>> This PR implements JEP 503: Remove the 32-bit x86 Port.
>>
>> The JEP is proposed to target 25, we would not integrate until JEP is ready.
>> Reviews are appreciated meanwhile.
>>
>> This is on
On Tue, 25 Mar 2025 10:43:32 GMT, Aleksey Shipilev wrote:
>> This PR implements JEP 503: Remove the 32-bit x86 Port.
>>
>> The JEP is proposed to target 25, we would not integrate until JEP is ready.
>> Reviews are appreciated meanwhile.
>>
>> This is on
On Fri, 14 Mar 2025 15:49:44 GMT, Magnus Ihse Bursie wrote:
> We should allow pre-built JVMs to be included in a build, so they are just
> copied into place, and the jvm.cfg file properly updated.
For completeness/reference, this is my JDK frankensteining script that is used
for producing buil
On Fri, 14 Mar 2025 17:57:31 GMT, Magnus Ihse Bursie wrote:
> No, it doesn't -- only libjvm.so. .jsa files complicate the situation. Hm.
Aha. Importing CDS archives without regenerating them is futile, IIRC: they
would never load properly, CDS would get disabled, and we would just carry dead
w
On Fri, 14 Mar 2025 15:49:44 GMT, Magnus Ihse Bursie wrote:
> We should allow pre-built JVMs to be included in a build, so they are just
> copied into place, and the jvm.cfg file properly updated.
This change copies `libjvm.so` _and_ sibling `.jsa` files, right?
If so, then one thing is missin
On Fri, 7 Mar 2025 15:06:18 GMT, Magnus Ihse Bursie wrote:
>> I think leaving a comment describing how to deprecate a port is useful. To
>> look it up in history you have to realise there is something to look up.
>>
>> "They who are not reminded of the past will invent a new way to do it in the
On Fri, 7 Mar 2025 07:18:27 GMT, David Holmes wrote:
> You could add a couple of lines to the build code and it would not be
> possible to build 32-bit, so that is a necessary but not sufficient condition
> to claim to implement the JEP IMO.
Agreed. This is why this PR removes the actual imple
ro fastdebug, `make bootcycle-images` (still works)
> - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images` (still works)
Aleksey Shipilev 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 th
On Thu, 6 Mar 2025 16:18:50 GMT, Magnus Ihse Bursie wrote:
>> This PR implements JEP 503: Remove the 32-bit x86 Port.
>>
>> The JEP is proposed to target 25, we would not integrate until JEP is ready.
>> Reviews are appreciated meanwhile.
>>
>> This is only the removal of obvious 32-bit x86 pa
On Thu, 6 Mar 2025 00:16:12 GMT, Vladimir Ivanov wrote:
>> There's a wide variety of options to justify the goal of the JEP. A bare
>> minimum would be to just remove x86-32 build support. And on the other side
>> of the spectrum the current patch would be accompanied by all
>> x86-32-specific
This PR implements JEP 503: Remove the 32-bit x86 Port.
The JEP is proposed to target 25, we would not integrate until JEP is ready.
Reviews are appreciated meanwhile.
This is only the removal of obvious 32-bit x86 parts, mostly files with
`x86_32` in their name. Those are only built when buil
On Wed, 26 Feb 2025 20:25:41 GMT, Jiangli Zhou wrote:
>> Please review this change that adds a `linux-x86-static` job in GHA. The job
>> builds the `static-jdk-image` release binary on linux-x64. Please see
>> https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for
>> some
On Wed, 26 Feb 2025 18:24:13 GMT, Jiangli Zhou wrote:
>> Please review this change that adds a `linux-x86-static` job in GHA. The job
>> builds the `static-jdk-image` release binary on linux-x64. Please see
>> https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for
>> some
On Wed, 26 Feb 2025 17:52:57 GMT, Jiangli Zhou wrote:
>> Please review this change that adds a `linux-x86-static` job in GHA. The job
>> builds the `static-jdk-image` release binary on linux-x64. Please see
>> https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for
>> some
On Wed, 26 Feb 2025 17:58:08 GMT, Aleksey Shipilev wrote:
>> Jiangli Zhou 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 contai
On Wed, 5 Feb 2025 19:41:51 GMT, Jiangli Zhou wrote:
> Please review this change that adds a `linux-x86-static` job in GHA. The job
> builds the `static-jdk-image` release binary on linux-x64. Please see
> https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for
> some addit
On Thu, 20 Feb 2025 17:15:13 GMT, Aleksey Shipilev wrote:
> Noticed this when reviewing
> [JDK-8349399](https://bugs.openjdk.org/browse/JDK-8349399), which had to
> kludgy workaround the hunk introduced by `static-libs-bundles` addition
> ([JDK-8337265](https://bugs.openjdk.or
On Fri, 21 Feb 2025 21:52:56 GMT, Jiangli Zhou wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Rename -static job to -static-libs
>
> Yes, we should distinguish between
On Fri, 21 Feb 2025 14:32:24 GMT, Aleksey Shipilev wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Rename -static job to -static-libs
>
> The point about difference between `st
ull/23471 just there by adding another
> `make-target` into that job definition.
>
> I did a partial GHA run already, and I expect full run to complete without
> errors.
>
> Testing:
> - [x] GHA
Aleksey Shipilev has updated the pull request with a new target base due to a
mer
On Fri, 21 Feb 2025 14:24:22 GMT, Aleksey Shipilev wrote:
>> Noticed this when reviewing
>> [JDK-8349399](https://bugs.openjdk.org/browse/JDK-8349399), which had to
>> kludgy workaround the hunk introduced by `static-libs-bundles` addition
>> ([JDK-8337265](https://bug
ull/23471 just there by adding another
> `make-target` into that job definition.
>
> I did a partial GHA run already, and I expect full run to complete without
> errors.
>
> Testing:
> - [x] GHA
Aleksey Shipilev has updated the pull request incrementally with one
ull/23471 just there by adding another
> `make-target` into that job definition.
>
> I did a partial GHA run already, and I expect full run to complete without
> errors.
>
> Testing:
> - [x] GHA
Aleksey Shipilev has updated the pull request incrementally with one additi
On Thu, 20 Feb 2025 15:58:03 GMT, Aleksey Shipilev wrote:
>> What's the difference between `build-linux-static.yml` and
>> `build-linux.yml`? Can we just call `build-linux.yml` to do the static build?
>
>> @shipilev Can you help review/approve the change, if no other
On Fri, 21 Feb 2025 08:29:28 GMT, Aleksey Shipilev wrote:
>> Noticed this when reviewing
>> [JDK-8349399](https://bugs.openjdk.org/browse/JDK-8349399), which had to
>> kludgy workaround the hunk introduced by `static-libs-bundles` addition
>> ([JDK-8337265](https://bug
ull/23471 just there by adding another
> `make-target` into that job definition.
>
> I did a partial GHA run already, and I expect full run to complete without
> errors.
>
> Testing:
> - [x] GHA
Aleksey Shipilev has updated the pull request incrementally wi
Noticed this when reviewing
[JDK-8349399](https://bugs.openjdk.org/browse/JDK-8349399), which had to kludgy
workaround the hunk introduced by `static-libs-bundles` addition
([JDK-8337265](https://bugs.openjdk.org/browse/JDK-8337265)). I am somewhat
surprised we even have `static-libs-bundles` a
On Thu, 6 Feb 2025 17:01:04 GMT, Aleksey Shipilev wrote:
>> Please review this change that adds a `linux-x86-static` job in GHA. The job
>> builds the `static-jdk-image` release binary on linux-x64. Please see
>> https://mail.openjdk.org/pipermail/build-dev/2025-Februa
On Wed, 12 Feb 2025 17:49:05 GMT, Vladimir Kozlov wrote:
> Backout change
> [JDK-8349859](https://git.openjdk.org/jdk/commit/332d87cc7e19d55ddb98a43a6eb3a77f3518ecfd)
> because it causes build failure.
Looks fine and trivial.
-
Marked as reviewed by shade (Reviewer).
PR Review:
On Wed, 5 Feb 2025 19:41:51 GMT, Jiangli Zhou wrote:
> Please review this change that adds a `linux-x86-static` job in GHA. The job
> builds the `static-jdk-image` release binary on linux-x64. Please see
> https://mail.openjdk.org/pipermail/build-dev/2025-February/048830.html for
> some addit
he commit being backported was authored by Mikael Vidstedt on 23 Jan 2025
> and was reviewed by Erik Joelsson, Vladimir Ivanov and Aleksey Shipilev.
>
> Testing: Manual verification of compilation command line, tier1-5 (in
> progress)
Marked as reviewed by shade (Reviewer).
On Thu, 23 Jan 2025 00:04:47 GMT, Mikael Vidstedt wrote:
> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) started building
> the libsleef library with `$(SVE_CFLAGS)` on aarch64. That variable expands
> to `-march=armv8-a+sve` if the compiler supports it.
>
> The flag should only b
On Tue, 21 Jan 2025 15:54:06 GMT, Stefan Karlsson wrote:
> Maybe something like this:
>
> * Some build configurations uses precompiled headers to speed up the
> build times. The compiled headers are included in the precompiled.hpp file.
> Note that precompiled.hpp is just a build time opti
On Tue, 21 Jan 2025 15:49:05 GMT, Stefan Karlsson wrote:
> > I can see more `DONT_USE_PRECOMPILED_HEADER` uses in `test/hotspot/gtest`,
> > take a look at those?
>
> There shouldn't be. Are you looking at the latest sources? I removed some of
> those in an earlier PR today.
Ah. Yes, I was loo
On Tue, 21 Jan 2025 12:41:13 GMT, Stefan Karlsson wrote:
> Before [JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909) we had to
> remove the include lines in precompiled.hpp when precompiled headers were
> turned off. This was done by defining DONT_USE_PRECOMPILED_HEADER.
>
> After [JDK
On Tue, 21 Jan 2025 12:29:33 GMT, Stefan Karlsson wrote:
> [JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909) removed the need
> for HotSpot devs to include the precompiled.hpp. This is the PR to reflect
> that.
>
> I know that there is some process around updating the style guide, but
1 - 100 of 587 matches
Mail list logo
