Re: JDK Build Broken since "8242524: Use different default CDS archives depending on UseCompressOops"
Dear Magnus, sure. But for whatever reason the patch does not work for me. Can you please send me the full file? Sry, -marc > On 15. May 2020, at 13:58, Magnus Ihse Bursie > wrote: > > In theory, this patch should work, but I cannot verify it. Marc, can you try > it out? > > diff --git a/make/Images.gmk b/make/Images.gmk > --- a/make/Images.gmk > +++ b/make/Images.gmk > @@ -147,31 +147,33 @@ > >JRE_TARGETS += $(gen_cds_archive_jre) > > - $(eval $(call SetupExecute, gen_cds_nocoops_archive_jdk, \ > - WARN := Creating CDS-NOCOOPS archive for jdk image, \ > - DEPS := $(jlink_jdk), \ > - OUTPUT_FILE := $(JDK_IMAGE_DIR)/$(CDS_NOCOOPS_ARCHIVE), \ > - SUPPORT_DIR := $(SUPPORT_OUTPUTDIR)/images/jdk, \ > - COMMAND := $(FIXPATH) $(JDK_IMAGE_DIR)/bin/java -Xshare:dump \ > - -XX:SharedArchiveFile=$(JDK_IMAGE_DIR)/$(CDS_NOCOOPS_ARCHIVE) \ > - -XX:-UseCompressedOops \ > - -Xmx128M -Xms128M $(LOG_INFO), \ > - )) > + ifeq ($(call isTargetCpuBits, 64), true) > +$(eval $(call SetupExecute, gen_cds_nocoops_archive_jdk, \ > +WARN := Creating CDS-NOCOOPS archive for jdk image, \ > +DEPS := $(jlink_jdk), \ > +OUTPUT_FILE := $(JDK_IMAGE_DIR)/$(CDS_NOCOOPS_ARCHIVE), \ > +SUPPORT_DIR := $(SUPPORT_OUTPUTDIR)/images/jdk, \ > +COMMAND := $(FIXPATH) $(JDK_IMAGE_DIR)/bin/java -Xshare:dump \ > + -XX:SharedArchiveFile=$(JDK_IMAGE_DIR)/$(CDS_NOCOOPS_ARCHIVE) \ > +-XX:-UseCompressedOops \ > +-Xmx128M -Xms128M $(LOG_INFO), \ > +)) > > - JDK_TARGETS += $(gen_cds_nocoops_archive_jdk) > +JDK_TARGETS += $(gen_cds_nocoops_archive_jdk) > > - $(eval $(call SetupExecute, gen_cds_nocoops_archive_jre, \ > - WARN := Creating CDS-NOCOOPS archive for jre image, \ > - DEPS := $(jlink_jre), \ > - OUTPUT_FILE := $(JRE_IMAGE_DIR)/$(CDS_NOCOOPS_ARCHIVE), \ > - SUPPORT_DIR := $(SUPPORT_OUTPUTDIR)/images/jre, \ > - COMMAND := $(FIXPATH) $(JRE_IMAGE_DIR)/bin/java -Xshare:dump \ > - -XX:SharedArchiveFile=$(JRE_IMAGE_DIR)/$(CDS_NOCOOPS_ARCHIVE) \ > - -XX:-UseCompressedOops \ > - -Xmx128M -Xms128M $(LOG_INFO), \ > - )) > +$(eval $(call SetupExecute, gen_cds_nocoops_archive_jre, \ > +WARN := Creating CDS-NOCOOPS archive for jre image, \ > +DEPS := $(jlink_jre), \ > +OUTPUT_FILE := $(JRE_IMAGE_DIR)/$(CDS_NOCOOPS_ARCHIVE), \ > +SUPPORT_DIR := $(SUPPORT_OUTPUTDIR)/images/jre, \ > +COMMAND := $(FIXPATH) $(JRE_IMAGE_DIR)/bin/java -Xshare:dump \ > + -XX:SharedArchiveFile=$(JRE_IMAGE_DIR)/$(CDS_NOCOOPS_ARCHIVE) \ > +-XX:-UseCompressedOops \ > +-Xmx128M -Xms128M $(LOG_INFO), \ > +)) > > - JRE_TARGETS += $(gen_cds_nocoops_archive_jre) > +JRE_TARGETS += $(gen_cds_nocoops_archive_jre) > + endif > endif > > > > > /Magnus > > On 2020-05-15 08:18, David Holmes wrote: >> https://bugs.openjdk.java.net/browse/JDK-8245070 >> >> David >> >> On 15/05/2020 4:10 pm, David Holmes wrote: >>> Hi Marc, >>> >>> I will file a bug for this. Thanks for the report. >>> >>> David >>> >>> On 15/05/2020 4:04 pm, Marc Hoffmann wrote: Dear Rory, dear all, JaCoCo project here. It looks like that OpenJDK build for jdk main dev branch (Java 15) is broken for us on ARM32 since commit changeset 59296:e25b21095e86 8242524: Use different default CDS archives depending on UseCompressOops Reviewed-by: erikj, iklam, ccheung The logged error is: === Output from failing command(s) repeated here === * For target support_images_jdk__gen_cds_nocoops_archive_jdk_exec: Unrecognized VM option 'UseCompressedOops' Did you mean '(+/-)CheckCompressedOops'? Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. Best regards, -marc >
Re: RFR: JDK-8245096 Better windows environment output in configure
Looks good. Nice change. /Erik On 2020-05-15 04:13, Magnus Ihse Bursie wrote: Unify and clean up windows environment output in configure Bug: https://bugs.openjdk.java.net/browse/JDK-8245096 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8245096-better-windows-version/webrev.01 /Magnus
Re: JDK Build Broken since "8242524: Use different default CDS archives depending on UseCompressOops"
In theory, this patch should work, but I cannot verify it. Marc, can you try it out? diff --git a/make/Images.gmk b/make/Images.gmk --- a/make/Images.gmk +++ b/make/Images.gmk @@ -147,31 +147,33 @@ JRE_TARGETS += $(gen_cds_archive_jre) - $(eval $(call SetupExecute, gen_cds_nocoops_archive_jdk, \ - WARN := Creating CDS-NOCOOPS archive for jdk image, \ - DEPS := $(jlink_jdk), \ - OUTPUT_FILE := $(JDK_IMAGE_DIR)/$(CDS_NOCOOPS_ARCHIVE), \ - SUPPORT_DIR := $(SUPPORT_OUTPUTDIR)/images/jdk, \ - COMMAND := $(FIXPATH) $(JDK_IMAGE_DIR)/bin/java -Xshare:dump \ - -XX:SharedArchiveFile=$(JDK_IMAGE_DIR)/$(CDS_NOCOOPS_ARCHIVE) \ - -XX:-UseCompressedOops \ - -Xmx128M -Xms128M $(LOG_INFO), \ - )) + ifeq ($(call isTargetCpuBits, 64), true) + $(eval $(call SetupExecute, gen_cds_nocoops_archive_jdk, \ + WARN := Creating CDS-NOCOOPS archive for jdk image, \ + DEPS := $(jlink_jdk), \ + OUTPUT_FILE := $(JDK_IMAGE_DIR)/$(CDS_NOCOOPS_ARCHIVE), \ + SUPPORT_DIR := $(SUPPORT_OUTPUTDIR)/images/jdk, \ + COMMAND := $(FIXPATH) $(JDK_IMAGE_DIR)/bin/java -Xshare:dump \ + -XX:SharedArchiveFile=$(JDK_IMAGE_DIR)/$(CDS_NOCOOPS_ARCHIVE) \ + -XX:-UseCompressedOops \ + -Xmx128M -Xms128M $(LOG_INFO), \ + )) - JDK_TARGETS += $(gen_cds_nocoops_archive_jdk) + JDK_TARGETS += $(gen_cds_nocoops_archive_jdk) - $(eval $(call SetupExecute, gen_cds_nocoops_archive_jre, \ - WARN := Creating CDS-NOCOOPS archive for jre image, \ - DEPS := $(jlink_jre), \ - OUTPUT_FILE := $(JRE_IMAGE_DIR)/$(CDS_NOCOOPS_ARCHIVE), \ - SUPPORT_DIR := $(SUPPORT_OUTPUTDIR)/images/jre, \ - COMMAND := $(FIXPATH) $(JRE_IMAGE_DIR)/bin/java -Xshare:dump \ - -XX:SharedArchiveFile=$(JRE_IMAGE_DIR)/$(CDS_NOCOOPS_ARCHIVE) \ - -XX:-UseCompressedOops \ - -Xmx128M -Xms128M $(LOG_INFO), \ - )) + $(eval $(call SetupExecute, gen_cds_nocoops_archive_jre, \ + WARN := Creating CDS-NOCOOPS archive for jre image, \ + DEPS := $(jlink_jre), \ + OUTPUT_FILE := $(JRE_IMAGE_DIR)/$(CDS_NOCOOPS_ARCHIVE), \ + SUPPORT_DIR := $(SUPPORT_OUTPUTDIR)/images/jre, \ + COMMAND := $(FIXPATH) $(JRE_IMAGE_DIR)/bin/java -Xshare:dump \ + -XX:SharedArchiveFile=$(JRE_IMAGE_DIR)/$(CDS_NOCOOPS_ARCHIVE) \ + -XX:-UseCompressedOops \ + -Xmx128M -Xms128M $(LOG_INFO), \ + )) - JRE_TARGETS += $(gen_cds_nocoops_archive_jre) + JRE_TARGETS += $(gen_cds_nocoops_archive_jre) + endif endif /Magnus On 2020-05-15 08:18, David Holmes wrote: https://bugs.openjdk.java.net/browse/JDK-8245070 David On 15/05/2020 4:10 pm, David Holmes wrote: Hi Marc, I will file a bug for this. Thanks for the report. David On 15/05/2020 4:04 pm, Marc Hoffmann wrote: Dear Rory, dear all, JaCoCo project here. It looks like that OpenJDK build for jdk main dev branch (Java 15) is broken for us on ARM32 since commit changeset 59296:e25b21095e86 8242524: Use different default CDS archives depending on UseCompressOops Reviewed-by: erikj, iklam, ccheung The logged error is: === Output from failing command(s) repeated here === * For target support_images_jdk__gen_cds_nocoops_archive_jdk_exec: Unrecognized VM option 'UseCompressedOops' Did you mean '(+/-)CheckCompressedOops'? Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. Best regards, -marc
RFR: JDK-8245096 Better windows environment output in configure
Unify and clean up windows environment output in configure Bug: https://bugs.openjdk.java.net/browse/JDK-8245096 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8245096-better-windows-version/webrev.01 /Magnus
RFR: JDK-8245093 WSL support broke cygwin toolchain detection
Unfortunately, the fixes for WSL changed the behavior so the autodetection of toolchain does not work on cygwin (but providing devkit does work, that's why I did not discover this). Windows and unix emulation environments are really a whack-a-mole... :( Bug: https://bugs.openjdk.java.net/browse/JDK-8245093 Patch inline: diff --git a/make/autoconf/basic_tools.m4 b/make/autoconf/basic_tools.m4 --- a/make/autoconf/basic_tools.m4 +++ b/make/autoconf/basic_tools.m4 @@ -97,7 +97,7 @@ UTIL_PATH_PROGS(NICE, nice) UTIL_PATH_PROGS(LSB_RELEASE, lsb_release) - UTIL_PATH_PROGS(CMD, cmd.exe, /mnt/c/Windows/System32) + UTIL_PATH_PROGS(CMD, cmd.exe, $PATH /cygdrive/c/Windows/System32 /mnt/c/Windows/System32) ]) ### /Magnus
Re: RFR: JDK-8245093 WSL support broke cygwin toolchain detection
Looks good. /Erik On 2020-05-15 04:39, Magnus Ihse Bursie wrote: Unfortunately, the fixes for WSL changed the behavior so the autodetection of toolchain does not work on cygwin (but providing devkit does work, that's why I did not discover this). Windows and unix emulation environments are really a whack-a-mole... :( Bug: https://bugs.openjdk.java.net/browse/JDK-8245093 Patch inline: diff --git a/make/autoconf/basic_tools.m4 b/make/autoconf/basic_tools.m4 --- a/make/autoconf/basic_tools.m4 +++ b/make/autoconf/basic_tools.m4 @@ -97,7 +97,7 @@ UTIL_PATH_PROGS(NICE, nice) UTIL_PATH_PROGS(LSB_RELEASE, lsb_release) - UTIL_PATH_PROGS(CMD, cmd.exe, /mnt/c/Windows/System32) + UTIL_PATH_PROGS(CMD, cmd.exe, $PATH /cygdrive/c/Windows/System32 /mnt/c/Windows/System32) ]) ### /Magnus
RFR: JDK-8245119 Fix include path for hotspot-ide-project
Unfortunately JDK-8245046 was not enough to be able to produce the Hotspot VS project file. With this patch, the generation has been tested and verified by one of our Windows developers. Bug: https://bugs.openjdk.java.net/browse/JDK-8245119 Patch inline: diff --git a/make/Main.gmk b/make/Main.gmk --- a/make/Main.gmk +++ b/make/Main.gmk @@ -263,6 +263,7 @@ $(eval $(call SetupTarget, hotspot-ide-project, \ MAKEFILE := hotspot/ide/CreateVSProject, \ DEPS := hotspot exploded-image, \ + ARGS := -I$(TOPDIR)/make/hotspot, \ )) ALL_TARGETS += $(HOTSPOT_VARIANT_TARGETS) $(HOTSPOT_VARIANT_GENSRC_TARGETS) \ /Magnus
Re: Mac OS X 32bit x86 build fails for jdk12u
I think you are right. I don't remember even JDK 7 having a 32 bit version. There may have been some unused partial support to create one, but we never shipped such a thing - nor were there internal 32 bit builds. Also macOS 10.15 doesn't support 32 bit applications. So when 10.14 goes EOSL in about 17 months from now, it'll be history. -phil On 5/15/20, 9:12 AM, Magnus Ihse Bursie wrote: On 2020-05-15 17:33, Erik Joelsson wrote: Hello Andre, As far as I'm aware, support for 32 bit on Macosx has not been supported by anyone for a very long time. I would assume it far from trivial to get it to work. In fact, I wonder if there *ever* have been 32-bit macOS support in OpenJDK. I believe we only inherited a 64-bit port from Apple. /Magnus /Erik On 2020-05-14 17:17, Andre Kovacs wrote: Dear members, For compatibility reasons with older 32bit i386 architecture dylibs via JNI, I'm trying to build a 32bit version of jdk12u on Mac OS X. I'm using the following configure command: "bash configure --with-boot-jdk=/Library/Java/JavaVirtualMachines/openjdk12/Contents/Home --with-target-bits=32" But I'm getting the following build errors when I try to build macosx-x86-client-release and macosx-x86-server-release: "ERROR: Build failed for target 'default (exploded-image)' in configuration 'macosx-x86-client-release' (exit code 2) === Output from failing command(s) repeated here === * For target hotspot_variant-client_libjvm_objs_abstractInterpreter.o: In file included from /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/share/interpreter/abstractInterpreter.cpp:33: In file included from /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/share/interpreter/interp_masm.hpp:31: /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/cpu/x86/interp_masm_x86.hpp:171:5: error: call to member function 'movptr' is ambiguous movptr(Address(rbp, frame::interpreter_frame_last_sp_offset * wordSize), (int32_t)NULL_WORD); ^~ /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/cpu/x86/macroAssembler_x86.hpp:1554:8: note: candidate function void movptr(Address dst, intptr_t src); ^ /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/cpu/x86/macroAssembler_x86.hpp:1556:8: note: candidate function void movptr(Address dst, Register src); ^ /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/cpu/x86/macroAssembler_x86.hpp:1540:8: note: candidate function not viable: no known conversion from 'Address' to 'ArrayAddress' for 1st argument ... (rest of output omitted) * All command lines available in /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/build/macosx-x86-client-release/make-support/failure-logs. === End of repeated output ===" Thank you in advance for your time. Regards, Andre
RFR(XS): 8245070: 32-bit builds are broken after JDK-8242524
Hi, Please review the xsmall change for bug: 8245070: https://bugs.openjdk.java.net/browse/JDK-8245070 webrev: http://cr.openjdk.java.net/~minqi/2020/8245070/webrev-00/ The change of 8245070 broke build for 32 bits, since no compressed oops on 32 bits. Guard the change for 64 bits only. I could not build 32 bits --- have no 32 bit platform to make sure of the change, so please give a detail look. The variable OPENJDK_TARGET_CPU_BITS is copied from other file. Thanks Yumin
Re: Mac OS X 32bit x86 build fails for jdk12u
Dear all, Thank you very much for your comments. I would like to be able to upgrade from my outdated Java 7u91 (x86 32-bit) to at least Java 12, but I have some device driver libraries that are x86 32-bit only and I can not instantiate them anymore via JNI with the x86 64-bit version. Regards, Andre Em sex., 15 de mai. de 2020 às 13:23, Philip Race escreveu: > I think you are right. I don't remember even JDK 7 having a 32 bit version. > There may have been some unused partial support to create one, but we > never shipped such a thing - nor were there internal 32 bit builds. > > Also macOS 10.15 doesn't support 32 bit applications. > So when 10.14 goes EOSL in about 17 months from now, it'll be history. > > -phil > > On 5/15/20, 9:12 AM, Magnus Ihse Bursie wrote: > > On 2020-05-15 17:33, Erik Joelsson wrote: > >> Hello Andre, > >> > >> As far as I'm aware, support for 32 bit on Macosx has not been > >> supported by anyone for a very long time. I would assume it far from > >> trivial to get it to work. > > In fact, I wonder if there *ever* have been 32-bit macOS support in > > OpenJDK. I believe we only inherited a 64-bit port from Apple. > > > > /Magnus > >> > >> /Erik > >> > >> On 2020-05-14 17:17, Andre Kovacs wrote: > >>> Dear members, > >>> > >>> For compatibility reasons with older 32bit i386 architecture dylibs via > >>> JNI, I'm trying to build a 32bit version of jdk12u on Mac OS X. > >>> > >>> I'm using the following configure command: > >>> "bash configure > >>> > --with-boot-jdk=/Library/Java/JavaVirtualMachines/openjdk12/Contents/Home > >>> > >>> --with-target-bits=32" > >>> > >>> But I'm getting the following build errors when I try to build > >>> macosx-x86-client-release and macosx-x86-server-release: > >>> "ERROR: Build failed for target 'default (exploded-image)' in > >>> configuration > >>> 'macosx-x86-client-release' (exit code 2) > >>> > >>> === Output from failing command(s) repeated here === > >>> * For target hotspot_variant-client_libjvm_objs_abstractInterpreter.o: > >>> In file included from > >>> > /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/share/interpreter/abstractInterpreter.cpp:33: > > >>> > >>> In file included from > >>> > /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/share/interpreter/interp_masm.hpp:31: > > >>> > >>> > /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/cpu/x86/interp_masm_x86.hpp:171:5: > > >>> > >>> error: call to member function 'movptr' is ambiguous > >>> movptr(Address(rbp, frame::interpreter_frame_last_sp_offset * > >>> wordSize), (int32_t)NULL_WORD); > >>> ^~ > >>> > /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/cpu/x86/macroAssembler_x86.hpp:1554:8: > > >>> > >>> note: candidate function > >>>void movptr(Address dst, intptr_t src); > >>> ^ > >>> > /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/cpu/x86/macroAssembler_x86.hpp:1556:8: > > >>> > >>> note: candidate function > >>>void movptr(Address dst, Register src); > >>> ^ > >>> > /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/cpu/x86/macroAssembler_x86.hpp:1540:8: > > >>> > >>> note: candidate function not viable: no known conversion from > >>> 'Address' to > >>> 'ArrayAddress' for 1st argument > >>> ... (rest of output omitted) > >>> > >>> * All command lines available in > >>> > /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/build/macosx-x86-client-release/make-support/failure-logs. > > >>> > >>> === End of repeated output ===" > >>> > >>> Thank you in advance for your time. > >>> > >>> Regards, > >>> Andre > > >
Mac OS X 32bit x86 build fails for jdk12u
Dear members, For compatibility reasons with older 32bit i386 architecture dylibs via JNI, I'm trying to build a 32bit version of jdk12u on Mac OS X. I'm using the following configure command: "bash configure --with-boot-jdk=/Library/Java/JavaVirtualMachines/openjdk12/Contents/Home --with-target-bits=32" But I'm getting the following build errors when I try to build macosx-x86-client-release and macosx-x86-server-release: "ERROR: Build failed for target 'default (exploded-image)' in configuration 'macosx-x86-client-release' (exit code 2) === Output from failing command(s) repeated here === * For target hotspot_variant-client_libjvm_objs_abstractInterpreter.o: In file included from /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/share/interpreter/abstractInterpreter.cpp:33: In file included from /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/share/interpreter/interp_masm.hpp:31: /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/cpu/x86/interp_masm_x86.hpp:171:5: error: call to member function 'movptr' is ambiguous movptr(Address(rbp, frame::interpreter_frame_last_sp_offset * wordSize), (int32_t)NULL_WORD); ^~ /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/cpu/x86/macroAssembler_x86.hpp:1554:8: note: candidate function void movptr(Address dst, intptr_t src); ^ /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/cpu/x86/macroAssembler_x86.hpp:1556:8: note: candidate function void movptr(Address dst, Register src); ^ /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/cpu/x86/macroAssembler_x86.hpp:1540:8: note: candidate function not viable: no known conversion from 'Address' to 'ArrayAddress' for 1st argument ... (rest of output omitted) * All command lines available in /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/build/macosx-x86-client-release/make-support/failure-logs. === End of repeated output ===" Thank you in advance for your time. Regards, Andre
Re: Mac OS X 32bit x86 build fails for jdk12u
Hello Andre, As far as I'm aware, support for 32 bit on Macosx has not been supported by anyone for a very long time. I would assume it far from trivial to get it to work. /Erik On 2020-05-14 17:17, Andre Kovacs wrote: Dear members, For compatibility reasons with older 32bit i386 architecture dylibs via JNI, I'm trying to build a 32bit version of jdk12u on Mac OS X. I'm using the following configure command: "bash configure --with-boot-jdk=/Library/Java/JavaVirtualMachines/openjdk12/Contents/Home --with-target-bits=32" But I'm getting the following build errors when I try to build macosx-x86-client-release and macosx-x86-server-release: "ERROR: Build failed for target 'default (exploded-image)' in configuration 'macosx-x86-client-release' (exit code 2) === Output from failing command(s) repeated here === * For target hotspot_variant-client_libjvm_objs_abstractInterpreter.o: In file included from /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/share/interpreter/abstractInterpreter.cpp:33: In file included from /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/share/interpreter/interp_masm.hpp:31: /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/cpu/x86/interp_masm_x86.hpp:171:5: error: call to member function 'movptr' is ambiguous movptr(Address(rbp, frame::interpreter_frame_last_sp_offset * wordSize), (int32_t)NULL_WORD); ^~ /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/cpu/x86/macroAssembler_x86.hpp:1554:8: note: candidate function void movptr(Address dst, intptr_t src); ^ /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/cpu/x86/macroAssembler_x86.hpp:1556:8: note: candidate function void movptr(Address dst, Register src); ^ /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/cpu/x86/macroAssembler_x86.hpp:1540:8: note: candidate function not viable: no known conversion from 'Address' to 'ArrayAddress' for 1st argument ... (rest of output omitted) * All command lines available in /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/build/macosx-x86-client-release/make-support/failure-logs. === End of repeated output ===" Thank you in advance for your time. Regards, Andre
Re: RFR: JDK-8245119 Fix include path for hotspot-ide-project
Looks good. /Erik On 2020-05-15 09:24, Magnus Ihse Bursie wrote: Unfortunately JDK-8245046 was not enough to be able to produce the Hotspot VS project file. With this patch, the generation has been tested and verified by one of our Windows developers. Bug: https://bugs.openjdk.java.net/browse/JDK-8245119 Patch inline: diff --git a/make/Main.gmk b/make/Main.gmk --- a/make/Main.gmk +++ b/make/Main.gmk @@ -263,6 +263,7 @@ $(eval $(call SetupTarget, hotspot-ide-project, \ MAKEFILE := hotspot/ide/CreateVSProject, \ DEPS := hotspot exploded-image, \ + ARGS := -I$(TOPDIR)/make/hotspot, \ )) ALL_TARGETS += $(HOTSPOT_VARIANT_TARGETS) $(HOTSPOT_VARIANT_GENSRC_TARGETS) \ /Magnus
Re: RFR(XS): 8245070: 32-bit builds are broken after JDK-8242524
On 2020-05-15 19:49, Yumin Qi wrote: Hi, Please review the xsmall change for bug: 8245070: https://bugs.openjdk.java.net/browse/JDK-8245070 webrev: http://cr.openjdk.java.net/~minqi/2020/8245070/webrev-00/ The change of 8245070 broke build for 32 bits, since no compressed oops on 32 bits. Guard the change for 64 bits only. I could not build 32 bits --- have no 32 bit platform to make sure of the change, so please give a detail look. The variable OPENJDK_TARGET_CPU_BITS is copied from other file. Hi Yumin, I have already suggested a patch along these line in https://mail.openjdk.java.net/pipermail/build-dev/2020-May/027469.html. I am still awaiting confirmation from Marc that it solves his problem. Regarding your patch, the contemporary style of checking target bits is "ifeq ($(call isTargetCpuBits, 64), true))", rather than "ifeq ($(OPENJDK_TARGET_CPU_BITS), 64)". /Magnus Thanks Yumin
RFR: JDK-8240228 "make hotspot-ide-project" on Windows creates a Visual Studio project with empty preprocessor defines
After JDK-8239450 (Overhaul JVM feature handling in configure), the Hotspot Visual Studio project creator did not properly pick up compiler defines. This turned out to be due to it hard-coding JVM_VARIANT to client (which is most often not built), and thus it got not JVM features for client, since none were defined. I changed this hack to a slightly better, which uses server instead. (While technically we can build without server, it's not a likely configuration, and users of the IDE target just needs to be aware of this.) Bug: https://bugs.openjdk.java.net/browse/JDK-8240228 Patch inline: diff --git a/make/hotspot/ide/CreateVSProject.gmk b/make/hotspot/ide/CreateVSProject.gmk --- a/make/hotspot/ide/CreateVSProject.gmk +++ b/make/hotspot/ide/CreateVSProject.gmk @@ -35,8 +35,8 @@ # The next part is a bit hacky. We include the CompileJvm.gmk to be # able to extact flags, but we do not wish to execute the rules. - # Use client as base for defines and includes - JVM_VARIANT=client + # Use server as base for defines and includes + JVM_VARIANT=server include HotspotCommon.gmk include lib/CompileJvm.gmk /Magnus
Re: RFR(XS): 8245070: 32-bit builds are broken after JDK-8242524
There is a copy/paste caused mismatch: On 5/15/20 10:49 AM, Yumin Qi wrote: Hi, Please review the xsmall change for bug: 8245070: https://bugs.openjdk.java.net/browse/JDK-8245070 webrev: http://cr.openjdk.java.net/~minqi/2020/8245070/webrev-00/ The change of 8245070 broke build for 32 bits, since no compressed oops on 32 bits. Guard the change for 64 bits only. 8245070 => 8242524. Thanks Yumin I could not build 32 bits --- have no 32 bit platform to make sure of the change, so please give a detail look. The variable OPENJDK_TARGET_CPU_BITS is copied from other file. Thanks Yumin
Re: Mac OS X 32bit x86 build fails for jdk12u
On 2020-05-15 17:33, Erik Joelsson wrote: Hello Andre, As far as I'm aware, support for 32 bit on Macosx has not been supported by anyone for a very long time. I would assume it far from trivial to get it to work. In fact, I wonder if there *ever* have been 32-bit macOS support in OpenJDK. I believe we only inherited a 64-bit port from Apple. /Magnus /Erik On 2020-05-14 17:17, Andre Kovacs wrote: Dear members, For compatibility reasons with older 32bit i386 architecture dylibs via JNI, I'm trying to build a 32bit version of jdk12u on Mac OS X. I'm using the following configure command: "bash configure --with-boot-jdk=/Library/Java/JavaVirtualMachines/openjdk12/Contents/Home --with-target-bits=32" But I'm getting the following build errors when I try to build macosx-x86-client-release and macosx-x86-server-release: "ERROR: Build failed for target 'default (exploded-image)' in configuration 'macosx-x86-client-release' (exit code 2) === Output from failing command(s) repeated here === * For target hotspot_variant-client_libjvm_objs_abstractInterpreter.o: In file included from /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/share/interpreter/abstractInterpreter.cpp:33: In file included from /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/share/interpreter/interp_masm.hpp:31: /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/cpu/x86/interp_masm_x86.hpp:171:5: error: call to member function 'movptr' is ambiguous movptr(Address(rbp, frame::interpreter_frame_last_sp_offset * wordSize), (int32_t)NULL_WORD); ^~ /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/cpu/x86/macroAssembler_x86.hpp:1554:8: note: candidate function void movptr(Address dst, intptr_t src); ^ /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/cpu/x86/macroAssembler_x86.hpp:1556:8: note: candidate function void movptr(Address dst, Register src); ^ /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/cpu/x86/macroAssembler_x86.hpp:1540:8: note: candidate function not viable: no known conversion from 'Address' to 'ArrayAddress' for 1st argument ... (rest of output omitted) * All command lines available in /Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/build/macosx-x86-client-release/make-support/failure-logs. === End of repeated output ===" Thank you in advance for your time. Regards, Andre
Re: JDK Build Broken since "8242524: Use different default CDS archives depending on UseCompressOops"
Hi Magnus, I can confirm that this version of the file successfully builds on ARM32 (can’t speak for other platforms): https://pici.beachhub.io/#/jdk-marchof/20200515-213321 Thanks for the quick fix! -marc > On 15. May 2020, at 17:05, Magnus Ihse Bursie > wrote: > > Here it is. > > /Magnus > > On 2020-05-15 15:19, Marc Hoffmann wrote: >> Dear Magnus, >> >> sure. But for whatever reason the patch does not work for me. >> >> Can you please send me the full file? >> >> Sry, >> -marc >> >>> On 15. May 2020, at 13:58, Magnus Ihse Bursie >>> wrote: >>> >>> In theory, this patch should work, but I cannot verify it. Marc, can you >>> try it out? >>> >>> diff --git a/make/Images.gmk b/make/Images.gmk >>> --- a/make/Images.gmk >>> +++ b/make/Images.gmk >>> @@ -147,31 +147,33 @@ >>> >>>JRE_TARGETS += $(gen_cds_archive_jre) >>> >>> - $(eval $(call SetupExecute, gen_cds_nocoops_archive_jdk, \ >>> - WARN := Creating CDS-NOCOOPS archive for jdk image, \ >>> - DEPS := $(jlink_jdk), \ >>> - OUTPUT_FILE := $(JDK_IMAGE_DIR)/$(CDS_NOCOOPS_ARCHIVE), \ >>> - SUPPORT_DIR := $(SUPPORT_OUTPUTDIR)/images/jdk, \ >>> - COMMAND := $(FIXPATH) $(JDK_IMAGE_DIR)/bin/java -Xshare:dump \ >>> - -XX:SharedArchiveFile=$(JDK_IMAGE_DIR)/$(CDS_NOCOOPS_ARCHIVE) \ >>> - -XX:-UseCompressedOops \ >>> - -Xmx128M -Xms128M $(LOG_INFO), \ >>> - )) >>> + ifeq ($(call isTargetCpuBits, 64), true) >>> +$(eval $(call SetupExecute, gen_cds_nocoops_archive_jdk, \ >>> +WARN := Creating CDS-NOCOOPS archive for jdk image, \ >>> +DEPS := $(jlink_jdk), \ >>> +OUTPUT_FILE := $(JDK_IMAGE_DIR)/$(CDS_NOCOOPS_ARCHIVE), \ >>> +SUPPORT_DIR := $(SUPPORT_OUTPUTDIR)/images/jdk, \ >>> +COMMAND := $(FIXPATH) $(JDK_IMAGE_DIR)/bin/java -Xshare:dump \ >>> + -XX:SharedArchiveFile=$(JDK_IMAGE_DIR)/$(CDS_NOCOOPS_ARCHIVE) \ >>> +-XX:-UseCompressedOops \ >>> +-Xmx128M -Xms128M $(LOG_INFO), \ >>> +)) >>> >>> - JDK_TARGETS += $(gen_cds_nocoops_archive_jdk) >>> +JDK_TARGETS += $(gen_cds_nocoops_archive_jdk) >>> >>> - $(eval $(call SetupExecute, gen_cds_nocoops_archive_jre, \ >>> - WARN := Creating CDS-NOCOOPS archive for jre image, \ >>> - DEPS := $(jlink_jre), \ >>> - OUTPUT_FILE := $(JRE_IMAGE_DIR)/$(CDS_NOCOOPS_ARCHIVE), \ >>> - SUPPORT_DIR := $(SUPPORT_OUTPUTDIR)/images/jre, \ >>> - COMMAND := $(FIXPATH) $(JRE_IMAGE_DIR)/bin/java -Xshare:dump \ >>> - -XX:SharedArchiveFile=$(JRE_IMAGE_DIR)/$(CDS_NOCOOPS_ARCHIVE) \ >>> - -XX:-UseCompressedOops \ >>> - -Xmx128M -Xms128M $(LOG_INFO), \ >>> - )) >>> +$(eval $(call SetupExecute, gen_cds_nocoops_archive_jre, \ >>> +WARN := Creating CDS-NOCOOPS archive for jre image, \ >>> +DEPS := $(jlink_jre), \ >>> +OUTPUT_FILE := $(JRE_IMAGE_DIR)/$(CDS_NOCOOPS_ARCHIVE), \ >>> +SUPPORT_DIR := $(SUPPORT_OUTPUTDIR)/images/jre, \ >>> +COMMAND := $(FIXPATH) $(JRE_IMAGE_DIR)/bin/java -Xshare:dump \ >>> + -XX:SharedArchiveFile=$(JRE_IMAGE_DIR)/$(CDS_NOCOOPS_ARCHIVE) \ >>> +-XX:-UseCompressedOops \ >>> +-Xmx128M -Xms128M $(LOG_INFO), \ >>> +)) >>> >>> - JRE_TARGETS += $(gen_cds_nocoops_archive_jre) >>> +JRE_TARGETS += $(gen_cds_nocoops_archive_jre) >>> + endif >>> endif >>> >>> >>> >>> >>> /Magnus >>> >>> On 2020-05-15 08:18, David Holmes wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8245070 >>>> >>>> David >>>> >>>> On 15/05/2020 4:10 pm, David Holmes wrote: >>>>> Hi Marc, >>>>> >>>>> I will file a bug for this. Thanks for the report. >>>>> >>>>> David >>>>> >>>>> On 15/05/2020 4:04 pm, Marc Hoffmann wrote: >>>>>> Dear Rory, dear all, >>>>>> >>>>>> JaCoCo project here. It looks like that OpenJDK build for jdk main dev >>>>>> branch (Java 15) is broken for us on ARM32 since commit >>>>>> >>>>>> changeset 59296:e25b21095e86 >>>>>> >>>>>> 8242524: Use different default CDS archives depending on >>>>>> UseCompressOops >>>>>> Reviewed-by: erikj, iklam, ccheung >>>>>> >>>>>> The logged error is: >>>>>> >>>>>> === Output from failing command(s) repeated here === >>>>>> * For target support_images_jdk__gen_cds_nocoops_archive_jdk_exec: >>>>>> Unrecognized VM option 'UseCompressedOops' >>>>>> Did you mean '(+/-)CheckCompressedOops'? Error: Could not create >>>>>> the Java Virtual Machine. >>>>>> Error: A fatal exception has occurred. Program will exit. >>>>>> >>>>>> >>>>>> Best regards, >>>>>> -marc >>>>>> > >
Re: RFR: JDK-8240228 "make hotspot-ide-project" on Windows creates a Visual Studio project with empty preprocessor defines
Looks good. /Erik On 2020-05-15 11:16, Magnus Ihse Bursie wrote: After JDK-8239450 (Overhaul JVM feature handling in configure), the Hotspot Visual Studio project creator did not properly pick up compiler defines. This turned out to be due to it hard-coding JVM_VARIANT to client (which is most often not built), and thus it got not JVM features for client, since none were defined. I changed this hack to a slightly better, which uses server instead. (While technically we can build without server, it's not a likely configuration, and users of the IDE target just needs to be aware of this.) Bug: https://bugs.openjdk.java.net/browse/JDK-8240228 Patch inline: diff --git a/make/hotspot/ide/CreateVSProject.gmk b/make/hotspot/ide/CreateVSProject.gmk --- a/make/hotspot/ide/CreateVSProject.gmk +++ b/make/hotspot/ide/CreateVSProject.gmk @@ -35,8 +35,8 @@ # The next part is a bit hacky. We include the CompileJvm.gmk to be # able to extact flags, but we do not wish to execute the rules. - # Use client as base for defines and includes - JVM_VARIANT=client + # Use server as base for defines and includes + JVM_VARIANT=server include HotspotCommon.gmk include lib/CompileJvm.gmk /Magnus
Re: RFR(XS): 8245070: 32-bit builds are broken after JDK-8242524
Magnus, Thanks. Let's wait for the result of your patch. I updated my webrev as your suggestion. Thanks Yumin On 5/15/20 11:19 AM, Magnus Ihse Bursie wrote: On 2020-05-15 19:49, Yumin Qi wrote: Hi, Please review the xsmall change for bug: 8245070: https://bugs.openjdk.java.net/browse/JDK-8245070 webrev: http://cr.openjdk.java.net/~minqi/2020/8245070/webrev-00/ The change of 8245070 broke build for 32 bits, since no compressed oops on 32 bits. Guard the change for 64 bits only. I could not build 32 bits --- have no 32 bit platform to make sure of the change, so please give a detail look. The variable OPENJDK_TARGET_CPU_BITS is copied from other file. Hi Yumin, I have already suggested a patch along these line in https://mail.openjdk.java.net/pipermail/build-dev/2020-May/027469.html. I am still awaiting confirmation from Marc that it solves his problem. Regarding your patch, the contemporary style of checking target bits is "ifeq ($(call isTargetCpuBits, 64), true))", rather than "ifeq ($(OPENJDK_TARGET_CPU_BITS), 64)". /Magnus Thanks Yumin
Re: RFR(XS): 8245070: 32-bit builds are broken after JDK-8242524
I tried a variant of this patch with a 32 bit intel build (server only to get the cds archive generation enabled). It makes the build work as expected. The conditions on line 120 and 125 are unnecessary and just add clutter IMO. Otherwise good. /Erik On 2020-05-15 11:29, Yumin Qi wrote: Magnus, Thanks. Let's wait for the result of your patch. I updated my webrev as your suggestion. Thanks Yumin On 5/15/20 11:19 AM, Magnus Ihse Bursie wrote: On 2020-05-15 19:49, Yumin Qi wrote: Hi, Please review the xsmall change for bug: 8245070: https://bugs.openjdk.java.net/browse/JDK-8245070 webrev: http://cr.openjdk.java.net/~minqi/2020/8245070/webrev-00/ The change of 8245070 broke build for 32 bits, since no compressed oops on 32 bits. Guard the change for 64 bits only. I could not build 32 bits --- have no 32 bit platform to make sure of the change, so please give a detail look. The variable OPENJDK_TARGET_CPU_BITS is copied from other file. Hi Yumin, I have already suggested a patch along these line in https://mail.openjdk.java.net/pipermail/build-dev/2020-May/027469.html. I am still awaiting confirmation from Marc that it solves his problem. Regarding your patch, the contemporary style of checking target bits is "ifeq ($(call isTargetCpuBits, 64), true))", rather than "ifeq ($(OPENJDK_TARGET_CPU_BITS), 64)". /Magnus Thanks Yumin
RFR: JDK-8244966: Add .vscode to .hgignore
Hi, This is my first review request so apologies for any missteps or inconsistencies. JBS: https://bugs.openjdk.java.net/browse/JDK-8244966 Webrev: http://cr.openjdk.java.net/~phh/8244966/webrev.01/ Please review this change that adds the .vscode directory to .hgignore, similar to the .idea directory. This directory is generated by various Visual Studio Code plugins during development. Testing: Local testing done, verified that .vscode/ no longer shows up when running hg status. Thanks, Dan
Re: RFR(XS): 8245070: 32-bit builds are broken after JDK-8242524
Hi, Erik Thanks for test/review. On 5/15/20 1:48 PM, Erik Joelsson wrote: I tried a variant of this patch with a 32 bit intel build (server only to get the cds archive generation enabled). It makes the build work as expected. The conditions on line 120 and 125 are unnecessary and just add clutter IMO. Otherwise good. Just don't want to have not-useful variables defined. I will remove them. Thanks Yumin /Erik On 2020-05-15 11:29, Yumin Qi wrote: Magnus, Thanks. Let's wait for the result of your patch. I updated my webrev as your suggestion. Thanks Yumin On 5/15/20 11:19 AM, Magnus Ihse Bursie wrote: On 2020-05-15 19:49, Yumin Qi wrote: Hi, Please review the xsmall change for bug: 8245070: https://bugs.openjdk.java.net/browse/JDK-8245070 webrev: http://cr.openjdk.java.net/~minqi/2020/8245070/webrev-00/ The change of 8245070 broke build for 32 bits, since no compressed oops on 32 bits. Guard the change for 64 bits only. I could not build 32 bits --- have no 32 bit platform to make sure of the change, so please give a detail look. The variable OPENJDK_TARGET_CPU_BITS is copied from other file. Hi Yumin, I have already suggested a patch along these line in https://mail.openjdk.java.net/pipermail/build-dev/2020-May/027469.html. I am still awaiting confirmation from Marc that it solves his problem. Regarding your patch, the contemporary style of checking target bits is "ifeq ($(call isTargetCpuBits, 64), true))", rather than "ifeq ($(OPENJDK_TARGET_CPU_BITS), 64)". /Magnus Thanks Yumin
Re: JDK Build Broken since "8242524: Use different default CDS archives depending on UseCompressOops"
Hi Marc, I will file a bug for this. Thanks for the report. David On 15/05/2020 4:04 pm, Marc Hoffmann wrote: Dear Rory, dear all, JaCoCo project here. It looks like that OpenJDK build for jdk main dev branch (Java 15) is broken for us on ARM32 since commit changeset 59296:e25b21095e86 8242524: Use different default CDS archives depending on UseCompressOops Reviewed-by: erikj, iklam, ccheung The logged error is: === Output from failing command(s) repeated here === * For target support_images_jdk__gen_cds_nocoops_archive_jdk_exec: Unrecognized VM option 'UseCompressedOops' Did you mean '(+/-)CheckCompressedOops'? Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. Best regards, -marc
JDK Build Broken since "8242524: Use different default CDS archives depending on UseCompressOops"
Dear Rory, dear all, JaCoCo project here. It looks like that OpenJDK build for jdk main dev branch (Java 15) is broken for us on ARM32 since commit changeset 59296:e25b21095e86 8242524: Use different default CDS archives depending on UseCompressOops Reviewed-by: erikj, iklam, ccheung The logged error is: === Output from failing command(s) repeated here === * For target support_images_jdk__gen_cds_nocoops_archive_jdk_exec: Unrecognized VM option 'UseCompressedOops' Did you mean '(+/-)CheckCompressedOops'? Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. Best regards, -marc
Re: JDK Build Broken since "8242524: Use different default CDS archives depending on UseCompressOops"
https://bugs.openjdk.java.net/browse/JDK-8245070 David On 15/05/2020 4:10 pm, David Holmes wrote: Hi Marc, I will file a bug for this. Thanks for the report. David On 15/05/2020 4:04 pm, Marc Hoffmann wrote: Dear Rory, dear all, JaCoCo project here. It looks like that OpenJDK build for jdk main dev branch (Java 15) is broken for us on ARM32 since commit changeset 59296:e25b21095e86 8242524: Use different default CDS archives depending on UseCompressOops Reviewed-by: erikj, iklam, ccheung The logged error is: === Output from failing command(s) repeated here === * For target support_images_jdk__gen_cds_nocoops_archive_jdk_exec: Unrecognized VM option 'UseCompressedOops' Did you mean '(+/-)CheckCompressedOops'? Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. Best regards, -marc
Re: run-tests on WSL; was Re: RFR: JDK-8245033 Fixes for building in WSL
On 2020-05-14 19:00, Jonathan Gibbons wrote: Separate from this RFR, jtreg supports WSL (or is supposed to!) and so I wonder if you have looked at using WSL in the run-tests framework. I just did "make test-tier1", and got this: == Test summary == TEST TOTAL PASS FAIL ERROR jtreg:open/test/hotspot/jtreg:tier1 1527 1527 0 0 >> jtreg:open/test/jdk:tier1 1918 1902 16 0 << >> jtreg:open/test/langtools:tier1 4037 4028 9 0 << jtreg:open/test/jaxp:tier1 0 0 0 0 == TEST FAILURE So, it's not DOA, we can certainly run tests. But I got in total 25 failures, and it seems likely that these are caused by quirks in the WSL environment. I looked at a few arbitrarily selected, and all of them where shell tests that had the same failure mode: ACTION: shell -- Failed. Execution failed: exit code 2 REASON: User specified action: run shell Class-Path2.sh TIME: 0.098 seconds messages: command: shell Class-Path2.sh reason: User specified action: run shell Class-Path2.sh elapsed time (seconds): 0.098 STDOUT: STDERR: /mnt/c/localdata/hg/sandbox-ALT/open/test/langtools/tools/javac/Paths/Class-Path2.sh: 34: .: Can't open C:/localdata/hg/sandbox-ALT/open/test/langtools/tools/javac/Paths/Util.sh ... which definitely sounds fishy. /Magnus
Re: run-tests on WSL; was Re: RFR: JDK-8245033 Fixes for building in WSL
Yeah, it definitely is an issue with path conversion on WSL. jtreg is jumping back and forth between the Windows and the Linux world. For instance, it sets TESTSRC=C:/localdata/hg/sandbox-ALT/open/test/jdk/java/lang/Class/forName using Windows paths, but then calls wsl.exe \ sh /mnt/c/localdata/hg/sandbox-ALT/open/test/jdk/java/lang/Class/forName/NonJavaNames.sh using unix paths and a unix shell. So, unsurprisingly, we get: cp: cannot stat 'C:/localdata/hg/sandbox-ALT/open/test/jdk/java/lang/Class/forName/classes/hyphen.class': No such file or directory One added complexity on WSL, compared to cygwin, is that not all unix paths have a Windows equivalent. Only data located on Windows drives (C: or, from WSL, /mnt/c, etc) can be shared, stuff on e.g. /usr is inaccessible from Windows. I don't know if this can be a problem for jtreg shell tests. But it means for instance that you cannot trivially have e.g. PROG=/bin/true and suppose you can trivially transcripe the path for PROG between unix and windows formats. So you need to be careful what kind of paths you are using. Which is unlike cygwin, were you could be quite sloppy about those things, and just convert the paths back and fro. /Magnus On 2020-05-15 09:08, Magnus Ihse Bursie wrote: On 2020-05-14 19:00, Jonathan Gibbons wrote: Separate from this RFR, jtreg supports WSL (or is supposed to!) and so I wonder if you have looked at using WSL in the run-tests framework. I just did "make test-tier1", and got this: == Test summary == TEST TOTAL PASS FAIL ERROR jtreg:open/test/hotspot/jtreg:tier1 1527 1527 0 0 >> jtreg:open/test/jdk:tier1 1918 1902 16 0 << >> jtreg:open/test/langtools:tier1 4037 4028 9 0 << jtreg:open/test/jaxp:tier1 0 0 0 0 == TEST FAILURE So, it's not DOA, we can certainly run tests. But I got in total 25 failures, and it seems likely that these are caused by quirks in the WSL environment. I looked at a few arbitrarily selected, and all of them where shell tests that had the same failure mode: ACTION: shell -- Failed. Execution failed: exit code 2 REASON: User specified action: run shell Class-Path2.sh TIME: 0.098 seconds messages: command: shell Class-Path2.sh reason: User specified action: run shell Class-Path2.sh elapsed time (seconds): 0.098 STDOUT: STDERR: /mnt/c/localdata/hg/sandbox-ALT/open/test/langtools/tools/javac/Paths/Class-Path2.sh: 34: .: Can't open C:/localdata/hg/sandbox-ALT/open/test/langtools/tools/javac/Paths/Util.sh ... which definitely sounds fishy. /Magnus
Re: JDK Build Broken since "8242524: Use different default CDS archives depending on UseCompressOops"
Thanks Marc! On 15/05/2020 07:18, David Holmes wrote: https://bugs.openjdk.java.net/browse/JDK-8245070 David On 15/05/2020 4:10 pm, David Holmes wrote: Hi Marc, I will file a bug for this. Thanks for the report. David On 15/05/2020 4:04 pm, Marc Hoffmann wrote: Dear Rory, dear all, JaCoCo project here. It looks like that OpenJDK build for jdk main dev branch (Java 15) is broken for us on ARM32 since commit changeset 59296:e25b21095e86 8242524: Use different default CDS archives depending on UseCompressOops Reviewed-by: erikj, iklam, ccheung The logged error is: === Output from failing command(s) repeated here === * For target support_images_jdk__gen_cds_nocoops_archive_jdk_exec: Unrecognized VM option 'UseCompressedOops' Did you mean '(+/-)CheckCompressedOops'? Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. Best regards, -marc -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland
