Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8349399: GHA: Add static-jdk build on linux-x64 #23471

Closed
wants to merge 11 commits into from

Conversation

jianglizhou
Copy link
Contributor

@jianglizhou jianglizhou commented Feb 5, 2025

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 additional context.

A debug build job (building static-jdk-image fastdebug binary) is not included currently. There is a known issue that causes build failure due to resource problem, which causes the fastdebug build fail in github workflow. Please see more related information in https://bugs.openjdk.org/browse/JDK-8349399?focusedId=14749789&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14749789.

GHA: https://github.com/jianglizhou/jdk/actions/runs/13163673020


Progress

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue

Issue

  • JDK-8349399: GHA: Add static-jdk build on linux-x64 (Enhancement - P4)

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/23471/head:pull/23471
$ git checkout pull/23471

Update a local copy of the PR:
$ git checkout pull/23471
$ git pull https://git.openjdk.org/jdk.git pull/23471/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 23471

View PR using the GUI difftool:
$ git pr show -t 23471

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/23471.diff

Using Webrev

Link to Webrev Comment

@bridgekeeper
Copy link

bridgekeeper bot commented Feb 5, 2025

👋 Welcome back jiangli! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk
Copy link

openjdk bot commented Feb 5, 2025

@jianglizhou This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8349399: GHA: Add static-jdk build on linux-x64

Reviewed-by: shade, ihse

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 1 new commit pushed to the master branch:

  • e43960a: 8350616: Skip ValidateHazardPtrsClosure in non-debug builds

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added the rfr Pull request is ready for review label Feb 5, 2025
@openjdk
Copy link

openjdk bot commented Feb 5, 2025

@jianglizhou The following label will be automatically applied to this pull request:

  • build

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added the build build-dev@openjdk.org label Feb 5, 2025
@mlbridge
Copy link

mlbridge bot commented Feb 5, 2025

Webrevs

@jianglizhou
Copy link
Contributor Author

@erikj79 @magicus Could you help review the GHA change for adding a static-jdk-image build? Thanks

@shipilev
Copy link
Member

shipilev commented Feb 6, 2025

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?

@jianglizhou
Copy link
Contributor Author

@shipilev Thanks for looking into this.

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?

Currently, the main difference is avoiding building static-libs-bundles completely in build-linux-static.yml, since that's not needed for the testing purpose with static-jdk-image. In build-linux.yml, there is the following logic that skips building static-libs-bundles but for fastdebug build only. I actually initially started using build-linux.yml for the static build job, but later added build-linux-static.yml when I was looking for a cleaner way to skipping building static-libs-bundles.

          # Only build static-libs-bundles for release builds.
          # For debug builds, building static-libs often exceeds disk space.
          STATIC_LIBS: ${{ matrix.debug-level == 'release' && 'static-libs-bundles' }}

@jianglizhou
Copy link
Contributor Author

@shipilev Thanks for looking into this.

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?

Currently, the main difference is avoiding building static-libs-bundles completely in build-linux-static.yml, since that's not needed for the testing purpose with static-jdk-image. In build-linux.yml, there is the following logic that skips building static-libs-bundles but for fastdebug build only. I actually initially started using build-linux.yml for the static build job, but later added build-linux-static.yml when I was looking for a cleaner way to skipping building static-libs-bundles.

          # Only build static-libs-bundles for release builds.
          # For debug builds, building static-libs often exceeds disk space.
          STATIC_LIBS: ${{ matrix.debug-level == 'release' && 'static-libs-bundles' }}

@shipilev Can you help review/approve the change, if no other questions?

@jianglizhou
Copy link
Contributor Author

I brought up this PR during today's hermetic Java meeting. There was a question asked about the time used for the static build job. Here is a comparison between linux-x64-static and existing linux-x64 jobs in GHA:

@shipilev
Copy link
Member

@shipilev Can you help review/approve the change, if no other questions?

Sorry for not looking at this sooner.

It looks to me that you are trying to work-around a little mess introduced by static-libs-bundles addition (JDK-8337265). Not your mess, but trying to avoid it introduces more headaches. I am somewhat surprised we even have static-libs-bundles as additional target in what I would consider a generic build-linux job! It looks cleaner to yank static-libs-bundles into a separate build job, which would then allow your PR to proceed by just calling build-linux normally, without introducing a wholly new job script. Let me try to fix static-libs-bundles first.

@jianglizhou
Copy link
Contributor Author

@shipilev Can you help review/approve the change, if no other questions?

Sorry for not looking at this sooner.

It looks to me that you are trying to work-around a little mess introduced by static-libs-bundles addition (JDK-8337265). Not your mess, but trying to avoid it introduces more headaches. I am somewhat surprised we even have static-libs-bundles as additional target in what I would consider a generic build-linux job! It looks cleaner to yank static-libs-bundles into a separate build job, which would then allow your PR to proceed by just calling build-linux normally, without introducing a wholly new job script. Let me try to fix static-libs-bundles first.

