Re: RFR: 8353217: Build libsleef on macos-aarch64
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 includes build changes and libsleef sources relocation from > `src/jdk.incubator.vector/linux/native/` to > `src/jdk.incubator.vector/share/native/`. > > Once libsleef library is present, existing code in > `stubGenerator_aarch64.cpp` successfully links at JVM startup. > > Testing: hs-tier1 - hs-tier4, microbenchmarks Thanks for the reviews. > This makes me wonder: @iwanowww what kind of testing have you done to ensure > this works correctly? hs-tier1 - hs-tier4 (and up to hs-tier6 as part of larger set of changes). Vector API unit tests (under `test/jdk/jdk/incubator/vector/`) exercise this functionality. >> Is leaving the sources of sleef in share/native the right thing to do? > No, it should move to the least common directory for all platforms where it > is needed. In this case, it should move to unix instead of share. Strictly speaking, `src/jdk.incubator.vector/linux/native/libsleef` consists of 3 parts: (a) original SLEEF library sources (under `upstream/` sub-folder); (b) platform-specific generated code (under `generated/`); (c) custom native wrappers used to build `libsleef` library in JDK (under `lib/`). While (c) may be Linux-specific, SLEEF library is cross-platform and covers wide range of platforms [1]. So, strictly speaking, it's (c) which are truly platform-specific and deserve being placed under `[linux|unix]/native`. Moreover, I'm experimenting with SLEEF usage on x86, so it's possible that it will be used on linux-x64/windows-x64 eventually. I'm fine with it either way. But if we don't want to relocate SLEEF sources again rather soon, I suggest to place it under `share/` right away. [1] https://sleef.org/ - PR Comment: https://git.openjdk.org/jdk/pull/24306#issuecomment-2767493489
Re: RFR: 8353009: Document target selection flag for Windows AArch64 builds
On Thu, 27 Mar 2025 19:38:28 GMT, Erik Joelsson wrote: > Wait, are you saying you can get a native build to work by setting > --build=aarch64-pc-cygwin? If so, then that's a better instruction IMO. No, it's not. If we could block the `--build` flag, we would. This is the built-in autoconf target/host/build system, that messes with the structure we use in OpenJDK (since we do not do canadian cross builds). So if you need to add configure option, this would be the correct one. However, we should be able to figure this out by ourselves. This can be solved by a patch in `config.sub` and/or `config.guess`. - PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2765781468
Re: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files [v2]
On Sat, 22 Mar 2025 10:09:46 GMT, Patrick Zhang wrote: >> Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'` >> triggers 1000+ warning messages like `cc1plus: warning: command-line option >> ‘-Wno-incompatible-pointer-types’ is valid for C/ObjC but not for C++`. >> >> The root cause is that `JVM_CFLAGS ` which contains both `EXTRA_CXXFLAGS` >> and `EXTRA_CFLAGS` when compiling `src/hotspot` C++ source files and >> building `BUILD_LIBJVM`. >> >> This PR does: >> 1. Not to append `EXTRA_CFLAGS` or `EXTRA_CXXFLAGS` into `JVM_CFLAGS` before >> calling `SetupJdkLibrary`, instead let `SetupCompilerFlags` accept and merge >> `EXTRA_CFLAGS` and `EXTRA_CXXFLAGS` passed from `SetupJdkLibrary` as >> parameters, so CPP compilation will only see `EXTRA_CXXFLAGS` as expected. >> 2. Correct `PCH_COMMAND` to use `EXTRA_CXXFLAGS` as precompiled.hpp.gch >> should not be compiled with `EXTRA_CFLAGS`. >> 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which was >> missed by >> [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) >> for the refactor of building static libs. >> >> Tests: Passed jdk building on an AArch64 Linux system and tier1 sanity >> tests, also passed OpenJDK GHA Sanity Checks. > > Patrick Zhang has updated the pull request incrementally with three > additional commits since the last revision: > > - Fixed a typo > >Signed-off-by: Patrick Zhang > - Added comments to describe why EXTRA_CFLAGS is excluded from JVM_CFLAGS > >Signed-off-by: Patrick Zhang > - Revert the changes of adding new params to SetupNativeCompilation > >Signed-off-by: Patrick Zhang Hi @magicus , do you think my above clarifications regarding the unrelated code change and added comments acceptable, or do you still recommend removing those sections before merging? Thank you for confirming, and any advice on further changes. - PR Comment: https://git.openjdk.org/jdk/pull/24115#issuecomment-2766136731
Re: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files [v2]
On Sat, 22 Mar 2025 10:09:46 GMT, Patrick Zhang wrote: >> Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'` >> triggers 1000+ warning messages like `cc1plus: warning: command-line option >> ‘-Wno-incompatible-pointer-types’ is valid for C/ObjC but not for C++`. >> >> The root cause is that `JVM_CFLAGS ` which contains both `EXTRA_CXXFLAGS` >> and `EXTRA_CFLAGS` when compiling `src/hotspot` C++ source files and >> building `BUILD_LIBJVM`. >> >> This PR does: >> 1. Not to append `EXTRA_CFLAGS` or `EXTRA_CXXFLAGS` into `JVM_CFLAGS` before >> calling `SetupJdkLibrary`, instead let `SetupCompilerFlags` accept and merge >> `EXTRA_CFLAGS` and `EXTRA_CXXFLAGS` passed from `SetupJdkLibrary` as >> parameters, so CPP compilation will only see `EXTRA_CXXFLAGS` as expected. >> 2. Correct `PCH_COMMAND` to use `EXTRA_CXXFLAGS` as precompiled.hpp.gch >> should not be compiled with `EXTRA_CFLAGS`. >> 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which was >> missed by >> [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) >> for the refactor of building static libs. >> >> Tests: Passed jdk building on an AArch64 Linux system and tier1 sanity >> tests, also passed OpenJDK GHA Sanity Checks. > > Patrick Zhang has updated the pull request incrementally with three > additional commits since the last revision: > > - Fixed a typo > >Signed-off-by: Patrick Zhang > - Added comments to describe why EXTRA_CFLAGS is excluded from JVM_CFLAGS > >Signed-off-by: Patrick Zhang > - Revert the changes of adding new params to SetupNativeCompilation > >Signed-off-by: Patrick Zhang I still have reservations. Let me re-read the patch to see if I can better understand what part of the code you find hard to understand, so I can be more constructive in my criticism. - PR Comment: https://git.openjdk.org/jdk/pull/24115#issuecomment-2766149983
Re: RFR: 8304674: File java.c compile error with -fsanitize=address -O0
On Sun, 30 Mar 2025 15:07:36 GMT, SendaoYan wrote:
> Hi all,
> File src/java.base/share/native/libjli/java.c compile error: control reaches
> end of non-void function [-Werror=return-type] with gcc options
> -fsanitize=address -O0. The function int JavaMain(void* _args) in this file
> will execute return ret in LEAVE() macro, but gcc with -O0 is not smart
> enough to recognized that the function already has return statement before at
> the end of function. It's a gcc bug which has been recorded by
> [80959](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80959), and below code
> snippet can demonstrate the gcc bug. I think we should disable return-type
> gcc warning for java.c file before the gcc bug has been fixed. Risk is low.
>
>
>> cat java.c
> char a() {
> return 0;
> int b;
> if (a(&b))
> return 0;
> }
>
>> gcc -O0 -Wall -Wextra -Werror -O0 -c java.c -fsanitize=address
> java.c: In function ‘a’:
> java.c:6:1: error: control reaches end of non-void function
> [-Werror=return-type]
> 6 | }
> | ^
> cc1: all warnings being treated as errors
While I normally advocate using DISABLE_WARNING in makefiles instead of
pragmas, in this particular case I wonder if not a pragma in the `LEAVE` macro
would be better?
-
PR Comment: https://git.openjdk.org/jdk/pull/24318#issuecomment-2766145747
Re: RFR: 8304674: File java.c compile error with -fsanitize=address -O0
On Mon, 31 Mar 2025 12:57:38 GMT, Magnus Ihse Bursie wrote: > in this particular case I wonder if not a pragma in the LEAVE macro would be > better? I will try it later. - PR Comment: https://git.openjdk.org/jdk/pull/24318#issuecomment-2766150226
Re: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
On Fri, 28 Mar 2025 05:10:33 GMT, Julian Waters wrote: > > Wait, sorry to trouble you further, but what does nm --demangle > > --reverse-sort --print-size --size-sort libjvm.so on HotSpot compiled by > > gcc 14 with LTO active yield as the largest symbol in the binary? (It > > should be the symbol listed at the very top) > > This is my output; maybe I have to add that I used the 'normal' jdk head > without patches, is that what I should do for a gcc14 build test? > > ``` > nm --demangle --reverse-sort --print-size --size-sort > images/jdk/lib/server/libjvm.so | more > 00453ee0 0002320e t State::MachNodeGenerator(int) > 00970f70 00018eb9 t > CompilerToVM::initialize_intrinsics(JVMCIEnv*) > 0140caa0 f018 b Matcher::mreg2regmask > 00993c80 a40d t JNIJVMCI::initialize_ids(JNIEnv_*) > 00ac16b0 9d16 t Matcher::Fixup_Save_On_Entry() > 0143db00 8000 b _ZL9_elements.lto_priv.0 > 01446d20 8000 b _free_list > 0141e900 7d00 b DFSClosure::_reference_stack > 013d6d40 7668 d _ZL9flagTable.lto_priv.0 > 013edf60 6c30 d VMStructs::localHotSpotVMStructs > 010463f0 6a06 t readConfiguration0(JNIEnv_*, JVMCIEnv*) > [clone .isra.0] > 00d51dc0 67a2 t StubGenerator::generate_libmPow() > 010b12d0 6289 t > G1ParScanThreadState::trim_queue_to_threshold(unsigned int) > 00e24550 61e8 t ClassVerifier::verify_method(methodHandle > const&, JavaThread*) > 01076dd0 548d t State::DFA(int, Node const*) [clone > .isra.0] > 00e1ba00 519d t VMError::report(outputStream*, bool) > 014521e0 5000 b TemplateInterpreter::_safept_table > 0142cb60 5000 b TemplateInterpreter::_normal_table > 01431b60 5000 b TemplateInterpreter::_active_table > 00653790 4e12 t > CompileBroker::print_heapinfo(outputStream*, char const*, unsigned long) > 0075be40 4e0b t > G1CollectedHeap::do_collection_pause_at_safepoint_helper() > 00b90260 4a41 t Parse::do_one_bytecode() [clone .part.0] > 010c1f20 49e6 t d_print_comp_inner > 00c1e180 4594 t > ServiceThread::service_thread_entry(JavaThread*, JavaThread*) > 005ad7c0 4424 t C2Compiler::compile_method(ciEnv*, > ciMethod*, int, bool, DirectiveSet*) > 00d260b0 440a t > PhaseStringOpts::replace_string_concat(StringConcat*) > 00e48920 42e5 t VM_Version::initialize() > 00afbad0 4240 t Method::init_intrinsic_id(vmSymbolID) > 010200d0 40ab t PSParallelCompact::invoke_no_policy(bool) > [clone .isra.0] > 0051f230 4054 t Compiler::compile_method(ciEnv*, > ciMethod*, int, bool, DirectiveSet*) > 0065c060 4015 t Compile::Code_Gen() > 00663060 3fec t CompileBroker::compiler_thread_loop() > 0070d9b0 3fd7 t ConnectionGraph::do_analysis(Compile*, > PhaseIterGVN*) > 00be8890 3f8e t PhaseChaitin::Split(unsigned int, > ResourceArea*) > 00818730 3f82 t > PhaseChaitin::build_ifg_physical(ResourceArea*) > 00fb1920 3f44 t > SharedRuntime::generate_native_wrapper(MacroAssembler*, methodHandle const&, > int, BasicType*, VMRegPair*, BasicType) [clone .constprop.0] > 007e2ab0 3f41 t PhaseCFG::global_code_motion() > 013e8580 3e10 d JVMCIVMStructs::localHotSpotVMStructs > 00db3b00 3dff t > TemplateInterpreterGenerator::generate_all() > 00f436d0 3d92 t initialize_stubs(StubGenBlobId, int, int, > char const*, char const*, char const*) [clone .constprop.0] > 00d6b680 3d42 t StubGenerator::generate_libmTan() > 004ff560 3d28 t BCEscapeAnalyzer::iterate_blocks(Arena*) > 00a2bfb0 3cef t > VM_RedefineClasses::load_new_class_versions() [clone .part.0] > 0073fde0 3ca2 t G1CollectedHeap::do_full_collection(bool, > bool) > 00e8e170 3bea t ZDriverMajor::run_thread() > 0103ec00 3b81 t JvmtiEnv::RetransformClasses(int, > _jclass* const*) [clone .isra.0] > 00d18c50 3b4d t > StubGenerator::generate_md5_implCompress(StubGenStubId) > 00a97160 3b20 t > PhaseIdealLoop::auto_vectorize(IdealLoopTree*, VSharedData&) [clone .part.0] > 013df000 3aa8 d ruleName > 005c7e90 3a9f t PhiNode::Ideal(PhaseGVN*, bool) > 006a1ef0 3a9f t State::_sub_Op_AddP(Node const*) > 00e86880 3a74 t > ZGeneration::select_relocation_set(ZGenerationId, bool)
Re: RFR: 8353009: Document target selection flag for Windows AArch64 builds
On Wed, 26 Mar 2025 22:38:40 GMT, Saint Wesonga wrote: > The target selection configuration flag for Windows AArch64 should be added > to the build documentation for improved discoverability and completeness. But is the problem that we just fails to detect the *build* platform, and thus generates build tools for x64, instead of aarch64, which makes the build fail? (Also, why doesn't the rosetta-equivalent kick in in that case?) Or do we also fail to set the proper target platform, so that building on windows/aarch64 will in effect be a cross compilation to x64? - PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2766274494
Re: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files [v2]
On Sat, 22 Mar 2025 10:09:46 GMT, Patrick Zhang wrote: >> Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'` >> triggers 1000+ warning messages like `cc1plus: warning: command-line option >> ‘-Wno-incompatible-pointer-types’ is valid for C/ObjC but not for C++`. >> >> The root cause is that `JVM_CFLAGS ` which contains both `EXTRA_CXXFLAGS` >> and `EXTRA_CFLAGS` when compiling `src/hotspot` C++ source files and >> building `BUILD_LIBJVM`. >> >> This PR does: >> 1. Not to append `EXTRA_CFLAGS` or `EXTRA_CXXFLAGS` into `JVM_CFLAGS` before >> calling `SetupJdkLibrary`, instead let `SetupCompilerFlags` accept and merge >> `EXTRA_CFLAGS` and `EXTRA_CXXFLAGS` passed from `SetupJdkLibrary` as >> parameters, so CPP compilation will only see `EXTRA_CXXFLAGS` as expected. >> 2. Correct `PCH_COMMAND` to use `EXTRA_CXXFLAGS` as precompiled.hpp.gch >> should not be compiled with `EXTRA_CFLAGS`. >> 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which was >> missed by >> [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) >> for the refactor of building static libs. >> >> Tests: Passed jdk building on an AArch64 Linux system and tier1 sanity >> tests, also passed OpenJDK GHA Sanity Checks. > > Patrick Zhang has updated the pull request incrementally with three > additional commits since the last revision: > > - Fixed a typo > >Signed-off-by: Patrick Zhang > - Added comments to describe why EXTRA_CFLAGS is excluded from JVM_CFLAGS > >Signed-off-by: Patrick Zhang > - Revert the changes of adding new params to SetupNativeCompilation > >Signed-off-by: Patrick Zhang I've now re-read it all, and I stand behind my position that the comment should be removed. I agree that the CFLAGS handling in the build system is obscure, and surprising. There is an old JBS issue from 2012 (!) tracking this: https://bugs.openjdk.org/browse/JDK-8001877 (see also https://bugs.openjdk.org/browse/JDK-8333089). It's a shame that this has not been fixed, but the problem is that the current situation is so complicated that it will take quite an effort to disentangle the mess, which combined with the limited ways to raise abstraction available in make makes this a much larger undertaking than maybe is apparent at first glance. So in this context, having the proposed comment at that place only just adds to the confusion. - PR Comment: https://git.openjdk.org/jdk/pull/24115#issuecomment-2766258358
Re: RFR: 8353009: Document target selection flag for Windows AArch64 builds
On Mon, 31 Mar 2025 12:31:10 GMT, Magnus Ihse Bursie wrote: > Wait a minute. I re-read the discussion a bit more carefully, and let my > brain re-process what I said above... > > Is the goal here to document how you properly do cross-compilation for > windows/aarch64 on windows/x64? If so, I think this is a correct solution, > but the documentation should be more clear that this applies for > cross-compiling to windows/aarch64 from x64 on cygwin. > > If the problem is that native builds on windows/aarch64 does not work, then > it is a different issue that needs to be fixed. The problem applies to both native and cross compilation, though cross compilation is no different than other platforms. The reason native compilation doesn't work on Cygwin is that there is no aarch64 distro of Cygwin, so even a native windows aarch64 build will use an x64 version of Cygwin running in emulated mode (I don't know the name on Windows, but pretty much the same as rosetta on mac). This trips up configure into thinking we are running on a native windows x64 machine, and it's the reason why telling configure that the **build** platform is `aarch64-pc-cygwin` helps. Caveat, this is all based on what I've heard, I've never had access to a windows-aarch64 machine. I completely agree that fixing this detection issue is better than documenting, but I also think that documenting how to perform a native build is better than how to perform a cross build on a native machine. Cross compiling works, but adds increased complexity and build time unnecessarily in this case. - PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2766199206
Re: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files [v3]
> Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'` > triggers 1000+ warning messages like `cc1plus: warning: command-line option > ‘-Wno-incompatible-pointer-types’ is valid for C/ObjC but not for C++`. > > The root cause is that `JVM_CFLAGS ` which contains both `EXTRA_CXXFLAGS` and > `EXTRA_CFLAGS` when compiling `src/hotspot` C++ source files and building > `BUILD_LIBJVM`. > > This PR does: > 1. Not to append `EXTRA_CFLAGS` or `EXTRA_CXXFLAGS` into `JVM_CFLAGS` before > calling `SetupJdkLibrary`, instead let `SetupCompilerFlags` accept and merge > `EXTRA_CFLAGS` and `EXTRA_CXXFLAGS` passed from `SetupJdkLibrary` as > parameters, so CPP compilation will only see `EXTRA_CXXFLAGS` as expected. > 2. Correct `PCH_COMMAND` to use `EXTRA_CXXFLAGS` as precompiled.hpp.gch > should not be compiled with `EXTRA_CFLAGS`. > 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which was > missed by > [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) > for the refactor of building static libs. > > Tests: Passed jdk building on an AArch64 Linux system and tier1 sanity tests, > also passed OpenJDK GHA Sanity Checks. Patrick Zhang has updated the pull request incrementally with one additional commit since the last revision: Remove the comments wrt not appending EXTRA_CFLAGS to JVM_CFLAGS Signed-off-by: Patrick Zhang - Changes: - all: https://git.openjdk.org/jdk/pull/24115/files - new: https://git.openjdk.org/jdk/pull/24115/files/aa242dd5..5440ddc5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24115&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24115&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24115.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24115/head:pull/24115 PR: https://git.openjdk.org/jdk/pull/24115
Re: RFR: 8353009: Document target selection flag for Windows AArch64 builds
On Wed, 26 Mar 2025 22:38:40 GMT, Saint Wesonga wrote: > The target selection configuration flag for Windows AArch64 should be added > to the build documentation for improved discoverability and completeness. > But is the problem that we just fails to detect the _build_ platform, and > thus generates build tools for x64, instead of aarch64, which makes the build > fail? (Also, why doesn't the rosetta-equivalent kick in in that case?) > > Or do we also fail to set the proper target platform, so that building on > windows/aarch64 will in effect be a cross compilation to x64? If configure thinks it's running on a build platform of windows-x64, why would it try to compile for any other target than windows-x64 by default? I don't think the build fails, it just builds for the wrong platform, but as I said, I never tried this myself, this is second hand information. - PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2766418606
Re: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files [v4]
> Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'` > triggers 1000+ warning messages like `cc1plus: warning: command-line option > ‘-Wno-incompatible-pointer-types’ is valid for C/ObjC but not for C++`. > > The root cause is that `JVM_CFLAGS ` which contains both `EXTRA_CXXFLAGS` and > `EXTRA_CFLAGS` when compiling `src/hotspot` C++ source files and building > `BUILD_LIBJVM`. > > This PR does: > 1. Not to append `EXTRA_CFLAGS` or `EXTRA_CXXFLAGS` into `JVM_CFLAGS` before > calling `SetupJdkLibrary`, instead let `SetupCompilerFlags` accept and merge > `EXTRA_CFLAGS` and `EXTRA_CXXFLAGS` passed from `SetupJdkLibrary` as > parameters, so CPP compilation will only see `EXTRA_CXXFLAGS` as expected. > 2. Correct `PCH_COMMAND` to use `EXTRA_CXXFLAGS` as precompiled.hpp.gch > should not be compiled with `EXTRA_CFLAGS`. > 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which was > missed by > [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) > for the refactor of building static libs. > > Tests: Passed jdk building on an AArch64 Linux system and tier1 sanity tests, > also passed OpenJDK GHA Sanity Checks. Patrick Zhang has updated the pull request incrementally with one additional commit since the last revision: Revertd the STATIC_LIB_CFLAGS fix as it is coverted by JDK-8353272 Signed-off-by: Patrick Zhang - Changes: - all: https://git.openjdk.org/jdk/pull/24115/files - new: https://git.openjdk.org/jdk/pull/24115/files/5440ddc5..46c43921 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24115&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24115&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24115.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24115/head:pull/24115 PR: https://git.openjdk.org/jdk/pull/24115
Re: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files [v2]
On Mon, 31 Mar 2025 13:35:24 GMT, Magnus Ihse Bursie wrote: > So in this context, having the proposed comment at that place only just adds > to the confusion. Sure, I removed the comments with a new commit. - PR Comment: https://git.openjdk.org/jdk/pull/24115#issuecomment-2766441330
Re: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files [v2]
On Mon, 31 Mar 2025 13:24:25 GMT, Magnus Ihse Bursie wrote: >>> 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which >>> was missed by >>> [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) >>> for the refactor of building static libs. >> >> Unrelated, after the fix got limited to `JvmFlags.gmk` only. >> However, it is a practical bug, and existing tests did not cover the corner >> case. As described in the No.3 bullet of this PR. The problem showed up when >> I tested applying `EXTRA_CXXFLAGS to `precompiled.hpp.gch`. It is a simple >> and tiny fix which may not require a separate PR I thought, does it? >> >> FYI, the failures on linux-x64-static and linux-x64-static-libs tests, >> captured by OpenJDK GHA Sanity Checks: >> https://github.com/cnqpzhang/jdk/actions/runs/13943096440. > > You are correct that this is a bug, but the fix should not be sneaked in > under the guise of another problem. > > I created https://bugs.openjdk.org/browse/JDK-8353272 for this. Reverted the fix. Thanks for helping file a new JBS and follow-ups. - PR Review Comment: https://git.openjdk.org/jdk/pull/24115#discussion_r2021172025
Re: RFR: 8353009: Document target selection flag for Windows AArch64 builds
On Mon, 31 Mar 2025 14:27:19 GMT, Erik Joelsson wrote: > > But is the problem that we just fails to detect the _build_ platform, and > > thus generates build tools for x64, instead of aarch64, which makes the > > build fail? (Also, why doesn't the rosetta-equivalent kick in in that case?) > > Or do we also fail to set the proper target platform, so that building on > > windows/aarch64 will in effect be a cross compilation to x64? > > If configure thinks it's running on a build platform of windows-x64, why > would it try to compile for any other target than windows-x64 by default? I > don't think the build fails, it just builds for the wrong platform, but as I > said, I never tried this myself, this is second hand information. Correct, the build does not fail. It just builds for windows-x64, which one would not expect on a Windows AArch64 machine. - PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2766454002
Re: RFR: 8353009: Document target selection flag for Windows AArch64 builds
On Mon, 31 Mar 2025 10:14:54 GMT, Magnus Ihse Bursie wrote: > > Wait, are you saying you can get a native build to work by setting > > --build=aarch64-pc-cygwin? If so, then that's a better instruction IMO. > > No, it's not. If we could block the `--build` flag, we would. This is the > built-in autoconf target/host/build system, that messes with the structure we > use in OpenJDK (since we do not do canadian cross builds). > > So if you need to add configure option, this would be the correct one. > > However, we should be able to figure this out by ourselves. This can be > solved by a patch in `config.sub` and/or `config.guess`. Thanks for the clarification that the --build flag is undesirable - PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2766515715
Re: RFR: 8352693: Use a simpler console reader instead of JLine for System.console()
On Thu, 27 Mar 2025 20:48:22 GMT, Naoto Sato wrote:
>> src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java
>> line 198:
>>
>>> 196:
>>> 197: if (it.hasNext()) {
>>> 198: out.append("\n\r");
>>
>> I understand this is a simple console, but do we want to CR/LF/CRLF based on
>> the platform?
>
> `line.seprator` system property can be used here
When the terminal is in the raw/unprocessed mode, I believe `\n` is only moving
the cursor to the next line (without changing the column), and `\r` is doing
carriage return. So, to move the cursor to the first character of the next
line, both are needed.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2021410890
Re: RFR: 8352693: Use a simpler console reader instead of JLine for System.console()
On Thu, 27 Mar 2025 18:28:17 GMT, Naoto Sato wrote: >> The `java.io.Console` has several backends: a simple on in `java.base`, a >> more convenient one in `jdk.internal.le` (with line-reading based on JLine) >> and one for JShell. >> >> The backend based on JLine is proving to be a somewhat problematic - JLine >> is very powerful, possibly too powerful and complex for the simple task of >> editing a line with no completion, no history, no variables, no commands, >> etc. As a consequence, there are inevitable sharp edges in this backend. >> >> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` >> backend with a simple escape code interpreter, that only handles a handful >> of keys/codes (left/right arrow, home, end, delete, backspace, enter), and >> ignores the rest. The goal is to have something simple with less surprising >> behavior. > > src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java > line 69: > >> 67: case 4: break READ; //EOF/Ctrl-D >> 68: case 127: >> 69: //backspace: > > Is it `delete`? I don't think so. Delete is an escape sequence (`\033[3~`). - PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2021413402
Re: RFR: 8352693: Use a simpler console reader instead of JLine for System.console()
On Mon, 31 Mar 2025 17:04:55 GMT, Jan Lahoda wrote: >> src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java >> line 69: >> >>> 67: case 4: break READ; //EOF/Ctrl-D >>> 68: case 127: >>> 69: //backspace: >> >> Is it `delete`? > > I don't think so. Delete is an escape sequence (`\033[3~`). Hmm, that's interesting. In ASCII control codes, 127 is defined as `Delete` and 08 is defined as `Backspace` - PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2021427938
Re: RFR: 8352693: Use a simpler console reader instead of JLine for System.console()
On Wed, 26 Mar 2025 07:54:48 GMT, Jan Lahoda wrote: > The `java.io.Console` has several backends: a simple on in `java.base`, a > more convenient one in `jdk.internal.le` (with line-reading based on JLine) > and one for JShell. > > The backend based on JLine is proving to be a somewhat problematic - JLine is > very powerful, possibly too powerful and complex for the simple task of > editing a line with no completion, no history, no variables, no commands, > etc. As a consequence, there are inevitable sharp edges in this backend. > > The idea in this PR is to replace the use of JLine in the `jdk.internal.le` > backend with a simple escape code interpreter, that only handles a handful of > keys/codes (left/right arrow, home, end, delete, backspace, enter), and > ignores the rest. The goal is to have something simple with less surprising > behavior. src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java line 75: > 73: } > 74: continue READ; > 75: case '\033': If this is meant to be platform-agnostic, is it really safe to make these assumptions about the ability to produce or interpret escape codes and to make assumptions about their behavior on the user's terminal? I don't think it would even be safe to assume a single terminal type or interpretation on POSIX-type OSes; that's what things like `terminfo`/`termcap` are supposed to be for, right? - PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2021436018
Re: RFR: 8353009: Document target selection flag for Windows AArch64 builds [v3]
> The target selection configuration flag for Windows AArch64 should be added > to the build documentation for improved discoverability and completeness. Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision: Add instructions for a native Windows AArch64 build - Changes: - all: https://git.openjdk.org/jdk/pull/24267/files - new: https://git.openjdk.org/jdk/pull/24267/files/8cb94d9b..ce4a5914 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24267&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24267&range=01-02 Stats: 18 lines in 2 files changed: 18 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24267.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24267/head:pull/24267 PR: https://git.openjdk.org/jdk/pull/24267
Re: RFR: 8342984: Bump minimum boot jdk to JDK 24
On Fri, 28 Mar 2025 23:44:19 GMT, Mikael Vidstedt wrote: > With the JDK 24 GA out it's time to bump the minimum boot JDK version for > mainline/JDK 25. > > Testing: tier1-5, GHA Marked as reviewed by ihse (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/24305#pullrequestreview-2728827582
Re: RFR: 8352693: Use a simpler console reader instead of JLine for System.console()
On Wed, 26 Mar 2025 07:54:48 GMT, Jan Lahoda wrote: > The `java.io.Console` has several backends: a simple on in `java.base`, a > more convenient one in `jdk.internal.le` (with line-reading based on JLine) > and one for JShell. > > The backend based on JLine is proving to be a somewhat problematic - JLine is > very powerful, possibly too powerful and complex for the simple task of > editing a line with no completion, no history, no variables, no commands, > etc. As a consequence, there are inevitable sharp edges in this backend. > > The idea in this PR is to replace the use of JLine in the `jdk.internal.le` > backend with a simple escape code interpreter, that only handles a handful of > keys/codes (left/right arrow, home, end, delete, backspace, enter), and > ignores the rest. The goal is to have something simple with less surprising > behavior. src/jdk.internal.le/windows/native/lible/WindowsTerminal.cpp line 32: > 30: #include > 31: #include > 32: //#include Should you really check in new files with commented-out code? - PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2020962013
Re: RFR: 8352693: Use a simpler console reader instead of JLine for System.console()
On Wed, 26 Mar 2025 07:54:48 GMT, Jan Lahoda wrote: > The `java.io.Console` has several backends: a simple on in `java.base`, a > more convenient one in `jdk.internal.le` (with line-reading based on JLine) > and one for JShell. > > The backend based on JLine is proving to be a somewhat problematic - JLine is > very powerful, possibly too powerful and complex for the simple task of > editing a line with no completion, no history, no variables, no commands, > etc. As a consequence, there are inevitable sharp edges in this backend. > > The idea in this PR is to replace the use of JLine in the `jdk.internal.le` > backend with a simple escape code interpreter, that only handles a handful of > keys/codes (left/right arrow, home, end, delete, backspace, enter), and > ignores the rest. The goal is to have something simple with less surprising > behavior. make/modules/jdk.internal.le/Lib.gmk line 30: > 28: > > 29: > 30: ifeq ($(call isTargetOs, linux macosx windows), true) You might want to sync with the AIX guys to see if this should be enabled there as well. The unix version seems quite portable, so I assume it will work with very few adjustments, if any. @MBaesken Otherwise, what will happen if you try to run this on a platform without the corresponding native library? make/modules/jdk.internal.le/Lib.gmk line 35: > 33: NAME := le, \ > 34: TOOLCHAIN := TOOLCHAIN_LINK_CXX, \ > 35: OPTIMIZATION := LOW, \ We are trying to move away from using `LOW` as a default optimization level. If you believe this library is not performance critical, please use `SIZE` as the new default. Or, use `HIGHEST` if that gives performance benefits with no significant impact on library size. make/modules/jdk.internal.le/Lib.gmk line 36: > 34: TOOLCHAIN := TOOLCHAIN_LINK_CXX, \ > 35: OPTIMIZATION := LOW, \ > 36: JDK_LIBS := java.base:libjava, \ A quick glance through the native code revealed no obvious calls to libjava functions. Are you sure this dependency is needed? make/modules/jdk.internal.le/Lib.gmk line 37: > 35: OPTIMIZATION := LOW, \ > 36: JDK_LIBS := java.base:libjava, \ > 37: LIBS_unix := $(JDKLIB_LIBS) $(LIBCXX), \ LIBCXX is added automatically nowadays, so you can remove this entire line. make/modules/jdk.internal.le/Lib.gmk line 38: > 36: JDK_LIBS := java.base:libjava, \ > 37: LIBS_unix := $(JDKLIB_LIBS) $(LIBCXX), \ > 38: LIBS_windows := $(JDKLIB_LIBS) user32.lib, \ JDKLIB_LIBS is not used anymore. - PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2020982841 PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2020979597 PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2020976254 PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2020977176 PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2020976750
Re: RFR: 8353217: Build libsleef on macos-aarch64
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 includes build changes and libsleef sources relocation from > `src/jdk.incubator.vector/linux/native/` to > `src/jdk.incubator.vector/share/native/`. > > Once libsleef library is present, existing code in > `stubGenerator_aarch64.cpp` successfully links at JVM startup. > > Testing: hs-tier1 - hs-tier4, microbenchmarks Instead of trying to guide you how to fix this, I made the unification of all libsleef stanzas myself. It is available here: https://github.com/openjdk/jdk/commit/04feadda561b2f7a6afff440ab5b4e188361c048 That commit assumes that `vector_math_sve.c` should have `$(SVE_CFLAGS)` on mac as well as on linux. If that is not correct, then it needs to be adjusted. - PR Comment: https://git.openjdk.org/jdk/pull/24306#issuecomment-2766072866
Re: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files [v2]
On Tue, 25 Mar 2025 01:54:33 GMT, Patrick Zhang wrote: >> make/common/native/Flags.gmk line 125: >> >>> 123: endif >>> 124: ifeq ($(STATIC_LIBS), true) >>> 125: $1_EXTRA_CXXFLAGS += -DSTATIC_BUILD=1 >> >> This seems unrelated to the fix? > >> 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which was >> missed by >> [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) >> for the refactor of building static libs. > > Unrelated, after the fix got limited to `JvmFlags.gmk` only. > However, it is a practical bug, and existing tests did not cover the corner > case. As described in the No.3 bullet of this PR. The problem showed up when > I tested applying `EXTRA_CXXFLAGS to `precompiled.hpp.gch`. It is a simple > and tiny fix which may not require a separate PR I thought, does it? > > FYI, the failures on linux-x64-static and linux-x64-static-libs tests, > captured by OpenJDK GHA Sanity Checks: > https://github.com/cnqpzhang/jdk/actions/runs/13943096440. You are correct that this is a bug, but the fix should not be sneaked in under the guise of another problem. I created https://bugs.openjdk.org/browse/JDK-8353272 for this. - PR Review Comment: https://git.openjdk.org/jdk/pull/24115#discussion_r2021042829
RFR: 8353272: One instance of STATIC_LIB_CFLAGS was missed in JDK-8345683
It turns out one instance of STATIC_LIB_CFLAGS was missed in Flags.gmk when fixing [JDK-8345683](https://bugs.openjdk.org/browse/JDK-8345683). This was noticed by @cnqpzhang in https://github.com/openjdk/jdk/pull/24115/files#r2011164138. - Commit messages: - 8353272: One instance of STATIC_LIB_CFLAGS was missed in JDK-8345683 Changes: https://git.openjdk.org/jdk/pull/24327/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24327&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353272 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24327.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24327/head:pull/24327 PR: https://git.openjdk.org/jdk/pull/24327
Re: RFR: 8353217: Build libsleef on macos-aarch64
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 includes build changes and libsleef sources relocation from > `src/jdk.incubator.vector/linux/native/` to > `src/jdk.incubator.vector/share/native/`. > > Once libsleef library is present, existing code in > `stubGenerator_aarch64.cpp` successfully links at JVM startup. > > Testing: hs-tier1 - hs-tier4, microbenchmarks make/modules/jdk.incubator.vector/Lib.gmk line 85: > 83: DISABLED_WARNINGS_gcc := unused-function sign-compare > tautological-compare ignored-qualifiers, \ > 84: DISABLED_WARNINGS_clang := unused-function sign-compare > tautological-compare ignored-qualifiers, \ > 85: CFLAGS := $(NEON_CFLAGS), \ Is this supposed to match configs for linux-aarch64? I see we add `NEON_CFLAGS` here, and do _not_ add `vector_math_sve.c_CFLAGS` here. I would have thought those two are applicable to macos-aarch64 as well? - PR Review Comment: https://git.openjdk.org/jdk/pull/24306#discussion_r2020647457
Re: RFR: 8353217: Build libsleef on macos-aarch64
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 includes build changes and libsleef sources relocation from > `src/jdk.incubator.vector/linux/native/` to > `src/jdk.incubator.vector/share/native/`. > > Once libsleef library is present, existing code in > `stubGenerator_aarch64.cpp` successfully links at JVM startup. > > Testing: hs-tier1 - hs-tier4, microbenchmarks The build code seems like it should be the same as for linux/aarch64. In fact, at this point, the code duplication should be removed into a single setup call. - PR Comment: https://git.openjdk.org/jdk/pull/24306#issuecomment-2766037908
Re: RFR: 8352284: EXTRA_CFLAGS incorrectly applied to BUILD_LIBJVM src/hotspot C++ source files [v4]
On Mon, 31 Mar 2025 14:31:56 GMT, Patrick Zhang wrote: >> Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'` >> triggers 1000+ warning messages like `cc1plus: warning: command-line option >> ‘-Wno-incompatible-pointer-types’ is valid for C/ObjC but not for C++`. >> >> The root cause is that `JVM_CFLAGS ` which contains both `EXTRA_CXXFLAGS` >> and `EXTRA_CFLAGS` when compiling `src/hotspot` C++ source files and >> building `BUILD_LIBJVM`. >> >> This PR does: >> 1. Not to append `EXTRA_CFLAGS` or `EXTRA_CXXFLAGS` into `JVM_CFLAGS` before >> calling `SetupJdkLibrary`, instead let `SetupCompilerFlags` accept and merge >> `EXTRA_CFLAGS` and `EXTRA_CXXFLAGS` passed from `SetupJdkLibrary` as >> parameters, so CPP compilation will only see `EXTRA_CXXFLAGS` as expected. >> 2. Correct `PCH_COMMAND` to use `EXTRA_CXXFLAGS` as precompiled.hpp.gch >> should not be compiled with `EXTRA_CFLAGS`. >> 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which was >> missed by >> [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7acc993cc4a2096cf31ccf40R114-R121) >> for the refactor of building static libs. >> >> Tests: Passed jdk building on an AArch64 Linux system and tier1 sanity >> tests, also passed OpenJDK GHA Sanity Checks. > > Patrick Zhang has updated the pull request incrementally with one additional > commit since the last revision: > > Revertd the STATIC_LIB_CFLAGS fix as it is coverted by JDK-8353272 > > Signed-off-by: Patrick Zhang Marked as reviewed by erikj (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/24115#pullrequestreview-273582
Re: RFR: 8353009: Document target selection flag for Windows AArch64 builds
On Mon, 31 Mar 2025 15:00:08 GMT, Saint Wesonga wrote: > > > Wait, are you saying you can get a native build to work by setting > > > --build=aarch64-pc-cygwin? If so, then that's a better instruction IMO. > > > > > > No, it's not. If we could block the `--build` flag, we would. This is the > > built-in autoconf target/host/build system, that messes with the structure > > we use in OpenJDK (since we do not do canadian cross builds). > > So if you need to add configure option, this would be the correct one. > > However, we should be able to figure this out by ourselves. This can be > > solved by a patch in `config.sub` and/or `config.guess`. > > Thanks for the clarification that the --build flag is undesirable I do not agree with `--build` being undesirable in this specific instance. I agree that it's generally not a flag we want to encourage using, but in this specific case, it's necessary to perform a native build on this platform. - PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2766916854
Re: RFR: 8353009: Document target selection flag for Windows AArch64 builds
On Mon, 31 Mar 2025 14:44:23 GMT, Saint Wesonga wrote: > Upon closer inspection, the --build option results in a native build (per the > build system) but the ARM64 C++ compiler binary (cl.exe) is actually an x64 > binary, so the compiler is running in emulated mode despite the build system > thinking that a native build is happening. I'm investigating this in > https://bugs.openjdk.org/browse/JDK-8353066 The logic for finding the vcvars.cmd file to setup the Visual Studio environment is hardcoded for x64. You will need to make that logic more generic. > I propose changing the scope of this PR to documenting cross compilation for > windows/aarch64 on windows/x64 and fixing the native build in > https://bugs.openjdk.org/browse/JDK-8353066 I propose expanding on the doc in this PR just a tad and explaining that to perform a _native_ windows-aarch64 build with Cygwin, you need to set `--build=aarch64-pc-cygwin` as a workaround and to cross compile it, set `--openjdk-target=aarch64-unknown-cygwin`. But it depends on how quickly you expect to fix JDK-8353066. At the very least, the documentation needs to be clear on the difference between a native and a cross compile setup. - PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2766930392
Re: RFR: 8353009: Document target selection flag for Windows AArch64 builds
On Mon, 31 Mar 2025 13:16:34 GMT, Erik Joelsson wrote: > > Wait a minute. I re-read the discussion a bit more carefully, and let my > > brain re-process what I said above... > > Is the goal here to document how you properly do cross-compilation for > > windows/aarch64 on windows/x64? If so, I think this is a correct solution, > > but the documentation should be more clear that this applies for > > cross-compiling to windows/aarch64 from x64 on cygwin. > > If the problem is that native builds on windows/aarch64 does not work, then > > it is a different issue that needs to be fixed. > > The problem applies to both native and cross compilation, though cross > compilation is no different than other platforms. The reason native > compilation doesn't work on Cygwin is that there is no aarch64 distro of > Cygwin, so even a native windows aarch64 build will use an x64 version of > Cygwin running in emulated mode (I don't know the name on Windows, but pretty > much the same as rosetta on mac). This trips up configure into thinking we > are running on a native windows x64 machine, and it's the reason why telling > configure that the **build** platform is `aarch64-pc-cygwin` helps. Caveat, > this is all based on what I've heard, I've never had access to a > windows-aarch64 machine. > > I completely agree that fixing this detection issue is better than > documenting, but I also think that documenting how to perform a native build > is better than how to perform a cross build on a native machine. Cross > compiling works, but adds increased complexity and build time unnecessarily > in this case. Upon closer inspection, the --build option results in a native build (per the build system) but the ARM64 C++ compiler binary (cl.exe) is actually an x64 binary, so the compiler is running in emulated mode despite the build system thinking that a native build is happening. I'm investigating this in https://bugs.openjdk.org/browse/JDK-8353066 I propose changing the scope of this PR to documenting cross compilation for windows/aarch64 on windows/x64 and fixing the native build in https://bugs.openjdk.org/browse/JDK-8353066 - PR Comment: https://git.openjdk.org/jdk/pull/24267#issuecomment-2766469401
