Re: hsx24 backport: Request for review: 7122222: GC log is limited to 2G for 32-bit
The format of passing cxxflag to a specific file is different in hsx24 than in hsx25. I've changed the setting accordingly in order to pass through the compilation. Please review the new webrev below and ignore webrev.00. hsx24 webrev: http://cr.openjdk.java.net/~tamao/712_hsx24/webrev.01/ (original) hsx25 webrev: http://cr.openjdk.java.net/~tamao/712/webrev.00/ Test: Builds were tested on Linux-i586, Solaris-i586, and Solaris-sparc. Builds were successful and they all passed test of the gc-log size limit of 2G. Thanks. Tao On 7/1/13 1:18 PM, Tao Mao wrote: The hsx25 fix has been pushed already. Then I got the 7u40-critical-approved. When I tried backporting to hsx24, it didn't apply to the hsx24 repo cleanly. Thus, I made the patch manually (copy-and-paste style) and now need some quick reviews to get it in since it's 7u40 related P3 CR. hsx24 webrev: http://cr.openjdk.java.net/~tamao/712_hsx24/webrev.00/ (original) hsx25 webrev: http://cr.openjdk.java.net/~tamao/712/webrev.00/ Thanks. Tao
Re: RFR (XS): Enable new build on Linux/PPC64 (jdk part)
This looks like you have applied a change to configure input files (*.m4) and haven't regenerated configure locally afterwards. The JPRT machines don't have autoconf setup so they can't do it. In this case it looks like one of them, probably the mac, has a faulty version of autoconf that gets picked up. I have seen this happen before on mac. The fix is to execute bash common/autoconf/autogen.sh locally and then resubmit to jprt. You need to have autoconf version 2.67 or newer installed for it to work. /Erik On 2013-07-02 05:48, Vladimir Kozlov wrote: Need help from JDK build experts. I applied next 2 changesets: http://cr.openjdk.java.net/~simonis/webrevs/8017568_toplevel/ http://cr.openjdk.java.net/~simonis/webrevs/8017568_jdk/ and got JPRT build problems (-control build) only on MacOS and Win64: http://bus2001067.us.oracle.com/archives/2013/06/2013-06-28-213927.vkozlov.ppc64_jdk_build_test/ -- macosx_x64_10.7-product (details from log file) ... Warning: The generated configure file contains changes not present in the custom generated file. Running autogen.sh to correct the situation Autoconf found: /usr/bin/autoconf Autoconf-2.67 found: Generating generated-configure.sh with /usr/bin/autoconf /usr/bin/gm4:stdin:187: bad expression in eval: 32 dynamic autom4te: /usr/bin/gm4 failed with exit status: 1 Generating custom generated-configure.sh /usr/bin/gm4:stdin:187: bad expression in eval: 32 dynamic autom4te: /usr/bin/gm4 failed with exit status: 1 -- windows_x64_5.2-fastdebug (details from log file) ... Warning: The generated configure file contains changes not present in the custom generated file. Error: Cannot continue Cannot locate autoconf, unable to correct situation. Please install autoconf and run 'bash autogen.sh' to update the generated files. make: *** [bridge2configure] Error 1 -- Without these changes the output is: Running custom generated-configure.sh configure: Configuration created at Thu Jun 27 16:32:25 EDT 2013. configure: configure script generated at timestamp 1371547939. Thanks, Vladimir On 6/28/13 12:04 AM, Volker Simonis wrote: Ok, that's fine. Could you please let me know when you've verified these changes. I will then push them to the staging repository. Regards, Volker On Thu, Jun 27, 2013 at 7:35 PM, Vladimir Kozlov vladimir.koz...@oracle.com wrote: On 6/27/13 10:16 AM, Iris Clark wrote: Hi, Volker. I think that the right thing for this change [1] is for you to push into ppc-aix-port/stage once you get the necessary reviews (presumably Erik and possibly Alan). While your changeset contains some general purpose updates, it also contains PPC/AIX-specific files which can't be added to a JDK release repository until stage is pushed into the a JDK release. The recommendation to push to stage of course assumes that Vladimir doesn't think that this will adversely affect the Hotspot work already being pushed to stage. This should not affect Hotspot in stage repo. Me or Albert will do JPRT bootstrap control build of jdk with this changes to make sure it works. After that Volker can push it into stage. When I talked about pushing *general* changes into main sources I meant changes with no ppc64 specific code. The example of such changes was recent Goetz's fix for '8017531: 8010460 changes broke bytecodeInterpreter.cpp'. Thanks, Vladimir Thanks, iris [1]: http://cr.openjdk.java.net/~simonis/webrevs/8017568_jdk/ -Original Message- From: Volker Simonis [mailto:volker.simo...@gmail.com] Sent: Thursday, June 27, 2013 9:23 AM To: Erik Joelsson Cc: Kumar Srinivasan; build-dev; ppc-aix-port-...@openjdk.java.net; Alan Bateman Subject: Re: RFR (XS): Enable new build on Linux/PPC64 (jdk part) Hi Erik, we have no polices which are carved in stone:) It's all done informally and by common sense. The main reason for the ppc-aix-port/stage repository is to have a sandbox for in-depth review and testing of changes we had to make in shared code before pushing them to the main repository (and this especially applies to hotspot changes). If you feel comfortable with the current changes and don't think that they will break anything (e.g. by running tests build on your supported platforms including the closed source ones) I'd really appreciate if you could push them to the build repository. Otherwise I'll push them to the staging repository and you'll get them once we're finished with the integration of the port. Thank you and best regards, Volker On Thu, Jun 27, 2013 at 1:51 PM, Erik Joelsson erik.joels...@oracle.com wrote: On 2013-06-27 13:00, Volker Simonis wrote: On Thu, Jun 27, 2013 at 12:16 PM, Erik Joelsson erik.joels...@oracle.com wrote: Hello Volker, I wasn't
Re: RFR (XS): Enable new build on Linux/PPC64 (jdk part)
Hi Erik, thank you for looking into this. On Tue, Jul 2, 2013 at 9:16 AM, Erik Joelsson erik.joels...@oracle.com wrote: This looks like you have applied a change to configure input files (*.m4) and haven't regenerated configure locally afterwards. The JPRT machines don't have autoconf setup so they can't do it. In this case it looks like one of them, probably the mac, has a faulty version of autoconf that gets picked up. I have seen this happen before on mac. Actually, that was my guess as well. On the other hand that's still strange, because my patch also contains an updated 'common/autoconf/generated- configure.sh' and it works on the other platforms (and also locally for me on MacOS X) without regenerating it. I just saw that the mail I wrote yesterday wasn't send to the lists so I quote my assumptions here: ... From your logs I only see that the make process does not find any configuration, but the configuration should have been created by running configure. Then it tries to call configure but doesn't succeed because it says The generated configure file contains changes not present in the custom generated file. That's also strange because my changesets also patch 'common/autoconf/generated- configure.sh' so it should not be re-generated. And finally the build fails because there's not autoconf on Windows and probably because the autoconf on Mac is too old (the checked-in file is generated by autoconf 2.8). I've just synced jdk8/jdk8 and applied the two patches. I could build without any problems on MacOS X 10.8 with the following command line. sh /usr/work/d046063/OpenJDK/ppc-aix-port/stage/configure --with-boot-jdk=path_to/darwinintel64/output/sapjvm_7 --with-target-bits=64 --with-debug-level=release make images LOG=debug Attached you can find the output I get from running configure. Could you please retry one more time? If you still have problems, can you please run configure by hand and post the output. PS: I also saw from your logs that '/usr/bin/make sanity' is called. This also seems strange to me because I think there aren't any sanity targets any more in the new build system. Maybe you have a mismatch between old and new build system? ... Erik, could you please try this locally on Mac or Windows and post you findings. Alternatively, could you please explain post the complete JPRT output and explain what JPRT is trying to do. From Vladimir's log snippets it's hard for me t understand the whole picture. Thank you and best regards, Volker The fix is to execute bash common/autoconf/autogen.sh locally and then resubmit to jprt. You need to have autoconf version 2.67 or newer installed for it to work. /Erik On 2013-07-02 05:48, Vladimir Kozlov wrote: Need help from JDK build experts. I applied next 2 changesets: http://cr.openjdk.java.net/~simonis/webrevs/8017568_toplevel/ http://cr.openjdk.java.net/~simonis/webrevs/8017568_jdk/ and got JPRT build problems (-control build) only on MacOS and Win64: http://bus2001067.us.oracle.com/archives/2013/06/2013-06-28-213927.vkozlov.ppc64_jdk_build_test/ -- macosx_x64_10.7-product (details from log file) ... Warning: The generated configure file contains changes not present in the custom generated file. Running autogen.sh to correct the situation Autoconf found: /usr/bin/autoconf Autoconf-2.67 found: Generating generated-configure.sh with /usr/bin/autoconf /usr/bin/gm4:stdin:187: bad expression in eval: 32 dynamic autom4te: /usr/bin/gm4 failed with exit status: 1 Generating custom generated-configure.sh /usr/bin/gm4:stdin:187: bad expression in eval: 32 dynamic autom4te: /usr/bin/gm4 failed with exit status: 1 -- windows_x64_5.2-fastdebug (details from log file) ... Warning: The generated configure file contains changes not present in the custom generated file. Error: Cannot continue Cannot locate autoconf, unable to correct situation. Please install autoconf and run 'bash autogen.sh' to update the generated files. make: *** [bridge2configure] Error 1 -- Without these changes the output is: Running custom generated-configure.sh configure: Configuration created at Thu Jun 27 16:32:25 EDT 2013. configure: configure script generated at timestamp 1371547939. Thanks, Vladimir On 6/28/13 12:04 AM, Volker Simonis wrote: Ok, that's fine. Could you please let me know when you've verified these changes. I will then push them to the staging repository. Regards, Volker On Thu, Jun 27, 2013 at 7:35 PM, Vladimir Kozlov vladimir.koz...@oracle.com wrote: On 6/27/13 10:16 AM, Iris Clark wrote: Hi, Volker. I think that the right thing for this change [1] is for you to push into ppc-aix-port/stage once you get the necessary reviews (presumably Erik
Re: RFR (XS): Enable new build on Linux/PPC64 (jdk part)
JPRT uses own target to build forest: jprt_build_product: sanity all_product_build http://hg.openjdk.java.net/ppc-aix-port/stage/file/c156084add48/make/jprt.gmk That is why 'make sanity' is called I think. Note the next warning was present in JPRT logs on all platforms: Warning: The generated configure file contains changes not present in the custom generated file. I verified that submitted source common/autoconf/generated-configure.sh is matching file in stage repo plus changes from patch. Hmm, may be the problem is next change in generated-configure.sh: -DATE_WHEN_GENERATED=1371547824 +DATE_WHEN_GENERATED=1372238067 It is date when Volker generated generated-configure.sh but the date of changed .m4 files is when I applied patch which is later. It looks like I need to regenerate generated-configure.sh file myself as Erik said. I will give it a try tomorrow. Vladimir On 7/2/13 12:31 AM, Volker Simonis wrote: Hi Erik, thank you for looking into this. On Tue, Jul 2, 2013 at 9:16 AM, Erik Joelsson erik.joels...@oracle.com wrote: This looks like you have applied a change to configure input files (*.m4) and haven't regenerated configure locally afterwards. The JPRT machines don't have autoconf setup so they can't do it. In this case it looks like one of them, probably the mac, has a faulty version of autoconf that gets picked up. I have seen this happen before on mac. Actually, that was my guess as well. On the other hand that's still strange, because my patch also contains an updated 'common/autoconf/generated- configure.sh' and it works on the other platforms (and also locally for me on MacOS X) without regenerating it. I just saw that the mail I wrote yesterday wasn't send to the lists so I quote my assumptions here: ... From your logs I only see that the make process does not find any configuration, but the configuration should have been created by running configure. Then it tries to call configure but doesn't succeed because it says The generated configure file contains changes not present in the custom generated file. That's also strange because my changesets also patch 'common/autoconf/generated- configure.sh' so it should not be re-generated. And finally the build fails because there's not autoconf on Windows and probably because the autoconf on Mac is too old (the checked-in file is generated by autoconf 2.8). I've just synced jdk8/jdk8 and applied the two patches. I could build without any problems on MacOS X 10.8 with the following command line. sh /usr/work/d046063/OpenJDK/ppc-aix-port/stage/configure --with-boot-jdk=path_to/darwinintel64/output/sapjvm_7 --with-target-bits=64 --with-debug-level=release make images LOG=debug Attached you can find the output I get from running configure. Could you please retry one more time? If you still have problems, can you please run configure by hand and post the output. PS: I also saw from your logs that '/usr/bin/make sanity' is called. This also seems strange to me because I think there aren't any sanity targets any more in the new build system. Maybe you have a mismatch between old and new build system? ... Erik, could you please try this locally on Mac or Windows and post you findings. Alternatively, could you please explain post the complete JPRT output and explain what JPRT is trying to do. From Vladimir's log snippets it's hard for me t understand the whole picture. Thank you and best regards, Volker The fix is to execute bash common/autoconf/autogen.sh locally and then resubmit to jprt. You need to have autoconf version 2.67 or newer installed for it to work. /Erik On 2013-07-02 05:48, Vladimir Kozlov wrote: Need help from JDK build experts. I applied next 2 changesets: http://cr.openjdk.java.net/~simonis/webrevs/8017568_toplevel/ http://cr.openjdk.java.net/~simonis/webrevs/8017568_jdk/ and got JPRT build problems (-control build) only on MacOS and Win64: http://bus2001067.us.oracle.com/archives/2013/06/2013-06-28-213927.vkozlov.ppc64_jdk_build_test/ -- macosx_x64_10.7-product (details from log file) ... Warning: The generated configure file contains changes not present in the custom generated file. Running autogen.sh to correct the situation Autoconf found: /usr/bin/autoconf Autoconf-2.67 found: Generating generated-configure.sh with /usr/bin/autoconf /usr/bin/gm4:stdin:187: bad expression in eval: 32 dynamic autom4te: /usr/bin/gm4 failed with exit status: 1 Generating custom generated-configure.sh /usr/bin/gm4:stdin:187: bad expression in eval: 32 dynamic autom4te: /usr/bin/gm4 failed with exit status: 1 -- windows_x64_5.2-fastdebug (details from log file) ... Warning: The generated configure file contains changes not present in the custom generated file. Error: Cannot continue Cannot locate autoconf, unable to correct situation. Please install
Re: RFR (XS): Enable new build on Linux/PPC64 (jdk part)
On Tue, Jul 2, 2013 at 9:56 AM, Vladimir Kozlov vladimir.koz...@oracle.com wrote: JPRT uses own target to build forest: jprt_build_product: sanity all_product_build http://hg.openjdk.java.net/ppc-aix-port/stage/file/c156084add48/make/jprt.gmk That is why 'make sanity' is called I think. Note the next warning was present in JPRT logs on all platforms: Warning: The generated configure file contains changes not present in the custom generated file. I verified that submitted source common/autoconf/generated-configure.sh is matching file in stage repo plus changes from patch. Hmm, may be the problem is next change in generated-configure.sh: -DATE_WHEN_GENERATED=1371547824 +DATE_WHEN_GENERATED=1372238067 It is date when Volker generated generated-configure.sh but the date of changed .m4 files is when I applied patch which is later. It looks like I need to regenerate generated-configure.sh file myself as Erik said. I will give it a try tomorrow. I doubt that that's the only reason, because I did exactly the same yesterday on MacOS without these problems: - clone jdk8/jdk8 - import the patches into the base and jdk repositroy - configure - make Is there a way I can simulate a JPRT build? If I just call 'make jprt_build_product' in the build directory where I have previously called 'configure' it fails because it wants to call configure again and doesn't find it. So from which directory am I supposed to start a JPRT build and which parameters should I pass to it? Vladimir On 7/2/13 12:31 AM, Volker Simonis wrote: Hi Erik, thank you for looking into this. On Tue, Jul 2, 2013 at 9:16 AM, Erik Joelsson erik.joels...@oracle.com wrote: This looks like you have applied a change to configure input files (*.m4) and haven't regenerated configure locally afterwards. The JPRT machines don't have autoconf setup so they can't do it. In this case it looks like one of them, probably the mac, has a faulty version of autoconf that gets picked up. I have seen this happen before on mac. Actually, that was my guess as well. On the other hand that's still strange, because my patch also contains an updated 'common/autoconf/generated- configure.sh' and it works on the other platforms (and also locally for me on MacOS X) without regenerating it. I just saw that the mail I wrote yesterday wasn't send to the lists so I quote my assumptions here: ... From your logs I only see that the make process does not find any configuration, but the configuration should have been created by running configure. Then it tries to call configure but doesn't succeed because it says The generated configure file contains changes not present in the custom generated file. That's also strange because my changesets also patch 'common/autoconf/generated- configure.sh' so it should not be re-generated. And finally the build fails because there's not autoconf on Windows and probably because the autoconf on Mac is too old (the checked-in file is generated by autoconf 2.8). I've just synced jdk8/jdk8 and applied the two patches. I could build without any problems on MacOS X 10.8 with the following command line. sh /usr/work/d046063/OpenJDK/ppc-aix-port/stage/configure --with-boot-jdk=path_to/darwinintel64/output/sapjvm_7 --with-target-bits=64 --with-debug-level=release make images LOG=debug Attached you can find the output I get from running configure. Could you please retry one more time? If you still have problems, can you please run configure by hand and post the output. PS: I also saw from your logs that '/usr/bin/make sanity' is called. This also seems strange to me because I think there aren't any sanity targets any more in the new build system. Maybe you have a mismatch between old and new build system? ... Erik, could you please try this locally on Mac or Windows and post you findings. Alternatively, could you please explain post the complete JPRT output and explain what JPRT is trying to do. From Vladimir's log snippets it's hard for me t understand the whole picture. Thank you and best regards, Volker The fix is to execute bash common/autoconf/autogen.sh locally and then resubmit to jprt. You need to have autoconf version 2.67 or newer installed for it to work. /Erik On 2013-07-02 05:48, Vladimir Kozlov wrote: Need help from JDK build experts. I applied next 2 changesets: http://cr.openjdk.java.net/~simonis/webrevs/8017568_toplevel/ http://cr.openjdk.java.net/~simonis/webrevs/8017568_jdk/ and got JPRT build problems (-control build) only on MacOS and Win64: http://bus2001067.us.oracle.com/archives/2013/06/2013-06-28-213927.vkozlov.ppc64_jdk_build_test/ -- macosx_x64_10.7-product (details from log file) ... Warning: The generated configure file contains changes not present in the custom generated file. Running autogen.sh to correct the situation Autoconf
RFR: 8019537: jdk8-build prebuild fails in source bundle generation, The path of TOOLS_DIR ... is not found
Please review this fix for the --with-tools-dir configure parameter. In 8017047: Can't use --with-java-devtools and --with-devkit at the same time, I carelessly added BASIC_FIXUP_PATH to both --with-tools-dir and --with-devkit, with the intention of adding support for relative paths. This doesn't work for --with-tools-dir however, since this parameter is supposed to handle a colon separated path string, containing multiple paths. This fix removes that call, restoring the old functionality of --with-tools-dir. http://cr.openjdk.java.net/~erikj/8019537/webrev.root.01/ /Erik
Re: RFR (XS): Enable new build on Linux/PPC64 (jdk part)
Ah, now I got it! The problem is with your closed sources which also have their own closed, autoconf-generated config file which has to be recreated after the OpenJDK autoconf-generated configure files changes. The warning Warning: The generated configure file contains changes not present in the custom generated file. from 'common/autoconf/configure:' actually checks exactly that: if test -e $conf_custom_script_dir/generated-configure.sh; then # Test if open configure is newer than custom configure, if so, custom needs to # be regenerated. This test is required to ensure consistency with custom source. conf_open_configure_timestamp=`grep DATE_WHEN_GENERATED= $conf_script_dir/generated-configure.sh | cut -d= -f 2` conf_custom_configure_timestamp=`grep DATE_WHEN_GENERATED= $conf_custom_script_dir/generated-configure.sh | cut -d= -f 2` if test $conf_open_configure_timestamp -gt $conf_custom_configure_timestamp; then echo Warning: The generated configure file contains changes not present in the custom generated file. run_autogen_or_fail fi fi I obviously can not fix that:) But if you've already done a successful build on any other platform, you can just copy the generated '$conf_custom_script_dir/generated-configure.sh' from that build into you workspace and that should do the job! Very nasty Closedsource/JPRT problems:( When will we finally overcome this mess... Regards, Volker On Tue, Jul 2, 2013 at 10:42 AM, Volker Simonis volker.simo...@gmail.com wrote: On Tue, Jul 2, 2013 at 9:56 AM, Vladimir Kozlov vladimir.koz...@oracle.com wrote: JPRT uses own target to build forest: jprt_build_product: sanity all_product_build http://hg.openjdk.java.net/ppc-aix-port/stage/file/c156084add48/make/jprt.gmk That is why 'make sanity' is called I think. Note the next warning was present in JPRT logs on all platforms: Warning: The generated configure file contains changes not present in the custom generated file. I verified that submitted source common/autoconf/generated-configure.sh is matching file in stage repo plus changes from patch. Hmm, may be the problem is next change in generated-configure.sh: -DATE_WHEN_GENERATED=1371547824 +DATE_WHEN_GENERATED=1372238067 It is date when Volker generated generated-configure.sh but the date of changed .m4 files is when I applied patch which is later. It looks like I need to regenerate generated-configure.sh file myself as Erik said. I will give it a try tomorrow. I doubt that that's the only reason, because I did exactly the same yesterday on MacOS without these problems: - clone jdk8/jdk8 - import the patches into the base and jdk repositroy - configure - make Is there a way I can simulate a JPRT build? If I just call 'make jprt_build_product' in the build directory where I have previously called 'configure' it fails because it wants to call configure again and doesn't find it. So from which directory am I supposed to start a JPRT build and which parameters should I pass to it? Vladimir On 7/2/13 12:31 AM, Volker Simonis wrote: Hi Erik, thank you for looking into this. On Tue, Jul 2, 2013 at 9:16 AM, Erik Joelsson erik.joels...@oracle.com wrote: This looks like you have applied a change to configure input files (*.m4) and haven't regenerated configure locally afterwards. The JPRT machines don't have autoconf setup so they can't do it. In this case it looks like one of them, probably the mac, has a faulty version of autoconf that gets picked up. I have seen this happen before on mac. Actually, that was my guess as well. On the other hand that's still strange, because my patch also contains an updated 'common/autoconf/generated- configure.sh' and it works on the other platforms (and also locally for me on MacOS X) without regenerating it. I just saw that the mail I wrote yesterday wasn't send to the lists so I quote my assumptions here: ... From your logs I only see that the make process does not find any configuration, but the configuration should have been created by running configure. Then it tries to call configure but doesn't succeed because it says The generated configure file contains changes not present in the custom generated file. That's also strange because my changesets also patch 'common/autoconf/generated- configure.sh' so it should not be re-generated. And finally the build fails because there's not autoconf on Windows and probably because the autoconf on Mac is too old (the checked-in file is generated by autoconf 2.8). I've just synced jdk8/jdk8 and applied the two patches. I could build without any problems on MacOS X 10.8 with the following command line. sh /usr/work/d046063/OpenJDK/ppc-aix-port/stage/configure --with-boot-jdk=path_to/darwinintel64/output/sapjvm_7 --with-target-bits=64 --with-debug-level=release make images LOG=debug Attached you can find the output I get from running configure. Could you please retry one more time? If
Re: RFR: 8019537: jdk8-build prebuild fails in source bundle generation, The path of TOOLS_DIR ... is not found
Hi Erik: Please review this fix for the --with-tools-dir configure parameter. In 8017047: Can't use --with-java-devtools and --with-devkit at the same time, I carelessly added BASIC_FIXUP_PATH to both --with-tools-dir and --with-devkit, with the intention of adding support for relative paths. This doesn't work for --with-tools-dir however, since this parameter is supposed to handle a colon separated path string, containing multiple paths. This fix removes that call, restoring the old functionality of --with-tools-dir. http://cr.openjdk.java.net/~erikj/8019537/webrev.root.01 Looks good to me. Tim
Re: hsx24 backport: Request for review: 7122222: GC log is limited to 2G for 32-bit
The format of passing cxxflag to a specific file is different in hsx24 than in hsx25. I've changed the setting accordingly in order to pass through the compilation. Please review the new webrev below and ignore webrev.00. hsx24 webrev: http://cr.openjdk.java.net/~tamao/712_hsx24/webrev.01/ (original) hsx25 webrev: http://cr.openjdk.java.net/~tamao/712/webrev.00/ Test: Builds were tested on Linux-i586, Solaris-i586, and Solaris-sparc. Builds were successful and they all passed test of the gc-log size limit of 2G. Passed JPRT. Thanks. Tao On 7/1/13 1:18 PM, Tao Mao wrote: The hsx25 fix has been pushed already. Then I got the 7u40-critical-approved. When I tried backporting to hsx24, it didn't apply to the hsx24 repo cleanly. Thus, I made the patch manually (copy-and-paste style) and now need some quick reviews to get it in since it's 7u40 related P3 CR. hsx24 webrev: http://cr.openjdk.java.net/~tamao/712_hsx24/webrev.00/ (original) hsx25 webrev: http://cr.openjdk.java.net/~tamao/712/webrev.00/ Thanks. Tao
Re: RFR: 8019537: jdk8-build prebuild fails in source bundle generation, The path of TOOLS_DIR ... is not found
On Jul 2, 2013, at 1:54 AM, Erik Joelsson erik.joels...@oracle.com wrote: Please review this fix for the --with-tools-dir configure parameter. In 8017047: Can't use --with-java-devtools and --with-devkit at the same time, I carelessly added BASIC_FIXUP_PATH to both --with-tools-dir and --with-devkit, with the intention of adding support for relative paths. This doesn't work for --with-tools-dir however, since this parameter is supposed to handle a colon separated path string, containing multiple paths. This fix removes that call, restoring the old functionality of --with-tools-dir. http://cr.openjdk.java.net/~erikj/8019537/webrev.root.01/ Fix looks correct, approved. Let me know when you've integrated and I'll restart the build forest build. Thanks Dave
hg: jdk8/build: 8019537: jdk8-build prebuild fails in source bundle generation, The path of TOOLS_DIR ... is not found
Changeset: b2b87e9e8683 Author:erikj Date: 2013-07-02 15:07 +0200 URL: http://hg.openjdk.java.net/jdk8/build/rev/b2b87e9e8683 8019537: jdk8-build prebuild fails in source bundle generation, The path of TOOLS_DIR ... is not found Reviewed-by: tbell ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh
Re: hsx24 backport: Request for review: 7122222: GC log is limited to 2G for 32-bit
Tao Mao (tao@oracle.com) wrote: The hsx25 fix has been pushed already. Then I got the 7u40-critical-approved. When I tried backporting to hsx24, it didn't apply to the hsx24 repo cleanly. Thus, I made the patch manually (copy-and-paste style) and now need some quick reviews to get it in since it's 7u40 related P3 CR. hsx24 webrev: http://cr.openjdk.java.net/~tamao/712_hsx24/webrev.00/ (original) hsx25 webrev: http://cr.openjdk.java.net/~tamao/712/webrev.00/ This looks good to me. -John
Re: Fwd: Re: hsx24 backport: Request for review: 7122222: GC log is limited to 2G for 32-bit
Thank you for review, Dan. Tao On 7/2/13 1:32 PM, Daniel D. Daugherty wrote: Adding hotspot-runtime-...@openjdk.java.net to this thread... http://cr.openjdk.java.net/~tamao/712_hsx24/webrev.01/ make/linux/makefiles/vm.make No comments. make/solaris/makefiles/vm.make No comments. src/os/solaris/vm/os_solaris.inline.hpp No comments. Also compared the two patch files: 712GCLogLimitedTo2GFor32Bit_hsx24.patch 712GCLogLimitedTo2GFor32Bit.patch In HSX-25, the Makefile construct looks like: CXXFLAGS/ostream.o += -D_FILE_OFFSET_BITS=64 In HSX-24, the Makefile construct looks like: ostream.o: CXXFLAGS += -D_FILE_OFFSET_BITS=64 which threw me for a loop for a minute... I realized that your construct matches the existing rules for vm_version.o in each release so I think the HSX-24 backport is good. I should've mentioned the point that I just would like to keep consistency with the existing way of passing cxxflag to vm_version.o in order to make the changeset simple to come up. Hopefully, you double checked builds logs on both Linux and Solaris and made sure that '-D_FILE_OFFSET_BITS=64' is only passed where you expect it. Yes, it is only passed -D_FILE_OFFSET_BITS=64 to ostream.o As I mentioned, the changeset passed JPRT. Also, I manually tested whether the change would solve the CR's problem as expected. It's doing its right job on Linux-i586, Solaris-i586 and Solaris-sparc. Thumbs up! Dan Original Message Subject: Re: hsx24 backport: Request for review: 712: GC log is limited to 2G for 32-bit Date: Mon, 01 Jul 2013 23:05:46 -0700 From: Tao Mao tao@oracle.com Organization: Oracle Corporation To: hotspot-gc-...@openjdk.java.net hotspot-gc-...@openjdk.java.net, build-dev@openjdk.java.net The format of passing cxxflag to a specific file is different in hsx24 than in hsx25. I've changed the setting accordingly in order to pass through the compilation. Please review the new webrev below and ignore webrev.00. hsx24 webrev: http://cr.openjdk.java.net/~tamao/712_hsx24/webrev.01/ (original) hsx25 webrev: http://cr.openjdk.java.net/~tamao/712/webrev.00/ Test: Builds were tested on Linux-i586, Solaris-i586, and Solaris-sparc. Builds were successful and they all passed test of the gc-log size limit of 2G. Thanks. Tao On 7/1/13 1:18 PM, Tao Mao wrote: The hsx25 fix has been pushed already. Then I got the 7u40-critical-approved. When I tried backporting to hsx24, it didn't apply to the hsx24 repo cleanly. Thus, I made the patch manually (copy-and-paste style) and now need some quick reviews to get it in since it's 7u40 related P3 CR. hsx24 webrev: http://cr.openjdk.java.net/~tamao/712_hsx24/webrev.00/ (original) hsx25 webrev: http://cr.openjdk.java.net/~tamao/712/webrev.00/ Thanks. Tao
hg: jdk8/build/corba: Added tag jdk8-b96 for changeset 3357c2776431
Changeset: 469995a8e974 Author:katleman Date: 2013-06-27 13:40 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/469995a8e974 Added tag jdk8-b96 for changeset 3357c2776431 ! .hgtags
hg: jdk8/build/hotspot: 26 new changesets
Changeset: b6d1e42655cd Author:katleman Date: 2013-06-27 13:40 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b6d1e42655cd Added tag jdk8-b96 for changeset e6a4b8c71fa6 ! .hgtags Changeset: fc8a1a5de78e Author:amurillo Date: 2013-06-21 00:59 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/fc8a1a5de78e 8017253: new hotspot build - hs25-b39 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 91acb82a8b7a Author:dholmes Date: 2013-06-19 13:14 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/91acb82a8b7a 8014326: [OSX] All libjvm symbols are exported Summary: Add support for a MacOS X compatible form of the libjvm mapfile. Reviewed-by: dcubed, rdurbin, coleenp ! make/bsd/makefiles/build_vm_def.sh ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product Changeset: b9f4c4ec0f50 Author:iklam Date: 2013-06-19 20:51 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b9f4c4ec0f50 8008964: NPG: Memory regression: Thread::_metadata_handles uses 1 KB per thread. Summary: Reduce default size of Thread::_metadata_handles from 300 to 30 Reviewed-by: coleenp, sspitsyn ! src/share/vm/runtime/thread.cpp Changeset: b3cd8b58b798 Author:mgronlun Date: 2013-06-20 11:53 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b3cd8b58b798 8016735: Remove superfluous EnableInvokeDynamic warning from UnlockDiagnosticVMOptions check Reviewed-by: sla, dholmes ! src/share/vm/runtime/globals.cpp Changeset: 9ba41a4a71ff Author:coleenp Date: 2013-06-21 10:50 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9ba41a4a71ff 8004124: Handle and/or warn about SI_KERNEL Summary: Detect this crash in the signal handler and give a fatal error message instead of making us chase down bugs that don't reproduce Reviewed-by: kvn, mgerdin, dholmes ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: bed34a7a3b9b Author:coleenp Date: 2013-06-21 10:57 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/bed34a7a3b9b 8017177: more explicit code location information in hs_err crash log Summary: Add code pc location for compiled code Reviewed-by: kvn, coleenp Contributed-by: doug.si...@oracle.com ! src/share/vm/runtime/frame.cpp Changeset: bb6c7f2f10fd Author:dcubed Date: 2013-06-21 08:18 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/bb6c7f2f10fd Merge Changeset: b7bc7c94b4b5 Author:dcubed Date: 2013-06-21 10:55 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b7bc7c94b4b5 Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp Changeset: d9eed26d638a Author:iklam Date: 2013-06-23 22:08 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d9eed26d638a 8009575: Reduce Symbol::_refcount from 4 bytes to 2 bytes Summary: Added Atomic::inc(short*) to support this change. Reviewed-by: coleenp, dcubed, dholmes, minqi ! src/share/vm/oops/symbol.cpp ! src/share/vm/oops/symbol.hpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/atomic.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: e0c9a1d29eb4 Author:coleenp Date: 2013-06-24 18:55 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e0c9a1d29eb4 8016325: JVM hangs verifying system dictionary Summary: Minimize redundant verifications of Klasses. Reviewed-by: hseigel, jmasa ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/code/debugInfo.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/compiledICHolder.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/shark/sharkBuilder.cpp Changeset: 01e10b366055 Author:sla Date: 2013-06-25 14:11 +0200 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/01e10b366055 8017561: Build errors caused by missing .PHONY Reviewed-by: stefank, brutisso ! make/excludeSrc.make Changeset: feae15578b2f Author:tamao Date: 2013-06-07 09:46 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/feae15578b2f 712: GC log is limited to 2G for 32-bit Summary: Enable large file support for generated 32-bit ostream.o
hg: jdk8/build/jaxws: Added tag jdk8-b96 for changeset 690d34b326bc
Changeset: dcde7f049111 Author:katleman Date: 2013-06-27 13:40 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/dcde7f049111 Added tag jdk8-b96 for changeset 690d34b326bc ! .hgtags
hg: jdk8/build/jdk: 3 new changesets
Changeset: 2f1386fc2079 Author:katleman Date: 2013-06-27 13:40 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/2f1386fc2079 Added tag jdk8-b96 for changeset 4a5d3cf2b3af ! .hgtags Changeset: 8339c83b16c6 Author:ehelin Date: 2013-07-02 13:06 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/8339c83b16c6 8019500: Exclude MemoryTest.java and MemoryTestAllGC.sh to enable integration Reviewed-by: erikj, alanb ! test/ProblemList.txt Changeset: 978a95239044 Author:katleman Date: 2013-07-02 15:55 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/978a95239044 Merge
hg: jdk8/build/nashorn: Added tag jdk8-b96 for changeset d6bd440ac5b9
Changeset: 1bf1d6ce3042 Author:katleman Date: 2013-06-27 13:40 -0700 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/1bf1d6ce3042 Added tag jdk8-b96 for changeset d6bd440ac5b9 ! .hgtags
hg: jdk8/build/langtools: Added tag jdk8-b96 for changeset 988aef3a8c3a
Changeset: 6a11a81a8824 Author:katleman Date: 2013-06-27 13:40 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/6a11a81a8824 Added tag jdk8-b96 for changeset 988aef3a8c3a ! .hgtags
hg: jdk8/build: 2 new changesets
Changeset: 4c363b94ea2a Author:katleman Date: 2013-06-27 13:40 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/4c363b94ea2a Added tag jdk8-b96 for changeset c156084add48 ! .hgtags Changeset: a1c1e8bf71f3 Author:katleman Date: 2013-07-02 15:55 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/a1c1e8bf71f3 Merge
Re: RFR (XS): Enable new build on Linux/PPC64 (jdk part)
Running autogen.sh in top directory updates both files: $ bash common/autoconf/autogen.sh Autoconf found: /usr/local/bin/autoconf Autoconf-2.67 found: Generating generated-configure.sh with /usr/local/bin/autoconf Generating custom generated-configure.sh Test builds are running (and already passed on MacOS and Linux) so I think the problem is solved. Thank you, Erik and Volker. I will push (since we need to push closed part too) changesets into ppc-aix-port/stage repository with Erik as reviewer. Thanks, Vladimir On 7/2/13 1:54 AM, Volker Simonis wrote: Ah, now I got it! The problem is with your closed sources which also have their own closed, autoconf-generated config file which has to be recreated after the OpenJDK autoconf-generated configure files changes. The warning Warning: The generated configure file contains changes not present in the custom generated file. from 'common/autoconf/configure:' actually checks exactly that: if test -e $conf_custom_script_dir/generated-configure.sh; then # Test if open configure is newer than custom configure, if so, custom needs to # be regenerated. This test is required to ensure consistency with custom source. conf_open_configure_timestamp=`grep DATE_WHEN_GENERATED= $conf_script_dir/generated-configure.sh | cut -d= -f 2` conf_custom_configure_timestamp=`grep DATE_WHEN_GENERATED= $conf_custom_script_dir/generated-configure.sh | cut -d= -f 2` if test $conf_open_configure_timestamp -gt $conf_custom_configure_timestamp; then echo Warning: The generated configure file contains changes not present in the custom generated file. run_autogen_or_fail fi fi I obviously can not fix that:) But if you've already done a successful build on any other platform, you can just copy the generated '$conf_custom_script_dir/generated-configure.sh' from that build into you workspace and that should do the job! Very nasty Closedsource/JPRT problems:( When will we finally overcome this mess... Regards, Volker On Tue, Jul 2, 2013 at 10:42 AM, Volker Simonis volker.simo...@gmail.com mailto:volker.simo...@gmail.com wrote: On Tue, Jul 2, 2013 at 9:56 AM, Vladimir Kozlov vladimir.koz...@oracle.com mailto:vladimir.koz...@oracle.com wrote: JPRT uses own target to build forest: jprt_build_product: sanity all_product_build http://hg.openjdk.java.net/ppc-aix-port/stage/file/c156084add48/make/jprt.gmk That is why 'make sanity' is called I think. Note the next warning was present in JPRT logs on all platforms: Warning: The generated configure file contains changes not present in the custom generated file. I verified that submitted source common/autoconf/generated-configure.sh is matching file in stage repo plus changes from patch. Hmm, may be the problem is next change in generated-configure.sh: -DATE_WHEN_GENERATED=1371547824 +DATE_WHEN_GENERATED=1372238067 It is date when Volker generated generated-configure.sh but the date of changed .m4 files is when I applied patch which is later. It looks like I need to regenerate generated-configure.sh file myself as Erik said. I will give it a try tomorrow. I doubt that that's the only reason, because I did exactly the same yesterday on MacOS without these problems: - clone jdk8/jdk8 - import the patches into the base and jdk repositroy - configure - make Is there a way I can simulate a JPRT build? If I just call 'make jprt_build_product' in the build directory where I have previously called 'configure' it fails because it wants to call configure again and doesn't find it. So from which directory am I supposed to start a JPRT build and which parameters should I pass to it? Vladimir On 7/2/13 12:31 AM, Volker Simonis wrote: Hi Erik, thank you for looking into this. On Tue, Jul 2, 2013 at 9:16 AM, Erik Joelsson erik.joels...@oracle.com mailto:erik.joels...@oracle.com wrote: This looks like you have applied a change to configure input files (*.m4) and haven't regenerated configure locally afterwards. The JPRT machines don't have autoconf setup so they can't do it. In this case it looks like one of them, probably the mac, has a faulty version of autoconf that gets picked up. I have seen this happen before on mac. Actually, that was my guess as well. On the other hand that's still strange, because my patch also contains an updated 'common/autoconf/generated- configure.sh' and it works on the other platforms (and also locally for me on MacOS X) without regenerating it. I just saw that the mail I wrote yesterday wasn't send to the lists so I quote my assumptions here: ... From your logs I only see that the make process does not find any configuration, but the configuration should have been created by running configure. Then it tries to call configure but doesn't succeed because it says The generated configure file contains changes not present in the custom generated
