Re: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two
Hi Bob, On 18/09/2018 2:20 AM, Bob Vandette wrote: Please review the changes related to JEP 340 which remove the second 64-bit ARM port from the JDK. http://cr.openjdk.java.net/~bobv/8209093/webrev.01 I’ve testing building the remaining 32 and 64 bit ARM ports including the minimal, client and server VMs. I’ve run specJVM98 on the three 32-bit ARM VMs. Did you test all the ARM related abi-profiles? It seems to me they were only for Oracle's ARM32 port and may have never been used otherwise. I would have expected all that stuff to be removed. Cheers, David I also verified that Linux x64 builds. Bob.
Re: RFR: JDK-8210592: Convert CDS-mode test sets in tier5 and tier6 to non-CDS-mode testing
Thanks, David! Jiangli On 9/17/18 4:45 PM, David Holmes wrote: Hi Jiangli, Conversion looks good. Thanks, David On 18/09/2018 8:15 AM, Jiangli Zhou wrote: Please review the change for JEP 341 (Default CDS Archives) sub-task, JDK-8210592. Currently, there are sub-sets of tiered tests running in CDS mode (defined in closed tier5 and tier6 test definitions). These tests are also executed in 'normal' mode in various tiers. GENERATE_CDS_ARCHIVE is used to create a CDS archive using the default classlist before executing those tests in CDS-mode. When the default CDS archive is enabled, it is no longer necessary to execute those tests in CDS mode explicitly since all tiered testing enables the default CDS archive by default. The change in the webrev removes GENERATE_CDS_ARCHIVE. To increase test coverage, the test sets in CDS mode are converted to run in non-CDS mode (with -Xshare:off enabled explicitly) in tier5 and tier6. The conversion is done in the closed repo. webrev: http://cr.openjdk.java.net/~jiangli/8210592/webrev.00/ JEP sub-task: https://bugs.openjdk.java.net/browse/JDK-8210592 Tested tier5 and tier6 with the default CDS archive patch enabled. Thanks, Jiangli
Re: RFR: JDK-8210592: Convert CDS-mode test sets in tier5 and tier6 to non-CDS-mode testing
Thanks, Erik! Jiangli On 9/17/18 4:42 PM, Erik Joelsson wrote: Looks good. /Erik On 2018-09-17 15:15, Jiangli Zhou wrote: Please review the change for JEP 341 (Default CDS Archives) sub-task, JDK-8210592. Currently, there are sub-sets of tiered tests running in CDS mode (defined in closed tier5 and tier6 test definitions). These tests are also executed in 'normal' mode in various tiers. GENERATE_CDS_ARCHIVE is used to create a CDS archive using the default classlist before executing those tests in CDS-mode. When the default CDS archive is enabled, it is no longer necessary to execute those tests in CDS mode explicitly since all tiered testing enables the default CDS archive by default. The change in the webrev removes GENERATE_CDS_ARCHIVE. To increase test coverage, the test sets in CDS mode are converted to run in non-CDS mode (with -Xshare:off enabled explicitly) in tier5 and tier6. The conversion is done in the closed repo. webrev: http://cr.openjdk.java.net/~jiangli/8210592/webrev.00/ JEP sub-task: https://bugs.openjdk.java.net/browse/JDK-8210592 Tested tier5 and tier6 with the default CDS archive patch enabled. Thanks, Jiangli
Re: RFR: JDK-8210592: Convert CDS-mode test sets in tier5 and tier6 to non-CDS-mode testing
Hi Jiangli, Conversion looks good. Thanks, David On 18/09/2018 8:15 AM, Jiangli Zhou wrote: Please review the change for JEP 341 (Default CDS Archives) sub-task, JDK-8210592. Currently, there are sub-sets of tiered tests running in CDS mode (defined in closed tier5 and tier6 test definitions). These tests are also executed in 'normal' mode in various tiers. GENERATE_CDS_ARCHIVE is used to create a CDS archive using the default classlist before executing those tests in CDS-mode. When the default CDS archive is enabled, it is no longer necessary to execute those tests in CDS mode explicitly since all tiered testing enables the default CDS archive by default. The change in the webrev removes GENERATE_CDS_ARCHIVE. To increase test coverage, the test sets in CDS mode are converted to run in non-CDS mode (with -Xshare:off enabled explicitly) in tier5 and tier6. The conversion is done in the closed repo. webrev: http://cr.openjdk.java.net/~jiangli/8210592/webrev.00/ JEP sub-task: https://bugs.openjdk.java.net/browse/JDK-8210592 Tested tier5 and tier6 with the default CDS archive patch enabled. Thanks, Jiangli
Re: RFR: JDK-8210592: Convert CDS-mode test sets in tier5 and tier6 to non-CDS-mode testing
Looks good. /Erik On 2018-09-17 15:15, Jiangli Zhou wrote: Please review the change for JEP 341 (Default CDS Archives) sub-task, JDK-8210592. Currently, there are sub-sets of tiered tests running in CDS mode (defined in closed tier5 and tier6 test definitions). These tests are also executed in 'normal' mode in various tiers. GENERATE_CDS_ARCHIVE is used to create a CDS archive using the default classlist before executing those tests in CDS-mode. When the default CDS archive is enabled, it is no longer necessary to execute those tests in CDS mode explicitly since all tiered testing enables the default CDS archive by default. The change in the webrev removes GENERATE_CDS_ARCHIVE. To increase test coverage, the test sets in CDS mode are converted to run in non-CDS mode (with -Xshare:off enabled explicitly) in tier5 and tier6. The conversion is done in the closed repo. webrev: http://cr.openjdk.java.net/~jiangli/8210592/webrev.00/ JEP sub-task: https://bugs.openjdk.java.net/browse/JDK-8210592 Tested tier5 and tier6 with the default CDS archive patch enabled. Thanks, Jiangli
Re: RFR: JDK-8210592: Convert CDS-mode test sets in tier5 and tier6 to non-CDS-mode testing
Thanks, Misha! Jiangli > On Sep 17, 2018, at 4:17 PM, mikhailo wrote: > > Change looks good, > > Misha > > >> On 09/17/2018 03:15 PM, Jiangli Zhou wrote: >> Please review the change for JEP 341 (Default CDS Archives) sub-task, >> JDK-8210592. >> >> Currently, there are sub-sets of tiered tests running in CDS mode (defined >> in closed tier5 and tier6 test definitions). These tests are also executed >> in 'normal' mode in various tiers. GENERATE_CDS_ARCHIVE is used to create a >> CDS archive using the default classlist before executing those tests in >> CDS-mode. >> >> When the default CDS archive is enabled, it is no longer necessary to >> execute those tests in CDS mode explicitly since all tiered testing enables >> the default CDS archive by default. The change in the webrev removes >> GENERATE_CDS_ARCHIVE. To increase test coverage, the test sets in CDS mode >> are converted to run in non-CDS mode (with -Xshare:off enabled explicitly) >> in tier5 and tier6. The conversion is done in the closed repo. >> >> webrev: http://cr.openjdk.java.net/~jiangli/8210592/webrev.00/ >> >> JEP sub-task: https://bugs.openjdk.java.net/browse/JDK-8210592 >> >> Tested tier5 and tier6 with the default CDS archive patch enabled. >> >> Thanks, >> >> Jiangli >> >
Re: RFR: JDK-8210592: Convert CDS-mode test sets in tier5 and tier6 to non-CDS-mode testing
Change looks good, Misha On 09/17/2018 03:15 PM, Jiangli Zhou wrote: Please review the change for JEP 341 (Default CDS Archives) sub-task, JDK-8210592. Currently, there are sub-sets of tiered tests running in CDS mode (defined in closed tier5 and tier6 test definitions). These tests are also executed in 'normal' mode in various tiers. GENERATE_CDS_ARCHIVE is used to create a CDS archive using the default classlist before executing those tests in CDS-mode. When the default CDS archive is enabled, it is no longer necessary to execute those tests in CDS mode explicitly since all tiered testing enables the default CDS archive by default. The change in the webrev removes GENERATE_CDS_ARCHIVE. To increase test coverage, the test sets in CDS mode are converted to run in non-CDS mode (with -Xshare:off enabled explicitly) in tier5 and tier6. The conversion is done in the closed repo. webrev: http://cr.openjdk.java.net/~jiangli/8210592/webrev.00/ JEP sub-task: https://bugs.openjdk.java.net/browse/JDK-8210592 Tested tier5 and tier6 with the default CDS archive patch enabled. Thanks, Jiangli
RFR: JDK-8210592: Convert CDS-mode test sets in tier5 and tier6 to non-CDS-mode testing
Please review the change for JEP 341 (Default CDS Archives) sub-task, JDK-8210592. Currently, there are sub-sets of tiered tests running in CDS mode (defined in closed tier5 and tier6 test definitions). These tests are also executed in 'normal' mode in various tiers. GENERATE_CDS_ARCHIVE is used to create a CDS archive using the default classlist before executing those tests in CDS-mode. When the default CDS archive is enabled, it is no longer necessary to execute those tests in CDS mode explicitly since all tiered testing enables the default CDS archive by default. The change in the webrev removes GENERATE_CDS_ARCHIVE. To increase test coverage, the test sets in CDS mode are converted to run in non-CDS mode (with -Xshare:off enabled explicitly) in tier5 and tier6. The conversion is done in the closed repo. webrev: http://cr.openjdk.java.net/~jiangli/8210592/webrev.00/ JEP sub-task: https://bugs.openjdk.java.net/browse/JDK-8210592 Tested tier5 and tier6 with the default CDS archive patch enabled. Thanks, Jiangli
Re: RFF (12): JDK-8207954: Data for --release 11
Jan, OK for the code changes. I still think it would be nice to see makefile support for generating these files, as compared to comments in source coe, but that can be handled separately. -- Jon On 07/23/2018 04:44 AM, Jan Lahoda wrote: Hi, To support --release 11 in JDK 12, historical data for JDK 11 need to be added. As new attributes (NestHost and NestMembers) have been added to the classfile, there also needs to be some tweaking of the tool that creates the historical descriptions and the ct.sym sigfiles. The proposed patch has two parts: -code changes, which include: --update to the build scripts and the tool, so that the tool can read both the open and extra/closed description of the ct.sym content, and merge those (there should not be any extra/closed for JDK 11, AFAIK, so this is to avoid having to update the closed part). --improving the description on how to add historical data for new releases, using the new source launcher --adding support for the new NestHost/NestMembers attributes --adding a new test which strives to fail when a new attribute is added and CreateSymbols is not updated http://cr.openjdk.java.net/~jlahoda/8207954/webrev.code.00/ -addition of the historical data: http://cr.openjdk.java.net/~jlahoda/8207954/webrev.data.00/ (these may need to be re-generated when the final JDK 11 is released in case there are any changes, but that should be very simple) JBS: https://bugs.openjdk.java.net/browse/JDK-8207954 Any feedback is welcome, Jan
Re: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two
Thanks for the detailed review Aleksey. I took care of these.
Bob.
> On Sep 17, 2018, at 1:49 PM, Aleksey Shipilev wrote:
>
> On 09/17/2018 07:00 PM, Vladimir Kozlov wrote:
>> On 9/17/18 9:20 AM, Bob Vandette wrote:
>>> Please review the changes related to JEP 340 which remove the second
>>> 64-bit ARM port from the JDK.>>
>>> http://cr.openjdk.java.net/~bobv/8209093/webrev.01
>
> I read through the webrev, and it seems to be the clean removal. It also feels
> very satisfying to drop 15 KLOC of ifdef-ed code.
>
> Minor nits:
>
> *) In src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp and
> src/hotspot/cpu/arm/interp_masm_arm.cpp we have "#if defined(ASSERT)", which
> cab
> be just "#ifdef ASSERT" now
>
> *) Ditto in src/hotspot/cpu/arm/jniFastGetField_arm.cpp we have "#if
> defined(__ABI_HARD__)"
>
> *) In src/hotspot/cpu/arm/macroAssembler_arm.hpp, the comment below seems to
> apply to AArch64 only. Yet, only the first line of the comment is removed. I
> think we should instead convert that comment into "TODO:" mentioning this
> might
> be revised after AArch64 removal?
>
> 992 void branch_if_negative_32(Register r, Label& L) {
> 993 // Note about branch_if_negative_32() / branch_if_any_negative_32()
> implementation for AArch64:
> 994 // tbnz is not used instead of tst & b.mi because destination may be
> out of tbnz range (+-32KB)
> 995 // since these methods are used in LIR_Assembler::emit_arraycopy() to
> jump to stub entry.
> 996 tst_32(r, r);
> 997 b(L, mi);
> 998 }
>
> *) In src/hotspot/cpu/arm/stubGenerator_arm.cpp, lines L1204..1205,
> L1435..1436
> can be merged together:
>
> 1203 // Generate the inner loop for shifted forward array copy (unaligned
> copy).
> 1204 // It can be used when bytes_per_count < wordSize, i.e.
> 1205 // byte/short copy
>
> 1434 // Generate the inner loop for shifted backward array copy (unaligned
> copy).
> 1435 // It can be used when bytes_per_count < wordSize, i.e.
> 1436 // byte/short copy
>
>
> *) In src/hotspot/cpu/arm/stubGenerator_arm.cpp, the comment changed
> incorrectly around L3363?
>
> - //R4 (AArch64) / SP[0] (32-bit ARM) - element count (32-bit int)
> + //R4- element count (32-bit int)
>
>
> *) In src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp, "R4"/"R5"
> comments are missing:
>
> - const Register Rsig_handler= AARCH64_ONLY(R21) NOT_AARCH64(Rtmp_save0
> /*
> R4 */);
> - const Register Rnative_code= AARCH64_ONLY(R22) NOT_AARCH64(Rtmp_save1
> /*
> R5 */);
> + const Register Rsig_handler= Rtmp_save0;
> + const Register Rnative_code= Rtmp_save1;
>
> Thanks,
> -Aleksey
>
Re: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two
On 09/17/2018 07:00 PM, Vladimir Kozlov wrote:
> On 9/17/18 9:20 AM, Bob Vandette wrote:
>> Please review the changes related to JEP 340 which remove the second
>> 64-bit ARM port from the JDK.>>
>> http://cr.openjdk.java.net/~bobv/8209093/webrev.01
I read through the webrev, and it seems to be the clean removal. It also feels
very satisfying to drop 15 KLOC of ifdef-ed code.
Minor nits:
*) In src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp and
src/hotspot/cpu/arm/interp_masm_arm.cpp we have "#if defined(ASSERT)", which cab
be just "#ifdef ASSERT" now
*) Ditto in src/hotspot/cpu/arm/jniFastGetField_arm.cpp we have "#if
defined(__ABI_HARD__)"
*) In src/hotspot/cpu/arm/macroAssembler_arm.hpp, the comment below seems to
apply to AArch64 only. Yet, only the first line of the comment is removed. I
think we should instead convert that comment into "TODO:" mentioning this might
be revised after AArch64 removal?
992 void branch_if_negative_32(Register r, Label& L) {
993 // Note about branch_if_negative_32() / branch_if_any_negative_32()
implementation for AArch64:
994 // tbnz is not used instead of tst & b.mi because destination may be
out of tbnz range (+-32KB)
995 // since these methods are used in LIR_Assembler::emit_arraycopy() to
jump to stub entry.
996 tst_32(r, r);
997 b(L, mi);
998 }
*) In src/hotspot/cpu/arm/stubGenerator_arm.cpp, lines L1204..1205, L1435..1436
can be merged together:
1203 // Generate the inner loop for shifted forward array copy (unaligned
copy).
1204 // It can be used when bytes_per_count < wordSize, i.e.
1205 // byte/short copy
1434 // Generate the inner loop for shifted backward array copy (unaligned
copy).
1435 // It can be used when bytes_per_count < wordSize, i.e.
1436 // byte/short copy
*) In src/hotspot/cpu/arm/stubGenerator_arm.cpp, the comment changed
incorrectly around L3363?
- //R4 (AArch64) / SP[0] (32-bit ARM) - element count (32-bit int)
+ //R4- element count (32-bit int)
*) In src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp, "R4"/"R5"
comments are missing:
- const Register Rsig_handler= AARCH64_ONLY(R21) NOT_AARCH64(Rtmp_save0 /*
R4 */);
- const Register Rnative_code= AARCH64_ONLY(R22) NOT_AARCH64(Rtmp_save1 /*
R5 */);
+ const Register Rsig_handler= Rtmp_save0;
+ const Register Rnative_code= Rtmp_save1;
Thanks,
-Aleksey
Re: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two
Build changes look ok. /Erik On 2018-09-17 10:00, Vladimir Kozlov wrote: CCing to build-dev and aarch64-port. I looked through changes and they seem fine. Thanks, Vladimir On 9/17/18 9:20 AM, Bob Vandette wrote: Please review the changes related to JEP 340 which remove the second 64-bit ARM port from the JDK. http://cr.openjdk.java.net/~bobv/8209093/webrev.01 I’ve testing building the remaining 32 and 64 bit ARM ports including the minimal, client and server VMs. I’ve run specJVM98 on the three 32-bit ARM VMs. I also verified that Linux x64 builds. Bob.
Re: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two
CCing to build-dev and aarch64-port. I looked through changes and they seem fine. Thanks, Vladimir On 9/17/18 9:20 AM, Bob Vandette wrote: Please review the changes related to JEP 340 which remove the second 64-bit ARM port from the JDK. http://cr.openjdk.java.net/~bobv/8209093/webrev.01 I’ve testing building the remaining 32 and 64 bit ARM ports including the minimal, client and server VMs. I’ve run specJVM98 on the three 32-bit ARM VMs. I also verified that Linux x64 builds. Bob.
Re: Failed to compile OpenJDK 12-dev by LLVM 8 for X86 with OpenJDK 10 boot jdk
We haven't yet agreed on how to fix https://bugs.openjdk.java.net/browse/JDK-8186780 You can locally apply any of the fixes from the bug report and you can give an opinion on which fix you like. On Mon, Sep 17, 2018 at 6:26 AM, Leslie Zhai wrote: > https://bugs.openjdk.java.net/browse/JDK-8186780 > > > > 在 2018年09月16日 13:21, Leslie Zhai 写道: >> >> Hi, >> >> I just want to verify JDK-8206183 and JDK-8205965 built with clang-8[1] >> >> >> http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023172.html >> >> $ hg log | head >> changeset: 51758:6c956c883137 >> tag: tip >> user:igerasim >> date:Sat Sep 15 13:53:43 2018 -0700 >> summary: 8210787: Object.wait(long, int) throws inappropriate >> IllegalArgumentException >> >> $ ./configure --with-debug-level=fastdebug --with-toolchain-type=clang >> --with-boot-jdk=/home/xiangzhai/jdk-10.0.2 --disable-warnings-as-errors >> >> Tools summary: >> * Boot JDK: openjdk version "10.0.2" 2018-07-17 OpenJDK Runtime >> Environment 18.3 (build 10.0.2+13) OpenJDK 64-Bit Server VM 18.3 (build >> 10.0.2+13, mixed mode) (at /home/xiangzhai/jdk-10.0.2) >> * Toolchain: clang (clang/LLVM) >> * C Compiler: Version 8.0.0 (at /opt/llvm-git/bin/clang) >> * C++ Compiler: Version 8.0.0 (at /opt/llvm-git/bin/clang++) >> >> $ make images >> >> ... >> >> Building target 'images' in configuration >> 'linux-x86_64-normal-server-fastdebug' >> # To suppress the following error report, specify this argument >> # after -XX: or in .hotspotrc: SuppressErrorAt=/os_linux_x86.cpp:833 >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error >> (/home/xiangzhai/project/jdk/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp:833), >> pid=3156, tid=3157 >> # assert(((intptr_t)os::current_stack_pointer() & >> (StackAlignmentInBytes-1)) == 0) failed: incorrect stack alignment >> # >> # JRE version: (12.0) (fastdebug build ) >> # Java VM: OpenJDK 64-Bit Server VM (fastdebug >> 12-internal+0-adhoc.xiangzhai.jdk, mixed mode, tiered, compressed oops, >> serial gc, linux-amd64) >> # Core dump will be written. Default location: Core dumps may be processed >> with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t %P %I" (or dumping to >> /home/xiangzhai/project/jdk/make/core.3156) >> # >> # An error report file with more information is saved as: >> # /home/xiangzhai/project/jdk/make/hs_err_pid3156.log >> # >> # If you would like to submit a bug report, please visit: >> # http://bugreport.java.com/bugreport/crash.jsp >> # >> Current thread is 3157 >> Dumping core ... >> >> - 8< 8< 8< 8< 8< 8< --- >> But clang-3.9[2] is OK! >> >> Tools summary: >> * Boot JDK: openjdk version "10.0.2" 2018-07-17 OpenJDK Runtime >> Environment 18.3 (build 10.0.2+13) OpenJDK 64-Bit Server VM 18.3 (build >> 10.0.2+13, mixed mode) (at /home/xiangzhai/jdk-10.0.2) >> * Toolchain: clang (clang/LLVM) >> * C Compiler: Version 3.9.1 (at /usr/bin/clang) >> * C++ Compiler: Version 3.9.1 (at /usr/bin/clang++) >> >> $ strings ./build/linux-x86_64-normal-server-slowdebug/images/jdk/bin/java >> | grep clang >> clang version 3.9.1 (tags/RELEASE_391/final) >> >> $ ./build/linux-x86_64-normal-server-slowdebug/images/jdk/bin/java >> -version >> openjdk version "12-internal" 2019-03-19 >> OpenJDK Runtime Environment (slowdebug build >> 12-internal+0-adhoc.xiangzhai.jdk) >> OpenJDK 64-Bit Server VM (slowdebug build >> 12-internal+0-adhoc.xiangzhai.jdk, mixed mode) >> >> [1] $ clang -v >> LLVM China clang version 8.0.0 (g...@github.com:llvm-mirror/clang.git >> 7f223b8fbf26fa0e4d8f98847a53c4ba457720f0) >> (g...@github.com:llvm-mirror/llvm.git >> 841e300fb15be4f9931d18d2f24f48cb59ef24a8) (based on LLVM 8.0.0svn) >> Target: x86_64-redhat-linux >> Thread model: posix >> InstalledDir: /opt/llvm-git/bin >> Found candidate GCC installation: /usr/lib/gcc/i686-redhat-linux/6.4.1 >> Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/6.4.1 >> Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/6.4.1 >> Candidate multilib: .;@m64 >> Candidate multilib: 32;@m32 >> Selected multilib: .;@m64 >> >> [2] $ clang -v >> clang version 3.9.1 (tags/RELEASE_391/final) >> Target: x86_64-unknown-linux-gnu >> Thread model: posix >> InstalledDir: /usr/bin >> Found candidate GCC installation: >> /usr/bin/../lib/gcc/i686-redhat-linux/6.4.1 >> Found candidate GCC installation: >> /usr/bin/../lib/gcc/x86_64-redhat-linux/6.4.1 >> Found candidate GCC installation: /usr/lib/gcc/i686-redhat-linux/6.4.1 >> Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/6.4.1 >> Selected GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/6.4.1 >> Candidate multilib: .;@m64 >> Candidate multilib: 32;@m32 >> Selected multilib: .;@m64 >> > > -- > Regards, > Leslie Zhai > >
[8u] RFR: 8207057: No debug info for assembler files
Hi, Please review this 8u backport of JDK-8207057 which adds debug info when assembling assembler files. The build system changed between 9+ and 8u, so it's an independent patch from JDK 12's version. Bug: https://bugs.openjdk.java.net/browse/JDK-8207057 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8207057/jdk8/01/ Testing: Debugging of assembler files in gdb. Eyeballing compile logs. Thoughts? Thanks, Severin
Re: Failed to compile OpenJDK 12-dev by LLVM 8 for X86 with OpenJDK 10 boot jdk
https://bugs.openjdk.java.net/browse/JDK-8186780 在 2018年09月16日 13:21, Leslie Zhai 写道: Hi, I just want to verify JDK-8206183 and JDK-8205965 built with clang-8[1] http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023172.html $ hg log | head changeset: 51758:6c956c883137 tag: tip user: igerasim date: Sat Sep 15 13:53:43 2018 -0700 summary: 8210787: Object.wait(long, int) throws inappropriate IllegalArgumentException $ ./configure --with-debug-level=fastdebug --with-toolchain-type=clang --with-boot-jdk=/home/xiangzhai/jdk-10.0.2 --disable-warnings-as-errors Tools summary: * Boot JDK: openjdk version "10.0.2" 2018-07-17 OpenJDK Runtime Environment 18.3 (build 10.0.2+13) OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode) (at /home/xiangzhai/jdk-10.0.2) * Toolchain: clang (clang/LLVM) * C Compiler: Version 8.0.0 (at /opt/llvm-git/bin/clang) * C++ Compiler: Version 8.0.0 (at /opt/llvm-git/bin/clang++) $ make images ... Building target 'images' in configuration 'linux-x86_64-normal-server-fastdebug' # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/os_linux_x86.cpp:833 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/xiangzhai/project/jdk/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp:833), pid=3156, tid=3157 # assert(((intptr_t)os::current_stack_pointer() & (StackAlignmentInBytes-1)) == 0) failed: incorrect stack alignment # # JRE version: (12.0) (fastdebug build ) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 12-internal+0-adhoc.xiangzhai.jdk, mixed mode, tiered, compressed oops, serial gc, linux-amd64) # Core dump will be written. Default location: Core dumps may be processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t %P %I" (or dumping to /home/xiangzhai/project/jdk/make/core.3156) # # An error report file with more information is saved as: # /home/xiangzhai/project/jdk/make/hs_err_pid3156.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # Current thread is 3157 Dumping core ... - 8< 8< 8< 8< 8< 8< --- But clang-3.9[2] is OK! Tools summary: * Boot JDK: openjdk version "10.0.2" 2018-07-17 OpenJDK Runtime Environment 18.3 (build 10.0.2+13) OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode) (at /home/xiangzhai/jdk-10.0.2) * Toolchain: clang (clang/LLVM) * C Compiler: Version 3.9.1 (at /usr/bin/clang) * C++ Compiler: Version 3.9.1 (at /usr/bin/clang++) $ strings ./build/linux-x86_64-normal-server-slowdebug/images/jdk/bin/java | grep clang clang version 3.9.1 (tags/RELEASE_391/final) $ ./build/linux-x86_64-normal-server-slowdebug/images/jdk/bin/java -version openjdk version "12-internal" 2019-03-19 OpenJDK Runtime Environment (slowdebug build 12-internal+0-adhoc.xiangzhai.jdk) OpenJDK 64-Bit Server VM (slowdebug build 12-internal+0-adhoc.xiangzhai.jdk, mixed mode) [1] $ clang -v LLVM China clang version 8.0.0 (g...@github.com:llvm-mirror/clang.git 7f223b8fbf26fa0e4d8f98847a53c4ba457720f0) (g...@github.com:llvm-mirror/llvm.git 841e300fb15be4f9931d18d2f24f48cb59ef24a8) (based on LLVM 8.0.0svn) Target: x86_64-redhat-linux Thread model: posix InstalledDir: /opt/llvm-git/bin Found candidate GCC installation: /usr/lib/gcc/i686-redhat-linux/6.4.1 Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/6.4.1 Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/6.4.1 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 [2] $ clang -v clang version 3.9.1 (tags/RELEASE_391/final) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib/gcc/i686-redhat-linux/6.4.1 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/6.4.1 Found candidate GCC installation: /usr/lib/gcc/i686-redhat-linux/6.4.1 Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/6.4.1 Selected GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/6.4.1 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 -- Regards, Leslie Zhai
Re: Syntax error with set-vs-env.sh: - building jdk8u on Windows (cygwin)
Hi Erik,
Thanks for the info, inside that shell script we noticed the concatenation
of PATH with whatever the host already had got corrupted (because of the
way we set it). We've fixed our ansible scripts locally and the build is
now going through again.
Cheers,
Martijn
On Fri, 14 Sep 2018 at 18:11, Erik Joelsson
wrote:
> That code was rather recently touched in 8u when backporting support for
> devkits and newer versions of Visual Studio. What is the contents of the
> generated set-vs-env.sh?
>
> /Erik
>
>
> On 2018-09-14 05:29, Martijn Verburg wrote:
> > Hi all,
> >
> > AdoptOpenJDK recently started seeing this error (full configure details
> > below the horizontal), has anyone else experienced this:
> >
> > configure: Setting extracted environment variables
> >
> /cygdrive/c/cygwin64/tmp/tmp.wVFLippfrz/workspace/build/src/build/windows-x86_64-normal-server-release/vs-env/
> > syntax error near unexpected token `('
> >
> /cygdrive/c/cygwin64/tmp/tmp.wVFLippfrz/workspace/build/src/build/windows-x86_64-normal-server-release/vs-env/set-vs-env.sh:
> > line 2: `VS_INCLUDE="C:\Program Files (x86)\Microsoft Visual Studio
> > 10.0\VC\INCLUDE;C:\Program Files (x86)\Microsoft Visual Studio
> > 10.0\VC\ATLMFC\INCLUDE;C:\Program Files (x86)\Microsoft
> > SDKs\Windows\v7.0A\include; "'
> > configure exiting with result code 2
> >
> > Looks like a typical shell expansion bug but it's only recently cropped
> up.
> >
> >
> >
> >
> [C:\Users\jenkins\workspace\build-scripts\jobs\jdk8u\jdk8u-windows-x64-hotspot]
> > Running shell script
> > + ./build-farm/make-adopt-build-farm.sh
> > BUILD TYPE:
> > VERSION: jdk8u
> > ARCHITECTURE x64
> > VARIANT: hotspot
> > OS: windows
> > Detecting boot jdk for: jdk8u
> > Found build version: 8
> > Boot jdk version: 7
> > Boot jdk: /cygdrive/c/openjdk/jdk7
> > Filename will be: OpenJDK8U_x64_windows_hotspot_2018-09-14-10-51.zip
> > Starting
> >
> /cygdrive/c/Users/jenkins/workspace/build-scripts/jobs/jdk8u/jdk8u-windows-x64-hotspot/build-farm/../makejdk-any-platform.sh
> > to configure, build (Adopt)OpenJDK binary
> > Working dir is ./build/
> > #
> > # OPENJDK BUILD CONFIGURATION:
> > #
> > BUILD_CONFIG[BRANCH]="dev"
> >
> BUILD_CONFIG[BUILD_FULL_NAME]="cygwin_nt-6.1-x86_64-normal-server-release"
> > BUILD_CONFIG[BUILD_VARIANT]=""
> > BUILD_CONFIG[CLEAN_DOCKER_BUILD]="false"
> > BUILD_CONFIG[CLEAN_GIT_REPO]="true"
> > BUILD_CONFIG[CONFIGURE_ARGS_FOR_ANY_PLATFORM]=""
> > BUILD_CONFIG[CONTAINER_NAME]="openjdk_container"
> > BUILD_CONFIG[COPY_MACOSX_FREE_FONT_LIB_FOR_JDK_FLAG]="false"
> > BUILD_CONFIG[COPY_MACOSX_FREE_FONT_LIB_FOR_JRE_FLAG]="false"
> > BUILD_CONFIG[DOCKER]="docker"
> > BUILD_CONFIG[DOCKER_FILE_PATH]=""
> > BUILD_CONFIG[DOCKER_SOURCE_VOLUME_NAME]="openjdk-source-volume"
> > BUILD_CONFIG[FREETYPE]="true"
> > BUILD_CONFIG[FREETYPE_DIRECTORY]=""
> > BUILD_CONFIG[FREETYPE_FONT_BUILD_TYPE_PARAM]=""
> > BUILD_CONFIG[FREETYPE_FONT_VERSION]="2.4.0"
> > BUILD_CONFIG[JDK_BOOT_DIR]="/cygdrive/c/openjdk/jdk7"
> > BUILD_CONFIG[JDK_PATH]="j2sdk-image"
> > BUILD_CONFIG[JRE_PATH]="j2re-image"
> > BUILD_CONFIG[JVM_VARIANT]="server"
> > BUILD_CONFIG[KEEP_CONTAINER]="false"
> > BUILD_CONFIG[MAKE_ARGS_FOR_ANY_PLATFORM]=""
> > BUILD_CONFIG[MAKE_COMMAND_NAME]="make"
> > BUILD_CONFIG[NUM_PROCESSORS]="1"
> > BUILD_CONFIG[OPENJDK_BUILD_NUMBER]=""
> > BUILD_CONFIG[OPENJDK_CORE_VERSION]="jdk8"
> > BUILD_CONFIG[OPENJDK_FOREST_NAME]="jdk8u"
> > BUILD_CONFIG[OPENJDK_SOURCE_DIR]="src"
> > BUILD_CONFIG[OPENJDK_UPDATE_VERSION]=""
> > BUILD_CONFIG[OS_ARCHITECTURE]="x86_64"
> > BUILD_CONFIG[OS_KERNEL_NAME]="cygwin_nt-6.1"
> > BUILD_CONFIG[REPOSITORY]="adoptopenjdk/openjdk-jdk8u"
> > BUILD_CONFIG[REUSE_CONTAINER]="true"
> > BUILD_CONFIG[SHALLOW_CLONE_OPTION]="--depth=1"
> > BUILD_CONFIG[SIGN]="false"
> > BUILD_CONFIG[TAG]=""
> > BUILD_CONFIG[TARGET_DIR]="target/"
> >
> BUILD_CONFIG[TARGET_FILE_NAME]="OpenJDK8U_x64_windows_hotspot_2018-09-14-10-51.zip"
> > BUILD_CONFIG[TMP_CONTAINER_NAME]="openjdk-copy-src"
> > BUILD_CONFIG[TMP_SPACE_BUILD]="true"
> > BUILD_CONFIG[USER_SUPPLIED_CONFIGURE_ARGS]="
> > --with-freetype-include=/cygdrive/c/openjdk/freetype/include
> > --with-freetype-lib=/cygdrive/c/openjdk/freetype/lib64 --disable-ccache"
> > BUILD_CONFIG[USE_DOCKER]="false"
> > BUILD_CONFIG[USE_SSH]="false"
> > BUILD_CONFIG[WORKING_DIR]="./build/"
> >
> BUILD_CONFIG[WORKSPACE_DIR]="/cygdrive/c/Users/jenkins/workspace/build-scripts/jobs/jdk8u/jdk8u-windows-x64-hotspot/workspace"
> > JDK Image folder name: j2sdk-image
> > JRE Image folder name: j2re-image
> > [debug] COPY_MACOSX_FREE_FONT_LIB_FOR_JDK_FLAG=false
> > [debug] COPY_MACOSX_FREE_FONT_LIB_FOR_JRE_FLAG=false
> >
> >
> >
> > OpenJDK repo tag is jdk8u181-b13
> > Version: 181 13
> > Completed configuring the version string parameter, config args are now:
> > --with-milestone=adoptopenjdk --with-build-number=13
> > Overriding JDK_BOOT_DIR, set to /cygdrive/c/openjdk/jdk7
> >
