-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8304915: Create jdk.internal.util.Architecture enum and apply #13357
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
Conversation
Merge amd64 and X64 to a single Architecture
👋 Welcome back rriggs! A progress list of the required criteria for merging this PR into |
@RogerRiggs The following labels will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
src/java.base/share/classes/jdk/internal/util/Architecture.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good from a build point of view.
/reviewers 2 reviewer
@RogerRiggs 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:
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 68 new commits pushed to the
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 |
…num. Refactor the is64Bit method to be a static method for the current runtime.
src/java.base/share/classes/jdk/internal/util/Architecture.java
Outdated
Show resolved
Hide resolved
ADDRESS_SIZE = ADDRESS.bitSize(); | ||
// might be running in a 32-bit VM on a 64-bit platform. | ||
// addressSize will be correctly 32 | ||
if ((ARCH.equals("amd64") || ARCH.equals("x86_64")) && ADDRESS_SIZE == 64) { | ||
if (Architecture.isX64() && ADDRESS_SIZE == 64) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a difference to Architecture.is64bit (I.e. is the later or the former runtime vs compiletime
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There should be no difference; I was hesitant to drop the ADDRESS_SIZE check without knowing more about the foreign api dependencies. ADDRESS_SIZE is computed (I think) from UNSAFE.ADDRESS_SIZE * 8
.
But I can't think of how it can be different than the CPU_BITS that are defined when the JDK is built.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a difference to Architecture.is64bit (I.e. is the later or the former runtime vs compiletime
Theoretically, the two can be unrelated. Linux x32 ABI is a typical example of using 32-bit addresses on the x86-64 architecture.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, it is still possible to run a 32-bit VM build on a 64-bit platform. os.arch
can be amd64
, the runtime platform, in this case, but the VM variant can still be 32 bits.
Since Architecture.isX64
seems to be the target arch of the VM, I'm think that when running a 32-bit VM on a amd64 would result in isX64
being false
? (In that case, only the isX64
check should be enough)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, it is still possible to run a 32-bit VM build on a 64-bit platform.
os.arch
can beamd64
, the runtime platform, in this case, but the VM variant can still be 32 bits.
os.arch
is always the target architecture for JVM, even using 32-bit JVM on 64-bit system, its value remains x86.
But as mentioned above, the size of the address can be independent of these.
Linux x32 ABI is an ABI for the x86-64 architecture, which uses unique features of 64-bit architectures such as 64-bit registers, but it uses 32-bit addresses.
Although OpenJDK does not support such a platform, technically speaking, it is still necessary to distinguish between architecture bits and address bits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
os.arch is always the target architecture for JVM, even using 32-bit JVM on 64-bit system, its value remains x86.
You're right. I could have sworn we had to add the ADDRESS_SIZE
check because of this issue where a 32-bit VM running on x64 would erroneously select the x64 ABIs (#1386)
src/java.base/share/classes/jdk/internal/util/Architecture.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
src/java.base/share/classes/jdk/internal/util/Architecture.java
Outdated
Show resolved
Hide resolved
src/java.base/share/classes/jdk/internal/util/Architecture.java
Outdated
Show resolved
Hide resolved
src/java.base/share/classes/jdk/internal/util/Architecture.java
Outdated
Show resolved
Hide resolved
src/java.base/share/classes/jdk/internal/util/Architecture.java
Outdated
Show resolved
Hide resolved
src/java.base/share/classes/jdk/internal/util/Architecture.java
Outdated
Show resolved
Hide resolved
src/java.base/share/classes/jdk/internal/util/Architecture.java
Outdated
Show resolved
Hide resolved
src/java.base/share/classes/jdk/internal/util/Architecture.java
Outdated
Show resolved
Hide resolved
src/java.base/share/classes/jdk/internal/util/Architecture.java
Outdated
Show resolved
Hide resolved
src/java.base/share/classes/jdk/internal/util/Architecture.java
Outdated
Show resolved
Hide resolved
src/java.base/share/classes/jdk/internal/util/Architecture.java
Outdated
Show resolved
Hide resolved
Rename S390X to S390, representing just the s390 architecture Removed ARM and IA64 enum values; they are unused; they can be added later if needed
src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java
Outdated
Show resolved
Hide resolved
All platforms and architectures that can be built support attach.
Works on PPC64 Big Endian, now. However, little Endian fails: |
zArch_64 is not relevant/not used in the OpenJDK port to IBM System z. As noted elsewhere in the PR, it's the architecture name that was used in the initial, proprietary port by SAP. I found just one occurrence of the string in the head revision, and that was in test/lib/jdk/test/lib/Platform.java. |
Consolidated switch cases in ArchTest. Moved mapping of build TARGET_OS and TARGET_CPU to the build to avoid multiple mappings in more than one place.
@TheRealMDoerr Thanks for the ppc64 feedback and testing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! PPC64 parts look good and the test has passed on both endianness versions.
|
||
# Normalize OPENJDK_TARGET_CPU name to match jdk.internal.util.Architecture enum | ||
ifneq ($(filter $(OPENJDK_TARGET_CPU), ppc64le), ) | ||
OPENJDK_TARGET_ARCH_CANONICAL = ppc64 | ||
else ifneq ($(filter $(OPENJDK_TARGET_CPU), s390x), ) | ||
OPENJDK_TARGET_ARCH_CANONICAL = s390 | ||
else ifneq ($(filter $(OPENJDK_TARGET_CPU), x86_64 amd64), ) | ||
OPENJDK_TARGET_ARCH_CANONICAL = x64 | ||
else | ||
OPENJDK_TARGET_ARCH_CANONICAL := $(OPENJDK_TARGET_CPU) | ||
endif | ||
|
||
# Normalize OPENJDK_TARGET_OS operating system name to match jdk.internal.util.OperatingSystem enum | ||
ifeq ($(OPENJDK_TARGET_OS), macosx) | ||
OPENJDK_TARGET_OS_CANONICAL = macos | ||
else | ||
OPENJDK_TARGET_OS_CANONICAL := $(OPENJDK_TARGET_OS) | ||
endif | ||
|
||
$(eval $(call SetupTextFileProcessing, BUILD_PLATFORMPROPERTIES_JAVA, \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@erikj79 Is there a better/good way to do these mappings, or select "local" variable names?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if it's better, but you could consider doing this directly in the switch statements in make/autoconf/platform.m4
and add the corresponding variables in spec.gmk.in
. That would make them available globally in the build, which may also be detrimental as parts of the build could start relying on them, and we end up with even more variants sprinkled around. I think what you have here is better for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, I'd rather keep it local. Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The RISC-V 64 part look good, ArchTest
has passed on Debian RISC-V 64.
Last call for Reviewers. Tnx |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Build changes look good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, tests still pass on Debian RISC-V 64.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for s390x, build is fine and tier1 (specifically ArchTest.java
) passes.
Thanks for the change.
… mentioning PPC64LE
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the comment updates!
/integrate |
Going to push as commit f00a748.
Your commit was automatically rebased without conflicts. |
@RogerRiggs Pushed as commit f00a748. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property
os.arch
.The enumeration values are defined to match those used in the build.
The initial values are:
X64, X86, AARCH64, RISCV64, S390, PPC64
Note that
amd64
andx86_64
in the build are represented byX64
.The value of the system property
os.arch
is unchanged.The API is similar to the jdk.internal.util.OperatingSystem enum created by #12931.
Uses in
java.base
and a few others are included but other modules will be done in separate PRs.Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357
$ git checkout pull/13357
Update a local copy of the PR:
$ git checkout pull/13357
$ git pull https://git.openjdk.org/jdk.git pull/13357/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 13357
View PR using the GUI difftool:
$ git pr show -t 13357
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/13357.diff
Webrev
Link to Webrev Comment