From yasu at ysfactory.dip.jp Sat Mar 1 14:07:06 2014 From: yasu at ysfactory.dip.jp (Yasumasa Suenaga) Date: Sat, 01 Mar 2014 23:07:06 +0900 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <53112019.9050504@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> Message-ID: <5311E98A.1020004@ysfactory.dip.jp> Hi David, > 1. Generating debug symbols in the binaries (via gcc -g or whatever) > 2. Generating debuginfo files (zipped or not) (FDS) > 3. Stripping debug symbols from the binaries (strip-policy) > > It may be that we don't have clean separation between them, and if so > that should be fixed, but I don't see the current proposal as the way > forward. Currently, 1. depends 2. If FDS set to disable, debug symbols (-g) are not generated. SEPARATED_DEBUGINFO_FILES which my patch provides can separate them. > Also there may well be differences between how things are handled on the > JDK side and hotspot side. libjvm, libjsig. libsaproc are built with each makefiles in hotspot/make . Other native library is built with make/common/NativeCompilation.gmk . Additionally strip command is executed in "image" target which is defined in jdk/make/Images.gmk . This "strip" ignores STRIP_POLICY . Thus ELF binaries which are contained in JDK/JRE images are stripped when we execute "images" or "all" target. So I change: 1. Separating to add "-g" option to compiler from executing objcopy. 2. jdk/make/Images.gmk regards STRIP_POLICY. As I mentioned earlier, this issue is related to RPM. So I hope to fix it before JDK8 GA is released. Thanks, Yasumasa On 2014/03/01 8:47, David Holmes wrote: > On 1/03/2014 1:38 AM, Yasumasa Suenaga wrote: >>> The proper way to fix this is to disable FDS. >> >> Does this mean I have to pass --disable-debug-symbols to configure ? >> I've added comment to JDK-8036003, I think if we pass --disable-debug-symbols >> to configure, gcc/g++ is not passed -g option. "-g" is needed to generate >> debuginfo. > > There are three pieces to all of this: > > 1. Generating debug symbols in the binaries (via gcc -g or whatever) > 2. Generating debuginfo files (zipped or not) (FDS) > 3. Stripping debug symbols from the binaries (strip-policy) > > It may be that we don't have clean separation between them, and if so > that should be fixed, but I don't see the current proposal as the way > forward. > > Also there may well be differences between how things are handled on the > JDK side and hotspot side. > > I will try to look closer if I get a chance but my time is limited at > the moment. > > David > >> >> Thanks, >> >> Yasumasa >> >> >> On 2014/02/28 23:04, Daniel D. Daugherty wrote: >>> The proper way to fix this is to disable FDS. We should not need >>> yet another option to control debug info. >>> >>> Dan >>> >>> >>> On 2/28/14 4:13 AM, David Holmes wrote: >>>> Hi, >>>> >>>> As I put in the bug report this seems way too complicated. Seems to me >>>> all you need to do to get what you want is not use FDS and not strip the >>>> symbols from the binary. The former is trivial. The latter is more >>>> awkward as the strip policy stuff does not work as I would want it to >>>> work, but still doable. >>>> >>>> David >>>> >>>> On 28/02/2014 7:18 PM, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> >>>>> Currently, configure script can accept --disable-debug-symbols and >>>>> --disable-zip-debug-info as controlling to generate debug information. >>>>> However, current makefiles cannot build ELF binaries which is contained >>>>> debug information with "images" target. >>>>> >>>>> Some Linux distros use RPM as package manager. >>>>> RPM is built by rpmbuild command, it strips symbols and debug information >>>>> during to generate rpm packages. >>>>> https://fedoraproject.org/wiki/Packaging:Debuginfo >>>>> >>>>> For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo . >>>>> libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not >>>>> contain debug information. Actual debug information is shipped by OpenJDK >>>>> debuginfo package. >>>>> This packaging is important when we have to debug JVM/JNI libraries. >>>>> If we want to use debugging tools (GDB, SystemTap, etc...), they may requires >>>>> debuginfo package. Debuggee (e.g. libjvm.so) points libjvm.so.debug which is >>>>> located at sub directory in /usr/lib/debug . It is defined in ELF section >>>>> (.note.gnu.build-id) of libjvm.so . However libjvm.so.debug does not contain >>>>> valid debug information. We need to access libjvm.debuginfo.debug at same location. >>>>> >>>>> >>>>> When we think to build OpenJDK rpm packages, we have to build ELF binaries >>>>> which contain all debug information. we should not to separate debug information. >>>>> >>>>> >>>>> Thus I want to add a variable "SEPARATED_DEBUGINFO_FILES" . >>>>> If we pass "SEPARATED_DEBUGINFO_FILES=false" to make command, "make" does not >>>>> execute objcopy command for generating debuginfo binaries. >>>>> >>>>> If we build rpm packages, we also have to add "STRIP_POLICY=no_strip" to arguments >>>>> of make command. Or ELF binaries will be stripped. >>>>> >>>>> >>>>> I've uploaded webrev for this enhancement. >>>>> This is separated 3-part: top of forest, hotspot, jdk >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/ >>>>> >>>>> Please review it and sponsoring! >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> P.S. >>>>> I tried to add SEPARATED_DEBUGINFO_FILES as a configure option like >>>>> "--disable-separated-debug-info" . >>>>> I ran configure which is located at jdk9/dev directory after I ran autoconf >>>>> and common/autoconf/autogen.sh. However it failed. >>>>> >>>>> I guess this is caused by changeset as below. >>>>> JDK-8035495: Improvements in autoconf integration >>>>> http://hg.openjdk.java.net/jdk9/dev/rev/6e29cd9ac2b4 >>>>> >>>>> This changes add "CHECKME" option to configure script. However, this changes >>>>> affects "configure" only. It should change "configure.ac" . >>>>> >>> >> > From mike.duigou at oracle.com Sat Mar 1 23:08:56 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Sat, 1 Mar 2014 15:08:56 -0800 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <5311E98A.1020004@ysfactory.dip.jp> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <5311E98A.1020004@ysfactory.dip.jp> Message-ID: On Mar 1 2014, at 06:07 , Yasumasa Suenaga wrote: > Hi David, > >> 1. Generating debug symbols in the binaries (via gcc -g or whatever) >> 2. Generating debuginfo files (zipped or not) (FDS) >> 3. Stripping debug symbols from the binaries (strip-policy) >> >> It may be that we don't have clean separation between them, and if so >> that should be fixed, but I don't see the current proposal as the way >> forward. > > Currently, 1. depends 2. If FDS set to disable, debug symbols (-g) are not > generated. > SEPARATED_DEBUGINFO_FILES which my patch provides can separate them. I think David's list (kudos) is very helpful as I haven't seen the requirements articulated this clearly anywhere else. Some comments: - Are there important tools that cannot deal with external debuginfo files? If we can put debuginfo into external files why would we ever want unstripped binaries? Is strip policy really necessary? Strip policy would seem to only be necessary if there are tools which can't handle external debuginfo. Assuming that everything can use external debuginfo then the policy would be to strip everything. Do I understand correctly that rpmbuild can only deal with unstripped binaries and generates the stripped rpm package and debuginfo package. It sounds kind of strange that find-debuginfo.sh wouldn't be able to use already generated debuginfo files. - I would expect that the flow is something like an extended version of https://blogs.oracle.com/dbx/entry/creating_separate_debug_info : 1. Compile source files with some form of "-g" 2. Create separate debug files for object files. 3. Strip object files. 4. Add gnu_debuglink to object files. 5. Link library or executable which should carry along links to debuginfo. 6a. Debugging, testing, profiling, etc. by developers. 6b. Packaging for program bits and debuginfo. 7. Testing and Use. Hopefully I didn't get any of those steps in the wrong order. What are the "you-cant-get-there-from-here" gaps and breakdowns from implementing this process? - Whether for the FDS debug symbols or RPM debuginfo packaging it seems that the default debug level isn't quite right. I believe that in both cases what's wanted is abbreviated debug info, mostly function names and line number tables, for building stack traces. This is not the debug info that is currently generated. There are four basic alternatives for levels of debug info: 1. (-g0) No debug info whatsoever. Only exported functions and globals will have names. 2. (-g1) Abbreviated debug info. All functions have names and line number information. This seems to be what is needed by both FDS and RPM debuginfo files to produce nice stack traces. 3. (-g) Default debugging info. Adds macro expansions and local variable names. Suitable for source level debugging. 4. (-g3 or -gdwarf-4 -fvar-tracking-assignments). Full debugging info. Most suitable for source level debugging including debugging of optimized code. It is not clear that anyone would want to build the entire product with this option. Compilations are currently done with a mix of -g, -g1, and -gstabs. It would be good to rationalize this somewhat and provide a mechanism for developers to tweak generated debugging output for files or components. - Eventual alignment with http://gcc.gnu.org/wiki/DebugFission on some platforms? > So I change: > > 1. Separating to add "-g" option to compiler from executing objcopy. > 2. jdk/make/Images.gmk regards STRIP_POLICY. > > > As I mentioned earlier, this issue is related to RPM. > So I hope to fix it before JDK8 GA is released. This won't happen (at least not for Java 8u0). Java 8 is already late in it's final candidate stage. It is too late for the initial Java 8 release to consider this magnitude of change. In any event, since the Java 8 rampdown began back in November, any change would first have to be applied to Java 9 and then approved for backport to a Java 8 or an update release (and it is also possibly too late for 8u20). Inability to include your suggested change in Java 8 or 8u20 is in no way a rejection of the ideas or contribution, it's merely a normal consequence of timelines and process. Mike From yasu at ysfactory.dip.jp Sun Mar 2 14:01:10 2014 From: yasu at ysfactory.dip.jp (Yasumasa Suenaga) Date: Sun, 02 Mar 2014 23:01:10 +0900 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <5311E98A.1020004@ysfactory.dip.jp> Message-ID: <531339A6.3050806@ysfactory.dip.jp> HI Mike, > - I would expect that the flow is something like an extended version of https://blogs.oracle.com/dbx/entry/creating_separate_debug_info : > 1. Compile source files with some form of "-g" > 2. Create separate debug files for object files. > 3. Strip object files. > 4. Add gnu_debuglink to object files. > 5. Link library or executable which should carry along links to debuginfo. > 6a. Debugging, testing, profiling, etc. by developers. > 6b. Packaging for program bits and debuginfo. > 7. Testing and Use. rpmbuild will execute 2 to 4 implicitly, Modern ELF binary has .note.gnu.build-id section. Debugging tools (e.g. GDB and SA in JDK) use this section for finding debuginfo files. If OpenJDK8 which is shipped by RPM is crashed and we want to analyze core image, we have to merge debuginfo and executable at first (e.g. eu-unstrip command). GDB and SA can find valid debuginfo through .note.gnu.debug-id or .gnu_debuglink section. But these tools can find /usr/lib/debug//.debug . They are cannot find *.debuginfo which are made by makefiles in OpenJDK tree. Yasumasa On 2014/03/02 8:08, Mike Duigou wrote: > > On Mar 1 2014, at 06:07 , Yasumasa Suenaga wrote: > >> Hi David, >> >>> 1. Generating debug symbols in the binaries (via gcc -g or whatever) >>> 2. Generating debuginfo files (zipped or not) (FDS) >>> 3. Stripping debug symbols from the binaries (strip-policy) >>> >>> It may be that we don't have clean separation between them, and if so >>> that should be fixed, but I don't see the current proposal as the way >>> forward. >> >> Currently, 1. depends 2. If FDS set to disable, debug symbols (-g) are not >> generated. >> SEPARATED_DEBUGINFO_FILES which my patch provides can separate them. > > I think David's list (kudos) is very helpful as I haven't seen the requirements articulated this clearly anywhere else. > > Some comments: > > - Are there important tools that cannot deal with external debuginfo files? If we can put debuginfo into external files why would we ever want unstripped binaries? Is strip policy really necessary? Strip policy would seem to only be necessary if there are tools which can't handle external debuginfo. Assuming that everything can use external debuginfo then the policy would be to strip everything. > > Do I understand correctly that rpmbuild can only deal with unstripped binaries and generates the stripped rpm package and debuginfo package. It sounds kind of strange that find-debuginfo.sh wouldn't be able to use already generated debuginfo files. > > - I would expect that the flow is something like an extended version of https://blogs.oracle.com/dbx/entry/creating_separate_debug_info : > 1. Compile source files with some form of "-g" > 2. Create separate debug files for object files. > 3. Strip object files. > 4. Add gnu_debuglink to object files. > 5. Link library or executable which should carry along links to debuginfo. > 6a. Debugging, testing, profiling, etc. by developers. > 6b. Packaging for program bits and debuginfo. > 7. Testing and Use. > > Hopefully I didn't get any of those steps in the wrong order. What are the "you-cant-get-there-from-here" gaps and breakdowns from implementing this process? > > - Whether for the FDS debug symbols or RPM debuginfo packaging it seems that the default debug level isn't quite right. I believe that in both cases what's wanted is abbreviated debug info, mostly function names and line number tables, for building stack traces. This is not the debug info that is currently generated. > > There are four basic alternatives for levels of debug info: > 1. (-g0) No debug info whatsoever. > Only exported functions and globals will have names. > 2. (-g1) Abbreviated debug info. > All functions have names and line number information. This seems to be what is needed by both FDS and RPM debuginfo files to produce nice stack traces. > 3. (-g) Default debugging info. > Adds macro expansions and local variable names. Suitable for source level debugging. > 4. (-g3 or -gdwarf-4 -fvar-tracking-assignments). Full debugging info. > Most suitable for source level debugging including debugging of optimized code. It is not clear that anyone would want to build the entire product with this option. > > Compilations are currently done with a mix of -g, -g1, and -gstabs. It would be good to rationalize this somewhat and provide a mechanism for developers to tweak generated debugging output for files or components. > > - Eventual alignment with http://gcc.gnu.org/wiki/DebugFission on some platforms? > >> So I change: >> >> 1. Separating to add "-g" option to compiler from executing objcopy. >> 2. jdk/make/Images.gmk regards STRIP_POLICY. >> >> >> As I mentioned earlier, this issue is related to RPM. >> So I hope to fix it before JDK8 GA is released. > > This won't happen (at least not for Java 8u0). Java 8 is already late in it's final candidate stage. It is too late for the initial Java 8 release to consider this magnitude of change. In any event, since the Java 8 rampdown began back in November, any change would first have to be applied to Java 9 and then approved for backport to a Java 8 or an update release (and it is also possibly too late for 8u20). > > Inability to include your suggested change in Java 8 or 8u20 is in no way a rejection of the ideas or contribution, it's merely a normal consequence of timelines and process. > > Mike From david.holmes at oracle.com Mon Mar 3 04:39:23 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 03 Mar 2014 14:39:23 +1000 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <5311E98A.1020004@ysfactory.dip.jp> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <5311E98A.1020004@ysfactory.dip.jp> Message-ID: <5314077B.9060908@oracle.com> Hi, On 2/03/2014 12:07 AM, Yasumasa Suenaga wrote: > Hi David, > >> 1. Generating debug symbols in the binaries (via gcc -g or whatever) >> 2. Generating debuginfo files (zipped or not) (FDS) >> 3. Stripping debug symbols from the binaries (strip-policy) >> >> It may be that we don't have clean separation between them, and if so >> that should be fixed, but I don't see the current proposal as the way >> forward. > > Currently, 1. depends 2. If FDS set to disable, debug symbols (-g) are not > generated. Okay. That would seem potentially inconvenient but not really critical. You simply enable FDS (the mere existence of the debuginfo files "shouldn't" cause a problem). Then you only need to address #3 - strip-policy. > SEPARATED_DEBUGINFO_FILES which my patch provides can separate them. > > >> Also there may well be differences between how things are handled on the >> JDK side and hotspot side. > > libjvm, libjsig. libsaproc are built with each makefiles in hotspot/make . > Other native library is built with make/common/NativeCompilation.gmk . > > Additionally strip command is executed in "image" target which is defined > in jdk/make/Images.gmk . This "strip" ignores STRIP_POLICY . Thus ELF binaries > which are contained in JDK/JRE images are stripped when we execute "images" > or "all" target. strip is also applied to the JVM libraries as part of the hotspot build. What occurs in the JDK "images" is additional to that.The hotspot build honors the STRIP_POLICY. It appears that STRIP_POLICY is not considered in the new build, though it was for the old. But perhaps I'm missing it somewhere in the autoconf settings? That aside it seems that you should be able to set POST_STRIP_CMD to "" avoid stripping. Moving forward I think we would need to expose the strip-policy via a configure option and have that pass STRIP_POLICY through to both hotspot and the Images target. > > So I change: > > 1. Separating to add "-g" option to compiler from executing objcopy. > 2. jdk/make/Images.gmk regards STRIP_POLICY. > > > As I mentioned earlier, this issue is related to RPM. > So I hope to fix it before JDK8 GA is released. As Mike said there is no chance of any changes to this getting into 8 GA. But if these are your own builds I'm not sure that is an issue anyway. That said, as per the above I think you can achieve what you want by enabling FDS but set STRIP_POLICY to none, and set POST_STRIP_CMD to empty. Thanks, David > > Thanks, > > Yasumasa > > > On 2014/03/01 8:47, David Holmes wrote: >> On 1/03/2014 1:38 AM, Yasumasa Suenaga wrote: >>>> The proper way to fix this is to disable FDS. >>> >>> Does this mean I have to pass --disable-debug-symbols to configure ? >>> I've added comment to JDK-8036003, I think if we pass --disable-debug-symbols >>> to configure, gcc/g++ is not passed -g option. "-g" is needed to generate >>> debuginfo. >> >> There are three pieces to all of this: >> >> 1. Generating debug symbols in the binaries (via gcc -g or whatever) >> 2. Generating debuginfo files (zipped or not) (FDS) >> 3. Stripping debug symbols from the binaries (strip-policy) >> >> It may be that we don't have clean separation between them, and if so >> that should be fixed, but I don't see the current proposal as the way >> forward. >> >> Also there may well be differences between how things are handled on the >> JDK side and hotspot side. >> >> I will try to look closer if I get a chance but my time is limited at >> the moment. >> >> David >> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2014/02/28 23:04, Daniel D. Daugherty wrote: >>>> The proper way to fix this is to disable FDS. We should not need >>>> yet another option to control debug info. >>>> >>>> Dan >>>> >>>> >>>> On 2/28/14 4:13 AM, David Holmes wrote: >>>>> Hi, >>>>> >>>>> As I put in the bug report this seems way too complicated. Seems to me >>>>> all you need to do to get what you want is not use FDS and not strip the >>>>> symbols from the binary. The former is trivial. The latter is more >>>>> awkward as the strip policy stuff does not work as I would want it to >>>>> work, but still doable. >>>>> >>>>> David >>>>> >>>>> On 28/02/2014 7:18 PM, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> >>>>>> Currently, configure script can accept --disable-debug-symbols and >>>>>> --disable-zip-debug-info as controlling to generate debug information. >>>>>> However, current makefiles cannot build ELF binaries which is contained >>>>>> debug information with "images" target. >>>>>> >>>>>> Some Linux distros use RPM as package manager. >>>>>> RPM is built by rpmbuild command, it strips symbols and debug information >>>>>> during to generate rpm packages. >>>>>> https://fedoraproject.org/wiki/Packaging:Debuginfo >>>>>> >>>>>> For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo . >>>>>> libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not >>>>>> contain debug information. Actual debug information is shipped by OpenJDK >>>>>> debuginfo package. >>>>>> This packaging is important when we have to debug JVM/JNI libraries. >>>>>> If we want to use debugging tools (GDB, SystemTap, etc...), they may requires >>>>>> debuginfo package. Debuggee (e.g. libjvm.so) points libjvm.so.debug which is >>>>>> located at sub directory in /usr/lib/debug . It is defined in ELF section >>>>>> (.note.gnu.build-id) of libjvm.so . However libjvm.so.debug does not contain >>>>>> valid debug information. We need to access libjvm.debuginfo.debug at same location. >>>>>> >>>>>> >>>>>> When we think to build OpenJDK rpm packages, we have to build ELF binaries >>>>>> which contain all debug information. we should not to separate debug information. >>>>>> >>>>>> >>>>>> Thus I want to add a variable "SEPARATED_DEBUGINFO_FILES" . >>>>>> If we pass "SEPARATED_DEBUGINFO_FILES=false" to make command, "make" does not >>>>>> execute objcopy command for generating debuginfo binaries. >>>>>> >>>>>> If we build rpm packages, we also have to add "STRIP_POLICY=no_strip" to arguments >>>>>> of make command. Or ELF binaries will be stripped. >>>>>> >>>>>> >>>>>> I've uploaded webrev for this enhancement. >>>>>> This is separated 3-part: top of forest, hotspot, jdk >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/ >>>>>> >>>>>> Please review it and sponsoring! >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> P.S. >>>>>> I tried to add SEPARATED_DEBUGINFO_FILES as a configure option like >>>>>> "--disable-separated-debug-info" . >>>>>> I ran configure which is located at jdk9/dev directory after I ran autoconf >>>>>> and common/autoconf/autogen.sh. However it failed. >>>>>> >>>>>> I guess this is caused by changeset as below. >>>>>> JDK-8035495: Improvements in autoconf integration >>>>>> http://hg.openjdk.java.net/jdk9/dev/rev/6e29cd9ac2b4 >>>>>> >>>>>> This changes add "CHECKME" option to configure script. However, this changes >>>>>> affects "configure" only. It should change "configure.ac" . >>>>>> >>>> >>> >> > From aph at redhat.com Mon Mar 3 09:41:33 2014 From: aph at redhat.com (Andrew Haley) Date: Mon, 03 Mar 2014 09:41:33 +0000 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> Message-ID: <53144E4D.8080606@redhat.com> On 02/28/2014 09:18 AM, Yasumasa Suenaga wrote: > For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo . > libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not > contain debug information. Actual debug information is shipped by OpenJDK > debuginfo package. That's a bug in Fedora's build. We should fix it. Andrew. From aph at redhat.com Mon Mar 3 09:46:38 2014 From: aph at redhat.com (Andrew Haley) Date: Mon, 03 Mar 2014 09:46:38 +0000 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <5311E98A.1020004@ysfactory.dip.jp> Message-ID: <53144F7E.5000105@redhat.com> On 03/01/2014 11:08 PM, Mike Duigou wrote: > Do I understand correctly that rpmbuild can only deal with > unstripped binaries and generates the stripped rpm package and > debuginfo package. Exactly. OpenJDK generating separate debuginfo files is very inconvenient for RPM builds. > It sounds kind of strange that find-debuginfo.sh wouldn't be able to > use already generated debuginfo files. The OpenJDK build can't have any idea of what debuginfo files the distro runtime requires, and indeed this may change. There is more than one mechanism for finding debuginfo. Separating debuginfo is not something that we want the OpenJDK build to do, and the most useful thing that we could have is a switch to turn all of OpenJDK's stripping and separate debuginfo off. I expect the same applies to all distros. Andrew. From erik.joelsson at oracle.com Mon Mar 3 09:46:36 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 03 Mar 2014 10:46:36 +0100 Subject: RFR: JDK-8036079 : (s) --with-boot-jdk-jvmargs configure options are ignored In-Reply-To: <5D14D012-EAAD-49FB-AF90-BC10A15C0530@oracle.com> References: <5D14D012-EAAD-49FB-AF90-BC10A15C0530@oracle.com> Message-ID: <53144F7C.4090002@oracle.com> Looks good to me. /Erik On 2014-02-28 20:53, Mike Duigou wrote: > Hello all; > > Currently the parameter passed to configure --with-bootjdk-jvmargs is ignored. This changeset improves(*) the handling of the args. > > http://cr.openjdk.java.net/~mduigou/JDK-8036079/0/webrev/ > > I also cleaned up the defaults slightly to better capture the intent of the tests. ie. check for host OS build bits rather than specific platforms. > > JAVA_FLAGS in the spec.gmk.in was previously defined by AC_SUBST from the BOOT_JDK_JVMARGS value. It is now AC_SUBST from JAVA_FLAGS though both JAVA_FLAGS and BOOT_JDK_JVMARGS currently have the same value. > > (*) It is reasonable to debate whether defaults applied by the configure script should be inserted in BOOTJDK_SETUP_BOOT_JDK_ARGUMENTS as JVM flags. The heap maximum size and stack size will hopefully be revisited via JDK-8007327 > > Mike From yasu at ysfactory.dip.jp Mon Mar 3 12:04:51 2014 From: yasu at ysfactory.dip.jp (Yasumasa Suenaga) Date: Mon, 03 Mar 2014 21:04:51 +0900 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <5314077B.9060908@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <5311E98A.1020004@ysfactory.dip.jp> <5314077B.9060908@oracle.com> Message-ID: <53146FE3.9040205@ysfactory.dip.jp> Hi David, > Moving forward I think we would need to expose the strip-policy via a > configure option and have that pass STRIP_POLICY through to both hotspot > and the Images target. I want you to do so :-) Additionally, >>> 1. Generating debug symbols in the binaries (via gcc -g or whatever) >>> 2. Generating debuginfo files (zipped or not) (FDS) >>> 3. Stripping debug symbols from the binaries (strip-policy) I think that FDS should be separated 1 from 2. That is more useful for building OpenJDK. > That said, as per the above I think you can achieve what you > want by enabling FDS but set STRIP_POLICY to none, and set > POST_STRIP_CMD to empty. I tried: $ make images STRIP_POLICY=no_strip POST_STRIP_CMD="" I was able to get binaries which is included debug information. Thanks, Yasumasa On 2014/03/03 13:39, David Holmes wrote: > Hi, > > On 2/03/2014 12:07 AM, Yasumasa Suenaga wrote: >> Hi David, >> >>> 1. Generating debug symbols in the binaries (via gcc -g or whatever) >>> 2. Generating debuginfo files (zipped or not) (FDS) >>> 3. Stripping debug symbols from the binaries (strip-policy) >>> >>> It may be that we don't have clean separation between them, and if so >>> that should be fixed, but I don't see the current proposal as the way >>> forward. >> >> Currently, 1. depends 2. If FDS set to disable, debug symbols (-g) are not >> generated. > > Okay. That would seem potentially inconvenient but not really critical. > You simply enable FDS (the mere existence of the debuginfo files > "shouldn't" cause a problem). Then you only need to address #3 - > strip-policy. > >> SEPARATED_DEBUGINFO_FILES which my patch provides can separate them. >> >> >>> Also there may well be differences between how things are handled on the >>> JDK side and hotspot side. >> >> libjvm, libjsig. libsaproc are built with each makefiles in hotspot/make . >> Other native library is built with make/common/NativeCompilation.gmk . >> >> Additionally strip command is executed in "image" target which is defined >> in jdk/make/Images.gmk . This "strip" ignores STRIP_POLICY . Thus ELF binaries >> which are contained in JDK/JRE images are stripped when we execute "images" >> or "all" target. > > strip is also applied to the JVM libraries as part of the hotspot build. > What occurs in the JDK "images" is additional to that.The hotspot build > honors the STRIP_POLICY. > > It appears that STRIP_POLICY is not considered in the new build, though > it was for the old. But perhaps I'm missing it somewhere in the autoconf > settings? That aside it seems that you should be able to set > POST_STRIP_CMD to "" avoid stripping. > > Moving forward I think we would need to expose the strip-policy via a > configure option and have that pass STRIP_POLICY through to both hotspot > and the Images target. > >> >> So I change: >> >> 1. Separating to add "-g" option to compiler from executing objcopy. >> 2. jdk/make/Images.gmk regards STRIP_POLICY. >> >> >> As I mentioned earlier, this issue is related to RPM. >> So I hope to fix it before JDK8 GA is released. > > As Mike said there is no chance of any changes to this getting into 8 > GA. But if these are your own builds I'm not sure that is an issue > anyway. That said, as per the above I think you can achieve what you > want by enabling FDS but set STRIP_POLICY to none, and set > POST_STRIP_CMD to empty. > > Thanks, > David > >> >> Thanks, >> >> Yasumasa >> >> >> On 2014/03/01 8:47, David Holmes wrote: >>> On 1/03/2014 1:38 AM, Yasumasa Suenaga wrote: >>>>> The proper way to fix this is to disable FDS. >>>> >>>> Does this mean I have to pass --disable-debug-symbols to configure ? >>>> I've added comment to JDK-8036003, I think if we pass --disable-debug-symbols >>>> to configure, gcc/g++ is not passed -g option. "-g" is needed to generate >>>> debuginfo. >>> >>> There are three pieces to all of this: >>> >>> 1. Generating debug symbols in the binaries (via gcc -g or whatever) >>> 2. Generating debuginfo files (zipped or not) (FDS) >>> 3. Stripping debug symbols from the binaries (strip-policy) >>> >>> It may be that we don't have clean separation between them, and if so >>> that should be fixed, but I don't see the current proposal as the way >>> forward. >>> >>> Also there may well be differences between how things are handled on the >>> JDK side and hotspot side. >>> >>> I will try to look closer if I get a chance but my time is limited at >>> the moment. >>> >>> David >>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2014/02/28 23:04, Daniel D. Daugherty wrote: >>>>> The proper way to fix this is to disable FDS. We should not need >>>>> yet another option to control debug info. >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 2/28/14 4:13 AM, David Holmes wrote: >>>>>> Hi, >>>>>> >>>>>> As I put in the bug report this seems way too complicated. Seems to me >>>>>> all you need to do to get what you want is not use FDS and not strip the >>>>>> symbols from the binary. The former is trivial. The latter is more >>>>>> awkward as the strip policy stuff does not work as I would want it to >>>>>> work, but still doable. >>>>>> >>>>>> David >>>>>> >>>>>> On 28/02/2014 7:18 PM, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> >>>>>>> Currently, configure script can accept --disable-debug-symbols and >>>>>>> --disable-zip-debug-info as controlling to generate debug information. >>>>>>> However, current makefiles cannot build ELF binaries which is contained >>>>>>> debug information with "images" target. >>>>>>> >>>>>>> Some Linux distros use RPM as package manager. >>>>>>> RPM is built by rpmbuild command, it strips symbols and debug information >>>>>>> during to generate rpm packages. >>>>>>> https://fedoraproject.org/wiki/Packaging:Debuginfo >>>>>>> >>>>>>> For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo . >>>>>>> libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not >>>>>>> contain debug information. Actual debug information is shipped by OpenJDK >>>>>>> debuginfo package. >>>>>>> This packaging is important when we have to debug JVM/JNI libraries. >>>>>>> If we want to use debugging tools (GDB, SystemTap, etc...), they may requires >>>>>>> debuginfo package. Debuggee (e.g. libjvm.so) points libjvm.so.debug which is >>>>>>> located at sub directory in /usr/lib/debug . It is defined in ELF section >>>>>>> (.note.gnu.build-id) of libjvm.so . However libjvm.so.debug does not contain >>>>>>> valid debug information. We need to access libjvm.debuginfo.debug at same location. >>>>>>> >>>>>>> >>>>>>> When we think to build OpenJDK rpm packages, we have to build ELF binaries >>>>>>> which contain all debug information. we should not to separate debug information. >>>>>>> >>>>>>> >>>>>>> Thus I want to add a variable "SEPARATED_DEBUGINFO_FILES" . >>>>>>> If we pass "SEPARATED_DEBUGINFO_FILES=false" to make command, "make" does not >>>>>>> execute objcopy command for generating debuginfo binaries. >>>>>>> >>>>>>> If we build rpm packages, we also have to add "STRIP_POLICY=no_strip" to arguments >>>>>>> of make command. Or ELF binaries will be stripped. >>>>>>> >>>>>>> >>>>>>> I've uploaded webrev for this enhancement. >>>>>>> This is separated 3-part: top of forest, hotspot, jdk >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/ >>>>>>> >>>>>>> Please review it and sponsoring! >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> P.S. >>>>>>> I tried to add SEPARATED_DEBUGINFO_FILES as a configure option like >>>>>>> "--disable-separated-debug-info" . >>>>>>> I ran configure which is located at jdk9/dev directory after I ran autoconf >>>>>>> and common/autoconf/autogen.sh. However it failed. >>>>>>> >>>>>>> I guess this is caused by changeset as below. >>>>>>> JDK-8035495: Improvements in autoconf integration >>>>>>> http://hg.openjdk.java.net/jdk9/dev/rev/6e29cd9ac2b4 >>>>>>> >>>>>>> This changes add "CHECKME" option to configure script. However, this changes >>>>>>> affects "configure" only. It should change "configure.ac" . >>>>>>> >>>>> >>>> >>> >> > From yasu at ysfactory.dip.jp Mon Mar 3 12:04:59 2014 From: yasu at ysfactory.dip.jp (Yasumasa Suenaga) Date: Mon, 03 Mar 2014 21:04:59 +0900 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <53144F7E.5000105@redhat.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <5311E98A.1020004@ysfactory.dip.jp> <53144F7E.5000105@redhat.com> Message-ID: <53146FEB.8050300@ysfactory.dip.jp> Hi Andrew, > Separating debuginfo is not > something that we want the OpenJDK build to do, and the most useful > thing that we could have is a switch to turn all of OpenJDK's > stripping and separate debuginfo off. I expect the same applies to > all distros. My patch provides "SEPARATED_DEBUGINFO_FILES" as a switch of separating debuginfo files, and affects "STRIP_POILCY" in HotSpot and other ELF binaries. > I expect the same applies to all distros. We need to pass ' STRIP_POLICY=no_strip POST_STRIP_CMD="" ' to make command as David said. And we need to pick up binaries which are NOT named ".debuginfo" or ".diz" suffix. Thanks, Yasumasa On 2014/03/03 18:46, Andrew Haley wrote: > On 03/01/2014 11:08 PM, Mike Duigou wrote: > >> Do I understand correctly that rpmbuild can only deal with >> unstripped binaries and generates the stripped rpm package and >> debuginfo package. > > Exactly. OpenJDK generating separate debuginfo files is very > inconvenient for RPM builds. > >> It sounds kind of strange that find-debuginfo.sh wouldn't be able to >> use already generated debuginfo files. > > The OpenJDK build can't have any idea of what debuginfo files the > distro runtime requires, and indeed this may change. There is more > than one mechanism for finding debuginfo. Separating debuginfo is not > something that we want the OpenJDK build to do, and the most useful > thing that we could have is a switch to turn all of OpenJDK's > stripping and separate debuginfo off. I expect the same applies to > all distros. > > Andrew. > From daniel.daugherty at oracle.com Mon Mar 3 14:56:38 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 03 Mar 2014 07:56:38 -0700 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <5311E98A.1020004@ysfactory.dip.jp> Message-ID: <53149826.7030106@oracle.com> I think we're having a problem with not all replies making it to all the aliases. Yasumasa's reply to David below that Mike is replying to did not arrive on any of the aliases that I'm on... Folks need to remember to reply to all of the aliases... On 3/1/14 4:08 PM, Mike Duigou wrote: > On Mar 1 2014, at 06:07 , Yasumasa Suenaga wrote: > >> Hi David, >> >>> 1. Generating debug symbols in the binaries (via gcc -g or whatever) >>> 2. Generating debuginfo files (zipped or not) (FDS) >>> 3. Stripping debug symbols from the binaries (strip-policy) >>> >>> It may be that we don't have clean separation between them, and if so >>> that should be fixed, but I don't see the current proposal as the way >>> forward. >> Currently, 1. depends 2. If FDS set to disable, debug symbols (-g) are not >> generated. Bit of history here. When FDS is disabled, the build system is supposed to go back to what was there prior to the FDS project. On Linux, one of the debug configs didn't actually have any debugging flags enabled (debug or fastdebug, I don't remember which). So when I implemented FDS, disabling FDS meant no debug info. Bug in the original? You betcha. >> SEPARATED_DEBUGINFO_FILES which my patch provides can separate them. > I think David's list (kudos) is very helpful as I haven't seen the requirements articulated this clearly anywhere else. > > Some comments: > > - Are there important tools that cannot deal with external debuginfo files? Not that I'm aware of. There have been bugs in the way gobjcopy is extracting the debuginfo into the separate files, but no complete failures as far as I know... > If we can put debuginfo into external files why would we ever want unstripped binaries? We deliver minimal stripped binaries so that can have stack traces with some amount of information in them when the debuginfo files are not available. We have not yet figured out how to implement minimal stripping on Windows so Windows hs_err_pid files have no symbols in them when the debuginfo bundles are not present. > Is strip policy really necessary? Yes. STRIP_POLICY allows folks to configure what they want for the build that they are doing. It is also meant to map to the Oracle policy where we were granted a waiver to deliver minimal symbols in FDS project. > Strip policy would seem to only be necessary if there are tools which can't handle external debuginfo. Assuming that everything can use external debuginfo then the policy would be to strip everything. No you don't want to strip everything. See above aboutminimal info in stack traces. > Do I understand correctly that rpmbuild can only deal with unstripped binaries and generates the stripped rpm package and debuginfo package. It sounds kind of strange that find-debuginfo.sh wouldn't be able to use already generated debuginfo files. > > - I would expect that the flow is something like an extended version of https://blogs.oracle.com/dbx/entry/creating_separate_debug_info : > 1. Compile source files with some form of "-g" > 2. Create separate debug files for object files. > 3. Strip object files. > 4. Add gnu_debuglink to object files. > 5. Link library or executable which should carry along links to debuginfo. > 6a. Debugging, testing, profiling, etc. by developers. > 6b. Packaging for program bits and debuginfo. > 7. Testing and Use. > > Hopefully I didn't get any of those steps in the wrong order. What are the "you-cant-get-there-from-here" gaps and breakdowns from implementing this process? > > - Whether for the FDS debug symbols or RPM debuginfo packaging it seems that the default debug level isn't quite right. I believe that in both cases what's wanted is abbreviated debug info, mostly function names and line number tables, for building stack traces. This is not the debug info that is currently generated. It's STRIP_POLICY=min_strip that leaves the minimal debug info attached to the binaries and the more complete debug info in left in the debuginfo file(s). And I'll disagree about only wanting abbreviated debug info in the separate debuginfo files. > There are four basic alternatives for levels of debug info: > 1. (-g0) No debug info whatsoever. > Only exported functions and globals will have names. > 2. (-g1) Abbreviated debug info. > All functions have names and line number information. This seems to be what is needed by both FDS and RPM debuginfo files to produce nice stack traces. > 3. (-g) Default debugging info. > Adds macro expansions and local variable names. Suitable for source level debugging. > 4. (-g3 or -gdwarf-4 -fvar-tracking-assignments). Full debugging info. > Most suitable for source level debugging including debugging of optimized code. It is not clear that anyone would want to build the entire product with this option. > > Compilations are currently done with a mix of -g, -g1, and -gstabs. It would be good to rationalize this somewhat and provide a mechanism for developers to tweak generated debugging output for files or components. There is a whole boatload of history behind using STABS or DWARF or -g1 and usually (at least in HotSpot) there are comments in the Makefiles explaining the sometimes arcane reasons why these choices were made... On Linux there is a special option DEBUG_BINARIES that is used to specify '-g' for everything. I believe the magic incantation for making RPM happy is something like: DEBUG_BINARIES=true FULL_DEBUG_SYMBOLS=0 STRIP_POLICY=none ALT_OBJCOPY=/does_not_exist The combination of FULL_DEBUG_SYMBOLS=0 and ALT_OBJCOPY=/does_not_exist disables FDS for all build configs and reverts to pre-FDS make logic. STRIP_POLICY=none says don't do any stripping. DEBUG_BINARIES=true says ignore all the other logic about which debug options and just do '-g'. I've accidentally broken DEBUG_BINARIES at least once, but I usually get pinged by the Red Hat folks when I do... Dan > - Eventual alignment with http://gcc.gnu.org/wiki/DebugFission on some platforms? > >> So I change: >> >> 1. Separating to add "-g" option to compiler from executing objcopy. >> 2. jdk/make/Images.gmk regards STRIP_POLICY. >> >> >> As I mentioned earlier, this issue is related to RPM. >> So I hope to fix it before JDK8 GA is released. > This won't happen (at least not for Java 8u0). Java 8 is already late in it's final candidate stage. It is too late for the initial Java 8 release to consider this magnitude of change. In any event, since the Java 8 rampdown began back in November, any change would first have to be applied to Java 9 and then approved for backport to a Java 8 or an update release (and it is also possibly too late for 8u20). > > Inability to include your suggested change in Java 8 or 8u20 is in no way a rejection of the ideas or contribution, it's merely a normal consequence of timelines and process. > > Mike From erik.joelsson at oracle.com Mon Mar 3 16:56:01 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 03 Mar 2014 17:56:01 +0100 Subject: RFR: JDK-8036145: Solaris standard grep does not understand -qE In-Reply-To: <530F45DF.9010301@oracle.com> References: <530F45DF.9010301@oracle.com> Message-ID: <5314B421.1010106@oracle.com> It seems I failed in the below fix. /usr/bin/grep on Solaris does not support -qE. Here is another patch, converting the regexp to work without the -E switch and piping to /dev/null to keep it quiet: Bug: https://bugs.openjdk.java.net/browse/JDK-8036145 diff --git a/common/autoconf/configure b/common/autoconf/configure --- a/common/autoconf/configure +++ b/common/autoconf/configure @@ -127,11 +127,11 @@ if [[ -n "$1" ]]; then # Uses only shell-safe characters? No quoting needed. # '=' is a zsh meta-character, but only in word-initial position. - if echo "$1" | grep -qE '^[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789.:,%/+=_-]+$' \ - && ! echo "$1" | grep -qE '^='; then + if echo "$1" | grep '^[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789\.:,%/+=_-]\{1,\}$' > /dev/null \ + && ! echo "$1" | grep '^=' > /dev/null; then quoted="$1" else - if echo "$1" | grep -qE "[\'!]"; then + if echo "$1" | grep "[\'!]" > /dev/null; then # csh does history expansion within single quotes, but not # when backslash-escaped! local quoted_quote="'\\''" quoted_exclam="'\\!'" /Erik On 2014-02-27 15:04, Erik Joelsson wrote: > JDK-8034199 unfortunately didn't work with a bunch of internal Solaris > installations. It seems common for Solaris 10 to not have an updated > bash version and the =~ construct used in that patch requires bash 3.x > or higher. > > Here is a rewrite of that part using grep. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8035904 > > Patch inline: > > diff -r 73d85b04c45c common/autoconf/configure > --- a/common/autoconf/configure > +++ b/common/autoconf/configure > @@ -127,10 +127,11 @@ > if [[ -n "$1" ]]; then > # Uses only shell-safe characters? No quoting needed. > # '=' is a zsh meta-character, but only in word-initial position. > - if [[ "$1" =~ > ^[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789.:,%/+=_-]+$ > && ! "$1" =~ ^= ]]; then > + if echo "$1" | grep -qE > '^[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789.:,%/+=_-]+$' > \ > + && ! echo "$1" | grep -qE '^='; then > quoted="$1" > else > - if [[ "$1" =~ [\'!] ]]; then > + if echo "$1" | grep -qE "[\'!]"; then > # csh does history expansion within single quotes, but not > # when backslash-escaped! > local quoted_quote="'\\''" quoted_exclam="'\\!'" > > > /Erik From Alan.Bateman at oracle.com Mon Mar 3 17:00:55 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 03 Mar 2014 17:00:55 +0000 Subject: RFR: JDK-8036145: Solaris standard grep does not understand -qE In-Reply-To: <5314B421.1010106@oracle.com> References: <530F45DF.9010301@oracle.com> <5314B421.1010106@oracle.com> Message-ID: <5314B547.9000800@oracle.com> On 03/03/2014 16:56, Erik Joelsson wrote: > It seems I failed in the below fix. /usr/bin/grep on Solaris does not > support -qE. Here is another patch, converting the regexp to work > without the -E switch and piping to /dev/null to keep it quiet: I've been seeing this lately so it's good to get it fixed. The change to drop using the extended regexp looks okay to me. -Alan From tim.bell at oracle.com Mon Mar 3 17:24:03 2014 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 03 Mar 2014 09:24:03 -0800 Subject: RFR: JDK-8036145: Solaris standard grep does not understand -qE In-Reply-To: <5314B547.9000800@oracle.com> References: <530F45DF.9010301@oracle.com> <5314B421.1010106@oracle.com> <5314B547.9000800@oracle.com> Message-ID: <5314BAB3.8040601@oracle.com> Hi Erik Looks good to me as well. Tim On 03/03/14 09:00, Alan Bateman wrote: > On 03/03/2014 16:56, Erik Joelsson wrote: >> It seems I failed in the below fix. /usr/bin/grep on Solaris does not >> support -qE. Here is another patch, converting the regexp to work >> without the -E switch and piping to /dev/null to keep it quiet: > I've been seeing this lately so it's good to get it fixed. The change > to drop using the extended regexp looks okay to me. > > -Alan From omajid at redhat.com Mon Mar 3 19:01:03 2014 From: omajid at redhat.com (Omair Majid) Date: Mon, 3 Mar 2014 14:01:03 -0500 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <53144E4D.8080606@redhat.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53144E4D.8080606@redhat.com> Message-ID: <20140303190102.GE2045@redhat.com> * Andrew Haley [2014-03-03 04:43]: > On 02/28/2014 09:18 AM, Yasumasa Suenaga wrote: > > For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo . > > libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not > > contain debug information. Actual debug information is shipped by OpenJDK > > debuginfo package. > > That's a bug in Fedora's build. We should fix it. This should fix it: http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/commit/?id=1734315551d634b7467f28788d90595b467ea5eb Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From omajid at redhat.com Mon Mar 3 19:11:18 2014 From: omajid at redhat.com (Omair Majid) Date: Mon, 3 Mar 2014 14:11:18 -0500 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <53149826.7030106@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <5311E98A.1020004@ysfactory.dip.jp> <53149826.7030106@oracle.com> Message-ID: <20140303191118.GF2045@redhat.com> Hi, * Daniel D. Daugherty [2014-03-03 09:57]: > On 3/1/14 4:08 PM, Mike Duigou wrote: > > If we can put debuginfo into external files why would we ever want unstripped binaries? > > We deliver minimal stripped binaries so that can have stack traces > with some amount of information in them when the debuginfo files > are not available. We have not yet figured out how to implement > minimal stripping on Windows so Windows hs_err_pid files have no > symbols in them when the debuginfo bundles are not present. Am I reading it right that when tools (like RPM) strip the debug information from these binaries, hotspot will break completely when it tries to generate a stack trace on crash? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From daniel.daugherty at oracle.com Mon Mar 3 19:20:38 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 03 Mar 2014 12:20:38 -0700 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <20140303191118.GF2045@redhat.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <5311E98A.1020004@ysfactory.dip.jp> <53149826.7030106@oracle.com> <20140303191118.GF2045@redhat.com> Message-ID: <5314D606.70804@oracle.com> On 3/3/14 12:11 PM, Omair Majid wrote: > Hi, > > * Daniel D. Daugherty [2014-03-03 09:57]: >> On 3/1/14 4:08 PM, Mike Duigou wrote: >>> If we can put debuginfo into external files why would we ever want unstripped binaries? >> We deliver minimal stripped binaries so that can have stack traces >> with some amount of information in them when the debuginfo files >> are not available. We have not yet figured out how to implement >> minimal stripping on Windows so Windows hs_err_pid files have no >> symbols in them when the debuginfo bundles are not present. > Am I reading it right that when tools (like RPM) strip the debug > information from these binaries, hotspot will break completely when it > tries to generate a stack trace on crash? Not quite. If you follow this process: - use gobjcopy to copy debug info from libjvm.so -> libjvm.debuginfo - use gobjcopy to tell libjvm.so that debug info is found in libjvm.debuginfo - strip libjvm.so (I don't remember the strip everything option) then you can still get symbols in your crashes as long as you have BOTH libjvm.so and libjvm.debuginfo. However, if you are in a situation where you don't have libjvm.debuginfo, then you do not get symbols in your crashes. When I did the Full Debug Symbols (FDS) project, I copied complete debug info from libjvm.so -> libjvm.debuginfo and left minimal debug info in libjvm.so so that you could still get symbols on crashes on Linux and Solaris when the libjvm.debuginfo files were not present. Dan > > Thanks, > Omair > From fw at deneb.enyo.de Mon Mar 3 21:42:37 2014 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 03 Mar 2014 22:42:37 +0100 Subject: [OpenJDK 2D-Dev] RFR: Allow using a system-installed lcms2 In-Reply-To: <20140228232443.GB18442@redhat.com> (Omair Majid's message of "Fri, 28 Feb 2014 18:24:43 -0500") References: <20140220224044.GB20217@redhat.com> <20140228212732.GG1965@redhat.com> <531101FE.2080600@oracle.com> <20140228232443.GB18442@redhat.com> Message-ID: <87k3cbhsc2.fsf@mid.deneb.enyo.de> * Omair Majid: > Basically, there is one file there (LCMS.c) that I want to make sure > that does not get compiled against the headers located in the same > directory. One way to be absolutely certain is to move the files out of > that directory into another. `#include <..>` rather than `#include > "..."` might also be sufficient but seems less of a guarantee > (especially because then I have to filter things so the compiler > invocation only includes LCMS.c and not the bundled lcms code). It seems > the patch would be more complex (from a Makefile point) to test. As some sort of gross hack, you could copy the file during the build process to a clean directory. From omajid at redhat.com Mon Mar 3 21:49:24 2014 From: omajid at redhat.com (Omair Majid) Date: Mon, 3 Mar 2014 16:49:24 -0500 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <53112019.9050504@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> Message-ID: <20140303214923.GA26825@redhat.com> * David Holmes [2014-02-28 18:48]: > There are three pieces to all of this: > > 1. Generating debug symbols in the binaries (via gcc -g or whatever) > 2. Generating debuginfo files (zipped or not) (FDS) > 3. Stripping debug symbols from the binaries (strip-policy) > > It may be that we don't have clean separation between them, and if so > that should be fixed, but I don't see the current proposal as the way > forward. Any chance we could clean up the names too? It's not obvious to me why FDS means 'generating debuginfo files'. What do folks think of modifying the OPENJDK build to use this as the settings for the options above by default. 1. Yes 2. No 3. No > Also there may well be differences between how things are handled on the > JDK side and hotspot side. Is there any chance of this becoming consistent between hotspot and JDK? It would be much nicer if concepts like strip-policy were consistent between hotspot and the rest of the JDK. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From medi.montaseri at hds.com Mon Mar 3 22:41:51 2014 From: medi.montaseri at hds.com (Medi Montaseri) Date: Mon, 3 Mar 2014 22:41:51 +0000 Subject: where is TimeZone bits Message-ID: <923F21021934C74299CD42CCCD265DA1013CBB9D@USINDEM101.corp.hds.com> Hi, Not sure if this is the correct forum.... I have installed openJDK8 on a Debian linux. I was comparing my new JRE with an older version (openjdk6) and I see that I don't have bunch of timezone files. Here is the old one ./jre/lib/zi/CST6CDT ./jre/lib/zi/SystemV/ ./jre/lib/zi/SystemV/PST8PDT ./jre/lib/zi/SystemV/AST4 etc, etc I read something about Sun no longer including tzupdator and timezone files....what is OpenJDK's position on this issue? If openjdk8 does not include TimeZone, how do I incorporate them into my JRE and JDK? Is there another upstream maintainer of TZs? thanks Medi From martinrb at google.com Mon Mar 3 23:36:06 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 3 Mar 2014 15:36:06 -0800 Subject: where is TimeZone bits In-Reply-To: <923F21021934C74299CD42CCCD265DA1013CBB9D@USINDEM101.corp.hds.com> References: <923F21021934C74299CD42CCCD265DA1013CBB9D@USINDEM101.corp.hds.com> Message-ID: A difference between IcedTea and Oracle JDK. E.g. http://icedtea.classpath.org/wiki/IcedTea_JDK6_Patches use-system-tzdata Use timezone data from the system . $ ./configure --help --with-tzdata-dir[=DIR] set the Java timezone data directory [DIR=/usr/share/javazi] On Mon, Mar 3, 2014 at 2:41 PM, Medi Montaseri wrote: > Hi, > > Not sure if this is the correct forum.... > I have installed openJDK8 on a Debian linux. I was comparing my new JRE > with an older version (openjdk6) and I see that I don't have bunch of > timezone files. > > Here is the old one > > ./jre/lib/zi/CST6CDT > ./jre/lib/zi/SystemV/ > ./jre/lib/zi/SystemV/PST8PDT > ./jre/lib/zi/SystemV/AST4 > etc, etc > > I read something about Sun no longer including tzupdator and timezone > files....what is OpenJDK's position on this issue? If openjdk8 does not > include TimeZone, how do I incorporate them into my JRE and JDK? Is there > another upstream maintainer of TZs? > > thanks > Medi > > From medi.montaseri at hds.com Tue Mar 4 00:49:03 2014 From: medi.montaseri at hds.com (Medi Montaseri) Date: Tue, 4 Mar 2014 00:49:03 +0000 Subject: where is TimeZone bits In-Reply-To: References: <923F21021934C74299CD42CCCD265DA1013CBB9D@USINDEM101.corp.hds.com>, Message-ID: <923F21021934C74299CD42CCCD265DA1013CBBE8@USINDEM101.corp.hds.com> Thanks Martin, Unfortunately I don't see that option ... mmontaseri at griffin:~/work/bug-91383/jdk8src> bash ./configure --help | grep tzdata mmontaseri at griffin:~/work/bug-91383/jdk8src> Can you please clarify? And what would that option do? would it integrate (bundle, pull-in, copy) system-tzdata files and put them along the JRE tar. I personally don't think a language should be that tightly coupled with an asset like timezone. JDK/JRE and tzdata have two different life cycles and charter. Thanks Medi ________________________________ From: Martin Buchholz [martinrb at google.com] Sent: Monday, March 03, 2014 3:36 PM To: Medi Montaseri Cc: build-dev at openjdk.java.net Subject: Re: where is TimeZone bits A difference between IcedTea and Oracle JDK. E.g. http://icedtea.classpath.org/wiki/IcedTea_JDK6_Patches use-system-tzdata Use timezone data from the system . $ ./configure --help --with-tzdata-dir[=DIR] set the Java timezone data directory [DIR=/usr/share/javazi] On Mon, Mar 3, 2014 at 2:41 PM, Medi Montaseri > wrote: Hi, Not sure if this is the correct forum.... I have installed openJDK8 on a Debian linux. I was comparing my new JRE with an older version (openjdk6) and I see that I don't have bunch of timezone files. Here is the old one ./jre/lib/zi/CST6CDT ./jre/lib/zi/SystemV/ ./jre/lib/zi/SystemV/PST8PDT ./jre/lib/zi/SystemV/AST4 etc, etc I read something about Sun no longer including tzupdator and timezone files....what is OpenJDK's position on this issue? If openjdk8 does not include TimeZone, how do I incorporate them into my JRE and JDK? Is there another upstream maintainer of TZs? thanks Medi From martinrb at google.com Tue Mar 4 00:56:59 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 3 Mar 2014 16:56:59 -0800 Subject: where is TimeZone bits In-Reply-To: <923F21021934C74299CD42CCCD265DA1013CBBE8@USINDEM101.corp.hds.com> References: <923F21021934C74299CD42CCCD265DA1013CBB9D@USINDEM101.corp.hds.com> <923F21021934C74299CD42CCCD265DA1013CBBE8@USINDEM101.corp.hds.com> Message-ID: It's an icedtea feature, not part of openjdk (although probably it should be... it seems you agree ...) (hg clone http://icedtea.classpath.org/hg/release/icedtea7-2.4/ /tmp/t9 && cd /tmp/t9 && ./autogen.sh && bash ./configure --help |& grep -2 tz) On Mon, Mar 3, 2014 at 4:49 PM, Medi Montaseri wrote: > Thanks Martin, > > Unfortunately I don't see that option ... > > mmontaseri at griffin:~/work/bug-91383/jdk8src> bash ./configure --help | > grep tzdata > mmontaseri at griffin:~/work/bug-91383/jdk8src> > > Can you please clarify? And what would that option do? would it integrate > (bundle, pull-in, copy) system-tzdata files and put them along the JRE tar. > I personally don't think a language should be that tightly coupled with an > asset like timezone. JDK/JRE and tzdata have two different life cycles and > charter. > > > Thanks > Medi > > ------------------------------ > *From:* Martin Buchholz [martinrb at google.com] > *Sent:* Monday, March 03, 2014 3:36 PM > *To:* Medi Montaseri > *Cc:* build-dev at openjdk.java.net > *Subject:* Re: where is TimeZone bits > > A difference between IcedTea and Oracle JDK. E.g. > http://icedtea.classpath.org/wiki/IcedTea_JDK6_Patches > > use-system-tzdata Use timezone data from the system . > > $ ./configure --help > --with-tzdata-dir[=DIR] set the Java timezone data directory > [DIR=/usr/share/javazi] > > > > On Mon, Mar 3, 2014 at 2:41 PM, Medi Montaseri wrote: > >> Hi, >> >> Not sure if this is the correct forum.... >> I have installed openJDK8 on a Debian linux. I was comparing my new JRE >> with an older version (openjdk6) and I see that I don't have bunch of >> timezone files. >> >> Here is the old one >> >> ./jre/lib/zi/CST6CDT >> ./jre/lib/zi/SystemV/ >> ./jre/lib/zi/SystemV/PST8PDT >> ./jre/lib/zi/SystemV/AST4 >> etc, etc >> >> I read something about Sun no longer including tzupdator and timezone >> files....what is OpenJDK's position on this issue? If openjdk8 does not >> include TimeZone, how do I incorporate them into my JRE and JDK? Is there >> another upstream maintainer of TZs? >> >> thanks >> Medi >> >> > From sean.coffey at oracle.com Tue Mar 4 01:13:50 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Mon, 03 Mar 2014 17:13:50 -0800 Subject: where is TimeZone bits In-Reply-To: References: <923F21021934C74299CD42CCCD265DA1013CBB9D@USINDEM101.corp.hds.com> Message-ID: <531528CE.1090101@oracle.com> JDK 8 does continue to ship with tzdata info built into it. The structure changed significantly with the introduction of JSR 310. The lib/zi directory has been replaced with one lib/tzdb.dat file which contains the tzdata rules in compiled format. You can always add the latest tzdata to the jdk/make/data/tzdata/ directory and rebuild for latest rules. regards, Sean. On 03/03/14 15:36, Martin Buchholz wrote: > A difference between IcedTea and Oracle JDK. E.g. > http://icedtea.classpath.org/wiki/IcedTea_JDK6_Patches > > use-system-tzdata Use timezone data from the system . > > $ ./configure --help > --with-tzdata-dir[=DIR] set the Java timezone data directory > [DIR=/usr/share/javazi] > > > > On Mon, Mar 3, 2014 at 2:41 PM, Medi Montaseri wrote: > >> Hi, >> >> Not sure if this is the correct forum.... >> I have installed openJDK8 on a Debian linux. I was comparing my new JRE >> with an older version (openjdk6) and I see that I don't have bunch of >> timezone files. >> >> Here is the old one >> >> ./jre/lib/zi/CST6CDT >> ./jre/lib/zi/SystemV/ >> ./jre/lib/zi/SystemV/PST8PDT >> ./jre/lib/zi/SystemV/AST4 >> etc, etc >> >> I read something about Sun no longer including tzupdator and timezone >> files....what is OpenJDK's position on this issue? If openjdk8 does not >> include TimeZone, how do I incorporate them into my JRE and JDK? Is there >> another upstream maintainer of TZs? >> >> thanks >> Medi >> >> From medi.montaseri at hds.com Tue Mar 4 01:45:32 2014 From: medi.montaseri at hds.com (Medi Montaseri) Date: Tue, 4 Mar 2014 01:45:32 +0000 Subject: where is TimeZone bits In-Reply-To: <531528CE.1090101@oracle.com> References: <923F21021934C74299CD42CCCD265DA1013CBB9D@USINDEM101.corp.hds.com> , <531528CE.1090101@oracle.com> Message-ID: <923F21021934C74299CD42CCCD265DA1013CBC0D@USINDEM101.corp.hds.com> thanks guys... Sean's recommendation (of including latest tzdata) sound very much like Martin's -with-tzdata-dir. Any chance of seeing that option (--with-tzdata-dir) in OpenJDK8? My read from Martin's comment is that Icedtea configurator is different from openjdk configurator. Thanks Medi ________________________________ From: Se?n Coffey [sean.coffey at oracle.com] Sent: Monday, March 03, 2014 5:13 PM To: Martin Buchholz; Medi Montaseri Cc: build-dev at openjdk.java.net Subject: Re: where is TimeZone bits JDK 8 does continue to ship with tzdata info built into it. The structure changed significantly with the introduction of JSR 310. The lib/zi directory has been replaced with one lib/tzdb.dat file which contains the tzdata rules in compiled format. You can always add the latest tzdata to the jdk/make/data/tzdata/ directory and rebuild for latest rules. regards, Sean. On 03/03/14 15:36, Martin Buchholz wrote: A difference between IcedTea and Oracle JDK. E.g. http://icedtea.classpath.org/wiki/IcedTea_JDK6_Patches use-system-tzdata Use timezone data from the system . $ ./configure --help --with-tzdata-dir[=DIR] set the Java timezone data directory [DIR=/usr/share/javazi] On Mon, Mar 3, 2014 at 2:41 PM, Medi Montaseri wrote: Hi, Not sure if this is the correct forum.... I have installed openJDK8 on a Debian linux. I was comparing my new JRE with an older version (openjdk6) and I see that I don't have bunch of timezone files. Here is the old one ./jre/lib/zi/CST6CDT ./jre/lib/zi/SystemV/ ./jre/lib/zi/SystemV/PST8PDT ./jre/lib/zi/SystemV/AST4 etc, etc I read something about Sun no longer including tzupdator and timezone files....what is OpenJDK's position on this issue? If openjdk8 does not include TimeZone, how do I incorporate them into my JRE and JDK? Is there another upstream maintainer of TZs? thanks Medi From david.katleman at oracle.com Tue Mar 4 02:57:07 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 04 Mar 2014 02:57:07 +0000 Subject: hg: jdk8/build/corba: 2 new changesets Message-ID: <20140304025708.9560462487@hg.openjdk.java.net> Changeset: 5e5c8f0c45dd Author: katleman Date: 2014-02-28 10:05 -0800 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/5e5c8f0c45dd Added tag jdk8-b130 for changeset 0683ee308085 ! .hgtags Changeset: 84fed37bbe64 Author: katleman Date: 2014-02-28 13:36 -0800 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/84fed37bbe64 Added tag jdk8-b131 for changeset 5e5c8f0c45dd ! .hgtags From david.katleman at oracle.com Tue Mar 4 02:58:24 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 04 Mar 2014 02:58:24 +0000 Subject: hg: jdk8/build/hotspot: 6 new changesets Message-ID: <20140304025840.9F52462488@hg.openjdk.java.net> Changeset: b5e7ebfe185c Author: katleman Date: 2014-02-28 10:06 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b5e7ebfe185c Added tag jdk8-b130 for changeset 1dbaf664a611 ! .hgtags Changeset: 5380dc5d007e Author: katleman Date: 2014-02-28 13:36 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5380dc5d007e Added tag jdk8-b131 for changeset b5e7ebfe185c ! .hgtags Changeset: 54f0c207dc35 Author: amurillo Date: 2014-01-28 15:11 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/54f0c207dc35 8032984: new hotspot build - hs25-b70 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e46f2ee62e78 Author: vlivanov Date: 2014-03-03 16:10 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e46f2ee62e78 8036100: Default method returns true for a while, and then returns false Reviewed-by: kvn, jrose ! src/share/vm/ci/ciMethod.cpp + test/compiler/inlining/InlineDefaultMethod1.java Changeset: 9f9179e8f0cf Author: amurillo Date: 2014-03-03 17:48 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9f9179e8f0cf Merge Changeset: 0c94c41dcd70 Author: amurillo Date: 2014-03-03 17:48 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/0c94c41dcd70 Added tag hs25-b70 for changeset 9f9179e8f0cf ! .hgtags From daniel.daugherty at oracle.com Tue Mar 4 03:02:34 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 03 Mar 2014 20:02:34 -0700 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <20140303214923.GA26825@redhat.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> Message-ID: <5315424A.4080201@oracle.com> On 3/3/14 2:49 PM, Omair Majid wrote: > * David Holmes [2014-02-28 18:48]: >> There are three pieces to all of this: >> >> 1. Generating debug symbols in the binaries (via gcc -g or whatever) >> 2. Generating debuginfo files (zipped or not) (FDS) >> 3. Stripping debug symbols from the binaries (strip-policy) >> >> It may be that we don't have clean separation between them, and if so >> that should be fixed, but I don't see the current proposal as the way >> forward. > Any chance we could clean up the names too? It's not obvious to me why > FDS means 'generating debuginfo files'. FDS stands for Full Debug Symbols and is defined that way in quite a few Makefiles... We just call it FDS for short... > What do folks think of modifying the OPENJDK build to use this as the > settings for the options above by default. > > 1. Yes > 2. No > 3. No Whatever we do here has be architecturallyconsistent across the various OpenJDK platforms. The above settings would not work well on non-Linux platforms so I'm not in favor of doing that. However, I don't have a problem with providing support for config'ing a build to work with the downstream Linux repos... >> Also there may well be differences between how things are handled on the >> JDK side and hotspot side. > Is there any chance of this becoming consistent between hotspot and JDK? > It would be much nicer if concepts like strip-policy were consistent > between hotspot and the rest of the JDK. When I did the Full Debug Symbols (FDS) project, I made it architecturally consistent between the HotSpot and JDK sides. Since the new build system has arrived, something of the consistency has been broken and I haven't been back on the JDK side to see what happened... Dan > > Thanks, > Omair > From david.katleman at oracle.com Tue Mar 4 03:03:32 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 04 Mar 2014 03:03:32 +0000 Subject: hg: jdk8/build/jaxp: 2 new changesets Message-ID: <20140304030341.5AD6962489@hg.openjdk.java.net> Changeset: 79d8b7fac21d Author: katleman Date: 2014-02-28 10:06 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/79d8b7fac21d Added tag jdk8-b130 for changeset 0cb0cd015218 ! .hgtags Changeset: 5993346020d1 Author: katleman Date: 2014-02-28 13:36 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/5993346020d1 Added tag jdk8-b131 for changeset 79d8b7fac21d ! .hgtags From david.katleman at oracle.com Tue Mar 4 03:04:05 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 04 Mar 2014 03:04:05 +0000 Subject: hg: jdk8/build/jaxws: 2 new changesets Message-ID: <20140304030414.3443D6248A@hg.openjdk.java.net> Changeset: 012b935707fa Author: katleman Date: 2014-02-28 10:06 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/012b935707fa Added tag jdk8-b130 for changeset 4195c0956930 ! .hgtags Changeset: c2be0dd15dbf Author: katleman Date: 2014-02-28 13:36 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/c2be0dd15dbf Added tag jdk8-b131 for changeset 012b935707fa ! .hgtags From david.katleman at oracle.com Tue Mar 4 03:04:53 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 04 Mar 2014 03:04:53 +0000 Subject: hg: jdk8/build/jdk: 4 new changesets Message-ID: <20140304030615.47BA16248B@hg.openjdk.java.net> Changeset: b07a8059dc08 Author: katleman Date: 2014-02-28 10:07 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b07a8059dc08 Added tag jdk8-b130 for changeset 43386cc9a017 ! .hgtags Changeset: 183a8c520b4a Author: rfield Date: 2014-02-28 10:43 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/183a8c520b4a 8035777: Consistent Lambda construction Reviewed-by: ahgross, briangoetz, dlsmith ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java + test/java/lang/invoke/lambda/LambdaReceiver.java + test/java/lang/invoke/lambda/LambdaReceiverBridge.java + test/java/lang/invoke/lambda/LambdaReceiver_anotherpkg/LambdaReceiver_A.java + test/java/lang/invoke/lambda/LambdaReturn.java + test/java/lang/invoke/lambda/MetafactoryArityTest.java + test/java/lang/invoke/lambda/MetafactoryParameterCastTest.java + test/java/lang/invoke/lambda/MetafactorySamReturnTest.java Changeset: e291ac47c9a9 Author: lana Date: 2014-02-28 11:51 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e291ac47c9a9 Merge Changeset: 43cb25339b55 Author: katleman Date: 2014-02-28 13:36 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/43cb25339b55 Added tag jdk8-b131 for changeset e291ac47c9a9 ! .hgtags From david.katleman at oracle.com Tue Mar 4 03:08:44 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 04 Mar 2014 03:08:44 +0000 Subject: hg: jdk8/build/langtools: 2 new changesets Message-ID: <20140304030852.AF40C6248D@hg.openjdk.java.net> Changeset: 196ab3dcbd28 Author: katleman Date: 2014-02-28 10:08 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/196ab3dcbd28 Added tag jdk8-b130 for changeset 9d81ae1c417a ! .hgtags Changeset: c8a87a58eb3e Author: katleman Date: 2014-02-28 13:37 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/c8a87a58eb3e Added tag jdk8-b131 for changeset 196ab3dcbd28 ! .hgtags From david.katleman at oracle.com Tue Mar 4 03:09:03 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 04 Mar 2014 03:09:03 +0000 Subject: hg: jdk8/build/nashorn: 2 new changesets Message-ID: <20140304030905.BB3646248E@hg.openjdk.java.net> Changeset: cca9748cfec7 Author: katleman Date: 2014-02-28 10:09 -0800 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/cca9748cfec7 Added tag jdk8-b130 for changeset f87eba70e9ee ! .hgtags Changeset: 5dbdae28a6f3 Author: katleman Date: 2014-02-28 13:37 -0800 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/5dbdae28a6f3 Added tag jdk8-b131 for changeset cca9748cfec7 ! .hgtags From david.katleman at oracle.com Tue Mar 4 02:56:57 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 04 Mar 2014 02:56:57 +0000 Subject: hg: jdk8/build: 2 new changesets Message-ID: <20140304025657.B0FE562485@hg.openjdk.java.net> Changeset: 0c38dfecab2a Author: katleman Date: 2014-02-28 10:05 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/0c38dfecab2a Added tag jdk8-b130 for changeset 839546caab12 ! .hgtags Changeset: 2a8f4c022aa0 Author: katleman Date: 2014-02-28 13:35 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/2a8f4c022aa0 Added tag jdk8-b131 for changeset 0c38dfecab2a ! .hgtags From erik.joelsson at oracle.com Tue Mar 4 09:31:36 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 04 Mar 2014 10:31:36 +0100 Subject: RFR: JDK-8019729: JDK build HIGHEST compiler optimisation setting isn't valid for Sun C++ compiler Message-ID: <53159D78.9020009@oracle.com> Hello, The compiler flag "-xalias_level=basic" is not valid for the Solaris Studio C++ compiler on Solaris, but is currently set for both C and C++ highest optimization flags. Since there are currently no C++ libraries using the highest setting on Solaris, we should just remove the flag for C++. Bug: https://bugs.openjdk.java.net/browse/JDK-8019729 Patch inline: diff --git a/common/autoconf/flags.m4 b/common/autoconf/flags.m4 --- a/common/autoconf/flags.m4 +++ b/common/autoconf/flags.m4 @@ -272,11 +272,11 @@ # Optimization levels if test "x$TOOLCHAIN_TYPE" = xsolstudio; then - CC_HIGHEST="$CC_HIGHEST -fns -fsimple -fsingle -xalias_level=basic -xbuiltin=%all -xdepend -xrestrict -xlibmil" + CC_HIGHEST="$CC_HIGHEST -fns -fsimple -fsingle -xbuiltin=%all -xdepend -xrestrict -xlibmil" if test "x$OPENJDK_TARGET_CPU_ARCH" = "xx86"; then # FIXME: seems we always set -xregs=no%frameptr; put it elsewhere more global? - C_O_FLAG_HIGHEST="-xO4 -Wu,-O4~yz $CC_HIGHEST -xregs=no%frameptr" + C_O_FLAG_HIGHEST="-xO4 -Wu,-O4~yz $CC_HIGHEST -xalias_level=basic -xregs=no%frameptr" C_O_FLAG_HI="-xO4 -Wu,-O4~yz -xregs=no%frameptr" C_O_FLAG_NORM="-xO2 -Wu,-O2~yz -xregs=no%frameptr" C_O_FLAG_NONE="-xregs=no%frameptr" @@ -289,7 +289,7 @@ CXX_O_FLAG_HIGHEST="$CXX_O_FLAG_HIGHEST -xchip=pentium" fi elif test "x$OPENJDK_TARGET_CPU_ARCH" = "xsparc"; then - C_O_FLAG_HIGHEST="-xO4 -Wc,-Qrm-s -Wc,-Qiselect-T0 $CC_HIGHEST -xprefetch=auto,explicit -xchip=ultra" + C_O_FLAG_HIGHEST="-xO4 -Wc,-Qrm-s -Wc,-Qiselect-T0 $CC_HIGHEST -xalias_level=basic -xprefetch=auto,explicit -xchip=ultra" C_O_FLAG_HI="-xO4 -Wc,-Qrm-s -Wc,-Qiselect-T0" C_O_FLAG_NORM="-xO2 -Wc,-Qrm-s -Wc,-Qiselect-T0" C_O_FLAG_NONE="" /Erik From eda at netbeans.org Tue Mar 4 10:57:45 2014 From: eda at netbeans.org (Eda) Date: Tue, 04 Mar 2014 10:57:45 +0000 Subject: boot JDK not recognized for building JDK8 Message-ID: <1393930665.13740.90337445.22803B42@webmail.messagingengine.com> Versions: tip of JDK8 from Mercurial Debian GNU/Linux unstable/sid OpenJDK 7 with javac 1.7.0_51 installed from distribution package. javac is in the execution PATH. The configure fails with a message that it does not find the JDK. Then running by: Path/To/configure --with-boot-jdk /usr/lib/jvm/java-7-openjdk-amd64 produces: Invalid configuration `/usr/lib/jvm/java-7-openjdk-amd64': machine `/usr/lib/jvm/java-7-openjdk' not recognized I searched https://bugs.openjdk.java.net and found nothing. What knowledge or suggestions do you have? -- http://www.fastmail.fm - Email service worth paying for. Try it for free From weijun.wang at oracle.com Tue Mar 4 11:13:34 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 4 Mar 2014 19:13:34 +0800 Subject: boot JDK not recognized for building JDK8 In-Reply-To: <1393930665.13740.90337445.22803B42@webmail.messagingengine.com> References: <1393930665.13740.90337445.22803B42@webmail.messagingengine.com> Message-ID: You should add a "=", like this --with-boot-jdk=/.... HTH --Max On Mar 4, 2014, at 18:57, Eda wrote: > Versions: > tip of JDK8 from Mercurial > Debian GNU/Linux unstable/sid > OpenJDK 7 with javac 1.7.0_51 installed from distribution package. javac is in the execution PATH. > > The configure fails with a message that it does not find the JDK. > Then running by: > Path/To/configure --with-boot-jdk /usr/lib/jvm/java-7-openjdk-amd64 > produces: > Invalid configuration `/usr/lib/jvm/java-7-openjdk-amd64': machine `/usr/lib/jvm/java-7-openjdk' not recognized > > I searched https://bugs.openjdk.java.net and found nothing. > What knowledge or suggestions do you have? > > -- > http://www.fastmail.fm - Email service worth paying for. Try it for free > From dpointo8 at linux.vnet.ibm.com Tue Mar 4 12:03:50 2014 From: dpointo8 at linux.vnet.ibm.com (Dave Pointon) Date: Tue, 04 Mar 2014 12:03:50 +0000 Subject: RFR: JDK-8036145: Solaris standard grep does not understand -qE In-Reply-To: <5314B421.1010106@oracle.com> References: <530F45DF.9010301@oracle.com> <5314B421.1010106@oracle.com> Message-ID: <1393934630.4127.4.camel@dpointo8-ThinkPad-T400> Hi Eric , On Mon, 2014-03-03 at 17:56 +0100, Erik Joelsson wrote: > It seems I failed in the below fix. /usr/bin/grep on Solaris does not > support -qE. Here is another patch, converting the regexp to work > without the -E switch and piping to /dev/null to keep it quiet: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8036145 > > diff --git a/common/autoconf/configure b/common/autoconf/configure > --- a/common/autoconf/configure > +++ b/common/autoconf/configure > @@ -127,11 +127,11 @@ > if [[ -n "$1" ]]; then > # Uses only shell-safe characters? No quoting needed. > # '=' is a zsh meta-character, but only in word-initial position. > - if echo "$1" | grep -qE > '^[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789.:,%/+=_-]+$' > \ > - && ! echo "$1" | grep -qE '^='; then > + if echo "$1" | grep > '^[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789\.:,%/+=_-]\{1,\}$' > > /dev/null \ > + && ! echo "$1" | grep '^=' > /dev/null; then > quoted="$1" > else > - if echo "$1" | grep -qE "[\'!]"; then > + if echo "$1" | grep "[\'!]" > /dev/null; then > # csh does history expansion within single quotes, but not > # when backslash-escaped! > local quoted_quote="'\\''" quoted_exclam="'\\!'" > > /Erik > Looks good, altho' I'd question the use of the '-E' switch/option anyway - there appears to be nothing that requires the use of extended RE's (which is what -E enables). Rgds , -- Dave Pointon FIAP MBCS Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we we judge rightly of our strength to go thro' with it - Robinson Crusoe From erik.joelsson at oracle.com Tue Mar 4 15:49:01 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 04 Mar 2014 16:49:01 +0100 Subject: RFR: JDK-8036611: Cleanup of handling of properties and other java resources in the build Message-ID: <5315F5ED.5090706@oracle.com> Hello, Here is a rather big patch that mainly cleans up build logic for properties files and other java resources. For a complete list of what was done, please see the bug. Bug: https://bugs.openjdk.java.net/browse/JDK-8036611 Webrev: http://cr.openjdk.java.net/~erikj/8036611/webrev.01/ /Erik From tim.bell at oracle.com Tue Mar 4 16:14:38 2014 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 04 Mar 2014 08:14:38 -0800 Subject: RFR: JDK-8019729: JDK build HIGHEST compiler optimisation setting isn't valid for Sun C++ compiler In-Reply-To: <53159D78.9020009@oracle.com> References: <53159D78.9020009@oracle.com> Message-ID: <5315FBEE.1010107@oracle.com> Hi Erik: > The compiler flag "-xalias_level=basic" is not valid for the Solaris > Studio C++ compiler on Solaris, but is currently set for both C and > C++ highest optimization flags. Since there are currently no C++ > libraries using the highest setting on Solaris, we should just remove > the flag for C++. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8019729 Looks good to me. /Tim > Patch inline: > > diff --git a/common/autoconf/flags.m4 b/common/autoconf/flags.m4 > --- a/common/autoconf/flags.m4 > +++ b/common/autoconf/flags.m4 > @@ -272,11 +272,11 @@ > > # Optimization levels > if test "x$TOOLCHAIN_TYPE" = xsolstudio; then > - CC_HIGHEST="$CC_HIGHEST -fns -fsimple -fsingle > -xalias_level=basic -xbuiltin=%all -xdepend -xrestrict -xlibmil" > + CC_HIGHEST="$CC_HIGHEST -fns -fsimple -fsingle -xbuiltin=%all > -xdepend -xrestrict -xlibmil" > > if test "x$OPENJDK_TARGET_CPU_ARCH" = "xx86"; then > # FIXME: seems we always set -xregs=no%frameptr; put it > elsewhere more global? > - C_O_FLAG_HIGHEST="-xO4 -Wu,-O4~yz $CC_HIGHEST -xregs=no%frameptr" > + C_O_FLAG_HIGHEST="-xO4 -Wu,-O4~yz $CC_HIGHEST > -xalias_level=basic -xregs=no%frameptr" > C_O_FLAG_HI="-xO4 -Wu,-O4~yz -xregs=no%frameptr" > C_O_FLAG_NORM="-xO2 -Wu,-O2~yz -xregs=no%frameptr" > C_O_FLAG_NONE="-xregs=no%frameptr" > @@ -289,7 +289,7 @@ > CXX_O_FLAG_HIGHEST="$CXX_O_FLAG_HIGHEST -xchip=pentium" > fi > elif test "x$OPENJDK_TARGET_CPU_ARCH" = "xsparc"; then > - C_O_FLAG_HIGHEST="-xO4 -Wc,-Qrm-s -Wc,-Qiselect-T0 $CC_HIGHEST > -xprefetch=auto,explicit -xchip=ultra" > + C_O_FLAG_HIGHEST="-xO4 -Wc,-Qrm-s -Wc,-Qiselect-T0 $CC_HIGHEST > -xalias_level=basic -xprefetch=auto,explicit -xchip=ultra" > C_O_FLAG_HI="-xO4 -Wc,-Qrm-s -Wc,-Qiselect-T0" > C_O_FLAG_NORM="-xO2 -Wc,-Qrm-s -Wc,-Qiselect-T0" > C_O_FLAG_NONE="" From tim.bell at oracle.com Tue Mar 4 16:49:48 2014 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 04 Mar 2014 08:49:48 -0800 Subject: RFR: JDK-8036611: Cleanup of handling of properties and other java resources in the build In-Reply-To: <5315F5ED.5090706@oracle.com> References: <5315F5ED.5090706@oracle.com> Message-ID: <5316042C.8000008@oracle.com> Hi Erik: > Here is a rather big patch that mainly cleans up build logic for > properties files and other java resources. For a complete list of what > was done, please see the bug. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8036611 > > Webrev: http://cr.openjdk.java.net/~erikj/8036611/webrev.01/ Looks good to me- /Tim From david.katleman at oracle.com Tue Mar 4 22:12:30 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 04 Mar 2014 22:12:30 +0000 Subject: hg: jdk8/build: Added tag jdk8-b132 for changeset 2a8f4c022aa0 Message-ID: <20140304221230.5861F624D2@hg.openjdk.java.net> Changeset: 1773f1fd0fac Author: katleman Date: 2014-03-04 11:50 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/1773f1fd0fac Added tag jdk8-b132 for changeset 2a8f4c022aa0 ! .hgtags From david.katleman at oracle.com Tue Mar 4 22:12:40 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 04 Mar 2014 22:12:40 +0000 Subject: hg: jdk8/build/corba: Added tag jdk8-b132 for changeset 84fed37bbe64 Message-ID: <20140304221241.85DF9624D3@hg.openjdk.java.net> Changeset: 3d96f0a5f9e2 Author: katleman Date: 2014-03-04 11:50 -0800 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/3d96f0a5f9e2 Added tag jdk8-b132 for changeset 84fed37bbe64 ! .hgtags From david.katleman at oracle.com Tue Mar 4 22:13:16 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 04 Mar 2014 22:13:16 +0000 Subject: hg: jdk8/build/hotspot: Added tag jdk8-b132 for changeset 0c94c41dcd70 Message-ID: <20140304221319.6AA6F624D4@hg.openjdk.java.net> Changeset: 87ee5ee27509 Author: katleman Date: 2014-03-04 11:51 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/87ee5ee27509 Added tag jdk8-b132 for changeset 0c94c41dcd70 ! .hgtags From david.katleman at oracle.com Tue Mar 4 22:14:46 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 04 Mar 2014 22:14:46 +0000 Subject: hg: jdk8/build/jaxp: Added tag jdk8-b132 for changeset 5993346020d1 Message-ID: <20140304221450.14E4C624D5@hg.openjdk.java.net> Changeset: 0c49f9209035 Author: katleman Date: 2014-03-04 11:51 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/0c49f9209035 Added tag jdk8-b132 for changeset 5993346020d1 ! .hgtags From david.katleman at oracle.com Tue Mar 4 22:15:01 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 04 Mar 2014 22:15:01 +0000 Subject: hg: jdk8/build/jaxws: Added tag jdk8-b132 for changeset c2be0dd15dbf Message-ID: <20140304221505.B48E3624D6@hg.openjdk.java.net> Changeset: d03dd22762db Author: katleman Date: 2014-03-04 11:51 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/d03dd22762db Added tag jdk8-b132 for changeset c2be0dd15dbf ! .hgtags From david.katleman at oracle.com Tue Mar 4 22:15:20 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 04 Mar 2014 22:15:20 +0000 Subject: hg: jdk8/build/jdk: Added tag jdk8-b132 for changeset 43cb25339b55 Message-ID: <20140304221543.D9058624D7@hg.openjdk.java.net> Changeset: 687fd7c7986d Author: katleman Date: 2014-03-04 11:51 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/687fd7c7986d Added tag jdk8-b132 for changeset 43cb25339b55 ! .hgtags From david.katleman at oracle.com Tue Mar 4 22:17:47 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 04 Mar 2014 22:17:47 +0000 Subject: hg: jdk8/build/nashorn: Added tag jdk8-b132 for changeset 5dbdae28a6f3 Message-ID: <20140304221749.C4FFB624DA@hg.openjdk.java.net> Changeset: 096dc407d310 Author: katleman Date: 2014-03-04 11:52 -0800 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/096dc407d310 Added tag jdk8-b132 for changeset 5dbdae28a6f3 ! .hgtags From david.katleman at oracle.com Tue Mar 4 22:17:19 2014 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 04 Mar 2014 22:17:19 +0000 Subject: hg: jdk8/build/langtools: Added tag jdk8-b132 for changeset c8a87a58eb3e Message-ID: <20140304221724.811D0624D8@hg.openjdk.java.net> Changeset: 1ff9d5118aae Author: katleman Date: 2014-03-04 11:52 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/1ff9d5118aae Added tag jdk8-b132 for changeset c8a87a58eb3e ! .hgtags From magnus.ihse.bursie at oracle.com Wed Mar 5 11:16:33 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 5 Mar 2014 12:16:33 +0100 Subject: RFR: JDK-8036611: Cleanup of handling of properties and other java resources in the build In-Reply-To: <5315F5ED.5090706@oracle.com> References: <5315F5ED.5090706@oracle.com> Message-ID: Hi Erik, Good work! Some comment: * In JavaCompilation.gmk: add_files_to_copy_and_clean should be named only "..to_clean", otherwise it sounds as it is handling the copy part too. This was bad even before your fix, but then nobody really used that code. Could you please fix that? I have a hard time figuring out that sed expression, including your additions. Do you mind trying to document its intentions? * In CompileCorba.gmk; The removed JAR line looks weird. Is it an webrev artifact or was it dangling like that in the original makefile? How in the world come make didn't complain about it? The copy of zh_XX is done in GensrcCorba, but the original file is created in CompileCorba. Does that really work? On a clean compile? Looks incorrect to me. * In CopyIntoClasses: Is there a reason the swingbeaninfo gif files are not stored in the corresponding source directory? (I have a vague feeling this one been up before for discussion...) I'm not clear about the handling of zh_XX files here. First, you have an install-file %-pattern rule. Then you have an COPY_EXTRA addition. Are both needed? Why? Is it to create dependencies on the copied files? Is COPY_EXTRA really ALSO_DEPEND_ON_THESE_TARGETS? Have you confirmed that the CLEAN_FILES list does not intersect with the properties files listed for compilation? * In GensrcProperties: There was a comment on us not handling removed properties correctly in incremental builds. That's still applicable, right? The zh_XX code (again): there are two pattern rules with the same target. Do we alternatively copy generated and pre-generated files from src/share/classes? What if they clash? (I'm no good at how make resolved pattern rules.) If the zh_TW file is checked in and not generated, shouldn't we check in a copy as the zh_HK file as well? In convert_tw_to_hk, what kind of sed expression is that? Never seen one of those; what does it do? /Magnus 4 mar 2014 kl. 16:49 skrev Erik Joelsson : > Hello, > > Here is a rather big patch that mainly cleans up build logic for properties files and other java resources. For a complete list of what was done, please see the bug. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8036611 > > Webrev: http://cr.openjdk.java.net/~erikj/8036611/webrev.01/ > > /Erik > From Jessica.Man at gs.com Wed Mar 5 15:41:44 2014 From: Jessica.Man at gs.com (Man, Jessica) Date: Wed, 5 Mar 2014 15:41:44 +0000 Subject: [PATCH] For OpenJDK 8 and 9 to fix build issue when --with-alsa option is used In-Reply-To: <52F4D355.7020400@oracle.com> References: <1CF6FDFD0639DF478B44651D79ECE7049EF3E3AB@GSCMHKP12EX.firmwide.corp.gs.com> <52F20FCB.703@oracle.com> <52F214F3.1040906@oracle.com> <52F4D355.7020400@oracle.com> Message-ID: Could this patch be backported to jdk8 please? Thank you. Regards, Jessica Man, Technology Goldman Sachs International Christchurch Court | 10-15 Newgate Street | London EC1A 7HD | Tel: +44 (0)20 7774 3695 The Goldman Sachs Group, Inc. All rights reserved. See http://www.gs.com/disclaimer/global_email for important risk disclosures, conflicts of interest and other terms and conditions relating to this e-mail and your reliance on information contained in it.? This message may contain confidential or privileged information.? If you are not the intended recipient, please advise us immediately and delete this message.? See http://www.gs.com/disclaimer/email for further information on confidentiality and the risks of non-secure electronic communication.? If you cannot access these links, please notify us by reply message and we will send the contents to you.? -----Original Message----- From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] Sent: 07 February 2014 12:37 To: Man, Jessica [Tech] Cc: 'build-dev at openjdk.java.net' Subject: Re: [PATCH] For OpenJDK 8 and 9 to fix build issue when --with-alsa option is used Jessica, Your patch is now committed to jdk9. Once again, thank you! /Magnus On 2014-02-05 11:44, Man, Jessica wrote: > Great, thank you Magnus. > > I have signed the OCA, http://www.oracle.com/technetwork/community/oca-486395.html#g under Goldman Sachs. > > -----Original Message----- > From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] > Sent: 05 February 2014 10:40 > To: Man, Jessica [Tech]; 'build-dev at openjdk.java.net' > Subject: Re: [PATCH] For OpenJDK 8 and 9 to fix build issue when > --with-alsa option is used > > Hi Jessica, > > The patch looks fine. Thank you for finding this issue and posting a patch! > > I believe such trivial changes can be accepted without the hassle of you signing the OCA, but I need to verify that. > > /Magnus > > On 2014-02-05 11:20, Man, Jessica wrote: >> Thank you Magnus. Here is the patch: >> >> # HG changeset patch >> # User Jessica Man # Date 1391463887 0 >> # Mon Feb 03 21:44:47 2014 +0000 >> # Node ID 7ddb4db0e9ec3ce3d924cd51d6edee5b0258adf2 >> # Parent 135f0c7af57ebace31383d8877f47e32172759ff >> Build fails if --with-alsa option is used due to incorrect ALSA link parameter in autoconf script. >> >> diff --git a/common/autoconf/libraries.m4 >> b/common/autoconf/libraries.m4 >> --- a/common/autoconf/libraries.m4 >> +++ b/common/autoconf/libraries.m4 >> @@ -554,7 +554,7 @@ >> fi >> >> if test "x${with_alsa}" != x; then >> - ALSA_LIBS="-L${with_alsa}/lib -lalsa" >> + ALSA_LIBS="-L${with_alsa}/lib -lasound" >> ALSA_CFLAGS="-I${with_alsa}/include" >> ALSA_FOUND=yes >> fi >> @@ -563,7 +563,7 @@ >> ALSA_FOUND=yes >> fi >> if test "x${with_alsa_lib}" != x; then >> - ALSA_LIBS="-L${with_alsa_lib} -lalsa" >> + ALSA_LIBS="-L${with_alsa_lib} -lasound" >> ALSA_FOUND=yes >> fi >> if test "x$ALSA_FOUND" = xno; then >> >> -----Original Message----- >> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] >> Sent: 05 February 2014 10:18 >> To: Man, Jessica [Tech]; 'build-dev at openjdk.java.net' >> Subject: Re: [PATCH] For OpenJDK 8 and 9 to fix build issue when >> --with-alsa option is used >> >> Hi Jessica, >> >> The attached patch was stripped by the mailing list server. Please paste the patch inline in the mail, or provide a link to a web site with the patch. >> >> /Magnus >> >> On 2014-02-05 11:09, Man, Jessica wrote: >>> Hi all, >>> >>> This patch is for fixing a build issue with OpenJDK autoconf files. If the --with-alsa option is used to point the build to the ALSA library from a specific directory instead of using the system default location, the JDK component will fail to build due to an incorrect -l parameter being passed to ld and result in this error: >>> >>> /usr/bin/ld: cannot find -lalsa >>> collect2: ld returned 1 exit status >>> >>> Please review and let me know if further information is needed, or if the patch should be modified in any way. Thank you. >>> >>> Regards, >>> Jessica Man, Technology >>> Goldman Sachs International >>> Christchurch Court | 10-15 Newgate Street | London EC1A 7HD | Tel: >>> +44 >>> (0)20 7774 3695 >>> >>> The Goldman Sachs Group, Inc. All rights reserved. >>> See http://www.gs.com/disclaimer/global_email for important risk disclosures, conflicts of interest and other terms and conditions relating to this e-mail and your reliance on information contained in it. This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.gs.com/disclaimer/email for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. >>> >>> >>> From henry.jen at oracle.com Thu Mar 6 00:11:04 2014 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 05 Mar 2014 16:11:04 -0800 Subject: JDK9: RFR: 8019470: Changes needed to compile JDK8 on MacOS with clang compiler In-Reply-To: <530DA490.4070208@oracle.com> References: <530DA490.4070208@oracle.com> Message-ID: <5317BD18.8030503@oracle.com> Ping! Is three any concern on this patch? I got JPRT reports no problem and other reports success. I hope we can get this in as early as we can because build is evloving quickly, and I think it only can get better after pushed for more tests. Cheers, Henry On 02/26/2014 12:23 AM, Henry Jen wrote: > Hi, > > Please review a webrev to enable XCode5 build on Mac OS X, this webrev > add basic clang flags and detect Xcode version to set default toolchain > to clang for Xcode5 and after, otherwise set to gcc for Mac OS X. > > http://cr.openjdk.java.net/~henryjen/jdk9/8019470/1/webrev/ > > This patch build on Maverick with Xcode 5, but is not yet sufficient to > enable clang build on my Arch Linux, where I installed clang 3.4. There > are some undeclare identifier|function|type warnings/errors, the cause > of which is still under investigation, my guess lies in precompile > header, but I think that can be addressed later. > > Cheers, > Henry From erik.joelsson at oracle.com Thu Mar 6 08:36:42 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 06 Mar 2014 09:36:42 +0100 Subject: JDK9: RFR: 8019470: Changes needed to compile JDK8 on MacOS with clang compiler In-Reply-To: <5317BD18.8030503@oracle.com> References: <530DA490.4070208@oracle.com> <5317BD18.8030503@oracle.com> Message-ID: <5318339A.6070508@oracle.com> Hello, I was waiting for Magnus to look at this since he is more involved in this code at the moment. I think it looks good ok, but would prefer if he got the chance to look at it too. /Erik On 2014-03-06 01:11, Henry Jen wrote: > Ping! Is three any concern on this patch? I got JPRT reports no > problem and other reports success. > > I hope we can get this in as early as we can because build is evloving > quickly, and I think it only can get better after pushed for more tests. > > Cheers, > Henry > > On 02/26/2014 12:23 AM, Henry Jen wrote: >> Hi, >> >> Please review a webrev to enable XCode5 build on Mac OS X, this webrev >> add basic clang flags and detect Xcode version to set default toolchain >> to clang for Xcode5 and after, otherwise set to gcc for Mac OS X. >> >> http://cr.openjdk.java.net/~henryjen/jdk9/8019470/1/webrev/ >> >> This patch build on Maverick with Xcode 5, but is not yet sufficient to >> enable clang build on my Arch Linux, where I installed clang 3.4. There >> are some undeclare identifier|function|type warnings/errors, the cause >> of which is still under investigation, my guess lies in precompile >> header, but I think that can be addressed later. >> >> Cheers, >> Henry From erik.joelsson at oracle.com Thu Mar 6 09:50:15 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 06 Mar 2014 10:50:15 +0100 Subject: RFR: JDK-8036611: Cleanup of handling of properties and other java resources in the build In-Reply-To: References: <5315F5ED.5090706@oracle.com> Message-ID: <531844D7.6080906@oracle.com> Thanks for the comments. Here is a new webrev: http://cr.openjdk.java.net/~erikj/8036611/webrev.02/ On 2014-03-05 12:16, Magnus Ihse Bursie wrote: > Hi Erik, > > Good work! > > Some comment: > * In JavaCompilation.gmk: > add_files_to_copy_and_clean should be named only "..to_clean", otherwise it sounds as it is handling the copy part too. This was bad even before your fix, but then nobody really used that code. Could you please fix that? Done > I have a hard time figuring out that sed expression, including your additions. Do you mind trying to document its intentions? Done > * In CompileCorba.gmk; > The removed JAR line looks weird. Is it an webrev artifact or was it dangling like that in the original makefile? How in the world come make didn't complain about it? It was unintentionally left there in my last change and this was a cleanup. It probably worked because there was no active left parentheses so the extra two right ones where just considered part of the value of the arbitrary variable "JAR". > The copy of zh_XX is done in GensrcCorba, but the original file is created in CompileCorba. Does that really work? On a clean compile? Looks incorrect to me. The original file is in the source tree and I generate the zh_HK version by copying it to gensrc. Then in CompileCorba all the properties files exist as source files for the clean. I could have opted to copy the cleaned file in CompileCorba instead but I thought this was easier. I realize it's not consistent with how it's done in the jdk repo though. > > * In CopyIntoClasses: > Is there a reason the swingbeaninfo gif files are not stored in the corresponding source directory? (I have a vague feeling this one been up before for discussion...) The rest of swingbeans is generated source so I guess it makes sense to some that the resources also be in the make/data dir. I would prefer to have them in the corresponding source dir, but would rather not take that fight now and potentially hold up this patch. > I'm not clear about the handling of zh_XX files here. First, you have an install-file %-pattern rule. Then you have an COPY_EXTRA addition. Are both needed? Why? Is it to create dependencies on the copied files? > > Is COPY_EXTRA really ALSO_DEPEND_ON_THESE_TARGETS? If you look in CompileJavaClasses.gmk, from which CopyIntoClasses.gmk is included, COPY_EXTRA is simply added to the dependency list at the end, so yes, that's what it is. A pattern rule in itself will not be very useful without some targets being depended on. > > Have you confirmed that the CLEAN_FILES list does not intersect with the properties files listed for compilation? Yes, I handled this one line at a time from the old GensrcProperties, and I've run a lot of compares on the resulting jars during this effort. > * In GensrcProperties: > > There was a comment on us not handling removed properties correctly in incremental builds. That's still applicable, right? Where was this comment? We don't handle removed files well in most cases since that's not how make normally works. Automatically removing files in the output requires keeping books on which files generated what and to have a separate remove step in the makefile. Fredrik wrote this for jar file generation so it probably works when removing java files today. If removing a C file, it will not be linked, but the object file will still be around. > > The zh_XX code (again): there are two pattern rules with the same target. Do we alternatively copy generated and pre-generated files from src/share/classes? What if they clash? (I'm no good at how make resolved pattern rules.) If the zh_TW file is checked in and not generated, shouldn't we check in a copy as the zh_HK file as well? There are some pre-generated java properties bundles in the source tree yes. I chose not to change anything regarding them. As for clashing, the first rule that matches will be used. In this case I very much doubt we will ever see a clash. > > In convert_tw_to_hk, what kind of sed expression is that? Never seen one of those; what does it do? I'm pretty sure it was just picked up from the old build. My understanding is that it searches for a line matching the regexp "class" and if found does a single search replace for "_zh_TW" to "_zh_HK" on that line. /Erik > /Magnus > > 4 mar 2014 kl. 16:49 skrev Erik Joelsson : > >> Hello, >> >> Here is a rather big patch that mainly cleans up build logic for properties files and other java resources. For a complete list of what was done, please see the bug. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8036611 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8036611/webrev.01/ >> >> /Erik >> From magnus.ihse.bursie at oracle.com Thu Mar 6 14:41:45 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 6 Mar 2014 15:41:45 +0100 Subject: RFR: JDK-8036611: Cleanup of handling of properties and other java resources in the build In-Reply-To: <531844D7.6080906@oracle.com> References: <5315F5ED.5090706@oracle.com> <531844D7.6080906@oracle.com> Message-ID: Comments inline. /Magnus > On 6 mar 2014, at 10:50, Erik Joelsson wrote: > > Thanks for the comments. > > Here is a new webrev: http://cr.openjdk.java.net/~erikj/8036611/webrev.02/ Looks good to me now! > >> On 2014-03-05 12:16, Magnus Ihse Bursie wrote: >> Hi Erik, >> >> Good work! >> >> Some comment: >> * In JavaCompilation.gmk: >> add_files_to_copy_and_clean should be named only "..to_clean", otherwise it sounds as it is handling the copy part too. This was bad even before your fix, but then nobody really used that code. Could you please fix that? > Done >> I have a hard time figuring out that sed expression, including your additions. Do you mind trying to document its intentions? > Done Thanks for both. >> * In CompileCorba.gmk; >> The removed JAR line looks weird. Is it an webrev artifact or was it dangling like that in the original makefile? How in the world come make didn't complain about it? > It was unintentionally left there in my last change and this was a cleanup. It probably worked because there was no active left parentheses so the extra two right ones where just considered part of the value of the arbitrary variable "JAR". Weird. But you're probably right. Darn that 70's syntax. :-) >> The copy of zh_XX is done in GensrcCorba, but the original file is created in CompileCorba. Does that really work? On a clean compile? Looks incorrect to me. > The original file is in the source tree and I generate the zh_HK version by copying it to gensrc. Then in CompileCorba all the properties files exist as source files for the clean. I could have opted to copy the cleaned file in CompileCorba instead but I thought this was easier. I realize it's not consistent with how it's done in the jdk repo though. Aha, I see now that you copy the properties file. I misread it as the java file. Ok. >> >> * In CopyIntoClasses: >> Is there a reason the swingbeaninfo gif files are not stored in the corresponding source directory? (I have a vague feeling this one been up before for discussion...) > The rest of swingbeans is generated source so I guess it makes sense to some that the resources also be in the make/data dir. I would prefer to have them in the corresponding source dir, but would rather not take that fight now and potentially hold up this patch. Fair enough. There's still plenty left to cleanup for everyone. :) >> I'm not clear about the handling of zh_XX files here. First, you have an install-file %-pattern rule. Then you have an COPY_EXTRA addition. Are both needed? Why? Is it to create dependencies on the copied files? >> >> Is COPY_EXTRA really ALSO_DEPEND_ON_THESE_TARGETS? > If you look in CompileJavaClasses.gmk, from which CopyIntoClasses.gmk is included, COPY_EXTRA is simply added to the dependency list at the end, so yes, that's what it is. A pattern rule in itself will not be very useful without some targets being depended on. Right. I got it confused with the COPY and CLEAN variables being passed into the macro call. >> >> Have you confirmed that the CLEAN_FILES list does not intersect with the properties files listed for compilation? > Yes, I handled this one line at a time from the old GensrcProperties, and I've run a lot of compares on the resulting jars during this effort. >> * In GensrcProperties: >> >> There was a comment on us not handling removed properties correctly in incremental builds. That's still applicable, right? > Where was this comment? We don't handle removed files well in most cases since that's not how make normally works. Automatically removing files in the output requires keeping books on which files generated what and to have a separate remove step in the makefile. Fredrik wrote this for jar file generation so it probably works when removing java files today. If removing a C file, it will not be linked, but the object file will still be around. >> >> The zh_XX code (again): there are two pattern rules with the same target. Do we alternatively copy generated and pre-generated files from src/share/classes? What if they clash? (I'm no good at how make resolved pattern rules.) If the zh_TW file is checked in and not generated, shouldn't we check in a copy as the zh_HK file as well? > There are some pre-generated java properties bundles in the source tree yes. I chose not to change anything regarding them. As for clashing, the first rule that matches will be used. In this case I very much doubt we will ever see a clash. >> >> In convert_tw_to_hk, what kind of sed expression is that? Never seen one of those; what does it do? > I'm pretty sure it was just picked up from the old build. My understanding is that it searches for a line matching the regexp "class" and if found does a single search replace for "_zh_TW" to "_zh_HK" on that line. Aha, it's a combined /class/ and s/zh_TW/zh_HK/. I see. Thought it was some fancy four-way operator. > > /Erik >> /Magnus >> >>> 4 mar 2014 kl. 16:49 skrev Erik Joelsson : >>> >>> Hello, >>> >>> Here is a rather big patch that mainly cleans up build logic for properties files and other java resources. For a complete list of what was done, please see the bug. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036611 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8036611/webrev.01/ >>> >>> /Erik > From magnus.ihse.bursie at oracle.com Thu Mar 6 14:46:48 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 6 Mar 2014 15:46:48 +0100 Subject: JDK9: RFR: 8019470: Changes needed to compile JDK8 on MacOS with clang compiler In-Reply-To: <5318339A.6070508@oracle.com> References: <530DA490.4070208@oracle.com> <5317BD18.8030503@oracle.com> <5318339A.6070508@oracle.com> Message-ID: <154F4576-B207-4F23-A195-3A19E7D83FD1@oracle.com> Looks good to me. Just one question, since clang otherwise duplicates the gcc flags: is it correct to drop -fPIC in clang? /Magnus > On 6 mar 2014, at 09:36, Erik Joelsson wrote: > > Hello, > > I was waiting for Magnus to look at this since he is more involved in this code at the moment. I think it looks good ok, but would prefer if he got the chance to look at it too. > > /Erik > >> On 2014-03-06 01:11, Henry Jen wrote: >> Ping! Is three any concern on this patch? I got JPRT reports no problem and other reports success. >> >> I hope we can get this in as early as we can because build is evloving quickly, and I think it only can get better after pushed for more tests. >> >> Cheers, >> Henry >> >>> On 02/26/2014 12:23 AM, Henry Jen wrote: >>> Hi, >>> >>> Please review a webrev to enable XCode5 build on Mac OS X, this webrev >>> add basic clang flags and detect Xcode version to set default toolchain >>> to clang for Xcode5 and after, otherwise set to gcc for Mac OS X. >>> >>> http://cr.openjdk.java.net/~henryjen/jdk9/8019470/1/webrev/ >>> >>> This patch build on Maverick with Xcode 5, but is not yet sufficient to >>> enable clang build on my Arch Linux, where I installed clang 3.4. There >>> are some undeclare identifier|function|type warnings/errors, the cause >>> of which is still under investigation, my guess lies in precompile >>> header, but I think that can be addressed later. >>> >>> Cheers, >>> Henry > From henry.jen at oracle.com Thu Mar 6 17:13:59 2014 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 06 Mar 2014 09:13:59 -0800 Subject: JDK9: RFR: 8019470: Changes needed to compile JDK8 on MacOS with clang compiler In-Reply-To: <154F4576-B207-4F23-A195-3A19E7D83FD1@oracle.com> References: <530DA490.4070208@oracle.com> <5317BD18.8030503@oracle.com> <5318339A.6070508@oracle.com> <154F4576-B207-4F23-A195-3A19E7D83FD1@oracle.com> Message-ID: <5318ACD7.8080600@oracle.com> I cannot find doc regarding to -fPIC in clang, thus I leave it empty after googled a little bit. There is a code generation option for lli, -relocation-model=pic, which seems to be default for clang[1]. [1] http://clang.llvm.org/doxygen/CodeGenOptions_8h_source.html Cheers, Henry On 03/06/2014 06:46 AM, Magnus Ihse Bursie wrote: > Looks good to me. Just one question, since clang otherwise duplicates the gcc flags: is it correct to drop -fPIC in clang? > > /Magnus > >> On 6 mar 2014, at 09:36, Erik Joelsson wrote: >> >> Hello, >> >> I was waiting for Magnus to look at this since he is more involved in this code at the moment. I think it looks good ok, but would prefer if he got the chance to look at it too. >> >> /Erik >> >>> On 2014-03-06 01:11, Henry Jen wrote: >>> Ping! Is three any concern on this patch? I got JPRT reports no problem and other reports success. >>> >>> I hope we can get this in as early as we can because build is evloving quickly, and I think it only can get better after pushed for more tests. >>> >>> Cheers, >>> Henry >>> >>>> On 02/26/2014 12:23 AM, Henry Jen wrote: >>>> Hi, >>>> >>>> Please review a webrev to enable XCode5 build on Mac OS X, this webrev >>>> add basic clang flags and detect Xcode version to set default toolchain >>>> to clang for Xcode5 and after, otherwise set to gcc for Mac OS X. >>>> >>>> http://cr.openjdk.java.net/~henryjen/jdk9/8019470/1/webrev/ >>>> >>>> This patch build on Maverick with Xcode 5, but is not yet sufficient to >>>> enable clang build on my Arch Linux, where I installed clang 3.4. There >>>> are some undeclare identifier|function|type warnings/errors, the cause >>>> of which is still under investigation, my guess lies in precompile >>>> header, but I think that can be addressed later. >>>> >>>> Cheers, >>>> Henry >> From philip.race at oracle.com Fri Mar 7 20:41:40 2014 From: philip.race at oracle.com (Phil Race) Date: Fri, 07 Mar 2014 12:41:40 -0800 Subject: jdk9 dev builds broken on all Solaris configs after fix "8036611: Cleanup of handling of properties..." Message-ID: <531A2F04.5040308@oracle.com> After the change below all my Solaris builds are failing. http://mail.openjdk.java.net/pipermail/jdk9-dev-changes/2014-March/000524.html Its failing at least on the JPRT sfbay server .. Eg :- ...build/solaris-x86_64-normal-server-release/jdk/classes/com/sun/rowset/RowSetResourceBundle_zh_HK.properties] Error 2 -phil. From philip.race at oracle.com Fri Mar 7 20:46:09 2014 From: philip.race at oracle.com (Phil Race) Date: Fri, 07 Mar 2014 12:46:09 -0800 Subject: jdk9 dev builds broken on all Solaris configs after fix "8036611: Cleanup of handling of properties..." In-Reply-To: <531A2F04.5040308@oracle.com> References: <531A2F04.5040308@oracle.com> Message-ID: <531A3011.201@oracle.com> I filed https://bugs.openjdk.java.net/browse/JDK-8036948 -phil. On 3/7/2014 12:41 PM, Phil Race wrote: > After the change below all my Solaris builds are failing. > http://mail.openjdk.java.net/pipermail/jdk9-dev-changes/2014-March/000524.html > > > Its failing at least on the JPRT sfbay server .. > Eg :- > ...build/solaris-x86_64-normal-server-release/jdk/classes/com/sun/rowset/RowSetResourceBundle_zh_HK.properties] > Error 2 From jonathan.gibbons at oracle.com Sat Mar 8 01:26:27 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 07 Mar 2014 17:26:27 -0800 Subject: jdk 8 jar file permissions Message-ID: <531A71C3.2000805@oracle.com> I'm curious, looking back over the archived builds of JDK 8, I notice that the permissions on rt.jar, tools.jar and jce.jar are curiously erratic, with various combinations of -r--r--r-- -rw-r--r-- -r-xr-xr-x Is this to be expected? -- Jon From bradford.wetmore at oracle.com Fri Mar 7 22:40:56 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 07 Mar 2014 14:40:56 -0800 Subject: Heads Up: OutOfMemoryError when building a 64-bit JDK 9 using a 32-bit bootdir. Message-ID: <531A4AF8.5040204@oracle.com> For quite some time I've been building on my Windows 7 laptop using something like this: % bash configure --enable-debug \ --with-boot-jdk=/cygdrive/d/java/bootdirs/i586/jdk1.7.0_XX As of Wed, my builds started dying in the big "compile the JDK world" javac part [1] of the jdk repo with : ---begin--- The system is out of resources. Consult the following stack trace for details. java.lang.OutOfMemoryError: Java heap space at com.sun.tools.javac.parser.UnicodeReader.getRawCharacters(UnicodeRead er.java:250) at com.sun.tools.javac.parser.JavaTokenizer.getLineMap(JavaTokenizer.jav a:763) at com.sun.tools.javac.parser.Scanner.getLineMap(Scanner.java:127) at com.sun.tools.javac.parser.JavacParser.parseCompilationUnit(JavacPars er.java:3136) at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:630) at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:667) at com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:95 5) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:854) at com.sun.tools.javac.main.Main.compile(Main.java:521) at com.sun.tools.javac.main.Main.compile(Main.java:381) at com.sun.tools.javac.main.Main.compile(Main.java:370) at com.sun.tools.javac.main.Main.compile(Main.java:361) at com.sun.tools.javac.Main.compile(Main.java:56) at com.sun.tools.javac.Main.main(Main.java:42) CompileJavaClasses.gmk:323: recipe for target `/cygdrive/d/java/ws/dev/build/win dows-x86_64-normal-server-release/jdk/classes/_the.BUILD_JDK_batch' failed make[2]: *** [/cygdrive/d/java/ws/dev/build/windows-x86_64-normal-server-release /jdk/classes/_the.BUILD_JDK_batch] Error 3 make[2]: Leaving directory `/cygdrive/d/java/ws/dev/jdk/make' BuildJdk.gmk:64: recipe for target `classes-only' failed make[1]: Leaving directory `/cygdrive/d/java/ws/dev/jdk/make' make[1]: *** [classes-only] Error 2 /cygdrive/d/java/ws/dev//make/Main.gmk:116: recipe for target `jdk-only' failed make: *** [jdk-only] Error 2 ---end--- My guess is that my build has been teetering on the edge of memory for a while, and some recent change likely pushed it over. Moving to a 64-bit bootdir took care of the problem. % bash configure --enable-debug \ --with-boot-jdk=/cygdrive/d/java/bootdirs/x64/jdk1.7.0_XX Brad [1] Build log Compiling 9634 files for BUILD_JDK (/cygdrive/d/java/ws/dev/build/windows-x86_64-normal-server-release/fixpath.exe -c \ /cygdrive/d/java/bootdirs/jdk1.7.0_51.old/bin/java \ -Xms64M -XX:ThreadStackSize=1536 \ "-Xbootclasspath/p:/cygdrive/d/java/ws/dev/build/windows-x86_64-normal-server-release/langtools/dist/interim_langtools.jar" \ -cp /cygdrive/d/java/ws/dev/build/windows-x86_64-normal-server-release/langtools/dist/interim_langtools.jar \ com.sun.tools.javac.Main -bootclasspath \ /cygdrive/d/java/ws/dev/build/windows-x86_64-normal-server-release/jdk/classes -source 8 -target 8 -encoding ascii \ -XDignore.symbol.file=true -Xlint:-unchecked,-deprecation,-overrides,\ auxiliaryclass,cast,classfile,dep-ann,divzero,empty,overloads,static,\ try,varargs -Werror -implicit:none -sourcepath \ "...deleted..." \ -d /cygdrive/d/java/ws/dev/build/windows-x86_64-normal-server-release/jdk/classes \ -h /cygdrive/d/java/ws/dev/build/windows-x86_64-normal-server-release/jdk/gensrc_headers.BUILD_JDK.tmp \ @/cygdrive/d/java/ws/dev/build/windows-x86_64-normal-server-release/jdk/classes/_the.BUILD_JDK_batch.tmp \ && /usr/bin/mv \ /cygdrive/d/java/ws/dev/build/windows-x86_64-normal-server-release/jdk/classes/_the.BUILD_JDK_batch.tmp \ /cygdrive/d/java/ws/dev/build/windows-x86_64-normal-server-release/jdk/classes/_the.BUILD_JDK_batch) From erik.joelsson at oracle.com Mon Mar 10 08:30:04 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 10 Mar 2014 09:30:04 +0100 Subject: jdk 8 jar file permissions In-Reply-To: <531A71C3.2000805@oracle.com> References: <531A71C3.2000805@oracle.com> Message-ID: <531D780C.40601@oracle.com> Does this apply to all platforms or did you look at one in particular? Did you look in the exploded archive dir or inside the bundles? /Erik On 2014-03-08 02:26, Jonathan Gibbons wrote: > I'm curious, > > looking back over the archived builds of JDK 8, I notice that the > permissions on rt.jar, tools.jar and jce.jar are curiously erratic, > with various combinations of > > -r--r--r-- > -rw-r--r-- > -r-xr-xr-x > > Is this to be expected? > > -- Jon From erik.joelsson at oracle.com Mon Mar 10 10:52:47 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 10 Mar 2014 11:52:47 +0100 Subject: RFR: JDK-8036948: Solaris builds broken by fix for 8036611: Cleanup of handling of properties ... Message-ID: <531D997F.405@oracle.com> Hello, Please review this fix for the install-file macro on Solaris. It did not work when copying a file into the same directory, which I started doing with the properties files cleanup. Bug: https://bugs.openjdk.java.net/browse/JDK-8036948 Patch inline: diff --git a/make/common/MakeBase.gmk b/make/common/MakeBase.gmk --- a/make/common/MakeBase.gmk +++ b/make/common/MakeBase.gmk @@ -380,11 +380,19 @@ # On Solaris, if the target is a symlink and exists, cp won't overwrite. # Cp has to operate in recursive mode to allow for -P flag, to preserve soft links. If the # name of the target file differs from the source file, rename after copy. + # If the source and target parent directories are the same, recursive copy doesn't work + # so we fall back on regular copy, which isn't preserving symlinks. define install-file $(MKDIR) -p $(@D) $(RM) '$@' - $(CP) -f -r -P '$<' '$(@D)' - if [ "$(@F)" != "$( Hello, Please review this simple fix which was also triggered by the properties files cleanup. On (at least) some Solaris configurations, sort fails if certain LC_xxx variables are set. The solution is to set LC_ALL=C instead of LANG=C. Bug: https://bugs.openjdk.java.net/browse/JDK-8036965 Patch inline: diff --git a/make/common/JavaCompilation.gmk b/make/common/JavaCompilation.gmk --- a/make/common/JavaCompilation.gmk +++ b/make/common/JavaCompilation.gmk @@ -364,7 +364,7 @@ | $(SED) -e '/^#/d' -e '/^$$$$/d' \ -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ -e 's/^[ \t]*//;s/[ \t]*$$$$//' \ - -e 's/\\=/=/' | LANG=C $(SORT) > $$@ + -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@ $(CHMOD) -f ug+w $$@ # And do not forget this target /Erik From henry.jen at oracle.com Mon Mar 10 15:21:14 2014 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 10 Mar 2014 08:21:14 -0700 Subject: RFR: JDK-8036965: 9-dev solaris builds failed: sort: can't read STDIN: Illegal byte sequence In-Reply-To: <531D9B1D.8050400@oracle.com> References: <531D9B1D.8050400@oracle.com> Message-ID: <531DD86A.3080107@oracle.com> Looks good. Cheers, Henry On 03/10/2014 03:59 AM, Erik Joelsson wrote: > Hello, > > Please review this simple fix which was also triggered by the properties > files cleanup. On (at least) some Solaris configurations, sort fails if > certain LC_xxx variables are set. The solution is to set LC_ALL=C > instead of LANG=C. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8036965 > > Patch inline: > > diff --git a/make/common/JavaCompilation.gmk > b/make/common/JavaCompilation.gmk > --- a/make/common/JavaCompilation.gmk > +++ b/make/common/JavaCompilation.gmk > @@ -364,7 +364,7 @@ > | $(SED) -e '/^#/d' -e '/^$$$$/d' \ > -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ > -e 's/^[ \t]*//;s/[ \t]*$$$$//' \ > - -e 's/\\=/=/' | LANG=C $(SORT) > $$@ > + -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@ > $(CHMOD) -f ug+w $$@ > > # And do not forget this target > > > /Erik From tim.bell at oracle.com Mon Mar 10 17:43:49 2014 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 10 Mar 2014 10:43:49 -0700 Subject: RFR: JDK-8036965: 9-dev solaris builds failed: sort: can't read STDIN: Illegal byte sequence In-Reply-To: <531DD86A.3080107@oracle.com> References: <531D9B1D.8050400@oracle.com> <531DD86A.3080107@oracle.com> Message-ID: <531DF9D5.2060706@oracle.com> Hi Erik Looks good to me as well. Tim On 03/10/14 08:21, Henry Jen wrote: > Looks good. > > Cheers, > Henry > > > On 03/10/2014 03:59 AM, Erik Joelsson wrote: >> Hello, >> >> Please review this simple fix which was also triggered by the properties >> files cleanup. On (at least) some Solaris configurations, sort fails if >> certain LC_xxx variables are set. The solution is to set LC_ALL=C >> instead of LANG=C. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8036965 >> >> Patch inline: >> >> diff --git a/make/common/JavaCompilation.gmk >> b/make/common/JavaCompilation.gmk >> --- a/make/common/JavaCompilation.gmk >> +++ b/make/common/JavaCompilation.gmk >> @@ -364,7 +364,7 @@ >> | $(SED) -e '/^#/d' -e '/^$$$$/d' \ >> -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ >> -e 's/^[ \t]*//;s/[ \t]*$$$$//' \ >> - -e 's/\\=/=/' | LANG=C $(SORT) > $$@ >> + -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@ >> $(CHMOD) -f ug+w $$@ >> >> # And do not forget this target >> >> >> /Erik From mike.duigou at oracle.com Mon Mar 10 23:46:20 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 10 Mar 2014 16:46:20 -0700 Subject: RFR : JDK-8032045 : (m/l) Enable compiler and linker safety switches for debug builds In-Reply-To: <530B52B1.1000501@oracle.com> References: <530B52B1.1000501@oracle.com> Message-ID: <62DEEEE3-833B-4AB0-9283-FA2CEAD2990C@oracle.com> On Feb 24 2014, at 06:09 , Magnus Ihse Bursie wrote: > Mike, > > I have only looked at toolchain.m4. > > First of all, I like the $C_O_FLAG_DEBUG logic. > > Some questions/comments: > * Have you tested the -qnoopt option on xlc? I copied it from the hotspot makefiles but have not tested it personally. > * This code and comment is not really aligned. Is the comment overly broad, or is it a mistake in C_O_FLAG_HIGHEST? > # Disable optimization > C_O_FLAG_HIGHEST="$C_O_FLAG_NORM" > C_O_FLAG_HI="$C_O_FLAG_DEBUG" > * Maybe it's worth considering to extract the duplication of "-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-all --param ssp-buffer-size=1" into a separate variable, something like CFLAGS_EXTRA_CHECKS or whatever. The same argument is also valid for the fastdebug extra switches, I think, even the amount of code duplication is not as high. Hm. Actually. In fact, from what I can tell this change will add these extra flags on all compilers, even though they are GCC only (?). So breaking out these flags into a variable, that can be set to empty if not using gcc, is probably not just a matter of style but a matter of correctness. I sort of followed this advice, see what you think of how it is now. > * I'd also have a preference for moving the "compiler supports -Og" check outside the actual flag setting. Maybe you can do the checking first and set a variable indicating the availablility of this flag, e.g. GCC_SUPPORTS_OG_FLAG, and then just check on that. The point here is that it's hard as it is to see the pattern between different optimization levels and compilers, but the more the code resembles a simple structured assignment matrix, the easier it is to see it. With checking code like this in the midst, it's easier to get lost. Done. Mike From mike.duigou at oracle.com Mon Mar 10 23:49:20 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 10 Mar 2014 16:49:20 -0700 Subject: RFR : JDK-8032045 : (m/l) Enable compiler and linker safety switches for debug builds In-Reply-To: References: Message-ID: I have updated the patch to respond to Magnus's feedback and to accommodate intervening changes to the configure and hotspot make files. https://bugs.openjdk.java.net/browse/JDK-8032045 http://cr.openjdk.java.net/~mduigou/JDK-8032045/3/webrev/ This version is, hopefully, almost ready to be pushed. Mike On Feb 20 2014, at 15:43 , Mike Duigou wrote: > Hello all; > > This issue is a followon to JDK-8030350 (https://bugs.openjdk.java.net/browse/JDK-8030350) which enhanced the compiler warnings used for compiling native code. The proposed changes principally impact the Linux platform. > > While 8030350 was focused on compiler warnings which did not impact code generation, this changeset will, for some configurations, change the native code generated and likely change performance. These proposed option changes prevent specific types of relocation table, stack and heap memory corruption in native code. Preventing these types of memory corruption may be useful for finding certain kinds of bugs though and do provide some minimal additional protections against malicious attacks. They aren't, by any means, a substitute for following appropriate secure coding guidelines. > > The rationale behind the implementation is as follows. For release builds during the initial phase of JDK 9 I would like to enable only compile time checks. This ends up being similar to the warnings in JDK-8030350. These options have no runtime impact on footprint or performance and very minimal additional compile time cost while providing value. **Release builds are not expected to see any performance or footprint change as a result of this changeset** > > For fast debug builds we can enable linker protections (relro) and static compile time bounds checks (FORTIFY_SOURCE=1). FORTIFY_SOURCE=1 might be moved to the production builds as well because it has no runtime cost or executable size cost. > > For slow debug builds we can enable full linker protection (at a potential cost in startup time), runtime bounds checks and stack protection (FORTIFY_SOURCE=2 -fprotect-stack-all). We will likely enable -fprotect-stack-strong when available in GCC 4.9 > > The basis for enabling the additional protections in debug builds is that it will help us find bugs in our native code and we aren't as concerned in debug builds with footprint and performance. Since many developers already do their personal builds in fastdebug or slowdebug mode for testing this will provide good opportunity to shake out any problems with the options while not impacting release builds. Should we find that any of the options provide significant value for their cost we can move them to fastdebug or release. If any of the options prove too costly they can be demoted or removed entirely. > > https://bugs.openjdk.java.net/browse/JDK-8032045 > http://cr.openjdk.java.net/~mduigou/JDK-8032045/2/webrev/ > > Additional to enabling the various compiler options I attempted to rationalize some of the skew between the various hotspot/make/{platform}/makefiles/gcc.make files while avoiding changing existing behaviour. I have also introduced the new -Og "optimize for debugging" option and there are now an explicit C{XX}_O_FLAG_DEBUG definitions to complement the C{XX}_O_FLAG_{DEBUG|NORM|HI|HIGHEST|NONE} optimization options. > > Thanks, > > Mike From magnus.ihse.bursie at oracle.com Tue Mar 11 10:16:31 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 11 Mar 2014 11:16:31 +0100 Subject: RFR: JDK-8036965: 9-dev solaris builds failed: sort: can't read STDIN: Illegal byte sequence In-Reply-To: <531D9B1D.8050400@oracle.com> References: <531D9B1D.8050400@oracle.com> Message-ID: <531EE27F.2090804@oracle.com> On 2014-03-10 11:59, Erik Joelsson wrote: > Hello, > > Please review this simple fix which was also triggered by the > properties files cleanup. On (at least) some Solaris configurations, > sort fails if certain LC_xxx variables are set. The solution is to set > LC_ALL=C instead of LANG=C. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8036965 > > Patch inline: > > diff --git a/make/common/JavaCompilation.gmk > b/make/common/JavaCompilation.gmk > --- a/make/common/JavaCompilation.gmk > +++ b/make/common/JavaCompilation.gmk > @@ -364,7 +364,7 @@ > | $(SED) -e '/^#/d' -e '/^$$$$/d' \ > -e :a -e '/\\$$$$/N; s/\\\n//; ta' \ > -e 's/^[ \t]*//;s/[ \t]*$$$$//' \ > - -e 's/\\=/=/' | LANG=C $(SORT) > $$@ > + -e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@ > $(CHMOD) -f ug+w $$@ > > # And do not forget this target Looks good to me. /Magnus From erik.joelsson at oracle.com Tue Mar 11 10:53:43 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 11 Mar 2014 11:53:43 +0100 Subject: RFR: JDK-8036948: Solaris builds broken by fix for 8036611: Cleanup of handling of properties ... In-Reply-To: <531D997F.405@oracle.com> References: <531D997F.405@oracle.com> Message-ID: <531EEB37.4070206@oracle.com> Here is a new version of the patch after an offline comment from Magnus. This adds a failure message for the unhandled case of trying to copy a symlink within the same directory. Verified that the error is triggered by setting it up manually. diff -r 65a66b8a998f make/common/MakeBase.gmk --- a/make/common/MakeBase.gmk +++ b/make/common/MakeBase.gmk @@ -380,11 +380,22 @@ # On Solaris, if the target is a symlink and exists, cp won't overwrite. # Cp has to operate in recursive mode to allow for -P flag, to preserve soft links. If the # name of the target file differs from the source file, rename after copy. + # If the source and target parent directories are the same, recursive copy doesn't work + # so we fall back on regular copy, which isn't preserving symlinks. define install-file $(MKDIR) -p $(@D) $(RM) '$@' - $(CP) -f -r -P '$<' '$(@D)' - if [ "$(@F)" != "$( Hello, > > Please review this fix for the install-file macro on Solaris. It did > not work when copying a file into the same directory, which I started > doing with the properties files cleanup. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8036948 > > Patch inline: > > diff --git a/make/common/MakeBase.gmk b/make/common/MakeBase.gmk > --- a/make/common/MakeBase.gmk > +++ b/make/common/MakeBase.gmk > @@ -380,11 +380,19 @@ > # On Solaris, if the target is a symlink and exists, cp won't > overwrite. > # Cp has to operate in recursive mode to allow for -P flag, to > preserve soft links. If the > # name of the target file differs from the source file, rename > after copy. > + # If the source and target parent directories are the same, > recursive copy doesn't work > + # so we fall back on regular copy, which isn't preserving symlinks. > define install-file > $(MKDIR) -p $(@D) > $(RM) '$@' > - $(CP) -f -r -P '$<' '$(@D)' > - if [ "$(@F)" != "$( + if [ "$(@D)" != "$( + $(CP) -f -r -P '$<' '$(@D)'; \ > + if [ "$(@F)" != "$( + $(MV) '$(@D)/$( + fi \ > + else \ > + $(CP) -f '$<' '$@'; \ > + fi > endef > else ifeq ($(OPENJDK_TARGET_OS),macosx) > # On mac, extended attributes sometimes creep into the source > files, which may later > From magnus.ihse.bursie at oracle.com Tue Mar 11 10:56:59 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 11 Mar 2014 11:56:59 +0100 Subject: RFR: JDK-8036948: Solaris builds broken by fix for 8036611: Cleanup of handling of properties ... In-Reply-To: <531EEB37.4070206@oracle.com> References: <531D997F.405@oracle.com> <531EEB37.4070206@oracle.com> Message-ID: <531EEBFB.5000901@oracle.com> On 2014-03-11 11:53, Erik Joelsson wrote: > Here is a new version of the patch after an offline comment from > Magnus. This adds a failure message for the unhandled case of trying > to copy a symlink within the same directory. Verified that the error > is triggered by setting it up manually. Thank you Erik. Looks good to me! /Magnus From magnus.ihse.bursie at oracle.com Tue Mar 11 12:47:15 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 11 Mar 2014 13:47:15 +0100 Subject: RFR : JDK-8032045 : (m/l) Enable compiler and linker safety switches for debug builds In-Reply-To: References: Message-ID: <531F05D3.6020008@oracle.com> On 2014-03-11 00:49, Mike Duigou wrote: > I have updated the patch to respond to Magnus's feedback and to accommodate intervening changes to the configure and hotspot make files. > > https://bugs.openjdk.java.net/browse/JDK-8032045 > http://cr.openjdk.java.net/~mduigou/JDK-8032045/3/webrev/ > > This version is, hopefully, almost ready to be pushed. I have only glanced at the hotspot build changes and can't really say anything about them. The hotspot team still owns these; I'm cc:ing them now. The top-level build changes looks fine. Thank you Mike for cleaning things up! /Magnus > > Mike > > On Feb 20 2014, at 15:43 , Mike Duigou wrote: > >> Hello all; >> >> This issue is a followon to JDK-8030350 (https://bugs.openjdk.java.net/browse/JDK-8030350) which enhanced the compiler warnings used for compiling native code. The proposed changes principally impact the Linux platform. >> >> While 8030350 was focused on compiler warnings which did not impact code generation, this changeset will, for some configurations, change the native code generated and likely change performance. These proposed option changes prevent specific types of relocation table, stack and heap memory corruption in native code. Preventing these types of memory corruption may be useful for finding certain kinds of bugs though and do provide some minimal additional protections against malicious attacks. They aren't, by any means, a substitute for following appropriate secure coding guidelines. >> >> The rationale behind the implementation is as follows. For release builds during the initial phase of JDK 9 I would like to enable only compile time checks. This ends up being similar to the warnings in JDK-8030350. These options have no runtime impact on footprint or performance and very minimal additional compile time cost while providing value. **Release builds are not expected to see any performance or footprint change as a result of this changeset** >> >> For fast debug builds we can enable linker protections (relro) and static compile time bounds checks (FORTIFY_SOURCE=1). FORTIFY_SOURCE=1 might be moved to the production builds as well because it has no runtime cost or executable size cost. >> >> For slow debug builds we can enable full linker protection (at a potential cost in startup time), runtime bounds checks and stack protection (FORTIFY_SOURCE=2 -fprotect-stack-all). We will likely enable -fprotect-stack-strong when available in GCC 4.9 >> >> The basis for enabling the additional protections in debug builds is that it will help us find bugs in our native code and we aren't as concerned in debug builds with footprint and performance. Since many developers already do their personal builds in fastdebug or slowdebug mode for testing this will provide good opportunity to shake out any problems with the options while not impacting release builds. Should we find that any of the options provide significant value for their cost we can move them to fastdebug or release. If any of the options prove too costly they can be demoted or removed entirely. >> >> https://bugs.openjdk.java.net/browse/JDK-8032045 >> http://cr.openjdk.java.net/~mduigou/JDK-8032045/2/webrev/ >> >> Additional to enabling the various compiler options I attempted to rationalize some of the skew between the various hotspot/make/{platform}/makefiles/gcc.make files while avoiding changing existing behaviour. I have also introduced the new -Og "optimize for debugging" option and there are now an explicit C{XX}_O_FLAG_DEBUG definitions to complement the C{XX}_O_FLAG_{DEBUG|NORM|HI|HIGHEST|NONE} optimization options. >> >> Thanks, >> >> Mike From vladimir.kozlov at oracle.com Tue Mar 11 21:12:37 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 11 Mar 2014 14:12:37 -0700 Subject: RFR : JDK-8032045 : (m/l) Enable compiler and linker safety switches for debug builds In-Reply-To: <531F05D3.6020008@oracle.com> References: <531F05D3.6020008@oracle.com> Message-ID: <531F7C45.30607@oracle.com> Mike, About hotspot makefiles changes. There is no DBG variant in hotspot: ifeq ($(VARIANT), DBG) We have specialized makefiles debug.make and fastdebug.make you can used for such settings. Note, normal Hotspot build (at least now) does not invoke top level make files. I would suggest to run JPRT hotspot test job (-stree . from hotspot repo). And also JDK control build with -buildenv SKIP_BOOT_CYCLE=false. Thanks, Vladimir On 3/11/14 5:47 AM, Magnus Ihse Bursie wrote: > On 2014-03-11 00:49, Mike Duigou wrote: >> I have updated the patch to respond to Magnus's feedback and to >> accommodate intervening changes to the configure and hotspot make files. >> >> https://bugs.openjdk.java.net/browse/JDK-8032045 >> http://cr.openjdk.java.net/~mduigou/JDK-8032045/3/webrev/ >> >> This version is, hopefully, almost ready to be pushed. > > I have only glanced at the hotspot build changes and can't really say > anything about them. The hotspot team still owns these; I'm cc:ing them > now. > > The top-level build changes looks fine. Thank you Mike for cleaning > things up! > > /Magnus > >> >> Mike >> >> On Feb 20 2014, at 15:43 , Mike Duigou wrote: >> >>> Hello all; >>> >>> This issue is a followon to JDK-8030350 >>> (https://bugs.openjdk.java.net/browse/JDK-8030350) which enhanced the >>> compiler warnings used for compiling native code. The proposed >>> changes principally impact the Linux platform. >>> >>> While 8030350 was focused on compiler warnings which did not impact >>> code generation, this changeset will, for some configurations, change >>> the native code generated and likely change performance. These >>> proposed option changes prevent specific types of relocation table, >>> stack and heap memory corruption in native code. Preventing these >>> types of memory corruption may be useful for finding certain kinds of >>> bugs though and do provide some minimal additional protections >>> against malicious attacks. They aren't, by any means, a substitute >>> for following appropriate secure coding guidelines. >>> >>> The rationale behind the implementation is as follows. For release >>> builds during the initial phase of JDK 9 I would like to enable only >>> compile time checks. This ends up being similar to the warnings in >>> JDK-8030350. These options have no runtime impact on footprint or >>> performance and very minimal additional compile time cost while >>> providing value. **Release builds are not expected to see any >>> performance or footprint change as a result of this changeset** >>> >>> For fast debug builds we can enable linker protections (relro) and >>> static compile time bounds checks (FORTIFY_SOURCE=1). >>> FORTIFY_SOURCE=1 might be moved to the production builds as well >>> because it has no runtime cost or executable size cost. >>> >>> For slow debug builds we can enable full linker protection (at a >>> potential cost in startup time), runtime bounds checks and stack >>> protection (FORTIFY_SOURCE=2 -fprotect-stack-all). We will likely >>> enable -fprotect-stack-strong when available in GCC 4.9 >>> >>> The basis for enabling the additional protections in debug builds is >>> that it will help us find bugs in our native code and we aren't as >>> concerned in debug builds with footprint and performance. Since many >>> developers already do their personal builds in fastdebug or slowdebug >>> mode for testing this will provide good opportunity to shake out any >>> problems with the options while not impacting release builds. Should >>> we find that any of the options provide significant value for their >>> cost we can move them to fastdebug or release. If any of the options >>> prove too costly they can be demoted or removed entirely. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8032045 >>> http://cr.openjdk.java.net/~mduigou/JDK-8032045/2/webrev/ >>> >>> Additional to enabling the various compiler options I attempted to >>> rationalize some of the skew between the various >>> hotspot/make/{platform}/makefiles/gcc.make files while avoiding >>> changing existing behaviour. I have also introduced the new -Og >>> "optimize for debugging" option and there are now an explicit >>> C{XX}_O_FLAG_DEBUG definitions to complement the >>> C{XX}_O_FLAG_{DEBUG|NORM|HI|HIGHEST|NONE} optimization options. >>> >>> Thanks, >>> >>> Mike > From david.holmes at oracle.com Wed Mar 12 09:57:28 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Mar 2014 19:57:28 +1000 Subject: RFR : JDK-8032045 : (m/l) Enable compiler and linker safety switches for debug builds In-Reply-To: <531F7C45.30607@oracle.com> References: <531F05D3.6020008@oracle.com> <531F7C45.30607@oracle.com> Message-ID: <53202F88.4030402@oracle.com> On 12/03/2014 7:12 AM, Vladimir Kozlov wrote: > Mike, > > About hotspot makefiles changes. There is no DBG variant in hotspot: > > ifeq ($(VARIANT), DBG) > > We have specialized makefiles debug.make and fastdebug.make you can used > for such settings. Though we are very inconsistent about whether things go in those files or in the compiler specific ones. You either have to put compiler conditionals in the debug/fastdebug files, or else debug/fastdebug conditionals in the compiler .make files. > Note, normal Hotspot build (at least now) does not invoke top level make > files. What are you referring to? A "normal" hotspot build starts with make/Makefile. A developer on platform X may kick of a build using make/X/Makefile (though we need to wean them off that). A top-level configure-based build will also use make/Makefile. David > I would suggest to run JPRT hotspot test job (-stree . from hotspot > repo). And also JDK control build with -buildenv SKIP_BOOT_CYCLE=false. > > Thanks, > Vladimir > > On 3/11/14 5:47 AM, Magnus Ihse Bursie wrote: >> On 2014-03-11 00:49, Mike Duigou wrote: >>> I have updated the patch to respond to Magnus's feedback and to >>> accommodate intervening changes to the configure and hotspot make files. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8032045 >>> http://cr.openjdk.java.net/~mduigou/JDK-8032045/3/webrev/ >>> >>> This version is, hopefully, almost ready to be pushed. >> >> I have only glanced at the hotspot build changes and can't really say >> anything about them. The hotspot team still owns these; I'm cc:ing them >> now. >> >> The top-level build changes looks fine. Thank you Mike for cleaning >> things up! >> >> /Magnus >> >>> >>> Mike >>> >>> On Feb 20 2014, at 15:43 , Mike Duigou wrote: >>> >>>> Hello all; >>>> >>>> This issue is a followon to JDK-8030350 >>>> (https://bugs.openjdk.java.net/browse/JDK-8030350) which enhanced the >>>> compiler warnings used for compiling native code. The proposed >>>> changes principally impact the Linux platform. >>>> >>>> While 8030350 was focused on compiler warnings which did not impact >>>> code generation, this changeset will, for some configurations, change >>>> the native code generated and likely change performance. These >>>> proposed option changes prevent specific types of relocation table, >>>> stack and heap memory corruption in native code. Preventing these >>>> types of memory corruption may be useful for finding certain kinds of >>>> bugs though and do provide some minimal additional protections >>>> against malicious attacks. They aren't, by any means, a substitute >>>> for following appropriate secure coding guidelines. >>>> >>>> The rationale behind the implementation is as follows. For release >>>> builds during the initial phase of JDK 9 I would like to enable only >>>> compile time checks. This ends up being similar to the warnings in >>>> JDK-8030350. These options have no runtime impact on footprint or >>>> performance and very minimal additional compile time cost while >>>> providing value. **Release builds are not expected to see any >>>> performance or footprint change as a result of this changeset** >>>> >>>> For fast debug builds we can enable linker protections (relro) and >>>> static compile time bounds checks (FORTIFY_SOURCE=1). >>>> FORTIFY_SOURCE=1 might be moved to the production builds as well >>>> because it has no runtime cost or executable size cost. >>>> >>>> For slow debug builds we can enable full linker protection (at a >>>> potential cost in startup time), runtime bounds checks and stack >>>> protection (FORTIFY_SOURCE=2 -fprotect-stack-all). We will likely >>>> enable -fprotect-stack-strong when available in GCC 4.9 >>>> >>>> The basis for enabling the additional protections in debug builds is >>>> that it will help us find bugs in our native code and we aren't as >>>> concerned in debug builds with footprint and performance. Since many >>>> developers already do their personal builds in fastdebug or slowdebug >>>> mode for testing this will provide good opportunity to shake out any >>>> problems with the options while not impacting release builds. Should >>>> we find that any of the options provide significant value for their >>>> cost we can move them to fastdebug or release. If any of the options >>>> prove too costly they can be demoted or removed entirely. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8032045 >>>> http://cr.openjdk.java.net/~mduigou/JDK-8032045/2/webrev/ >>>> >>>> Additional to enabling the various compiler options I attempted to >>>> rationalize some of the skew between the various >>>> hotspot/make/{platform}/makefiles/gcc.make files while avoiding >>>> changing existing behaviour. I have also introduced the new -Og >>>> "optimize for debugging" option and there are now an explicit >>>> C{XX}_O_FLAG_DEBUG definitions to complement the >>>> C{XX}_O_FLAG_{DEBUG|NORM|HI|HIGHEST|NONE} optimization options. >>>> >>>> Thanks, >>>> >>>> Mike >> From vladimir.kozlov at oracle.com Wed Mar 12 19:22:35 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Mar 2014 12:22:35 -0700 Subject: RFR : JDK-8032045 : (m/l) Enable compiler and linker safety switches for debug builds In-Reply-To: <53202F88.4030402@oracle.com> References: <531F05D3.6020008@oracle.com> <531F7C45.30607@oracle.com> <53202F88.4030402@oracle.com> Message-ID: <5320B3FB.4080208@oracle.com> On 3/12/14 2:57 AM, David Holmes wrote: > On 12/03/2014 7:12 AM, Vladimir Kozlov wrote: >> Mike, >> >> About hotspot makefiles changes. There is no DBG variant in hotspot: >> >> ifeq ($(VARIANT), DBG) >> >> We have specialized makefiles debug.make and fastdebug.make you can used >> for such settings. > > Though we are very inconsistent about whether things go in those files > or in the compiler specific ones. You either have to put compiler > conditionals in the debug/fastdebug files, or else debug/fastdebug > conditionals in the compiler .make files. > >> Note, normal Hotspot build (at least now) does not invoke top level make >> files. > > What are you referring to? A "normal" hotspot build starts with > make/Makefile. A developer on platform X may kick of a build using > make/X/Makefile (though we need to wean them off that). A top-level > configure-based build will also use make/Makefile. DBG is defined in JDK make files only: common//autoconf/generated-configure.sh: VARIANT="DBG" common//autoconf/generated-configure.sh: VARIANT="DBG" common//autoconf/hotspot-spec.gmk.in:# Legacy setting: OPT or DBG common//autoconf/jdk-options.m4: VARIANT="DBG" common//autoconf/jdk-options.m4: VARIANT="DBG" But when we build Hotspot standalone we don't use or even have those files. So we should not check DBG in Hotspot's makefiles. Thanks, Vladimir > > David > >> I would suggest to run JPRT hotspot test job (-stree . from hotspot >> repo). And also JDK control build with -buildenv SKIP_BOOT_CYCLE=false. >> >> Thanks, >> Vladimir >> >> On 3/11/14 5:47 AM, Magnus Ihse Bursie wrote: >>> On 2014-03-11 00:49, Mike Duigou wrote: >>>> I have updated the patch to respond to Magnus's feedback and to >>>> accommodate intervening changes to the configure and hotspot make >>>> files. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8032045 >>>> http://cr.openjdk.java.net/~mduigou/JDK-8032045/3/webrev/ >>>> >>>> This version is, hopefully, almost ready to be pushed. >>> >>> I have only glanced at the hotspot build changes and can't really say >>> anything about them. The hotspot team still owns these; I'm cc:ing them >>> now. >>> >>> The top-level build changes looks fine. Thank you Mike for cleaning >>> things up! >>> >>> /Magnus >>> >>>> >>>> Mike >>>> >>>> On Feb 20 2014, at 15:43 , Mike Duigou wrote: >>>> >>>>> Hello all; >>>>> >>>>> This issue is a followon to JDK-8030350 >>>>> (https://bugs.openjdk.java.net/browse/JDK-8030350) which enhanced the >>>>> compiler warnings used for compiling native code. The proposed >>>>> changes principally impact the Linux platform. >>>>> >>>>> While 8030350 was focused on compiler warnings which did not impact >>>>> code generation, this changeset will, for some configurations, change >>>>> the native code generated and likely change performance. These >>>>> proposed option changes prevent specific types of relocation table, >>>>> stack and heap memory corruption in native code. Preventing these >>>>> types of memory corruption may be useful for finding certain kinds of >>>>> bugs though and do provide some minimal additional protections >>>>> against malicious attacks. They aren't, by any means, a substitute >>>>> for following appropriate secure coding guidelines. >>>>> >>>>> The rationale behind the implementation is as follows. For release >>>>> builds during the initial phase of JDK 9 I would like to enable only >>>>> compile time checks. This ends up being similar to the warnings in >>>>> JDK-8030350. These options have no runtime impact on footprint or >>>>> performance and very minimal additional compile time cost while >>>>> providing value. **Release builds are not expected to see any >>>>> performance or footprint change as a result of this changeset** >>>>> >>>>> For fast debug builds we can enable linker protections (relro) and >>>>> static compile time bounds checks (FORTIFY_SOURCE=1). >>>>> FORTIFY_SOURCE=1 might be moved to the production builds as well >>>>> because it has no runtime cost or executable size cost. >>>>> >>>>> For slow debug builds we can enable full linker protection (at a >>>>> potential cost in startup time), runtime bounds checks and stack >>>>> protection (FORTIFY_SOURCE=2 -fprotect-stack-all). We will likely >>>>> enable -fprotect-stack-strong when available in GCC 4.9 >>>>> >>>>> The basis for enabling the additional protections in debug builds is >>>>> that it will help us find bugs in our native code and we aren't as >>>>> concerned in debug builds with footprint and performance. Since many >>>>> developers already do their personal builds in fastdebug or slowdebug >>>>> mode for testing this will provide good opportunity to shake out any >>>>> problems with the options while not impacting release builds. Should >>>>> we find that any of the options provide significant value for their >>>>> cost we can move them to fastdebug or release. If any of the options >>>>> prove too costly they can be demoted or removed entirely. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8032045 >>>>> http://cr.openjdk.java.net/~mduigou/JDK-8032045/2/webrev/ >>>>> >>>>> Additional to enabling the various compiler options I attempted to >>>>> rationalize some of the skew between the various >>>>> hotspot/make/{platform}/makefiles/gcc.make files while avoiding >>>>> changing existing behaviour. I have also introduced the new -Og >>>>> "optimize for debugging" option and there are now an explicit >>>>> C{XX}_O_FLAG_DEBUG definitions to complement the >>>>> C{XX}_O_FLAG_{DEBUG|NORM|HI|HIGHEST|NONE} optimization options. >>>>> >>>>> Thanks, >>>>> >>>>> Mike >>> From philip.race at oracle.com Wed Mar 12 21:45:33 2014 From: philip.race at oracle.com (Phil Race) Date: Wed, 12 Mar 2014 14:45:33 -0700 Subject: JDK9 build failure on Windows : javac OutOfMemoryError Message-ID: <5320D57D.1040708@oracle.com> I'm on Windows 7 64 bit and I've quit every app except for my console windows yet I still get this error below. How can I get past this ? -phil. ---------- ## Starting jdk Compiling 9635 files for BUILD_JDK The system is out of resources. Consult the following stack trace for details. java.lang.OutOfMemoryError: Java heap space at com.sun.tools.javac.tree.TreeMaker.Literal(TreeMaker.java:451) at com.sun.tools.javac.parser.JavacParser.literal(JavacParser.java:740) at com.sun.tools.javac.parser.JavacParser.literal(JavacParser.java:660) at com.sun.tools.javac.parser.JavacParser.term3(JavacParser.java:1158) at com.sun.tools.javac.parser.JavacParser.term2(JavacParser.java:910) at com.sun.tools.javac.parser.JavacParser.term1(JavacParser.java:881) at com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:837) at com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:817) at com.sun.tools.javac.parser.JavacParser.parseExpression(JavacParser.ja va:780) .... .... make[2]: *** [/cygdrive/c/jdks/client/build/windows-x86-normal-serverANDclient-release/jdk/classes/_the.BUILD_JDK_batch] Error 3 BuildJdk.gmk:64: recipe for target `classes-only' failed make[1]: *** [classes-only] Error 2 /cygdrive/c/jdks/client//make/Main.gmk:116: recipe for target `jdk-only' failed make: *** [jdk-only] Error 2 --------------------- From mike.duigou at oracle.com Wed Mar 12 22:06:35 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 12 Mar 2014 15:06:35 -0700 Subject: JDK9 build failure on Windows : javac OutOfMemoryError In-Reply-To: <5320D57D.1040708@oracle.com> References: <5320D57D.1040708@oracle.com> Message-ID: <0D6C8060-2367-4D44-89C1-923A35804270@oracle.com> Is your bootjdk a 32 bit VM? Brad Wetmore had similar issues last week. The problem in his case was that the 32 bit VM couldn't get a large enough heap. Switching to a 64 bit boot jdk resolved the issue for him. Mike On Mar 12 2014, at 14:45 , Phil Race wrote: > I'm on Windows 7 64 bit and I've quit every app except for my console windows > yet I still get this error below. > > How can I get past this ? > > -phil. > > ---------- > ## Starting jdk > Compiling 9635 files for BUILD_JDK > > > The system is out of resources. > Consult the following stack trace for details. > java.lang.OutOfMemoryError: Java heap space > at com.sun.tools.javac.tree.TreeMaker.Literal(TreeMaker.java:451) > at com.sun.tools.javac.parser.JavacParser.literal(JavacParser.java:740) > at com.sun.tools.javac.parser.JavacParser.literal(JavacParser.java:660) > at com.sun.tools.javac.parser.JavacParser.term3(JavacParser.java:1158) > at com.sun.tools.javac.parser.JavacParser.term2(JavacParser.java:910) > at com.sun.tools.javac.parser.JavacParser.term1(JavacParser.java:881) > at com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:837) > at com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:817) > at com.sun.tools.javac.parser.JavacParser.parseExpression(JavacParser.ja > va:780) > .... > .... > > make[2]: *** [/cygdrive/c/jdks/client/build/windows-x86-normal-serverANDclient-release/jdk/classes/_the.BUILD_JDK_batch] Error 3 > BuildJdk.gmk:64: recipe for target `classes-only' failed > make[1]: *** [classes-only] Error 2 > /cygdrive/c/jdks/client//make/Main.gmk:116: recipe for target `jdk-only' failed > make: *** [jdk-only] Error 2 > --------------------- From philip.race at oracle.com Wed Mar 12 22:17:15 2014 From: philip.race at oracle.com (Phil Race) Date: Wed, 12 Mar 2014 15:17:15 -0700 Subject: JDK9 build failure on Windows : javac OutOfMemoryError In-Reply-To: <0D6C8060-2367-4D44-89C1-923A35804270@oracle.com> References: <5320D57D.1040708@oracle.com> <0D6C8060-2367-4D44-89C1-923A35804270@oracle.com> Message-ID: <5320DCEB.10205@oracle.com> Yes, 32 bit it appears, although I didn't supply the boot dir option, it chose it all by itself. Who can dig into how much heap is actually needed and see if some new bug is requiring more than that ? -phil. On 3/12/2014 3:06 PM, Mike Duigou wrote: > Is your bootjdk a 32 bit VM? Brad Wetmore had similar issues last week. The problem in his case was that the 32 bit VM couldn't get a large enough heap. Switching to a 64 bit boot jdk resolved the issue for him. > > Mike > > On Mar 12 2014, at 14:45 , Phil Race wrote: > >> I'm on Windows 7 64 bit and I've quit every app except for my console windows >> yet I still get this error below. >> >> How can I get past this ? >> >> -phil. >> >> ---------- >> ## Starting jdk >> Compiling 9635 files for BUILD_JDK >> >> >> The system is out of resources. >> Consult the following stack trace for details. >> java.lang.OutOfMemoryError: Java heap space >> at com.sun.tools.javac.tree.TreeMaker.Literal(TreeMaker.java:451) >> at com.sun.tools.javac.parser.JavacParser.literal(JavacParser.java:740) >> at com.sun.tools.javac.parser.JavacParser.literal(JavacParser.java:660) >> at com.sun.tools.javac.parser.JavacParser.term3(JavacParser.java:1158) >> at com.sun.tools.javac.parser.JavacParser.term2(JavacParser.java:910) >> at com.sun.tools.javac.parser.JavacParser.term1(JavacParser.java:881) >> at com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:837) >> at com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:817) >> at com.sun.tools.javac.parser.JavacParser.parseExpression(JavacParser.ja >> va:780) >> .... >> .... >> >> make[2]: *** [/cygdrive/c/jdks/client/build/windows-x86-normal-serverANDclient-release/jdk/classes/_the.BUILD_JDK_batch] Error 3 >> BuildJdk.gmk:64: recipe for target `classes-only' failed >> make[1]: *** [classes-only] Error 2 >> /cygdrive/c/jdks/client//make/Main.gmk:116: recipe for target `jdk-only' failed >> make: *** [jdk-only] Error 2 >> --------------------- From erik.joelsson at oracle.com Thu Mar 13 08:48:18 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 13 Mar 2014 09:48:18 +0100 Subject: RFR: JDK-8037238: JDK 9 images don't rebuild when access bridge jars rebuild Message-ID: <532170D2.5050808@oracle.com> When rebuilding after touching a java source file in AccessBridge, the classes were recompiled but the jars were not rebuilt. This was caused by a bug in the macro CacheFind. The cache in this case contained the directory $(JDK_OUTPUTDIR)/classes. The jar was built from the src dir $(JDK_OUTPUTDIR)/classes_ab. The matching code found the latter to be a subdir of the former and so chose to use the cache and of course found nothing. I fixed the test to either match with a trailing slash or make an exact match. I also added a warning in SetupArchive so that we will catch empty dependency lists faster next time. Bug: https://bugs.openjdk.java.net/browse/JDK-8037238 Webrev: http://cr.openjdk.java.net/~erikj/8037238/webrev.root.01/ /Erik From erik.joelsson at oracle.com Thu Mar 13 10:26:55 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 13 Mar 2014 11:26:55 +0100 Subject: RFR: JDK-8037281: Improve CacheFind and enable on all platforms Message-ID: <532187EF.2050401@oracle.com> Triggered by JDK-8037238 and the CacheFind problems I decided to give it some more love. One reason CacheFind errors are rarely discovered is that it's only enabled on Windows, which is not used much in the build group. I would like to enable it on all platforms, simply to give it more usage and hardening. There is a very slight performance improvement on my Linux workstation, so it's not without benefits. ("time make images" with no changes reports 6.5 secs down from 7.5). I also made the FillCacheFind macro a little smarter so that it handles being called multiple times with same or similar arguments without incurring a performance overhead. Now it only executes find if it's really needed. With this check, I could also add a call to FillCacheFind in SetupJavaCompilation and SetupArchive. To provide a workaround next time a problem with the FindCache is found (or to just be able to measure the benefits), I added a variable DISABLE_CACHE_FIND that when set to true disables the cache. (Note that the webrevs also contains the changes for JDK-8037238 since they were needed but aren't yet committed) Bug: https://bugs.openjdk.java.net/browse/JDK-8037281 Webrevs: http://cr.openjdk.java.net/~erikj/8037281/webrev.root.01/ http://cr.openjdk.java.net/~erikj/8037281/webrev.jdk.01/ /Erik From volker.simonis at gmail.com Thu Mar 13 15:04:33 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 13 Mar 2014 16:04:33 +0100 Subject: RFR[9](XS): 8037298: Export HotSpots 'optimized' (i.e. not-product) configuration in the top-level configure/makefile Message-ID: Hi, could somebody please review this small change which exports HotSpots 'optimized' (i.e. not-product) configuration in the top-level configure/makefile: http://cr.openjdk.java.net/~simonis/webrevs/8037298/ https://bugs.openjdk.java.net/browse/JDK-8037298 The HotSpot offers a so called 'optimized' configuration which is actually the same as a product build, but without setting '-DPRODUCT'. That means that an 'optimized' HotSpot VM offers additional command line options and functionality which is not present in an actual product build. While the 'product' configuration is exported in the top-level configure/make system as "--with-debug-level=release" the , this was not the case for the 'optimized' configuration. I think I need a sponsor for this change because it requires the regeneration of common/autoconf/generated-configure.sh as well as of the closed generated configure files. Thank you and best regards, Volker From tim.bell at oracle.com Thu Mar 13 15:55:52 2014 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 13 Mar 2014 08:55:52 -0700 Subject: RFR: JDK-8037238: JDK 9 images don't rebuild when access bridge jars rebuild In-Reply-To: <532170D2.5050808@oracle.com> References: <532170D2.5050808@oracle.com> Message-ID: <5321D508.6040806@oracle.com> Hi Erik: > When rebuilding after touching a java source file in AccessBridge, the > classes were recompiled but the jars were not rebuilt. This was caused > by a bug in the macro CacheFind. The cache in this case contained the > directory $(JDK_OUTPUTDIR)/classes. The jar was built from the src dir > $(JDK_OUTPUTDIR)/classes_ab. The matching code found the latter to be > a subdir of the former and so chose to use the cache and of course > found nothing. I fixed the test to either match with a trailing slash > or make an exact match. > > I also added a warning in SetupArchive so that we will catch empty > dependency lists faster next time. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8037238 > Webrev: http://cr.openjdk.java.net/~erikj/8037238/webrev.root.01/ Very subtle. Looks good to me. Tim From tim.bell at oracle.com Thu Mar 13 15:59:16 2014 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 13 Mar 2014 08:59:16 -0700 Subject: RFR: JDK-8037281: Improve CacheFind and enable on all platforms In-Reply-To: <532187EF.2050401@oracle.com> References: <532187EF.2050401@oracle.com> Message-ID: <5321D5D4.6070005@oracle.com> Hi Erik: > Triggered by JDK-8037238 and the CacheFind problems I decided to give > it some more love. > > One reason CacheFind errors are rarely discovered is that it's only > enabled on Windows, which is not used much in the build group. I would > like to enable it on all platforms, simply to give it more usage and > hardening. There is a very slight performance improvement on my Linux > workstation, so it's not without benefits. ("time make images" with no > changes reports 6.5 secs down from 7.5). > > I also made the FillCacheFind macro a little smarter so that it > handles being called multiple times with same or similar arguments > without incurring a performance overhead. Now it only executes find if > it's really needed. With this check, I could also add a call to > FillCacheFind in SetupJavaCompilation and SetupArchive. > > To provide a workaround next time a problem with the FindCache is > found (or to just be able to measure the benefits), I added a variable > DISABLE_CACHE_FIND that when set to true disables the cache. > > (Note that the webrevs also contains the changes for JDK-8037238 since > they were needed but aren't yet committed) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8037281 > Webrevs: > http://cr.openjdk.java.net/~erikj/8037281/webrev.root.01/ > http://cr.openjdk.java.net/~erikj/8037281/webrev.jdk.01/ Looks good to me. Tim From erik.joelsson at oracle.com Thu Mar 13 16:08:45 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 13 Mar 2014 17:08:45 +0100 Subject: RFR: JDK-8010767: Build fails on OEL6 with 16 cores Message-ID: <5321D80D.5030604@oracle.com> Hello, When building on large machines, the default Hotspot ergonomics are causing us trouble. Trying to spawn 30 or more jvm instances just does not work with default options. To tackle this, I've split the JAVA_FLAGS variable into one common JAVA_FLAGS and two separate JAVA_FLAGS_BIG and JAVA_FLAGS_SMALL. Big contains the memory settings that used to be in JAVA_FLAGS. Small sets SerialGC and a smaller heap. Small is then used for most of our smaller jvm instances in the build. (Building demos, tools and most notably when running native2ascii in images to generate _ja man pages). On the particular machine this was last reported on (32 virtual cpus, 256GB memory), the default setting of JOBS=16 (which is the current max automatic setting) would fail in native2ascii. With these changes I'm able to run the build with at least JOBS=100. There is currently no performance improvement going from 16 to 100 jobs, but it's good to know we no longer have issues with resources when scaling up. Bug: https://bugs.openjdk.java.net/browse/JDK-8010767 Webrevs: http://cr.openjdk.java.net/~erikj/8010767/webrev.root.01/ http://cr.openjdk.java.net/~erikj/8010767/webrev.jdk.01/ /Erik From tim.bell at oracle.com Thu Mar 13 16:20:23 2014 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 13 Mar 2014 09:20:23 -0700 Subject: RFR: JDK-8010767: Build fails on OEL6 with 16 cores In-Reply-To: <5321D80D.5030604@oracle.com> References: <5321D80D.5030604@oracle.com> Message-ID: <5321DAC7.3090201@oracle.com> Hi Erik: > When building on large machines, the default Hotspot ergonomics are > causing us trouble. Trying to spawn 30 or more jvm instances just does > not work with default options. To tackle this, I've split the > JAVA_FLAGS variable into one common JAVA_FLAGS and two separate > JAVA_FLAGS_BIG and JAVA_FLAGS_SMALL. Big contains the memory settings > that used to be in JAVA_FLAGS. Small sets SerialGC and a smaller heap. > Small is then used for most of our smaller jvm instances in the build. > (Building demos, tools and most notably when running native2ascii in > images to generate _ja man pages). > > On the particular machine this was last reported on (32 virtual cpus, > 256GB memory), the default setting of JOBS=16 (which is the current > max automatic setting) would fail in native2ascii. With these changes > I'm able to run the build with at least JOBS=100. There is currently > no performance improvement going from 16 to 100 jobs, but it's good to > know we no longer have issues with resources when scaling up. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8010767 > Webrevs: > http://cr.openjdk.java.net/~erikj/8010767/webrev.root.01/ > http://cr.openjdk.java.net/~erikj/8010767/webrev.jdk.01/ Thank you, Erik - this looks great and is a much better solution than my prototype. Thanks for taking this over. Approved. Tim From vladimir.kozlov at oracle.com Thu Mar 13 17:17:27 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Mar 2014 10:17:27 -0700 Subject: RFR[9](XS): 8037298: Export HotSpots 'optimized' (i.e. not-product) configuration in the top-level configure/makefile In-Reply-To: References: Message-ID: <5321E827.2070204@oracle.com> Looks good to me. Vladimir On 3/13/14 8:04 AM, Volker Simonis wrote: > Hi, > > could somebody please review this small change which exports HotSpots > 'optimized' (i.e. not-product) configuration in the top-level > configure/makefile: > > http://cr.openjdk.java.net/~simonis/webrevs/8037298/ > https://bugs.openjdk.java.net/browse/JDK-8037298 > > The HotSpot offers a so called 'optimized' configuration which is > actually the same as a product build, but without setting '-DPRODUCT'. > That means that an 'optimized' HotSpot VM offers additional command > line options and functionality which is not present in an actual > product build. > > While the 'product' configuration is exported in the top-level > configure/make system as "--with-debug-level=release" the , this was > not the case for the 'optimized' configuration. > > I think I need a sponsor for this change because it requires the > regeneration of common/autoconf/generated-configure.sh as well as of > the closed generated configure files. > > Thank you and best regards, > Volker > From bradford.wetmore at oracle.com Thu Mar 13 21:36:31 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 13 Mar 2014 14:36:31 -0700 Subject: JDK9 build failure on Windows : javac OutOfMemoryError In-Reply-To: <5320DCEB.10205@oracle.com> References: <5320D57D.1040708@oracle.com> <0D6C8060-2367-4D44-89C1-923A35804270@oracle.com> <5320DCEB.10205@oracle.com> Message-ID: <532224DF.9070202@oracle.com> Phil, That looks exactly like my problem. http://mail.openjdk.java.net/pipermail/build-dev/2014-March/012089.html Subject: Heads Up: OutOfMemoryError when building a 64-bit JDK 9 using a 32-bit bootdir. > Yes, 32 bit it appears, although I didn't supply the boot dir option, > it chose it all by itself. I *BELIEVE* that for the bootdirs discovery (I haven't checked the code), if a JDK isn't given one with config's --with-boot-jdk, it defaults to whatever JDK is found in the path. I typically only install a 32-bit one, as several applets I use require 32-bit only. > Who can dig into how much heap is actually needed and see if some new > bug is requiring more than that ? As for how much head is actually needed, I haven't dug into it, but just doing a simple javac -XmxXXXM Foo.java, I could only get up to about 1500M. I wasn't able to build on my laptop, but my lab machine worked just fine, so it's probably close to the border. Brad On 3/12/2014 3:17 PM, Phil Race wrote: > Yes, 32 bit it appears, although I didn't supply the boot dir option, it > chose it all by itself. > Who can dig into how much heap is actually needed and see if some new > bug is > requiring more than that ? > > -phil. > > On 3/12/2014 3:06 PM, Mike Duigou wrote: >> Is your bootjdk a 32 bit VM? Brad Wetmore had similar issues last >> week. The problem in his case was that the 32 bit VM couldn't get a >> large enough heap. Switching to a 64 bit boot jdk resolved the issue >> for him. >> >> Mike >> >> On Mar 12 2014, at 14:45 , Phil Race wrote: >> >>> I'm on Windows 7 64 bit and I've quit every app except for my >>> console windows >>> yet I still get this error below. >>> >>> How can I get past this ? >>> >>> -phil. >>> >>> ---------- >>> ## Starting jdk >>> Compiling 9635 files for BUILD_JDK >>> >>> >>> The system is out of resources. >>> Consult the following stack trace for details. >>> java.lang.OutOfMemoryError: Java heap space >>> at >>> com.sun.tools.javac.tree.TreeMaker.Literal(TreeMaker.java:451) >>> at >>> com.sun.tools.javac.parser.JavacParser.literal(JavacParser.java:740) >>> at >>> com.sun.tools.javac.parser.JavacParser.literal(JavacParser.java:660) >>> at >>> com.sun.tools.javac.parser.JavacParser.term3(JavacParser.java:1158) >>> at >>> com.sun.tools.javac.parser.JavacParser.term2(JavacParser.java:910) >>> at >>> com.sun.tools.javac.parser.JavacParser.term1(JavacParser.java:881) >>> at >>> com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:837) >>> at >>> com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:817) >>> at >>> com.sun.tools.javac.parser.JavacParser.parseExpression(JavacParser.ja >>> va:780) >>> .... >>> .... >>> >>> make[2]: *** >>> [/cygdrive/c/jdks/client/build/windows-x86-normal-serverANDclient-release/jdk/classes/_the.BUILD_JDK_batch] >>> Error 3 >>> BuildJdk.gmk:64: recipe for target `classes-only' failed >>> make[1]: *** [classes-only] Error 2 >>> /cygdrive/c/jdks/client//make/Main.gmk:116: recipe for target >>> `jdk-only' failed >>> make: *** [jdk-only] Error 2 >>> --------------------- > From magnus.ihse.bursie at oracle.com Fri Mar 14 09:44:55 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Mar 2014 10:44:55 +0100 Subject: RFR[9](XS): 8037298: Export HotSpots 'optimized' (i.e. not-product) configuration in the top-level configure/makefile In-Reply-To: References: Message-ID: <5322CF97.6080301@oracle.com> On 2014-03-13 16:04, Volker Simonis wrote: > Hi, > > could somebody please review this small change which exports HotSpots > 'optimized' (i.e. not-product) configuration in the top-level > configure/makefile: > > http://cr.openjdk.java.net/~simonis/webrevs/8037298/ > https://bugs.openjdk.java.net/browse/JDK-8037298 > > The HotSpot offers a so called 'optimized' configuration which is > actually the same as a product build, but without setting '-DPRODUCT'. > That means that an 'optimized' HotSpot VM offers additional command > line options and functionality which is not present in an actual > product build. > > While the 'product' configuration is exported in the top-level > configure/make system as "--with-debug-level=release" the , this was > not the case for the 'optimized' configuration. > > I think I need a sponsor for this change because it requires the > regeneration of common/autoconf/generated-configure.sh as well as of > the closed generated configure files. Hi Volker, Unfortunately, this is more of a mine field than what first looks will tell. :( The problem here is that the DEBUG_LEVEL variable that is set by --with-debug-level is used for setting *both* the Hotspot debug level and the JDK debug level. In JDK, the only real difference is between "debug" and "release", so the existing "fastdebug" and "slowdebug" are generally considered to be "debug", in contrast to "release". Maybe it was incorrect to introduce a single debug level for the whole product -- maybe we should have kept a separate hotspot-debug-level and a jdk-debug-level. In a way, that makes sense. On the other hand, it also makes sense to try to unify the product as a whole. So I'm a bit ambivalent here. But here we are now; while it is possible to change this now I'd rather avoid it. If you introduce "optimized" as a new level, this will affect all the existing code as well that checks the DEBUG_LEVEL. So you will need to determine how this should be interpreted by the JDK part of the build. With your patch as it looks today, the effects will be a bit random. Most of the time, we check if debug level is release or not, where the "not" case (currently fastdebug and slowdebug) is bunched together and treated as a general debug case. Your "optimized" level would end up there. Probably correct, but that depends on what you want to achieve. In a few cases we explicitely look for slowdebug or fastdebug, and consider the alternative as release; there your optimized level will be treated as release. It might very well be that this treatment of optimized as a mix between debug and release is what's needed here, but the decisions should be made explicitely. You should at least check the uses of DEBUG_LEVEL in flags.m4 and NativeCompilation.gmk. Also, how would you feel about naming the level "optdebug" instead of "optimized"? I think that would make things clearer in the rest of the build, since then you'd have three debug levels: "[slow|fast|opt]debug" in contrast to "release", and anything that is not explicitely a release build is some kind of debug build -- not intended for shipping. It would make it possible to keep the abilitiy in the make files to check DEBUG_LEVEL to see if it contains "debug". And I believe it would make it more clear to future jdk make file developers to understand that this is some kind of debug (i.e. non-release) build. /Magnus I'm not convinced this is the best way to achieve what you want. The "debug levels" in the configure system is not really the same as the "configurations" in hotspot. The optimized configuration in hotspot is really, from the configuration point of view, a release build (DEBUG_LEVEL=release), but at the same time, it is telling hotspot not to disable non-product functionality. From magnus.ihse.bursie at oracle.com Fri Mar 14 10:25:36 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Mar 2014 11:25:36 +0100 Subject: RFR: JDK-8037281: Improve CacheFind and enable on all platforms In-Reply-To: <532187EF.2050401@oracle.com> References: <532187EF.2050401@oracle.com> Message-ID: <5322D920.7060603@oracle.com> On 2014-03-13 11:26, Erik Joelsson wrote: > Triggered by JDK-8037238 and the CacheFind problems I decided to give > it some more love. > > One reason CacheFind errors are rarely discovered is that it's only > enabled on Windows, which is not used much in the build group. I would > like to enable it on all platforms, simply to give it more usage and > hardening. There is a very slight performance improvement on my Linux > workstation, so it's not without benefits. ("time make images" with no > changes reports 6.5 secs down from 7.5). > > I also made the FillCacheFind macro a little smarter so that it > handles being called multiple times with same or similar arguments > without incurring a performance overhead. Now it only executes find if > it's really needed. With this check, I could also add a call to > FillCacheFind in SetupJavaCompilation and SetupArchive. > > To provide a workaround next time a problem with the FindCache is > found (or to just be able to measure the benefits), I added a variable > DISABLE_CACHE_FIND that when set to true disables the cache. > > (Note that the webrevs also contains the changes for JDK-8037238 since > they were needed but aren't yet committed) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8037281 > Webrevs: > http://cr.openjdk.java.net/~erikj/8037281/webrev.root.01/ > http://cr.openjdk.java.net/~erikj/8037281/webrev.jdk.01/ Looks good to me! /Magnus From magnus.ihse.bursie at oracle.com Fri Mar 14 10:44:54 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Mar 2014 11:44:54 +0100 Subject: RFR: JDK-8010767: Build fails on OEL6 with 16 cores In-Reply-To: <5321D80D.5030604@oracle.com> References: <5321D80D.5030604@oracle.com> Message-ID: <5322DDA6.2010307@oracle.com> On 2014-03-13 17:08, Erik Joelsson wrote: > Hello, > > When building on large machines, the default Hotspot ergonomics are > causing us trouble. Trying to spawn 30 or more jvm instances just does > not work with default options. To tackle this, I've split the > JAVA_FLAGS variable into one common JAVA_FLAGS and two separate > JAVA_FLAGS_BIG and JAVA_FLAGS_SMALL. Big contains the memory settings > that used to be in JAVA_FLAGS. Small sets SerialGC and a smaller heap. > Small is then used for most of our smaller jvm instances in the build. > (Building demos, tools and most notably when running native2ascii in > images to generate _ja man pages). > > On the particular machine this was last reported on (32 virtual cpus, > 256GB memory), the default setting of JOBS=16 (which is the current > max automatic setting) would fail in native2ascii. With these changes > I'm able to run the build with at least JOBS=100. There is currently > no performance improvement going from 16 to 100 jobs, but it's good to > know we no longer have issues with resources when scaling up. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8010767 > Webrevs: > http://cr.openjdk.java.net/~erikj/8010767/webrev.root.01/ > http://cr.openjdk.java.net/~erikj/8010767/webrev.jdk.01/ Looks good! However the variable BOOT_JDK_JVMARGS is not used anywhere any longer, so I'd appreciate if you could remove it completely. Also, you're outputting this: AC_MSG_CHECKING([flags for boot jdk java command for big configurations] ) It's great that you provide user feedback! However, we use the word "configuration" for a very specific meaning and I think it's better to rephrase this, maybe something like: AC_MSG_CHECKING([flags for java command for big workloads]) (also note the absence of space before the end paranthesis). And correspondingly for small. /Magnus From erik.joelsson at oracle.com Fri Mar 14 11:06:39 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 14 Mar 2014 12:06:39 +0100 Subject: RFR: JDK-8010767: Build fails on OEL6 with 16 cores In-Reply-To: <5322DDA6.2010307@oracle.com> References: <5321D80D.5030604@oracle.com> <5322DDA6.2010307@oracle.com> Message-ID: <5322E2BF.7070806@oracle.com> Thanks for the comments, here is a new webrev for the root repo: http://cr.openjdk.java.net/~erikj/8010767/webrev.root.02/ /Erik On 2014-03-14 11:44, Magnus Ihse Bursie wrote: > On 2014-03-13 17:08, Erik Joelsson wrote: >> Hello, >> >> When building on large machines, the default Hotspot ergonomics are >> causing us trouble. Trying to spawn 30 or more jvm instances just >> does not work with default options. To tackle this, I've split the >> JAVA_FLAGS variable into one common JAVA_FLAGS and two separate >> JAVA_FLAGS_BIG and JAVA_FLAGS_SMALL. Big contains the memory settings >> that used to be in JAVA_FLAGS. Small sets SerialGC and a smaller >> heap. Small is then used for most of our smaller jvm instances in the >> build. (Building demos, tools and most notably when running >> native2ascii in images to generate _ja man pages). >> >> On the particular machine this was last reported on (32 virtual cpus, >> 256GB memory), the default setting of JOBS=16 (which is the current >> max automatic setting) would fail in native2ascii. With these changes >> I'm able to run the build with at least JOBS=100. There is currently >> no performance improvement going from 16 to 100 jobs, but it's good >> to know we no longer have issues with resources when scaling up. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8010767 >> Webrevs: >> http://cr.openjdk.java.net/~erikj/8010767/webrev.root.01/ >> http://cr.openjdk.java.net/~erikj/8010767/webrev.jdk.01/ > > Looks good! > > However the variable BOOT_JDK_JVMARGS is not used anywhere any longer, > so I'd appreciate if you could remove it completely. > > Also, you're outputting this: > AC_MSG_CHECKING([flags for boot jdk java command for big > configurations] ) > > It's great that you provide user feedback! However, we use the word > "configuration" for a very specific meaning and I think it's better to > rephrase this, maybe something like: > AC_MSG_CHECKING([flags for java command for big workloads]) > (also note the absence of space before the end paranthesis). And > correspondingly for small. > > /Magnus From magnus.ihse.bursie at oracle.com Fri Mar 14 11:52:30 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Mar 2014 12:52:30 +0100 Subject: RFR: JDK-8010767: Build fails on OEL6 with 16 cores In-Reply-To: <5322E2BF.7070806@oracle.com> References: <5321D80D.5030604@oracle.com> <5322DDA6.2010307@oracle.com> <5322E2BF.7070806@oracle.com> Message-ID: <5322ED7E.9030609@oracle.com> On 2014-03-14 12:06, Erik Joelsson wrote: > Thanks for the comments, here is a new webrev for the root repo: > > http://cr.openjdk.java.net/~erikj/8010767/webrev.root.02/ Looks great. Thank you! /Magnus From magnus.ihse.bursie at oracle.com Fri Mar 14 11:58:37 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Mar 2014 12:58:37 +0100 Subject: RFR: JDK-8037238: JDK 9 images don't rebuild when access bridge jars rebuild In-Reply-To: <532170D2.5050808@oracle.com> References: <532170D2.5050808@oracle.com> Message-ID: <5322EEED.9010801@oracle.com> On 2014-03-13 09:48, Erik Joelsson wrote: > When rebuilding after touching a java source file in AccessBridge, the > classes were recompiled but the jars were not rebuilt. This was caused > by a bug in the macro CacheFind. The cache in this case contained the > directory $(JDK_OUTPUTDIR)/classes. The jar was built from the src dir > $(JDK_OUTPUTDIR)/classes_ab. The matching code found the latter to be > a subdir of the former and so chose to use the cache and of course > found nothing. I fixed the test to either match with a trailing slash > or make an exact match. > > I also added a warning in SetupArchive so that we will catch empty > dependency lists faster next time. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8037238 > Webrev: http://cr.openjdk.java.net/~erikj/8037238/webrev.root.01/ > > /Erik Looks good to me. /Magnus From magnus.ihse.bursie at oracle.com Fri Mar 14 12:16:45 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Mar 2014 13:16:45 +0100 Subject: [PATCH] For OpenJDK 8 and 9 to fix build issue when --with-alsa option is used In-Reply-To: References: <1CF6FDFD0639DF478B44651D79ECE7049EF3E3AB@GSCMHKP12EX.firmwide.corp.gs.com> <52F20FCB.703@oracle.com> <52F214F3.1040906@oracle.com> <52F4D355.7020400@oracle.com> Message-ID: <5322F32D.9040909@oracle.com> On 2014-03-05 16:41, Man, Jessica wrote: > Could this patch be backported to jdk8 please? > > Thank you. > > Regards, > Jessica Man, Technology > Goldman Sachs International Done, now. Thank you once again for your contribution. /Magnus From volker.simonis at gmail.com Fri Mar 14 16:55:10 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 14 Mar 2014 17:55:10 +0100 Subject: RFR[9](XS): 8037298: Export HotSpots 'optimized' (i.e. not-product) configuration in the top-level configure/makefile In-Reply-To: <5322CF97.6080301@oracle.com> References: <5322CF97.6080301@oracle.com> Message-ID: Hi Magnus, thanks for your detailed comments. I generally agree with your analysis of the problem. However, as you correctly noticed, the 'optimized' configuration is actually a "HotSpot only" concept. It is used to enable extra options/functionality which should not be shipped to the customer. Everything flagged with "#ifndef PRODUCT" in HotSpot is enabled by default in the "slowdebug" and "fastdebug" configuration - so no problem. But the Hotspot has this extra configuration called 'optimized' which is exactly like a release build, but with the extra, "#ifndef PRODUCT" stuff enabled. This may be useful for example for testing/benchmarking new functionality (i.e. you don't want to benchmark with a debug build). There's no general 'optimized' concept for the jdk and the other repositories as far as I can see. The "PRODUCT" macro is only used in src/share/native/com/sun/java/util/jar/pack/* within the 'jdk/' repository (and it is used there with a DEBUG/ASSERT semantics). I'd therefore propose to slightly modify my change as follows: optimized ) DEBUG_LEVEL="release" VARIANT="OPT" FASTDEBUG="false" DEBUG_CLASSFILES="false" BUILD_VARIANT_RELEASE="-optimized" HOTSPOT_DEBUG_LEVEL="optimized" HOTSPOT_EXPORT="optimized" ;; Notice that 'DEBUG_LEVEL' is now reset to "release" for the 'optimized' configuration. And this is actually exactly what we want: an optimized JDK which behaves exactly like a release version but with the extra "NOT_PRODUCT" features of HotSpot.Thanks for catching this. I've slightly changed the description of the 'optimized' configuration to make it clear that it only applies to the HotSpot build. And I now also print the exact HotSpot debug level in the configuration summary to make it clear what we are actually building. Here's the new webrev: http://cr.openjdk.java.net/~simonis/webrevs/8037298_2/ Altogether, I think this change will be mostly helpful to Hotspot engineers and won't bother others too much:) Regards, Volker On Fri, Mar 14, 2014 at 10:44 AM, Magnus Ihse Bursie wrote: > On 2014-03-13 16:04, Volker Simonis wrote: >> >> Hi, >> >> could somebody please review this small change which exports HotSpots >> 'optimized' (i.e. not-product) configuration in the top-level >> configure/makefile: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8037298/ >> https://bugs.openjdk.java.net/browse/JDK-8037298 >> >> The HotSpot offers a so called 'optimized' configuration which is >> actually the same as a product build, but without setting '-DPRODUCT'. >> That means that an 'optimized' HotSpot VM offers additional command >> line options and functionality which is not present in an actual >> product build. >> >> While the 'product' configuration is exported in the top-level >> configure/make system as "--with-debug-level=release" the , this was >> not the case for the 'optimized' configuration. >> >> I think I need a sponsor for this change because it requires the >> regeneration of common/autoconf/generated-configure.sh as well as of >> the closed generated configure files. > > > Hi Volker, > > Unfortunately, this is more of a mine field than what first looks will tell. > :( > > The problem here is that the DEBUG_LEVEL variable that is set by > --with-debug-level is used for setting *both* the Hotspot debug level and > the JDK debug level. > > In JDK, the only real difference is between "debug" and "release", so the > existing "fastdebug" and "slowdebug" are generally considered to be "debug", > in contrast to "release". > > Maybe it was incorrect to introduce a single debug level for the whole > product -- maybe we should have kept a separate hotspot-debug-level and a > jdk-debug-level. In a way, that makes sense. On the other hand, it also > makes sense to try to unify the product as a whole. So I'm a bit ambivalent > here. But here we are now; while it is possible to change this now I'd > rather avoid it. > > If you introduce "optimized" as a new level, this will affect all the > existing code as well that checks the DEBUG_LEVEL. So you will need to > determine how this should be interpreted by the JDK part of the build. With > your patch as it looks today, the effects will be a bit random. Most of the > time, we check if debug level is release or not, where the "not" case > (currently fastdebug and slowdebug) is bunched together and treated as a > general debug case. Your "optimized" level would end up there. Probably > correct, but that depends on what you want to achieve. In a few cases we > explicitely look for slowdebug or fastdebug, and consider the alternative as > release; there your optimized level will be treated as release. > > It might very well be that this treatment of optimized as a mix between > debug and release is what's needed here, but the decisions should be made > explicitely. You should at least check the uses of DEBUG_LEVEL in flags.m4 > and NativeCompilation.gmk. > > Also, how would you feel about naming the level "optdebug" instead of > "optimized"? I think that would make things clearer in the rest of the > build, since then you'd have three debug levels: "[slow|fast|opt]debug" in > contrast to "release", and anything that is not explicitely a release build > is some kind of debug build -- not intended for shipping. It would make it > possible to keep the abilitiy in the make files to check DEBUG_LEVEL to see > if it contains "debug". And I believe it would make it more clear to future > jdk make file developers to understand that this is some kind of debug (i.e. > non-release) build. > > /Magnus > > > > > > > > I'm not convinced this is the best way to achieve what you want. > > The "debug levels" in the configure system is not really the same as the > "configurations" in hotspot. The optimized configuration in hotspot is > really, from the configuration point of view, a release build > (DEBUG_LEVEL=release), but at the same time, it is telling hotspot not to > disable non-product functionality. From david.holmes at oracle.com Mon Mar 17 04:13:35 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Mar 2014 14:13:35 +1000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA6A09@DEWDFEMB12A.global.corp.sap> <531F9370.4020305@oracle.com> <5320E5F8.3020500@oracle.com> Message-ID: <5326766F.80104@oracle.com> On 15/03/2014 7:11 AM, Alexander Smundak wrote: > Ping. My position hasn't changed. I don't think this needs to be, or should be, a distinct architecture. I've added build-dev to cc list to see what our build experts think. David ----- > On Wed, Mar 12, 2014 at 4:59 PM, Alexander Smundak wrote: >> I was concerned by the term 'variant', which might suggest that the applications >> built for PPC64 and PPC64LE are binary compatible. They are not. >> >> On Wed, Mar 12, 2014 at 3:55 PM, David Holmes wrote: >>> On 12/03/2014 9:19 AM, Alexander Smundak wrote: >>>> >>>> On Tue, Mar 11, 2014 at 3:51 PM, Vladimir Kozlov >>>> wrote: >>>>> >>>>> It would only help if you could do cross compilation to have both build >>>>> variants at the same place. Currently you can only build le variant on >>>>> ppc64le machine and vice versa. That is why, I think, David asked if we >>>>> can >>>>> control what variant to build. >>>> >>>> Just to clarify the situation a bit: ppc64le is not a variant of ppc64. >>>> That is, >>>> an application compiled for the little-endian PowerPC64 does not "just >>>> run" on >>>> the big-endian PowerPC64 (albeit OS can have such feature, similar to the >>>> ability of the Linux running on x86_64 CPU to run 32-bit x86 >>>> applications). >>>> So ppc64le is a different architecture from ppc64. >>> >>> >>> I disagree with that classification for "architecture" and it seems at odds >>> with the literature which describes the endian-ness selection as a "mode". >>> >>> David >>> ----- >>> >>> >>>>> I would like to see the changes based on Volker suggestion. We can >>>>> compare >>>>> them and decide which way to go. >>>> >>>> Volker has the detailed suggestion here: >>>> >>>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2014-March/001790.html >>>> and it involves additional Make variable and if statements in the >>>> platform makefile >>>> where they are not supposed to be present. >>>> >>> From magnus.ihse.bursie at oracle.com Mon Mar 17 11:27:48 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 17 Mar 2014 12:27:48 +0100 Subject: [OpenJDK 2D-Dev] RFR: Allow using a system-installed lcms2 In-Reply-To: <20140228232443.GB18442@redhat.com> References: <20140220224044.GB20217@redhat.com> <20140228212732.GG1965@redhat.com> <531101FE.2080600@oracle.com> <20140228232443.GB18442@redhat.com> Message-ID: <5326DC34.3060602@oracle.com> On 2014-03-01 00:24, Omair Majid wrote: > * Phil Race [2014-02-28 16:46]: >> The moving of most of these files will cause me some significant pain. > Oh. Sorry :( > > Is there anything I (or possibly the jigsaw folks) can do to minimize > it? > >> I am not convinced why its necessary. > Basically, there is one file there (LCMS.c) that I want to make sure > that does not get compiled against the headers located in the same > directory. One way to be absolutely certain is to move the files out of > that directory into another. `#include <..>` rather than `#include > "..."` might also be sufficient but seems less of a guarantee > (especially because then I have to filter things so the compiler > invocation only includes LCMS.c and not the bundled lcms code). It seems > the patch would be more complex (from a Makefile point) to test. > > I also figured it's a nice cleanup, separating code that is maintained > in OpenJDK from code that isn't. I had an offline discussion with Erik regarding this. While we generally support moving files to a proper location, if this move is causing trouble for Phil and the 2d team, we think it can be an acceptable exception this time to just single out the LCMS.c file. (This can be achieved by setting INCLUDE_FILES:=LCMS.c -- that will automatically exclude other files in the SRC dirs.) If we do reorganize the source code, we can handle where to move the files at that time instead. >> I need to look at this more, but I have no time right now. > Fair enough. I don't mind waiting for a few weeks. Any idea when you > might have some time? Phil, ping? > >> And this needs to be built and tested on all platforms to be approved. >> And open & closed builds need to work. I'm not sure they will. >> That suggests I'd need to run it through JPRT. > If there is a way for non-Oracle folks to access JPRT, I will be happy > to run this patch through it myself. Unfortunately there is not. However, I can help you run the neccessary JPRT tests if we can get to a patch that 2d is comfortable with. /Magnus From magnus.ihse.bursie at oracle.com Mon Mar 17 11:36:15 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 17 Mar 2014 12:36:15 +0100 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <5326766F.80104@oracle.com> References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA6A09@DEWDFEMB12A.global.corp.sap> <531F9370.4020305@oracle.com> <5320E5F8.3020500@oracle.com> <5326766F.80104@oracle.com> Message-ID: <5326DE2F.6000107@oracle.com> On 2014-03-17 05:13, David Holmes wrote: > On 15/03/2014 7:11 AM, Alexander Smundak wrote: >> Ping. > > My position hasn't changed. I don't think this needs to be, or should > be, a distinct architecture. > > I've added build-dev to cc list to see what our build experts think. I'm not sure I've completely understood the discussion (it has jumped around a bit between mailing lists), but I think I agree with David here. Architecture is a term that implies general common features, not specific differences. While hotspot and the rest of the jdk build is not currently in sync with this terminology, in the common configure and makefiles we use the terminology "target cpu" (which can be for instance "x86_64" or "sparcv9" and "target cpu arch" (which can be for instance "x86" or "sparc"). Regarding ppc, we currently define the target cpu arch "ppc" and two target cpus, "ppc" and "ppc64". Perhaps it would be more approriate to consider this a separate target cpu ("ppc64le"), but not a separate target cpu architecture? But that would be on the top-level -- I'm not sure how that would map properly to the current hotspot build system. /Magnus From goetz.lindenmaier at sap.com Mon Mar 17 08:18:50 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 17 Mar 2014 08:18:50 +0000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <5326766F.80104@oracle.com> References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA6A09@DEWDFEMB12A.global.corp.sap> <531F9370.4020305@oracle.com> <5320E5F8.3020500@oracle.com> <5326766F.80104@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA843F@DEWDFEMB12A.global.corp.sap> Hi, having said what I wanted to say about the build output directory path, I'm fine with both solutions. In the end it affects only a few line in shared make files. Best regards, Goetz -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of David Holmes Sent: Montag, 17. M?rz 2014 05:14 To: Alexander Smundak; HotSpot Open Source Developers; build-dev Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model On 15/03/2014 7:11 AM, Alexander Smundak wrote: > Ping. My position hasn't changed. I don't think this needs to be, or should be, a distinct architecture. I've added build-dev to cc list to see what our build experts think. David ----- > On Wed, Mar 12, 2014 at 4:59 PM, Alexander Smundak wrote: >> I was concerned by the term 'variant', which might suggest that the applications >> built for PPC64 and PPC64LE are binary compatible. They are not. >> >> On Wed, Mar 12, 2014 at 3:55 PM, David Holmes wrote: >>> On 12/03/2014 9:19 AM, Alexander Smundak wrote: >>>> >>>> On Tue, Mar 11, 2014 at 3:51 PM, Vladimir Kozlov >>>> wrote: >>>>> >>>>> It would only help if you could do cross compilation to have both build >>>>> variants at the same place. Currently you can only build le variant on >>>>> ppc64le machine and vice versa. That is why, I think, David asked if we >>>>> can >>>>> control what variant to build. >>>> >>>> Just to clarify the situation a bit: ppc64le is not a variant of ppc64. >>>> That is, >>>> an application compiled for the little-endian PowerPC64 does not "just >>>> run" on >>>> the big-endian PowerPC64 (albeit OS can have such feature, similar to the >>>> ability of the Linux running on x86_64 CPU to run 32-bit x86 >>>> applications). >>>> So ppc64le is a different architecture from ppc64. >>> >>> >>> I disagree with that classification for "architecture" and it seems at odds >>> with the literature which describes the endian-ness selection as a "mode". >>> >>> David >>> ----- >>> >>> >>>>> I would like to see the changes based on Volker suggestion. We can >>>>> compare >>>>> them and decide which way to go. >>>> >>>> Volker has the detailed suggestion here: >>>> >>>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2014-March/001790.html >>>> and it involves additional Make variable and if statements in the >>>> platform makefile >>>> where they are not supposed to be present. >>>> >>> From goetz.lindenmaier at sap.com Mon Mar 17 13:36:07 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 17 Mar 2014 13:36:07 +0000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <5326DE2F.6000107@oracle.com> References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA6A09@DEWDFEMB12A.global.corp.sap> <531F9370.4020305@oracle.com> <5320E5F8.3020500@oracle.com> <5326766F.80104@oracle.com> <5326DE2F.6000107@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> Hi Magnus, The change keeps target cpu and target cpu arch as is. The C-code uses -DLITTLE_ENDIAN to distinguish implementation differences. As I understand, we discuss the setting of BUILDARCH in the makefiles. Indirectly it is set from uname, which returns ppc64le on these machines. This affects the following namings: 1. the build path: linux_ppc64le-compiler2 2. which makefiles used: platform_ppc64le and ppc64le.make 1.) would allow to build ppc64 and ppc64le from the same repo without setting ALT_OUTPUTDIR 2.) BUILDARCH=ppc64le means two new files, where platform_ppc64 and platform_ppc64le are the same. BUILDARCH=ppc64 means no new files, but lots of platform checks in ppc64.make, which is uncommon. So far these files are just settings. I don't think setting LIBARCH=ppc64le ==> jre/lib/ppc64le/server/libjvm.so and the settings in os_linux.cpp are questioned. Best regards, Goetz. http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.00/ -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Magnus Ihse Bursie Sent: Montag, 17. M?rz 2014 12:36 To: David Holmes Cc: build-dev; HotSpot Open Source Developers; Alexander Smundak Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model On 2014-03-17 05:13, David Holmes wrote: > On 15/03/2014 7:11 AM, Alexander Smundak wrote: >> Ping. > > My position hasn't changed. I don't think this needs to be, or should > be, a distinct architecture. > > I've added build-dev to cc list to see what our build experts think. I'm not sure I've completely understood the discussion (it has jumped around a bit between mailing lists), but I think I agree with David here. Architecture is a term that implies general common features, not specific differences. While hotspot and the rest of the jdk build is not currently in sync with this terminology, in the common configure and makefiles we use the terminology "target cpu" (which can be for instance "x86_64" or "sparcv9" and "target cpu arch" (which can be for instance "x86" or "sparc"). Regarding ppc, we currently define the target cpu arch "ppc" and two target cpus, "ppc" and "ppc64". Perhaps it would be more approriate to consider this a separate target cpu ("ppc64le"), but not a separate target cpu architecture? But that would be on the top-level -- I'm not sure how that would map properly to the current hotspot build system. /Magnus From gnu.andrew at redhat.com Tue Mar 18 01:19:30 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 17 Mar 2014 21:19:30 -0400 (EDT) Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <5315424A.4080201@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> Message-ID: <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 3/3/14 2:49 PM, Omair Majid wrote: > > * David Holmes [2014-02-28 18:48]: > >> There are three pieces to all of this: > >> > >> 1. Generating debug symbols in the binaries (via gcc -g or whatever) > >> 2. Generating debuginfo files (zipped or not) (FDS) > >> 3. Stripping debug symbols from the binaries (strip-policy) > >> > >> It may be that we don't have clean separation between them, and if so > >> that should be fixed, but I don't see the current proposal as the way > >> forward. > > Any chance we could clean up the names too? It's not obvious to me why > > FDS means 'generating debuginfo files'. > > FDS stands for Full Debug Symbols and is defined that way in > quite a few Makefiles... We just call it FDS for short... > At least to me, Full Debug Symbols suggests #1 (i.e. that symbols are generated in the binaries), not #2. That's why it sounded so odd to me when you suggested turning it off, when we discussed this before. It's also not clear why you'd want a situation where #3 would be turned off, but not #2, as you end up with two copies of the debug symbols. That's the problem I believe we have with our builds; we can turn the stripping off, but then we end up with duplicate debug information. Do we need more than just the following three alternatives? #1. No debugging information at all. #2. Debugging information left in the original binaries. #3. Debugging information stripped from the binaries and zipped in separate files. It sounds to me like Oracle want #3, while distros want #2 and I imagine some end users may just want #1 for a faster, smaller build. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From vladimir.kozlov at oracle.com Tue Mar 18 01:35:34 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 17 Mar 2014 18:35:34 -0700 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA6A09@DEWDFEMB12A.global.corp.sap> <531F9370.4020305@oracle.com> <5320E5F8.3020500@oracle.com> <5326766F.80104@oracle.com> <5326DE2F.6000107@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> Message-ID: <5327A2E6.5060100@oracle.com> On 3/17/14 6:36 AM, Lindenmaier, Goetz wrote: > Hi Magnus, > > The change keeps target cpu and target cpu arch as is. The C-code uses > -DLITTLE_ENDIAN to distinguish implementation differences. > > As I understand, we discuss the setting of BUILDARCH in the makefiles. > Indirectly it is set from uname, which returns ppc64le on these machines. > > This affects the following namings: > 1. the build path: linux_ppc64le-compiler2 I am fine with it (your case is reasonable) but it could be done with PPC64_ENDIANNESS check for PLATFORM and VM_PLATFORM definition. > 2. which makefiles used: platform_ppc64le and ppc64le.make These causes the main resistance to these changes. > > 1.) would allow to build ppc64 and ppc64le from the same repo without setting ALT_OUTPUTDIR > 2.) BUILDARCH=ppc64le means two new files, where platform_ppc64 and platform_ppc64le > are the same. > BUILDARCH=ppc64 means no new files, but lots of platform checks in ppc64.make, > which is uncommon. So far these files are just settings. It is only one check as Volker showed. > > I don't think setting > LIBARCH=ppc64le ==> jre/lib/ppc64le/server/libjvm.so It is questionable. Why you need jre/lib/ppc64le and not the same jre/lib/ppc64? It does not make sense to me to deploy JDK which have both of them in one jre/lib. Thanks, Vladimir > and the settings in os_linux.cpp are questioned. > > Best regards, > Goetz. > > http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.00/ > > > > > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Magnus Ihse Bursie > Sent: Montag, 17. M?rz 2014 12:36 > To: David Holmes > Cc: build-dev; HotSpot Open Source Developers; Alexander Smundak > Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model > > On 2014-03-17 05:13, David Holmes wrote: >> On 15/03/2014 7:11 AM, Alexander Smundak wrote: >>> Ping. >> >> My position hasn't changed. I don't think this needs to be, or should >> be, a distinct architecture. >> >> I've added build-dev to cc list to see what our build experts think. > > I'm not sure I've completely understood the discussion (it has jumped > around a bit between mailing lists), but I think I agree with David > here. Architecture is a term that implies general common features, not > specific differences. > > While hotspot and the rest of the jdk build is not currently in sync > with this terminology, in the common configure and makefiles we use the > terminology "target cpu" (which can be for instance "x86_64" or > "sparcv9" and "target cpu arch" (which can be for instance "x86" or > "sparc"). > > Regarding ppc, we currently define the target cpu arch "ppc" and two > target cpus, "ppc" and "ppc64". > > Perhaps it would be more approriate to consider this a separate target > cpu ("ppc64le"), but not a separate target cpu architecture? But that > would be on the top-level -- I'm not sure how that would map properly to > the current hotspot build system. > > /Magnus > From magnus.ihse.bursie at oracle.com Tue Mar 18 08:59:28 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 18 Mar 2014 09:59:28 +0100 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> Message-ID: <53280AF0.5000502@oracle.com> On 2014-03-18 02:19, Andrew Hughes wrote: > Do we need more than just the following three alternatives? > > #1. No debugging information at all. > #2. Debugging information left in the original binaries. > #3. Debugging information stripped from the binaries and zipped in separate files. > > It sounds to me like Oracle want #3, while distros want #2 and I imagine some > end users may just want #1 for a faster, smaller build. I'm completely thinking along your lines here. I think we should focus on the end result, not the specific implementations details. I've been thinking about exposing a configure option like this: --with-debug-symbols=none (for #1) --with-debug-symbols=internal (for #2) --with-debug-symbols=zipped (for #3) but perhaps with better names. I also imagine there might be a use case for yet another option, #4. Debuggin information stripped from the binaries, but not zipped expressed like this --with-debug-symbols=external And then this would be the only user interface needed, and the rest of the current set of not-really-clear flags can be hidden inside the configure script. For compatibility reasons, the default would be --with-debug-symbols=zipped (which is called "FDS" here), just as we currently do, but distributions would just need to add a --with-debug-symbols=internal to get what they want. /Magnus From goetz.lindenmaier at sap.com Tue Mar 18 09:58:08 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 18 Mar 2014 09:58:08 +0000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <5327A2E6.5060100@oracle.com> References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA6A09@DEWDFEMB12A.global.corp.sap> <531F9370.4020305@oracle.com> <5320E5F8.3020500@oracle.com> <5326766F.80104@oracle.com> <5326DE2F.6000107@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> <5327A2E6.5060100@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> Hi, > it could be done with PPC64_ENDIANNESS check Yes, that's fine. I would further propose to choose a neutral name ENDIANESS and set it for all architectures. Platform specific variables should be avoided in shared files. And it's used in ppc64.make, so that should be fine. Also -DLITTLE_ENDIAN could be set in a shared makefile once for all if there is a variable ENDIANESS. But I don't see how you want to fix the build path with this. It's used in a lot of places, in linux/Makefile for setting the subdirs SUBDIRS_C1 = $(addprefix $(OSNAME)_$(BUILDARCH)_compiler1/,$(TARGETS)) and also when doing the install. Further it's used in buildtree.make to set up these directories. One would have to change all these locations to SUBDIRS_C1 = $(addprefix $(OSNAME)_$(BUILDARCH)$(PPC64_ENDIANESS)_compiler1/,$(TARGETS)) But I don?t want to insist on the setting of a different build path. Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Tuesday, March 18, 2014 2:36 AM To: Lindenmaier, Goetz; Magnus Ihse Bursie; David Holmes Cc: build-dev; HotSpot Open Source Developers; Alexander Smundak Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model On 3/17/14 6:36 AM, Lindenmaier, Goetz wrote: > Hi Magnus, > > The change keeps target cpu and target cpu arch as is. The C-code uses > -DLITTLE_ENDIAN to distinguish implementation differences. > > As I understand, we discuss the setting of BUILDARCH in the makefiles. > Indirectly it is set from uname, which returns ppc64le on these machines. > > This affects the following namings: > 1. the build path: linux_ppc64le-compiler2 I am fine with it (your case is reasonable) but it could be done with PPC64_ENDIANNESS check for PLATFORM and VM_PLATFORM definition. > 2. which makefiles used: platform_ppc64le and ppc64le.make These causes the main resistance to these changes. > > 1.) would allow to build ppc64 and ppc64le from the same repo without setting ALT_OUTPUTDIR > 2.) BUILDARCH=ppc64le means two new files, where platform_ppc64 and platform_ppc64le > are the same. > BUILDARCH=ppc64 means no new files, but lots of platform checks in ppc64.make, > which is uncommon. So far these files are just settings. It is only one check as Volker showed. > > I don't think setting > LIBARCH=ppc64le ==> jre/lib/ppc64le/server/libjvm.so It is questionable. Why you need jre/lib/ppc64le and not the same jre/lib/ppc64? It does not make sense to me to deploy JDK which have both of them in one jre/lib. Thanks, Vladimir > and the settings in os_linux.cpp are questioned. > > Best regards, > Goetz. > > http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.00/ > > > > > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Magnus Ihse Bursie > Sent: Montag, 17. M?rz 2014 12:36 > To: David Holmes > Cc: build-dev; HotSpot Open Source Developers; Alexander Smundak > Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model > > On 2014-03-17 05:13, David Holmes wrote: >> On 15/03/2014 7:11 AM, Alexander Smundak wrote: >>> Ping. >> >> My position hasn't changed. I don't think this needs to be, or should >> be, a distinct architecture. >> >> I've added build-dev to cc list to see what our build experts think. > > I'm not sure I've completely understood the discussion (it has jumped > around a bit between mailing lists), but I think I agree with David > here. Architecture is a term that implies general common features, not > specific differences. > > While hotspot and the rest of the jdk build is not currently in sync > with this terminology, in the common configure and makefiles we use the > terminology "target cpu" (which can be for instance "x86_64" or > "sparcv9" and "target cpu arch" (which can be for instance "x86" or > "sparc"). > > Regarding ppc, we currently define the target cpu arch "ppc" and two > target cpus, "ppc" and "ppc64". > > Perhaps it would be more approriate to consider this a separate target > cpu ("ppc64le"), but not a separate target cpu architecture? But that > would be on the top-level -- I'm not sure how that would map properly to > the current hotspot build system. > > /Magnus > From magnus.ihse.bursie at oracle.com Tue Mar 18 10:29:52 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 18 Mar 2014 11:29:52 +0100 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA6A09@DEWDFEMB12A.global.corp.sap> <531F9370.4020305@oracle.com> <5320E5F8.3020500@oracle.com> <5326766F.80104@oracle.com> <5326DE2F.6000107@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> Message-ID: <53282020.5040302@oracle.com> On 2014-03-18 10:58, Lindenmaier, Goetz wrote: > Hi, > >> it could be done with PPC64_ENDIANNESS check > Yes, that's fine. I would further propose to choose a neutral name ENDIANESS > and set it for all architectures. Platform specific variables should be avoided in > shared files. And it's used in ppc64.make, so that should be fine. > Also -DLITTLE_ENDIAN could be set in a shared makefile once for all if there is a > variable ENDIANESS. When using the top-level build from configure, there is a OPENJDK_TARGET_CPU_ENDIAN variable defined already, set to "big" or "little". I assume that you will need to add support to ppc64le into the top-level and jdk make files as well. Building just hotspot for ppc64le, but not any of the jdk native libraries, does not really make sense. /Magnus From magnus.ihse.bursie at oracle.com Tue Mar 18 10:37:35 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 18 Mar 2014 11:37:35 +0100 Subject: RFR[9](XS): 8037298: Export HotSpots 'optimized' (i.e. not-product) configuration in the top-level configure/makefile In-Reply-To: References: <5322CF97.6080301@oracle.com> Message-ID: <532821EF.7070308@oracle.com> On 2014-03-14 17:55, Volker Simonis wrote: > Hi Magnus, > > thanks for your detailed comments. > > I generally agree with your analysis of the problem. > > However, as you correctly noticed, the 'optimized' configuration is > actually a "HotSpot only" concept. It is used to enable extra > options/functionality which should not be shipped to the customer. > > Everything flagged with "#ifndef PRODUCT" in HotSpot is enabled by > default in the "slowdebug" and "fastdebug" configuration - so no > problem. But the Hotspot has this extra configuration called > 'optimized' which is exactly like a release build, but with the extra, > "#ifndef PRODUCT" stuff enabled. This may be useful for example for > testing/benchmarking new functionality (i.e. you don't want to > benchmark with a debug build). > > There's no general 'optimized' concept for the jdk and the other > repositories as far as I can see. The "PRODUCT" macro is only used in > src/share/native/com/sun/java/util/jar/pack/* within the 'jdk/' > repository (and it is used there with a DEBUG/ASSERT semantics). > > I'd therefore propose to slightly modify my change as follows: > > optimized ) > DEBUG_LEVEL="release" > VARIANT="OPT" > FASTDEBUG="false" > DEBUG_CLASSFILES="false" > BUILD_VARIANT_RELEASE="-optimized" > HOTSPOT_DEBUG_LEVEL="optimized" > HOTSPOT_EXPORT="optimized" > ;; Okay. This seems more robust. However, I think it's a bit scary to change the value of DEBUG_LEVEL, it's sort of considered to be a straight mapping from the configure command line option. I'm okay with it, but it needs to be done more explicitely. Either a comment at the place where you modify it to "release", or -- even better -- a separate if statement after the case block that clearly shows that optimized is replaced with release, with proper comments. Also, you do not need to do AC_SUBST unless you publish the value in spec.gmk. If you want to use the variable HOTSPOT_DEBUG_LEVEL in the makefiles, you need to add it to spec.gmk.in (or hotspot-spec.gmk.in). If not, you do not need the AC_SUBST. Apart from that, the change looks good. /Magnus From erik.joelsson at oracle.com Tue Mar 18 10:42:50 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 18 Mar 2014 11:42:50 +0100 Subject: RFR: JDK-8037483: issue with the crypto / sec zip unzipping in the jdk8 build Message-ID: <5328232A.3030000@oracle.com> Please review this very simple fix to unzipping pre built security classes. When building incrementally, unzip will go into interactive mode and ask if it should overwrite files. The fix is to add -q -o to the unzip line as is done on all other invocations of unzip. Bug: https://bugs.openjdk.java.net/browse/JDK-8037483 Patch inline: diff -r a94a8944bd2b make/Import.gmk --- a/make/Import.gmk +++ b/make/Import.gmk @@ -252,7 +252,7 @@ $(ECHO) Unzipping $( $@.tmp) + ($(CD) $(JDK_OUTPUTDIR) && $(UNZIP) -q -o $< > $@.tmp) $(MV) $@.tmp $@ endef /Erik From magnus.ihse.bursie at oracle.com Tue Mar 18 10:58:43 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 18 Mar 2014 11:58:43 +0100 Subject: RFR: JDK-8037483: issue with the crypto / sec zip unzipping in the jdk8 build In-Reply-To: <5328232A.3030000@oracle.com> References: <5328232A.3030000@oracle.com> Message-ID: <532826E3.5050203@oracle.com> On 2014-03-18 11:42, Erik Joelsson wrote: > Please review this very simple fix to unzipping pre built security > classes. When building incrementally, unzip will go into interactive > mode and ask if it should overwrite files. The fix is to add -q -o to > the unzip line as is done on all other invocations of unzip. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8037483 > Patch inline: > diff -r a94a8944bd2b make/Import.gmk > --- a/make/Import.gmk > +++ b/make/Import.gmk > @@ -252,7 +252,7 @@ > $(ECHO) Unzipping $( $(MKDIR) -p $(@D) > $(RM) $@ > - ($(CD) $(JDK_OUTPUTDIR) && $(UNZIP) $< > $@.tmp) > + ($(CD) $(JDK_OUTPUTDIR) && $(UNZIP) -q -o $< > $@.tmp) > $(MV) $@.tmp $@ > endef Looks good to me. /Magnus From erik.joelsson at oracle.com Tue Mar 18 11:29:55 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 18 Mar 2014 12:29:55 +0100 Subject: RFR: JDK-8037414: Licensee Source Bundles build issue Message-ID: <53282E33.8080300@oracle.com> Hello, The file jdk/make/closed/javax/crypto/doc/README.txt is not available to licensees. The makefiles currently assumes it's always there as long as we build crypto and it's not an OpenJDK build. This change also checks that the file is actually in the source too. Bug: https://bugs.openjdk.java.net/browse/JDK-8037414 Patch inline: diff -r a94a8944bd2b make/CreateSecurityJars.gmk --- a/make/CreateSecurityJars.gmk +++ b/make/CreateSecurityJars.gmk @@ -284,11 +284,13 @@ TARGETS += $(LOCAL_POLICY_JAR_LIMITED_UNSIGNED) $(LOCAL_POLICY_JAR_UNLIMITED_UNSIGNED) ifndef OPENJDK - $(JDK_OUTPUTDIR)/jce/unsigned/policy/unlimited/README.txt: \ - $(JDK_TOPDIR)/make/closed/javax/crypto/doc/README.txt + ifneq ($(wildcard $(JDK_TOPDIR)/make/closed/javax/crypto/doc/README.txt), ) + $(JDK_OUTPUTDIR)/jce/unsigned/policy/unlimited/README.txt: \ + $(JDK_TOPDIR)/make/closed/javax/crypto/doc/README.txt $(install-file) - TARGETS += $(JDK_OUTPUTDIR)/jce/unsigned/policy/unlimited/README.txt + TARGETS += $(JDK_OUTPUTDIR)/jce/unsigned/policy/unlimited/README.txt + endif endif endif /Erik From magnus.ihse.bursie at oracle.com Tue Mar 18 14:00:22 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 18 Mar 2014 15:00:22 +0100 Subject: RFR: JDK-8037414: Licensee Source Bundles build issue In-Reply-To: <53282E33.8080300@oracle.com> References: <53282E33.8080300@oracle.com> Message-ID: <53285176.6090100@oracle.com> On 2014-03-18 12:29, Erik Joelsson wrote: > Hello, > > The file jdk/make/closed/javax/crypto/doc/README.txt is not available > to licensees. The makefiles currently assumes it's always there as > long as we build crypto and it's not an OpenJDK build. This change > also checks that the file is actually in the source too. Looks good to me. /Magnus From tim.bell at oracle.com Tue Mar 18 15:04:38 2014 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 18 Mar 2014 08:04:38 -0700 Subject: RFR: JDK-8037483: issue with the crypto / sec zip unzipping in the jdk8 build In-Reply-To: <532826E3.5050203@oracle.com> References: <5328232A.3030000@oracle.com> <532826E3.5050203@oracle.com> Message-ID: <53286086.20505@oracle.com> Hi Erik: > On 2014-03-18 11:42, Erik Joelsson wrote: >> Please review this very simple fix to unzipping pre built security >> classes. When building incrementally, unzip will go into interactive >> mode and ask if it should overwrite files. The fix is to add -q -o to >> the unzip line as is done on all other invocations of unzip. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8037483 >> Patch inline: >> diff -r a94a8944bd2b make/Import.gmk >> --- a/make/Import.gmk >> +++ b/make/Import.gmk >> @@ -252,7 +252,7 @@ >> $(ECHO) Unzipping $(> $(MKDIR) -p $(@D) >> $(RM) $@ >> - ($(CD) $(JDK_OUTPUTDIR) && $(UNZIP) $< > $@.tmp) >> + ($(CD) $(JDK_OUTPUTDIR) && $(UNZIP) -q -o $< > $@.tmp) >> $(MV) $@.tmp $@ >> endef > > Looks good to me. > > /Magnus Looks good to me as well. Tim From tim.bell at oracle.com Tue Mar 18 15:16:00 2014 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 18 Mar 2014 08:16:00 -0700 Subject: RFR: JDK-8037414: Licensee Source Bundles build issue In-Reply-To: <53285176.6090100@oracle.com> References: <53282E33.8080300@oracle.com> <53285176.6090100@oracle.com> Message-ID: <53286330.1040605@oracle.com> Hi Erik: > On 2014-03-18 12:29, Erik Joelsson wrote: >> Hello, >> >> The file jdk/make/closed/javax/crypto/doc/README.txt is not available >> to licensees. The makefiles currently assumes it's always there as >> long as we build crypto and it's not an OpenJDK build. This change >> also checks that the file is actually in the source too. > > Looks good to me. > > /Magnus Looks good to me as well. Tim From gary.collins at oracle.com Tue Mar 18 15:24:16 2014 From: gary.collins at oracle.com (Gary Collins) Date: Tue, 18 Mar 2014 08:24:16 -0700 Subject: RFR: JDK-8037414: Licensee Source Bundles build issue In-Reply-To: <53282E33.8080300@oracle.com> References: <53282E33.8080300@oracle.com> Message-ID: <36D1FB52-8388-438C-8D4A-5B5540E9F68F@oracle.com> Looks good.. This was one of our other possible fixes as well. Gary On Mar 18, 2014, at 4:29 AM, Erik Joelsson wrote: > Hello, > > The file jdk/make/closed/javax/crypto/doc/README.txt is not available to licensees. The makefiles currently assumes it's always there as long as we build crypto and it's not an OpenJDK build. This change also checks that the file is actually in the source too. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8037414 > Patch inline: > diff -r a94a8944bd2b make/CreateSecurityJars.gmk > --- a/make/CreateSecurityJars.gmk > +++ b/make/CreateSecurityJars.gmk > @@ -284,11 +284,13 @@ > TARGETS += $(LOCAL_POLICY_JAR_LIMITED_UNSIGNED) $(LOCAL_POLICY_JAR_UNLIMITED_UNSIGNED) > > ifndef OPENJDK > - $(JDK_OUTPUTDIR)/jce/unsigned/policy/unlimited/README.txt: \ > - $(JDK_TOPDIR)/make/closed/javax/crypto/doc/README.txt > + ifneq ($(wildcard $(JDK_TOPDIR)/make/closed/javax/crypto/doc/README.txt), ) > + $(JDK_OUTPUTDIR)/jce/unsigned/policy/unlimited/README.txt: \ > + $(JDK_TOPDIR)/make/closed/javax/crypto/doc/README.txt > $(install-file) > > - TARGETS += $(JDK_OUTPUTDIR)/jce/unsigned/policy/unlimited/README.txt > + TARGETS += $(JDK_OUTPUTDIR)/jce/unsigned/policy/unlimited/README.txt > + endif > endif > endif > > /Erik From gary.collins at oracle.com Tue Mar 18 15:25:42 2014 From: gary.collins at oracle.com (Gary Collins) Date: Tue, 18 Mar 2014 08:25:42 -0700 Subject: RFR: JDK-8037414: Licensee Source Bundles build issue In-Reply-To: <53282E33.8080300@oracle.com> References: <53282E33.8080300@oracle.com> Message-ID: Erik, We will need this fix backported to all 8uX releases as well as 9.. Thanks for getting this done so quickly. Thanks, Gary On Mar 18, 2014, at 4:29 AM, Erik Joelsson wrote: > Hello, > > The file jdk/make/closed/javax/crypto/doc/README.txt is not available to licensees. The makefiles currently assumes it's always there as long as we build crypto and it's not an OpenJDK build. This change also checks that the file is actually in the source too. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8037414 > Patch inline: > diff -r a94a8944bd2b make/CreateSecurityJars.gmk > --- a/make/CreateSecurityJars.gmk > +++ b/make/CreateSecurityJars.gmk > @@ -284,11 +284,13 @@ > TARGETS += $(LOCAL_POLICY_JAR_LIMITED_UNSIGNED) $(LOCAL_POLICY_JAR_UNLIMITED_UNSIGNED) > > ifndef OPENJDK > - $(JDK_OUTPUTDIR)/jce/unsigned/policy/unlimited/README.txt: \ > - $(JDK_TOPDIR)/make/closed/javax/crypto/doc/README.txt > + ifneq ($(wildcard $(JDK_TOPDIR)/make/closed/javax/crypto/doc/README.txt), ) > + $(JDK_OUTPUTDIR)/jce/unsigned/policy/unlimited/README.txt: \ > + $(JDK_TOPDIR)/make/closed/javax/crypto/doc/README.txt > $(install-file) > > - TARGETS += $(JDK_OUTPUTDIR)/jce/unsigned/policy/unlimited/README.txt > + TARGETS += $(JDK_OUTPUTDIR)/jce/unsigned/policy/unlimited/README.txt > + endif > endif > endif > > /Erik From volker.simonis at gmail.com Tue Mar 18 17:26:59 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 18 Mar 2014 18:26:59 +0100 Subject: RFR[9](XS): 8037298: Export HotSpots 'optimized' (i.e. not-product) configuration in the top-level configure/makefile In-Reply-To: <532821EF.7070308@oracle.com> References: <5322CF97.6080301@oracle.com> <532821EF.7070308@oracle.com> Message-ID: On Tue, Mar 18, 2014 at 11:37 AM, Magnus Ihse Bursie wrote: > On 2014-03-14 17:55, Volker Simonis wrote: >> >> Hi Magnus, >> >> thanks for your detailed comments. >> >> I generally agree with your analysis of the problem. >> >> However, as you correctly noticed, the 'optimized' configuration is >> actually a "HotSpot only" concept. It is used to enable extra >> options/functionality which should not be shipped to the customer. >> >> Everything flagged with "#ifndef PRODUCT" in HotSpot is enabled by >> default in the "slowdebug" and "fastdebug" configuration - so no >> problem. But the Hotspot has this extra configuration called >> 'optimized' which is exactly like a release build, but with the extra, >> "#ifndef PRODUCT" stuff enabled. This may be useful for example for >> testing/benchmarking new functionality (i.e. you don't want to >> benchmark with a debug build). >> >> There's no general 'optimized' concept for the jdk and the other >> repositories as far as I can see. The "PRODUCT" macro is only used in >> src/share/native/com/sun/java/util/jar/pack/* within the 'jdk/' >> repository (and it is used there with a DEBUG/ASSERT semantics). >> >> I'd therefore propose to slightly modify my change as follows: >> >> optimized ) >> DEBUG_LEVEL="release" >> VARIANT="OPT" >> FASTDEBUG="false" >> DEBUG_CLASSFILES="false" >> BUILD_VARIANT_RELEASE="-optimized" >> HOTSPOT_DEBUG_LEVEL="optimized" >> HOTSPOT_EXPORT="optimized" >> ;; > > > Okay. This seems more robust. > > However, I think it's a bit scary to change the value of DEBUG_LEVEL, it's > sort of considered to be a straight mapping from the configure command line > option. I'm okay with it, but it needs to be done more explicitely. Either a > comment at the place where you modify it to "release", or -- even better -- > a separate if statement after the case block that clearly shows that > optimized is replaced with release, with proper comments. > Done. Please see the new webrev at: http://cr.openjdk.java.net/~simonis/webrevs/8037298_3/ > Also, you do not need to do AC_SUBST unless you publish the value in > spec.gmk. If you want to use the variable HOTSPOT_DEBUG_LEVEL in the > makefiles, you need to add it to spec.gmk.in (or hotspot-spec.gmk.in). If > not, you do not need the AC_SUBST. > You're right. I only need HOTSPOT_DEBUG_LEVEL in help.m4 and for that purpose AC_SUBST isn't neccessary, so I removed it. > Apart from that, the change looks good. > Thanks. Could you please push this change for me because it requires the regeneration of generated-configure.sh and potentially also the regeneration of closed configure files which I can't do. Regards, Volker > /Magnus From gnu.andrew at redhat.com Tue Mar 18 17:28:54 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 18 Mar 2014 13:28:54 -0400 (EDT) Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <53280AF0.5000502@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <53280AF0.5000502@oracle.com> Message-ID: <874803482.1166247.1395163734109.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 2014-03-18 02:19, Andrew Hughes wrote: > > Do we need more than just the following three alternatives? > > > > #1. No debugging information at all. > > #2. Debugging information left in the original binaries. > > #3. Debugging information stripped from the binaries and zipped in separate > > files. > > > > It sounds to me like Oracle want #3, while distros want #2 and I imagine > > some > > end users may just want #1 for a faster, smaller build. > > I'm completely thinking along your lines here. I think we should focus > on the end result, not the specific implementations details. I've been > thinking about exposing a configure option like this: > > --with-debug-symbols=none (for #1) > --with-debug-symbols=internal (for #2) > --with-debug-symbols=zipped (for #3) > > but perhaps with better names. I also imagine there might be a use case > for yet another option, > #4. Debuggin information stripped from the binaries, but not zipped > > expressed like this > --with-debug-symbols=external > > And then this would be the only user interface needed, and the rest of > the current set of not-really-clear flags can be hidden inside the > configure script. > > For compatibility reasons, the default would be > --with-debug-symbols=zipped (which is called "FDS" here), just as we > currently do, but distributions would just need to add a > --with-debug-symbols=internal to get what they want. > > /Magnus > That sounds perfect. We already have to change numerous defaults; one more isn't an issue. The problem at the moment is that, at least in 7, I've had to patch the Makefiles to get what we want (i.e. making STRIP_POLICY=no_strip not create duplicate debuginfo in zipped debuginfo files) and that should be avoided if possible. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From daniel.daugherty at oracle.com Tue Mar 18 17:57:04 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 18 Mar 2014 11:57:04 -0600 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> Message-ID: <532888F0.2050402@oracle.com> On 3/17/14 7:19 PM, Andrew Hughes wrote: > ----- Original Message ----- >> On 3/3/14 2:49 PM, Omair Majid wrote: >>> * David Holmes [2014-02-28 18:48]: >>>> There are three pieces to all of this: >>>> >>>> 1. Generating debug symbols in the binaries (via gcc -g or whatever) >>>> 2. Generating debuginfo files (zipped or not) (FDS) >>>> 3. Stripping debug symbols from the binaries (strip-policy) >>>> >>>> It may be that we don't have clean separation between them, and if so >>>> that should be fixed, but I don't see the current proposal as the way >>>> forward. >>> Any chance we could clean up the names too? It's not obvious to me why >>> FDS means 'generating debuginfo files'. >> FDS stands for Full Debug Symbols and is defined that way in >> quite a few Makefiles... We just call it FDS for short... >> > At least to me, Full Debug Symbols suggests #1 (i.e. that symbols are generated > in the binaries), not #2. That's why it sounded so odd to me when you suggested > turning it off, when we discussed this before. > > It's also not clear why you'd want a situation where #3 would be turned off, but > not #2, as you end up with two copies of the debug symbols. That's the problem > I believe we have with our builds; we can turn the stripping off, but then we > end up with duplicate debug information. > > Do we need more than just the following three alternatives? > > #1. No debugging information at all. > #2. Debugging information left in the original binaries. > #3. Debugging information stripped from the binaries and zipped in separate files. The way Oracle does it is complete debug info in the separate files and partial debug info left in the original binaries so you get symbol names in stack traces for those cases where the full debug info bundles are not available. I'm not clear whether we need a 4th alternative or if #3 covers this case. Dan > > It sounds to me like Oracle want #3, while distros want #2 and I imagine some > end users may just want #1 for a faster, smaller build. From gnu.andrew at redhat.com Tue Mar 18 18:22:59 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 18 Mar 2014 14:22:59 -0400 (EDT) Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <532888F0.2050402@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <532888F0.2050402@oracle.com> Message-ID: <1371463485.1186545.1395166979412.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 3/17/14 7:19 PM, Andrew Hughes wrote: > > ----- Original Message ----- > >> On 3/3/14 2:49 PM, Omair Majid wrote: > >>> * David Holmes [2014-02-28 18:48]: > >>>> There are three pieces to all of this: > >>>> > >>>> 1. Generating debug symbols in the binaries (via gcc -g or whatever) > >>>> 2. Generating debuginfo files (zipped or not) (FDS) > >>>> 3. Stripping debug symbols from the binaries (strip-policy) > >>>> > >>>> It may be that we don't have clean separation between them, and if so > >>>> that should be fixed, but I don't see the current proposal as the way > >>>> forward. > >>> Any chance we could clean up the names too? It's not obvious to me why > >>> FDS means 'generating debuginfo files'. > >> FDS stands for Full Debug Symbols and is defined that way in > >> quite a few Makefiles... We just call it FDS for short... > >> > > At least to me, Full Debug Symbols suggests #1 (i.e. that symbols are > > generated > > in the binaries), not #2. That's why it sounded so odd to me when you > > suggested > > turning it off, when we discussed this before. > > > > It's also not clear why you'd want a situation where #3 would be turned > > off, but > > not #2, as you end up with two copies of the debug symbols. That's the > > problem > > I believe we have with our builds; we can turn the stripping off, but then > > we > > end up with duplicate debug information. > > > > Do we need more than just the following three alternatives? > > > > #1. No debugging information at all. > > #2. Debugging information left in the original binaries. > > #3. Debugging information stripped from the binaries and zipped in separate > > files. > > The way Oracle does it is complete debug info in the > separate files and partial debug info left in the original > binaries so you get symbol names in stack traces for those > cases where the full debug info bundles are not available. > > I'm not clear whether we need a 4th alternative or if #3 > covers this case. > The intent was for #3 to cover this case (i.e. whatever Oracle does now) and for #2 to be what the GNU/Linux distributions want (i.e. binaries with all debuginfo generated and left intact so they can do their own stripping). > Dan > > > > > > It sounds to me like Oracle want #3, while distros want #2 and I imagine > > some > > end users may just want #1 for a faster, smaller build. > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From bradford.wetmore at oracle.com Tue Mar 18 19:09:31 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 18 Mar 2014 12:09:31 -0700 Subject: RFR: JDK-8037483: issue with the crypto / sec zip unzipping in the jdk8 build In-Reply-To: <53286086.20505@oracle.com> References: <5328232A.3030000@oracle.com> <532826E3.5050203@oracle.com> <53286086.20505@oracle.com> Message-ID: <532899EB.3070902@oracle.com> Looks good. Brad On 3/18/2014 8:04 AM, Tim Bell wrote: > Hi Erik: > >> On 2014-03-18 11:42, Erik Joelsson wrote: >>> Please review this very simple fix to unzipping pre built security >>> classes. When building incrementally, unzip will go into interactive >>> mode and ask if it should overwrite files. The fix is to add -q -o to >>> the unzip line as is done on all other invocations of unzip. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8037483 >>> Patch inline: >>> diff -r a94a8944bd2b make/Import.gmk >>> --- a/make/Import.gmk >>> +++ b/make/Import.gmk >>> @@ -252,7 +252,7 @@ >>> $(ECHO) Unzipping $(>> $(MKDIR) -p $(@D) >>> $(RM) $@ >>> - ($(CD) $(JDK_OUTPUTDIR) && $(UNZIP) $< > $@.tmp) >>> + ($(CD) $(JDK_OUTPUTDIR) && $(UNZIP) -q -o $< > $@.tmp) >>> $(MV) $@.tmp $@ >>> endef >> >> Looks good to me. >> >> /Magnus > > Looks good to me as well. > > Tim > From daniel.daugherty at oracle.com Tue Mar 18 21:15:55 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 18 Mar 2014 15:15:55 -0600 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <1371463485.1186545.1395166979412.JavaMail.zimbra@redhat.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <532888F0.2050402@oracle.com> <1371463485.1186545.1395166979412.JavaMail.zimbra@redhat.com> Message-ID: <5328B78B.8020806@oracle.com> On 3/18/14 12:22 PM, Andrew Hughes wrote: > ----- Original Message ----- >> On 3/17/14 7:19 PM, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> On 3/3/14 2:49 PM, Omair Majid wrote: >>>>> * David Holmes [2014-02-28 18:48]: >>>>>> There are three pieces to all of this: >>>>>> >>>>>> 1. Generating debug symbols in the binaries (via gcc -g or whatever) >>>>>> 2. Generating debuginfo files (zipped or not) (FDS) >>>>>> 3. Stripping debug symbols from the binaries (strip-policy) >>>>>> >>>>>> It may be that we don't have clean separation between them, and if so >>>>>> that should be fixed, but I don't see the current proposal as the way >>>>>> forward. >>>>> Any chance we could clean up the names too? It's not obvious to me why >>>>> FDS means 'generating debuginfo files'. >>>> FDS stands for Full Debug Symbols and is defined that way in >>>> quite a few Makefiles... We just call it FDS for short... >>>> >>> At least to me, Full Debug Symbols suggests #1 (i.e. that symbols are >>> generated >>> in the binaries), not #2. That's why it sounded so odd to me when you >>> suggested >>> turning it off, when we discussed this before. >>> >>> It's also not clear why you'd want a situation where #3 would be turned >>> off, but >>> not #2, as you end up with two copies of the debug symbols. That's the >>> problem >>> I believe we have with our builds; we can turn the stripping off, but then >>> we >>> end up with duplicate debug information. >>> >>> Do we need more than just the following three alternatives? >>> >>> #1. No debugging information at all. >>> #2. Debugging information left in the original binaries. >>> #3. Debugging information stripped from the binaries and zipped in separate >>> files. >> The way Oracle does it is complete debug info in the >> separate files and partial debug info left in the original >> binaries so you get symbol names in stack traces for those >> cases where the full debug info bundles are not available. >> >> I'm not clear whether we need a 4th alternative or if #3 >> covers this case. >> > The intent was for #3 to cover this case (i.e. whatever Oracle does now) > and for #2 to be what the GNU/Linux distributions want (i.e. binaries with > all debuginfo generated and left intact so they can do their own stripping). Very cool. Thanks for the clarification. Dan > >> Dan >> >> >>> It sounds to me like Oracle want #3, while distros want #2 and I imagine >>> some >>> end users may just want #1 for a faster, smaller build. >> From andreas.lundblad at oracle.com Wed Mar 19 08:49:40 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Wed, 19 Mar 2014 09:49:40 +0100 Subject: RFR: 8035063: Option handling in sjavac needs to be rewritten Message-ID: <20140319084939.GA17590@e6430> Hi compiler-dev + build-dev, Please review the fix for JDK-8035063 and JDK-8037085 which involves changes to sjavac (option handling) and dev/ + dev/jdk build files. Description: - Sjavac relied on passing around the main arg array to whatever part of the code that were potentially affected by command line options. The patch restructures the code so that all option are validated and parsed up front. - A recent commit in the JDK repository exposed another sjavac bug caused by having directory names that were not valid package identifiers. The patch changes sjavac to handle directories instead of packages... - ...which required modifying a couple of .gmk so that arguments are passed as directories (separated by "/") instead of packages (separated with ".") - Finally the patch adds a couple of unit tests which cover the new code. Link to webrevs: http://cr.openjdk.java.net/~alundblad/8035063/ - dev build (dev/make/common/JavaCompilation.gmk) - jdk build (dev/jdk/make/CompileJavaClasses.gmk) - langtools (the sjavac changes + tests) Links to bug reports: https://bugs.openjdk.java.net/browse/JDK-8035063 https://bugs.openjdk.java.net/browse/JDK-8037085 -- Andreas From erik.joelsson at oracle.com Wed Mar 19 09:03:33 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 19 Mar 2014 10:03:33 +0100 Subject: RFR: 8035063: Option handling in sjavac needs to be rewritten In-Reply-To: <20140319084939.GA17590@e6430> References: <20140319084939.GA17590@e6430> Message-ID: <53295D65.7040707@oracle.com> Hello, The input from our makefiles changes from "-i some.package" to "-i some/package/*". IIRC the include flag works recursively for sub packages. Will the single * do the same? /Erik On 2014-03-19 09:49, Andreas Lundblad wrote: > Hi compiler-dev + build-dev, > > Please review the fix for JDK-8035063 and JDK-8037085 which involves changes to sjavac (option handling) and dev/ + dev/jdk build files. > > > Description: > > - Sjavac relied on passing around the main arg array to whatever part of the code that were potentially affected by command line options. The patch restructures the code so that all option are validated and parsed up front. > > - A recent commit in the JDK repository exposed another sjavac bug caused by having directory names that were not valid package identifiers. The patch changes sjavac to handle directories instead of packages... > > - ...which required modifying a couple of .gmk so that arguments are passed as directories (separated by "/") instead of packages (separated with ".") > > - Finally the patch adds a couple of unit tests which cover the new code. > > > Link to webrevs: > http://cr.openjdk.java.net/~alundblad/8035063/ > - dev build (dev/make/common/JavaCompilation.gmk) > - jdk build (dev/jdk/make/CompileJavaClasses.gmk) > - langtools (the sjavac changes + tests) > > > Links to bug reports: > https://bugs.openjdk.java.net/browse/JDK-8035063 > https://bugs.openjdk.java.net/browse/JDK-8037085 > > -- Andreas From andreas.lundblad at oracle.com Wed Mar 19 10:17:58 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Wed, 19 Mar 2014 11:17:58 +0100 Subject: RFR: 8035063: Option handling in sjavac needs to be rewritten In-Reply-To: <53295D65.7040707@oracle.com> References: <20140319084939.GA17590@e6430> <53295D65.7040707@oracle.com> Message-ID: <20140319101757.GA3230@e6430> On Wed, Mar 19, 2014 at 10:03:33AM +0100, Erik Joelsson wrote: > Hello, > > The input from our makefiles changes from "-i some.package" to "-i > some/package/*". IIRC the include flag works recursively for sub > packages. Will the single * do the same? > > /Erik That's strange. What used to be "-i some.package" should now be "-i some/package". The -i works recursively only if the pattern ends with a '*'. I did however log all patterns that were given as arguments to -i during a 'make clean images' and all those patterns ended with a '.*'. (Maby I missed some patterns somewhere?) Regardless, if something that used to be "some.package" and is now "some/package/*", I'd say it's a bug. -- Andreas From aph at redhat.com Tue Mar 18 18:25:34 2014 From: aph at redhat.com (Andrew Haley) Date: Tue, 18 Mar 2014 18:25:34 +0000 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <1371463485.1186545.1395166979412.JavaMail.zimbra@redhat.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <532888F0.2050402@oracle.com> <1371463485.1186545.1395166979412.JavaMail.zimbra@redhat.com> Message-ID: <53288F9E.6070309@redhat.com> On 03/18/2014 06:22 PM, Andrew Hughes wrote: > The intent was for #3 to cover this case (i.e. whatever Oracle does now) > and for #2 to be what the GNU/Linux distributions want (i.e. binaries with > all debuginfo generated and left intact so they can do their own stripping). Mmm, but maybe that will break things when debuginfo isn't installed. In fact, I already know that it has broken some things. So it's not ideal. Andrew. From erik.joelsson at oracle.com Wed Mar 19 11:29:03 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 19 Mar 2014 12:29:03 +0100 Subject: RFR: 8035063: Option handling in sjavac needs to be rewritten In-Reply-To: <20140319101757.GA3230@e6430> References: <20140319084939.GA17590@e6430> <53295D65.7040707@oracle.com> <20140319101757.GA3230@e6430> Message-ID: <53297F7F.7080002@oracle.com> Ah, I see now, it was "-i some.package.*" in the original code. Build part looks good to me now. /Erik On 2014-03-19 11:17, Andreas Lundblad wrote: > On Wed, Mar 19, 2014 at 10:03:33AM +0100, Erik Joelsson wrote: >> Hello, >> >> The input from our makefiles changes from "-i some.package" to "-i >> some/package/*". IIRC the include flag works recursively for sub >> packages. Will the single * do the same? >> >> /Erik > That's strange. What used to be "-i some.package" should now be "-i some/package". > > The -i works recursively only if the pattern ends with a '*'. > > I did however log all patterns that were given as arguments to -i during a 'make clean images' and all those patterns ended with a '.*'. (Maby I missed some patterns somewhere?) > > Regardless, if something that used to be "some.package" and is now "some/package/*", I'd say it's a bug. > > -- Andreas From staffan.larsen at oracle.com Wed Mar 19 12:30:34 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 19 Mar 2014 13:30:34 +0100 Subject: RFR 8037825 Fix warnings and enable "warnings as errors" in serviceability native libraries Message-ID: The serviceability libraries (as defined by jdk/make/lib/ServiceabilityLibraries.gmk) should be compiled with "warnings as errors". To enable this all current warnings need to be fixed. The background for this is that we recently had a bug that could have easily been avoided if we had paid attention to the warnings. webrev: http://cr.openjdk.java.net/~sla/8037825/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8037825 Thanks, /Staffan Here is a list of warnings that I have fixed: linux-i586 jdk/src/share/back/eventHandler.c: In function 'eventHandler_createPermanentInternal': jdk/src/share/back/eventHandler.c:1685: error: cast from pointer to integer of different size jdk/src/share/back/eventHandler.c: In function 'eventHandler_createInternalThreadOnly': jdk/src/share/back/eventHandler.c:1694: error: cast from pointer to integer of different size jdk/src/share/back/inStream.c: In function 'inStream_readLong': jdk/src/share/back/inStream.c:147: error: integer constant is too large for 'long' type macosx jdk/src/share/back/SDE.c:51:1: warning: "true" redefined jdk/src/share/back/SDE.c:52:1: warning: "false" redefined jdk/src/share/back/log_messages.c: In function ?get_time_stamp?: jdk/src/share/back/log_messages.c:69: warning: format not a string literal, argument types not checked jdk/src/share/back/log_messages.c: In function ?log_message_end?: jdk/src/share/back/log_messages.c:174: warning: cast from pointer to integer of different size jdk/src/solaris/native/sun/management/MacosxOperatingSystem.c: In function 'Java_sun_management_OperatingSystemImpl_getProcessCpuLoad0': jdk/src/solaris/native/sun/management/MacosxOperatingSystem.c:136: warning: implicit declaration of function 'JVM_ActiveProcessorCount' windows jdk/src/share/back/error_messages.c(328) : warning C4996: '_sleep': This function or variable has been superceded by newer library or operating system functionality. Consider using Sleep instead. See online help for details. jdk/src/windows/back/linker_md.c(62) : warning C4013: 'free' undefined; assuming extern returning int jdk/src/share/instrument/PathCharsValidator.c(49) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data jdk/src/share/instrument/PathCharsValidator.c(62) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data jdk/src/share/instrument/PathCharsValidator.c(179) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data solaris-x64 jdk/src/share/back/inStream.c, line 147: constant promoted to unsigned long long From magnus.ihse.bursie at oracle.com Wed Mar 19 12:59:15 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 19 Mar 2014 13:59:15 +0100 Subject: RFR 8037825 Fix warnings and enable "warnings as errors" in serviceability native libraries In-Reply-To: References: Message-ID: <532994A3.9020703@oracle.com> On 2014-03-19 13:30, Staffan Larsen wrote: > The serviceability libraries (as defined by jdk/make/lib/ServiceabilityLibraries.gmk) should be compiled with "warnings as errors". To enable this all current warnings need to be fixed. > > The background for this is that we recently had a bug that could have easily been avoided if we had paid attention to the warnings. > > webrev: http://cr.openjdk.java.net/~sla/8037825/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8037825 Hi Staffan, I have only looked at the build part of the fix. I have one request: please check for toolchain type instead of operating system, e.g. ifeq ($(TOOLCHAIN_TYPE), microsoft) WARNINGS_ARE_ERRORS := /WX else ifeq ($(TOOLCHAIN_TYPE), solstudio) WARNINGS_ARE_ERRORS := -errtags -errwarn=%all else ifeq ($(TOOLCHAIN_TYPE), gcc) WARNINGS_ARE_ERRORS := -Werror else ifeq ($(TOOLCHAIN_TYPE), clang) WARNINGS_ARE_ERRORS := -Werror endif (with the clang part only if you have tested on clang, that is). Apart from this, it looks good. Thank you for hunting down those warnings! Great job! /Magnus From erik.joelsson at oracle.com Wed Mar 19 13:03:49 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 19 Mar 2014 14:03:49 +0100 Subject: RFR 8037825 Fix warnings and enable "warnings as errors" in serviceability native libraries In-Reply-To: References: Message-ID: <532995B5.30902@oracle.com> Hello, Nice work! Removing warnings and enforcing them is definitely something we like. For the makefile change, ideally the new variable WARNINGS_ARE_ERRORS should be set in configure. I would suggest flags.m4, in FLAGS_SETUP_COMPILER_FLAGS_MISC. Also, instead of making the conditional on OS, it should be on the new variable TOOLCHAIN_TYPE. Perhaps the variable name should contain the word CFLAGS somewhere to make it more obvious what it applies to. /Erik On 2014-03-19 13:30, Staffan Larsen wrote: > The serviceability libraries (as defined by jdk/make/lib/ServiceabilityLibraries.gmk) should be compiled with "warnings as errors". To enable this all current warnings need to be fixed. > > The background for this is that we recently had a bug that could have easily been avoided if we had paid attention to the warnings. > > webrev: http://cr.openjdk.java.net/~sla/8037825/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8037825 > > Thanks, > /Staffan > > > Here is a list of warnings that I have fixed: > > linux-i586 > > jdk/src/share/back/eventHandler.c: In function 'eventHandler_createPermanentInternal': > jdk/src/share/back/eventHandler.c:1685: error: cast from pointer to integer of different size > jdk/src/share/back/eventHandler.c: In function 'eventHandler_createInternalThreadOnly': > jdk/src/share/back/eventHandler.c:1694: error: cast from pointer to integer of different size > > jdk/src/share/back/inStream.c: In function 'inStream_readLong': > jdk/src/share/back/inStream.c:147: error: integer constant is too large for 'long' type > > > macosx > > jdk/src/share/back/SDE.c:51:1: warning: "true" redefined > jdk/src/share/back/SDE.c:52:1: warning: "false" redefined > > jdk/src/share/back/log_messages.c: In function ?get_time_stamp?: > jdk/src/share/back/log_messages.c:69: warning: format not a string literal, argument types not checked > jdk/src/share/back/log_messages.c: In function ?log_message_end?: > jdk/src/share/back/log_messages.c:174: warning: cast from pointer to integer of different size > > jdk/src/solaris/native/sun/management/MacosxOperatingSystem.c: In function 'Java_sun_management_OperatingSystemImpl_getProcessCpuLoad0': > jdk/src/solaris/native/sun/management/MacosxOperatingSystem.c:136: warning: implicit declaration of function 'JVM_ActiveProcessorCount' > > > windows > > jdk/src/share/back/error_messages.c(328) : warning C4996: '_sleep': This function or variable has been superceded by newer library or operating system functionality. Consider using Sleep instead. See online help for details. > > jdk/src/windows/back/linker_md.c(62) : warning C4013: 'free' undefined; assuming extern returning int > > jdk/src/share/instrument/PathCharsValidator.c(49) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data > jdk/src/share/instrument/PathCharsValidator.c(62) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data > jdk/src/share/instrument/PathCharsValidator.c(179) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data > > > solaris-x64 > > jdk/src/share/back/inStream.c, line 147: constant promoted to unsigned long long From andreas.lundblad at oracle.com Wed Mar 19 13:32:09 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Wed, 19 Mar 2014 14:32:09 +0100 Subject: RFR: 8035063: Option handling in sjavac needs to be rewritten In-Reply-To: References: <20140319084939.GA17590@e6430> <53295D65.7040707@oracle.com> <20140319101757.GA3230@e6430> <53297F7F.7080002@oracle.com> Message-ID: <20140319133208.GC3230@e6430> On Wed, Mar 19, 2014 at 01:58:21PM +0100, Fredrik ?hrstr?m wrote: > The code by itself looks good. However I think that changing from . to / is > a really bad idea. > > If someone committed a package directory that does not map correctly to the > package name, then that is a major problem. You will not find that source > through -sourcepath, which means that you just broke sjavac ability to > compile using multiple threads. This is just as bad as when Nashorn tried > to insert $ into java source file names! The horror, the horror. > > I.e. do not replace . with /. Fix the problem in the jdk. In this case, the directory did not contain any source files, just a bunch of resources for documentation, such as .gif-files. (How could it contain source files? A package may not contain a '-'.) So unless I misunderstood you, there should therefore be no problem in this case. I would prefer to see -i and -x as filters on what directories (not packages) exists in the subsequent source root: This is more in line with other options (-if, -xf, -src, ...) which all talk about paths and more general since each package corresponds to a directory, but only some directories correspond to packages. - Andreas From magnus.ihse.bursie at oracle.com Wed Mar 19 13:51:33 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 19 Mar 2014 14:51:33 +0100 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <53288F9E.6070309@redhat.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <532888F0.2050402@oracle.com> <1371463485.1186545.1395166979412.JavaMail.zimbra@redhat.com> <53288F9E.6070309@redhat.com> Message-ID: <5329A0E5.4000603@oracle.com> On 2014-03-18 19:25, Andrew Haley wrote: > On 03/18/2014 06:22 PM, Andrew Hughes wrote: >> The intent was for #3 to cover this case (i.e. whatever Oracle does now) >> and for #2 to be what the GNU/Linux distributions want (i.e. binaries with >> all debuginfo generated and left intact so they can do their own stripping). > Mmm, but maybe that will break things when debuginfo isn't installed. > In fact, I already know that it has broken some things. So it's not > ideal. Which case is it that will break? #3 or #2? What would an ideal solution be for you? /Magnus From magnus.ihse.bursie at oracle.com Wed Mar 19 13:57:13 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 19 Mar 2014 14:57:13 +0100 Subject: RFR: 8035063: Option handling in sjavac needs to be rewritten In-Reply-To: <20140319084939.GA17590@e6430> References: <20140319084939.GA17590@e6430> Message-ID: <5329A239.5040204@oracle.com> On 2014-03-19 09:49, Andreas Lundblad wrote: > Hi compiler-dev + build-dev, > > Please review the fix for JDK-8035063 and JDK-8037085 which involves changes to sjavac (option handling) and dev/ + dev/jdk build files. The build part looks good to me. /Magnus From erik.joelsson at oracle.com Wed Mar 19 13:58:51 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 19 Mar 2014 14:58:51 +0100 Subject: RFR: 8035063: Option handling in sjavac needs to be rewritten In-Reply-To: <20140319133208.GC3230@e6430> References: <20140319084939.GA17590@e6430> <53295D65.7040707@oracle.com> <20140319101757.GA3230@e6430> <53297F7F.7080002@oracle.com> <20140319133208.GC3230@e6430> Message-ID: <5329A29B.90804@oracle.com> I should fill in that the background for this change is that there are a bunch of directories named "doc-files" in the classes source dir. They have been there a long time. These contain html and gif files (mainly) that shouldn't get copied into the output classes directory. In a recent cleanup of the copy mechanism, I changed the copy rules to by default include html and gif files and explicitly exclude those that shouldn't be included, rather than explicitly listing what should be copied. Because of this, we now have the following exclude rules: # These directories should not be copied at all EXCLUDES += \ com/sun/org/apache/xml/internal/security/resource/schema \ java/awt/doc-files \ java/lang/doc-files \ javax/swing/doc-files \ javax/swing/text/doc-files \ javax/swing/plaf/synth/doc-files \ javax/swing/undo/doc-files \ sun/awt/X11/doc-files \ sun/util/cldr/resources \ # When building with sjavac, these get translated to "-e java.awt.doc-files.*" which sjavac does not accept, because doc-files are not proper package names. Another possible fix would be to filter out non valid package names from the excludes sent to sjavac. /Erik On 2014-03-19 14:32, Andreas Lundblad wrote: > On Wed, Mar 19, 2014 at 01:58:21PM +0100, Fredrik ?hrstr?m wrote: >> The code by itself looks good. However I think that changing from . to / is >> a really bad idea. >> >> If someone committed a package directory that does not map correctly to the >> package name, then that is a major problem. You will not find that source >> through -sourcepath, which means that you just broke sjavac ability to >> compile using multiple threads. This is just as bad as when Nashorn tried >> to insert $ into java source file names! The horror, the horror. >> >> I.e. do not replace . with /. Fix the problem in the jdk. > In this case, the directory did not contain any source files, just a bunch of resources for documentation, such as .gif-files. (How could it contain source files? A package may not contain a '-'.) So unless I misunderstood you, there should therefore be no problem in this case. > > I would prefer to see -i and -x as filters on what directories (not packages) exists in the subsequent source root: This is more in line with other options (-if, -xf, -src, ...) which all talk about paths and more general since each package corresponds to a directory, but only some directories correspond to packages. > > - Andreas From staffan.larsen at oracle.com Wed Mar 19 14:20:22 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 19 Mar 2014 15:20:22 +0100 Subject: RFR 8037825 Fix warnings and enable "warnings as errors" in serviceability native libraries In-Reply-To: <532995B5.30902@oracle.com> References: <532995B5.30902@oracle.com> Message-ID: <557ABEF7-7D08-41C3-BB6D-9525C78C32B1@oracle.com> Erik, Magnus, Thanks for the quick looks. Here is an updated version that adds the new variable to flags.m4 instead. http://cr.openjdk.java.net/~sla/8037825/webrev.01/root/ http://cr.openjdk.java.net/~sla/8037825/webrev.01/jdk/ Thanks, /Staffan On 19 mar 2014, at 14:03, Erik Joelsson wrote: > Hello, > > Nice work! Removing warnings and enforcing them is definitely something we like. > > For the makefile change, ideally the new variable WARNINGS_ARE_ERRORS should be set in configure. I would suggest flags.m4, in FLAGS_SETUP_COMPILER_FLAGS_MISC. Also, instead of making the conditional on OS, it should be on the new variable TOOLCHAIN_TYPE. Perhaps the variable name should contain the word CFLAGS somewhere to make it more obvious what it applies to. > > /Erik > > On 2014-03-19 13:30, Staffan Larsen wrote: >> The serviceability libraries (as defined by jdk/make/lib/ServiceabilityLibraries.gmk) should be compiled with "warnings as errors". To enable this all current warnings need to be fixed. >> >> The background for this is that we recently had a bug that could have easily been avoided if we had paid attention to the warnings. >> >> webrev: http://cr.openjdk.java.net/~sla/8037825/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8037825 >> >> Thanks, >> /Staffan >> >> >> Here is a list of warnings that I have fixed: >> >> linux-i586 >> >> jdk/src/share/back/eventHandler.c: In function 'eventHandler_createPermanentInternal': >> jdk/src/share/back/eventHandler.c:1685: error: cast from pointer to integer of different size >> jdk/src/share/back/eventHandler.c: In function 'eventHandler_createInternalThreadOnly': >> jdk/src/share/back/eventHandler.c:1694: error: cast from pointer to integer of different size >> >> jdk/src/share/back/inStream.c: In function 'inStream_readLong': >> jdk/src/share/back/inStream.c:147: error: integer constant is too large for 'long' type >> >> >> macosx >> >> jdk/src/share/back/SDE.c:51:1: warning: "true" redefined >> jdk/src/share/back/SDE.c:52:1: warning: "false" redefined >> >> jdk/src/share/back/log_messages.c: In function ?get_time_stamp?: >> jdk/src/share/back/log_messages.c:69: warning: format not a string literal, argument types not checked >> jdk/src/share/back/log_messages.c: In function ?log_message_end?: >> jdk/src/share/back/log_messages.c:174: warning: cast from pointer to integer of different size >> >> jdk/src/solaris/native/sun/management/MacosxOperatingSystem.c: In function 'Java_sun_management_OperatingSystemImpl_getProcessCpuLoad0': >> jdk/src/solaris/native/sun/management/MacosxOperatingSystem.c:136: warning: implicit declaration of function 'JVM_ActiveProcessorCount' >> >> >> windows >> >> jdk/src/share/back/error_messages.c(328) : warning C4996: '_sleep': This function or variable has been superceded by newer library or operating system functionality. Consider using Sleep instead. See online help for details. >> >> jdk/src/windows/back/linker_md.c(62) : warning C4013: 'free' undefined; assuming extern returning int >> >> jdk/src/share/instrument/PathCharsValidator.c(49) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data >> jdk/src/share/instrument/PathCharsValidator.c(62) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data >> jdk/src/share/instrument/PathCharsValidator.c(179) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data >> >> >> solaris-x64 >> >> jdk/src/share/back/inStream.c, line 147: constant promoted to unsigned long long > From oehrstroem at gmail.com Wed Mar 19 12:58:21 2014 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Wed, 19 Mar 2014 13:58:21 +0100 Subject: RFR: 8035063: Option handling in sjavac needs to be rewritten In-Reply-To: <53297F7F.7080002@oracle.com> References: <20140319084939.GA17590@e6430> <53295D65.7040707@oracle.com> <20140319101757.GA3230@e6430> <53297F7F.7080002@oracle.com> Message-ID: The code by itself looks good. However I think that changing from . to / is a really bad idea. If someone committed a package directory that does not map correctly to the package name, then that is a major problem. You will not find that source through -sourcepath, which means that you just broke sjavac ability to compile using multiple threads. This is just as bad as when Nashorn tried to insert $ into java source file names! The horror, the horror. I.e. do not replace . with /. Fix the problem in the jdk. //Fredrik 2014-03-19 12:29 GMT+01:00 Erik Joelsson : > Ah, I see now, it was "-i some.package.*" in the original code. Build part > looks good to me now. > > /Erik > > > On 2014-03-19 11:17, Andreas Lundblad wrote: > >> On Wed, Mar 19, 2014 at 10:03:33AM +0100, Erik Joelsson wrote: >> >>> Hello, >>> >>> The input from our makefiles changes from "-i some.package" to "-i >>> some/package/*". IIRC the include flag works recursively for sub >>> packages. Will the single * do the same? >>> >>> /Erik >>> >> That's strange. What used to be "-i some.package" should now be "-i >> some/package". >> >> The -i works recursively only if the pattern ends with a '*'. >> >> I did however log all patterns that were given as arguments to -i during >> a 'make clean images' and all those patterns ended with a '.*'. (Maby I >> missed some patterns somewhere?) >> >> Regardless, if something that used to be "some.package" and is now >> "some/package/*", I'd say it's a bug. >> >> -- Andreas >> > > From aph at redhat.com Wed Mar 19 14:54:32 2014 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Mar 2014 14:54:32 +0000 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <5329A0E5.4000603@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <532888F0.2050402@oracle.com> <1371463485.1186545.1395166979412.JavaMail.zimbra@redhat.com> <53288F9E.6070309@redhat.com> <5329A0E5.4000603@oracle.com> Message-ID: <5329AFA8.2090003@redhat.com> On 03/19/2014 01:51 PM, Magnus Ihse Bursie wrote: > On 2014-03-18 19:25, Andrew Haley wrote: >> On 03/18/2014 06:22 PM, Andrew Hughes wrote: >>> The intent was for #3 to cover this case (i.e. whatever Oracle does now) >>> and for #2 to be what the GNU/Linux distributions want (i.e. binaries with >>> all debuginfo generated and left intact so they can do their own stripping). >> Mmm, but maybe that will break things when debuginfo isn't installed. >> In fact, I already know that it has broken some things. So it's not >> ideal. > > Which case is it that will break? #3 or #2? What would an ideal solution > be for you? I think the problem was that jstack and jmap didn't work until the debuginfo package was installed. This tells me that the debuginfo stripping in our Linux build system is too aggressive for this purpose. I think that's something we must fix ourselves. What we really need from OpenJDK is a way to build with complete debuginfo in both binaries and jarfiles. Andrew. From gnu.andrew at redhat.com Wed Mar 19 14:57:31 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 19 Mar 2014 10:57:31 -0400 (EDT) Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <5329AFA8.2090003@redhat.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <532888F0.2050402@oracle.com> <1371463485.1186545.1395166979412.JavaMail.zimbra@redhat.com> <53288F9E.6070309@redhat.com> <5329A0E5.4000603@oracle.com> <5329AFA8.2090003@redhat.com> Message-ID: <955387107.1663490.1395241051025.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 03/19/2014 01:51 PM, Magnus Ihse Bursie wrote: > > On 2014-03-18 19:25, Andrew Haley wrote: > >> On 03/18/2014 06:22 PM, Andrew Hughes wrote: > >>> The intent was for #3 to cover this case (i.e. whatever Oracle does now) > >>> and for #2 to be what the GNU/Linux distributions want (i.e. binaries > >>> with > >>> all debuginfo generated and left intact so they can do their own > >>> stripping). > >> Mmm, but maybe that will break things when debuginfo isn't installed. > >> In fact, I already know that it has broken some things. So it's not > >> ideal. > > > > Which case is it that will break? #3 or #2? What would an ideal solution > > be for you? > > I think the problem was that jstack and jmap didn't work until the > debuginfo package was installed. This tells me that the debuginfo > stripping in our Linux build system is too aggressive for this purpose. > Yes, https://bugzilla.redhat.com/show_bug.cgi?id=1010786 The distro builds strip too much and remove the needed symtab from libjvm.so. > I think that's something we must fix ourselves. What we really > need from OpenJDK is a way to build with complete debuginfo in > both binaries and jarfiles. This was my intent with #2. The jstack/jmap issue needs to be fixed by stripping less debuginfo post-build on libjvm.so. > > Andrew. > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From philip.race at oracle.com Wed Mar 19 16:42:28 2014 From: philip.race at oracle.com (Phil Race) Date: Wed, 19 Mar 2014 09:42:28 -0700 Subject: [OpenJDK 2D-Dev] RFR: Allow using a system-installed lcms2 In-Reply-To: <5326DC34.3060602@oracle.com> References: <20140220224044.GB20217@redhat.com> <20140228212732.GG1965@redhat.com> <531101FE.2080600@oracle.com> <20140228232443.GB18442@redhat.com> <5326DC34.3060602@oracle.com> Message-ID: <5329C8F4.1080302@oracle.com> On 3/17/2014 4:27 AM, Magnus Ihse Bursie wrote: > > While we generally support moving files to a proper location, if this > move is causing trouble for Phil and the 2d team, we think it can be > an acceptable exception this time to just single out the LCMS.c file. > (This can be achieved by setting INCLUDE_FILES:=LCMS.c -- that will > automatically exclude other files in the SRC dirs.) If we do > reorganize the source code, we can handle where to move the files at > that time instead. This sounds like a reasonable plan. The final on disk bits in the JRE/lib/arch directory should however always show "liblcms.so" and in the case of a build which didn't select the system installed option this will contain everything. In the case the system installed option is selected this will be a small stub library containing just our glue code and have a runtime dependency on the system' liblcms2-2.so So we have no names clashes and consistency in what you see in the jre directory across platforms/configs. > Unfortunately there is not. However, I can help you run the neccessary > JPRT tests if we can get to a patch that 2d is comfortable with. > > /Magnus I don't think JPRT runs any relevant tests. As someone else just found out yesterday relying on it to test client code will bite you. However I really meant that we need to make sure that all platforms build *AND* that the closed builds will work too. So if you can help there, great, but I will want to try all of that myself too so that if any closed changes are needed we have them in place beforehand and aren't scrambling .. -phil. From erik.joelsson at oracle.com Wed Mar 19 16:47:31 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 19 Mar 2014 17:47:31 +0100 Subject: RFR 8037825 Fix warnings and enable "warnings as errors" in serviceability native libraries In-Reply-To: <557ABEF7-7D08-41C3-BB6D-9525C78C32B1@oracle.com> References: <532995B5.30902@oracle.com> <557ABEF7-7D08-41C3-BB6D-9525C78C32B1@oracle.com> Message-ID: <5329CA23.9010205@oracle.com> Build part looks good! Don't forget to push the closed generated configure. /Erik On 2014-03-19 15:20, Staffan Larsen wrote: > Erik, Magnus, > > Thanks for the quick looks. Here is an updated version that adds the new variable to flags.m4 instead. > > http://cr.openjdk.java.net/~sla/8037825/webrev.01/root/ > http://cr.openjdk.java.net/~sla/8037825/webrev.01/jdk/ > > Thanks, > /Staffan > > On 19 mar 2014, at 14:03, Erik Joelsson wrote: > >> Hello, >> >> Nice work! Removing warnings and enforcing them is definitely something we like. >> >> For the makefile change, ideally the new variable WARNINGS_ARE_ERRORS should be set in configure. I would suggest flags.m4, in FLAGS_SETUP_COMPILER_FLAGS_MISC. Also, instead of making the conditional on OS, it should be on the new variable TOOLCHAIN_TYPE. Perhaps the variable name should contain the word CFLAGS somewhere to make it more obvious what it applies to. >> >> /Erik >> >> On 2014-03-19 13:30, Staffan Larsen wrote: >>> The serviceability libraries (as defined by jdk/make/lib/ServiceabilityLibraries.gmk) should be compiled with "warnings as errors". To enable this all current warnings need to be fixed. >>> >>> The background for this is that we recently had a bug that could have easily been avoided if we had paid attention to the warnings. >>> >>> webrev: http://cr.openjdk.java.net/~sla/8037825/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8037825 >>> >>> Thanks, >>> /Staffan >>> >>> >>> Here is a list of warnings that I have fixed: >>> >>> linux-i586 >>> >>> jdk/src/share/back/eventHandler.c: In function 'eventHandler_createPermanentInternal': >>> jdk/src/share/back/eventHandler.c:1685: error: cast from pointer to integer of different size >>> jdk/src/share/back/eventHandler.c: In function 'eventHandler_createInternalThreadOnly': >>> jdk/src/share/back/eventHandler.c:1694: error: cast from pointer to integer of different size >>> >>> jdk/src/share/back/inStream.c: In function 'inStream_readLong': >>> jdk/src/share/back/inStream.c:147: error: integer constant is too large for 'long' type >>> >>> >>> macosx >>> >>> jdk/src/share/back/SDE.c:51:1: warning: "true" redefined >>> jdk/src/share/back/SDE.c:52:1: warning: "false" redefined >>> >>> jdk/src/share/back/log_messages.c: In function ?get_time_stamp?: >>> jdk/src/share/back/log_messages.c:69: warning: format not a string literal, argument types not checked >>> jdk/src/share/back/log_messages.c: In function ?log_message_end?: >>> jdk/src/share/back/log_messages.c:174: warning: cast from pointer to integer of different size >>> >>> jdk/src/solaris/native/sun/management/MacosxOperatingSystem.c: In function 'Java_sun_management_OperatingSystemImpl_getProcessCpuLoad0': >>> jdk/src/solaris/native/sun/management/MacosxOperatingSystem.c:136: warning: implicit declaration of function 'JVM_ActiveProcessorCount' >>> >>> >>> windows >>> >>> jdk/src/share/back/error_messages.c(328) : warning C4996: '_sleep': This function or variable has been superceded by newer library or operating system functionality. Consider using Sleep instead. See online help for details. >>> >>> jdk/src/windows/back/linker_md.c(62) : warning C4013: 'free' undefined; assuming extern returning int >>> >>> jdk/src/share/instrument/PathCharsValidator.c(49) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data >>> jdk/src/share/instrument/PathCharsValidator.c(62) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data >>> jdk/src/share/instrument/PathCharsValidator.c(179) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data >>> >>> >>> solaris-x64 >>> >>> jdk/src/share/back/inStream.c, line 147: constant promoted to unsigned long long From staffan.larsen at oracle.com Wed Mar 19 18:14:07 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 19 Mar 2014 19:14:07 +0100 Subject: RFR 8037825 Fix warnings and enable "warnings as errors" in serviceability native libraries In-Reply-To: <5329CA23.9010205@oracle.com> References: <532995B5.30902@oracle.com> <557ABEF7-7D08-41C3-BB6D-9525C78C32B1@oracle.com> <5329CA23.9010205@oracle.com> Message-ID: <08767C19-F22A-4914-800C-CEADC749FA44@oracle.com> On 19 mar 2014, at 17:47, Erik Joelsson wrote: > Build part looks good! Thanks. > > Don't forget to push the closed generated configure. I would have forgotten? /Staffan > > /Erik > > On 2014-03-19 15:20, Staffan Larsen wrote: >> Erik, Magnus, >> >> Thanks for the quick looks. Here is an updated version that adds the new variable to flags.m4 instead. >> >> http://cr.openjdk.java.net/~sla/8037825/webrev.01/root/ >> http://cr.openjdk.java.net/~sla/8037825/webrev.01/jdk/ >> >> Thanks, >> /Staffan >> >> On 19 mar 2014, at 14:03, Erik Joelsson wrote: >> >>> Hello, >>> >>> Nice work! Removing warnings and enforcing them is definitely something we like. >>> >>> For the makefile change, ideally the new variable WARNINGS_ARE_ERRORS should be set in configure. I would suggest flags.m4, in FLAGS_SETUP_COMPILER_FLAGS_MISC. Also, instead of making the conditional on OS, it should be on the new variable TOOLCHAIN_TYPE. Perhaps the variable name should contain the word CFLAGS somewhere to make it more obvious what it applies to. >>> >>> /Erik >>> >>> On 2014-03-19 13:30, Staffan Larsen wrote: >>>> The serviceability libraries (as defined by jdk/make/lib/ServiceabilityLibraries.gmk) should be compiled with "warnings as errors". To enable this all current warnings need to be fixed. >>>> >>>> The background for this is that we recently had a bug that could have easily been avoided if we had paid attention to the warnings. >>>> >>>> webrev: http://cr.openjdk.java.net/~sla/8037825/webrev.00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8037825 >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>> Here is a list of warnings that I have fixed: >>>> >>>> linux-i586 >>>> >>>> jdk/src/share/back/eventHandler.c: In function 'eventHandler_createPermanentInternal': >>>> jdk/src/share/back/eventHandler.c:1685: error: cast from pointer to integer of different size >>>> jdk/src/share/back/eventHandler.c: In function 'eventHandler_createInternalThreadOnly': >>>> jdk/src/share/back/eventHandler.c:1694: error: cast from pointer to integer of different size >>>> >>>> jdk/src/share/back/inStream.c: In function 'inStream_readLong': >>>> jdk/src/share/back/inStream.c:147: error: integer constant is too large for 'long' type >>>> >>>> >>>> macosx >>>> >>>> jdk/src/share/back/SDE.c:51:1: warning: "true" redefined >>>> jdk/src/share/back/SDE.c:52:1: warning: "false" redefined >>>> >>>> jdk/src/share/back/log_messages.c: In function ?get_time_stamp?: >>>> jdk/src/share/back/log_messages.c:69: warning: format not a string literal, argument types not checked >>>> jdk/src/share/back/log_messages.c: In function ?log_message_end?: >>>> jdk/src/share/back/log_messages.c:174: warning: cast from pointer to integer of different size >>>> >>>> jdk/src/solaris/native/sun/management/MacosxOperatingSystem.c: In function 'Java_sun_management_OperatingSystemImpl_getProcessCpuLoad0': >>>> jdk/src/solaris/native/sun/management/MacosxOperatingSystem.c:136: warning: implicit declaration of function 'JVM_ActiveProcessorCount' >>>> >>>> >>>> windows >>>> >>>> jdk/src/share/back/error_messages.c(328) : warning C4996: '_sleep': This function or variable has been superceded by newer library or operating system functionality. Consider using Sleep instead. See online help for details. >>>> >>>> jdk/src/windows/back/linker_md.c(62) : warning C4013: 'free' undefined; assuming extern returning int >>>> >>>> jdk/src/share/instrument/PathCharsValidator.c(49) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data >>>> jdk/src/share/instrument/PathCharsValidator.c(62) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data >>>> jdk/src/share/instrument/PathCharsValidator.c(179) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data >>>> >>>> >>>> solaris-x64 >>>> >>>> jdk/src/share/back/inStream.c, line 147: constant promoted to unsigned long long > From omajid at redhat.com Wed Mar 19 23:25:44 2014 From: omajid at redhat.com (Omair Majid) Date: Wed, 19 Mar 2014 19:25:44 -0400 Subject: [OpenJDK 2D-Dev] RFR: Allow using a system-installed lcms2 In-Reply-To: <5329C8F4.1080302@oracle.com> References: <20140220224044.GB20217@redhat.com> <20140228212732.GG1965@redhat.com> <531101FE.2080600@oracle.com> <20140228232443.GB18442@redhat.com> <5326DC34.3060602@oracle.com> <5329C8F4.1080302@oracle.com> Message-ID: <20140319232544.GB3167@redhat.com> Hi, * Phil Race [2014-03-19 12:39]: > On 3/17/2014 4:27 AM, Magnus Ihse Bursie wrote: > >While we generally support moving files to a proper location, if > >this move is causing trouble for Phil and the 2d team, we think it > >can be an acceptable exception this time to just single out the > >LCMS.c file. (This can be achieved by setting > >INCLUDE_FILES:=LCMS.c -- that will automatically exclude other > >files in the SRC dirs.) Magnus, thanks for the pointer! > This sounds like a reasonable plan. > The final on disk bits in the JRE/lib/arch directory should however always > show "liblcms.so" and in the case of a build which didn't select the system > installed option this will contain everything. The following webrevs implement this: Root: http://cr.openjdk.java.net/~omajid/webrevs/system-lcms/01/ JDK: http://cr.openjdk.java.net/~omajid/webrevs/system-lcms/01-jdk/ > I don't think JPRT runs any relevant tests. As someone else just found > out yesterday relying on it to test client code will bite you. I tested that this builds but nothing else so far. Any pointers to what is a good way to test this client code? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From mike.duigou at oracle.com Thu Mar 20 01:51:33 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 19 Mar 2014 18:51:33 -0700 Subject: RFR: 8030681 : (s) add "serve" command and --quiet and --verbose options to hgforest Message-ID: <5C7F5B32-B543-4B1F-AEE0-17D3317E7F5A@oracle.com> Hello all; This is a patch which adds support for the "serve" command to hgforest as well as providing --quiet and --verbose options. The serve command is particularly useful for sharing repos with virtual machines used for building/testing. Using "serve" is generally faster and has fewer problems than using shared filesystems (let me tell you! I if I have to delete one more .hg/store/lock file... Well, you don't want to know what would happen!) https://bugs.openjdk.java.net/browse/JDK-8030681 http://cr.openjdk.java.net/~mduigou/JDK-8030681/2/webrev/ This issue was originally created for another purpose, "--subrepo", that is being deferred to a future issue. Changes to hgforest to support the "trees" extension are likely coming and I wanted to get these changes out of the way before other hgforest changes complicate things. Cheers, Mike From magnus.ihse.bursie at oracle.com Thu Mar 20 08:49:23 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Mar 2014 09:49:23 +0100 Subject: RFR 8037825 Fix warnings and enable "warnings as errors" in serviceability native libraries In-Reply-To: <5329CA23.9010205@oracle.com> References: <532995B5.30902@oracle.com> <557ABEF7-7D08-41C3-BB6D-9525C78C32B1@oracle.com> <5329CA23.9010205@oracle.com> Message-ID: <532AAB93.7080608@oracle.com> On 2014-03-19 17:47, Erik Joelsson wrote: > Build part looks good! Build part looks good to me to. /Magnus From magnus.ihse.bursie at oracle.com Thu Mar 20 08:53:31 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Mar 2014 09:53:31 +0100 Subject: RFR: 8030681 : (s) add "serve" command and --quiet and --verbose options to hgforest In-Reply-To: <5C7F5B32-B543-4B1F-AEE0-17D3317E7F5A@oracle.com> References: <5C7F5B32-B543-4B1F-AEE0-17D3317E7F5A@oracle.com> Message-ID: <532AAC8B.4040307@oracle.com> On 2014-03-20 02:51, Mike Duigou wrote: > Hello all; > > This is a patch which adds support for the "serve" command to hgforest as well as providing --quiet and --verbose options. > > The serve command is particularly useful for sharing repos with virtual machines used for building/testing. Using "serve" is generally faster and has fewer problems than using shared filesystems (let me tell you! I if I have to delete one more .hg/store/lock file... Well, you don't want to know what would happen!) > > https://bugs.openjdk.java.net/browse/JDK-8030681 > > http://cr.openjdk.java.net/~mduigou/JDK-8030681/2/webrev/ I found this: # XXX mduigou I can't figure out how to make the root repo the serve "/" root. Is this something that ought to be fixed? Apart from that, it looks good to me. /Magnus From magnus.ihse.bursie at oracle.com Thu Mar 20 08:57:02 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Mar 2014 09:57:02 +0100 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <955387107.1663490.1395241051025.JavaMail.zimbra@redhat.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <532888F0.2050402@oracle.com> <1371463485.1186545.1395166979412.JavaMail.zimbra@redhat.com> <53288F9E.6070309@redhat.com> <5329A0E5.4000603@oracle.com> <5329AFA8.2090003@redhat.com> <955387107.1663490.1395241051025.JavaMail.zimbra@redhat.com> Message-ID: <532AAD5E.1000006@oracle.com> On 2014-03-19 15:57, Andrew Hughes wrote: > > >> I think that's something we must fix ourselves. What we really >> need from OpenJDK is a way to build with complete debuginfo in >> both binaries and jarfiles. > This was my intent with #2. The jstack/jmap issue needs to be fixed by > stripping less debuginfo post-build on libjvm.so. Ok, that sounds great. We provide a way to keep the debuginfo in the binaries, and then you can do your own magic, and everyone is happy. :) I'll re-target the original bug (JDK-8036003) so that it is about implementing such debuginfo handling instead. /Magnus From oehrstroem at gmail.com Thu Mar 20 09:00:55 2014 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Thu, 20 Mar 2014 10:00:55 +0100 Subject: RFR: 8035063: Option handling in sjavac needs to be rewritten In-Reply-To: <5329C39E.5040109@oracle.com> References: <20140319084939.GA17590@e6430> <53295D65.7040707@oracle.com> <20140319101757.GA3230@e6430> <53297F7F.7080002@oracle.com> <20140319133208.GC3230@e6430> <5329A29B.90804@oracle.com> <5329C39E.5040109@oracle.com> Message-ID: Ok, Eriks explanation makes sense. There might also be situations where you want to exclude/include copying META-INF files and such, that reside in non-package directories. So, changing from . to / is ok. In particular since sjavac cleverly detects and reports an error, if a source file is in the wrong package directory. See JavaCompilerWithDeps.java at the end, so there is already protection against messing up the source tree. :-) //Fredrik 2014-03-19 17:19 GMT+01:00 Jonathan Gibbons : > I think sjavac should filter out all directories which could not > correspond to package names. > > -- Jon > > > On 03/19/2014 06:58 AM, Erik Joelsson wrote: > >> I should fill in that the background for this change is that there are a >> bunch of directories named "doc-files" in the classes source dir. They have >> been there a long time. These contain html and gif files (mainly) that >> shouldn't get copied into the output classes directory. >> >> In a recent cleanup of the copy mechanism, I changed the copy rules to by >> default include html and gif files and explicitly exclude those that >> shouldn't be included, rather than explicitly listing what should be >> copied. Because of this, we now have the following exclude rules: >> >> # These directories should not be copied at all >> EXCLUDES += \ >> com/sun/org/apache/xml/internal/security/resource/schema \ >> java/awt/doc-files \ >> java/lang/doc-files \ >> javax/swing/doc-files \ >> javax/swing/text/doc-files \ >> javax/swing/plaf/synth/doc-files \ >> javax/swing/undo/doc-files \ >> sun/awt/X11/doc-files \ >> sun/util/cldr/resources \ >> # >> >> When building with sjavac, these get translated to "-e >> java.awt.doc-files.*" which sjavac does not accept, because doc-files are >> not proper package names. Another possible fix would be to filter out non >> valid package names from the excludes sent to sjavac. >> >> /Erik >> >> On 2014-03-19 14:32, Andreas Lundblad wrote: >> >>> On Wed, Mar 19, 2014 at 01:58:21PM +0100, Fredrik ?hrstr?m wrote: >>> >>>> The code by itself looks good. However I think that changing from . to >>>> / is >>>> a really bad idea. >>>> >>>> If someone committed a package directory that does not map correctly to >>>> the >>>> package name, then that is a major problem. You will not find that >>>> source >>>> through -sourcepath, which means that you just broke sjavac ability to >>>> compile using multiple threads. This is just as bad as when Nashorn >>>> tried >>>> to insert $ into java source file names! The horror, the horror. >>>> >>>> I.e. do not replace . with /. Fix the problem in the jdk. >>>> >>> In this case, the directory did not contain any source files, just a >>> bunch of resources for documentation, such as .gif-files. (How could it >>> contain source files? A package may not contain a '-'.) So unless I >>> misunderstood you, there should therefore be no problem in this case. >>> >>> I would prefer to see -i and -x as filters on what directories (not >>> packages) exists in the subsequent source root: This is more in line with >>> other options (-if, -xf, -src, ...) which all talk about paths and more >>> general since each package corresponds to a directory, but only some >>> directories correspond to packages. >>> >>> - Andreas >>> >> >> > From staffan.larsen at oracle.com Thu Mar 20 09:13:33 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 20 Mar 2014 10:13:33 +0100 Subject: RFR 8037825 Fix warnings and enable "warnings as errors" in serviceability native libraries In-Reply-To: <532AAB93.7080608@oracle.com> References: <532995B5.30902@oracle.com> <557ABEF7-7D08-41C3-BB6D-9525C78C32B1@oracle.com> <5329CA23.9010205@oracle.com> <532AAB93.7080608@oracle.com> Message-ID: <983CE070-BB04-4770-8041-B266D4CE8D0B@oracle.com> Thanks! Still need someone to look at the actual code changes. /Staffan On 20 mar 2014, at 09:49, Magnus Ihse Bursie wrote: > On 2014-03-19 17:47, Erik Joelsson wrote: >> Build part looks good! > > Build part looks good to me to. > > /Magnus > From Alan.Bateman at oracle.com Thu Mar 20 10:25:53 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 20 Mar 2014 10:25:53 +0000 Subject: RFR 8037825 Fix warnings and enable "warnings as errors" in serviceability native libraries In-Reply-To: <983CE070-BB04-4770-8041-B266D4CE8D0B@oracle.com> References: <532995B5.30902@oracle.com> <557ABEF7-7D08-41C3-BB6D-9525C78C32B1@oracle.com> <5329CA23.9010205@oracle.com> <532AAB93.7080608@oracle.com> <983CE070-BB04-4770-8041-B266D4CE8D0B@oracle.com> Message-ID: <532AC231.2080803@oracle.com> On 20/03/2014 09:13, Staffan Larsen wrote: > Thanks! > > Still need someone to look at the actual code changes. > > In webrev.01 then jdk/make/lib/ServiceabilityLibraries.gmk and src/solaris/native/sun/management/MacosxOperatingSystem.c are showing up as new files, I can't tell why that is. The code changes mostly look good to me. The only change that isn't very clear (I had to stare at it for a few minutes) in log_messages.c where it's now two calls to strftime. It might be useful to include a comment to explain this, also maybe reduce the line length to make it easier for future side-by-side reviews. -Alan. **** From staffan.larsen at oracle.com Thu Mar 20 12:11:14 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 20 Mar 2014 13:11:14 +0100 Subject: RFR 8037825 Fix warnings and enable "warnings as errors" in serviceability native libraries In-Reply-To: <532AC231.2080803@oracle.com> References: <532995B5.30902@oracle.com> <557ABEF7-7D08-41C3-BB6D-9525C78C32B1@oracle.com> <5329CA23.9010205@oracle.com> <532AAB93.7080608@oracle.com> <983CE070-BB04-4770-8041-B266D4CE8D0B@oracle.com> <532AC231.2080803@oracle.com> Message-ID: On 20 mar 2014, at 11:25, Alan Bateman wrote: > On 20/03/2014 09:13, Staffan Larsen wrote: >> >> Thanks! >> >> Still need someone to look at the actual code changes. >> >> > In webrev.01 then jdk/make/lib/ServiceabilityLibraries.gmk and src/solaris/native/sun/management/MacosxOperatingSystem.c are showing up as new files, I can't tell why that is. I had some trouble creating reviews for multiple repos now that "webrev -f? does not work. The review at http://cr.openjdk.java.net/~sla/8037825/webrev.01/jdk/ is the good one. > The code changes mostly look good to me. The only change that isn't very clear (I had to stare at it for a few minutes) in log_messages.c where it's now two calls to strftime. It might be useful to include a comment to explain this, also maybe reduce the line length to make it easier for future side-by-side reviews. Yes, that one was a bit messy. I cleaned it up and added some comments. Also remove the SCCS workarounds. http://cr.openjdk.java.net/~sla/8037825/webrev.02/ Thanks, /Staffan From david.holmes at oracle.com Thu Mar 20 12:24:41 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Mar 2014 22:24:41 +1000 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <53280AF0.5000502@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <53280AF0.5000502@oracle.com> Message-ID: <532ADE09.7050602@oracle.com> On 18/03/2014 6:59 PM, Magnus Ihse Bursie wrote: > On 2014-03-18 02:19, Andrew Hughes wrote: >> Do we need more than just the following three alternatives? >> >> #1. No debugging information at all. >> #2. Debugging information left in the original binaries. >> #3. Debugging information stripped from the binaries and zipped in >> separate files. >> >> It sounds to me like Oracle want #3, while distros want #2 and I >> imagine some >> end users may just want #1 for a faster, smaller build. > > I'm completely thinking along your lines here. I think we should focus > on the end result, not the specific implementations details. I've been > thinking about exposing a configure option like this: > > --with-debug-symbols=none (for #1) > --with-debug-symbols=internal (for #2) > --with-debug-symbols=zipped (for #3) I don't think this quite works as there are other variations not captured here. Rather than "zipped" it should just be "external". Whether the debuginfo files are zipped or not is then an additional build time option. Additionally we still have to be able to control the degree of stripping that is carried out. It doesn't make sense to me to try and enumerate all possible combinations as top-level configure options. Further, as Dan was saying, this doesn't capture the overlap between "internal" and "external" because we still leave some symbols internal even when creating the debuginfo file. So I don't think this proposed categorization works. We still have three aspects: - generating symbols into the object files - stripping symbols from the final binaries - saving symbols into an external form Each of which can potentally be varied (of course if you don't generate symbols in the obj files stripping and saving are non issues). David ----- > but perhaps with better names. I also imagine there might be a use case > for yet another option, > #4. Debuggin information stripped from the binaries, but not zipped > > expressed like this > --with-debug-symbols=external > > And then this would be the only user interface needed, and the rest of > the current set of not-really-clear flags can be hidden inside the > configure script. > > For compatibility reasons, the default would be > --with-debug-symbols=zipped (which is called "FDS" here), just as we > currently do, but distributions would just need to add a > --with-debug-symbols=internal to get what they want. > > /Magnus From mike.duigou at oracle.com Thu Mar 20 16:39:30 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 20 Mar 2014 09:39:30 -0700 Subject: RFR: 8030681 : (s) add "serve" command and --quiet and --verbose options to hgforest In-Reply-To: <532AAC8B.4040307@oracle.com> References: <5C7F5B32-B543-4B1F-AEE0-17D3317E7F5A@oracle.com> <532AAC8B.4040307@oracle.com> Message-ID: <47199626-9ACE-4898-AB61-69878690A997@oracle.com> On Mar 20 2014, at 01:53 , Magnus Ihse Bursie wrote: > On 2014-03-20 02:51, Mike Duigou wrote: >> Hello all; >> >> This is a patch which adds support for the "serve" command to hgforest as well as providing --quiet and --verbose options. >> >> The serve command is particularly useful for sharing repos with virtual machines used for building/testing. Using "serve" is generally faster and has fewer problems than using shared filesystems (let me tell you! I if I have to delete one more .hg/store/lock file... Well, you don't want to know what would happen!) >> >> https://bugs.openjdk.java.net/browse/JDK-8030681 >> >> http://cr.openjdk.java.net/~mduigou/JDK-8030681/2/webrev/ > > I found this: > > # XXX mduigou I can't figure out how to make the root repo the serve "/" root. > > Is this something that ought to be fixed? I wish I knew how. Despite fiddling with it extensively I was unable to convince hg to serve the top repo from http://server:8000/ instead the top repo is: http://server:8000/ I wanted to have the URL of the top repo displayed as part of the serve message but a) can't get hg to display it b) can't determine what the service address is going to be myself to construct the url. It's a minor annoyance/limitation that people will get used to. mike From Alan.Bateman at oracle.com Thu Mar 20 18:15:16 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 20 Mar 2014 18:15:16 +0000 Subject: RFR 8037825 Fix warnings and enable "warnings as errors" in serviceability native libraries In-Reply-To: References: <532995B5.30902@oracle.com> <557ABEF7-7D08-41C3-BB6D-9525C78C32B1@oracle.com> <5329CA23.9010205@oracle.com> <532AAB93.7080608@oracle.com> <983CE070-BB04-4770-8041-B266D4CE8D0B@oracle.com> <532AC231.2080803@oracle.com> Message-ID: <532B3034.8050606@oracle.com> On 20/03/2014 12:11, Staffan Larsen wrote: > : > Yes, that one was a bit messy. I cleaned it up and added some comments. Also remove the SCCS workarounds. > > http://cr.openjdk.java.net/~sla/8037825/webrev.02/ > > It's looks okay and thanks for adding a comment. -Alan From gary.collins at oracle.com Thu Mar 20 18:54:27 2014 From: gary.collins at oracle.com (Gary Collins) Date: Thu, 20 Mar 2014 11:54:27 -0700 Subject: RFR: JDK-8037414: Licensee Source Bundles build issue In-Reply-To: <53282E33.8080300@oracle.com> References: <53282E33.8080300@oracle.com> Message-ID: <19394353-C167-42CD-81AB-00B632A7894B@oracle.com> Hi Erik, When do we expect this bug to be pushed for next 8uX release & 9? This bug needs to be fixed in the next available build of 8uX. We may need to work with Tracy or Anita to figure out what 8uX release makes sense. It would be great to get it into 9 and backported to emb-8u6 release. If 8u5 needs a respin we have the possibility to get it in that release. Can you please let us know if you are ready for push if it comes to it? On Mar 18, 2014, at 4:29 AM, Erik Joelsson wrote: > Hello, > > The file jdk/make/closed/javax/crypto/doc/README.txt is not available to licensees. The makefiles currently assumes it's always there as long as we build crypto and it's not an OpenJDK build. This change also checks that the file is actually in the source too. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8037414 > Patch inline: > diff -r a94a8944bd2b make/CreateSecurityJars.gmk > --- a/make/CreateSecurityJars.gmk > +++ b/make/CreateSecurityJars.gmk > @@ -284,11 +284,13 @@ > TARGETS += $(LOCAL_POLICY_JAR_LIMITED_UNSIGNED) $(LOCAL_POLICY_JAR_UNLIMITED_UNSIGNED) > > ifndef OPENJDK > - $(JDK_OUTPUTDIR)/jce/unsigned/policy/unlimited/README.txt: \ > - $(JDK_TOPDIR)/make/closed/javax/crypto/doc/README.txt > + ifneq ($(wildcard $(JDK_TOPDIR)/make/closed/javax/crypto/doc/README.txt), ) > + $(JDK_OUTPUTDIR)/jce/unsigned/policy/unlimited/README.txt: \ > + $(JDK_TOPDIR)/make/closed/javax/crypto/doc/README.txt > $(install-file) > > - TARGETS += $(JDK_OUTPUTDIR)/jce/unsigned/policy/unlimited/README.txt > + TARGETS += $(JDK_OUTPUTDIR)/jce/unsigned/policy/unlimited/README.txt > + endif > endif > endif > > /Erik From staffan.larsen at oracle.com Thu Mar 20 19:16:37 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 20 Mar 2014 20:16:37 +0100 Subject: RFR 8037825 Fix warnings and enable "warnings as errors" in serviceability native libraries In-Reply-To: <532B3034.8050606@oracle.com> References: <532995B5.30902@oracle.com> <557ABEF7-7D08-41C3-BB6D-9525C78C32B1@oracle.com> <5329CA23.9010205@oracle.com> <532AAB93.7080608@oracle.com> <983CE070-BB04-4770-8041-B266D4CE8D0B@oracle.com> <532AC231.2080803@oracle.com> <532B3034.8050606@oracle.com> Message-ID: Thanks Alan! On 20 mar 2014, at 19:15, Alan Bateman wrote: > On 20/03/2014 12:11, Staffan Larsen wrote: >> : >> Yes, that one was a bit messy. I cleaned it up and added some comments. Also remove the SCCS workarounds. >> >> http://cr.openjdk.java.net/~sla/8037825/webrev.02/ >> >> > It's looks okay and thanks for adding a comment. > > -Alan From david.dehaven at oracle.com Thu Mar 20 20:02:39 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 20 Mar 2014 13:02:39 -0700 Subject: RFR: 8038027: DTDBuilder should be run in headless mode Message-ID: <79DC1E49-9531-4B77-970A-F09649BCA92E@oracle.com> Please review a simple fix for a cosmetic issue: https://bugs.openjdk.java.net/browse/JDK-8038027 Proposed fix: diff --git a/make/Tools.gmk b/make/Tools.gmk --- a/make/Tools.gmk +++ b/make/Tools.gmk @@ -71,6 +71,7 @@ build.tools.generatecharacter.CharacterName TOOL_DTDBUILDER = $(JAVA) -Ddtd_home=$(JDK_TOPDIR)/make/data/dtdbuilder \ + -Djava.awt.headless=true \ -cp $(JDK_OUTPUTDIR)/btclasses build.tools.dtdbuilder.DTDBuilder TOOL_GENERATEBREAKITERATORDATA = $(JAVA) \ Test run showed no change in build results. Need a sponsor to push, any volunteers? -DrD- From magnus.ihse.bursie at oracle.com Thu Mar 20 20:19:51 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Mar 2014 21:19:51 +0100 Subject: RFR: 8038027: DTDBuilder should be run in headless mode In-Reply-To: <79DC1E49-9531-4B77-970A-F09649BCA92E@oracle.com> References: <79DC1E49-9531-4B77-970A-F09649BCA92E@oracle.com> Message-ID: <532B4D67.3050609@oracle.com> On 2014-03-20 21:02, David DeHaven wrote: > Please review a simple fix for a cosmetic issue: > https://bugs.openjdk.java.net/browse/JDK-8038027 > > Proposed fix: > diff --git a/make/Tools.gmk b/make/Tools.gmk > --- a/make/Tools.gmk > +++ b/make/Tools.gmk > @@ -71,6 +71,7 @@ > build.tools.generatecharacter.CharacterName > > TOOL_DTDBUILDER = $(JAVA) -Ddtd_home=$(JDK_TOPDIR)/make/data/dtdbuilder \ > + -Djava.awt.headless=true \ > -cp $(JDK_OUTPUTDIR)/btclasses build.tools.dtdbuilder.DTDBuilder > > TOOL_GENERATEBREAKITERATORDATA = $(JAVA) \ > > > Test run showed no change in build results. > > Need a sponsor to push, any volunteers? Looks good to me. I can sponsor this fix. /Magnus From david.dehaven at oracle.com Thu Mar 20 20:26:02 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 20 Mar 2014 13:26:02 -0700 Subject: RFR: 8038027: DTDBuilder should be run in headless mode In-Reply-To: <532B4D67.3050609@oracle.com> References: <79DC1E49-9531-4B77-970A-F09649BCA92E@oracle.com> <532B4D67.3050609@oracle.com> Message-ID: >> Please review a simple fix for a cosmetic issue: >> https://bugs.openjdk.java.net/browse/JDK-8038027 >> >> Proposed fix: >> diff --git a/make/Tools.gmk b/make/Tools.gmk >> --- a/make/Tools.gmk >> +++ b/make/Tools.gmk >> @@ -71,6 +71,7 @@ >> build.tools.generatecharacter.CharacterName >> >> TOOL_DTDBUILDER = $(JAVA) -Ddtd_home=$(JDK_TOPDIR)/make/data/dtdbuilder \ >> + -Djava.awt.headless=true \ >> -cp $(JDK_OUTPUTDIR)/btclasses build.tools.dtdbuilder.DTDBuilder >> >> TOOL_GENERATEBREAKITERATORDATA = $(JAVA) \ >> >> >> Test run showed no change in build results. >> >> Need a sponsor to push, any volunteers? > > Looks good to me. > > I can sponsor this fix. Thanks. I'll email a proper patch since cut and paste butchered this one... -DrD- From david.holmes at oracle.com Fri Mar 21 02:39:12 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 21 Mar 2014 12:39:12 +1000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA6A09@DEWDFEMB12A.global.corp.sap> <531F9370.4020305@oracle.com> <5320E5F8.3020500@oracle.com> <5326766F.80104@oracle.com> <5326DE2F.6000107@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> Message-ID: <532BA650.7000402@oracle.com> On 21/03/2014 11:59 AM, Alexander Smundak wrote: > I've revised the patch to have fold little endian and big endian > PowerPC64 architectures. The build changes look much cleaner to me - thanks. > The patch for the hotspot repository is at > http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.01 > Top-level build's OPENJDK_TARGET_CPU_ENDIAN variable is carried over > to the Hotspot build as ZERO_ENDIANNESS, so the patch takes advantage > of this to set target-dependend compiler flags in > make/linux/makefiles/ppc64.make. Why are you not using OPENJDK_TARGET_CPU_ENDIAN directly? Ah! Because it doesn't reach down into the .make files. ZERO_ENDIANNESS does but seems inappropriate if this is not Zero specific. (I'm also not seeing how ZERO_ENDIANNESS reaches down that far either ??). > The accompanying patches for the other repositories are at: > top-level: http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.01 Seems ok. > jdk: http://cr.openjdk.java.net/~martin/asmundak/8036767/jdk/webrev.01 This change: - LDFLAGS_SUFFIX := $(ALSA_LIBS) -ljava -ljvm, \ + LDFLAGS_SUFFIX := $(ALSA_LIBS) $(LIBDL) $(LIBM) -lpthread -ljava -ljvm, \ seems unrelated to endianness. Why is it needed, and why is it being applied to all platforms? Thanks, David From david.holmes at oracle.com Fri Mar 21 03:57:23 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 21 Mar 2014 13:57:23 +1000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA6A09@DEWDFEMB12A.global.corp.sap> <531F9370.4020305@oracle.com> <5320E5F8.3020500@oracle.com> <5326766F.80104@oracle.com> <5326DE2F.6000107@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> <532BA650.7000402@oracle.com> Message-ID: <532BB8A3.3080004@oracle.com> On 21/03/2014 1:42 PM, Alexander Smundak wrote: > On Thu, Mar 20, 2014 at 7:39 PM, David Holmes wrote: >> The build changes look much cleaner to me - thanks. > It's at the expense of platform directory being ppc64/ instead of the > conventional ppc64le/, and having rather ugly check in the ppc64.make file. > > >> Why are you not using OPENJDK_TARGET_CPU_ENDIAN directly? Ah! Because it >> doesn't reach down into the .make files. ZERO_ENDIANNESS does but >> seems inappropriate if this is not Zero specific. (I'm also not seeing how >> ZERO_ENDIANNESS reaches down that far either ??). > configure script writes hotspot-spec.gmk file to the top-level build directory, > and it contains > ZERO_ENDIANNESS=$(OPENJDK_TARGET_CPU_ENDIAN) Yes but my query was how does ZERO_ENDIANNESS become visible in ppc64.make? The answer to which is that the generated flags.make file has an explicit include of hotspot-spec.gmk. In which case you don't need to use ZERO_ENDIANNESS you can just use $(OPENJDK_TARGET_CPU_ENDIAN) directly. (Which now begs the question as to why ZERO_ENDIANNESS even exists - perhaps it predates the integration with the new build.) David ----- > The patch contains the fuse in ppc64.make, the build will fail unless > ZERO_ENDIANNESS is set. > >>> jdk: http://cr.openjdk.java.net/~martin/asmundak/8036767/jdk/webrev.01 >> >> >> This change: >> >> - LDFLAGS_SUFFIX := $(ALSA_LIBS) -ljava -ljvm, \ >> + LDFLAGS_SUFFIX := $(ALSA_LIBS) $(LIBDL) $(LIBM) -lpthread -ljava >> -ljvm, \ >> >> seems unrelated to endianness. Why is it needed, and why is it being applied >> to all platforms? > Sorry, this is not needed, it's the problem with the toolchain I am using. > > Please ignore this patch. > From asmundak at google.com Fri Mar 21 06:14:48 2014 From: asmundak at google.com (Alexander Smundak) Date: Thu, 20 Mar 2014 23:14:48 -0700 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <532BB8A3.3080004@oracle.com> References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA6A09@DEWDFEMB12A.global.corp.sap> <531F9370.4020305@oracle.com> <5320E5F8.3020500@oracle.com> <5326766F.80104@oracle.com> <5326DE2F.6000107@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> <532BA650.7000402@oracle.com> <532BB8A3.3080004@oracle.com> Message-ID: Revised the patch to use OPENJDK_TARGET_CPU_ENDIAN instead. The new version is at: http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.02 On Thu, Mar 20, 2014 at 8:57 PM, David Holmes wrote: > On 21/03/2014 1:42 PM, Alexander Smundak wrote: >> >> On Thu, Mar 20, 2014 at 7:39 PM, David Holmes >> wrote: >>> >>> The build changes look much cleaner to me - thanks. >> >> It's at the expense of platform directory being ppc64/ instead of the >> conventional ppc64le/, and having rather ugly check in the ppc64.make >> file. >> >> >>> Why are you not using OPENJDK_TARGET_CPU_ENDIAN directly? Ah! Because it >>> doesn't reach down into the .make files. ZERO_ENDIANNESS does but >>> seems inappropriate if this is not Zero specific. (I'm also not seeing >>> how >>> ZERO_ENDIANNESS reaches down that far either ??). >> >> configure script writes hotspot-spec.gmk file to the top-level build >> directory, >> and it contains >> ZERO_ENDIANNESS=$(OPENJDK_TARGET_CPU_ENDIAN) > > > Yes but my query was how does ZERO_ENDIANNESS become visible in ppc64.make? > The answer to which is that the generated flags.make file has an explicit > include of hotspot-spec.gmk. In which case you don't need to use > ZERO_ENDIANNESS you can just use $(OPENJDK_TARGET_CPU_ENDIAN) directly. > (Which now begs the question as to why ZERO_ENDIANNESS even exists - perhaps > it predates the integration with the new build.) > > David > ----- > > >> The patch contains the fuse in ppc64.make, the build will fail unless >> ZERO_ENDIANNESS is set. >> >>>> jdk: http://cr.openjdk.java.net/~martin/asmundak/8036767/jdk/webrev.01 >>> >>> >>> >>> This change: >>> >>> - LDFLAGS_SUFFIX := $(ALSA_LIBS) -ljava -ljvm, \ >>> + LDFLAGS_SUFFIX := $(ALSA_LIBS) $(LIBDL) $(LIBM) -lpthread -ljava >>> -ljvm, \ >>> >>> seems unrelated to endianness. Why is it needed, and why is it being >>> applied >>> to all platforms? >> >> Sorry, this is not needed, it's the problem with the toolchain I am using. >> >> Please ignore this patch. >> > From david.holmes at oracle.com Fri Mar 21 06:16:56 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 21 Mar 2014 16:16:56 +1000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: References: <531ED06F.5040905@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA6A09@DEWDFEMB12A.global.corp.sap> <531F9370.4020305@oracle.com> <5320E5F8.3020500@oracle.com> <5326766F.80104@oracle.com> <5326DE2F.6000107@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> <532BA650.7000402@oracle.com> <532BB8A3.3080004@oracle.com> Message-ID: <532BD958.6010705@oracle.com> On 21/03/2014 4:14 PM, Alexander Smundak wrote: > Revised the patch to use OPENJDK_TARGET_CPU_ENDIAN instead. The new > version is at: > http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.02 Thanks Alexander - the build changes look good to me. David ----- > On Thu, Mar 20, 2014 at 8:57 PM, David Holmes wrote: >> On 21/03/2014 1:42 PM, Alexander Smundak wrote: >>> >>> On Thu, Mar 20, 2014 at 7:39 PM, David Holmes >>> wrote: >>>> >>>> The build changes look much cleaner to me - thanks. >>> >>> It's at the expense of platform directory being ppc64/ instead of the >>> conventional ppc64le/, and having rather ugly check in the ppc64.make >>> file. >>> >>> >>>> Why are you not using OPENJDK_TARGET_CPU_ENDIAN directly? Ah! Because it >>>> doesn't reach down into the .make files. ZERO_ENDIANNESS does but >>>> seems inappropriate if this is not Zero specific. (I'm also not seeing >>>> how >>>> ZERO_ENDIANNESS reaches down that far either ??). >>> >>> configure script writes hotspot-spec.gmk file to the top-level build >>> directory, >>> and it contains >>> ZERO_ENDIANNESS=$(OPENJDK_TARGET_CPU_ENDIAN) >> >> >> Yes but my query was how does ZERO_ENDIANNESS become visible in ppc64.make? >> The answer to which is that the generated flags.make file has an explicit >> include of hotspot-spec.gmk. In which case you don't need to use >> ZERO_ENDIANNESS you can just use $(OPENJDK_TARGET_CPU_ENDIAN) directly. >> (Which now begs the question as to why ZERO_ENDIANNESS even exists - perhaps >> it predates the integration with the new build.) >> >> David >> ----- >> >> >>> The patch contains the fuse in ppc64.make, the build will fail unless >>> ZERO_ENDIANNESS is set. >>> >>>>> jdk: http://cr.openjdk.java.net/~martin/asmundak/8036767/jdk/webrev.01 >>>> >>>> >>>> >>>> This change: >>>> >>>> - LDFLAGS_SUFFIX := $(ALSA_LIBS) -ljava -ljvm, \ >>>> + LDFLAGS_SUFFIX := $(ALSA_LIBS) $(LIBDL) $(LIBM) -lpthread -ljava >>>> -ljvm, \ >>>> >>>> seems unrelated to endianness. Why is it needed, and why is it being >>>> applied >>>> to all platforms? >>> >>> Sorry, this is not needed, it's the problem with the toolchain I am using. >>> >>> Please ignore this patch. >>> >> From magnus.ihse.bursie at oracle.com Fri Mar 21 08:14:28 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 21 Mar 2014 09:14:28 +0100 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <532ADE09.7050602@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <53280AF0.5000502@oracle.com> <532ADE09.7050602@oracle.com> Message-ID: <532BF4E4.5080003@oracle.com> > I don't think this quite works as there are other variations not > captured here. Rather than "zipped" it should just be "external". > Whether the debuginfo files are zipped or not is then an additional > build time option. Additionally we still have to be able to control > the degree of stripping that is carried out. It doesn't make sense to > me to try and enumerate all possible combinations as top-level > configure options. > > Further, as Dan was saying, this doesn't capture the overlap between > "internal" and "external" because we still leave some symbols internal > even when creating the debuginfo file. > > So I don't think this proposed categorization works. We still have > three aspects: > - generating symbols into the object files > - stripping symbols from the final binaries > - saving symbols into an external form > > Each of which can potentally be varied (of course if you don't > generate symbols in the obj files stripping and saving are non issues). But they are not independent on each other! Unless you generate debug symbols, you can't strip them, nor save them elsewhere. So generating debug symbols (your item #1) is a prerequisite for the rest of your items. And while, technically, you can save symbols externally, and at the same time keep them in the binary, that does not make sense. So, in a practical sense, you are going to do #2 if you are going to do #3. And you can't zip external symbols unless you create a non-zipped version. And if you zip them, it does not make sense to keep the non-zipped version. And yes, we do not strip all debug information when creating external debug info. But there seems to be no real use case (not even for IcedTea, as it turned out) to want a completely stripped binary, I don't think that's worth discussing much. That's just part of how the external debuginfo scheme works. Can you give a more concrete example of the variations of your "aspects" that you think my suggested solution would not capture? /Magnus From david.holmes at oracle.com Fri Mar 21 08:57:06 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 21 Mar 2014 18:57:06 +1000 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <532BF4E4.5080003@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <53280AF0.5000502@oracle.com> <532ADE09.7050602@oracle.com> <532BF4E4.5080003@oracle.com> Message-ID: <532BFEE2.6080802@oracle.com> On 21/03/2014 6:14 PM, Magnus Ihse Bursie wrote: > >> I don't think this quite works as there are other variations not >> captured here. Rather than "zipped" it should just be "external". >> Whether the debuginfo files are zipped or not is then an additional >> build time option. Additionally we still have to be able to control >> the degree of stripping that is carried out. It doesn't make sense to >> me to try and enumerate all possible combinations as top-level >> configure options. >> >> Further, as Dan was saying, this doesn't capture the overlap between >> "internal" and "external" because we still leave some symbols internal >> even when creating the debuginfo file. >> >> So I don't think this proposed categorization works. We still have >> three aspects: >> - generating symbols into the object files >> - stripping symbols from the final binaries >> - saving symbols into an external form >> >> Each of which can potentally be varied (of course if you don't >> generate symbols in the obj files stripping and saving are non issues). > > But they are not independent on each other! > > Unless you generate debug symbols, you can't strip them, nor save them > elsewhere. So generating debug symbols (your item #1) is a prerequisite > for the rest of your items. Yes I just said that. :) > And while, technically, you can save symbols externally, and at the same > time keep them in the binary, that does not make sense. So, in a > practical sense, you are going to do #2 if you are going to do #3. But you can vary what is kept internally independent of what is made external. > And you can't zip external symbols unless you create a non-zipped > version. And if you zip them, it does not make sense to keep the > non-zipped version. zip vs non-zip is just an issue of disk space. It is not a fundamental configuration choice, just a variation on how external symbols are packaged. > And yes, we do not strip all debug information when creating external > debug info. But there seems to be no real use case (not even for > IcedTea, as it turned out) to want a completely stripped binary, I don't > think that's worth discussing much. That's just part of how the external > debuginfo scheme works. Umm we fully strip all our binaries in embedded. > Can you give a more concrete example of the variations of your "aspects" > that you think my suggested solution would not capture? I think I already have. There aren't tree simple choices here, there are three aspects, each of which could have different variants. If I could draw a flow chart easily I would but basically if you generate debug symbols you can then select what symbols are kept internally (the strip policy) and what are put externally (objcopy options), then for the external symbol file you can choose zipped or unzipped. Multiple inter-connected choices, not just three (or four if you add zipped) David > /Magnus From goetz.lindenmaier at sap.com Fri Mar 21 09:06:57 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 21 Mar 2014 09:06:57 +0000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA6A09@DEWDFEMB12A.global.corp.sap> <531F9370.4020305@oracle.com> <5320E5F8.3020500@oracle.com> <5326766F.80104@oracle.com> <5326DE2F.6000107@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> <532BA650.7000402@oracle.com> <532BB8A3.3080004@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> Hi Sasha, I tried to test your change (02), but it does not work. On linux ppc be;) I get make[4]: Leaving directory `/net/usr.work/d045726/oJ/builds/8036767-comp-ld9502-dbg/linux_ppc64_compiler2/debug' make[4]: Entering directory `/net/usr.work/d045726/oJ/builds/8036767-comp-ld9502-dbg/linux_ppc64_compiler2/debug' /sapmnt/home1/d045726/oJ/8036767-hs-comp/make/linux/makefiles/ppc64.make:30: *** OPENJDK_TARGET_CPU_ENDIAN has not been passed to this makefile. Stop. which is just what you discussed with David. On Aix I get "/sapmnt/home1/d045726/oJ/8036767-aix-hs-comp/src/cpu/ppc/vm/bytes_ppc.hpp", line 277.10: 1540-0836 (S) The #include file "bytes_linux_ppc.inline.hpp" is not found. I think we fixed this before, you need to add #ifdef TARGET_OS_ARCH_linux_ppc around the include. Also, you need to fix os_linux.cpp: remove + #if defined(PPC64) else other platforms will not build (linux x86_64): /sapmnt/home/d045726/oJ/8036767-hs-comp/src/os/linux/vm/os_linux.cpp:1972: error: ???PPC64_ELFDATA2XSB??? was not declared in this scope Thanks for undoing the change in make/linux/Makefile! Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Alexander Smundak Sent: Friday, March 21, 2014 7:15 AM To: David Holmes Cc: build-dev; HotSpot Open Source Developers Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model Revised the patch to use OPENJDK_TARGET_CPU_ENDIAN instead. The new version is at: http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.02 On Thu, Mar 20, 2014 at 8:57 PM, David Holmes wrote: > On 21/03/2014 1:42 PM, Alexander Smundak wrote: >> >> On Thu, Mar 20, 2014 at 7:39 PM, David Holmes >> wrote: >>> >>> The build changes look much cleaner to me - thanks. >> >> It's at the expense of platform directory being ppc64/ instead of the >> conventional ppc64le/, and having rather ugly check in the ppc64.make >> file. >> >> >>> Why are you not using OPENJDK_TARGET_CPU_ENDIAN directly? Ah! Because it >>> doesn't reach down into the .make files. ZERO_ENDIANNESS does but >>> seems inappropriate if this is not Zero specific. (I'm also not seeing >>> how >>> ZERO_ENDIANNESS reaches down that far either ??). >> >> configure script writes hotspot-spec.gmk file to the top-level build >> directory, >> and it contains >> ZERO_ENDIANNESS=$(OPENJDK_TARGET_CPU_ENDIAN) > > > Yes but my query was how does ZERO_ENDIANNESS become visible in ppc64.make? > The answer to which is that the generated flags.make file has an explicit > include of hotspot-spec.gmk. In which case you don't need to use > ZERO_ENDIANNESS you can just use $(OPENJDK_TARGET_CPU_ENDIAN) directly. > (Which now begs the question as to why ZERO_ENDIANNESS even exists - perhaps > it predates the integration with the new build.) > > David > ----- > > >> The patch contains the fuse in ppc64.make, the build will fail unless >> ZERO_ENDIANNESS is set. >> >>>> jdk: http://cr.openjdk.java.net/~martin/asmundak/8036767/jdk/webrev.01 >>> >>> >>> >>> This change: >>> >>> - LDFLAGS_SUFFIX := $(ALSA_LIBS) -ljava -ljvm, \ >>> + LDFLAGS_SUFFIX := $(ALSA_LIBS) $(LIBDL) $(LIBM) -lpthread -ljava >>> -ljvm, \ >>> >>> seems unrelated to endianness. Why is it needed, and why is it being >>> applied >>> to all platforms? >> >> Sorry, this is not needed, it's the problem with the toolchain I am using. >> >> Please ignore this patch. >> > From dmitry.samersoff at oracle.com Fri Mar 21 09:36:10 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 21 Mar 2014 13:36:10 +0400 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <532BFEE2.6080802@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <53280AF0.5000502@oracle.com> <532ADE09.7050602@oracle.com> <532BF4E4.5080003@oracle.com> <532BFEE2.6080802@oracle.com> Message-ID: <532C080A.9020002@oracle.com> David, In practice, we don't have to much to keep internally. There are no reason to copy out some of .debug_* sections but keep other ones. So we have a matrix: (a) Strip mode: 1. full 2. keep symbols 3. keep symbols and .debug_* (b) Copy mode: 1. Copy all to ext file 2. Copy none to ext file (c) Compression mode: 1. none 2. per-section compression, SHF_GNU_COMPRESSED [1] 3. zip entire file Where *a2 + b2 + c2* have perfect sense, *a1 + b1 + c3* have no sense etc. -Dmitry Refs: 1. https://sourceware.org/bugzilla/show_bug.cgi?id=11819 http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01780.html -Dmitry On 2014-03-21 12:57, David Holmes wrote: > On 21/03/2014 6:14 PM, Magnus Ihse Bursie wrote: >> >>> I don't think this quite works as there are other variations not >>> captured here. Rather than "zipped" it should just be "external". >>> Whether the debuginfo files are zipped or not is then an additional >>> build time option. Additionally we still have to be able to control >>> the degree of stripping that is carried out. It doesn't make sense to >>> me to try and enumerate all possible combinations as top-level >>> configure options. >>> >>> Further, as Dan was saying, this doesn't capture the overlap between >>> "internal" and "external" because we still leave some symbols internal >>> even when creating the debuginfo file. >>> >>> So I don't think this proposed categorization works. We still have >>> three aspects: >>> - generating symbols into the object files >>> - stripping symbols from the final binaries >>> - saving symbols into an external form >>> >>> Each of which can potentally be varied (of course if you don't >>> generate symbols in the obj files stripping and saving are non issues). >> >> But they are not independent on each other! >> >> Unless you generate debug symbols, you can't strip them, nor save them >> elsewhere. So generating debug symbols (your item #1) is a prerequisite >> for the rest of your items. > > Yes I just said that. :) > >> And while, technically, you can save symbols externally, and at the same >> time keep them in the binary, that does not make sense. So, in a >> practical sense, you are going to do #2 if you are going to do #3. > > But you can vary what is kept internally independent of what is made > external. > >> And you can't zip external symbols unless you create a non-zipped >> version. And if you zip them, it does not make sense to keep the >> non-zipped version. > > zip vs non-zip is just an issue of disk space. It is not a fundamental > configuration choice, just a variation on how external symbols are > packaged. > >> And yes, we do not strip all debug information when creating external >> debug info. But there seems to be no real use case (not even for >> IcedTea, as it turned out) to want a completely stripped binary, I don't >> think that's worth discussing much. That's just part of how the external >> debuginfo scheme works. > > Umm we fully strip all our binaries in embedded. > >> Can you give a more concrete example of the variations of your "aspects" >> that you think my suggested solution would not capture? > > I think I already have. There aren't tree simple choices here, there are > three aspects, each of which could have different variants. > > If I could draw a flow chart easily I would but basically if you > generate debug symbols you can then select what symbols are kept > internally (the strip policy) and what are put externally (objcopy > options), then for the external symbol file you can choose zipped or > unzipped. > > Multiple inter-connected choices, not just three (or four if you add > zipped) > > David > >> /Magnus -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From david.holmes at oracle.com Fri Mar 21 11:08:23 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 21 Mar 2014 21:08:23 +1000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> References: <531F9370.4020305@oracle.com> <5320E5F8.3020500@oracle.com> <5326766F.80104@oracle.com> <5326DE2F.6000107@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> <532BA650.7000402@oracle.com> <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> Message-ID: <532C1DA7.1030409@oracle.com> On 21/03/2014 7:06 PM, Lindenmaier, Goetz wrote: > Hi Sasha, > > I tried to test your change (02), but it does not work. > On linux ppc be;) I get > > make[4]: Leaving directory `/net/usr.work/d045726/oJ/builds/8036767-comp-ld9502-dbg/linux_ppc64_compiler2/debug' > make[4]: Entering directory `/net/usr.work/d045726/oJ/builds/8036767-comp-ld9502-dbg/linux_ppc64_compiler2/debug' > /sapmnt/home1/d045726/oJ/8036767-hs-comp/make/linux/makefiles/ppc64.make:30: *** OPENJDK_TARGET_CPU_ENDIAN has not been passed to this makefile. Stop. > > which is just what you discussed with David. Was that a full configure build or a hotspot-only build? For hotspot-only you would need to set this explicitly. David > On Aix I get > "/sapmnt/home1/d045726/oJ/8036767-aix-hs-comp/src/cpu/ppc/vm/bytes_ppc.hpp", line 277.10: 1540-0836 (S) The #include file "bytes_linux_ppc.inline.hpp" is not found. > > I think we fixed this before, you need to add > #ifdef TARGET_OS_ARCH_linux_ppc > around the include. > > Also, you need to fix os_linux.cpp: remove > + #if defined(PPC64) > else other platforms will not build (linux x86_64): > /sapmnt/home/d045726/oJ/8036767-hs-comp/src/os/linux/vm/os_linux.cpp:1972: error: ???PPC64_ELFDATA2XSB??? was not declared in this scope > > Thanks for undoing the change in make/linux/Makefile! > > Best regards, > Goetz. > > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Alexander Smundak > Sent: Friday, March 21, 2014 7:15 AM > To: David Holmes > Cc: build-dev; HotSpot Open Source Developers > Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model > > Revised the patch to use OPENJDK_TARGET_CPU_ENDIAN instead. The new > version is at: > http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.02 > > On Thu, Mar 20, 2014 at 8:57 PM, David Holmes wrote: >> On 21/03/2014 1:42 PM, Alexander Smundak wrote: >>> >>> On Thu, Mar 20, 2014 at 7:39 PM, David Holmes >>> wrote: >>>> >>>> The build changes look much cleaner to me - thanks. >>> >>> It's at the expense of platform directory being ppc64/ instead of the >>> conventional ppc64le/, and having rather ugly check in the ppc64.make >>> file. >>> >>> >>>> Why are you not using OPENJDK_TARGET_CPU_ENDIAN directly? Ah! Because it >>>> doesn't reach down into the .make files. ZERO_ENDIANNESS does but >>>> seems inappropriate if this is not Zero specific. (I'm also not seeing >>>> how >>>> ZERO_ENDIANNESS reaches down that far either ??). >>> >>> configure script writes hotspot-spec.gmk file to the top-level build >>> directory, >>> and it contains >>> ZERO_ENDIANNESS=$(OPENJDK_TARGET_CPU_ENDIAN) >> >> >> Yes but my query was how does ZERO_ENDIANNESS become visible in ppc64.make? >> The answer to which is that the generated flags.make file has an explicit >> include of hotspot-spec.gmk. In which case you don't need to use >> ZERO_ENDIANNESS you can just use $(OPENJDK_TARGET_CPU_ENDIAN) directly. >> (Which now begs the question as to why ZERO_ENDIANNESS even exists - perhaps >> it predates the integration with the new build.) >> >> David >> ----- >> >> >>> The patch contains the fuse in ppc64.make, the build will fail unless >>> ZERO_ENDIANNESS is set. >>> >>>>> jdk: http://cr.openjdk.java.net/~martin/asmundak/8036767/jdk/webrev.01 >>>> >>>> >>>> >>>> This change: >>>> >>>> - LDFLAGS_SUFFIX := $(ALSA_LIBS) -ljava -ljvm, \ >>>> + LDFLAGS_SUFFIX := $(ALSA_LIBS) $(LIBDL) $(LIBM) -lpthread -ljava >>>> -ljvm, \ >>>> >>>> seems unrelated to endianness. Why is it needed, and why is it being >>>> applied >>>> to all platforms? >>> >>> Sorry, this is not needed, it's the problem with the toolchain I am using. >>> >>> Please ignore this patch. >>> >> From david.holmes at oracle.com Fri Mar 21 11:13:48 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 21 Mar 2014 21:13:48 +1000 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <532C080A.9020002@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <53280AF0.5000502@oracle.com> <532ADE09.7050602@oracle.com> <532BF4E4.5080003@oracle.com> <532BFEE2.6080802@oracle.com> <532C080A.9020002@oracle.com> Message-ID: <532C1EEC.7040404@oracle.com> On 21/03/2014 7:36 PM, Dmitry Samersoff wrote: > David, > > In practice, we don't have to much to keep internally. > > There are no reason to copy out some of .debug_* sections but keep other > ones. I'm not familiar with exactly what the different strip options do but the point is this is covered by the strip-policy. > So we have a matrix: > > (a) Strip mode: > > 1. full > 2. keep symbols > 3. keep symbols and .debug_* > > > (b) Copy mode: > > 1. Copy all to ext file > 2. Copy none to ext file > > > (c) Compression mode: > > 1. none > 2. per-section compression, SHF_GNU_COMPRESSED [1] > 3. zip entire file > > Where > *a2 + b2 + c2* have perfect sense, So now your compression mode may apply to either the external file or the original? That's even more permutations. > *a1 + b1 + c3* have no sense etc. Why does full strip + copy-all + zip make no sense? It is exactly what we do with embedded builds. (Naturally you have to copy before you strip) David ----- > > -Dmitry > > > Refs: > 1. > https://sourceware.org/bugzilla/show_bug.cgi?id=11819 > http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01780.html > > > -Dmitry > > On 2014-03-21 12:57, David Holmes wrote: >> On 21/03/2014 6:14 PM, Magnus Ihse Bursie wrote: >>> >>>> I don't think this quite works as there are other variations not >>>> captured here. Rather than "zipped" it should just be "external". >>>> Whether the debuginfo files are zipped or not is then an additional >>>> build time option. Additionally we still have to be able to control >>>> the degree of stripping that is carried out. It doesn't make sense to >>>> me to try and enumerate all possible combinations as top-level >>>> configure options. >>>> >>>> Further, as Dan was saying, this doesn't capture the overlap between >>>> "internal" and "external" because we still leave some symbols internal >>>> even when creating the debuginfo file. >>>> >>>> So I don't think this proposed categorization works. We still have >>>> three aspects: >>>> - generating symbols into the object files >>>> - stripping symbols from the final binaries >>>> - saving symbols into an external form >>>> >>>> Each of which can potentally be varied (of course if you don't >>>> generate symbols in the obj files stripping and saving are non issues). >>> >>> But they are not independent on each other! >>> >>> Unless you generate debug symbols, you can't strip them, nor save them >>> elsewhere. So generating debug symbols (your item #1) is a prerequisite >>> for the rest of your items. >> >> Yes I just said that. :) >> >>> And while, technically, you can save symbols externally, and at the same >>> time keep them in the binary, that does not make sense. So, in a >>> practical sense, you are going to do #2 if you are going to do #3. >> >> But you can vary what is kept internally independent of what is made >> external. >> >>> And you can't zip external symbols unless you create a non-zipped >>> version. And if you zip them, it does not make sense to keep the >>> non-zipped version. >> >> zip vs non-zip is just an issue of disk space. It is not a fundamental >> configuration choice, just a variation on how external symbols are >> packaged. >> >>> And yes, we do not strip all debug information when creating external >>> debug info. But there seems to be no real use case (not even for >>> IcedTea, as it turned out) to want a completely stripped binary, I don't >>> think that's worth discussing much. That's just part of how the external >>> debuginfo scheme works. >> >> Umm we fully strip all our binaries in embedded. >> >>> Can you give a more concrete example of the variations of your "aspects" >>> that you think my suggested solution would not capture? >> >> I think I already have. There aren't tree simple choices here, there are >> three aspects, each of which could have different variants. >> >> If I could draw a flow chart easily I would but basically if you >> generate debug symbols you can then select what symbols are kept >> internally (the strip policy) and what are put externally (objcopy >> options), then for the external symbol file you can choose zipped or >> unzipped. >> >> Multiple inter-connected choices, not just three (or four if you add >> zipped) >> >> David >> >>> /Magnus > > From dmitry.samersoff at oracle.com Fri Mar 21 11:20:58 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 21 Mar 2014 15:20:58 +0400 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <532C1EEC.7040404@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <53280AF0.5000502@oracle.com> <532ADE09.7050602@oracle.com> <532BF4E4.5080003@oracle.com> <532BFEE2.6080802@oracle.com> <532C080A.9020002@oracle.com> <532C1EEC.7040404@oracle.com> Message-ID: <532C209A.7000609@oracle.com> David, My point was that we don't need in fine grained selection of elf sections on strip - three options are enough. > Why does full strip + copy-all + zip make no sense? It is exactly what > we do with embedded builds. (Naturally you have to copy before you > strip) Sorry! it should be: full strip + copy-none + zip -Dmitry On 2014-03-21 15:13, David Holmes wrote: > On 21/03/2014 7:36 PM, Dmitry Samersoff wrote: >> David, >> >> In practice, we don't have to much to keep internally. >> >> There are no reason to copy out some of .debug_* sections but keep other >> ones. > > I'm not familiar with exactly what the different strip options do but > the point is this is covered by the strip-policy. > >> So we have a matrix: >> >> (a) Strip mode: >> >> 1. full >> 2. keep symbols >> 3. keep symbols and .debug_* >> >> >> (b) Copy mode: >> >> 1. Copy all to ext file >> 2. Copy none to ext file >> >> >> (c) Compression mode: >> >> 1. none >> 2. per-section compression, SHF_GNU_COMPRESSED [1] >> 3. zip entire file >> >> Where >> *a2 + b2 + c2* have perfect sense, > > So now your compression mode may apply to either the external file or > the original? That's even more permutations. > >> *a1 + b1 + c3* have no sense etc. > > Why does full strip + copy-all + zip make no sense? It is exactly what > we do with embedded builds. (Naturally you have to copy before you strip) > > David > ----- > >> >> -Dmitry >> >> >> Refs: >> 1. >> https://sourceware.org/bugzilla/show_bug.cgi?id=11819 >> http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01780.html >> >> >> -Dmitry >> >> On 2014-03-21 12:57, David Holmes wrote: >>> On 21/03/2014 6:14 PM, Magnus Ihse Bursie wrote: >>>> >>>>> I don't think this quite works as there are other variations not >>>>> captured here. Rather than "zipped" it should just be "external". >>>>> Whether the debuginfo files are zipped or not is then an additional >>>>> build time option. Additionally we still have to be able to control >>>>> the degree of stripping th > *Subject:* Fwd: Re: Compute sizes of classes loat is carried out. It doesn't make sense to >>>>> me to try and enumerate all possible combinations as top-level >>>>> configure options. >>>>> >>>>> Further, as Dan was saying, this doesn't capture the overlap between >>>>> "internal" and "external" because we still leave some symbols internal >>>>> even when creating the debuginfo file. >>>>> >>>>> So I don't think this proposed categorization works. We still have >>>>> three aspects: >>>>> - generating symbols into the object files >>>>> - stripping symbols from the final binaries >>>>> - saving symbols into an external form >>>>> >>>>> Each of which can potentally be varied (of course if you don't >>>>> generate symbols in the obj files stripping and saving are non >>>>> issues). >>>> >>>> But they are not independent on each other! >>>> >>>> Unless you generate debug symbols, you can't strip them, nor save them >>>> elsewhere. So generating debug symbols (your item #1) is a prerequisite >>>> for the rest of your items. >>> >>> Yes I just said that. :) >>> >>>> And while, technically, you can save symbols externally, and at the >>>> same >>>> time keep them in the binary, that does not make sense. So, in a >>>> practical sense, you are going to do #2 if you are going to do #3. >>> >>> But you can vary what is kept internally independent of what is made >>> external. >>> >>>> And you can't zip external symbols unless you create a non-zipped >>>> version. And if you zip them, it does not make sense to keep the >>>> non-zipped version. >>> >>> zip vs non-zip is just an issue of disk space. It is not a fundamental >>> configuration choice, just a variation on how external symbols are >>> packaged. >>> >>>> And yes, we do not strip all debug information when creating external >>>> debug info. But there seems to be no real use case (not even for >>>> IcedTea, as it turned out) to want a completely stripped binary, I >>>> don't >>>> think that's worth discussing much. That's just part of how the >>>> external >>>> debuginfo scheme works. >>> >>> Umm we fully strip all our binaries in embedded. >>> >>>> Can you give a more concrete example of the variations of your >>>> "aspects" >>>> that you think my suggested solution would not capture? >>> >>> I think I already have. There aren't tree simple choices here, there are >>> three aspects, each of which could have different variants. >>> >>> If I could draw a flow chart easily I would but basically if you >>> generate debug symbols you can then select what symbols are kept >>> internally (the strip policy) and what are put externally (objcopy >>> options), then for the external symbol file you can choose zipped or >>> unzipped. >>> >>> Multiple inter-connected choices, not just three (or four if you add >>> zipped) >>> >>> David >>> >>>> /Magnus >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From goetz.lindenmaier at sap.com Fri Mar 21 14:40:28 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 21 Mar 2014 14:40:28 +0000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <532C1DA7.1030409@oracle.com> References: <531F9370.4020305@oracle.com> <5320E5F8.3020500@oracle.com> <5326766F.80104@oracle.com> <5326DE2F.6000107@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> <532BA650.7000402@oracle.com> <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> <532C1DA7.1030409@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA9BF4@DEWDFEMB12A.global.corp.sap> Hi David, yes, it's the hotspot only build. But that's no good If I have to set something that can be easily derived from information already available! I at least would add another $(shell uname -m) test in the condition in the ppc64.make file. ifeq (,$(filter $(OPENJDK_TARGET_CPU_ENDIAN),big little)) OPENJDK_TARGET_CPU_ENDIAN=big ifeq($(shell uname -m), ppc64le) OPENJDK_TARGET_CPU_ENDIAN =little endif endif Also, I don't see how defs.make deals with the outcome ppc64le of uname. Sasha, is there missing something from your change? If there needs to be a section # PPC64le ifeq ($(ARCH), ppc64le) ARCH_DATA_MODEL = 64 MAKE_ARGS += LP64=1 PLATFORM = linux-ppc64 VM_PLATFORM = linux_ppc64 HS_ARCH = ppc endif setting OPENJDK_TARGET_CPU_ENDIAN should be added there I think. Best regards, Goetz -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Friday, March 21, 2014 12:08 PM To: Lindenmaier, Goetz; 'Alexander Smundak' Cc: 'build-dev'; 'HotSpot Open Source Developers' Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model On 21/03/2014 7:06 PM, Lindenmaier, Goetz wrote: > Hi Sasha, > > I tried to test your change (02), but it does not work. > On linux ppc be;) I get > > make[4]: Leaving directory `/net/usr.work/d045726/oJ/builds/8036767-comp-ld9502-dbg/linux_ppc64_compiler2/debug' > make[4]: Entering directory `/net/usr.work/d045726/oJ/builds/8036767-comp-ld9502-dbg/linux_ppc64_compiler2/debug' > /sapmnt/home1/d045726/oJ/8036767-hs-comp/make/linux/makefiles/ppc64.make:30: *** OPENJDK_TARGET_CPU_ENDIAN has not been passed to this makefile. Stop. > > which is just what you discussed with David. Was that a full configure build or a hotspot-only build? For hotspot-only you would need to set this explicitly. David > On Aix I get > "/sapmnt/home1/d045726/oJ/8036767-aix-hs-comp/src/cpu/ppc/vm/bytes_ppc.hpp", line 277.10: 1540-0836 (S) The #include file "bytes_linux_ppc.inline.hpp" is not found. > > I think we fixed this before, you need to add > #ifdef TARGET_OS_ARCH_linux_ppc > around the include. > > Also, you need to fix os_linux.cpp: remove > + #if defined(PPC64) > else other platforms will not build (linux x86_64): > /sapmnt/home/d045726/oJ/8036767-hs-comp/src/os/linux/vm/os_linux.cpp:1972: error: ???PPC64_ELFDATA2XSB??? was not declared in this scope > > Thanks for undoing the change in make/linux/Makefile! > > Best regards, > Goetz. > > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Alexander Smundak > Sent: Friday, March 21, 2014 7:15 AM > To: David Holmes > Cc: build-dev; HotSpot Open Source Developers > Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model > > Revised the patch to use OPENJDK_TARGET_CPU_ENDIAN instead. The new > version is at: > http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.02 > > On Thu, Mar 20, 2014 at 8:57 PM, David Holmes wrote: >> On 21/03/2014 1:42 PM, Alexander Smundak wrote: >>> >>> On Thu, Mar 20, 2014 at 7:39 PM, David Holmes >>> wrote: >>>> >>>> The build changes look much cleaner to me - thanks. >>> >>> It's at the expense of platform directory being ppc64/ instead of the >>> conventional ppc64le/, and having rather ugly check in the ppc64.make >>> file. >>> >>> >>>> Why are you not using OPENJDK_TARGET_CPU_ENDIAN directly? Ah! Because it >>>> doesn't reach down into the .make files. ZERO_ENDIANNESS does but >>>> seems inappropriate if this is not Zero specific. (I'm also not seeing >>>> how >>>> ZERO_ENDIANNESS reaches down that far either ??). >>> >>> configure script writes hotspot-spec.gmk file to the top-level build >>> directory, >>> and it contains >>> ZERO_ENDIANNESS=$(OPENJDK_TARGET_CPU_ENDIAN) >> >> >> Yes but my query was how does ZERO_ENDIANNESS become visible in ppc64.make? >> The answer to which is that the generated flags.make file has an explicit >> include of hotspot-spec.gmk. In which case you don't need to use >> ZERO_ENDIANNESS you can just use $(OPENJDK_TARGET_CPU_ENDIAN) directly. >> (Which now begs the question as to why ZERO_ENDIANNESS even exists - perhaps >> it predates the integration with the new build.) >> >> David >> ----- >> >> >>> The patch contains the fuse in ppc64.make, the build will fail unless >>> ZERO_ENDIANNESS is set. >>> >>>>> jdk: http://cr.openjdk.java.net/~martin/asmundak/8036767/jdk/webrev.01 >>>> >>>> >>>> >>>> This change: >>>> >>>> - LDFLAGS_SUFFIX := $(ALSA_LIBS) -ljava -ljvm, \ >>>> + LDFLAGS_SUFFIX := $(ALSA_LIBS) $(LIBDL) $(LIBM) -lpthread -ljava >>>> -ljvm, \ >>>> >>>> seems unrelated to endianness. Why is it needed, and why is it being >>>> applied >>>> to all platforms? >>> >>> Sorry, this is not needed, it's the problem with the toolchain I am using. >>> >>> Please ignore this patch. >>> >> From joel.franck at oracle.com Fri Mar 21 14:52:37 2014 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Fri, 21 Mar 2014 15:52:37 +0100 Subject: RFR: 8035063: Option handling in sjavac needs to be rewritten In-Reply-To: <20140319084939.GA17590@e6430> References: <20140319084939.GA17590@e6430> Message-ID: <20140321145237.GE3061@oracle.com> Hi, On 2014-03-19, Andreas Lundblad wrote: > Hi compiler-dev + build-dev, > > Please review the fix for JDK-8035063 and JDK-8037085 which involves changes to sjavac (option handling) and dev/ + dev/jdk build files. > > > Description: > > - Sjavac relied on passing around the main arg array to whatever part of the code that were potentially affected by command line options. The patch restructures the code so that all option are validated and parsed up front. > > - A recent commit in the JDK repository exposed another sjavac bug caused by having directory names that were not valid package identifiers. The patch changes sjavac to handle directories instead of packages... > > - ...which required modifying a couple of .gmk so that arguments are passed as directories (separated by "/") instead of packages (separated with ".") > > - Finally the patch adds a couple of unit tests which cover the new code. > > > Link to webrevs: > http://cr.openjdk.java.net/~alundblad/8035063/ > - dev build (dev/make/common/JavaCompilation.gmk) > - jdk build (dev/jdk/make/CompileJavaClasses.gmk) > - langtools (the sjavac changes + tests) > > > Links to bug reports: > https://bugs.openjdk.java.net/browse/JDK-8035063 > https://bugs.openjdk.java.net/browse/JDK-8037085 > I think this looks good. In the future, if we need the ability to exclude packages we can add it back (-xp or something like it), but we currently don't need it. cheers /Joel From asmundak at google.com Fri Mar 21 01:59:45 2014 From: asmundak at google.com (Alexander Smundak) Date: Thu, 20 Mar 2014 18:59:45 -0700 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <53282020.5040302@oracle.com> References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA6A09@DEWDFEMB12A.global.corp.sap> <531F9370.4020305@oracle.com> <5320E5F8.3020500@oracle.com> <5326766F.80104@oracle.com> <5326DE2F.6000107@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> Message-ID: I've revised the patch to have fold little endian and big endian PowerPC64 architectures. The patch for the hotspot repository is at http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.01 Top-level build's OPENJDK_TARGET_CPU_ENDIAN variable is carried over to the Hotspot build as ZERO_ENDIANNESS, so the patch takes advantage of this to set target-dependend compiler flags in make/linux/makefiles/ppc64.make. The accompanying patches for the other repositories are at: top-level: http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.01 jdk: http://cr.openjdk.java.net/~martin/asmundak/8036767/jdk/webrev.01 From asmundak at google.com Fri Mar 21 03:42:00 2014 From: asmundak at google.com (Alexander Smundak) Date: Thu, 20 Mar 2014 20:42:00 -0700 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <532BA650.7000402@oracle.com> References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA6A09@DEWDFEMB12A.global.corp.sap> <531F9370.4020305@oracle.com> <5320E5F8.3020500@oracle.com> <5326766F.80104@oracle.com> <5326DE2F.6000107@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> <532BA650.7000402@oracle.com> Message-ID: On Thu, Mar 20, 2014 at 7:39 PM, David Holmes wrote: > The build changes look much cleaner to me - thanks. It's at the expense of platform directory being ppc64/ instead of the conventional ppc64le/, and having rather ugly check in the ppc64.make file. > Why are you not using OPENJDK_TARGET_CPU_ENDIAN directly? Ah! Because it > doesn't reach down into the .make files. ZERO_ENDIANNESS does but > seems inappropriate if this is not Zero specific. (I'm also not seeing how > ZERO_ENDIANNESS reaches down that far either ??). configure script writes hotspot-spec.gmk file to the top-level build directory, and it contains ZERO_ENDIANNESS=$(OPENJDK_TARGET_CPU_ENDIAN) The patch contains the fuse in ppc64.make, the build will fail unless ZERO_ENDIANNESS is set. >> jdk: http://cr.openjdk.java.net/~martin/asmundak/8036767/jdk/webrev.01 > > > This change: > > - LDFLAGS_SUFFIX := $(ALSA_LIBS) -ljava -ljvm, \ > + LDFLAGS_SUFFIX := $(ALSA_LIBS) $(LIBDL) $(LIBM) -lpthread -ljava > -ljvm, \ > > seems unrelated to endianness. Why is it needed, and why is it being applied > to all platforms? Sorry, this is not needed, it's the problem with the toolchain I am using. Please ignore this patch. From gnu.andrew at redhat.com Fri Mar 21 17:25:40 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 21 Mar 2014 13:25:40 -0400 (EDT) Subject: [OpenJDK 2D-Dev] RFR: Allow using a system-installed lcms2 In-Reply-To: <20140319232544.GB3167@redhat.com> References: <20140220224044.GB20217@redhat.com> <20140228212732.GG1965@redhat.com> <531101FE.2080600@oracle.com> <20140228232443.GB18442@redhat.com> <5326DC34.3060602@oracle.com> <5329C8F4.1080302@oracle.com> <20140319232544.GB3167@redhat.com> Message-ID: <1825429909.979300.1395422740031.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi, > > * Phil Race [2014-03-19 12:39]: > > On 3/17/2014 4:27 AM, Magnus Ihse Bursie wrote: > > >While we generally support moving files to a proper location, if > > >this move is causing trouble for Phil and the 2d team, we think it > > >can be an acceptable exception this time to just single out the > > >LCMS.c file. (This can be achieved by setting > > >INCLUDE_FILES:=LCMS.c -- that will automatically exclude other > > >files in the SRC dirs.) > > Magnus, thanks for the pointer! > > > This sounds like a reasonable plan. > > The final on disk bits in the JRE/lib/arch directory should however always > > show "liblcms.so" and in the case of a build which didn't select the system > > installed option this will contain everything. > > The following webrevs implement this: > Root: http://cr.openjdk.java.net/~omajid/webrevs/system-lcms/01/ > JDK: http://cr.openjdk.java.net/~omajid/webrevs/system-lcms/01-jdk/ > Why the huge duplication in make/lib/Awt2dLibraries.gmk? > > I don't think JPRT runs any relevant tests. As someone else just found > > out yesterday relying on it to test client code will bite you. > > I tested that this builds but nothing else so far. Any pointers to what > is a good way to test this client code? > > Thanks, > Omair > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From omajid at redhat.com Fri Mar 21 17:27:53 2014 From: omajid at redhat.com (Omair Majid) Date: Fri, 21 Mar 2014 13:27:53 -0400 Subject: [OpenJDK 2D-Dev] RFR: Allow using a system-installed lcms2 In-Reply-To: <1825429909.979300.1395422740031.JavaMail.zimbra@redhat.com> References: <20140220224044.GB20217@redhat.com> <20140228212732.GG1965@redhat.com> <531101FE.2080600@oracle.com> <20140228232443.GB18442@redhat.com> <5326DC34.3060602@oracle.com> <5329C8F4.1080302@oracle.com> <20140319232544.GB3167@redhat.com> <1825429909.979300.1395422740031.JavaMail.zimbra@redhat.com> Message-ID: <20140321172752.GF6449@redhat.com> * Andrew Hughes [2014-03-21 13:25]: > Why the huge duplication in make/lib/Awt2dLibraries.gmk? I couldn't find a way to make an argument conditional (the 'INCLUDE_FILES := LCMS.c,' bit) inside the $(call ...) block. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From asmundak at google.com Fri Mar 21 21:02:20 2014 From: asmundak at google.com (Alexander Smundak) Date: Fri, 21 Mar 2014 14:02:20 -0700 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA6A09@DEWDFEMB12A.global.corp.sap> <531F9370.4020305@oracle.com> <5320E5F8.3020500@oracle.com> <5326766F.80104@oracle.com> <5326DE2F.6000107@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> <532BA650.7000402@oracle.com> <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> Message-ID: On Fri, Mar 21, 2014 at 2:06 AM, Lindenmaier, Goetz wrote: > /sapmnt/home1/d045726/oJ/8036767-hs-comp/make/linux/makefiles/ppc64.make:30: *** OPENJDK_TARGET_CPU_ENDIAN has not been passed to this makefile. Stop. I've fixed make/linux/makefile/defs.make to remap ARCH from ppc64le to ppc64. I have fixed make/linux/makefiles/ppc64.make to set OPENJDK_TARGET_CPU_ENDIAN if it hasn't been set by the caller. > On Aix I get > "/sapmnt/home1/d045726/oJ/8036767-aix-hs-comp/src/cpu/ppc/vm/bytes_ppc.hpp", line 277.10: 1540-0836 (S) The #include file "bytes_linux_ppc.inline.hpp" is not found. > > I think we fixed this before [...] Sorry, I forgot to resync with another repository. Done. The new patch is: http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.03 From goetz.lindenmaier at sap.com Fri Mar 21 21:55:38 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 21 Mar 2014 21:55:38 +0000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA6A09@DEWDFEMB12A.global.corp.sap> <531F9370.4020305@oracle.com> <5320E5F8.3020500@oracle.com> <5326766F.80104@oracle.com> <5326DE2F.6000107@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> <532BA650.7000402@oracle.com> <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> Hi Sasha, I still get a small problem in ppc64.make. You need to remove the space before big and little in the assignment: OPENJDK_TARGET_CPU_ENDIAN := $(if $(filter ppc64le,$(shell uname -m)),little,big) My build ran into the 'little' case below, as I understand because ' big' was compared with 'big'. Make is strange ... After fixing that, tested linuxppc64, aix and linuxx86_64, they all work. Best regards, Goetz. -----Original Message----- From: Alexander Smundak [mailto:asmundak at google.com] Sent: Friday, March 21, 2014 10:02 PM To: Lindenmaier, Goetz Cc: David Holmes; build-dev; HotSpot Open Source Developers Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model On Fri, Mar 21, 2014 at 2:06 AM, Lindenmaier, Goetz wrote: > /sapmnt/home1/d045726/oJ/8036767-hs-comp/make/linux/makefiles/ppc64.make:30: *** OPENJDK_TARGET_CPU_ENDIAN has not been passed to this makefile. Stop. I've fixed make/linux/makefile/defs.make to remap ARCH from ppc64le to ppc64. I have fixed make/linux/makefiles/ppc64.make to set OPENJDK_TARGET_CPU_ENDIAN if it hasn't been set by the caller. > On Aix I get > "/sapmnt/home1/d045726/oJ/8036767-aix-hs-comp/src/cpu/ppc/vm/bytes_ppc.hpp", line 277.10: 1540-0836 (S) The #include file "bytes_linux_ppc.inline.hpp" is not found. > > I think we fixed this before [...] Sorry, I forgot to resync with another repository. Done. The new patch is: http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.03 From magnus.ihse.bursie at oracle.com Sat Mar 22 00:04:44 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sat, 22 Mar 2014 01:04:44 +0100 Subject: [OpenJDK 2D-Dev] RFR: Allow using a system-installed lcms2 In-Reply-To: <20140321172752.GF6449@redhat.com> References: <20140220224044.GB20217@redhat.com> <20140228212732.GG1965@redhat.com> <531101FE.2080600@oracle.com> <20140228232443.GB18442@redhat.com> <5326DC34.3060602@oracle.com> <5329C8F4.1080302@oracle.com> <20140319232544.GB3167@redhat.com> <1825429909.979300.1395422740031.JavaMail.zimbra@redhat.com> <20140321172752.GF6449@redhat.com> Message-ID: <532CD39C.6070203@oracle.com> On 2014-03-21 18:27, Omair Majid wrote: > * Andrew Hughes [2014-03-21 13:25]: >> Why the huge duplication in make/lib/Awt2dLibraries.gmk? > I couldn't find a way to make an argument conditional (the > 'INCLUDE_FILES := LCMS.c,' bit) inside the $(call ...) block. The typical way to solve that is to assign to a variable, e.g. ifeq ($(USE_EXTERNAL_LCMS), true) # If we're using an external library, we'll just need the wrapper part. # By including it explicitely, all other files will be excluded. BUILD_LIBLCMS_INCLUDE_FILES := LCMS.c else BUILD_LIBLCMS_INCLUDE_FILES := endif and then using INCLUDE_FILES := $(BUILD_LIBLCMS_INCLUDE_FILES), \ inside the build declaration. /Magnus From david.holmes at oracle.com Sat Mar 22 00:08:32 2014 From: david.holmes at oracle.com (David Holmes) Date: Sat, 22 Mar 2014 10:08:32 +1000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA9BF4@DEWDFEMB12A.global.corp.sap> References: <5320E5F8.3020500@oracle.com> <5326766F.80104@oracle.com> <5326DE2F.6000107@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> <532BA650.7000402@oracle.com> <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> <532C1DA7.1030409@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9BF4@DEWDFEMB12A.global.corp.sap> Message-ID: <532CD480.1050505@oracle.com> On 22/03/2014 12:40 AM, Lindenmaier, Goetz wrote: > Hi David, > > yes, it's the hotspot only build. > > But that's no good If I have to set something that can be > easily derived from information already available! > > I at least would add another $(shell uname -m) test > in the condition in the ppc64.make file. It is your file but personally I think this is moving in the wrong direction. We should move away from a build process where we perform hotspot builds outside of a configure-based build setup (easily done, just use target hotspot-only). Otherwise we continue to duplicate logic in the configure files and then in the hotspot makefiles. David ----- > ifeq (,$(filter $(OPENJDK_TARGET_CPU_ENDIAN),big little)) > OPENJDK_TARGET_CPU_ENDIAN=big > ifeq($(shell uname -m), ppc64le) > OPENJDK_TARGET_CPU_ENDIAN =little > endif > endif > > Also, I don't see how defs.make deals with the outcome ppc64le of uname. > Sasha, is there missing something from your change? > If there needs to be a section > # PPC64le > ifeq ($(ARCH), ppc64le) > ARCH_DATA_MODEL = 64 > MAKE_ARGS += LP64=1 > PLATFORM = linux-ppc64 > VM_PLATFORM = linux_ppc64 > HS_ARCH = ppc > endif > setting OPENJDK_TARGET_CPU_ENDIAN should be added there I think. > > Best regards, > Goetz > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Friday, March 21, 2014 12:08 PM > To: Lindenmaier, Goetz; 'Alexander Smundak' > Cc: 'build-dev'; 'HotSpot Open Source Developers' > Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model > > On 21/03/2014 7:06 PM, Lindenmaier, Goetz wrote: >> Hi Sasha, >> >> I tried to test your change (02), but it does not work. >> On linux ppc be;) I get >> >> make[4]: Leaving directory `/net/usr.work/d045726/oJ/builds/8036767-comp-ld9502-dbg/linux_ppc64_compiler2/debug' >> make[4]: Entering directory `/net/usr.work/d045726/oJ/builds/8036767-comp-ld9502-dbg/linux_ppc64_compiler2/debug' >> /sapmnt/home1/d045726/oJ/8036767-hs-comp/make/linux/makefiles/ppc64.make:30: *** OPENJDK_TARGET_CPU_ENDIAN has not been passed to this makefile. Stop. >> >> which is just what you discussed with David. > > Was that a full configure build or a hotspot-only build? For > hotspot-only you would need to set this explicitly. > > David > > >> On Aix I get >> "/sapmnt/home1/d045726/oJ/8036767-aix-hs-comp/src/cpu/ppc/vm/bytes_ppc.hpp", line 277.10: 1540-0836 (S) The #include file "bytes_linux_ppc.inline.hpp" is not found. >> >> I think we fixed this before, you need to add >> #ifdef TARGET_OS_ARCH_linux_ppc >> around the include. >> >> Also, you need to fix os_linux.cpp: remove >> + #if defined(PPC64) >> else other platforms will not build (linux x86_64): >> /sapmnt/home/d045726/oJ/8036767-hs-comp/src/os/linux/vm/os_linux.cpp:1972: error: ???PPC64_ELFDATA2XSB??? was not declared in this scope >> >> Thanks for undoing the change in make/linux/Makefile! >> >> Best regards, >> Goetz. >> >> >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Alexander Smundak >> Sent: Friday, March 21, 2014 7:15 AM >> To: David Holmes >> Cc: build-dev; HotSpot Open Source Developers >> Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model >> >> Revised the patch to use OPENJDK_TARGET_CPU_ENDIAN instead. The new >> version is at: >> http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.02 >> >> On Thu, Mar 20, 2014 at 8:57 PM, David Holmes wrote: >>> On 21/03/2014 1:42 PM, Alexander Smundak wrote: >>>> >>>> On Thu, Mar 20, 2014 at 7:39 PM, David Holmes >>>> wrote: >>>>> >>>>> The build changes look much cleaner to me - thanks. >>>> >>>> It's at the expense of platform directory being ppc64/ instead of the >>>> conventional ppc64le/, and having rather ugly check in the ppc64.make >>>> file. >>>> >>>> >>>>> Why are you not using OPENJDK_TARGET_CPU_ENDIAN directly? Ah! Because it >>>>> doesn't reach down into the .make files. ZERO_ENDIANNESS does but >>>>> seems inappropriate if this is not Zero specific. (I'm also not seeing >>>>> how >>>>> ZERO_ENDIANNESS reaches down that far either ??). >>>> >>>> configure script writes hotspot-spec.gmk file to the top-level build >>>> directory, >>>> and it contains >>>> ZERO_ENDIANNESS=$(OPENJDK_TARGET_CPU_ENDIAN) >>> >>> >>> Yes but my query was how does ZERO_ENDIANNESS become visible in ppc64.make? >>> The answer to which is that the generated flags.make file has an explicit >>> include of hotspot-spec.gmk. In which case you don't need to use >>> ZERO_ENDIANNESS you can just use $(OPENJDK_TARGET_CPU_ENDIAN) directly. >>> (Which now begs the question as to why ZERO_ENDIANNESS even exists - perhaps >>> it predates the integration with the new build.) >>> >>> David >>> ----- >>> >>> >>>> The patch contains the fuse in ppc64.make, the build will fail unless >>>> ZERO_ENDIANNESS is set. >>>> >>>>>> jdk: http://cr.openjdk.java.net/~martin/asmundak/8036767/jdk/webrev.01 >>>>> >>>>> >>>>> >>>>> This change: >>>>> >>>>> - LDFLAGS_SUFFIX := $(ALSA_LIBS) -ljava -ljvm, \ >>>>> + LDFLAGS_SUFFIX := $(ALSA_LIBS) $(LIBDL) $(LIBM) -lpthread -ljava >>>>> -ljvm, \ >>>>> >>>>> seems unrelated to endianness. Why is it needed, and why is it being >>>>> applied >>>>> to all platforms? >>>> >>>> Sorry, this is not needed, it's the problem with the toolchain I am using. >>>> >>>> Please ignore this patch. >>>> >>> From asmundak at google.com Sat Mar 22 00:47:56 2014 From: asmundak at google.com (Alexander Smundak) Date: Fri, 21 Mar 2014 17:47:56 -0700 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA6A09@DEWDFEMB12A.global.corp.sap> <531F9370.4020305@oracle.com> <5320E5F8.3020500@oracle.com> <5326766F.80104@oracle.com> <5326DE2F.6000107@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> <532BA650.7000402@oracle.com> <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> Message-ID: On Fri, Mar 21, 2014 at 2:55 PM, Lindenmaier, Goetz wrote: > My build ran into the 'little' case below, as I understand because ' big' was compared > with 'big'. Make is strange ... Removed the spaces, please take a look at http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.04 From omajid at redhat.com Sat Mar 22 19:11:33 2014 From: omajid at redhat.com (Omair Majid) Date: Sat, 22 Mar 2014 15:11:33 -0400 Subject: [OpenJDK 2D-Dev] RFR: Allow using a system-installed lcms2 In-Reply-To: <532CD39C.6070203@oracle.com> References: <20140220224044.GB20217@redhat.com> <20140228212732.GG1965@redhat.com> <531101FE.2080600@oracle.com> <20140228232443.GB18442@redhat.com> <5326DC34.3060602@oracle.com> <5329C8F4.1080302@oracle.com> <20140319232544.GB3167@redhat.com> <1825429909.979300.1395422740031.JavaMail.zimbra@redhat.com> <20140321172752.GF6449@redhat.com> <532CD39C.6070203@oracle.com> Message-ID: <20140322191133.GB3192@redhat.com> * Magnus Ihse Bursie [2014-03-21 20:04]: > On 2014-03-21 18:27, Omair Majid wrote: > >* Andrew Hughes [2014-03-21 13:25]: > >>Why the huge duplication in make/lib/Awt2dLibraries.gmk? > >I couldn't find a way to make an argument conditional (the > >'INCLUDE_FILES := LCMS.c,' bit) inside the $(call ...) block. > > The typical way to solve that is to assign to a variable, e.g. > > ifeq ($(USE_EXTERNAL_LCMS), true) > # If we're using an external library, we'll just need the wrapper part. > # By including it explicitely, all other files will be excluded. > BUILD_LIBLCMS_INCLUDE_FILES := LCMS.c > else > BUILD_LIBLCMS_INCLUDE_FILES := > endif > > and then using > INCLUDE_FILES := $(BUILD_LIBLCMS_INCLUDE_FILES), \ > inside the build declaration. Thanks. I wasn't sure how an empty value might be processed. Updated webrev: http://cr.openjdk.java.net/~omajid/webrevs/system-lcms/02/ http://cr.openjdk.java.net/~omajid/webrevs/system-lcms/02-jdk/ Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From vladimir.kozlov at oracle.com Sun Mar 23 00:28:42 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 22 Mar 2014 17:28:42 -0700 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: References: <5326766F.80104@oracle.com> <5326DE2F.6000107@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> <532BA650.7000402@oracle.com> <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> Message-ID: <532E2ABA.3060505@oracle.com> Alexander, I think these changes are good. Thanks, Vladimir On 3/21/14 5:47 PM, Alexander Smundak wrote: > On Fri, Mar 21, 2014 at 2:55 PM, Lindenmaier, Goetz > wrote: >> My build ran into the 'little' case below, as I understand because ' big' was compared >> with 'big'. Make is strange ... > > Removed the spaces, please take a look at > http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.04 > From david.holmes at oracle.com Mon Mar 24 03:37:13 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 24 Mar 2014 13:37:13 +1000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: References: <5326766F.80104@oracle.com> <5326DE2F.6000107@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> <532BA650.7000402@oracle.com> <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> Message-ID: <532FA869.7030209@oracle.com> On 22/03/2014 10:47 AM, Alexander Smundak wrote: > On Fri, Mar 21, 2014 at 2:55 PM, Lindenmaier, Goetz > wrote: >> My build ran into the 'little' case below, as I understand because ' big' was compared >> with 'big'. Make is strange ... > > Removed the spaces, please take a look at > http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.04 Stylistically the hotspot makefiles test a variable/expression against a value/constant not the other way around. So: ifeq (undefined,$(origin OPENJDK_TARGET_CPU_ENDIAN)) becomes ifeq ($(origin OPENJDK_TARGET_CPU_ENDIAN),undefined) and the same for all the other comparisons you have added. Sorry. David From magnus.ihse.bursie at oracle.com Mon Mar 24 09:14:00 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 24 Mar 2014 10:14:00 +0100 Subject: RFR[9](XS): 8037298: Export HotSpots 'optimized' (i.e. not-product) configuration in the top-level configure/makefile In-Reply-To: References: <5322CF97.6080301@oracle.com> <532821EF.7070308@oracle.com> Message-ID: <532FF758.8000703@oracle.com> On 2014-03-18 18:26, Volker Simonis wrote: > Done. Please see the new webrev at: > > http://cr.openjdk.java.net/~simonis/webrevs/8037298_3/ Looks good to me. > Thanks. Could you please push this change for me because it requires > the regeneration of generated-configure.sh and potentially also the > regeneration of closed configure files which I can't do. I can do that. I'm pushing it to jdk9-dev, since it only affects the top-level build, so it is unrelated to hotspot (even though it is only needed for building hotspot). /Magnus From magnus.ihse.bursie at oracle.com Mon Mar 24 09:46:37 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 24 Mar 2014 10:46:37 +0100 Subject: [OpenJDK 2D-Dev] RFR: Allow using a system-installed lcms2 In-Reply-To: <20140322191133.GB3192@redhat.com> References: <20140220224044.GB20217@redhat.com> <20140228212732.GG1965@redhat.com> <531101FE.2080600@oracle.com> <20140228232443.GB18442@redhat.com> <5326DC34.3060602@oracle.com> <5329C8F4.1080302@oracle.com> <20140319232544.GB3167@redhat.com> <1825429909.979300.1395422740031.JavaMail.zimbra@redhat.com> <20140321172752.GF6449@redhat.com> <532CD39C.6070203@oracle.com> <20140322191133.GB3192@redhat.com> Message-ID: <532FFEFD.6080607@oracle.com> On 2014-03-22 20:11, Omair Majid wrote: > Thanks. I wasn't sure how an empty value might be processed. Make can't really see the difference between an unassigned variable and one assigned to nothing. (Or, it can, but it's more tricky to check). In all the SetupFoo macros, assigning an empty value or leaving unassigned is the same thing. > > Updated webrev: > http://cr.openjdk.java.net/~omajid/webrevs/system-lcms/02/ > http://cr.openjdk.java.net/~omajid/webrevs/system-lcms/02-jdk/ Looks good to me. I hope this version can be acceptable to all parties. Thank you for continuing tweaking this patch to all requirements that has crept up. /Magnus From magnus.ihse.bursie at oracle.com Mon Mar 24 10:18:09 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 24 Mar 2014 11:18:09 +0100 Subject: RFR: 8030681 : (s) add "serve" command and --quiet and --verbose options to hgforest In-Reply-To: <47199626-9ACE-4898-AB61-69878690A997@oracle.com> References: <5C7F5B32-B543-4B1F-AEE0-17D3317E7F5A@oracle.com> <532AAC8B.4040307@oracle.com> <47199626-9ACE-4898-AB61-69878690A997@oracle.com> Message-ID: <53300661.3010007@oracle.com> On 2014-03-20 17:39, Mike Duigou wrote: >> I found this: >> >> # XXX mduigou I can't figure out how to make the root repo the serve "/" root. >> >> Is this something that ought to be fixed? > I wish I knew how. Despite fiddling with it extensively I was unable to convince hg to serve the top repo from > > http://server:8000/ > > instead the top repo is: > > http://server:8000/ > > I wanted to have the URL of the top repo displayed as part of the serve message but a) can't get hg to display it b) can't determine what the service address is going to be myself to construct the url. > > It's a minor annoyance/limitation that people will get used to. It was a bit unclear to me until I tested running it myself. I see what you mean. But I think this is completely acceptable. I'd recommend you leave the functionality as it is and just removes the comment. Apart from that, the fix looks good to me. /Magnus From magnus.ihse.bursie at oracle.com Mon Mar 24 11:04:31 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 24 Mar 2014 12:04:31 +0100 Subject: RFR: JDK-8035751 Clean up Visual Studio detection logic Message-ID: <5330113F.1020306@oracle.com> This bug was triggered by the issue in JDK-8035725. Had the VS detection logic been more transparent, that bug would not have had to happen. We need to rewrite the VS detection so that it is much more controlled, and do not run an unchecked shell script that modifies arbitrary environment variables. We can never re-create the same circumstances during "make time" as we have during "configure time" in that case. Instead, we should systematically set only those variables that are actually needed. Bug: https://bugs.openjdk.java.net/browse/JDK-8035751 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8035751-clean-up-visual-studio-detection/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Mon Mar 24 11:18:16 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 24 Mar 2014 12:18:16 +0100 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <532C080A.9020002@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <53280AF0.5000502@oracle.com> <532ADE09.7050602@oracle.com> <532BF4E4.5080003@oracle.com> <532BFEE2.6080802@oracle.com> <532C080A.9020002@oracle.com> Message-ID: <53301478.8000809@oracle.com> On 2014-03-21 10:36, Dmitry Samersoff wrote: > > (c) Compression mode: > > 1. none > 2. per-section compression, SHF_GNU_COMPRESSED [1] > 3. zip entire file > Is 2 something we're doing? I couldn't find any references to it in the code. Or is it something we're planning to do? /Magnus From erik.joelsson at oracle.com Mon Mar 24 11:20:10 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 24 Mar 2014 12:20:10 +0100 Subject: RFR: JDK-8035751 Clean up Visual Studio detection logic In-Reply-To: <5330113F.1020306@oracle.com> References: <5330113F.1020306@oracle.com> Message-ID: <533014EA.5000507@oracle.com> I think it looks good overall and it's good to clean this up. toolchain_windows.m4: 204: not your change but the typo stings my eyes and could be fixed while in the area. (corrent?) I wonder if it would be better to move the deletion of the temporary script files to later in the function so that they are still around if it fails, for easier debugging? /Erik On 2014-03-24 12:04, Magnus Ihse Bursie wrote: > This bug was triggered by the issue in JDK-8035725. Had the VS > detection logic been more transparent, that bug would not have had to > happen. > > We need to rewrite the VS detection so that it is much more > controlled, and do not run an unchecked shell script that modifies > arbitrary environment variables. We can never re-create the same > circumstances during "make time" as we have during "configure time" in > that case. Instead, we should systematically set only those variables > that are actually needed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8035751 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8035751-clean-up-visual-studio-detection/webrev.01 > > /Magnus From magnus.ihse.bursie at oracle.com Mon Mar 24 11:33:19 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 24 Mar 2014 12:33:19 +0100 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <532BFEE2.6080802@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> <53112019.9050504@oracle.com> <20140303214923.GA26825@redhat.com> <5315424A.4080201@oracle.com> <633566380.792587.1395105570031.JavaMail.zimbra@redhat.com> <53280AF0.5000502@oracle.com> <532ADE09.7050602@oracle.com> <532BF4E4.5080003@oracle.com> <532BFEE2.6080802@oracle.com> Message-ID: <533017FF.7010400@oracle.com> On 2014-03-21 09:57, David Holmes wrote: > >> And while, technically, you can save symbols externally, and at the same >> time keep them in the binary, that does not make sense. So, in a >> practical sense, you are going to do #2 if you are going to do #3. > > But you can vary what is kept internally independent of what is made > external. While that technically is correct, not all combinations does make sense. > >> And you can't zip external symbols unless you create a non-zipped >> version. And if you zip them, it does not make sense to keep the >> non-zipped version. > > zip vs non-zip is just an issue of disk space. It is not a fundamental > configuration choice, just a variation on how external symbols are > packaged. So can we agree that for external symbols, there are three ways to deal with them: no external symbols unzipped external symbols zipped external symbols ? >> Can you give a more concrete example of the variations of your "aspects" >> that you think my suggested solution would not capture? > > I think I already have. There aren't tree simple choices here, there > are three aspects, each of which could have different variants. > > If I could draw a flow chart easily I would but basically if you > generate debug symbols you can then select what symbols are kept > internally (the strip policy) and what are put externally (objcopy > options), then for the external symbol file you can choose zipped or > unzipped. > > Multiple inter-connected choices, not just three (or four if you add > zipped) And then there's the aspect that got this bug started, that you need to compile with -g to be able to have any useful symbols at all. While technically you can compile without -g and then run strip, it's a combination that does not make sense. In the end, it all boils down to a few sensible ways to handle all debug information. 1) The Oracle way -- copying debug information into an external format (that by default is zipped), and stripping the binary as much as reasonable. 2) The community way -- keep everything in the binary, and not creating a separate external format. 3) The hardcore way -- ignore debug information alltogether. Instead of providing a lots of handles and knobs to configure, that will allow the user to configure invalid (e.g. zip-external=true, produce-external=false), or meaningless (compile-with-debug-flag=yes, strip=everything, produce-external=false), I'd rather provide a high-level option (or two, if it's not possible to condense into a single option) that allows the user to express the intent. And for all practical purposes, it's going to be set to either "oracle mode" or "community mode". /Magnus From magnus.ihse.bursie at oracle.com Mon Mar 24 12:52:21 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 24 Mar 2014 13:52:21 +0100 Subject: RFR: JDK-8035751 Clean up Visual Studio detection logic In-Reply-To: <533014EA.5000507@oracle.com> References: <5330113F.1020306@oracle.com> <533014EA.5000507@oracle.com> Message-ID: <53302A85.50100@oracle.com> On 2014-03-24 12:20, Erik Joelsson wrote: > I think it looks good overall and it's good to clean this up. > > toolchain_windows.m4: > 204: not your change but the typo stings my eyes and could be fixed > while in the area. (corrent?) Fixed. > I wonder if it would be better to move the deletion of the temporary > script files to later in the function so that they are still around if > it fails, for easier debugging? Actually, there's no real need to delete the files at all. I commented out the removal during debugging of this patch at several occasions. We should just keep them around, if we need to debug them. I've modified the script to put them in "OUTPUT/vs-env" and keep them there. I also realized the names I chose didn't match our naming standard (_ instead of - as separator). I fixed this as well. Updated webrev: http://cr.openjdk.java.net/~ihse/JDK-8035751-clean-up-visual-studio-detection/webrev.02 /Magnus From asmundak at google.com Mon Mar 24 20:09:51 2014 From: asmundak at google.com (Alexander Smundak) Date: Mon, 24 Mar 2014 13:09:51 -0700 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <532FA869.7030209@oracle.com> References: <5326766F.80104@oracle.com> <5326DE2F.6000107@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> <532BA650.7000402@oracle.com> <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> <532FA869.7030209@oracle.com> Message-ID: Done. Uploaded http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.05 On Sun, Mar 23, 2014 at 8:37 PM, David Holmes wrote: > On 22/03/2014 10:47 AM, Alexander Smundak wrote: >> >> On Fri, Mar 21, 2014 at 2:55 PM, Lindenmaier, Goetz >> wrote: >>> >>> My build ran into the 'little' case below, as I understand because ' big' >>> was compared >>> with 'big'. Make is strange ... >> >> >> Removed the spaces, please take a look at >> http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.04 > > > Stylistically the hotspot makefiles test a variable/expression against a > value/constant not the other way around. So: > > ifeq (undefined,$(origin OPENJDK_TARGET_CPU_ENDIAN)) > > becomes > > ifeq ($(origin OPENJDK_TARGET_CPU_ENDIAN),undefined) > > and the same for all the other comparisons you have added. > > > Sorry. > > David > From goetz.lindenmaier at sap.com Mon Mar 24 21:32:31 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 24 Mar 2014 21:32:31 +0000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: References: <5326766F.80104@oracle.com> <5326DE2F.6000107@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> <532BA650.7000402@oracle.com> <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> <532FA869.7030209@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEAA13C@DEWDFEMB12A.global.corp.sap> Hi, builds and runs on ppc linux be / aix. Best regards, Goetz. -----Original Message----- From: Alexander Smundak [mailto:asmundak at google.com] Sent: Monday, March 24, 2014 9:10 PM To: David Holmes Cc: Lindenmaier, Goetz; build-dev; HotSpot Open Source Developers Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model Done. Uploaded http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.05 On Sun, Mar 23, 2014 at 8:37 PM, David Holmes wrote: > On 22/03/2014 10:47 AM, Alexander Smundak wrote: >> >> On Fri, Mar 21, 2014 at 2:55 PM, Lindenmaier, Goetz >> wrote: >>> >>> My build ran into the 'little' case below, as I understand because ' big' >>> was compared >>> with 'big'. Make is strange ... >> >> >> Removed the spaces, please take a look at >> http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.04 > > > Stylistically the hotspot makefiles test a variable/expression against a > value/constant not the other way around. So: > > ifeq (undefined,$(origin OPENJDK_TARGET_CPU_ENDIAN)) > > becomes > > ifeq ($(origin OPENJDK_TARGET_CPU_ENDIAN),undefined) > > and the same for all the other comparisons you have added. > > > Sorry. > > David > From tim.bell at oracle.com Mon Mar 24 22:12:24 2014 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 24 Mar 2014 15:12:24 -0700 Subject: RFR: JDK-8035751 Clean up Visual Studio detection logic In-Reply-To: <533014EA.5000507@oracle.com> References: <5330113F.1020306@oracle.com> <533014EA.5000507@oracle.com> Message-ID: <5330ADC8.40300@oracle.com> Hi Magnus Looks good to me as well. Tim On 03/24/14 04:20, Erik Joelsson wrote: > I think it looks good overall and it's good to clean this up. > > toolchain_windows.m4: > 204: not your change but the typo stings my eyes and could be fixed > while in the area. (corrent?) > > I wonder if it would be better to move the deletion of the temporary > script files to later in the function so that they are still around if > it fails, for easier debugging? > > /Erik > > On 2014-03-24 12:04, Magnus Ihse Bursie wrote: >> This bug was triggered by the issue in JDK-8035725. Had the VS >> detection logic been more transparent, that bug would not have had to >> happen. >> >> We need to rewrite the VS detection so that it is much more >> controlled, and do not run an unchecked shell script that modifies >> arbitrary environment variables. We can never re-create the same >> circumstances during "make time" as we have during "configure time" >> in that case. Instead, we should systematically set only those >> variables that are actually needed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8035751 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8035751-clean-up-visual-studio-detection/webrev.01 >> >> /Magnus > From erik.helin at oracle.com Tue Mar 25 09:41:40 2014 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 25 Mar 2014 10:41:40 +0100 Subject: RFR: 8033580: Old debug information in IMPORT_JDK is not removed In-Reply-To: <5301C3A3.1090406@oracle.com> References: <52FB8D4B.7080807@oracle.com> <52FC0683.2010301@oracle.com> <52FD3218.9010403@oracle.com> <52FD5571.4010104@oracle.com> <52FE185F.4070605@oracle.com> <52FE481F.5080208@oracle.com> <5301C3A3.1090406@oracle.com> Message-ID: <53314F54.5020408@oracle.com> Daniel, Erik thanks for the reviews and sorry taking so long to respond. About the indentation: I understand the convention used in the new build system and I think it makes a lot of sense, but the file hotspot/make/Makefile clearly does not use this convention :) I would prefer to use the same kind of indentation as the rest of the file, even though as Dan noted, the file is not consistent with itself. It seems like most of the file is using 2 spaces for ifeq (something) and then just or for recipes depending on logical level. Dan and Erik, are you fine with keeping the indentation as it is or do you prefer that I update the change to use the convention of the new build system? Thanks, Erik On 02/17/2014 09:09 AM, Erik Joelsson wrote: > Hello, > > The change looks good to me too. > > Regarding indentation, for the rest of the JDK, we indent rules with > make ifeqs like this: > > target: sources > <8 spaces>ifeq (something) > recipe line > <8 spaces>endif > > Our reasoning is that it should still look like a recipe when glancing > over it quickly (so 8 characters base indentation). After that we apply > our standard 2 chars per logical level. Since make regards tab > characters as special, we have to use space for non recipe lines. > > The rest of our guidelines can be found here: > http://openjdk.java.net/groups/build/doc/code-conventions.html > > /Erik > > On 2014-02-14 17:45, Daniel D. Daugherty wrote: >> > http://cr.openjdk.java.net/~ehelin/8033580/webrev.03/ >> >> make/Makefile >> No comments. >> >> Makefile style question: >> Since all this ifeq(...) logic is around Makefile rules, >> should the rules themselves be indented by one tab or by >> one tab and some number of spaces. >> >> I scrolled around the Makefile and I don't really see >> consistent indenting of the rule lines themselves... >> >> If you change the indenting, I don't see a reason for >> another round of review. >> >> Dan >> >> >> On 2/14/14 6:21 AM, Erik Helin wrote: >>> Dan, >>> >>> On 2014-02-14 00:29, Daniel D. Daugherty wrote: >>>> > http://cr.openjdk.java.net/~ehelin/8033580/webrev.01/ >>>> >>>> make/Makefile >>>> >>>> + ifeq ($(OSNAME), bsd) >>>> + $(RM) -rf $(EXPORT_SERVER_DIR)/libjvm.dylib.dSYM >>>> >>>> The above needs to be: >>>> >>>> ifeq ($(OS_VENDOR), Darwin) >>>> $(RM) -rf $(EXPORT_SERVER_DIR)/libjvm.dylib.dSYM >>>> >>>> I don't think that BSD uses .dylib stuff; that's MacOS X specific. >>> >>> You are right, thanks for the correction. Please see new webrev at: >>> http://cr.openjdk.java.net/~ehelin/8033580/webrev.03/ >>> >>> Again, same testing as for prior patches were run. >>> >>> Thanks, >>> Erik >>> >>>> Dan >>>> >>>> >>>> On 2/13/14 1:59 PM, Erik Helin wrote: >>>>> Hi Dan, >>>>> >>>>> thanks for reviewing! See my replies inline. >>>>> >>>>> On 02/13/2014 12:40 AM, Daniel D. Daugherty wrote: >>>>>> > http://cr.openjdk.java.net/~ehelin/8033580/webrev.00/ >>>>>> >>>>>> make/Makefile >>>>>> 277 ifeq ($(ZIP_DEBUGINFO_FILES),1) >>>>>> 278 ifeq ($(OSNAME), windows) >>>>>> 279 $(RM) -f $(EXPORT_SERVER_DIR)/jvm.map >>>>>> $(EXPORT_SERVER_DIR)/jvm.pdb >>>>>> 280 else >>>>>> 281 $(RM) -f $(EXPORT_SERVER_DIR)/libjvm.debuginfo >>>>>> 282 endif >>>>>> >>>>>> On MacOS X, the debuginfo will be in libjvm.dylib.dSYM so >>>>>> you'll need a MacOS X specific rule. You don't need an >>>>>> update for the JVM_VARIANT_CLIENT version because MacOS X >>>>>> doesn't support the Client VM, but if it did... >>>>> >>>>> Thanks for catching this! I've uploaded a new webrev at: >>>>> http://cr.openjdk.java.net/~ehelin/8033580/webrev.01/ >>>>> >>>>> The same testing was done as for the first patch. >>>>> >>>>> On 02/13/2014 12:40 AM, Daniel D. Daugherty wrote: >>>>>> So the above change handles libjvm, but what about the >>>>>> other libraries exported by HotSpot? libjsig, libjvm_db, >>>>>> and libjvm_dtrace come to mind... >>>>> >>>>> As we discussed, I would like to implement this for libjvm first and >>>>> then take care of the other libraries in a separate patch. >>>>> >>>>> Thanks, >>>>> Erik >>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> On 2/12/14 8:03 AM, Erik Helin wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> this patch changes how old debug information copied from >>>>>>> IMPORT_JDK is >>>>>>> treated. >>>>>>> >>>>>>> When running the copy_*_jdk target, HotSpot's makefiles copies the >>>>>>> entire IMPORT_JDK folder, including additional files (such as >>>>>>> unzipped >>>>>>> debug information). The export_*_jdk targets will then, via the >>>>>>> generic_export target, copy the build artifacts via implicit >>>>>>> rules to >>>>>>> the correct destination in hotspot/build/JDK_IMAGE_DIR. >>>>>>> >>>>>>> The bug arises when IMPORT_JDK contains unzipped debug info >>>>>>> (libjvm.debuginfo) and the make target produces zipped debug info >>>>>>> (libjvm.diz), or vice versa. hotspot/build/JDK_IMAGE_DIR will then >>>>>>> contain both libjvm.debuginfo and libjvm.diz, but only one of them >>>>>>> will match libjvm.so. >>>>>>> >>>>>>> Finally, the JPRT make targets jprt_build_* just zips >>>>>>> hotspot/build/$(JDK_IMAGE_DIR). The zipped JPRT bundle will end up >>>>>>> having different zipped and unzipped debug info, since the >>>>>>> IMPORT_JDK >>>>>>> in JPRT contains libjvm.debuginfo and we build libjvm.diz by >>>>>>> default. >>>>>>> >>>>>>> This patch removes the debug info that we did *not* build. If we >>>>>>> build >>>>>>> libjvm.diz, then libjvm.debuginfo will be removed (if it exists). >>>>>>> Correspondingly, if we build libjvm.debuginfo, then libjvm.diz >>>>>>> will be >>>>>>> removed (if it exists). >>>>>>> >>>>>>> Patch: >>>>>>> http://cr.openjdk.java.net/~ehelin/8033580/webrev.00/ >>>>>>> >>>>>>> Bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8033580 >>>>>>> >>>>>>> Testing: >>>>>>> - Building in JPRT >>>>>>> - Building Linux 32-bit locally on a Linux 64-bit machine >>>>>>> - Building Linux 64-bit locally on a Linux 64-bit machine >>>>>>> >>>>>>> For all of the above, verify that only the correct debug info is >>>>>>> present in the output. >>>>>>> >>>>>>> Thanks, >>>>>>> Erik >>>>>> >>>> >> > From david.holmes at oracle.com Tue Mar 25 10:32:52 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 25 Mar 2014 20:32:52 +1000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: References: <5326766F.80104@oracle.com> <5326DE2F.6000107@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> <532BA650.7000402@oracle.com> <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> <532FA869.7030209@oracle.com> Message-ID: <53315B54.3050005@oracle.com> Thanks. Build side looks fine to me. David On 25/03/2014 6:09 AM, Alexander Smundak wrote: > Done. Uploaded > http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.05 > > On Sun, Mar 23, 2014 at 8:37 PM, David Holmes wrote: >> On 22/03/2014 10:47 AM, Alexander Smundak wrote: >>> >>> On Fri, Mar 21, 2014 at 2:55 PM, Lindenmaier, Goetz >>> wrote: >>>> >>>> My build ran into the 'little' case below, as I understand because ' big' >>>> was compared >>>> with 'big'. Make is strange ... >>> >>> >>> Removed the spaces, please take a look at >>> http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.04 >> >> >> Stylistically the hotspot makefiles test a variable/expression against a >> value/constant not the other way around. So: >> >> ifeq (undefined,$(origin OPENJDK_TARGET_CPU_ENDIAN)) >> >> becomes >> >> ifeq ($(origin OPENJDK_TARGET_CPU_ENDIAN),undefined) >> >> and the same for all the other comparisons you have added. >> >> >> Sorry. >> >> David >> From daniel.daugherty at oracle.com Tue Mar 25 14:32:25 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 25 Mar 2014 08:32:25 -0600 Subject: RFR: 8033580: Old debug information in IMPORT_JDK is not removed In-Reply-To: <53314F54.5020408@oracle.com> References: <52FB8D4B.7080807@oracle.com> <52FC0683.2010301@oracle.com> <52FD3218.9010403@oracle.com> <52FD5571.4010104@oracle.com> <52FE185F.4070605@oracle.com> <52FE481F.5080208@oracle.com> <5301C3A3.1090406@oracle.com> <53314F54.5020408@oracle.com> Message-ID: <53319379.1030308@oracle.com> I'm fine if you leave your indentation as-is. This can be addressed when the new build system style reaches the HotSpot universe... Dan On 3/25/14 3:41 AM, Erik Helin wrote: > Daniel, Erik > > thanks for the reviews and sorry taking so long to respond. > > About the indentation: I understand the convention used in the new > build system and I think it makes a lot of sense, but the file > hotspot/make/Makefile clearly does not use this convention :) > > I would prefer to use the same kind of indentation as the rest of the > file, even though as Dan noted, the file is not consistent with > itself. It seems like most of the file is using 2 spaces for ifeq > (something) and then just or for recipes > depending on logical level. > > Dan and Erik, are you fine with keeping the indentation as it is or do > you prefer that I update the change to use the convention of the new > build system? > > Thanks, > Erik > > On 02/17/2014 09:09 AM, Erik Joelsson wrote: >> Hello, >> >> The change looks good to me too. >> >> Regarding indentation, for the rest of the JDK, we indent rules with >> make ifeqs like this: >> >> target: sources >> <8 spaces>ifeq (something) >> recipe line >> <8 spaces>endif >> >> Our reasoning is that it should still look like a recipe when glancing >> over it quickly (so 8 characters base indentation). After that we apply >> our standard 2 chars per logical level. Since make regards tab >> characters as special, we have to use space for non recipe lines. >> >> The rest of our guidelines can be found here: >> http://openjdk.java.net/groups/build/doc/code-conventions.html >> >> /Erik >> >> On 2014-02-14 17:45, Daniel D. Daugherty wrote: >>> > http://cr.openjdk.java.net/~ehelin/8033580/webrev.03/ >>> >>> make/Makefile >>> No comments. >>> >>> Makefile style question: >>> Since all this ifeq(...) logic is around Makefile rules, >>> should the rules themselves be indented by one tab or by >>> one tab and some number of spaces. >>> >>> I scrolled around the Makefile and I don't really see >>> consistent indenting of the rule lines themselves... >>> >>> If you change the indenting, I don't see a reason for >>> another round of review. >>> >>> Dan >>> >>> >>> On 2/14/14 6:21 AM, Erik Helin wrote: >>>> Dan, >>>> >>>> On 2014-02-14 00:29, Daniel D. Daugherty wrote: >>>>> > http://cr.openjdk.java.net/~ehelin/8033580/webrev.01/ >>>>> >>>>> make/Makefile >>>>> >>>>> + ifeq ($(OSNAME), bsd) >>>>> + $(RM) -rf $(EXPORT_SERVER_DIR)/libjvm.dylib.dSYM >>>>> >>>>> The above needs to be: >>>>> >>>>> ifeq ($(OS_VENDOR), Darwin) >>>>> $(RM) -rf $(EXPORT_SERVER_DIR)/libjvm.dylib.dSYM >>>>> >>>>> I don't think that BSD uses .dylib stuff; that's MacOS X specific. >>>> >>>> You are right, thanks for the correction. Please see new webrev at: >>>> http://cr.openjdk.java.net/~ehelin/8033580/webrev.03/ >>>> >>>> Again, same testing as for prior patches were run. >>>> >>>> Thanks, >>>> Erik >>>> >>>>> Dan >>>>> >>>>> >>>>> On 2/13/14 1:59 PM, Erik Helin wrote: >>>>>> Hi Dan, >>>>>> >>>>>> thanks for reviewing! See my replies inline. >>>>>> >>>>>> On 02/13/2014 12:40 AM, Daniel D. Daugherty wrote: >>>>>>> > http://cr.openjdk.java.net/~ehelin/8033580/webrev.00/ >>>>>>> >>>>>>> make/Makefile >>>>>>> 277 ifeq ($(ZIP_DEBUGINFO_FILES),1) >>>>>>> 278 ifeq ($(OSNAME), windows) >>>>>>> 279 $(RM) -f $(EXPORT_SERVER_DIR)/jvm.map >>>>>>> $(EXPORT_SERVER_DIR)/jvm.pdb >>>>>>> 280 else >>>>>>> 281 $(RM) -f $(EXPORT_SERVER_DIR)/libjvm.debuginfo >>>>>>> 282 endif >>>>>>> >>>>>>> On MacOS X, the debuginfo will be in libjvm.dylib.dSYM so >>>>>>> you'll need a MacOS X specific rule. You don't need an >>>>>>> update for the JVM_VARIANT_CLIENT version because MacOS X >>>>>>> doesn't support the Client VM, but if it did... >>>>>> >>>>>> Thanks for catching this! I've uploaded a new webrev at: >>>>>> http://cr.openjdk.java.net/~ehelin/8033580/webrev.01/ >>>>>> >>>>>> The same testing was done as for the first patch. >>>>>> >>>>>> On 02/13/2014 12:40 AM, Daniel D. Daugherty wrote: >>>>>>> So the above change handles libjvm, but what about the >>>>>>> other libraries exported by HotSpot? libjsig, libjvm_db, >>>>>>> and libjvm_dtrace come to mind... >>>>>> >>>>>> As we discussed, I would like to implement this for libjvm first and >>>>>> then take care of the other libraries in a separate patch. >>>>>> >>>>>> Thanks, >>>>>> Erik >>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> On 2/12/14 8:03 AM, Erik Helin wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> this patch changes how old debug information copied from >>>>>>>> IMPORT_JDK is >>>>>>>> treated. >>>>>>>> >>>>>>>> When running the copy_*_jdk target, HotSpot's makefiles copies the >>>>>>>> entire IMPORT_JDK folder, including additional files (such as >>>>>>>> unzipped >>>>>>>> debug information). The export_*_jdk targets will then, via the >>>>>>>> generic_export target, copy the build artifacts via implicit >>>>>>>> rules to >>>>>>>> the correct destination in hotspot/build/JDK_IMAGE_DIR. >>>>>>>> >>>>>>>> The bug arises when IMPORT_JDK contains unzipped debug info >>>>>>>> (libjvm.debuginfo) and the make target produces zipped debug info >>>>>>>> (libjvm.diz), or vice versa. hotspot/build/JDK_IMAGE_DIR will then >>>>>>>> contain both libjvm.debuginfo and libjvm.diz, but only one of them >>>>>>>> will match libjvm.so. >>>>>>>> >>>>>>>> Finally, the JPRT make targets jprt_build_* just zips >>>>>>>> hotspot/build/$(JDK_IMAGE_DIR). The zipped JPRT bundle will end up >>>>>>>> having different zipped and unzipped debug info, since the >>>>>>>> IMPORT_JDK >>>>>>>> in JPRT contains libjvm.debuginfo and we build libjvm.diz by >>>>>>>> default. >>>>>>>> >>>>>>>> This patch removes the debug info that we did *not* build. If we >>>>>>>> build >>>>>>>> libjvm.diz, then libjvm.debuginfo will be removed (if it exists). >>>>>>>> Correspondingly, if we build libjvm.debuginfo, then libjvm.diz >>>>>>>> will be >>>>>>>> removed (if it exists). >>>>>>>> >>>>>>>> Patch: >>>>>>>> http://cr.openjdk.java.net/~ehelin/8033580/webrev.00/ >>>>>>>> >>>>>>>> Bug: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8033580 >>>>>>>> >>>>>>>> Testing: >>>>>>>> - Building in JPRT >>>>>>>> - Building Linux 32-bit locally on a Linux 64-bit machine >>>>>>>> - Building Linux 64-bit locally on a Linux 64-bit machine >>>>>>>> >>>>>>>> For all of the above, verify that only the correct debug info is >>>>>>>> present in the output. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Erik >>>>>>> >>>>> >>> >> From vladimir.kozlov at oracle.com Tue Mar 25 19:41:41 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 25 Mar 2014 12:41:41 -0700 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <53315B54.3050005@oracle.com> References: <5326DE2F.6000107@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> <532BA650.7000402@oracle.com> <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> <532FA869.7030209@oracle.com> <53315B54.3050005@oracle.com> Message-ID: <5331DBF5.1000501@oracle.com> I will push changes from webrev.05 into hs-comp/hotspot Where I should push jdk changes (jdk9/dev/ or hs-comp)?: http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.01/ Thanks, Vladimir On 3/25/14 3:32 AM, David Holmes wrote: > Thanks. Build side looks fine to me. > > David > > On 25/03/2014 6:09 AM, Alexander Smundak wrote: >> Done. Uploaded >> http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.05 >> >> On Sun, Mar 23, 2014 at 8:37 PM, David Holmes >> wrote: >>> On 22/03/2014 10:47 AM, Alexander Smundak wrote: >>>> >>>> On Fri, Mar 21, 2014 at 2:55 PM, Lindenmaier, Goetz >>>> wrote: >>>>> >>>>> My build ran into the 'little' case below, as I understand because >>>>> ' big' >>>>> was compared >>>>> with 'big'. Make is strange ... >>>> >>>> >>>> Removed the spaces, please take a look at >>>> http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.04 >>> >>> >>> Stylistically the hotspot makefiles test a variable/expression against a >>> value/constant not the other way around. So: >>> >>> ifeq (undefined,$(origin OPENJDK_TARGET_CPU_ENDIAN)) >>> >>> becomes >>> >>> ifeq ($(origin OPENJDK_TARGET_CPU_ENDIAN),undefined) >>> >>> and the same for all the other comparisons you have added. >>> >>> >>> Sorry. >>> >>> David >>> From vladimir.kozlov at oracle.com Tue Mar 25 23:18:27 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 25 Mar 2014 16:18:27 -0700 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <5331DBF5.1000501@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> <532BA650.7000402@oracle.com> <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> <532FA869.7030209@oracle.com> <53315B54.3050005@oracle.com> <5331DBF5.1000501@oracle.com> Message-ID: <53320EC3.8070607@oracle.com> I assume jdk changes are reviewed by Magnus. Please, confirm. Changes require a regeneration of generated-configure.sh files. I am going to push jdk(top) changes into jdk9/hs-comp and will ask gatekeepers to push it up later. JDK control build testing is running in JPRT now. Thanks, Vladimir On 3/25/14 12:41 PM, Vladimir Kozlov wrote: > I will push changes from webrev.05 into hs-comp/hotspot > > Where I should push jdk changes (jdk9/dev/ or hs-comp)?: > > http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.01/ > > Thanks, > Vladimir > > On 3/25/14 3:32 AM, David Holmes wrote: >> Thanks. Build side looks fine to me. >> >> David >> >> On 25/03/2014 6:09 AM, Alexander Smundak wrote: >>> Done. Uploaded >>> http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.05 >>> >>> On Sun, Mar 23, 2014 at 8:37 PM, David Holmes >>> wrote: >>>> On 22/03/2014 10:47 AM, Alexander Smundak wrote: >>>>> >>>>> On Fri, Mar 21, 2014 at 2:55 PM, Lindenmaier, Goetz >>>>> wrote: >>>>>> >>>>>> My build ran into the 'little' case below, as I understand because >>>>>> ' big' >>>>>> was compared >>>>>> with 'big'. Make is strange ... >>>>> >>>>> >>>>> Removed the spaces, please take a look at >>>>> http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.04 >>>> >>>> >>>> Stylistically the hotspot makefiles test a variable/expression >>>> against a >>>> value/constant not the other way around. So: >>>> >>>> ifeq (undefined,$(origin OPENJDK_TARGET_CPU_ENDIAN)) >>>> >>>> becomes >>>> >>>> ifeq ($(origin OPENJDK_TARGET_CPU_ENDIAN),undefined) >>>> >>>> and the same for all the other comparisons you have added. >>>> >>>> >>>> Sorry. >>>> >>>> David >>>> From asmundak at google.com Tue Mar 25 23:57:43 2014 From: asmundak at google.com (Alexander Smundak) Date: Tue, 25 Mar 2014 16:57:43 -0700 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <53320EC3.8070607@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEA859D@DEWDFEMB12A.global.corp.sap> <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> <532BA650.7000402@oracle.com> <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> <532FA869.7030209@oracle.com> <53315B54.3050005@oracle.com> <5331DBF5.1000501@oracle.com> <53320EC3.8070607@oracle.com> Message-ID: On Tue, Mar 25, 2014 at 4:18 PM, Vladimir Kozlov wrote: > I assume jdk changes are reviewed by Magnus. Please, confirm. There are no changes to the jdk/ repository -- the webrev posted as http://cr.openjdk.java.net/~martin/asmundak/8036767/jdk/webrev.01 has been withdrawn. From vladimir.kozlov at oracle.com Wed Mar 26 00:00:44 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 25 Mar 2014 17:00:44 -0700 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <53320EC3.8070607@oracle.com> References: <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> <532BA650.7000402@oracle.com> <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> <532FA869.7030209@oracle.com> <53315B54.3050005@oracle.com> <5331DBF5.1000501@oracle.com> <53320EC3.8070607@oracle.com> Message-ID: <533218AC.4000108@oracle.com> I mean build changes in top directory: http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.01/ Thanks, Vladimir On 3/25/14 4:18 PM, Vladimir Kozlov wrote: > I assume jdk changes are reviewed by Magnus. Please, confirm. > > Changes require a regeneration of generated-configure.sh files. > > I am going to push jdk(top) changes into jdk9/hs-comp and will ask > gatekeepers to push it up later. > > JDK control build testing is running in JPRT now. > > Thanks, > Vladimir > > On 3/25/14 12:41 PM, Vladimir Kozlov wrote: >> I will push changes from webrev.05 into hs-comp/hotspot >> >> Where I should push jdk changes (jdk9/dev/ or hs-comp)?: >> >> http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.01/ >> >> Thanks, >> Vladimir >> >> On 3/25/14 3:32 AM, David Holmes wrote: >>> Thanks. Build side looks fine to me. >>> >>> David >>> >>> On 25/03/2014 6:09 AM, Alexander Smundak wrote: >>>> Done. Uploaded >>>> http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.05 >>>> >>>> On Sun, Mar 23, 2014 at 8:37 PM, David Holmes >>>> wrote: >>>>> On 22/03/2014 10:47 AM, Alexander Smundak wrote: >>>>>> >>>>>> On Fri, Mar 21, 2014 at 2:55 PM, Lindenmaier, Goetz >>>>>> wrote: >>>>>>> >>>>>>> My build ran into the 'little' case below, as I understand because >>>>>>> ' big' >>>>>>> was compared >>>>>>> with 'big'. Make is strange ... >>>>>> >>>>>> >>>>>> Removed the spaces, please take a look at >>>>>> http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.04 >>>>> >>>>> >>>>> Stylistically the hotspot makefiles test a variable/expression >>>>> against a >>>>> value/constant not the other way around. So: >>>>> >>>>> ifeq (undefined,$(origin OPENJDK_TARGET_CPU_ENDIAN)) >>>>> >>>>> becomes >>>>> >>>>> ifeq ($(origin OPENJDK_TARGET_CPU_ENDIAN),undefined) >>>>> >>>>> and the same for all the other comparisons you have added. >>>>> >>>>> >>>>> Sorry. >>>>> >>>>> David >>>>> From magnus.ihse.bursie at oracle.com Wed Mar 26 07:07:18 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 26 Mar 2014 08:07:18 +0100 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <533218AC.4000108@oracle.com> References: <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> <532BA650.7000402@oracle.com> <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> <532FA869.7030209@oracle.com> <53315B54.3050005@oracle.com> <5331DBF5.1000501@oracle.com> <53320EC3.8070607@oracle.com> <533218AC.4000108@oracle.com> Message-ID: <16216345-F06B-404B-90C5-EA605600D6F2@oracle.com> I have not seen it before, but that webrev contains a modification of autoconf-config.guess, which is not okay. That file is copied directly from the autoconf project and should not be modified. If that script is not working properly, a correction can be made in the config.guess wrapper. See existing code there for how it can be done. /Magnus > On 26 mar 2014, at 01:00, Vladimir Kozlov wrote: > > I mean build changes in top directory: > > http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.01/ > > Thanks, > Vladimir > >> On 3/25/14 4:18 PM, Vladimir Kozlov wrote: >> I assume jdk changes are reviewed by Magnus. Please, confirm. >> >> Changes require a regeneration of generated-configure.sh files. >> >> I am going to push jdk(top) changes into jdk9/hs-comp and will ask >> gatekeepers to push it up later. >> >> JDK control build testing is running in JPRT now. >> >> Thanks, >> Vladimir >> >>> On 3/25/14 12:41 PM, Vladimir Kozlov wrote: >>> I will push changes from webrev.05 into hs-comp/hotspot >>> >>> Where I should push jdk changes (jdk9/dev/ or hs-comp)?: >>> >>> http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.01/ >>> >>> Thanks, >>> Vladimir >>> >>>> On 3/25/14 3:32 AM, David Holmes wrote: >>>> Thanks. Build side looks fine to me. >>>> >>>> David >>>> >>>>> On 25/03/2014 6:09 AM, Alexander Smundak wrote: >>>>> Done. Uploaded >>>>> http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.05 >>>>> >>>>> On Sun, Mar 23, 2014 at 8:37 PM, David Holmes >>>>> wrote: >>>>>> On 22/03/2014 10:47 AM, Alexander Smundak wrote: >>>>>>> >>>>>>> On Fri, Mar 21, 2014 at 2:55 PM, Lindenmaier, Goetz >>>>>>> wrote: >>>>>>>> >>>>>>>> My build ran into the 'little' case below, as I understand because >>>>>>>> ' big' >>>>>>>> was compared >>>>>>>> with 'big'. Make is strange ... >>>>>>> >>>>>>> >>>>>>> Removed the spaces, please take a look at >>>>>>> http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.04 >>>>>> >>>>>> >>>>>> Stylistically the hotspot makefiles test a variable/expression >>>>>> against a >>>>>> value/constant not the other way around. So: >>>>>> >>>>>> ifeq (undefined,$(origin OPENJDK_TARGET_CPU_ENDIAN)) >>>>>> >>>>>> becomes >>>>>> >>>>>> ifeq ($(origin OPENJDK_TARGET_CPU_ENDIAN),undefined) >>>>>> >>>>>> and the same for all the other comparisons you have added. >>>>>> >>>>>> >>>>>> Sorry. >>>>>> >>>>>> David >>>>>> From volker.simonis at gmail.com Wed Mar 26 09:21:08 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 26 Mar 2014 10:21:08 +0100 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <16216345-F06B-404B-90C5-EA605600D6F2@oracle.com> References: <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> <532BA650.7000402@oracle.com> <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> <532FA869.7030209@oracle.com> <53315B54.3050005@oracle.com> <5331DBF5.1000501@oracle.com> <53320EC3.8070607@oracle.com> <533218AC.4000108@oracle.com> <16216345-F06B-404B-90C5-EA605600D6F2@oracle.com> Message-ID: On Wed, Mar 26, 2014 at 8:07 AM, Magnus Ihse Bursie wrote: > I have not seen it before, but that webrev contains a modification of autoconf-config.guess, which is not okay. That file is copied directly from the autoconf project and should not be modified. > > If that script is not working properly, a correction can be made in the config.guess wrapper. See existing code there for how it can be done. > We could do that, but I think that would be an ugly hack. I'm not sure what the current autoconf-config.guess actually returns for ppc64le-linux, but from a quick hack (i.e. changing uname to return 'ppc64le' if given the '-m' option) I can see that it returns an emtpy string and writes an error text to stderr: ========================================================== common/autoconf/build-aux/config.guess: unable to guess system type This script, last modified 2012-02-10, has failed to recognize the operating system you are using. It is advised that you download the most up to date version of the config scripts from http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD and http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD If the version you run (common/autoconf/build-aux/config.guess) is already up to date, please send the following data and any information you think might be pertinent to in order to provide the needed information to handle your system. config.guess timestamp = 2012-02-10 uname -m = ppc64le uname -r = 3.2.0-60-generic uname -s = Linux uname -v = #91-Ubuntu SMP Wed Feb 19 03:54:44 UTC 2014 /usr/bin/uname -p = /bin/uname -X = hostinfo = /bin/universe = /usr/bin/arch -k = /bin/arch = /usr/bin/oslevel = /usr/convex/getsysinfo = UNAME_MACHINE = ppc64le UNAME_RELEASE = 3.2.0-60-generic UNAME_SYSTEM = Linux UNAME_VERSION = #91-Ubuntu SMP Wed Feb 19 03:54:44 UTC 2014 ================================================================== We could of course handle that, but I think it would be a bad idea to treat every unrecognized system as 'ppc64le'. I've checked that the latest config.guess (from http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD) does indeed recognize ppc64le. So I'd suggest we just check in this new version for the current common/autoconf/build-aux/config.guess. It is by far the cleanest solution and it shouldn't do any harm for the few platforms we support (and it additionally can detect mingw-64 which may be interesting for our MinGW experiments). What do you think? Regards, Volker > /Magnus > >> On 26 mar 2014, at 01:00, Vladimir Kozlov wrote: >> >> I mean build changes in top directory: >> >> http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.01/ >> >> Thanks, >> Vladimir >> >>> On 3/25/14 4:18 PM, Vladimir Kozlov wrote: >>> I assume jdk changes are reviewed by Magnus. Please, confirm. >>> >>> Changes require a regeneration of generated-configure.sh files. >>> >>> I am going to push jdk(top) changes into jdk9/hs-comp and will ask >>> gatekeepers to push it up later. >>> >>> JDK control build testing is running in JPRT now. >>> >>> Thanks, >>> Vladimir >>> >>>> On 3/25/14 12:41 PM, Vladimir Kozlov wrote: >>>> I will push changes from webrev.05 into hs-comp/hotspot >>>> >>>> Where I should push jdk changes (jdk9/dev/ or hs-comp)?: >>>> >>>> http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.01/ >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> On 3/25/14 3:32 AM, David Holmes wrote: >>>>> Thanks. Build side looks fine to me. >>>>> >>>>> David >>>>> >>>>>> On 25/03/2014 6:09 AM, Alexander Smundak wrote: >>>>>> Done. Uploaded >>>>>> http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.05 >>>>>> >>>>>> On Sun, Mar 23, 2014 at 8:37 PM, David Holmes >>>>>> wrote: >>>>>>> On 22/03/2014 10:47 AM, Alexander Smundak wrote: >>>>>>>> >>>>>>>> On Fri, Mar 21, 2014 at 2:55 PM, Lindenmaier, Goetz >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> My build ran into the 'little' case below, as I understand because >>>>>>>>> ' big' >>>>>>>>> was compared >>>>>>>>> with 'big'. Make is strange ... >>>>>>>> >>>>>>>> >>>>>>>> Removed the spaces, please take a look at >>>>>>>> http://cr.openjdk.java.net/~martin/asmundak/8036767/hotspot/webrev.04 >>>>>>> >>>>>>> >>>>>>> Stylistically the hotspot makefiles test a variable/expression >>>>>>> against a >>>>>>> value/constant not the other way around. So: >>>>>>> >>>>>>> ifeq (undefined,$(origin OPENJDK_TARGET_CPU_ENDIAN)) >>>>>>> >>>>>>> becomes >>>>>>> >>>>>>> ifeq ($(origin OPENJDK_TARGET_CPU_ENDIAN),undefined) >>>>>>> >>>>>>> and the same for all the other comparisons you have added. >>>>>>> >>>>>>> >>>>>>> Sorry. >>>>>>> >>>>>>> David >>>>>>> From erik.joelsson at oracle.com Wed Mar 26 10:32:35 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 26 Mar 2014 11:32:35 +0100 Subject: RFR: JDK-8038340: Cleanup and fix sysroot and devkit handling on Linux and Solaris Message-ID: <5332ACC3.6080109@oracle.com> Hello, (including 2d-dev/awt-dev because I'm changing linker flags on desktop libs.) In preparation for upgrading compilers and build platforms, we would like to get better separation between the two. At least on Linux and Solaris this is certainly possible. Some work for this was already done in Jdk 8 but it was never taken all the way through into actual usage. In this bug, the configure parameters relating to this will be changed to: --with-sysroot: Sets a sysroot directory that will be propagated to the compiler (gcc --sysroot) if supported and which will be used by configure to look for all dependencies like headers and libraries. (old --with-sys-root will be kept for compatibility as an alias) --with-toolchain-path: Prepends to the path when looking for compilers and other target specific tools. Replaces --with-tools-dir, which will also be kept for compatibility as an alias. --with-extra-path: Prepends to the path when looking for everything. --with-devkit: Points to the root of a devkit. A devkit may have a "devkit.info" in its root detailing values for the above three parameters. If not, the fallback behavior is what it used to do. (set toolchain_path to devkit/bin and some options for subdirs for sysroot) Along with these changes some more was needed and done: * To get it to work properly on Solaris, the OPENWIN variables were removed and replaced with X_LIBS and X_CFLAGS. Several unnecessary runtime paths for awt* libs were removed and some were added where they were actually needed instead. All the libs have been verified to still find their dependencies with ldd. * The devkit generation makefiles for linux (in root/make/devkit) were updated to the proposed compiler versions and adding the devkit.info file. * A minor fix in compare.sh that was missed in an earlier patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8038340 Webrevs: http://cr.openjdk.java.net/~erikj/8038340/webrev.root.01/ http://cr.openjdk.java.net/~erikj/8038340/webrev.jdk.01/ /Erik From magnus.ihse.bursie at oracle.com Wed Mar 26 11:14:15 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 26 Mar 2014 12:14:15 +0100 Subject: RFR: JDK-8038340: Cleanup and fix sysroot and devkit handling on Linux and Solaris In-Reply-To: <5332ACC3.6080109@oracle.com> References: <5332ACC3.6080109@oracle.com> Message-ID: <5332B687.40402@oracle.com> That's a lot of good changes! :-) Some comments: In basics.m4: * The description of --with-devkit is not ideal. It does more than sets sysroot and toolchain path (e.g. the extra path, and perhaps more things to come). Maybe just some more vague description like "use this devkit for compilers, tools and resources"? * The comment "If a separate sysroot has not been defined, use the one in the devkit" does not really match what's happening anymore. Overriding of SYSROOT happens outside that block. A more suitable comment would be something about what we do if DEVKIT_SYSROOT is not set. In toolchain.m4: * There is some logic trying to avoid setting /usr/ccs/bin to the PATH on Solaris if the toolchain path is set. But since toolchain path will be prepended just below, we don't need that precaution, and we can just set it always. Apart from that, it looks great! /Magnus On 2014-03-26 11:32, Erik Joelsson wrote: > Hello, > > (including 2d-dev/awt-dev because I'm changing linker flags on desktop > libs.) > > In preparation for upgrading compilers and build platforms, we would > like to get better separation between the two. At least on Linux and > Solaris this is certainly possible. Some work for this was already > done in Jdk 8 but it was never taken all the way through into actual > usage. > > In this bug, the configure parameters relating to this will be changed > to: > > --with-sysroot: Sets a sysroot directory that will be propagated to > the compiler (gcc --sysroot) if supported and which will be used by > configure to look for all dependencies like headers and libraries. > (old --with-sys-root will be kept for compatibility as an alias) > > --with-toolchain-path: Prepends to the path when looking for compilers > and other target specific tools. Replaces --with-tools-dir, which will > also be kept for compatibility as an alias. > > --with-extra-path: Prepends to the path when looking for everything. > > --with-devkit: Points to the root of a devkit. A devkit may have a > "devkit.info" in its root detailing values for the above three > parameters. If not, the fallback behavior is what it used to do. (set > toolchain_path to devkit/bin and some options for subdirs for sysroot) > > > Along with these changes some more was needed and done: > > * To get it to work properly on Solaris, the OPENWIN variables were > removed and replaced with X_LIBS and X_CFLAGS. Several unnecessary > runtime paths for awt* libs were removed and some were added where > they were actually needed instead. All the libs have been verified to > still find their dependencies with ldd. > > * The devkit generation makefiles for linux (in root/make/devkit) were > updated to the proposed compiler versions and adding the devkit.info > file. > > * A minor fix in compare.sh that was missed in an earlier patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8038340 > Webrevs: > http://cr.openjdk.java.net/~erikj/8038340/webrev.root.01/ > http://cr.openjdk.java.net/~erikj/8038340/webrev.jdk.01/ > > /Erik From erik.joelsson at oracle.com Wed Mar 26 11:32:03 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 26 Mar 2014 12:32:03 +0100 Subject: RFR: JDK-8038340: Cleanup and fix sysroot and devkit handling on Linux and Solaris In-Reply-To: <5332B687.40402@oracle.com> References: <5332ACC3.6080109@oracle.com> <5332B687.40402@oracle.com> Message-ID: <5332BAB3.6020505@oracle.com> Thanks, here is a new webrev: http://cr.openjdk.java.net/~erikj/8038340/webrev.root.02/ /Erik On 2014-03-26 12:14, Magnus Ihse Bursie wrote: > That's a lot of good changes! :-) > > Some comments: > > In basics.m4: > * The description of --with-devkit is not ideal. It does more than > sets sysroot and toolchain path (e.g. the extra path, and perhaps more > things to come). Maybe just some more vague description like "use this > devkit for compilers, tools and resources"? > * The comment "If a separate sysroot has not been defined, use the one > in the devkit" does not really match what's happening anymore. > Overriding of SYSROOT happens outside that block. A more suitable > comment would be something about what we do if DEVKIT_SYSROOT is not set. > > In toolchain.m4: > * There is some logic trying to avoid setting /usr/ccs/bin to the PATH > on Solaris if the toolchain path is set. But since toolchain path will > be prepended just below, we don't need that precaution, and we can > just set it always. > > Apart from that, it looks great! > > /Magnus > > On 2014-03-26 11:32, Erik Joelsson wrote: >> Hello, >> >> (including 2d-dev/awt-dev because I'm changing linker flags on >> desktop libs.) >> >> In preparation for upgrading compilers and build platforms, we would >> like to get better separation between the two. At least on Linux and >> Solaris this is certainly possible. Some work for this was already >> done in Jdk 8 but it was never taken all the way through into actual >> usage. >> >> In this bug, the configure parameters relating to this will be >> changed to: >> >> --with-sysroot: Sets a sysroot directory that will be propagated to >> the compiler (gcc --sysroot) if supported and which will be used by >> configure to look for all dependencies like headers and libraries. >> (old --with-sys-root will be kept for compatibility as an alias) >> >> --with-toolchain-path: Prepends to the path when looking for >> compilers and other target specific tools. Replaces --with-tools-dir, >> which will also be kept for compatibility as an alias. >> >> --with-extra-path: Prepends to the path when looking for everything. >> >> --with-devkit: Points to the root of a devkit. A devkit may have a >> "devkit.info" in its root detailing values for the above three >> parameters. If not, the fallback behavior is what it used to do. (set >> toolchain_path to devkit/bin and some options for subdirs for sysroot) >> >> >> Along with these changes some more was needed and done: >> >> * To get it to work properly on Solaris, the OPENWIN variables were >> removed and replaced with X_LIBS and X_CFLAGS. Several unnecessary >> runtime paths for awt* libs were removed and some were added where >> they were actually needed instead. All the libs have been verified to >> still find their dependencies with ldd. >> >> * The devkit generation makefiles for linux (in root/make/devkit) >> were updated to the proposed compiler versions and adding the >> devkit.info file. >> >> * A minor fix in compare.sh that was missed in an earlier patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8038340 >> Webrevs: >> http://cr.openjdk.java.net/~erikj/8038340/webrev.root.01/ >> http://cr.openjdk.java.net/~erikj/8038340/webrev.jdk.01/ >> >> /Erik > From magnus.ihse.bursie at oracle.com Wed Mar 26 11:36:25 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 26 Mar 2014 12:36:25 +0100 Subject: RFR: JDK-8038340: Cleanup and fix sysroot and devkit handling on Linux and Solaris In-Reply-To: <5332BAB3.6020505@oracle.com> References: <5332ACC3.6080109@oracle.com> <5332B687.40402@oracle.com> <5332BAB3.6020505@oracle.com> Message-ID: <5332BBB9.1040302@oracle.com> On 2014-03-26 12:32, Erik Joelsson wrote: > Thanks, here is a new webrev: > > http://cr.openjdk.java.net/~erikj/8038340/webrev.root.02/ Looks good to me. /Magnus From david.holmes at oracle.com Wed Mar 26 11:51:12 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Mar 2014 21:51:12 +1000 Subject: RFR: JDK-8038340: Cleanup and fix sysroot and devkit handling on Linux and Solaris In-Reply-To: <5332ACC3.6080109@oracle.com> References: <5332ACC3.6080109@oracle.com> Message-ID: <5332BF30.7080903@oracle.com> sysroots and tool-chains and dev-kits! oh my! Seriously, what does all this mean for someone who just wants to build the OpenJDK? I use dev-kit for cross-compilation builds but I have no idea what these different things are supposed to represent. David On 26/03/2014 8:32 PM, Erik Joelsson wrote: > Hello, > > (including 2d-dev/awt-dev because I'm changing linker flags on desktop > libs.) > > In preparation for upgrading compilers and build platforms, we would > like to get better separation between the two. At least on Linux and > Solaris this is certainly possible. Some work for this was already done > in Jdk 8 but it was never taken all the way through into actual usage. > > In this bug, the configure parameters relating to this will be changed to: > > --with-sysroot: Sets a sysroot directory that will be propagated to the > compiler (gcc --sysroot) if supported and which will be used by > configure to look for all dependencies like headers and libraries. (old > --with-sys-root will be kept for compatibility as an alias) > > --with-toolchain-path: Prepends to the path when looking for compilers > and other target specific tools. Replaces --with-tools-dir, which will > also be kept for compatibility as an alias. > > --with-extra-path: Prepends to the path when looking for everything. > > --with-devkit: Points to the root of a devkit. A devkit may have a > "devkit.info" in its root detailing values for the above three > parameters. If not, the fallback behavior is what it used to do. (set > toolchain_path to devkit/bin and some options for subdirs for sysroot) > > > Along with these changes some more was needed and done: > > * To get it to work properly on Solaris, the OPENWIN variables were > removed and replaced with X_LIBS and X_CFLAGS. Several unnecessary > runtime paths for awt* libs were removed and some were added where they > were actually needed instead. All the libs have been verified to still > find their dependencies with ldd. > > * The devkit generation makefiles for linux (in root/make/devkit) were > updated to the proposed compiler versions and adding the devkit.info file. > > * A minor fix in compare.sh that was missed in an earlier patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8038340 > Webrevs: > http://cr.openjdk.java.net/~erikj/8038340/webrev.root.01/ > http://cr.openjdk.java.net/~erikj/8038340/webrev.jdk.01/ > > /Erik From magnus.ihse.bursie at oracle.com Wed Mar 26 11:57:42 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 26 Mar 2014 12:57:42 +0100 Subject: RFR: JDK-8038340: Cleanup and fix sysroot and devkit handling on Linux and Solaris In-Reply-To: <5332BF30.7080903@oracle.com> References: <5332ACC3.6080109@oracle.com> <5332BF30.7080903@oracle.com> Message-ID: <5332C0B6.5020804@oracle.com> On 2014-03-26 12:51, David Holmes wrote: > sysroots and tool-chains and dev-kits! oh my! > > Seriously, what does all this mean for someone who just wants to build > the OpenJDK? I use dev-kit for cross-compilation builds but I have no > idea what these different things are supposed to represent. You can continue to use --with-devkit as you had. That was one of the design goals for this change. The theory is something like this: * A "sysroot" is a stripped-down root directory of the *target* platform, containing include files and libraries needed to compile and link for a target (possibly cross-) platform. * The toolchain path is one or more directories that contains binaries that will run on the build platform, but generate code for the target platform. While the separation is somewhat fuzzy, we use the toolchain path for "toolchain" binaries, basically, those that compile, link or otherwise interact with the target platform binaries. * The extra path is one or more directories that contain any kind of binaries, e.g. a proper version of zip or grep. If you do not deal with cross-platform devkits, there is no real difference between extra path and toolchain path. And that is what is needed to encapsulate the tools needed to compile OpenJDK. /Magnus > > David > > On 26/03/2014 8:32 PM, Erik Joelsson wrote: >> Hello, >> >> (including 2d-dev/awt-dev because I'm changing linker flags on desktop >> libs.) >> >> In preparation for upgrading compilers and build platforms, we would >> like to get better separation between the two. At least on Linux and >> Solaris this is certainly possible. Some work for this was already done >> in Jdk 8 but it was never taken all the way through into actual usage. >> >> In this bug, the configure parameters relating to this will be >> changed to: >> >> --with-sysroot: Sets a sysroot directory that will be propagated to the >> compiler (gcc --sysroot) if supported and which will be used by >> configure to look for all dependencies like headers and libraries. (old >> --with-sys-root will be kept for compatibility as an alias) >> >> --with-toolchain-path: Prepends to the path when looking for compilers >> and other target specific tools. Replaces --with-tools-dir, which will >> also be kept for compatibility as an alias. >> >> --with-extra-path: Prepends to the path when looking for everything. >> >> --with-devkit: Points to the root of a devkit. A devkit may have a >> "devkit.info" in its root detailing values for the above three >> parameters. If not, the fallback behavior is what it used to do. (set >> toolchain_path to devkit/bin and some options for subdirs for sysroot) >> >> >> Along with these changes some more was needed and done: >> >> * To get it to work properly on Solaris, the OPENWIN variables were >> removed and replaced with X_LIBS and X_CFLAGS. Several unnecessary >> runtime paths for awt* libs were removed and some were added where they >> were actually needed instead. All the libs have been verified to still >> find their dependencies with ldd. >> >> * The devkit generation makefiles for linux (in root/make/devkit) were >> updated to the proposed compiler versions and adding the devkit.info >> file. >> >> * A minor fix in compare.sh that was missed in an earlier patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8038340 >> Webrevs: >> http://cr.openjdk.java.net/~erikj/8038340/webrev.root.01/ >> http://cr.openjdk.java.net/~erikj/8038340/webrev.jdk.01/ >> >> /Erik From gnu.andrew at redhat.com Wed Mar 26 13:09:21 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 26 Mar 2014 09:09:21 -0400 (EDT) Subject: [OpenJDK 2D-Dev] RFR: Allow using a system-installed lcms2 In-Reply-To: <532FFEFD.6080607@oracle.com> References: <20140220224044.GB20217@redhat.com> <5329C8F4.1080302@oracle.com> <20140319232544.GB3167@redhat.com> <1825429909.979300.1395422740031.JavaMail.zimbra@redhat.com> <20140321172752.GF6449@redhat.com> <532CD39C.6070203@oracle.com> <20140322191133.GB3192@redhat.com> <532FFEFD.6080607@oracle.com> Message-ID: <1607570978.914282.1395839361690.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 2014-03-22 20:11, Omair Majid wrote: > > > Thanks. I wasn't sure how an empty value might be processed. > Make can't really see the difference between an unassigned variable and > one assigned to nothing. (Or, it can, but it's more tricky to check). In > all the SetupFoo macros, assigning an empty value or leaving unassigned > is the same thing. > > > > Updated webrev: > > http://cr.openjdk.java.net/~omajid/webrevs/system-lcms/02/ > > http://cr.openjdk.java.net/~omajid/webrevs/system-lcms/02-jdk/ > Looks good to me. I hope this version can be acceptable to all parties. > Thank you for continuing tweaking this patch to all requirements that > has crept up. > > /Magnus > Looks a lot clearer. Thanks. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From mike.duigou at oracle.com Wed Mar 26 21:11:10 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 26 Mar 2014 14:11:10 -0700 Subject: RFR : 8038435 : Some hgforest.sh commands don't receive parameters Message-ID: Hello all; I introduced bug in JDK-8030681 which prevents non-clone commands from receiving parameters. I also slightly cleaned up checking for what is an acceptable root repo as I had encountered this in a problem with a local clone and reverted prior change which made the script a bash script. bug: https://bugs.openjdk.java.net/browse/JDK-8038435 webrev: http://cr.openjdk.java.net/~mduigou/JDK-8038435/0/webrev/ Thanks, Mike From david.katleman at oracle.com Wed Mar 26 21:52:23 2014 From: david.katleman at oracle.com (David Katleman) Date: Wed, 26 Mar 2014 14:52:23 -0700 Subject: RFR : 8038435 : Some hgforest.sh commands don't receive parameters In-Reply-To: References: Message-ID: <53334C17.6030902@oracle.com> Hi Mike, A few minor comments, overall looks good. On 3/26/2014 2:11 PM, Mike Duigou wrote: > Hello all; > > I introduced bug in JDK-8030681 which prevents non-clone commands from receiving parameters. > > I also slightly cleaned up checking for what is an acceptable root repo as I had encountered this in a problem with a local clone and reverted prior change which made the script a bash script. > > bug: https://bugs.openjdk.java.net/browse/JDK-8038435 > > webrev: http://cr.openjdk.java.net/~mduigou/JDK-8038435/0/webrev/ > 116 if [ "${command}" = "clone" -o "${command}" = "fclone" ] ; then > 221 if [ "${command}" = "clone" -o "${command}" = "fclone" ] ; then Perhaps out of scope of this fix, but shouldn't we add -o "${command}" = "tclone"? The "fclone" & "tclone" are both cosmetic, neither extensions are used. Can't remove "fclone" without potentionally breaking scripts. > 127 pull_default_tail=`echo ${pull_default} | sed -e 's@^.*://[^/]*/\(.*\)@\1@'` > 128 if [ "x${pull_default}" = "x${pull_default_tail}" ] ; then > 129 echo "ERROR: Need initial clone from non-local source" > ${status_output} > 130 exit 1 > 131 fi The above code looks right for what you want to do, but is it necessary to restrict hgforest.sh to only operate vs non-local? Seems one should still be able to have their own forest, and clone from that forest locally. > 238 echo "cd ${i} && hg${global_opts} ${command} ${command_args}" > ${status_output} > 239 cd ${i} && (PYTHONUNBUFFERED=true hg${global_opts} ${command} ${command_args}; echo "$?" > ${tmp}/${repopidfile}.pid.rc ) 2>&1 & Add "PYTHONUNBUFFERED=true" to the echo line. Thanks Dave From mike.duigou at oracle.com Wed Mar 26 22:15:21 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 26 Mar 2014 15:15:21 -0700 Subject: RFR : 8038435 : Some hgforest.sh commands don't receive parameters In-Reply-To: <53334C17.6030902@oracle.com> References: <53334C17.6030902@oracle.com> Message-ID: <13E28882-3028-4E81-A308-FE102FF27410@oracle.com> On Mar 26 2014, at 14:52 , David Katleman wrote: > Hi Mike, > > A few minor comments, overall looks good. > > On 3/26/2014 2:11 PM, Mike Duigou wrote: >> Hello all; >> >> I introduced bug in JDK-8030681 which prevents non-clone commands from receiving parameters. >> >> I also slightly cleaned up checking for what is an acceptable root repo as I had encountered this in a problem with a local clone and reverted prior change which made the script a bash script. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8038435 >> >> webrev: http://cr.openjdk.java.net/~mduigou/JDK-8038435/0/webrev/ > >> 116 if [ "${command}" = "clone" -o "${command}" = "fclone" ] ; then >> 221 if [ "${command}" = "clone" -o "${command}" = "fclone" ] ; then > > Perhaps out of scope of this fix, but shouldn't we add -o "${command}" = "tclone"? > The "fclone" & "tclone" are both cosmetic, neither extensions are used. > Can't remove "fclone" without potentionally breaking scripts. I can easily add the tclone. > >> 127 pull_default_tail=`echo ${pull_default} | sed -e 's@^.*://[^/]*/\(.*\)@\1@'` >> 128 if [ "x${pull_default}" = "x${pull_default_tail}" ] ; then >> 129 echo "ERROR: Need initial clone from non-local source" > ${status_output} >> 130 exit 1 >> 131 fi > > The above code looks right for what you want to do, but is it necessary to restrict hgforest.sh to only operate vs non-local? The problem is that the default path is used to figure out the peer name in the extra (closed) repo. It's not possible to do this from a local path unless you make assumptions or we change the requirements for the extra path to include the appropriate root repo. > > Seems one should still be able to have their own forest, and clone from that forest locally. > >> 238 echo "cd ${i} && hg${global_opts} ${command} ${command_args}" > ${status_output} >> 239 cd ${i} && (PYTHONUNBUFFERED=true hg${global_opts} ${command} ${command_args}; echo "$?" > ${tmp}/${repopidfile}.pid.rc ) 2>&1 & > > Add "PYTHONUNBUFFERED=true" to the echo line. I am not sure why this would be important. It would seem to be just clutter to me. Thanks! Mike From mike.duigou at oracle.com Wed Mar 26 22:39:57 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 26 Mar 2014 15:39:57 -0700 Subject: RFR : 8038435 : Some hgforest.sh commands don't receive parameters In-Reply-To: <13E28882-3028-4E81-A308-FE102FF27410@oracle.com> References: <53334C17.6030902@oracle.com> <13E28882-3028-4E81-A308-FE102FF27410@oracle.com> Message-ID: I have updated the webrev to add the tclone. I also moved the initial clone from non-local source to only the closed repo case. The check isn't necessary for the case where all sub-repos will be relative to the root repo and not in a separate forest. http://cr.openjdk.java.net/~mduigou/JDK-8038435/1/webrev/ Mike On Mar 26 2014, at 15:15 , Mike Duigou wrote: > > On Mar 26 2014, at 14:52 , David Katleman wrote: > >> Hi Mike, >> >> A few minor comments, overall looks good. >> >> On 3/26/2014 2:11 PM, Mike Duigou wrote: >>> Hello all; >>> >>> I introduced bug in JDK-8030681 which prevents non-clone commands from receiving parameters. >>> >>> I also slightly cleaned up checking for what is an acceptable root repo as I had encountered this in a problem with a local clone and reverted prior change which made the script a bash script. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8038435 >>> >>> webrev: http://cr.openjdk.java.net/~mduigou/JDK-8038435/0/webrev/ >> >>> 116 if [ "${command}" = "clone" -o "${command}" = "fclone" ] ; then >>> 221 if [ "${command}" = "clone" -o "${command}" = "fclone" ] ; then >> >> Perhaps out of scope of this fix, but shouldn't we add -o "${command}" = "tclone"? >> The "fclone" & "tclone" are both cosmetic, neither extensions are used. >> Can't remove "fclone" without potentionally breaking scripts. > > I can easily add the tclone. >> >>> 127 pull_default_tail=`echo ${pull_default} | sed -e 's@^.*://[^/]*/\(.*\)@\1@'` >>> 128 if [ "x${pull_default}" = "x${pull_default_tail}" ] ; then >>> 129 echo "ERROR: Need initial clone from non-local source" > ${status_output} >>> 130 exit 1 >>> 131 fi >> >> The above code looks right for what you want to do, but is it necessary to restrict hgforest.sh to only operate vs non-local? > > The problem is that the default path is used to figure out the peer name in the extra (closed) repo. It's not possible to do this from a local path unless you make assumptions or we change the requirements for the extra path to include the appropriate root repo. > >> >> Seems one should still be able to have their own forest, and clone from that forest locally. >> >>> 238 echo "cd ${i} && hg${global_opts} ${command} ${command_args}" > ${status_output} >>> 239 cd ${i} && (PYTHONUNBUFFERED=true hg${global_opts} ${command} ${command_args}; echo "$?" > ${tmp}/${repopidfile}.pid.rc ) 2>&1 & >> >> Add "PYTHONUNBUFFERED=true" to the echo line. > > I am not sure why this would be important. It would seem to be just clutter to me. > > Thanks! > > Mike From asmundak at google.com Wed Mar 26 22:47:20 2014 From: asmundak at google.com (Alexander Smundak) Date: Wed, 26 Mar 2014 15:47:20 -0700 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: References: <5327A2E6.5060100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA8CD4@DEWDFEMB12A.global.corp.sap> <53282020.5040302@oracle.com> <532BA650.7000402@oracle.com> <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> <532FA869.7030209@oracle.com> <53315B54.3050005@oracle.com> <5331DBF5.1000501@oracle.com> <53320EC3.8070607@oracle.com> <533218AC.4000108@oracle.com> <16216345-F06B-404B-90C5-EA605600D6F2@oracle.com> Message-ID: On Wed, Mar 26, 2014 at 2:21 AM, Volker Simonis wrote: > So I'd suggest we just check in this new version for the current > common/autoconf/build-aux/config.guess. I agree. Magnus, would you like me to do this? From david.holmes at oracle.com Wed Mar 26 22:48:36 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Mar 2014 08:48:36 +1000 Subject: RFR: JDK-8038340: Cleanup and fix sysroot and devkit handling on Linux and Solaris In-Reply-To: <5332C0B6.5020804@oracle.com> References: <5332ACC3.6080109@oracle.com> <5332BF30.7080903@oracle.com> <5332C0B6.5020804@oracle.com> Message-ID: <53335944.4070007@oracle.com> On 26/03/2014 9:57 PM, Magnus Ihse Bursie wrote: > > On 2014-03-26 12:51, David Holmes wrote: >> sysroots and tool-chains and dev-kits! oh my! >> >> Seriously, what does all this mean for someone who just wants to build >> the OpenJDK? I use dev-kit for cross-compilation builds but I have no >> idea what these different things are supposed to represent. > > You can continue to use --with-devkit as you had. That was one of the > design goals for this change. > > The theory is something like this: > * A "sysroot" is a stripped-down root directory of the *target* > platform, containing include files and libraries needed to compile and > link for a target (possibly cross-) platform. > * The toolchain path is one or more directories that contains binaries > that will run on the build platform, but generate code for the target > platform. While the separation is somewhat fuzzy, we use the toolchain > path for "toolchain" binaries, basically, those that compile, link or > otherwise interact with the target platform binaries. > * The extra path is one or more directories that contain any kind of > binaries, e.g. a proper version of zip or grep. If you do not deal with > cross-platform devkits, there is no real difference between extra path > and toolchain path. So what then is a "dev-kit"? A combined sysroot+tool-chain? Thanks, David > And that is what is needed to encapsulate the tools needed to compile > OpenJDK. > > /Magnus > >> >> David >> >> On 26/03/2014 8:32 PM, Erik Joelsson wrote: >>> Hello, >>> >>> (including 2d-dev/awt-dev because I'm changing linker flags on desktop >>> libs.) >>> >>> In preparation for upgrading compilers and build platforms, we would >>> like to get better separation between the two. At least on Linux and >>> Solaris this is certainly possible. Some work for this was already done >>> in Jdk 8 but it was never taken all the way through into actual usage. >>> >>> In this bug, the configure parameters relating to this will be >>> changed to: >>> >>> --with-sysroot: Sets a sysroot directory that will be propagated to the >>> compiler (gcc --sysroot) if supported and which will be used by >>> configure to look for all dependencies like headers and libraries. (old >>> --with-sys-root will be kept for compatibility as an alias) >>> >>> --with-toolchain-path: Prepends to the path when looking for compilers >>> and other target specific tools. Replaces --with-tools-dir, which will >>> also be kept for compatibility as an alias. >>> >>> --with-extra-path: Prepends to the path when looking for everything. >>> >>> --with-devkit: Points to the root of a devkit. A devkit may have a >>> "devkit.info" in its root detailing values for the above three >>> parameters. If not, the fallback behavior is what it used to do. (set >>> toolchain_path to devkit/bin and some options for subdirs for sysroot) >>> >>> >>> Along with these changes some more was needed and done: >>> >>> * To get it to work properly on Solaris, the OPENWIN variables were >>> removed and replaced with X_LIBS and X_CFLAGS. Several unnecessary >>> runtime paths for awt* libs were removed and some were added where they >>> were actually needed instead. All the libs have been verified to still >>> find their dependencies with ldd. >>> >>> * The devkit generation makefiles for linux (in root/make/devkit) were >>> updated to the proposed compiler versions and adding the devkit.info >>> file. >>> >>> * A minor fix in compare.sh that was missed in an earlier patch. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038340 >>> Webrevs: >>> http://cr.openjdk.java.net/~erikj/8038340/webrev.root.01/ >>> http://cr.openjdk.java.net/~erikj/8038340/webrev.jdk.01/ >>> >>> /Erik > From david.katleman at oracle.com Wed Mar 26 23:23:02 2014 From: david.katleman at oracle.com (David Katleman) Date: Wed, 26 Mar 2014 16:23:02 -0700 Subject: RFR : 8038435 : Some hgforest.sh commands don't receive parameters In-Reply-To: References: <53334C17.6030902@oracle.com> <13E28882-3028-4E81-A308-FE102FF27410@oracle.com> Message-ID: <53336156.2080207@oracle.com> On 3/26/2014 3:39 PM, Mike Duigou wrote: > I have updated the webrev to add the tclone. > > I also moved the initial clone from non-local source to only the closed repo case. The check isn't necessary for the case where all sub-repos will be relative to the root repo and not in a separate forest. > > http://cr.openjdk.java.net/~mduigou/JDK-8038435/1/webrev/ >> Add "PYTHONUNBUFFERED=true" to the echo line. > I am not sure why this would be important. It would seem to be just clutter to me. It's clutter only until you are trying to figure out why you get different results when you cut&paste the echo command. That's just my reasoning for suggesting it, you can leave it out. New changes look fine, approved. Thanks Dave On Mar 26 2014, at 15:15 , Mike Duigou wrote: >> On Mar 26 2014, at 14:52 , David Katleman wrote: >> >>> Hi Mike, >>> >>> A few minor comments, overall looks good. >>> >>> On 3/26/2014 2:11 PM, Mike Duigou wrote: >>>> Hello all; >>>> >>>> I introduced bug in JDK-8030681 which prevents non-clone commands from receiving parameters. >>>> >>>> I also slightly cleaned up checking for what is an acceptable root repo as I had encountered this in a problem with a local clone and reverted prior change which made the script a bash script. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8038435 >>>> >>>> webrev: http://cr.openjdk.java.net/~mduigou/JDK-8038435/0/webrev/ >>>> 116 if [ "${command}" = "clone" -o "${command}" = "fclone" ] ; then >>>> 221 if [ "${command}" = "clone" -o "${command}" = "fclone" ] ; then >>> Perhaps out of scope of this fix, but shouldn't we add -o "${command}" = "tclone"? >>> The "fclone" & "tclone" are both cosmetic, neither extensions are used. >>> Can't remove "fclone" without potentionally breaking scripts. >> I can easily add the tclone. >>>> 127 pull_default_tail=`echo ${pull_default} | sed -e 's@^.*://[^/]*/\(.*\)@\1@'` >>>> 128 if [ "x${pull_default}" = "x${pull_default_tail}" ] ; then >>>> 129 echo "ERROR: Need initial clone from non-local source" > ${status_output} >>>> 130 exit 1 >>>> 131 fi >>> The above code looks right for what you want to do, but is it necessary to restrict hgforest.sh to only operate vs non-local? >> The problem is that the default path is used to figure out the peer name in the extra (closed) repo. It's not possible to do this from a local path unless you make assumptions or we change the requirements for the extra path to include the appropriate root repo. >> >>> Seems one should still be able to have their own forest, and clone from that forest locally. >>> >>>> 238 echo "cd ${i} && hg${global_opts} ${command} ${command_args}" > ${status_output} >>>> 239 cd ${i} && (PYTHONUNBUFFERED=true hg${global_opts} ${command} ${command_args}; echo "$?" > ${tmp}/${repopidfile}.pid.rc ) 2>&1 & >>> Add "PYTHONUNBUFFERED=true" to the echo line. >> I am not sure why this would be important. It would seem to be just clutter to me. >> >> Thanks! >> >> Mike From magnus.ihse.bursie at oracle.com Thu Mar 27 08:00:19 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 27 Mar 2014 09:00:19 +0100 Subject: RFR: JDK-8038340: Cleanup and fix sysroot and devkit handling on Linux and Solaris In-Reply-To: <53335944.4070007@oracle.com> References: <5332ACC3.6080109@oracle.com> <5332BF30.7080903@oracle.com> <5332C0B6.5020804@oracle.com> <53335944.4070007@oracle.com> Message-ID: <0B9D384A-0709-445A-89B7-54DE0229AE2D@oracle.com> Yes, basically. And, optionally, an extra path (for non-toolchain binaries). So setting --with-devkit is, in a way, a convenient way of setting all these three options, in a way that works together and makes sense. That is, more or less, the same behavior we've had all the time, but it's slightly more formalized now. /Magnus > On 26 mar 2014, at 23:48, David Holmes wrote: > >> On 26/03/2014 9:57 PM, Magnus Ihse Bursie wrote: >> >>> On 2014-03-26 12:51, David Holmes wrote: >>> sysroots and tool-chains and dev-kits! oh my! >>> >>> Seriously, what does all this mean for someone who just wants to build >>> the OpenJDK? I use dev-kit for cross-compilation builds but I have no >>> idea what these different things are supposed to represent. >> >> You can continue to use --with-devkit as you had. That was one of the >> design goals for this change. >> >> The theory is something like this: >> * A "sysroot" is a stripped-down root directory of the *target* >> platform, containing include files and libraries needed to compile and >> link for a target (possibly cross-) platform. >> * The toolchain path is one or more directories that contains binaries >> that will run on the build platform, but generate code for the target >> platform. While the separation is somewhat fuzzy, we use the toolchain >> path for "toolchain" binaries, basically, those that compile, link or >> otherwise interact with the target platform binaries. >> * The extra path is one or more directories that contain any kind of >> binaries, e.g. a proper version of zip or grep. If you do not deal with >> cross-platform devkits, there is no real difference between extra path >> and toolchain path. > > So what then is a "dev-kit"? A combined sysroot+tool-chain? > > Thanks, > David > >> And that is what is needed to encapsulate the tools needed to compile >> OpenJDK. >> >> /Magnus >> >>> >>> David >>> >>>> On 26/03/2014 8:32 PM, Erik Joelsson wrote: >>>> Hello, >>>> >>>> (including 2d-dev/awt-dev because I'm changing linker flags on desktop >>>> libs.) >>>> >>>> In preparation for upgrading compilers and build platforms, we would >>>> like to get better separation between the two. At least on Linux and >>>> Solaris this is certainly possible. Some work for this was already done >>>> in Jdk 8 but it was never taken all the way through into actual usage. >>>> >>>> In this bug, the configure parameters relating to this will be >>>> changed to: >>>> >>>> --with-sysroot: Sets a sysroot directory that will be propagated to the >>>> compiler (gcc --sysroot) if supported and which will be used by >>>> configure to look for all dependencies like headers and libraries. (old >>>> --with-sys-root will be kept for compatibility as an alias) >>>> >>>> --with-toolchain-path: Prepends to the path when looking for compilers >>>> and other target specific tools. Replaces --with-tools-dir, which will >>>> also be kept for compatibility as an alias. >>>> >>>> --with-extra-path: Prepends to the path when looking for everything. >>>> >>>> --with-devkit: Points to the root of a devkit. A devkit may have a >>>> "devkit.info" in its root detailing values for the above three >>>> parameters. If not, the fallback behavior is what it used to do. (set >>>> toolchain_path to devkit/bin and some options for subdirs for sysroot) >>>> >>>> >>>> Along with these changes some more was needed and done: >>>> >>>> * To get it to work properly on Solaris, the OPENWIN variables were >>>> removed and replaced with X_LIBS and X_CFLAGS. Several unnecessary >>>> runtime paths for awt* libs were removed and some were added where they >>>> were actually needed instead. All the libs have been verified to still >>>> find their dependencies with ldd. >>>> >>>> * The devkit generation makefiles for linux (in root/make/devkit) were >>>> updated to the proposed compiler versions and adding the devkit.info >>>> file. >>>> >>>> * A minor fix in compare.sh that was missed in an earlier patch. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038340 >>>> Webrevs: >>>> http://cr.openjdk.java.net/~erikj/8038340/webrev.root.01/ >>>> http://cr.openjdk.java.net/~erikj/8038340/webrev.jdk.01/ >>>> >>>> /Erik >> From erik.joelsson at oracle.com Thu Mar 27 08:05:31 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 27 Mar 2014 09:05:31 +0100 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: References: <532BA650.7000402@oracle.com> <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> <532FA869.7030209@oracle.com> <53315B54.3050005@oracle.com> <5331DBF5.1000501@oracle.com> <53320EC3.8070607@oracle.com> <533218AC.4000108@oracle.com> <16216345-F06B-404B-90C5-EA605600D6F2@oracle.com> Message-ID: <5333DBCB.6050200@oracle.com> There are unfortunately legal complications surrounding updating these files. We can initiate the approval dance, but it will take time to go through (weeks at least). This is the reason Magnus added the wrapper around config.guess, so that we could get functional updates to it faster. I agree that long term, updating these files from the source is the correct action. /Erik On 2014-03-26 23:47, Alexander Smundak wrote: > On Wed, Mar 26, 2014 at 2:21 AM, Volker Simonis > wrote: >> So I'd suggest we just check in this new version for the current >> common/autoconf/build-aux/config.guess. > I agree. > > Magnus, would you like me to do this? From volker.simonis at gmail.com Thu Mar 27 08:36:28 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 27 Mar 2014 09:36:28 +0100 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <5333DBCB.6050200@oracle.com> References: <532BA650.7000402@oracle.com> <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> <532FA869.7030209@oracle.com> <53315B54.3050005@oracle.com> <5331DBF5.1000501@oracle.com> <53320EC3.8070607@oracle.com> <533218AC.4000108@oracle.com> <16216345-F06B-404B-90C5-EA605600D6F2@oracle.com> <5333DBCB.6050200@oracle.com> Message-ID: On Thu, Mar 27, 2014 at 9:05 AM, Erik Joelsson wrote: > There are unfortunately legal complications surrounding updating these > files. We can initiate the approval dance, but it will take time to go > through (weeks at least). This is the reason Magnus added the wrapper around > config.guess, so that we could get functional updates to it faster. > OK, but as I wrote, config.guess currently only maps some recognized systems to different names. This case is different because for ppc64le the output of 'autoconf-config.guess' would be an emtpy string and a quite big error message on stderr. Do you really want that we make Linux/ppc64le the default fallback in config.guess if 'autoconf-config.guess' can not detect a system? Or should we exceptionally just patch 'autoconf-config.guess' if we know that we will update it anyway with a new version within a few weeks? I think I'd prefer this solution, because this is just one change which will be automatically removed once we integrate the new 'autoconf-config.guess' version. If we just hack 'config.guess' we would have to manually take that change back once we get the new 'autoconf-config.guess' version. In any case I'd kindly ask you to start the 'legal approval dance' :) Regards, Volker > I agree that long term, updating these files from the source is the correct > action. > > /Erik > > > On 2014-03-26 23:47, Alexander Smundak wrote: >> >> On Wed, Mar 26, 2014 at 2:21 AM, Volker Simonis >> wrote: >>> >>> So I'd suggest we just check in this new version for the current >>> common/autoconf/build-aux/config.guess. >> >> I agree. >> >> Magnus, would you like me to do this? > > From erik.joelsson at oracle.com Thu Mar 27 10:30:49 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 27 Mar 2014 11:30:49 +0100 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: References: <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> <532FA869.7030209@oracle.com> <53315B54.3050005@oracle.com> <5331DBF5.1000501@oracle.com> <53320EC3.8070607@oracle.com> <533218AC.4000108@oracle.com> <16216345-F06B-404B-90C5-EA605600D6F2@oracle.com> <5333DBCB.6050200@oracle.com> Message-ID: <5333FDD9.2040707@oracle.com> For the approval. Is this for JDK9 only? /Erik On 2014-03-27 09:36, Volker Simonis wrote: > On Thu, Mar 27, 2014 at 9:05 AM, Erik Joelsson wrote: >> There are unfortunately legal complications surrounding updating these >> files. We can initiate the approval dance, but it will take time to go >> through (weeks at least). This is the reason Magnus added the wrapper around >> config.guess, so that we could get functional updates to it faster. >> > OK, but as I wrote, config.guess currently only maps some recognized > systems to different names. This case is different because for ppc64le > the output of 'autoconf-config.guess' would be an emtpy string and a > quite big error message on stderr. Do you really want that we make > Linux/ppc64le the default fallback in config.guess if > 'autoconf-config.guess' can not detect a system? Why does it need to be the only fallback? Couldn't you do some sanity uname check as well? > Or should we exceptionally just patch 'autoconf-config.guess' if we > know that we will update it anyway with a new version within a few > weeks? I think I'd prefer this solution, because this is just one > change which will be automatically removed once we integrate the new > 'autoconf-config.guess' version. If we just hack 'config.guess' we > would have to manually take that change back once we get the new > 'autoconf-config.guess' version. It's unclear to us if we are allowed to make edits in these files. I also suspect that the current wrapper file would need to be changed after an update anyway. > In any case I'd kindly ask you to start the 'legal approval dance' :) Working on it. Is this for JDK9 only or are you planning backports? /Erik > Regards, > Volker > >> I agree that long term, updating these files from the source is the correct >> action. >> >> /Erik >> >> >> On 2014-03-26 23:47, Alexander Smundak wrote: >>> On Wed, Mar 26, 2014 at 2:21 AM, Volker Simonis >>> wrote: >>>> So I'd suggest we just check in this new version for the current >>>> common/autoconf/build-aux/config.guess. >>> I agree. >>> >>> Magnus, would you like me to do this? >> From erik.joelsson at oracle.com Thu Mar 27 10:42:26 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 27 Mar 2014 11:42:26 +0100 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <5333FDD9.2040707@oracle.com> References: <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> <532FA869.7030209@oracle.com> <53315B54.3050005@oracle.com> <5331DBF5.1000501@oracle.com> <53320EC3.8070607@oracle.com> <533218AC.4000108@oracle.com> <16216345-F06B-404B-90C5-EA605600D6F2@oracle.com> <5333DBCB.6050200@oracle.com> <5333FDD9.2040707@oracl! e.com> Message-ID: <53340092.2010907@oracle.com> Oops, sent this unfinished. See answers inline instead: On 2014-03-27 11:30, Erik Joelsson wrote: > > On 2014-03-27 09:36, Volker Simonis wrote: >> On Thu, Mar 27, 2014 at 9:05 AM, Erik Joelsson >> wrote: >>> There are unfortunately legal complications surrounding updating these >>> files. We can initiate the approval dance, but it will take time to go >>> through (weeks at least). This is the reason Magnus added the >>> wrapper around >>> config.guess, so that we could get functional updates to it faster. >>> >> OK, but as I wrote, config.guess currently only maps some recognized >> systems to different names. This case is different because for ppc64le >> the output of 'autoconf-config.guess' would be an emtpy string and a >> quite big error message on stderr. Do you really want that we make >> Linux/ppc64le the default fallback in config.guess if >> 'autoconf-config.guess' can not detect a system? Why does it need to be the only fallback? Couldn't you do some sanity uname check as well? >> Or should we exceptionally just patch 'autoconf-config.guess' if we >> know that we will update it anyway with a new version within a few >> weeks? I think I'd prefer this solution, because this is just one >> change which will be automatically removed once we integrate the new >> 'autoconf-config.guess' version. If we just hack 'config.guess' we >> would have to manually take that change back once we get the new >> 'autoconf-config.guess' version. It's unclear to us if we are allowed to make edits in these files. I also suspect that the current wrapper file would need to be changed after an update anyway. >> In any case I'd kindly ask you to start the 'legal approval dance' :) Working on it. Is this for JDK9 only or are you planning backports? /Erik From chris.hegarty at oracle.com Thu Mar 27 10:46:59 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 27 Mar 2014 10:46:59 +0000 Subject: RFR [9] 8038459: (sctp) Remove superflous classes on platforms without an implementation [macosx, aix] Message-ID: While hunting around the build recently, when working on another SCTP bug, I noticed a small issue where SCTP classes are being built on some platforms unnecessarily. Webrev: http://cr.openjdk.java.net/~chegar/8038459/webrev.00/webrev/ Mac OS X and AIX contain only stubs for the SCTP channels. There are platform specific versions of the stubs for these platforms, so the build currently filters out the three channel implementation classes, on these platforms. But, there are other implementation classes in src/solaris/classes/sun/nio/ch/sctp that are needed for Linux and Solaris. These classes should be filter out also, on platforms that do not require them ( Mac OS X and AIX ). Looking at rt. jar from a Mac JRE the superfluous classes can be seen: $ jar -tvf rt.jar | grep "sun/nio/ch/sctp" 2420 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/AssociationChange.class <<< NOT NEEDED 759 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/AssociationImpl.class <<< NOT NEEDED 2614 Thu Feb 27 23:47:04 GMT 2014 sun/nio/ch/sctp/MessageInfoImpl.class 2607 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/PeerAddrChange.class <<< NOT NEEDED 2793 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/ResultContainer.class <<< NOT NEEDED 2850 Thu Feb 27 23:47:10 GMT 2014 sun/nio/ch/sctp/SctpChannelImpl.class 2987 Thu Feb 27 23:47:10 GMT 2014 sun/nio/ch/sctp/SctpMultiChannelImpl.class 7712 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/SctpNet.class <<< NOT NEEDED 251 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/SctpNotification.class <<< NOT NEEDED 1935 Thu Feb 27 23:47:10 GMT 2014 sun/nio/ch/sctp/SctpServerChannelImpl.class 1379 Thu Feb 27 23:47:04 GMT 2014 sun/nio/ch/sctp/SctpStdSocketOption.class 1953 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/SendFailed.class <<< NOT NEEDED 1239 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/Shutdown.class <<< NOT NEEDED Note: SctpStdSocketOption.class and MessageInfoImpl.class are platform independent, and needed to support parts of the API that are not dependent on an actual socket implementation. -Chris. From erik.joelsson at oracle.com Thu Mar 27 11:02:27 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 27 Mar 2014 12:02:27 +0100 Subject: RFR [9] 8038459: (sctp) Remove superflous classes on platforms without an implementation [macosx, aix] In-Reply-To: References: Message-ID: <53340543.50808@oracle.com> Looks good to me from a build perspective. /Erik On 2014-03-27 11:46, Chris Hegarty wrote: > While hunting around the build recently, when working on another SCTP bug, I noticed a small issue where SCTP classes are being built on some platforms unnecessarily. > > Webrev: > http://cr.openjdk.java.net/~chegar/8038459/webrev.00/webrev/ > > Mac OS X and AIX contain only stubs for the SCTP channels. There are platform specific versions of the stubs for these platforms, so the build currently filters out the three channel implementation classes, on these platforms. But, there are other implementation classes in src/solaris/classes/sun/nio/ch/sctp that are needed for Linux and Solaris. These classes should be filter out also, on platforms that do not require them ( Mac OS X and AIX ). > > Looking at rt. jar from a Mac JRE the superfluous classes can be seen: > > $ jar -tvf rt.jar | grep "sun/nio/ch/sctp" > 2420 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/AssociationChange.class <<< NOT NEEDED > 759 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/AssociationImpl.class <<< NOT NEEDED > 2614 Thu Feb 27 23:47:04 GMT 2014 sun/nio/ch/sctp/MessageInfoImpl.class > 2607 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/PeerAddrChange.class <<< NOT NEEDED > 2793 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/ResultContainer.class <<< NOT NEEDED > 2850 Thu Feb 27 23:47:10 GMT 2014 sun/nio/ch/sctp/SctpChannelImpl.class > 2987 Thu Feb 27 23:47:10 GMT 2014 sun/nio/ch/sctp/SctpMultiChannelImpl.class > 7712 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/SctpNet.class <<< NOT NEEDED > 251 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/SctpNotification.class <<< NOT NEEDED > 1935 Thu Feb 27 23:47:10 GMT 2014 sun/nio/ch/sctp/SctpServerChannelImpl.class > 1379 Thu Feb 27 23:47:04 GMT 2014 sun/nio/ch/sctp/SctpStdSocketOption.class > 1953 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/SendFailed.class <<< NOT NEEDED > 1239 Thu Feb 27 23:47:08 GMT 2014 sun/nio/ch/sctp/Shutdown.class <<< NOT NEEDED > > Note: SctpStdSocketOption.class and MessageInfoImpl.class are platform independent, and needed to support parts of the API that are not dependent on an actual socket implementation. > > -Chris. From volker.simonis at gmail.com Thu Mar 27 11:40:07 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 27 Mar 2014 12:40:07 +0100 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <5333FDD9.2040707@oracle.com> References: <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> <532FA869.7030209@oracle.com> <53315B54.3050005@oracle.com> <5331DBF5.1000501@oracle.com> <53320EC3.8070607@oracle.com> <533218AC.4000108@oracle.com> <16216345-F06B-404B-90C5-EA605600D6F2@oracle.com> <5333DBCB.6050200@oracle.com> <5333FDD9.2040707@oracle.com> Message-ID: On Thu, Mar 27, 2014 at 11:30 AM, Erik Joelsson wrote: > > > > > For the approval. Is this for JDK9 only? > No, we want to bring this to jdk8 eventually. > /Erik > > > On 2014-03-27 09:36, Volker Simonis wrote: >> >> On Thu, Mar 27, 2014 at 9:05 AM, Erik Joelsson >> wrote: >>> >>> There are unfortunately legal complications surrounding updating these >>> files. We can initiate the approval dance, but it will take time to go >>> through (weeks at least). This is the reason Magnus added the wrapper >>> around >>> config.guess, so that we could get functional updates to it faster. >>> >> OK, but as I wrote, config.guess currently only maps some recognized >> systems to different names. This case is different because for ppc64le >> the output of 'autoconf-config.guess' would be an emtpy string and a >> quite big error message on stderr. Do you really want that we make >> Linux/ppc64le the default fallback in config.guess if >> 'autoconf-config.guess' can not detect a system? > > Why does it need to be the only fallback? Couldn't you do some sanity uname > check as well? Sorry, you're right of course. @Sasha: could you please add something like: if [ "$OUT"x = ""x ]; then if [ `uname -m` = "ppc64le" ]; then OUT=ppc64le-unknown-linux-gnu fi fi to the end of config.guess. That should do the job and it is probably the fastest solution for our problem. It may be also easier to downport this simple change to 8 compared to a completely new version of 'autoconf-config.guess' (although I don't see a problem with that either). > >> Or should we exceptionally just patch 'autoconf-config.guess' if we >> know that we will update it anyway with a new version within a few >> weeks? I think I'd prefer this solution, because this is just one >> change which will be automatically removed once we integrate the new >> 'autoconf-config.guess' version. If we just hack 'config.guess' we >> would have to manually take that change back once we get the new >> 'autoconf-config.guess' version. > > It's unclear to us if we are allowed to make edits in these files. > > I also suspect that the current wrapper file would need to be changed after > an update anyway. I don't think so because as far as I can see, the new versions are backward compatible in the sense that they don't change existing platform strings. So the old mappings will have to be done with the new script in the same way. > >> In any case I'd kindly ask you to start the 'legal approval dance' :) > > Working on it. Is this for JDK9 only or are you planning backports? > > /Erik > >> Regards, >> Volker >> >>> I agree that long term, updating these files from the source is the >>> correct >>> action. >>> >>> /Erik >>> >>> >>> On 2014-03-26 23:47, Alexander Smundak wrote: >>>> >>>> On Wed, Mar 26, 2014 at 2:21 AM, Volker Simonis >>>> wrote: >>>>> >>>>> So I'd suggest we just check in this new version for the current >>>>> common/autoconf/build-aux/config.guess. >>>> >>>> I agree. >>>> >>>> Magnus, would you like me to do this? >>> >>> > From erik.joelsson at oracle.com Thu Mar 27 11:47:27 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 27 Mar 2014 12:47:27 +0100 Subject: RFR: JDK-8038340: Cleanup and fix sysroot and devkit handling on Linux and Solaris In-Reply-To: <5332BBB9.1040302@oracle.com> References: <5332ACC3.6080109@oracle.com> <5332B687.40402@oracle.com> <5332BAB3.6020505@oracle.com> <5332BBB9.1040302@oracle.com> Message-ID: <53340FCF.3080305@oracle.com> Further testing revealed some more issues. New webrev: http://cr.openjdk.java.net/~erikj/8038340/webrev.root.03/ I had to break out the devkit/sysroot parts from from BASIC_SETUP_PATHS so that it happened after the early custom hook. /Erik On 2014-03-26 12:36, Magnus Ihse Bursie wrote: > > On 2014-03-26 12:32, Erik Joelsson wrote: >> Thanks, here is a new webrev: >> >> http://cr.openjdk.java.net/~erikj/8038340/webrev.root.02/ > Looks good to me. > > /Magnus From magnus.ihse.bursie at oracle.com Thu Mar 27 12:27:31 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 27 Mar 2014 13:27:31 +0100 Subject: RFR: JDK-8038340: Cleanup and fix sysroot and devkit handling on Linux and Solaris In-Reply-To: <53340FCF.3080305@oracle.com> References: <5332ACC3.6080109@oracle.com> <5332B687.40402@oracle.com> <5332BAB3.6020505@oracle.com> <5332BBB9.1040302@oracle.com> <53340FCF.3080305@oracle.com> Message-ID: Looks good to me. /Magnus > On 27 mar 2014, at 12:47, Erik Joelsson wrote: > > Further testing revealed some more issues. New webrev: > > http://cr.openjdk.java.net/~erikj/8038340/webrev.root.03/ > > I had to break out the devkit/sysroot parts from from BASIC_SETUP_PATHS so that it happened after the early custom hook. > > /Erik > >> On 2014-03-26 12:36, Magnus Ihse Bursie wrote: >> >>> On 2014-03-26 12:32, Erik Joelsson wrote: >>> Thanks, here is a new webrev: >>> >>> http://cr.openjdk.java.net/~erikj/8038340/webrev.root.02/ >> Looks good to me. >> >> /Magnus > From asmundak at google.com Thu Mar 27 17:51:29 2014 From: asmundak at google.com (Alexander Smundak) Date: Thu, 27 Mar 2014 10:51:29 -0700 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: References: <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> <532FA869.7030209@oracle.com> <53315B54.3050005@oracle.com> <5331DBF5.1000501@oracle.com> <53320EC3.8070607@oracle.com> <533218AC.4000108@oracle.com> <16216345-F06B-404B-90C5-EA605600D6F2@oracle.com> <5333DBCB.6050200@oracle.com> <5333FDD9.2040707@oracle.com> Message-ID: I have uploaded a new revision which handler ppc64le in the config.guess wrapper: http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.02/ On Thu, Mar 27, 2014 at 4:40 AM, Volker Simonis wrote: > On Thu, Mar 27, 2014 at 11:30 AM, Erik Joelsson > wrote: >> >> >> >> >> For the approval. Is this for JDK9 only? >> > > No, we want to bring this to jdk8 eventually. > >> /Erik >> >> >> On 2014-03-27 09:36, Volker Simonis wrote: >>> >>> On Thu, Mar 27, 2014 at 9:05 AM, Erik Joelsson >>> wrote: >>>> >>>> There are unfortunately legal complications surrounding updating these >>>> files. We can initiate the approval dance, but it will take time to go >>>> through (weeks at least). This is the reason Magnus added the wrapper >>>> around >>>> config.guess, so that we could get functional updates to it faster. >>>> >>> OK, but as I wrote, config.guess currently only maps some recognized >>> systems to different names. This case is different because for ppc64le >>> the output of 'autoconf-config.guess' would be an emtpy string and a >>> quite big error message on stderr. Do you really want that we make >>> Linux/ppc64le the default fallback in config.guess if >>> 'autoconf-config.guess' can not detect a system? >> >> Why does it need to be the only fallback? Couldn't you do some sanity uname >> check as well? > > Sorry, you're right of course. > > @Sasha: could you please add something like: > > > if [ "$OUT"x = ""x ]; then > if [ `uname -m` = "ppc64le" ]; then > OUT=ppc64le-unknown-linux-gnu > fi > fi > > to the end of config.guess. That should do the job and it is probably > the fastest solution for our problem. > > It may be also easier to downport this simple change to 8 compared to > a completely new version of 'autoconf-config.guess' (although I don't > see a problem with that either). > >> >>> Or should we exceptionally just patch 'autoconf-config.guess' if we >>> know that we will update it anyway with a new version within a few >>> weeks? I think I'd prefer this solution, because this is just one >>> change which will be automatically removed once we integrate the new >>> 'autoconf-config.guess' version. If we just hack 'config.guess' we >>> would have to manually take that change back once we get the new >>> 'autoconf-config.guess' version. >> >> It's unclear to us if we are allowed to make edits in these files. >> >> I also suspect that the current wrapper file would need to be changed after >> an update anyway. > > I don't think so because as far as I can see, the new versions are > backward compatible in the sense that they don't change existing > platform strings. So the old mappings will have to be done with the > new script in the same way. > >> >>> In any case I'd kindly ask you to start the 'legal approval dance' :) >> >> Working on it. Is this for JDK9 only or are you planning backports? >> >> /Erik >> >>> Regards, >>> Volker >>> >>>> I agree that long term, updating these files from the source is the >>>> correct >>>> action. >>>> >>>> /Erik >>>> >>>> >>>> On 2014-03-26 23:47, Alexander Smundak wrote: >>>>> >>>>> On Wed, Mar 26, 2014 at 2:21 AM, Volker Simonis >>>>> wrote: >>>>>> >>>>>> So I'd suggest we just check in this new version for the current >>>>>> common/autoconf/build-aux/config.guess. >>>>> >>>>> I agree. >>>>> >>>>> Magnus, would you like me to do this? >>>> >>>> >> From magnus.ihse.bursie at oracle.com Fri Mar 28 07:40:53 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 28 Mar 2014 08:40:53 +0100 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: References: <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> <532FA869.7030209@oracle.com> <53315B54.3050005@oracle.com> <5331DBF5.1000501@oracle.com> <53320EC3.8070607@oracle.com> <533218AC.4000108@oracle.com> <16216345-F06B-404B-90C5-EA605600D6F2@oracle.com> <5333DBCB.6050200@oracle.com> <5333FDD9.2040707@oracl! e.com> Message-ID: > On 27 mar 2014, at 18:51, Alexander Smundak wrote: > > I have uploaded a new revision which handler ppc64le in the > config.guess wrapper: > http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.02/ Thank you Alexander. Looks good to me. /Magnus From volker.simonis at gmail.com Fri Mar 28 10:49:22 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 28 Mar 2014 11:49:22 +0100 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: References: <532BB8A3.3080004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA9A38@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CEA9D9F@DEWDFEMB12A.global.corp.sap> <532FA869.7030209@oracle.com> <53315B54.3050005@oracle.com> <5331DBF5.1000501@oracle.com> <53320EC3.8070607@oracle.com> <533218AC.4000108@oracle.com> <16216345-F06B-404B-90C5-EA605600D6F2@oracle.com> <5333DBCB.6050200@oracle.com> Message-ID: Hi Magnus, could you please push this change? I can't do it because it requires regenerating generated-configure.sh and potentially regenerating the closed configure files as well. Thank you and best regards, Volker On Fri, Mar 28, 2014 at 8:40 AM, Magnus Ihse Bursie wrote: >> On 27 mar 2014, at 18:51, Alexander Smundak wrote: >> >> I have uploaded a new revision which handler ppc64le in the >> config.guess wrapper: >> http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.02/ > > Thank you Alexander. Looks good to me. > > /Magnus From james.laskey at oracle.com Fri Mar 28 13:28:40 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 28 Mar 2014 10:28:40 -0300 Subject: -Wformat-nonliteral Message-ID: /Projects/jdk9-dev/hotspot/src/share/vm/utilities/debug.cpp:105:19: error: format string is not a string literal [-Werror,-Wformat-nonliteral] vfprintf(err, format, ap); ^~~~~~ Try to build jdk9-dev tip I ran into this. Wassup? -- Jim From staffan.larsen at oracle.com Fri Mar 28 14:05:10 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 28 Mar 2014 15:05:10 +0100 Subject: -Wformat-nonliteral In-Reply-To: References: Message-ID: Building with clang? https://bugs.openjdk.java.net/browse/JDK-8037816 https://bugs.openjdk.java.net/browse/JDK-8019470 /Staffan On 28 mar 2014, at 14:28, Jim Laskey (Oracle) wrote: > /Projects/jdk9-dev/hotspot/src/share/vm/utilities/debug.cpp:105:19: error: format string is not a string literal [-Werror,-Wformat-nonliteral] > vfprintf(err, format, ap); > ^~~~~~ > > > Try to build jdk9-dev tip I ran into this. Wassup? > > -- Jim > From james.laskey at oracle.com Fri Mar 28 14:06:06 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 28 Mar 2014 11:06:06 -0300 Subject: -Wformat-nonliteral In-Reply-To: References: Message-ID: <8CFD96AF-48A3-4247-ADD8-C0594916EDA9@oracle.com> Yes On Mar 28, 2014, at 11:05 AM, Staffan Larsen wrote: > Building with clang? > > https://bugs.openjdk.java.net/browse/JDK-8037816 > https://bugs.openjdk.java.net/browse/JDK-8019470 > > /Staffan > > > On 28 mar 2014, at 14:28, Jim Laskey (Oracle) wrote: > >> /Projects/jdk9-dev/hotspot/src/share/vm/utilities/debug.cpp:105:19: error: format string is not a string literal [-Werror,-Wformat-nonliteral] >> vfprintf(err, format, ap); >> ^~~~~~ >> >> >> Try to build jdk9-dev tip I ran into this. Wassup? >> >> -- Jim >> > From volker.simonis at gmail.com Fri Mar 28 15:52:30 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 28 Mar 2014 16:52:30 +0100 Subject: -Wformat-nonliteral In-Reply-To: <8CFD96AF-48A3-4247-ADD8-C0594916EDA9@oracle.com> References: <8CFD96AF-48A3-4247-ADD8-C0594916EDA9@oracle.com> Message-ID: I think this is: "8037816: Fix for 8036122 breaks build with Xcode5/clang" (https://bugs.openjdk.java.net/browse/JDK-8037816) which was caused by: "8036122: Fix warning "format not a string literal"" https://bugs.openjdk.java.net/browse/JDK-8036122 which was caused by: "8030350: Enable additional compiler warnings for GCC" https://bugs.openjdk.java.net/browse/JDK-8030350 Hopefully the fix for "8037816: Fix for 8036122 breaks build with Xcode5/clang" will not introduce any other new regressions:) Regards, Volker On Fri, Mar 28, 2014 at 3:06 PM, Jim Laskey (Oracle) wrote: > Yes > > On Mar 28, 2014, at 11:05 AM, Staffan Larsen wrote: > >> Building with clang? >> >> https://bugs.openjdk.java.net/browse/JDK-8037816 >> https://bugs.openjdk.java.net/browse/JDK-8019470 >> >> /Staffan >> >> >> On 28 mar 2014, at 14:28, Jim Laskey (Oracle) wrote: >> >>> /Projects/jdk9-dev/hotspot/src/share/vm/utilities/debug.cpp:105:19: error: format string is not a string literal [-Werror,-Wformat-nonliteral] >>> vfprintf(err, format, ap); >>> ^~~~~~ >>> >>> >>> Try to build jdk9-dev tip I ran into this. Wassup? >>> >>> -- Jim >>> >> > From henry.jen at oracle.com Fri Mar 28 16:27:07 2014 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 28 Mar 2014 09:27:07 -0700 Subject: -Wformat-nonliteral In-Reply-To: <8CFD96AF-48A3-4247-ADD8-C0594916EDA9@oracle.com> References: <8CFD96AF-48A3-4247-ADD8-C0594916EDA9@oracle.com> Message-ID: <5335A2DB.6070806@oracle.com> Workaround is to revert the bsd makefile change, this will get you a build on Mac as before, > --- a/make/bsd/makefiles/gcc.make Tue Mar 04 09:57:16 2014 -0500 > +++ b/make/bsd/makefiles/gcc.make Mon Mar 03 11:54:35 2014 +0100 > @@ -260,7 +260,7 @@ > WARNINGS_ARE_ERRORS += -Wno-empty-body > endif > > -WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wformat=2 > +WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wformat=2 -Wno-error=format-nonliteral > > ifeq ($(USE_CLANG),) > # Since GCC 4.3, -Wconversion has changed its meanings to warn these implicit The better fix is to add attribute annotation, IMHO. Cheers, Henry On 03/28/2014 07:06 AM, Jim Laskey (Oracle) wrote: > Yes > > On Mar 28, 2014, at 11:05 AM, Staffan Larsen wrote: > >> Building with clang? >> >> https://bugs.openjdk.java.net/browse/JDK-8037816 >> https://bugs.openjdk.java.net/browse/JDK-8019470 >> >> /Staffan >> >> >> On 28 mar 2014, at 14:28, Jim Laskey (Oracle) wrote: >> >>> /Projects/jdk9-dev/hotspot/src/share/vm/utilities/debug.cpp:105:19: error: format string is not a string literal [-Werror,-Wformat-nonliteral] >>> vfprintf(err, format, ap); >>> ^~~~~~ >>> >>> >>> Try to build jdk9-dev tip I ran into this. Wassup? >>> >>> -- Jim >>> >> > From peter.brunet at oracle.com Fri Mar 28 17:20:17 2014 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 28 Mar 2014 12:20:17 -0500 Subject: macosx jdk builds failing randomly Message-ID: <5335AF51.702@oracle.com> It's been two or three weeks since I last built 9 on macosx but I started rebuilding yesterday and am getting random failures in the jdk build: Twice I got this: Compiling 225 files for BUILD_SECURITY Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. /usr/bin/printf: illegal option -- s usage: printf format [arguments ...] make[2]: *** [/Users/petebrunet/JDK9/JDK-8034118/jdk9/build/macosx-x86-normal-server-release/jdk/lib/jvm.cfg] Error 1 And twice got this: /Users/petebrunet/JDK9/JDK-8034768/jdk9/jdk/src/macosx/native/sun/awt/LWCToolkit.m:92: warning: ivar name ?_runnable? specified on the synthesized property ?runnable? not found /Users/petebrunet/JDK9/JDK-8034768/jdk9/jdk/src/macosx/native/sun/awt/LWCToolkit.m:92: error: synthesized property ?runnable? must either be named the same as a compatible ivar or must explicitly name an ivar /Users/petebrunet/JDK9/JDK-8034768/jdk9/jdk/src/macosx/native/sun/awt/LWCToolkit.m: In function ?__doLoadNativeColors_block_invoke_1?: /Users/petebrunet/JDK9/JDK-8034768/jdk9/jdk/src/macosx/native/sun/awt/LWCToolkit.m:288: warning: comparison between signed and unsigned make[2]: *** [/Users/petebrunet/JDK9/JDK-8034768/jdk9/build/macosx-x86-normal-server-release/jdk/objs/libawt_lwawt/LWCToolkit.o] Error 1 From peter.brunet at oracle.com Fri Mar 28 21:00:06 2014 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 28 Mar 2014 16:00:06 -0500 Subject: macosx jdk builds failing randomly In-Reply-To: <5335AF51.702@oracle.com> References: <5335AF51.702@oracle.com> Message-ID: <5335E2D6.7040301@oracle.com> Cockpit error - that's what happens when you use --with-target-bits=32 on macosx. (I also upgraded Java to 8 GA but I doubt that mattered.) On 3/28/14 12:20 PM, Pete Brunet wrote: > It's been two or three weeks since I last built 9 on macosx but I > started rebuilding yesterday and am getting random failures in the jdk > build: > > Twice I got this: > > Compiling 225 files for BUILD_SECURITY > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > /usr/bin/printf: illegal option -- s > usage: printf format [arguments ...] > make[2]: *** > [/Users/petebrunet/JDK9/JDK-8034118/jdk9/build/macosx-x86-normal-server-release/jdk/lib/jvm.cfg] > Error 1 > > And twice got this: > > /Users/petebrunet/JDK9/JDK-8034768/jdk9/jdk/src/macosx/native/sun/awt/LWCToolkit.m:92: > warning: ivar name ?_runnable? specified on the synthesized property > ?runnable? not found > /Users/petebrunet/JDK9/JDK-8034768/jdk9/jdk/src/macosx/native/sun/awt/LWCToolkit.m:92: > error: synthesized property ?runnable? must either be named the same as > a compatible ivar or must explicitly name an ivar > /Users/petebrunet/JDK9/JDK-8034768/jdk9/jdk/src/macosx/native/sun/awt/LWCToolkit.m: > In function ?__doLoadNativeColors_block_invoke_1?: > /Users/petebrunet/JDK9/JDK-8034768/jdk9/jdk/src/macosx/native/sun/awt/LWCToolkit.m:288: > warning: comparison between signed and unsigned > make[2]: *** > [/Users/petebrunet/JDK9/JDK-8034768/jdk9/build/macosx-x86-normal-server-release/jdk/objs/libawt_lwawt/LWCToolkit.o] > Error 1 > > From david.holmes at oracle.com Sat Mar 29 00:50:46 2014 From: david.holmes at oracle.com (David Holmes) Date: Sat, 29 Mar 2014 10:50:46 +1000 Subject: macosx jdk builds failing randomly In-Reply-To: <5335E2D6.7040301@oracle.com> References: <5335AF51.702@oracle.com> <5335E2D6.7040301@oracle.com> Message-ID: <533618E6.6010303@oracle.com> On 29/03/2014 7:00 AM, Pete Brunet wrote: > Cockpit error - that's what happens when you use --with-target-bits=32 > on macosx. (I also upgraded Java to 8 GA but I doubt that mattered.) > > On 3/28/14 12:20 PM, Pete Brunet wrote: >> It's been two or three weeks since I last built 9 on macosx but I >> started rebuilding yesterday and am getting random failures in the jdk >> build: >> >> Twice I got this: >> >> Compiling 225 files for BUILD_SECURITY >> Note: Some input files use or override a deprecated API. >> Note: Recompile with -Xlint:deprecation for details. >> /usr/bin/printf: illegal option -- s >> usage: printf format [arguments ...] >> make[2]: *** >> [/Users/petebrunet/JDK9/JDK-8034118/jdk9/build/macosx-x86-normal-server-release/jdk/lib/jvm.cfg] >> Error 1 Your "cockpit error" triggered an actual bug in the code that generates jvm.cfg in CopyFiles.gmk. The printf on OSX doesn't like text that starts with -, we need to add the -- flag. Normally an OSX build would not trigger this logic. David >> >> And twice got this: >> >> /Users/petebrunet/JDK9/JDK-8034768/jdk9/jdk/src/macosx/native/sun/awt/LWCToolkit.m:92: >> warning: ivar name ?_runnable? specified on the synthesized property >> ?runnable? not found >> /Users/petebrunet/JDK9/JDK-8034768/jdk9/jdk/src/macosx/native/sun/awt/LWCToolkit.m:92: >> error: synthesized property ?runnable? must either be named the same as >> a compatible ivar or must explicitly name an ivar >> /Users/petebrunet/JDK9/JDK-8034768/jdk9/jdk/src/macosx/native/sun/awt/LWCToolkit.m: >> In function ?__doLoadNativeColors_block_invoke_1?: >> /Users/petebrunet/JDK9/JDK-8034768/jdk9/jdk/src/macosx/native/sun/awt/LWCToolkit.m:288: >> warning: comparison between signed and unsigned >> make[2]: *** >> [/Users/petebrunet/JDK9/JDK-8034768/jdk9/build/macosx-x86-normal-server-release/jdk/objs/libawt_lwawt/LWCToolkit.o] >> Error 1 >> >> >