Thank you, @shipilev! Fixing the build-linux first sounds good to me. I see you have PR already, thanks again!

In fact, there is a similar build resource (disk space) issue for the static job as well. It requires some work in both the runtime and build system to address the underlying problem that causes excessive build resource consumption. I created https://bugs.openjdk.org/browse/JDK-8350450. @magicus has been looking into integrating (related runtime changes from hermetic-java-runtime branch) and fixing the issue in JDK mainline.

@shipilev
Copy link
Member

shipilev commented Feb 21, 2025

Thank you, @shipilev! Fixing the build-linux first sounds good to me. I see you have PR already, thanks again!

Hey @jianglizhou, a quick question for you. There are two options for this PR:
1. Build both static-jdk-image and static-libs-bundle in the same linux-x64-static job from #23715
2. Build static-jdk-image and static-libs-bundle in different jobs

Which one would you prefer? I would prefer to test all static stuff in a single job (1), unless you disagree? If we decide now, it would allow me to name the job in #23715 properly from the start. I think we are going for separate jobs, so the question is moot.

@shipilev
Copy link
Member

#23715 should now be in. Now you can just add a clean separate job for this, like this one:

build-linux-x64-static-libs:
name: linux-x64-static-libs
needs: prepare
uses: ./.github/workflows/build-linux.yml
with:
platform: linux-x64
make-target: 'static-libs-bundles'
# Only build static-libs-bundles for release builds.
# For debug builds, building static-libs often exceeds disk space.
debug-levels: '[ "release" ]'
gcc-major-version: '10'
configure-arguments: ${{ github.event.inputs.configure-arguments }}
make-arguments: ${{ github.event.inputs.make-arguments }}
# Upload static libs bundles separately to avoid interference with normal linux-x64 bundle.
# This bundle is not used by testing jobs, but downstreams use it to check that
# dependent projects, e.g. libgraal, builds fine.
bundle-suffix: "-static-libs"
if: needs.prepare.outputs.linux-x64-variants == 'true'

And then you don't need a whole new script for static-jdk build.

Copy link
Member

@shipilev shipilev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, one nit:

@@ -168,6 +168,19 @@ jobs:
make-arguments: ${{ github.event.inputs.make-arguments }}
if: needs.prepare.outputs.linux-x64 == 'true'

build-linux-x64-static-jdk:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Move this closer to build-linux-x64-static-libs? These are somewhat related, at least in their need for debug-levels: release. Probably copy a comment about debug-level there.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also maybe just build-linux-x64-static? -jdk feels a bit redundant. I see you had it before, would you still prefer ...-static-jdk?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the quick look, @shipilev! Also, thanks for separating the static-libs-bundle with #23715. I haven't responded to your earlier comment as I wanted to wait for the GHA testing results.

I renamed to ...-static-jdk to be more consistent with the new ...-static-libs job. build-linux-x64-static still sounds fine to me, I'll rename it back.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shipilev Updated based on your suggestions.

…move close to build-linux-x64-static-libs, for addressing shipilev's suggestions.
Comment on lines 240 to 241
make-arguments: ${{ github.event.inputs.make-arguments }}
if: needs.prepare.outputs.linux-x64 == 'true'
Copy link
Member

@shipilev shipilev Feb 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, one more trouble: this job produces bundles. But that bundle name is just linux-x64, which overrides the standard bundle. See how build-linux-x64-static-libs overrides bundle-suffix:, do the same here. E.g. bundle-suffix: "-static"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, one more trouble: this job produces bundles. But that bundle name is just linux-x64, which overrides the standard bundle. See how build-linux-x64-static-libs overrides bundle-suffix:, do the same here. E.g. bundle-suffix: "-static"?

The current build-linux-x64-static job doesn't produce any bundles.

I do agree with your point on overriding the bundle name, as we probably want to include bundle creation in the job at some later point. I actually ran into GHA failure initially when I used the build-linux.yml for the job due to bundle name conflict before your #23715 change. Updating to include your suggestion for the bundle name...

Copy link
Member

@shipilev shipilev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, this looks fine. See if @magicus agrees as well.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Feb 26, 2025
Copy link
Member

@magicus magicus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, looks good. Thanks @shipilev and @jianglizhou for getting this better solution than the initial proposal.

@jianglizhou
Copy link
Contributor Author

@shipilev @magicus Thanks!

@jianglizhou
Copy link
Contributor Author

/integrate

@openjdk
Copy link

openjdk bot commented Feb 26, 2025

Going to push as commit 78c18cf.
Since your change was applied there has been 1 commit pushed to the master branch:

  • e43960a: 8350616: Skip ValidateHazardPtrsClosure in non-debug builds

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Feb 26, 2025
@openjdk openjdk bot closed this Feb 26, 2025
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Feb 26, 2025
@openjdk
Copy link

openjdk bot commented Feb 26, 2025

@jianglizhou Pushed as commit 78c18cf.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build build-dev@openjdk.org integrated Pull request has been integrated
Development

Successfully merging this pull request may close these issues.

3 participants