Re: RFR: 8025612: rt.jar still has old specification value in the manifest
On 2013-10-11 20:14, Bradford Wetmore wrote: As the submitter, I also agree with this part of the fix and all comments made here. ;) Erik, one thing I did not check is whether other .jars in j2re/j2sdk use a different manifest template than the one you modified. Have you checked them all? I could not find any other manifests and greping for Specification-Version did not give me any other hits. There are jars that do not specify this attribute, for example nashorn, but I assume they don't count. /Erik You do not need to check these .jars, they will be updated shortly. ./ec/sunec.jar ./jce/jce.jar ./jce/local_policy.jar ./jce/sunjce_provider.jar ./jce/US_export_policy.jar ./mscapi/sunmscapi.jar ./pkcs11/sunpkcs11.jar ./ucrypto/ucrypto.jar I only noticed this when upgrading the JCE build to use the new build-infra, and noticed my JCE jar files still had 1.7, which meant the others had the same problem. (Alan...I was close to throwing the JCE new build-infra switch when we discovered RE has different build output format, and then got a couple small P1's yesterdays.) Brad On 10/11/2013 7:09 AM, Tim Bell wrote: Erik: Please review this small change, updating the specification version in the manifest of the jar files. Posted diff inline since it's so small. I couldn't find anywhere else where this would need changing, but if anyone knows of somewhere, please speak up. /Erik diff -r 98d98ec01f07 make/tools/manifest.mf --- a/make/tools/manifest.mf +++ b/make/tools/manifest.mf @@ -1,6 +1,6 @@ Manifest-Version: 1.0 Specification-Title: Java Platform API Specification -Specification-Version: 1.7 +Specification-Version: 1.8 Specification-Vendor: Oracle Corporation Implementation-Title: Java Runtime Environment Implementation-Version: @@RELEASE@@ https://bugs.openjdk.java.net/browse/JDK-8025612 Looks good. /Tim
Re: X509CertImpl.java compilation error on linux-x86
I have seen this before and filed this bug. It's currently the main stopper for making sjavac default. https://bugs.openjdk.java.net/browse/JDK-8025702 /Erik On 2013-10-11 23:00, Dmitry Samersoff wrote: Brad, Thank you for greet idea. sjavac might be a culprit. -Dmitry On 2013-10-11 22:23, Bradford Wetmore wrote: Offhand, no idea. Instance lives in sun.security.getInstance, and you're finding that class. I haven't tried out sjavac, but given the warning build/linux-x86-normal-server-release/jdk/classes/javac_state, and that I've never seen this directory, might you be triggering a sjavac bug? If you simply need to build, I might suggest cleaning your JDK build and trying again (without sjavac). Brad On 10/11/2013 6:02 AM, Dmitry Samersoff wrote: Hi Everyone, I get weird error trying to compile latest hotspot-rt on linux-x86, I suspect something is wrong wit my machine setup, because the same workspace on linux-x64 compiles fine. Any idea what is happening? ## Starting jdk Compiling BUILD_JDK Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/home/dms/ESC/JDK-8025812/hotspot-rt/jdk/src/share/classes/sun/security/x509/X509CertImpl.java:436: error: cannot access Instance sigVerf = Signature.getInstance(algId.getName(), sigProvider); ^ class file for sun.security.jca.GetInstance$Instance not found /usr/home/dms/ESC/JDK-8025812/hotspot-rt/jdk/src/share/classes/sun/security/jca/GetInstance.java:238: error: cannot find symbol return new Instance(s.getProvider(), instance); ^ symbol: class Instance location: class GetInstance /usr/home/dms/ESC/JDK-8025812/hotspot-rt/jdk/src/share/classes/sun/security/jca/GetInstance.java:245: error: cannot find symbol return new Instance(s.getProvider(), instance); ^ symbol: class Instance location: class GetInstance 3 errors gmake[2]: *** [/usr/home/dms/ESC/JDK-8025812/hotspot-rt/build/linux-x86-normal-server-release/jdk/classes/javac_state] Error 255 -Dmitry
Re: RFR: JDK -8001933 Move Gensrc*.gmk and Gendata*.gmk into separate directories
On 2013-10-11 20:18, Magnus Ihse Bursie wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8001933 In the makefiles directory in the jdk repo, there are a lot of files -- important files, and lot of small helper files. Many of them share a common filename prefix; however, there is a better kind of namespaces to show hierarchy in file systems: directories! :-) This fix moves all the Gensrc* files into the gensrc directory, and all the Gendata* into the gendata directory. The result is a clearer picture of the overall structure of the JDK build system. WebRev: http://cr.openjdk.java.net/~ihse/JDK-8001933-move-gensrc-and-gendata/webrev.01 In private communication, Erik suggested that we take this opportunity to rename GenerateJavaSources.gmk to GenerateSources.gmk, since it's actually more accurate (we are generating other kinds of sources, not only Java source code). Updated WebRev: http://cr.openjdk.java.net/~ihse/JDK-8001933-move-gensrc-and-gendata/webrev.02 /Magnus
Re: RFR: JDK -8001933 Move Gensrc*.gmk and Gendata*.gmk into separate directories
I'm in favor of this change and it looks good to me. /Erik On 2013-10-14 10:07, Magnus Ihse Bursie wrote: On 2013-10-11 20:18, Magnus Ihse Bursie wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8001933 In the makefiles directory in the jdk repo, there are a lot of files -- important files, and lot of small helper files. Many of them share a common filename prefix; however, there is a better kind of namespaces to show hierarchy in file systems: directories! :-) This fix moves all the Gensrc* files into the gensrc directory, and all the Gendata* into the gendata directory. The result is a clearer picture of the overall structure of the JDK build system. WebRev: http://cr.openjdk.java.net/~ihse/JDK-8001933-move-gensrc-and-gendata/webrev.01 In private communication, Erik suggested that we take this opportunity to rename GenerateJavaSources.gmk to GenerateSources.gmk, since it's actually more accurate (we are generating other kinds of sources, not only Java source code). Updated WebRev: http://cr.openjdk.java.net/~ihse/JDK-8001933-move-gensrc-and-gendata/webrev.02 /Magnus
Re: X509CertImpl.java compilation error on linux-x86
Erik, Thank you! -Dmitry On 2013-10-14 11:50, Erik Joelsson wrote: I have seen this before and filed this bug. It's currently the main stopper for making sjavac default. https://bugs.openjdk.java.net/browse/JDK-8025702 /Erik On 2013-10-11 23:00, Dmitry Samersoff wrote: Brad, Thank you for greet idea. sjavac might be a culprit. -Dmitry On 2013-10-11 22:23, Bradford Wetmore wrote: Offhand, no idea. Instance lives in sun.security.getInstance, and you're finding that class. I haven't tried out sjavac, but given the warning build/linux-x86-normal-server-release/jdk/classes/javac_state, and that I've never seen this directory, might you be triggering a sjavac bug? If you simply need to build, I might suggest cleaning your JDK build and trying again (without sjavac). Brad On 10/11/2013 6:02 AM, Dmitry Samersoff wrote: Hi Everyone, I get weird error trying to compile latest hotspot-rt on linux-x86, I suspect something is wrong wit my machine setup, because the same workspace on linux-x64 compiles fine. Any idea what is happening? ## Starting jdk Compiling BUILD_JDK Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/home/dms/ESC/JDK-8025812/hotspot-rt/jdk/src/share/classes/sun/security/x509/X509CertImpl.java:436: error: cannot access Instance sigVerf = Signature.getInstance(algId.getName(), sigProvider); ^ class file for sun.security.jca.GetInstance$Instance not found /usr/home/dms/ESC/JDK-8025812/hotspot-rt/jdk/src/share/classes/sun/security/jca/GetInstance.java:238: error: cannot find symbol return new Instance(s.getProvider(), instance); ^ symbol: class Instance location: class GetInstance /usr/home/dms/ESC/JDK-8025812/hotspot-rt/jdk/src/share/classes/sun/security/jca/GetInstance.java:245: error: cannot find symbol return new Instance(s.getProvider(), instance); ^ symbol: class Instance location: class GetInstance 3 errors gmake[2]: *** [/usr/home/dms/ESC/JDK-8025812/hotspot-rt/build/linux-x86-normal-server-release/jdk/classes/javac_state] Error 255 -Dmitry -- 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.
Re: [7u]: ERROR: Trouble with the absolute path for OUTPUTDIR './bui, ld/windows-i586'. Stop.
Hi, On 10/14/2013 09:58 AM, Francis ANDRE wrote: Hi Just cloning this repository http://hg.openjdk.java.net/jdk7u/jdk7u to a fresh new directory on a WXP/Cygwin platform with the following ALT_* variables $ env | grep ALT ALT_BOOTDIR=C:/Progra~1/Java/jdk1.7.0_40 ALT_SLASH_JAVA=C:/Progra~1/Java/jdk1.7.0_40 ALT_JDK_IMPORT_PATH=C:/Progra~1/Java/jdk1.7.0_40 ALT_FREETYPE_HEADERS_PATH=C:/Cygwin/OpenJDK/freetype-2.4.7/include ALT_FREETYPE_LIB_PATH=C:/Cygwin/OpenJDK/freetype-2.4.7/objs/win32/vc2010 ALT_DXSDK_PATH=C:/PROGRA~1/MI7482~1 FREETYPE2_LIB_PATH=C:/Cygwin/OpenJDK/freetype-2.4.7/objs/win32/vc2010 FrancisANDRE@idefix /cygdrive/Z/JDK/jdk7u $ make sanity jdk/make/common/shared/Defs.gmk:559: *** ERROR: Trouble with the absolute path for OUTPUTDIR './bui ld/windows-i586'. Stop. My understanding is that there is no need to specify the ALT_OUTPUTDIR but it seems to be needed by make sanity. Did I miss something? I never encountered this error, what is the path to openjdk sourcedir, does it contain spaces or long names? ALT_OUTPUTDIR is not needed for build, OUTPUTDIR points to openjdk/build/windows-i586 by default. I am using the following script for windows-i586, it's for winsdk7.1 (vs2010 one should be very similar), you may find more details in my github account: @echo off rem unset variables set LD_LIBRARY_PATH= set CLASSPATH= set JAVA_HOME= rem shortcuts from script directory set BAD_SLASH_SCRIPT_DIR=%~dp0 set SCRIPT_DIR=%BAD_SLASH_SCRIPT_DIR:\=/% set UTILS_DIR=%SCRIPT_DIR%utils set LIBS_DIR=%SCRIPT_DIR%libs set VS=%UTILS_DIR%/winsdk71/vs2010e set WINSDK=%UTILS_DIR%/winsdk71/sdk rem utils in path set MAKE_HOME=%UTILS_DIR%/make set PATH_PREPEND=%UTILS_DIR%/path_prepend set CYGWIN_HOME=%UTILS_DIR%/cygwin set BOOTJDK_HOME=%SCRIPT_DIR%/../jdk7 set ANT_HOME=%UTILS_DIR%/ant rem ALT_* varibles set ALT_BOOTDIR=%BOOTJDK_HOME% set ALT_COMPILER_PATH=%VS%/VC/Bin set ALT_WINDOWSSDKDIR=%WINSDK% set ALT_FREETYPE_LIB_PATH=%LIBS_DIR%/freetype/dist/7_32 set ALT_FREETYPE_HEADERS_PATH=%LIBS_DIR%/freetype/include set ALT_MSVCRNN_DLL_PATH=%LIBS_DIR%/msvcr/7_32 set ALT_DXSDK_PATH=%LIBS_DIR%/directx set ALT_CACERTS_FILE=%LIBS_DIR%/cacerts/cacerts rem other openjdk variables set UNLIMITED_CRYPTO=true set MILESTONE=u40-unofficial set BUILD_NUMBER=b43 set FULL_DEBUG_SYMBOLS=0 rem set NO_DOCS=true rem other variables set CYGWIN=nodosfilewarning rem set compiler environment manually set WINDOWSSDKDIR=%WINSDK% set VS100COMNTOOLS=%VS%/Common7/Tools set Configuration=Release set WindowsSDKVersionOverride=v7.1 set ToolsVersion=4.0 set TARGET_CPU=x86 set CURRENT_CPU=x86 set PlatformToolset=Windows7.1SDK set TARGET_PLATFORM=XP set LIB=%VS%/VC/Lib;%WINSDK%/Lib set LIBPATH=%VS%/VC/Lib set PATH=%PATH_PREPEND%;%VS%/Common7/IDE;%VS%/Common7/Tools;%VS%/VC/Bin;%VS%/VC/Bin/VCPackages;%WINSDK%/Bin;C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem;%MAKE_HOME%;%CYGWIN_HOME%/bin;%BOOTJDK_HOME%/bin;%ANT_HOME%/bin;%LIBS_DIR%/msvcr/7_32 set INCLUDE=%VS%/VC/INCLUDE;%WINSDK%/INCLUDE;%WINSDK%/INCLUDE/gl; bash Francis -- Regards, Alex Kasko
RFR: JDK-8019540: licensee reports a JDK8 build failure after 8005849/8005008 fixes integrated.
Please review the following changes, correcting the conditions for when to build certain parts of the servicability features. Instead of guarding them with the OPENJDK variable, they need to be conditioned on the existence of the source itself. In hotspot, this only fails on Windows. The linux makefiles already check on the existence of the source rather than if it's an OPENJDK build. This change makes windows do the same. http://cr.openjdk.java.net/~erikj/8019540/webrev.hotspot.01/ In JDK, it fails on all platforms. There is already a configure variable, ENABLE_JFR, that seems to be set correctly for this case. http://cr.openjdk.java.net/~erikj/8019540/webrev.jdk.01/ I will need a sponsor to push this to hotspot if it passes review. /Erik
Re: RFR: JDK-8019540: licensee reports a JDK8 build failure after 8005849/8005008 fixes integrated.
Looks good! Of course, the proof is in building it. I can sponsor the hotspot fix. Thanks, /Staffan On 14 okt 2013, at 11:25, Erik Joelsson erik.joels...@oracle.com wrote: Please review the following changes, correcting the conditions for when to build certain parts of the servicability features. Instead of guarding them with the OPENJDK variable, they need to be conditioned on the existence of the source itself. In hotspot, this only fails on Windows. The linux makefiles already check on the existence of the source rather than if it's an OPENJDK build. This change makes windows do the same. http://cr.openjdk.java.net/~erikj/8019540/webrev.hotspot.01/ In JDK, it fails on all platforms. There is already a configure variable, ENABLE_JFR, that seems to be set correctly for this case. http://cr.openjdk.java.net/~erikj/8019540/webrev.jdk.01/ I will need a sponsor to push this to hotspot if it passes review. /Erik
Re: RFR: 8009280: JCE jurisdiction policy files not copied into jdk/lib/security
Bumping this review. I'm pretty sure it fixes the problem reported in this particular bug. There is another bug to track all of the problems the JCE team has with the new build. /Erik On 2013-08-16 17:09, Tim Bell wrote: Erik: Woops, as some of you pointed out, I missed adding the link to the webrev: http://cr.openjdk.java.net/~erikj/8009280/webrev.02/ Looks good to me, but we should wait to hear from Brad. Tim
8026398: Can't load jdk.Exported, ClassNotFoundException
This is an update to the BuildMetaIndex tool, the tool used in the build to generate the meta-index file. The problem is that the tool assumes that there are at least two levels of package in the name of each type. This causes a problem for jdk.Exported, the annotation that was added as part of JEP 179 [1]. At this time you can't load this class because the entry in the meta-index file is generated as jdk/internal/ rather than jdk/. The tool is crying out for a re-write but it's a bit late in JDK 8 so I've instead did enough to get it to handle top-level packages in the known prefix set. The change mans that when a type in the top-level package is found then it adds a special value (TOP) into its second package set, this is enough to allow it be handled when emitting the lines for the known prefixes. The webrev with the proposed change is here: http://cr.openjdk.java.net/~alanb/8026398/webrev/ Thanks, -Alan. [1] http://openjdk.java.net/jeps/179
Re: 8026398: Can't load jdk.Exported, ClassNotFoundException
The changes look right to me, and prudent given where we are with jdk8. It suspect that this would have gone unnoticed forever, if you were not to add this type. -Chris. On 14/10/2013 14:39, Alan Bateman wrote: This is an update to the BuildMetaIndex tool, the tool used in the build to generate the meta-index file. The problem is that the tool assumes that there are at least two levels of package in the name of each type. This causes a problem for jdk.Exported, the annotation that was added as part of JEP 179 [1]. At this time you can't load this class because the entry in the meta-index file is generated as jdk/internal/ rather than jdk/. The tool is crying out for a re-write but it's a bit late in JDK 8 so I've instead did enough to get it to handle top-level packages in the known prefix set. The change mans that when a type in the top-level package is found then it adds a special value (TOP) into its second package set, this is enough to allow it be handled when emitting the lines for the known prefixes. The webrev with the proposed change is here: http://cr.openjdk.java.net/~alanb/8026398/webrev/ Thanks, -Alan. [1] http://openjdk.java.net/jeps/179
Re: code review round 1 for Full Debug Symbols on MacOS X hotspot (7165611)
Thanks for the re-review! On 10/13/13 7:57 PM, David Holmes wrote: Hi Dan, Only further comment I have, and it may well be deferred for future work, is that we should be able to abstract away the actual extension used for the debuginfo file so that we don't need macosx conditionals as much eg one: if macosx DEBUGINFO_EXTENSION=dSYM else DEBUGINFO_EXTENSION=debuginfo endif then eg: JSIG_DEBUGINFO := $(strip $(wildcard $(HOTSPOT_DIST)/jre/lib$(OPENJDK_TARGET_CPU_LIBDIR)/libjsig.$DEBUGINFO_EXTENSION) \ $(wildcard $(HOTSPOT_DIST)/jre/lib$(OPENJDK_TARGET_CPU_LIBDIR)/libjsig.diz) ) The biggest worry that I have about something like DEBUGINFO_EXTENSION is that on MacOS X the '.dSYM' objects are directories instead of files. This requires that different cmd options be used in many/most/all of the cases. More thought would be needed. Hmm second comment - I don't see a .m4 file change that corresponds to the DSYMUTIL configure change ?? Yikes! I'll check into that shortly. Not sure what happened here. Dan Thanks, David On 12/10/2013 6:27 AM, Daniel D. Daugherty wrote: Greetings, I'm ready for code review round 1 of the FDS on MacOS X hotspot changes. Below is the original code review round 0 invite (slightly edited for clarity). Working on FDS is like pulling a thread on a sweater... so there are four additional changed files along with more changes to many of the files from round 0. Here is the code review round 1 JDK8/HSX-25 webrev URL: OpenJDK: http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/1-jdk8/ Internal: http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/1-jdk8/ Changes from code review round 0 to round 1: root repo: - add configure support for DSYMUTIL macro hotspot repo: - drop Minimal1 config support for FDS on MacOS X - use DSYMUTIL macro instead of literal 'dsymutil' - fix FASTDEBUG_CFLAGS typo and add USE_CLANG support - STRIP is not used on MacOS X - fix $(UNIVERSAL_COPY_LIST) rule - refine install-dir function jdk repo: - add prep-target-dir, install-import-dir, and install-import-debuginfo functions - support importing .dSYM directories from hotspot - create libjsig.dSYM symlink from VM specific directory to the real location Files changed from code review round 0 to round 1: common/autoconf/generated-configure.sh hotspot/make/Makefile hotspot/make/bsd/makefiles/defs.make hotspot/make/bsd/makefiles/dtrace.make hotspot/make/bsd/makefiles/gcc.make hotspot/make/bsd/makefiles/jsig.make hotspot/make/bsd/makefiles/saproc.make hotspot/make/bsd/makefiles/universal.gmk hotspot/make/bsd/makefiles/vm.make hotspot/make/defs.make New files changed in code review round 1: hotspot/make/bsd/makefiles/product.make jdk/make/common/Defs.gmk jdk/make/java/redist/Makefile jdk/makefiles/Import.gmk Additional bugs filed based on code review comments, testing and just plain looking at the Makefiles: 8026280 implement Full Debug Symbols on MacOS X jdk 8026281 hotspot 'jdk6_or_earlier logic' for FDS needs to be removed 8026282 the '64' subdir logic in Makefiles might be removable 8026283 literal 'lipo' cmd uses in HotSpot makefiles 8026284 Minimal1 references/support should be removed from BSD/MacOS X 8026285 JPRT -buildenv ZIP_DEBUGINFO_FILES=0 no longer works As always, comments, questions and suggestions are welcome. Dan Greetings, I have the initial support for Full Debug Symbols (FDS) on MacOS X done and ready for review: 7165611 implement Full Debug Symbols on MacOS X hotspot https://bugs.openjdk.java.net/browse/JDK-7165611 Here is the JDK8/HSX-25 webrev URL: OpenJDK: http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ Internal: http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ This webrev includes changes for the follow repos: jdk8 jdk8/hotspot jdk8/jdk Once these changes are approved, I'm planning to push them to RT_Baseline. From there, they can follow the normal path to Main_Baseline and eventually JDK8. This work enables FDS on MacOS X for the 'hotspot' repo; the changes in the other repos are necessary to support importing the .diz files from the MacOS X 'hotspot' build into the forest build. I also fixed a few FDS related errors in the magic incantations for the new build. This is mostly a port from Linux - MacOS X/BSD with the dtrace changes ported from Solaris. In other words, this is Frankenstein's monster... Thanks to Staffan Larsen for providing an initial set of changes which I morphed into what you see here. Testing: - JPRT HSX build and test on all platforms; verification of .diz files in the MacOS X JPRT bundles - JPRT JDK8 forest build and test on all platforms; verification of .diz files in
Re: code review round 1 for Full Debug Symbols on MacOS X hotspot (7165611)
On 10/14/13 9:18 AM, Daniel D. Daugherty wrote: On 10/13/13 7:57 PM, David Holmes wrote: Hmm second comment - I don't see a .m4 file change that corresponds to the DSYMUTIL configure change ?? Yikes! I'll check into that shortly. Not sure what happened here. I somehow missed/lost two 1-liner changes: hg diff common/autoconf/basics.m4 common/autoconf/spec.gmk.in diff -r 4faa09c7fe55 common/autoconf/basics.m4 --- a/common/autoconf/basics.m4 Wed Oct 02 15:08:03 2013 +0200 +++ b/common/autoconf/basics.m4 Mon Oct 14 08:49:37 2013 -0700 @@ -644,6 +644,7 @@ fi fi if test x$OPENJDK_TARGET_OS = xmacosx; then + BASIC_REQUIRE_PROG(DSYMUTIL, dsymutil) BASIC_REQUIRE_PROG(XATTR, xattr) AC_PATH_PROG(CODESIGN, codesign) if test x$CODESIGN != x; then diff -r 4faa09c7fe55 common/autoconf/spec.gmk.in --- a/common/autoconf/spec.gmk.in Wed Oct 02 15:08:03 2013 +0200 +++ b/common/autoconf/spec.gmk.in Mon Oct 14 08:49:37 2013 -0700 @@ -484,6 +484,7 @@ DATE:=@DATE@ DATE:=@DATE@ DIFF:=@DIFF@ DIRNAME:=@DIRNAME@ +DSYMUTIL:=@DSYMUTIL@ FIND:=@FIND@ FIND_DELETE:=@FIND_DELETE@ ECHO:=@ECHO@ I don't think that these two 1-liners are worth re-rolling the webrev. Please let me know if you don't agree. Dan Dan Thanks, David On 12/10/2013 6:27 AM, Daniel D. Daugherty wrote: Greetings, I'm ready for code review round 1 of the FDS on MacOS X hotspot changes. Below is the original code review round 0 invite (slightly edited for clarity). Working on FDS is like pulling a thread on a sweater... so there are four additional changed files along with more changes to many of the files from round 0. Here is the code review round 1 JDK8/HSX-25 webrev URL: OpenJDK: http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/1-jdk8/ Internal: http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/1-jdk8/ Changes from code review round 0 to round 1: root repo: - add configure support for DSYMUTIL macro hotspot repo: - drop Minimal1 config support for FDS on MacOS X - use DSYMUTIL macro instead of literal 'dsymutil' - fix FASTDEBUG_CFLAGS typo and add USE_CLANG support - STRIP is not used on MacOS X - fix $(UNIVERSAL_COPY_LIST) rule - refine install-dir function jdk repo: - add prep-target-dir, install-import-dir, and install-import-debuginfo functions - support importing .dSYM directories from hotspot - create libjsig.dSYM symlink from VM specific directory to the real location Files changed from code review round 0 to round 1: common/autoconf/generated-configure.sh hotspot/make/Makefile hotspot/make/bsd/makefiles/defs.make hotspot/make/bsd/makefiles/dtrace.make hotspot/make/bsd/makefiles/gcc.make hotspot/make/bsd/makefiles/jsig.make hotspot/make/bsd/makefiles/saproc.make hotspot/make/bsd/makefiles/universal.gmk hotspot/make/bsd/makefiles/vm.make hotspot/make/defs.make New files changed in code review round 1: hotspot/make/bsd/makefiles/product.make jdk/make/common/Defs.gmk jdk/make/java/redist/Makefile jdk/makefiles/Import.gmk Additional bugs filed based on code review comments, testing and just plain looking at the Makefiles: 8026280 implement Full Debug Symbols on MacOS X jdk 8026281 hotspot 'jdk6_or_earlier logic' for FDS needs to be removed 8026282 the '64' subdir logic in Makefiles might be removable 8026283 literal 'lipo' cmd uses in HotSpot makefiles 8026284 Minimal1 references/support should be removed from BSD/MacOS X 8026285 JPRT -buildenv ZIP_DEBUGINFO_FILES=0 no longer works As always, comments, questions and suggestions are welcome. Dan Greetings, I have the initial support for Full Debug Symbols (FDS) on MacOS X done and ready for review: 7165611 implement Full Debug Symbols on MacOS X hotspot https://bugs.openjdk.java.net/browse/JDK-7165611 Here is the JDK8/HSX-25 webrev URL: OpenJDK: http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ Internal: http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ This webrev includes changes for the follow repos: jdk8 jdk8/hotspot jdk8/jdk Once these changes are approved, I'm planning to push them to RT_Baseline. From there, they can follow the normal path to Main_Baseline and eventually JDK8. This work enables FDS on MacOS X for the 'hotspot' repo; the changes in the other repos are necessary to support importing the .diz files from the MacOS X 'hotspot' build into the forest build. I also fixed a few FDS related errors in the magic incantations for the new build. This is mostly a port from Linux - MacOS X/BSD with the dtrace changes ported from Solaris. In other words, this is Frankenstein's monster... Thanks to Staffan Larsen for providing an initial set of changes which I morphed into what you see here.
Re: RFR: 8026062 : (s) webrev.ksh: fix bug title web scraping, remove teamware, sac, open bug and wxfile support
On Oct 11 2013, at 18:03 , Weijun Wang wrote: The webrev shows quot; inside the Bug id header entry. I have fixed this. It was being double escaped. ie. amp;quot; Updated webrev: http://cr.openjdk.java.net/~mduigou/JDK-8026062/2 Also, the following headers look a little suspicious: Compare against: ssh://hg.openjdk.java.net/jdk8/tl-gate Compare against version: -2 I usually compare with -2 when -1 is an mq patch and I also have -N. But the compare against line seems to show you are comparing to -2 of the remote repo. That would include the last changeset. This is because I have [mq]secret = True in my .hgrc file. (secret prevents me from accidentally committing mq patches to a non-jcheck repo). It may look a little unfamiliar but it is not a consequence of my webrev changes. It's so cool reviewing webrev itself without looking at the actual code changes. :) Thank you for the review! Mike Thanks Max On 10/12/13 8:22 AM, Mike Duigou wrote: On Oct 11 2013, at 14:56 , Bradford Wetmore wrote: It never worked like it did in Teamware. Thanks Brad, that's what I thought reading the source. It appeared that it had never been implemented for mercurial. I have removed support for -l Here's an updated webrev (generated with itself!): http://cr.openjdk.java.net/~mduigou/JDK-8026062/1 In addition to removing support for -l it also cleans up options handling, fixes incorrect escaping of # numeric character entities (pointed out by John Rose), and adds some documentation to the -? help. Mike Brad On 10/11/2013 11:33 AM, Mike Duigou wrote: I should also ask if anyone is using the -l option. I would like to delete it as well as it offers no particular value for mercurial (that I can tell). Mike On Oct 10 2013, at 17:20 , Weijun Wang wrote: On 10/10/13 1:13 PM, Mike Duigou wrote: On Oct 9 2013, at 22:11 , Weijun Wang wrote: Some of us still use wxfile to generate a single webrev for code changes in multiple repos. Is there another way to do it? Yes, you can pipe a simple file list to webrev to have it use that list of files. I removed wxfile support in part because it's not documented anywhere and there are alternatives. If you can confirm that the alternatives are adequate I would very much appreciate being able to go ahead with removing wxfile support. I tried to create a file list and pipe it to webrev.ksh -N -r -1 but seems not working. Am I using the wrong options? Thanks Max
hg: jdk8/build: 8025921: Make LOG=debug output more readable
Changeset: 6274d4cd22d3 Author:erikj Date: 2013-10-14 11:54 +0200 URL: http://hg.openjdk.java.net/jdk8/build/rev/6274d4cd22d3 8025921: Make LOG=debug output more readable Reviewed-by: tbell, ihse ! common/makefiles/JavaCompilation.gmk ! common/makefiles/MakeBase.gmk
hg: jdk8/build/jdk: 8025612: rt.jar still has old specification value in the manifest
Changeset: cf3ee0e2c1a5 Author:erikj Date: 2013-10-14 11:36 +0200 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/cf3ee0e2c1a5 8025612: rt.jar still has old specification value in the manifest Reviewed-by: alanb, dholmes, tbell, wetmore ! make/tools/manifest.mf
Re: RFR: JDK -8001933 Move Gensrc*.gmk and Gendata*.gmk into separate directories
Looks good to me as well.. /Tim On 10/14/13 01:17 AM, Erik Joelsson wrote: I'm in favor of this change and it looks good to me. /Erik On 2013-10-14 10:07, Magnus Ihse Bursie wrote: On 2013-10-11 20:18, Magnus Ihse Bursie wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8001933 In the makefiles directory in the jdk repo, there are a lot of files -- important files, and lot of small helper files. Many of them share a common filename prefix; however, there is a better kind of namespaces to show hierarchy in file systems: directories! :-) This fix moves all the Gensrc* files into the gensrc directory, and all the Gendata* into the gendata directory. The result is a clearer picture of the overall structure of the JDK build system. WebRev: http://cr.openjdk.java.net/~ihse/JDK-8001933-move-gensrc-and-gendata/webrev.01 In private communication, Erik suggested that we take this opportunity to rename GenerateJavaSources.gmk to GenerateSources.gmk, since it's actually more accurate (we are generating other kinds of sources, not only Java source code). Updated WebRev: http://cr.openjdk.java.net/~ihse/JDK-8001933-move-gensrc-and-gendata/webrev.02 /Magnus
Re: 8026398: Can't load jdk.Exported, ClassNotFoundException
On 10/14/2013 6:39 AM, Alan Bateman wrote: This is an update to the BuildMetaIndex tool, the tool used in the build to generate the meta-index file. The problem is that the tool assumes that there are at least two levels of package in the name of each type. This causes a problem for jdk.Exported, the annotation that was added as part of JEP 179 [1]. At this time you can't load this class because the entry in the meta-index file is generated as jdk/internal/ rather than jdk/. The tool is crying out for a re-write but it's a bit late in JDK 8 so I've instead did enough to get it to handle top-level packages in the known prefix set. The change mans that when a type in the top-level package is found then it adds a special value (TOP) into its second package set, this is enough to allow it be handled when emitting the lines for the known prefixes. The webrev with the proposed change is here: http://cr.openjdk.java.net/~alanb/8026398/webrev/ The change looks okay to me and good enough to handle this jdk.Exported case. Mandy
