From Joe.Darcy at Sun.COM Tue Jul 15 16:55:08 2008 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 15 Jul 2008 16:55:08 -0700 Subject: OpenJDK 6 build 11 source posted Message-ID: <487D38DC.2080201@sun.com> Somewhat later than planned, the OpenJDK 6 b11 source is now available at http://download.java.net/openjdk/jdk6/ This source bundle includes all the relevant JDK security fixes that recently went out: 6542088 JAX-WS server allows XXE attacks 6607339 IncrementalSAXSource_Filter still allows reading of local files 6661918 Array reference changes behavior when compiled 6332953 JMX agent should bind to loopback address when starting the local connector server More information about these changes is available from the Sun Alerts linked to from http://sunsolve.sun.com/show.do?target=security/sec (Some of the security fixes only affect closed code or areas otherwise not open sourced as part of OpenJDK 6 so not all the security fixes are reflected in the source bundle.) This build also includes ports of existing fixes in various areas. For HotSpot, fixes in previous 6 update releases are included: 6497639 Profiling Swing application caused JVM crash 6623167 C2 crashed in StoreCMNode::Value 6659207 access violation in CompilerThread0 6497639 Profiling Swing application caused JVM crash 6599425 OopMapCache::lookup() can cause later crash or assert() failure as well as a build issue: 6681796 hotspot build failure on gcc 4.2.x (ubuntu 8.04) w/ openjdk6 and a fix for an Eclipse crash: 6614100 EXCEPTION_ACCESS_VIOLATION while running Eclipse with 1.6.0_05-ea Library fixes: 6691328 DragSourceContext returns unexpected cursor 6608764 test/closed/java/awt/Focus/TemporaryLostComponentDeadlock fails 6624717 Corrupted combo box, GTK L&F, Ubuntu 7.10 6685178 REGRESSION: NPE in ConnectorBootstrap when Agent.getManagementProperties() returns null. I'm in the process of updating the Gervill sound engine included in OpenJDK 6 to the current version; that work will be complete by build 12. In the meantime, as an initial step the spacing of the source code has been normalized. 6717694 Normalize src/share/classes/com/sun/media/sound Various of the previously raised licensing/copyright and binary artifact concerns have been addressed. First, I applied Andrew John Hughes's fix to remove jscheme.jar: 6695776 corba jscheme jar files in repository could be built from source Kelly and Iris have fixed other licensing and binary artifact issues: 6565364 update legal notices in corba 6695765 Remove winver.exe completely from jdk sources 6705945 com.sun.tools.javac.zip files do not have valid copyright 6601384 hotspot/src/share/vm/adlc/archDesc.cpp generates files with incorrect legal notices 6601377 hotspot/src/share/vm/prims/jvmtiLib.xsl generates files with incorrect legal notices 6713083 hotspot copy.cpp and vmStructs_parNew.hpp source files contains proprietary sun notice 6695777 Queens.class should be built from source, not put in source repo 6710791 Remove files or build them from source: maf-1_0.jar, jlfgr-1_0.jar There were miscellaneous other fixes, including some cleanup of the regression tests: 6717575 Make sanity prints duplicated BUILD_JDK messages 6665028 native code of method j*.text.Bidi.nativeBidiChars is using the contents of a primitive array direct 6589868 transition to Mercurial: need to eliminate dependencies on SCCS keywords 6621691 (dc) test/java/nio/channels/DatagramChannel/NotBound.java missing public modifier 6596323 (fc) ClosedByInterruptException not thrown by the interrupt method (lnx) 6710579 (ch) test/java/nio/channels/AsyncCloseAndInterrupt fails (lnx) I'd expect b12 to be available within two weeks and to include the Gervill update and probably a few more licensing/artifact fixes. Going forward, I plan to get the OpenJDK 6 sources into a public Mercurial repository by the end of the summer; that will allow fixes put there to be shared more quickly and should also allow more work to go on directly in the upstream code base. -Joe From doko at ubuntu.com Wed Jul 16 01:21:09 2008 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 16 Jul 2008 10:21:09 +0200 Subject: OpenJDK 6 build 11 source posted In-Reply-To: <487D38DC.2080201@sun.com> References: <487D38DC.2080201@sun.com> Message-ID: <487DAF75.1070207@ubuntu.com> Joseph D. Darcy schrieb: > Somewhat later than planned, the OpenJDK 6 b11 source is now available at > > http://download.java.net/openjdk/jdk6/ thanks for all the work to make the tarball more FSG compliant and the announcement; I suppose the release needs some time to propagate to this site? Matthias From doko at ubuntu.com Wed Jul 16 03:01:45 2008 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 16 Jul 2008 12:01:45 +0200 Subject: OpenJDK 6 build 11 source posted In-Reply-To: <487DAF75.1070207@ubuntu.com> References: <487D38DC.2080201@sun.com> <487DAF75.1070207@ubuntu.com> Message-ID: <487DC709.5090102@ubuntu.com> Matthias Klose schrieb: > Joseph D. Darcy schrieb: >> Somewhat later than planned, the OpenJDK 6 b11 source is now available at >> >> http://download.java.net/openjdk/jdk6/ > > thanks for all the work to make the tarball more FSG compliant and the > announcement; I suppose the release needs some time to propagate to this site? I see it now on the site. From doko at ubuntu.com Fri Jul 25 06:51:04 2008 From: doko at ubuntu.com (Matthias Klose) Date: Fri, 25 Jul 2008 15:51:04 +0200 Subject: [patch] hotspot miscompilation of OpenJDK6 with gcc from the gcc-4_3-branch Message-ID: <4889DA48.2060101@ubuntu.com> OpenJDK (using the IcedTea6 build and patches) fails to build with 4.3 from the 4.3 branch, when the jvm built in stage1 is used for the first time in the stage2 build: -def-pcompile: [javac] Compiling 2 source files to /scratch/packages/openjdk/x/openjdk-6-6b11/openjdk/control/build/linux-i586/langtools/build/toolclasses WARNING: Default charset US-ASCII not supported, using ISO-8859-1 instead [javac] /scratch/packages/openjdk/x/openjdk-6-6b11/openjdk/langtools/make/tools/CompileProperties/CompileProperties.java:26: cannot access unnamed package [javac] ANSI_X3.4-1968 [javac] import java.io.BufferedWriter; [javac] ^ BUILD FAILED the build failure is not seen when reverting r136501; seen as well when just reverting the two hunks for record_numbers_of_iterations. seen with -O3 and -O2, not -O1. not seen on amd64 and sparc (the other two archs using OpenJDK hotspot). the miscompiled file is ciTypeFlow.cpp, compiled using g++-4.3 -fpic -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -g -m32 -march=i586 -mtune=generic -O2 -fno-strict-aliasing -DVM_LITTLE_ENDIAN -Wpointer-arith -Wconversion -Wsign-compare -c ciTypeFlow.cpp Upstream GCC [1] doesn't agree on a bug in the compiler, but in the application code: "I belive this is just INVALID. The code seems to do lots of things with this enum Cell, but the C++ compiler is allowed to just allocate 1 bit of storage for it. Maybe changing the Cell declaration to enum Cell { Cell_0, Cell_max = UINT_MAX } fixes the issue. See 7.2/6 for the standard wording." The suggested fix is attached; I don't see any regressions. IcedTea currently has a patch to work around the problem, compiling this file with -fno-ivopts. Matthias [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36917 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: citypeflow.diff Url: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080725/3ff5a494/attachment.ksh From martinrb at google.com Fri Jul 25 10:10:32 2008 From: martinrb at google.com (Martin Buchholz) Date: Fri, 25 Jul 2008 10:10:32 -0700 Subject: [patch] hotspot miscompilation of OpenJDK6 with gcc from the gcc-4_3-branch In-Reply-To: <4889DA48.2060101@ubuntu.com> References: <4889DA48.2060101@ubuntu.com> Message-ID: <1ccfd1c10807251010y1b281d7hfe5093a7c4ba1ec8@mail.gmail.com> I've thought about how best to fix the enum Cell crash. Extending the range of the enum to enum Cell { Cell_0, Cell_max = MAX_INT } works in practice. But I was left wondering whether this was actually standards-correct. Is it legal to use values for an enum that were not specified in the enum declaration (e.g. 1 for Cell above). A check of the draft C++ standard gives this wording: "An expression of arithmetic or enumeration type can be converted to an enumeration type explicitly. The value is unchanged if it is in the range of enumeration values of the enumeration type; otherwise the resulting enumeration value is unspecified." which makes it look like extending the range is Just Right. I might be tempted to create a proper "class Cell", but there is not a lot of state or behavior there to encapsulate. Martin On Fri, Jul 25, 2008 at 6:51 AM, Matthias Klose wrote: > BUILD FAILED > > the build failure is not seen when reverting r136501; seen as well when just > reverting the two hunks for record_numbers_of_iterations. > > seen with -O3 and -O2, not -O1. > > not seen on amd64 and sparc (the other two archs using OpenJDK hotspot). > > the miscompiled file is ciTypeFlow.cpp, compiled using > g++-4.3 -fpic -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -g -m32 > -march=i586 -mtune=generic -O2 -fno-strict-aliasing -DVM_LITTLE_ENDIAN > -Wpointer-arith -Wconversion -Wsign-compare -c ciTypeFlow.cpp > > > Upstream GCC [1] doesn't agree on a bug in the compiler, but in the application > code: > > "I belive this is just INVALID. The code seems to do lots of things with > this enum Cell, but the C++ compiler is allowed to just allocate 1 bit of > storage for it. > > Maybe changing the Cell declaration to > > enum Cell { Cell_0, Cell_max = UINT_MAX } > > fixes the issue. > > See 7.2/6 for the standard wording." > > The suggested fix is attached; I don't see any regressions. IcedTea currently > has a patch to work around the problem, compiling this file with -fno-ivopts. > > Matthias > > [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36917 > > --- openjdk/hotspot/src/share/vm/ci/ciTypeFlow.hpp~ 2008-07-10 22:04:30.000000000 +0200 > +++ openjdk/hotspot/src/share/vm/ci/ciTypeFlow.hpp 2008-07-25 14:32:03.544802121 +0200 > @@ -130,7 +130,7 @@ > > // Used as a combined index for locals and temps > enum Cell { > - Cell_0 > + Cell_0, Cell_max = UINT_MAX > }; > > // A StateVector summarizes the type information at some > > From yamauchi at google.com Fri Jul 25 11:48:36 2008 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Fri, 25 Jul 2008 11:48:36 -0700 Subject: [patch] hotspot miscompilation of OpenJDK6 with gcc from the gcc-4_3-branch In-Reply-To: <1ccfd1c10807251010y1b281d7hfe5093a7c4ba1ec8@mail.gmail.com> References: <4889DA48.2060101@ubuntu.com> <1ccfd1c10807251010y1b281d7hfe5093a7c4ba1ec8@mail.gmail.com> Message-ID: Though it may not be a big deal, Martin and I have talked about various options to fix the issue: 1. What Matthias suggested. 2. Pass -fno-tree-vrp to GCC which disables the value range propagation optimization 3. Make Cell a real class and use it as a value type with almost no runtime overhead 4. Replace the enum with "typedef int Cell" (but loses type safety) Hiroshi On Fri, Jul 25, 2008 at 10:10 AM, Martin Buchholz wrote: > I've thought about how best to fix the enum Cell crash. > Extending the range of the enum to > enum Cell { Cell_0, Cell_max = MAX_INT } > works in practice. But I was left wondering whether this was actually > standards-correct. Is it legal to use values for an enum that were > not specified in the enum declaration (e.g. 1 for Cell above). > A check of the draft C++ standard gives this wording: > > "An expression of arithmetic or enumeration type can be converted to > an enumeration type explicitly. The value is > unchanged if it is in the range of enumeration values of the > enumeration type; otherwise the resulting enumeration value > is unspecified." > > which makes it look like extending the range is Just Right. > > I might be tempted to create a proper "class Cell", > but there is not a lot of state or behavior there to encapsulate. > > Martin > > On Fri, Jul 25, 2008 at 6:51 AM, Matthias Klose wrote: >> BUILD FAILED >> >> the build failure is not seen when reverting r136501; seen as well when just >> reverting the two hunks for record_numbers_of_iterations. >> >> seen with -O3 and -O2, not -O1. >> >> not seen on amd64 and sparc (the other two archs using OpenJDK hotspot). >> >> the miscompiled file is ciTypeFlow.cpp, compiled using >> g++-4.3 -fpic -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -g -m32 >> -march=i586 -mtune=generic -O2 -fno-strict-aliasing -DVM_LITTLE_ENDIAN >> -Wpointer-arith -Wconversion -Wsign-compare -c ciTypeFlow.cpp >> >> >> Upstream GCC [1] doesn't agree on a bug in the compiler, but in the application >> code: >> >> "I belive this is just INVALID. The code seems to do lots of things with >> this enum Cell, but the C++ compiler is allowed to just allocate 1 bit of >> storage for it. >> >> Maybe changing the Cell declaration to >> >> enum Cell { Cell_0, Cell_max = UINT_MAX } >> >> fixes the issue. >> >> See 7.2/6 for the standard wording." >> >> The suggested fix is attached; I don't see any regressions. IcedTea currently >> has a patch to work around the problem, compiling this file with -fno-ivopts. >> >> Matthias >> >> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36917 >> >> --- openjdk/hotspot/src/share/vm/ci/ciTypeFlow.hpp~ 2008-07-10 22:04:30.000000000 +0200 >> +++ openjdk/hotspot/src/share/vm/ci/ciTypeFlow.hpp 2008-07-25 14:32:03.544802121 +0200 >> @@ -130,7 +130,7 @@ >> >> // Used as a combined index for locals and temps >> enum Cell { >> - Cell_0 >> + Cell_0, Cell_max = UINT_MAX >> }; >> >> // A StateVector summarizes the type information at some >> >> >