From volker.simonis at gmail.com Tue Mar 1 02:24:26 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 1 Mar 2011 11:24:26 +0100 Subject: RFE: configuration for compiling HotSpot with Clang In-Reply-To: References: Message-ID: The new numbers are now online at: http://weblogs.java.net/blog/simonis/archive/2011/02/10/compiling-hotspot-vm-clang After my first blog I got a lot of feedback and it turned out that the comparison was unfair because the way I did it Clang didn't use Precompiled Headers correctly. Now with the new configuration, it does use PCH and the results are indeed pleasant: Clang has now 15% faster build times compared to GCC. For more details and a new patch please refer to the updated blog. Regards, Volker PS: Sorry for the long delay. In fact I finished the new measurements already last week, but then java.net was down:) On Fri, Feb 11, 2011 at 7:24 PM, Volker Simonis wrote: > Hi, > > at the FOSEDM I've heard Chris Lattner's very nice "LLVM and Clang" > keynote. The claims he made in his talk have been very impressing: he > was speaking about Clang being a "production quality" "drop-in > replacement" for GCC with superior code generation and improved > compile speed. Already during the talk I decided that I would be > interesting to prove his pretensions on the HotSpot VM. If you're > interested in the details you can read my blog: > > http://weblogs.java.net/blog/simonis/archive/2011/02/10/compiling-hotspot-vm-clang > > For the impatient the summary is that Clang is still slower than > current GCC versions and the generated code seems to be slightly > slower as well. Nevertheless, Clang has excellent warning capabilities > and is an excellent C++ compiler with regard to C++ conformance. (Now > it's probably a good time to finally fix > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6889002 ?which I've > promised already more than a year ago at > http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-October/thread.html#2175 > :) > > Attached you can find a patch which contains a Clang configuration for > the HotSpot build (Linux x86/x86_64). A Clang make can be triggered by > passing "USE_CLANG=true" to the make command. Warnings are currently > turned off for the reasons mentioned above. > > This patch may also be interesting in the context of the new MacOs X > port, where Clang is much more common (or perhaps even the default C++ > compiler - i don't know?). > > Notice that this patch contains one additional change compared to the > patch in the blog. While I did the tests for the blog with an slightly > outdated HS20b03 I synced a brand new version today to prepare the > patch. With this new version I found a true C++ bug in > "src/share/vm/utilities/hashtable.hpp" which was introduced recently > by the "6990754: Use native memory and reference counting to implement > SymbolTable" change and which has to do with name lookup of > nondependent names in dependent base classes (see > http://www.parashift.com/c++-faq-lite/templates.html#faq-35.19 for a > nice explanation). Wouldn't have happened with Clang:) > > Regards, > Volker > From erik.trimble at oracle.com Tue Mar 1 11:55:51 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Tue, 01 Mar 2011 19:55:51 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20110301195554.CF44247B8C@hg.openjdk.java.net> Changeset: 7dc5384467e0 Author: coleenp Date: 2011-02-12 10:28 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7dc5384467e0 7022659: errorHandler doesn't compile without precompiled headers Summary: add proper includes in errorHandler.hpp Reviewed-by: phh, kamg ! src/share/vm/utilities/errorReporter.hpp Changeset: 0e531ab5ba04 Author: trims Date: 2011-03-01 11:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0e531ab5ba04 Merge From clattner at apple.com Tue Mar 1 15:22:04 2011 From: clattner at apple.com (Chris Lattner) Date: Tue, 1 Mar 2011 15:22:04 -0800 Subject: RFE: configuration for compiling HotSpot with Clang In-Reply-To: References: Message-ID: <68E5F578-F789-47E6-8480-051C312EDDBA@apple.com> On Mar 1, 2011, at 2:24 AM, Volker Simonis wrote: > The new numbers are now online at: > http://weblogs.java.net/blog/simonis/archive/2011/02/10/compiling-hotspot-vm-clang > > After my first blog I got a lot of feedback and it turned out that the > comparison was unfair because the way I did it Clang didn't use > Precompiled Headers correctly. Now with the new configuration, it does > use PCH and the results are indeed pleasant: Clang has now 15% faster > build times compared to GCC. This is great progress! If -fcheck-new is an important feature for you (and not a workaround for an old gcc problem), please feel free to file a bug at http://llvm.org/bugs/ In the LLVM 3.0 timeframe (~6 months from now) -flimit-debug-info should be on by default and additional debug info improvements will also land. I don't know how interested you are in tracking down the cause of the performance differences you see, but if there is anything specific LLVM is doing and there is a way to reproduce it in a small testcase, I would also really appreciate a bug report :) -Chris From volker.simonis at gmail.com Wed Mar 2 08:09:07 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 2 Mar 2011 17:09:07 +0100 Subject: -XX:+UseCompressedStrings ??? Message-ID: Hi, I just saw that 6u23 has a new optimization option -XX:+UseCompressedStrings. See for example: http://thevirtualmachinist.blogspot.com/2010/12/xxusecompressedstrings-explained.html Apparently this feature was implemented for the performance release 6u21p as can be seen here: http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html Looking at http://download.java.net/jdk6/6u23/promoted/b01/changes/JDK6u23.list.html one may guess that this was change: 6836579: Use byte[] instead of char[] for Strings where possible (Hotspot) but unfortunately the bug report is not available publicly. 6u23 has HS 19b09. If I look at http://hg.openjdk.java.net/hsx/hsx19/master I can not find this option, although it is HS19b09 as well. I thought the general promise was that the HotSpot would be developed "in the open". I understand that sensitive security fixes may follow a "deferred integration" policy, but what about this pure performance relevant change: it's not in HSX19 neither in the tip revision. Do we have to expect more proprietary changes which will be present only in the commercial/closed version of the OpenJDK? Any comments? Regards, Volker From daniel.daugherty at oracle.com Thu Mar 3 16:55:13 2011 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 04 Mar 2011 00:55:13 +0000 Subject: hg: jdk7/hotspot/hotspot: 10 new changesets Message-ID: <20110304005533.2E05A47C44@hg.openjdk.java.net> Changeset: f91db74a6810 Author: kamg Date: 2011-02-26 13:33 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f91db74a6810 7017640: Fix for 6766644 deadlocks on some NSK tests when running with -Xcomp Summary: Dynamic-code generated events should be deferred and processed by service thread Reviewed-by: dsamersoff, dcubed ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp Changeset: da091bb67459 Author: sla Date: 2011-02-28 14:19 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/da091bb67459 7022037: Pause when exiting if debugger is attached on windows Reviewed-by: dsamersoff, kamg, hosterda ! src/os/linux/vm/os_linux.cpp ! src/os/posix/vm/os_posix.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/vmError.cpp Changeset: c1a6154012c8 Author: kamg Date: 2011-02-28 16:01 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c1a6154012c8 7020118: Alter frame assignability to allow for exception handler coverage of invokespecial Summary: Add special rule to allow assignment of frames with uninit flags set. Reviewed-by: never, coleenp ! src/share/vm/classfile/stackMapFrame.cpp ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/classfile/verificationType.hpp Changeset: 23ae54207126 Author: rottenha Date: 2011-02-28 15:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/23ae54207126 Merge ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/os.hpp Changeset: cef8c988e7b8 Author: rottenha Date: 2011-02-28 22:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/cef8c988e7b8 Merge Changeset: 5584e20db481 Author: sla Date: 2011-03-02 09:41 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5584e20db481 7023323: Build failure on VS2003: IsDebuggerPresent not found Summary: #define _WIN32_WINNT 0x500 Reviewed-by: ohrstrom, hosterda, coleenp ! src/os/windows/vm/os_windows.cpp Changeset: 4a9604cd7c5f Author: kamg Date: 2011-03-02 08:18 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4a9604cd7c5f 6878713: Verifier heap corruption, relating to backward jsrs Summary: Added overflow detection in arena Amalloc methods Reviewed-by: coleenp, phh ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/globalDefinitions_sparcWorks.hpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp + test/runtime/6878713/Test6878713.sh + test/runtime/6878713/testcase.jar Changeset: 99bd05619fa4 Author: zgu Date: 2011-03-02 09:16 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/99bd05619fa4 7017110: Add /SAFESEH to links on windows 32bit to verify safe exceptions Summary: Ensure safe exception handler table is generated on Win32 binaries when compile with VS2010 Reviewed-by: acorn, coleenp, dcubed, sla, ohair ! make/windows/makefiles/compile.make ! make/windows/makefiles/launcher.make Changeset: a3c0ec0428a2 Author: zgu Date: 2011-03-02 16:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a3c0ec0428a2 Merge Changeset: 8c0d0510d36f Author: dcubed Date: 2011-03-03 09:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8c0d0510d36f Merge From john.coomes at oracle.com Thu Mar 3 20:32:29 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Mar 2011 04:32:29 +0000 Subject: hg: jdk7/hotspot: 13 new changesets Message-ID: <20110304043230.1F7F247C5B@hg.openjdk.java.net> Changeset: 995077c73fbb Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/995077c73fbb Added tag jdk7-b130 for changeset cc58c11af154 ! .hgtags Changeset: 0fd0aeb592cb Author: jqzuo Date: 2010-12-09 10:58 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/0fd0aeb592cb Merge Changeset: 20955959b7b7 Author: jqzuo Date: 2010-12-22 15:55 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/20955959b7b7 Merge Changeset: 08fe18caf411 Author: jqzuo Date: 2011-01-10 13:45 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/08fe18caf411 Merge Changeset: aee1b0183364 Author: jqzuo Date: 2011-01-24 17:14 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/aee1b0183364 Merge Changeset: 12764a5a3aec Author: jqzuo Date: 2011-02-01 15:03 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/12764a5a3aec Merge Changeset: df3abd560cbd Author: jqzuo Date: 2011-02-09 16:05 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/df3abd560cbd Merge Changeset: e2370dfcc721 Author: paulk Date: 2011-02-14 14:29 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/e2370dfcc721 7019371: JDK7 is not building UPX. IFTW wrappers are not compressed. Reviewed-by: billyh, jqzuo ! make/deploy-rules.gmk Changeset: 5466f13d19be Author: jqzuo Date: 2011-02-21 14:18 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/5466f13d19be Merge Changeset: da55264ff2fb Author: ohair Date: 2011-02-16 13:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/da55264ff2fb 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: 5d86d951426a Author: cl Date: 2011-02-23 15:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/5d86d951426a Merge Changeset: 0f62a65fb666 Author: cl Date: 2011-02-24 15:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/0f62a65fb666 Added tag jdk7-b131 for changeset 5d86d951426a ! .hgtags Changeset: b1fafacc3040 Author: katleman Date: 2011-03-03 14:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/b1fafacc3040 Added tag jdk7-b132 for changeset 0f62a65fb666 ! .hgtags From john.coomes at oracle.com Thu Mar 3 20:32:38 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Mar 2011 04:32:38 +0000 Subject: hg: jdk7/hotspot/corba: 9 new changesets Message-ID: <20110304043246.B430D47C5C@hg.openjdk.java.net> Changeset: 30ecf5c90a30 Author: mfang Date: 2011-02-10 11:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/30ecf5c90a30 7014477: pt_BR corba resource bundle is missing in jdk7 build Reviewed-by: ohair ! make/common/Defs.gmk Changeset: c08dff674e53 Author: mfang Date: 2011-02-10 14:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/c08dff674e53 7017734: jdk7 message drop 1 translation integration Reviewed-by: ogino, yhuang ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_de.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_es.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_fr.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_it.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ja.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ko.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_sv.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_CN.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_TW.properties Changeset: e0f0b358cd2c Author: mfang Date: 2011-02-11 22:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/e0f0b358cd2c Merge Changeset: 563a8f8b5be3 Author: mfang Date: 2011-02-11 23:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/563a8f8b5be3 Merge Changeset: 49a96611c870 Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/49a96611c870 Added tag jdk7-b130 for changeset 563a8f8b5be3 ! .hgtags Changeset: a9335b646c1c Author: ohair Date: 2011-02-16 13:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/a9335b646c1c 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: 9d6dd2cdfcb9 Author: cl Date: 2011-02-23 15:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/9d6dd2cdfcb9 Merge Changeset: 1b1e75e8f476 Author: cl Date: 2011-02-24 15:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/1b1e75e8f476 Added tag jdk7-b131 for changeset 9d6dd2cdfcb9 ! .hgtags Changeset: 671fe2e623ff Author: katleman Date: 2011-03-03 14:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/671fe2e623ff Added tag jdk7-b132 for changeset 1b1e75e8f476 ! .hgtags From john.coomes at oracle.com Thu Mar 3 20:32:54 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Mar 2011 04:32:54 +0000 Subject: hg: jdk7/hotspot/jaxp: 5 new changesets Message-ID: <20110304043254.5E7E447C5D@hg.openjdk.java.net> Changeset: f2ad604323c0 Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/f2ad604323c0 Added tag jdk7-b130 for changeset ab107c1bc4b9 ! .hgtags Changeset: a57220f22751 Author: ohair Date: 2011-02-16 13:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/a57220f22751 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: eab6f27131e4 Author: cl Date: 2011-02-23 15:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/eab6f27131e4 Merge Changeset: abe04c59a556 Author: cl Date: 2011-02-24 15:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/abe04c59a556 Added tag jdk7-b131 for changeset eab6f27131e4 ! .hgtags Changeset: 8e1148c7911b Author: katleman Date: 2011-03-03 14:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/8e1148c7911b Added tag jdk7-b132 for changeset abe04c59a556 ! .hgtags From john.coomes at oracle.com Thu Mar 3 20:33:01 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Mar 2011 04:33:01 +0000 Subject: hg: jdk7/hotspot/jaxws: 5 new changesets Message-ID: <20110304043301.A6E4A47C5E@hg.openjdk.java.net> Changeset: a8ffd75ad5df Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/a8ffd75ad5df Added tag jdk7-b130 for changeset ba1fac1c2083 ! .hgtags Changeset: 9e3904866cab Author: ohair Date: 2011-02-16 13:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/9e3904866cab 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: 438abc0356cd Author: cl Date: 2011-02-23 15:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/438abc0356cd Merge Changeset: 0e57c3272d37 Author: cl Date: 2011-02-24 15:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/0e57c3272d37 Added tag jdk7-b131 for changeset 438abc0356cd ! .hgtags Changeset: 359d0c8c00a0 Author: katleman Date: 2011-03-03 14:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/359d0c8c00a0 Added tag jdk7-b132 for changeset 0e57c3272d37 ! .hgtags From john.coomes at oracle.com Thu Mar 3 20:34:55 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Mar 2011 04:34:55 +0000 Subject: hg: jdk7/hotspot/jdk: 60 new changesets Message-ID: <20110304044512.DD28947C67@hg.openjdk.java.net> Changeset: 7905b047a475 Author: prr Date: 2011-02-08 14:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7905b047a475 7006865: Regression: Corrupted output when printing images with bit depth of 4 Reviewed-by: bae, jgodinez ! src/windows/classes/sun/awt/windows/WPathGraphics.java ! src/windows/classes/sun/awt/windows/WPrinterJob.java + test/java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java Changeset: d42ce0b309ae Author: bae Date: 2011-02-09 22:24 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d42ce0b309ae 6818960: ImageFetcher ( MediaTracker) Thread leak Reviewed-by: igor, prr ! src/share/classes/sun/awt/image/ImageFetcher.java ! src/share/classes/sun/awt/image/InputStreamImageSource.java Changeset: 37d20456c54c Author: ceisserer Date: 2011-02-09 14:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/37d20456c54c 7018387: Xrender pipeline may leak GC's Reviewed-by: prr ! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java Changeset: bcf663c292ef Author: bae Date: 2011-02-10 13:44 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/bcf663c292ef 6989774: imageio compiler warnings in native code Reviewed-by: igor, prr ! make/sun/jpeg/Makefile ! make/sun/jpeg/reorder-i586 ! make/sun/jpeg/reorder-sparc ! make/sun/jpeg/reorder-sparcv9 ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/share/native/sun/awt/image/jpeg/jdmarker.c ! src/share/native/sun/awt/image/jpeg/jmemmgr.c ! src/share/native/sun/awt/image/jpeg/jmemnobs.c ! src/share/native/sun/awt/image/jpeg/jmemsys.h ! src/share/native/sun/awt/image/jpeg/jpegdecoder.c ! src/share/native/sun/awt/image/jpeg/jpeglib.h Changeset: 1881764c4cdf Author: prr Date: 2011-02-11 10:40 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1881764c4cdf 7018364: XShmGetImage with image's > drawable's size causes BadMatch Reviewed-by: art, anthony Contributed-by: linuxhippy at gmail.com ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c ! src/solaris/native/sun/java2d/x11/X11SurfaceData.h Changeset: b04dafeda706 Author: prr Date: 2011-02-16 15:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b04dafeda706 7019441: No lookup cache for internal composite font creation leads to java heap growth Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/FontUtilities.java Changeset: e45f7d50dbc9 Author: bae Date: 2011-02-17 13:42 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e45f7d50dbc9 7018912: [parfait] potential buffer overruns in imageio jpeg Reviewed-by: jgodinez, prr ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c Changeset: 810445ab3099 Author: prr Date: 2011-02-18 09:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/810445ab3099 6857592: Getting warning while moving or resizing the frame when component.printAll() is called on local JNI Reviewed-by: bae, flar ! src/windows/native/sun/java2d/windows/GDIBlitLoops.cpp Changeset: 5d8cfcb9a4e8 Author: prr Date: 2011-02-18 09:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5d8cfcb9a4e8 7017637: closed/java/awt/font/StyledMetrics/BoldSpace.java failed : Space char should have 0 advance Reviewed-by: igor, jgodinez + test/java/awt/font/StyledMetrics/BoldSpace.java Changeset: 4c6500d20ebf Author: jgodinez Date: 2011-02-04 11:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4c6500d20ebf 7014796: Regression test java/awt/PrintJob/Text/stringwidth.sh cannot be terminated on Windows. Reviewed-by: prr ! test/java/awt/PrintJob/Text/StringWidth.java Changeset: 33cd780e8989 Author: jgodinez Date: 2011-02-04 11:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/33cd780e8989 6995147: Case needs to be update. ServiceDialogTest.java failed as compilation error. Reviewed-by: prr ! test/javax/print/attribute/ServiceDialogTest.java Changeset: 1d3f3c8d7ed5 Author: jgodinez Date: 2011-02-18 11:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1d3f3c8d7ed5 6722351: sun.print.Win32PrintService.initMedia() is slow Reviewed-by: igor, prr ! src/windows/classes/sun/print/Win32PrintService.java Changeset: 059b56058cad Author: jgodinez Date: 2011-02-18 12:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/059b56058cad Merge - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 1acdde062e92 Author: jgodinez Date: 2011-02-18 13:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1acdde062e92 6850806: NPE exception throws in PrintServce.getSupportedAttributeValues Reviewed-by: igor, prr ! src/windows/classes/sun/print/Win32PrintService.java Changeset: fa6547fa57e6 Author: lana Date: 2011-02-21 14:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/fa6547fa57e6 Merge Changeset: 5a6bd7df28b8 Author: lana Date: 2011-02-11 15:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5a6bd7df28b8 Merge - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 14d9e6af8889 Author: andrew Date: 2011-02-15 15:09 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/14d9e6af8889 7017581: missing copyright header in test/sun/java2d/pipe/RegionOps.java Reviewed-by: anthony ! test/sun/java2d/pipe/RegionOps.java Changeset: 7c98b6b4e8a7 Author: dav Date: 2011-02-16 01:12 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7c98b6b4e8a7 6994933: java.awt.Desktop feature is "intermittently" supported on Solaris. Really unexpected behavior. Reviewed-by: art, dcherepanov ! src/solaris/classes/sun/awt/X11/XDesktopPeer.java ! src/solaris/native/sun/xawt/awt_Desktop.c Changeset: 41da8f9ea83a Author: lana Date: 2011-02-21 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/41da8f9ea83a Merge Changeset: eeaad0d340b2 Author: peytoia Date: 2011-02-09 18:00 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/eeaad0d340b2 7017800: (tz) Support tzdata2011b Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: 493a9eeb9bca Author: alexp Date: 2011-02-10 21:36 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/493a9eeb9bca 6993171: JavaTest/JDK7b114 - no help text is shown for interview questions, JavaTest HANGS UP Reviewed-by: rupashka ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/plaf/LayerUI.java ! test/javax/swing/JComponent/6989617/bug6989617.java Changeset: be8045e2d792 Author: lana Date: 2011-02-11 12:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/be8045e2d792 Merge - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 82f7b8f6b174 Author: alexp Date: 2011-02-15 16:40 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/82f7b8f6b174 6956842: BasicTreeUI.getPreferredSize(JComp c) is delegated to getPreferredSize(c, true) not (c, false) Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java Changeset: be44bda15fcf Author: okutsu Date: 2011-02-16 16:51 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/be44bda15fcf 6936350: API clarification needed on useDaylightTime() for timezones that have defined usage dates Reviewed-by: peytoia ! src/share/classes/java/util/SimpleTimeZone.java ! src/share/classes/java/util/TimeZone.java + test/java/util/TimeZone/DaylightTimeTest.java Changeset: f326139e7fda Author: malenkov Date: 2011-02-16 18:32 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f326139e7fda 6980124: closed/javax/swing/plaf/synth/SynthPainter/unitTest/UnitTest.java fails Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/synth/SynthGraphicsUtils.java Changeset: 888baed5c55b Author: rupashka Date: 2011-02-18 00:16 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/888baed5c55b 7016693: javax/swing/JScrollBar/6542335/bug6542335.java failed on Ubuntu Reviewed-by: alexp ! test/javax/swing/JScrollBar/6542335/bug6542335.java Changeset: db0a6fd0fea9 Author: amenkov Date: 2011-02-18 13:21 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/db0a6fd0fea9 6801236: test closed/javax/sound/sampled/FileWriter/WaveBigEndian.java fails Reviewed-by: alexp ! src/share/classes/com/sun/media/sound/services/javax.sound.sampled.spi.FormatConversionProvider Changeset: 64b4226f171f Author: amenkov Date: 2011-02-18 13:27 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/64b4226f171f 7000132: Misplaced description in javax.sound.sampled.AudioSystem.getTargetDataLine Reviewed-by: dav ! src/share/classes/javax/sound/sampled/AudioSystem.java Changeset: a93bb05d00fd Author: alexp Date: 2011-02-18 19:21 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a93bb05d00fd 6474153: LookAndFeel.makeKeyBindings(...) doesn't ignore last element in keyBindingList with odd size Reviewed-by: rupashka ! src/share/classes/javax/swing/LookAndFeel.java + test/javax/swing/LookAndFeel/6474153/bug6474153.java Changeset: 3772a3d90b40 Author: rupashka Date: 2011-02-18 20:09 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3772a3d90b40 6997102: Test case has hard code, so that applet thread threw exception Reviewed-by: alexp ! test/javax/swing/JFileChooser/6798062/bug6798062.html ! test/javax/swing/JFileChooser/6798062/bug6798062.java Changeset: 2cc71008b6db Author: lana Date: 2011-02-21 14:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2cc71008b6db Merge ! src/share/classes/javax/swing/JComponent.java Changeset: cfd397d86474 Author: sundar Date: 2011-02-11 10:38 +0530 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/cfd397d86474 6604827: JavaDoc for ScriptEngineFactory.getMethodCallSyntax contains an error. Reviewed-by: mchung ! src/share/classes/javax/script/ScriptEngineFactory.java Changeset: 05a0271173a6 Author: ohair Date: 2011-02-10 20:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/05a0271173a6 Merge - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java - src/share/demo/zipfs - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: 1dc0c3021d13 Author: ohair Date: 2011-02-11 01:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1dc0c3021d13 Merge Changeset: 8711aedb08f2 Author: sherman Date: 2011-02-11 12:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8711aedb08f2 7007596: (zipfs) FileSystems.newFileSystem(FileRef...) always employs zipfs regardless the real Path type. Summary: updated newFileSystem() to throw UOE exception for non-zip/jar file Reviewed-by: alanb ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh Changeset: 8860e17db3bd Author: weijun Date: 2011-02-12 05:09 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8860e17db3bd 6742654: Code insertion/replacement attacks against signed jars 6911041: JCK api/signaturetest tests fails for Mixed Code PIT builds (b91) for all trains 6921823: JarVerifier csdomain field not initialized 6921839: Update trusted.libraries list Reviewed-by: dgu ! make/java/security/Makefile ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java ! src/share/classes/sun/misc/JarIndex.java ! src/share/classes/sun/misc/JavaUtilJarAccess.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java Changeset: de923c0ec3c4 Author: weijun Date: 2011-02-12 07:30 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/de923c0ec3c4 7016698: test sun/security/krb5/runNameEquals.sh failed on Ubuntu Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java Changeset: 21a1e86dedc2 Author: sherman Date: 2011-02-11 17:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/21a1e86dedc2 6996192: Console.readPassword race: input echo off must be prior to writing prompt Summary: To turn off echo before prompt Reviewed-by: alanb ! src/share/classes/java/io/Console.java Changeset: b04e86b3e27e Author: dcubed Date: 2011-02-14 09:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b04e86b3e27e 6637230: 2/3 jps doesn't work for application waiting for direct attach Summary: Properly handle exceptions thrown when querying a monitored VM. Reviewed-by: dsamersoff, swamyv ! src/share/classes/sun/tools/jps/Jps.java Changeset: fefc740bff52 Author: alanb Date: 2011-02-14 18:30 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/fefc740bff52 7016704: TEST_BUG: java/nio/file/Files/walk_file_tree.sh fails with new version of find (lnx) Reviewed-by: forax ! test/java/nio/file/Files/walkFileTree/PrintFileTree.java Changeset: 28037efa90a3 Author: mduigou Date: 2011-02-14 10:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/28037efa90a3 6934356: Vector.writeObject() serialization may deadlock Summary: No longer synchronize on self while writing other objects. Reviewed-by: alanb, forax, mduigou, peterjones Contributed-by: Neil Richards ! src/share/classes/java/util/Vector.java + test/java/util/Vector/SerializationDeadlock.java + test/java/util/Vector/SimpleSerialization.java Changeset: 2633daa325ed Author: mduigou Date: 2011-02-14 10:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2633daa325ed Merge Changeset: 338c5b815ff2 Author: mduigou Date: 2011-02-14 11:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/338c5b815ff2 6927486: Hashtable writeObject() may deadlock Summary: Do not synchronize on self while writing hash table elements Reviewed-by: alanb, mduigou Contributed-by: Neil Richards ! src/share/classes/java/util/Hashtable.java + test/java/util/Hashtable/SerializationDeadlock.java + test/java/util/Hashtable/SimpleSerialization.java Changeset: 44c99f30f9df Author: xuelei Date: 2011-02-14 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/44c99f30f9df 7018897: CertPath validation cannot handle self-signed cert with bad KeyUsage Summary: Remove KeyUsage checking for trust anchors Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java Changeset: 9024288330c4 Author: weijun Date: 2011-02-15 12:11 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9024288330c4 7018928: test failure: sun/security/krb5/auto/SSL.java Reviewed-by: valeriep ! test/sun/security/krb5/auto/BadKdc1.java ! test/sun/security/krb5/auto/BadKdc2.java ! test/sun/security/krb5/auto/BadKdc3.java ! test/sun/security/krb5/auto/BadKdc4.java ! test/sun/security/krb5/auto/CleanState.java ! test/sun/security/krb5/auto/CrossRealm.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/krb5/auto/IgnoreChannelBinding.java ! test/sun/security/krb5/auto/KerberosHashEqualsTest.java ! test/sun/security/krb5/auto/LifeTimeInSeconds.java ! test/sun/security/krb5/auto/LoginModuleOptions.java ! test/sun/security/krb5/auto/MaxRetries.java ! test/sun/security/krb5/auto/MoreKvno.java ! test/sun/security/krb5/auto/NewSalt.java ! test/sun/security/krb5/auto/NonMutualSpnego.java ! test/sun/security/krb5/auto/SSL.java ! test/sun/security/krb5/auto/SpnegoReqFlags.java ! test/sun/security/krb5/auto/Test5653.java Changeset: b578c9ccfb01 Author: lana Date: 2011-02-15 08:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b578c9ccfb01 Merge Changeset: afa89f8ab9c8 Author: chegar Date: 2011-02-16 12:38 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/afa89f8ab9c8 6562203: Thread doesn't terminate immediately if it was stopped before start Reviewed-by: dholmes, alanb ! src/share/classes/java/lang/Thread.java - test/java/lang/Thread/StopBeforeStart.java Changeset: dbc74475822f Author: sherman Date: 2011-02-16 11:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/dbc74475822f 6999337: java.exe fails to start if some directory names in path to java binaries contain Russian characters Summary: updated to make sure the system properties are accessable by vm during initialization Reviewed-by: alanb, mchung ! src/share/classes/java/lang/System.java Changeset: 6e33b377aa6e Author: smarks Date: 2011-02-16 18:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6e33b377aa6e 7018392: update URLJarFile.java to use try-with-resources Reviewed-by: alanb, chegar, hawtin ! src/share/classes/sun/net/www/protocol/jar/URLJarFile.java Changeset: 15ef6cf616d6 Author: chegar Date: 2011-02-17 09:56 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/15ef6cf616d6 7017901: OOME in java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java Summary: Unbounded queues should be disabled in the test Reviewed-by: alanb ! test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java Changeset: 302877469037 Author: alanb Date: 2011-02-17 20:50 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/302877469037 6526860: (fc) FileChannel.position returns 0 when FileOutputStream opened in append mode Reviewed-by: forax ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java ! test/java/nio/channels/FileChannel/Position.java Changeset: a5861eb81f3c Author: alanb Date: 2011-02-17 20:53 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a5861eb81f3c Merge Changeset: dd143033cef1 Author: sundar Date: 2011-02-18 12:07 +0530 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/dd143033cef1 7018459: javax.script code comments have issues with HTML4 validation and Accessibility compliance Reviewed-by: jjh ! src/share/classes/javax/script/ScriptEngineFactory.java Changeset: 5bf920749b97 Author: smarks Date: 2011-02-18 12:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5bf920749b97 7018385: update javax.sql classes to use try-with-resources Reviewed-by: alanb, lancea, darcy ! src/share/classes/javax/sql/rowset/serial/SerialClob.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java Changeset: 42e4205db024 Author: mduigou Date: 2011-02-21 13:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/42e4205db024 7001685: Renable EnumSetBash Test Reviewed-by: alanb, ohair, darcy ! test/ProblemList.txt Changeset: 3ebece41badd Author: lana Date: 2011-02-21 14:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3ebece41badd Merge - test/java/lang/Thread/StopBeforeStart.java Changeset: f046a44e92fd Author: jgodinez Date: 2011-02-24 15:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f046a44e92fd 7022228: JPRT failure: RuntimeException in SupportedMedia regression test Reviewed-by: igor, prr ! src/windows/classes/sun/print/Win32PrintService.java Changeset: 094c70388ab0 Author: lana Date: 2011-02-24 18:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/094c70388ab0 Merge - test/java/lang/Thread/StopBeforeStart.java Changeset: 6bbc7a473495 Author: lana Date: 2011-03-01 14:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6bbc7a473495 Merge - test/java/lang/Thread/StopBeforeStart.java Changeset: b88e4395c437 Author: katleman Date: 2011-03-03 14:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b88e4395c437 Added tag jdk7-b132 for changeset 6bbc7a473495 ! .hgtags From john.coomes at oracle.com Thu Mar 3 23:17:15 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 04 Mar 2011 07:17:15 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20110304071718.E2EF147C77@hg.openjdk.java.net> Changeset: 4e0069ff33df Author: johnc Date: 2011-02-28 09:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4e0069ff33df 7022200: G1: optimized build broken Summary: Make the G1 specific version of is_in_closed_subset() available in all builds. Reviewed-by: tonyp, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 11303bede852 Author: jcoomes Date: 2011-03-03 21:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/11303bede852 Merge From vladimir.kozlov at oracle.com Fri Mar 4 03:23:11 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 04 Mar 2011 11:23:11 +0000 Subject: hg: jdk7/hotspot/hotspot: 13 new changesets Message-ID: <20110304112334.5226047CAE@hg.openjdk.java.net> Changeset: d89a22843c62 Author: iveresov Date: 2011-02-22 15:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d89a22843c62 7020521: arraycopy stubs place prebarriers incorrectly Summary: Rearranged the pre-barrier placement in arraycopy stubs so that they are properly called in case of chained calls. Also refactored the code a little bit so that it looks uniform across the platforms and is more readable. Reviewed-by: never, kvn ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: d5a078cf7f39 Author: iveresov Date: 2011-02-22 18:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d5a078cf7f39 Merge Changeset: ba5d119730dd Author: kvn Date: 2011-02-23 12:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ba5d119730dd Merge Changeset: d411927672ed Author: never Date: 2011-02-23 19:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d411927672ed 7012072: CompileTheWorld causes incorrect class initialization Reviewed-by: kvn, twisti ! src/share/vm/prims/unsafe.cpp Changeset: 5a41a201d08c Author: kvn Date: 2011-02-24 10:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5a41a201d08c 6812217: Base memory of MergeMem node violates assert during killing expanded AllocateArray node Summary: The assert in MergeMemNode::memory_at() misses the case when address is TOP. Reviewed-by: never ! src/share/vm/opto/memnode.cpp Changeset: 6f3746e69a78 Author: never Date: 2011-02-24 11:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6f3746e69a78 7021603: crash in fill_sync_handler with ExtendedDTrace probes Reviewed-by: iveresov ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: 8190d4b75e09 Author: never Date: 2011-02-24 14:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8190d4b75e09 Merge Changeset: 41d4973cf100 Author: kvn Date: 2011-02-26 12:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/41d4973cf100 6942326: x86 code in string_indexof() could read beyond reserved heap space Summary: copy small (<8) strings on stack if str+16 crosses a page boundary and load from stack into XMM. Back up pointer when loading string's tail. Reviewed-by: never ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.cpp + test/compiler/6942326/Test.java Changeset: 1b4e6a5d98e0 Author: twisti Date: 2011-02-28 06:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1b4e6a5d98e0 7012914: JSR 292 MethodHandlesTest C1: frame::verify_return_pc(return_address) failed: must be a return pc Reviewed-by: never, bdelsart ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/utilities/macros.hpp Changeset: 50c0f22d6d0e Author: never Date: 2011-02-28 17:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/50c0f22d6d0e 7023229: extraneous include of precompiled.hpp in hsdis.c Reviewed-by: never, jrose Contributed-by: volker.simonis at gmail.com ! src/share/tools/hsdis/hsdis-demo.c ! src/share/tools/hsdis/hsdis.c Changeset: bc6b27fb3568 Author: never Date: 2011-03-01 10:27 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/bc6b27fb3568 6725983: Assertion "method->method_holder())->is_not_initialized(),"method holder must be initialized" Reviewed-by: kvn, iveresov ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/runtime/globals.hpp Changeset: 0ac769a57c64 Author: iveresov Date: 2011-03-01 14:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0ac769a57c64 6627983: G1: Bad oop deference during marking Summary: Bulk zeroing reduction didn't work with G1, because arraycopy would call pre-barriers on uninitialized oops. The solution is to have version of arraycopy stubs that don't have pre-barriers. Also refactored arraycopy stubs generation on SPARC to be more readable and reduced the number of stubs necessary in some cases. Reviewed-by: jrose, kvn, never ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/memory/barrierSet.cpp ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp Changeset: 8c9c9ee30d71 Author: kvn Date: 2011-03-03 23:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8c9c9ee30d71 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp From volker.simonis at gmail.com Fri Mar 4 03:31:08 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 4 Mar 2011 12:31:08 +0100 Subject: Differences between the HotSpot in OpenJDK and the closed Oracle JDK Message-ID: Sorry for my impertinence. I already sent this message to the list a few days before but I can not believe that nobody is interested in this topic so I resend it with a different (more appropriate?) subject. If again nobody comments I apologize and promise to keep silent forevermore:) I just saw that 6u23 has a new optimization option -XX:+UseCompressedStrings. See for example: http://thevirtualmachinist.blogspot.com/2010/12/xxusecompressedstrings-explained.html Apparently this feature was implemented for the performance release 6u21p as can be seen here: http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html Looking at http://download.java.net/jdk6/6u23/promoted/b01/changes/JDK6u23.list.html one may guess that this was change: 6836579: Use byte[] instead of char[] for Strings where possible (Hotspot) but unfortunately the bug report is not available publicly. 6u23 has HS 19b09. If I look at http://hg.openjdk.java.net/hsx/hsx19/master I can not find this option, although it is HS19b09 as well. I thought the general promise was that the HotSpot would be developed "in the open". I understand that sensitive security fixes may follow a ?"deferred integration" policy, but what about this pure performance relevant change: it's not in HSX19 neither in the tip revision. Do we have to expect more proprietary changes which will be present only in the commercial/closed version of the OpenJDK? Any comments? Regards, Volker From john.pampuch at oracle.com Fri Mar 4 12:58:36 2011 From: john.pampuch at oracle.com (John Pampuch) Date: Fri, 04 Mar 2011 12:58:36 -0800 Subject: Differences between the HotSpot in OpenJDK and the closed Oracle JDK In-Reply-To: References: Message-ID: <4D71527C.7040400@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110304/b9f2148a/attachment.html From erik.trimble at oracle.com Fri Mar 4 14:18:33 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Fri, 04 Mar 2011 22:18:33 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20110304221844.9B3EF47CF8@hg.openjdk.java.net> Changeset: a8d643a4db47 Author: katleman Date: 2011-03-03 14:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a8d643a4db47 Added tag jdk7-b132 for changeset 0e531ab5ba04 ! .hgtags Changeset: 1b3a350709e4 Author: trims Date: 2011-03-03 15:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1b3a350709e4 Added tag hs21-b03 for changeset a8d643a4db47 ! .hgtags Changeset: 3e2b59ab2d07 Author: trims Date: 2011-03-04 14:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3e2b59ab2d07 Merge Changeset: 3c76374706ea Author: trims Date: 2011-03-04 14:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3c76374706ea 7024814: Bump the HS21 build number to 04 Summary: Update the HS21 build number to 04 Reviewed-by: jcoomes ! make/hotspot_version From tom.rodriguez at oracle.com Tue Mar 8 13:04:11 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 8 Mar 2011 13:04:11 -0800 Subject: review (L) for 7017732: move static fields into Class to prepare for perm gen removal In-Reply-To: <3C5028C8-1C34-4267-916B-D9BEA461521D@oracle.com> References: <33AEF62A-EE62-48FF-B9D6-B38A73443590@oracle.com> <4D533AB9.2060206@oracle.com> <3311F28E-EDAF-4270-B807-15200E044856@oracle.com> <4D53448E.60706@oracle.com> <0BB30DC5-E9D8-484A-975B-2A91375DD1DA@oracle.com> <3C5028C8-1C34-4267-916B-D9BEA461521D@oracle.com> Message-ID: I discovered that I hadn't tested with CDS on and that required me to change the way that the synthetic fields in Class are laid out. When using the classes from the shared archive the class file parser isn't runtime so the synthetic fields had to be at some well known offset. The current synthetic oop fields are allocated right after the header and I needed 2 new int fields so I chose to allocate them just after the header and have the synthetic oop fields directly follow those. That required some small changes to the SA to use the computed value for klass_offset. The allocation of the Java mirror had to change as well. I also brought over support for allocating the mirrors in the normal heap which exposed a few bugs in the oop visitors for arrayKlass. Some of them weren't calling their super visitor so _java_mirror wasn't being visited. arrayKlassKlass::oop_oop_iterate_m was also forwarding to oop_oop_iterate and ignoring the MemRegion. I also added a separate flag to control whether the Class is in perm or not instead of overloading ScavengeRootsInCode. I called it JavaObjectsInPerm but I'm open to changing the name. This can also be used for the String changes that Coomes has. It can also be used for debugging once ScavengeRootsInCode is always enabled. I reran all my tests and also ran Tony's gc_test_suite with all the various collectors, which showed the oop visitor issues I found. I did testing with -Xshare:dump as well. I've updated the full webrev itself and I also generated a incremental webrev to show what I changed since the last review. http://cr.openjdk.java.net/~never/7017732 http://cr.openjdk.java.net/~never/7017732_incremental tom On Feb 10, 2011, at 1:07 AM, Christian Thalinger wrote: > Yes, looks good. -- Christian > > On Feb 10, 2011, at 3:40 AM, Tom Rodriguez wrote: >> >> On Feb 9, 2011, at 5:51 PM, Vladimir Kozlov wrote: >> >>> Tom Rodriguez wrote: >>>> I removed the no longer correct part. Did you want something added? >>> >>> Is next description is still valid? >>> >>> 77 // [EMBEDDED Java vtable ] size in words = vtable_len >>> 78 // [EMBEDDED static oop fields ] size in words = static_oop_fields_size >>> 79 // [ static non-oop fields ] size in words = static_field_size - static_oop_fields_size >>> 80 // [EMBEDDED nonstatic oop-map blocks] size in words = nonstatic_oop_map_size >> >> I removed lines 78 and 79 but the rest is still correct I think. >> >>> >>>>> I don't understand changes in Unsafe_StaticFieldBaseFromClass(), >>>>> it should return handle but you just return original jobject. >>>> We're supposed to return the object to use as the base of unsafe static field references. That's just the java.lang.Class instance which was passed in so we simply return it. What would you expect it to do? I guess we might want to unhandle it and return a new local one in case the original one wasn't a local handle. Is that what you're getting at? >>> >>> Thank you for explaining. Code is good. >> >> I've changed it to return a new local handle as that seems less surprising. >> >> @@ -704,7 +704,7 @@ UNSAFE_ENTRY(jobject, Unsafe_StaticField >> if (clazz == NULL) { >> THROW_0(vmSymbols::java_lang_NullPointerException()); >> } >> - return JNIHandles::make_local(env, java_lang_Class::as_klassOop(JNIHandles::resolve_non_null(clazz))); >> + return JNIHandles::make_local(env, JNIHandles::resolve_non_null(clazz)); >> UNSAFE_END >> >> UNSAFE_ENTRY(void, Unsafe_EnsureClassInitialized(JNIEnv *env, jobject unsafe, jobject clazz)) >> >> I've regenerated the webrev. >> >> tom >> >>> >>> Vladimir >>> >>>> tom >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> I've updated the webrev with this change, fixed a couple macro names that still referenced InstanceKlass and fixed the alignment of the continuation slashes. >>>>>> tom >>>>>> On Feb 9, 2011, at 3:52 AM, Christian Thalinger wrote: >>>>>>> On Feb 8, 2011, at 11:01 PM, Tom Rodriguez wrote: >>>>>>>> http://cr.openjdk.java.net/~never/7017732 >>>>>>> src/cpu/x86/vm/c1_CodeStubs_x86.cpp: >>>>>>> >>>>>>> 315 Register tmp = rax; >>>>>>> 316 Register tmp2 = rbx; >>>>>>> 317 if (_obj == tmp) tmp = rcx; >>>>>>> 318 else if (_obj == tmp2) tmp = rcx; >>>>>>> 319 __ push(tmp); >>>>>>> 320 __ push(tmp2); >>>>>>> 321 __ get_thread(tmp); >>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>> 324 __ pop(tmp2); >>>>>>> 325 __ pop(tmp); >>>>>>> >>>>>>> Why do you change tmp if _obj == tmp2? I think line 318 isn't required at all since if _obj == tmp2 it gets saved and restored anyway. What about this: >>>>>>> >>>>>>> 315 Register tmp = rax; >>>>>>> 316 Register tmp2 = rbx; >>>>>>> 319 __ push(tmp); >>>>>>> 320 __ push(tmp2); >>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>> 321 __ get_thread(tmp); >>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>> 324 __ pop(tmp2); >>>>>>> 325 __ pop(tmp); >>>>>>> >>>>>>> -- Christian > > From vladimir.kozlov at oracle.com Tue Mar 8 16:59:43 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Mar 2011 16:59:43 -0800 Subject: review (L) for 7017732: move static fields into Class to prepare for perm gen removal In-Reply-To: References: <33AEF62A-EE62-48FF-B9D6-B38A73443590@oracle.com> <4D533AB9.2060206@oracle.com> <3311F28E-EDAF-4270-B807-15200E044856@oracle.com> <4D53448E.60706@oracle.com> <0BB30DC5-E9D8-484A-975B-2A91375DD1DA@oracle.com> <3C5028C8-1C34-4267-916B-D9BEA461521D@oracle.com> Message-ID: <4D76D0FF.7030507@oracle.com> Looks good to me, at least parts which I understand. I would prefer JavaObjectsInPerm be diagnostic flag so we can change its value in product VM. Or experimental since we remove it later, right? vmStructs.cpp: add separation comment for klass_offset: /**************************************/ /* java_lang_Class (NOTE: incomplete) */ /**************************************/ static_field(java_lang_Class, klass_offset, int) it also miss java_lang_Class::hc_number_of_fake_int_fields. Thanks, Vladimir Tom Rodriguez wrote: > I discovered that I hadn't tested with CDS on and that required me to change the way that the synthetic fields in Class are laid out. When using the classes from the shared archive the class file parser isn't runtime so the synthetic fields had to be at some well known offset. The current synthetic oop fields are allocated right after the header and I needed 2 new int fields so I chose to allocate them just after the header and have the synthetic oop fields directly follow those. That required some small changes to the SA to use the computed value for klass_offset. The allocation of the Java mirror had to change as well. > > I also brought over support for allocating the mirrors in the normal heap which exposed a few bugs in the oop visitors for arrayKlass. Some of them weren't calling their super visitor so _java_mirror wasn't being visited. arrayKlassKlass::oop_oop_iterate_m was also forwarding to oop_oop_iterate and ignoring the MemRegion. > > I also added a separate flag to control whether the Class is in perm or not instead of overloading ScavengeRootsInCode. I called it JavaObjectsInPerm but I'm open to changing the name. This can also be used for the String changes that Coomes has. It can also be used for debugging once ScavengeRootsInCode is always enabled. > > I reran all my tests and also ran Tony's gc_test_suite with all the various collectors, which showed the oop visitor issues I found. I did testing with -Xshare:dump as well. I've updated the full webrev itself and I also generated a incremental webrev to show what I changed since the last review. > > http://cr.openjdk.java.net/~never/7017732 > http://cr.openjdk.java.net/~never/7017732_incremental > > tom > > On Feb 10, 2011, at 1:07 AM, Christian Thalinger wrote: > >> Yes, looks good. -- Christian >> >> On Feb 10, 2011, at 3:40 AM, Tom Rodriguez wrote: >>> On Feb 9, 2011, at 5:51 PM, Vladimir Kozlov wrote: >>> >>>> Tom Rodriguez wrote: >>>>> I removed the no longer correct part. Did you want something added? >>>> Is next description is still valid? >>>> >>>> 77 // [EMBEDDED Java vtable ] size in words = vtable_len >>>> 78 // [EMBEDDED static oop fields ] size in words = static_oop_fields_size >>>> 79 // [ static non-oop fields ] size in words = static_field_size - static_oop_fields_size >>>> 80 // [EMBEDDED nonstatic oop-map blocks] size in words = nonstatic_oop_map_size >>> I removed lines 78 and 79 but the rest is still correct I think. >>> >>>>>> I don't understand changes in Unsafe_StaticFieldBaseFromClass(), >>>>>> it should return handle but you just return original jobject. >>>>> We're supposed to return the object to use as the base of unsafe static field references. That's just the java.lang.Class instance which was passed in so we simply return it. What would you expect it to do? I guess we might want to unhandle it and return a new local one in case the original one wasn't a local handle. Is that what you're getting at? >>>> Thank you for explaining. Code is good. >>> I've changed it to return a new local handle as that seems less surprising. >>> >>> @@ -704,7 +704,7 @@ UNSAFE_ENTRY(jobject, Unsafe_StaticField >>> if (clazz == NULL) { >>> THROW_0(vmSymbols::java_lang_NullPointerException()); >>> } >>> - return JNIHandles::make_local(env, java_lang_Class::as_klassOop(JNIHandles::resolve_non_null(clazz))); >>> + return JNIHandles::make_local(env, JNIHandles::resolve_non_null(clazz)); >>> UNSAFE_END >>> >>> UNSAFE_ENTRY(void, Unsafe_EnsureClassInitialized(JNIEnv *env, jobject unsafe, jobject clazz)) >>> >>> I've regenerated the webrev. >>> >>> tom >>> >>>> Vladimir >>>> >>>>> tom >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> I've updated the webrev with this change, fixed a couple macro names that still referenced InstanceKlass and fixed the alignment of the continuation slashes. >>>>>>> tom >>>>>>> On Feb 9, 2011, at 3:52 AM, Christian Thalinger wrote: >>>>>>>> On Feb 8, 2011, at 11:01 PM, Tom Rodriguez wrote: >>>>>>>>> http://cr.openjdk.java.net/~never/7017732 >>>>>>>> src/cpu/x86/vm/c1_CodeStubs_x86.cpp: >>>>>>>> >>>>>>>> 315 Register tmp = rax; >>>>>>>> 316 Register tmp2 = rbx; >>>>>>>> 317 if (_obj == tmp) tmp = rcx; >>>>>>>> 318 else if (_obj == tmp2) tmp = rcx; >>>>>>>> 319 __ push(tmp); >>>>>>>> 320 __ push(tmp2); >>>>>>>> 321 __ get_thread(tmp); >>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>> 324 __ pop(tmp2); >>>>>>>> 325 __ pop(tmp); >>>>>>>> >>>>>>>> Why do you change tmp if _obj == tmp2? I think line 318 isn't required at all since if _obj == tmp2 it gets saved and restored anyway. What about this: >>>>>>>> >>>>>>>> 315 Register tmp = rax; >>>>>>>> 316 Register tmp2 = rbx; >>>>>>>> 319 __ push(tmp); >>>>>>>> 320 __ push(tmp2); >>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>> 321 __ get_thread(tmp); >>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>> 324 __ pop(tmp2); >>>>>>>> 325 __ pop(tmp); >>>>>>>> >>>>>>>> -- Christian >> > From tom.rodriguez at oracle.com Tue Mar 8 20:23:25 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 8 Mar 2011 20:23:25 -0800 Subject: review (L) for 7017732: move static fields into Class to prepare for perm gen removal In-Reply-To: <4D76D0FF.7030507@oracle.com> References: <33AEF62A-EE62-48FF-B9D6-B38A73443590@oracle.com> <4D533AB9.2060206@oracle.com> <3311F28E-EDAF-4270-B807-15200E044856@oracle.com> <4D53448E.60706@oracle.com> <0BB30DC5-E9D8-484A-975B-2A91375DD1DA@oracle.com> <3C5028C8-1C34-4267-916B-D9BEA461521D@oracle.com> <4D76D0FF.7030507@oracle.com> Message-ID: On Mar 8, 2011, at 4:59 PM, Vladimir Kozlov wrote: > Looks good to me, at least parts which I understand. > > I would prefer JavaObjectsInPerm be diagnostic flag so we can change its value in product VM. Or experimental since we remove it later, right? JohnC didn't seem to want it to be in the product and I don't have a strong opinion either way. Why don't we leave it develop for now? > > vmStructs.cpp: add separation comment for klass_offset: > > /**************************************/ > /* java_lang_Class (NOTE: incomplete) */ > /**************************************/ > > static_field(java_lang_Class, klass_offset, int) I added that along with the rest of the offset fields in case we ever want them later. > > it also miss java_lang_Class::hc_number_of_fake_int_fields. The SA doesn't really need to that value so there's no point in adding it. I went ahead and deleted the entry for java_lang_Class::hc_number_of_fake_oop_fields since it's unused. I updated the webrevs. Thanks! tom > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> I discovered that I hadn't tested with CDS on and that required me to change the way that the synthetic fields in Class are laid out. When using the classes from the shared archive the class file parser isn't runtime so the synthetic fields had to be at some well known offset. The current synthetic oop fields are allocated right after the header and I needed 2 new int fields so I chose to allocate them just after the header and have the synthetic oop fields directly follow those. That required some small changes to the SA to use the computed value for klass_offset. The allocation of the Java mirror had to change as well. >> I also brought over support for allocating the mirrors in the normal heap which exposed a few bugs in the oop visitors for arrayKlass. Some of them weren't calling their super visitor so _java_mirror wasn't being visited. arrayKlassKlass::oop_oop_iterate_m was also forwarding to oop_oop_iterate and ignoring the MemRegion. >> I also added a separate flag to control whether the Class is in perm or not instead of overloading ScavengeRootsInCode. I called it JavaObjectsInPerm but I'm open to changing the name. This can also be used for the String changes that Coomes has. It can also be used for debugging once ScavengeRootsInCode is always enabled. >> I reran all my tests and also ran Tony's gc_test_suite with all the various collectors, which showed the oop visitor issues I found. I did testing with -Xshare:dump as well. I've updated the full webrev itself and I also generated a incremental webrev to show what I changed since the last review. >> http://cr.openjdk.java.net/~never/7017732 >> http://cr.openjdk.java.net/~never/7017732_incremental >> tom >> On Feb 10, 2011, at 1:07 AM, Christian Thalinger wrote: >>> Yes, looks good. -- Christian >>> >>> On Feb 10, 2011, at 3:40 AM, Tom Rodriguez wrote: >>>> On Feb 9, 2011, at 5:51 PM, Vladimir Kozlov wrote: >>>> >>>>> Tom Rodriguez wrote: >>>>>> I removed the no longer correct part. Did you want something added? >>>>> Is next description is still valid? >>>>> >>>>> 77 // [EMBEDDED Java vtable ] size in words = vtable_len >>>>> 78 // [EMBEDDED static oop fields ] size in words = static_oop_fields_size >>>>> 79 // [ static non-oop fields ] size in words = static_field_size - static_oop_fields_size >>>>> 80 // [EMBEDDED nonstatic oop-map blocks] size in words = nonstatic_oop_map_size >>>> I removed lines 78 and 79 but the rest is still correct I think. >>>> >>>>>>> I don't understand changes in Unsafe_StaticFieldBaseFromClass(), >>>>>>> it should return handle but you just return original jobject. >>>>>> We're supposed to return the object to use as the base of unsafe static field references. That's just the java.lang.Class instance which was passed in so we simply return it. What would you expect it to do? I guess we might want to unhandle it and return a new local one in case the original one wasn't a local handle. Is that what you're getting at? >>>>> Thank you for explaining. Code is good. >>>> I've changed it to return a new local handle as that seems less surprising. >>>> >>>> @@ -704,7 +704,7 @@ UNSAFE_ENTRY(jobject, Unsafe_StaticField >>>> if (clazz == NULL) { THROW_0(vmSymbols::java_lang_NullPointerException()); } - return JNIHandles::make_local(env, java_lang_Class::as_klassOop(JNIHandles::resolve_non_null(clazz))); + return JNIHandles::make_local(env, JNIHandles::resolve_non_null(clazz)); UNSAFE_END >>>> UNSAFE_ENTRY(void, Unsafe_EnsureClassInitialized(JNIEnv *env, jobject unsafe, jobject clazz)) >>>> >>>> I've regenerated the webrev. >>>> >>>> tom >>>> >>>>> Vladimir >>>>> >>>>>> tom >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> Tom Rodriguez wrote: >>>>>>>> I've updated the webrev with this change, fixed a couple macro names that still referenced InstanceKlass and fixed the alignment of the continuation slashes. >>>>>>>> tom >>>>>>>> On Feb 9, 2011, at 3:52 AM, Christian Thalinger wrote: >>>>>>>>> On Feb 8, 2011, at 11:01 PM, Tom Rodriguez wrote: >>>>>>>>>> http://cr.openjdk.java.net/~never/7017732 >>>>>>>>> src/cpu/x86/vm/c1_CodeStubs_x86.cpp: >>>>>>>>> >>>>>>>>> 315 Register tmp = rax; >>>>>>>>> 316 Register tmp2 = rbx; >>>>>>>>> 317 if (_obj == tmp) tmp = rcx; >>>>>>>>> 318 else if (_obj == tmp2) tmp = rcx; >>>>>>>>> 319 __ push(tmp); >>>>>>>>> 320 __ push(tmp2); >>>>>>>>> 321 __ get_thread(tmp); >>>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>>> 324 __ pop(tmp2); >>>>>>>>> 325 __ pop(tmp); >>>>>>>>> >>>>>>>>> Why do you change tmp if _obj == tmp2? I think line 318 isn't required at all since if _obj == tmp2 it gets saved and restored anyway. What about this: >>>>>>>>> >>>>>>>>> 315 Register tmp = rax; >>>>>>>>> 316 Register tmp2 = rbx; >>>>>>>>> 319 __ push(tmp); >>>>>>>>> 320 __ push(tmp2); >>>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>>> 321 __ get_thread(tmp); >>>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>>> 324 __ pop(tmp2); >>>>>>>>> 325 __ pop(tmp); >>>>>>>>> >>>>>>>>> -- Christian >>> From vladimir.kozlov at oracle.com Tue Mar 8 20:46:27 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Mar 2011 20:46:27 -0800 Subject: review (L) for 7017732: move static fields into Class to prepare for perm gen removal In-Reply-To: References: <33AEF62A-EE62-48FF-B9D6-B38A73443590@oracle.com> <4D533AB9.2060206@oracle.com> <3311F28E-EDAF-4270-B807-15200E044856@oracle.com> <4D53448E.60706@oracle.com> <0BB30DC5-E9D8-484A-975B-2A91375DD1DA@oracle.com> <3C5028C8-1C34-4267-916B-D9BEA461521D@oracle.com> <4D76D0FF.7030507@oracle.com> Message-ID: <4D770623.9030209@oracle.com> On 3/8/11 8:23 PM, Tom Rodriguez wrote: > > On Mar 8, 2011, at 4:59 PM, Vladimir Kozlov wrote: > >> Looks good to me, at least parts which I understand. >> >> I would prefer JavaObjectsInPerm be diagnostic flag so we can change its value in product VM. Or experimental since we remove it later, right? > > JohnC didn't seem to want it to be in the product and I don't have a strong opinion either way. Why don't we leave it develop for now? OK. Changes looks good. Vladimir > >> >> vmStructs.cpp: add separation comment for klass_offset: >> >> /**************************************/ >> /* java_lang_Class (NOTE: incomplete) */ >> /**************************************/ >> >> static_field(java_lang_Class, klass_offset, int) > > I added that along with the rest of the offset fields in case we ever want them later. > >> >> it also miss java_lang_Class::hc_number_of_fake_int_fields. > > The SA doesn't really need to that value so there's no point in adding it. I went ahead and deleted the entry for java_lang_Class::hc_number_of_fake_oop_fields since it's unused. > > I updated the webrevs. Thanks! > > tom > >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> I discovered that I hadn't tested with CDS on and that required me to change the way that the synthetic fields in Class are laid out. When using the classes from the shared archive the class file parser isn't runtime so the synthetic fields had to be at some well known offset. The current synthetic oop fields are allocated right after the header and I needed 2 new int fields so I chose to allocate them just after the header and have the synthetic oop fields directly follow those. That required some small changes to the SA to use the computed value for klass_offset. The allocation of the Java mirror had to change as well. >>> I also brought over support for allocating the mirrors in the normal heap which exposed a few bugs in the oop visitors for arrayKlass. Some of them weren't calling their super visitor so _java_mirror wasn't being visited. arrayKlassKlass::oop_oop_iterate_m was also forwarding to oop_oop_iterate and ignoring the MemRegion. >>> I also added a separate flag to control whether the Class is in perm or not instead of overloading ScavengeRootsInCode. I called it JavaObjectsInPerm but I'm open to changing the name. This can also be used for the String changes that Coomes has. It can also be used for debugging once ScavengeRootsInCode is always enabled. >>> I reran all my tests and also ran Tony's gc_test_suite with all the various collectors, which showed the oop visitor issues I found. I did testing with -Xshare:dump as well. I've updated the full webrev itself and I also generated a incremental webrev to show what I changed since the last review. >>> http://cr.openjdk.java.net/~never/7017732 >>> http://cr.openjdk.java.net/~never/7017732_incremental >>> tom >>> On Feb 10, 2011, at 1:07 AM, Christian Thalinger wrote: >>>> Yes, looks good. -- Christian >>>> >>>> On Feb 10, 2011, at 3:40 AM, Tom Rodriguez wrote: >>>>> On Feb 9, 2011, at 5:51 PM, Vladimir Kozlov wrote: >>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> I removed the no longer correct part. Did you want something added? >>>>>> Is next description is still valid? >>>>>> >>>>>> 77 // [EMBEDDED Java vtable ] size in words = vtable_len >>>>>> 78 // [EMBEDDED static oop fields ] size in words = static_oop_fields_size >>>>>> 79 // [ static non-oop fields ] size in words = static_field_size - static_oop_fields_size >>>>>> 80 // [EMBEDDED nonstatic oop-map blocks] size in words = nonstatic_oop_map_size >>>>> I removed lines 78 and 79 but the rest is still correct I think. >>>>> >>>>>>>> I don't understand changes in Unsafe_StaticFieldBaseFromClass(), >>>>>>>> it should return handle but you just return original jobject. >>>>>>> We're supposed to return the object to use as the base of unsafe static field references. That's just the java.lang.Class instance which was passed in so we simply return it. What would you expect it to do? I guess we might want to unhandle it and return a new local one in case the original one wasn't a local handle. Is that what you're getting at? >>>>>> Thank you for explaining. Code is good. >>>>> I've changed it to return a new local handle as that seems less surprising. >>>>> >>>>> @@ -704,7 +704,7 @@ UNSAFE_ENTRY(jobject, Unsafe_StaticField >>>>> if (clazz == NULL) { THROW_0(vmSymbols::java_lang_NullPointerException()); } - return JNIHandles::make_local(env, java_lang_Class::as_klassOop(JNIHandles::resolve_non_null(clazz))); + return JNIHandles::make_local(env, JNIHandles::resolve_non_null(clazz)); UNSAFE_END >>>>> UNSAFE_ENTRY(void, Unsafe_EnsureClassInitialized(JNIEnv *env, jobject unsafe, jobject clazz)) >>>>> >>>>> I've regenerated the webrev. >>>>> >>>>> tom >>>>> >>>>>> Vladimir >>>>>> >>>>>>> tom >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> Tom Rodriguez wrote: >>>>>>>>> I've updated the webrev with this change, fixed a couple macro names that still referenced InstanceKlass and fixed the alignment of the continuation slashes. >>>>>>>>> tom >>>>>>>>> On Feb 9, 2011, at 3:52 AM, Christian Thalinger wrote: >>>>>>>>>> On Feb 8, 2011, at 11:01 PM, Tom Rodriguez wrote: >>>>>>>>>>> http://cr.openjdk.java.net/~never/7017732 >>>>>>>>>> src/cpu/x86/vm/c1_CodeStubs_x86.cpp: >>>>>>>>>> >>>>>>>>>> 315 Register tmp = rax; >>>>>>>>>> 316 Register tmp2 = rbx; >>>>>>>>>> 317 if (_obj == tmp) tmp = rcx; >>>>>>>>>> 318 else if (_obj == tmp2) tmp = rcx; >>>>>>>>>> 319 __ push(tmp); >>>>>>>>>> 320 __ push(tmp2); >>>>>>>>>> 321 __ get_thread(tmp); >>>>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>>>> 324 __ pop(tmp2); >>>>>>>>>> 325 __ pop(tmp); >>>>>>>>>> >>>>>>>>>> Why do you change tmp if _obj == tmp2? I think line 318 isn't required at all since if _obj == tmp2 it gets saved and restored anyway. What about this: >>>>>>>>>> >>>>>>>>>> 315 Register tmp = rax; >>>>>>>>>> 316 Register tmp2 = rbx; >>>>>>>>>> 319 __ push(tmp); >>>>>>>>>> 320 __ push(tmp2); >>>>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>>>> 321 __ get_thread(tmp); >>>>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>>>> 324 __ pop(tmp2); >>>>>>>>>> 325 __ pop(tmp); >>>>>>>>>> >>>>>>>>>> -- Christian >>>> > From ptisnovs at redhat.com Wed Mar 9 05:17:47 2011 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Wed, 09 Mar 2011 14:17:47 +0100 Subject: Reviewer needed - new regression test for checking issues described in bugs #6196102 and #5091921 Message-ID: <4D777DFB.6020901@redhat.com> Hi, I'd like to add new regression test into Hotspot test suite. This test check issues described in bugs #6196102 and #5091921. Webrev containing this test is available here: http://cr.openjdk.java.net/~ptisnovs/jtreg-6196102/ Can anybody please review this change (and probably assign new bug ID to it to allow me to push this change)? Thank you in advance Pavel Tisnovsky From vladimir.kozlov at oracle.com Wed Mar 9 09:25:48 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Mar 2011 09:25:48 -0800 Subject: Reviewer needed - new regression test for checking issues described in bugs #6196102 and #5091921 In-Reply-To: <4D777DFB.6020901@redhat.com> References: <4D777DFB.6020901@redhat.com> Message-ID: <4D77B81C.5080509@oracle.com> We add a regression test only together with corresponding fix. We have tests from corresponding bugs which show this problem and some of them will be added to regression suit. Vladimir Pavel Tisnovsky wrote: > Hi, > > I'd like to add new regression test into Hotspot test suite. This test > check issues described in bugs #6196102 and #5091921. > > Webrev containing this test is available here: > http://cr.openjdk.java.net/~ptisnovs/jtreg-6196102/ > > Can anybody please review this change (and probably assign new bug ID to > it to allow me to push this change)? > > Thank you in advance > Pavel Tisnovsky From karen.kinnear at oracle.com Wed Mar 9 13:48:58 2011 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Wed, 09 Mar 2011 21:48:58 +0000 Subject: hg: jdk7/hotspot/hotspot: 6 new changesets Message-ID: <20110309214909.A723747FFF@hg.openjdk.java.net> Changeset: 9f44e9aad2d9 Author: coleenp Date: 2011-03-03 19:51 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9f44e9aad2d9 7022999: Can't build with FORCE_TIERED=0 Summary: Put UseFastLocking test under #ifdef COMPILER1 Reviewed-by: kvn, phh, never, dcubed ! src/share/vm/runtime/arguments.cpp Changeset: fbbeec6dad2d Author: coleenp Date: 2011-03-03 19:52 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fbbeec6dad2d 6512830: Error: assert(tag_at(which).is_unresolved_klass(), "Corrupted constant pool") Summary: Redefine classes copies the constant pool while the constant pool may be resolving strings or classes Reviewed-by: dcubed, dsamersoff, acorn ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: f767174aac14 Author: coleenp Date: 2011-03-03 19:53 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f767174aac14 7021653: Parfait issue in hotspot/src/share/vm/oops/methodDataOops.hpp Summary: Fix compilation error(s) Reviewed-by: kvn, phh, jcoomes, dholmes ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/runtime/os.cpp Changeset: dbad0519a1c4 Author: kamg Date: 2011-03-04 14:40 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/dbad0519a1c4 6845426: non-static method with no args is called during the class initialization process Summary: Only call with ACC_STATIC for classfiles with version > 50 Reviewed-by: acorn, dholmes, coleenp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp Changeset: 0cd0a06d2535 Author: acorn Date: 2011-03-07 09:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0cd0a06d2535 Merge ! src/share/vm/runtime/arguments.cpp Changeset: df1347358fe6 Author: coleenp Date: 2011-03-07 16:03 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/df1347358fe6 7024584: Symbol printouts shouldnt be under PrintGCDetails Summary: Put symbol printing under Verbose and WizardMode so you can get this information if you really want it. Reviewed-by: phh, stefank, never, dholmes, jcoomes ! src/share/vm/classfile/symbolTable.cpp From vladimir.danushevsky at oracle.com Thu Mar 10 09:21:03 2011 From: vladimir.danushevsky at oracle.com (Vladimir Danushevsky) Date: Thu, 10 Mar 2011 12:21:03 -0500 Subject: Request for review: 7011490 Wrong computation results in Test6880034 Message-ID: <5D47A46C-ABF5-4FA4-9666-CBF930941F1D@oracle.com> http://cr.openjdk.java.net/~vladidan/7011490/webrev.00/ LinearScan::append_scope_value_for_operand() appends high and low registers of the double operand based on big endianess. On ARM platform (little endian) that causes shift in the registers allocation when copied to an expression stack during c2i deoptimization. x86 (being a LE) uses stack slot for a double op, therefore it's not affected. I want to make sure Zero target is not broken by that change as it could be built little endian as well. Could anyone comment on that please? Thanks, Vlad From tom.rodriguez at oracle.com Thu Mar 10 09:31:31 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 10 Mar 2011 09:31:31 -0800 Subject: Request for review: 7011490 Wrong computation results in Test6880034 In-Reply-To: <5D47A46C-ABF5-4FA4-9666-CBF930941F1D@oracle.com> References: <5D47A46C-ABF5-4FA4-9666-CBF930941F1D@oracle.com> Message-ID: <13AE4E4D-8E5D-4282-9F6A-EC721DBBE1E9@oracle.com> On Mar 10, 2011, at 9:21 AM, Vladimir Danushevsky wrote: > http://cr.openjdk.java.net/~vladidan/7011490/webrev.00/ > > LinearScan::append_scope_value_for_operand() appends high and low registers of the double operand based on big endianess. On ARM platform (little endian) that causes shift in the registers allocation when copied to an expression stack during c2i deoptimization. > x86 (being a LE) uses stack slot for a double op, therefore it's not affected. Are you saying that x86 doesn't use this path? That doesn't seem right to me. > I want to make sure Zero target is not broken by that change as it could be built little endian as well. Could anyone comment on that please? Zero doesn't use our compilers so it can't be effected. tom > > Thanks, > Vlad > > From vladimir.danushevsky at oracle.com Thu Mar 10 10:16:09 2011 From: vladimir.danushevsky at oracle.com (Vladimir Danushevsky) Date: Thu, 10 Mar 2011 13:16:09 -0500 Subject: Request for review: 7011490 Wrong computation results in Test6880034 In-Reply-To: <13AE4E4D-8E5D-4282-9F6A-EC721DBBE1E9@oracle.com> References: <5D47A46C-ABF5-4FA4-9666-CBF930941F1D@oracle.com> <13AE4E4D-8E5D-4282-9F6A-EC721DBBE1E9@oracle.com> Message-ID: <9BF9ECA5-7986-4C5C-94B6-0DCC9D7B7F6D@oracle.com> On Mar 10, 2011, at 12:31 PM, Tom Rodriguez wrote: > > On Mar 10, 2011, at 9:21 AM, Vladimir Danushevsky wrote: > >> http://cr.openjdk.java.net/~vladidan/7011490/webrev.00/ >> >> LinearScan::append_scope_value_for_operand() appends high and low >> registers of the double operand based on big endianess. On ARM >> platform (little endian) that causes shift in the registers >> allocation when copied to an expression stack during c2i >> deoptimization. >> x86 (being a LE) uses stack slot for a double op, therefore it's >> not affected. > > Are you saying that x86 doesn't use this path? That doesn't seem > right to me. x86 uses the path but opr->fpu_regnrLo() = opr->fpu_regnrHi, therefore no difference in behavior for that architecture. Thanks, Vlad > > >> I want to make sure Zero target is not broken by that change as it >> could be built little endian as well. Could anyone comment on that >> please? > > Zero doesn't use our compilers so it can't be effected. > > tom > >> >> Thanks, >> Vlad >> >> > From tom.rodriguez at oracle.com Thu Mar 10 10:33:23 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 10 Mar 2011 10:33:23 -0800 Subject: Request for review: 7011490 Wrong computation results in Test6880034 In-Reply-To: <9BF9ECA5-7986-4C5C-94B6-0DCC9D7B7F6D@oracle.com> References: <5D47A46C-ABF5-4FA4-9666-CBF930941F1D@oracle.com> <13AE4E4D-8E5D-4282-9F6A-EC721DBBE1E9@oracle.com> <9BF9ECA5-7986-4C5C-94B6-0DCC9D7B7F6D@oracle.com> Message-ID: <6292CECB-866B-48E9-A8DE-0D8FCBD2627B@oracle.com> On Mar 10, 2011, at 10:16 AM, Vladimir Danushevsky wrote: > > On Mar 10, 2011, at 12:31 PM, Tom Rodriguez wrote: > >> >> On Mar 10, 2011, at 9:21 AM, Vladimir Danushevsky wrote: >> >>> http://cr.openjdk.java.net/~vladidan/7011490/webrev.00/ >>> >>> LinearScan::append_scope_value_for_operand() appends high and low registers of the double operand based on big endianess. On ARM platform (little endian) that causes shift in the registers allocation when copied to an expression stack during c2i deoptimization. >>> x86 (being a LE) uses stack slot for a double op, therefore it's not affected. >> >> Are you saying that x86 doesn't use this path? That doesn't seem right to me. > > x86 uses the path but opr->fpu_regnrLo() = opr->fpu_regnrHi, therefore no difference in behavior for that architecture. I read through it but missed that. Looks good then, though you might correct the x86 comment: assert(opr->fpu_regnrLo() == opr->fpu_regnrHi(), "assumed in calculation (only fpu_regnrHi is used)"); tom > > Thanks, > Vlad >> >> >>> I want to make sure Zero target is not broken by that change as it could be built little endian as well. Could anyone comment on that please? >> >> Zero doesn't use our compilers so it can't be effected. >> >> tom >> >>> >>> Thanks, >>> Vlad >>> >>> >> > From vladimir.danushevsky at oracle.com Thu Mar 10 10:39:06 2011 From: vladimir.danushevsky at oracle.com (Vladimir Danushevsky) Date: Thu, 10 Mar 2011 13:39:06 -0500 Subject: Request for review: 7011490 Wrong computation results in Test6880034 In-Reply-To: <6292CECB-866B-48E9-A8DE-0D8FCBD2627B@oracle.com> References: <5D47A46C-ABF5-4FA4-9666-CBF930941F1D@oracle.com> <13AE4E4D-8E5D-4282-9F6A-EC721DBBE1E9@oracle.com> <9BF9ECA5-7986-4C5C-94B6-0DCC9D7B7F6D@oracle.com> <6292CECB-866B-48E9-A8DE-0D8FCBD2627B@oracle.com> Message-ID: <02ABE49B-5739-4260-B46A-38A01FDAD362@oracle.com> So for x86 should that be just: assert(opr->fpu_regnrLo() == opr->fpu_regnrHi(), "assumed in calculation"); Thanks, Vlad On Mar 10, 2011, at 1:33 PM, Tom Rodriguez wrote: > > On Mar 10, 2011, at 10:16 AM, Vladimir Danushevsky wrote: > >> >> On Mar 10, 2011, at 12:31 PM, Tom Rodriguez wrote: >> >>> >>> On Mar 10, 2011, at 9:21 AM, Vladimir Danushevsky wrote: >>> >>>> http://cr.openjdk.java.net/~vladidan/7011490/webrev.00/ >>>> >>>> LinearScan::append_scope_value_for_operand() appends high and low >>>> registers of the double operand based on big endianess. On ARM >>>> platform (little endian) that causes shift in the registers >>>> allocation when copied to an expression stack during c2i >>>> deoptimization. >>>> x86 (being a LE) uses stack slot for a double op, therefore it's >>>> not affected. >>> >>> Are you saying that x86 doesn't use this path? That doesn't seem >>> right to me. >> >> x86 uses the path but opr->fpu_regnrLo() = opr->fpu_regnrHi, >> therefore no difference in behavior for that architecture. > > I read through it but missed that. Looks good then, though you > might correct the x86 comment: > > assert(opr->fpu_regnrLo() == opr->fpu_regnrHi(), "assumed in > calculation (only fpu_regnrHi is used)"); > > tom > >> >> Thanks, >> Vlad >>> >>> >>>> I want to make sure Zero target is not broken by that change as >>>> it could be built little endian as well. Could anyone comment on >>>> that please? >>> >>> Zero doesn't use our compilers so it can't be effected. >>> >>> tom >>> >>>> >>>> Thanks, >>>> Vlad >>>> >>>> >>> >> > From tom.rodriguez at oracle.com Thu Mar 10 11:01:05 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 10 Mar 2011 11:01:05 -0800 Subject: Request for review: 7011490 Wrong computation results in Test6880034 In-Reply-To: <02ABE49B-5739-4260-B46A-38A01FDAD362@oracle.com> References: <5D47A46C-ABF5-4FA4-9666-CBF930941F1D@oracle.com> <13AE4E4D-8E5D-4282-9F6A-EC721DBBE1E9@oracle.com> <9BF9ECA5-7986-4C5C-94B6-0DCC9D7B7F6D@oracle.com> <6292CECB-866B-48E9-A8DE-0D8FCBD2627B@oracle.com> <02ABE49B-5739-4260-B46A-38A01FDAD362@oracle.com> Message-ID: <0851249E-A634-427D-B754-64DA50A213E7@oracle.com> The reference to fpu_regnrHi in the message should become fpu_regnrLo. You could delete that part but I don't see why. tom On Mar 10, 2011, at 10:39 AM, Vladimir Danushevsky wrote: > So for x86 should that be just: > > assert(opr->fpu_regnrLo() == opr->fpu_regnrHi(), "assumed in calculation"); > > Thanks, > Vlad > > > On Mar 10, 2011, at 1:33 PM, Tom Rodriguez wrote: > >> >> On Mar 10, 2011, at 10:16 AM, Vladimir Danushevsky wrote: >> >>> >>> On Mar 10, 2011, at 12:31 PM, Tom Rodriguez wrote: >>> >>>> >>>> On Mar 10, 2011, at 9:21 AM, Vladimir Danushevsky wrote: >>>> >>>>> http://cr.openjdk.java.net/~vladidan/7011490/webrev.00/ >>>>> >>>>> LinearScan::append_scope_value_for_operand() appends high and low registers of the double operand based on big endianess. On ARM platform (little endian) that causes shift in the registers allocation when copied to an expression stack during c2i deoptimization. >>>>> x86 (being a LE) uses stack slot for a double op, therefore it's not affected. >>>> >>>> Are you saying that x86 doesn't use this path? That doesn't seem right to me. >>> >>> x86 uses the path but opr->fpu_regnrLo() = opr->fpu_regnrHi, therefore no difference in behavior for that architecture. >> >> I read through it but missed that. Looks good then, though you might correct the x86 comment: >> >> assert(opr->fpu_regnrLo() == opr->fpu_regnrHi(), "assumed in calculation (only fpu_regnrHi is used)"); >> >> tom >> >>> >>> Thanks, >>> Vlad >>>> >>>> >>>>> I want to make sure Zero target is not broken by that change as it could be built little endian as well. Could anyone comment on that please? >>>> >>>> Zero doesn't use our compilers so it can't be effected. >>>> >>>> tom >>>> >>>>> >>>>> Thanks, >>>>> Vlad >>>>> >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Thu Mar 10 12:04:15 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 10 Mar 2011 15:04:15 -0500 Subject: review (L) for 7017732: move static fields into Class to prepare for perm gen removal In-Reply-To: References: <33AEF62A-EE62-48FF-B9D6-B38A73443590@oracle.com> <4D533AB9.2060206@oracle.com> <3311F28E-EDAF-4270-B807-15200E044856@oracle.com> <4D53448E.60706@oracle.com> <0BB30DC5-E9D8-484A-975B-2A91375DD1DA@oracle.com> <3C5028C8-1C34-4267-916B-D9BEA461521D@oracle.com> Message-ID: <4D792EBF.9040807@oracle.com> http://cr.openjdk.java.net/~never/7017732/src/share/vm/classfile/javaClasses.cpp.frames.html line 485 - shouldn't the "if (k->oop_is_instance())" start with "else". Or can something be a javaArray and an instance? That's all I saw that looked strange. The rest is too subtle. That function to layout static and nonstatic fields in a class is overly complicated to tell if it's correct or not, but it looks okay to me. I hope someone rewrites that someday. Did CDS work with both JavaObjectsInPerm and without? It should recreate the mirrors if they are not in the shared archive, but I didn't know if it did that yet. Also, thank you for adding JavaObjectsInPerm - less confusing to me. Thanks, Coleen On 3/8/2011 4:04 PM, Tom Rodriguez wrote: > I discovered that I hadn't tested with CDS on and that required me to change the way that the synthetic fields in Class are laid out. When using the classes from the shared archive the class file parser isn't runtime so the synthetic fields had to be at some well known offset. The current synthetic oop fields are allocated right after the header and I needed 2 new int fields so I chose to allocate them just after the header and have the synthetic oop fields directly follow those. That required some small changes to the SA to use the computed value for klass_offset. The allocation of the Java mirror had to change as well. > > I also brought over support for allocating the mirrors in the normal heap which exposed a few bugs in the oop visitors for arrayKlass. Some of them weren't calling their super visitor so _java_mirror wasn't being visited. arrayKlassKlass::oop_oop_iterate_m was also forwarding to oop_oop_iterate and ignoring the MemRegion. > > I also added a separate flag to control whether the Class is in perm or not instead of overloading ScavengeRootsInCode. I called it JavaObjectsInPerm but I'm open to changing the name. This can also be used for the String changes that Coomes has. It can also be used for debugging once ScavengeRootsInCode is always enabled. > > I reran all my tests and also ran Tony's gc_test_suite with all the various collectors, which showed the oop visitor issues I found. I did testing with -Xshare:dump as well. I've updated the full webrev itself and I also generated a incremental webrev to show what I changed since the last review. > > http://cr.openjdk.java.net/~never/7017732 > http://cr.openjdk.java.net/~never/7017732_incremental > > tom > > On Feb 10, 2011, at 1:07 AM, Christian Thalinger wrote: > >> Yes, looks good. -- Christian >> >> On Feb 10, 2011, at 3:40 AM, Tom Rodriguez wrote: >>> On Feb 9, 2011, at 5:51 PM, Vladimir Kozlov wrote: >>> >>>> Tom Rodriguez wrote: >>>>> I removed the no longer correct part. Did you want something added? >>>> Is next description is still valid? >>>> >>>> 77 // [EMBEDDED Java vtable ] size in words = vtable_len >>>> 78 // [EMBEDDED static oop fields ] size in words = static_oop_fields_size >>>> 79 // [ static non-oop fields ] size in words = static_field_size - static_oop_fields_size >>>> 80 // [EMBEDDED nonstatic oop-map blocks] size in words = nonstatic_oop_map_size >>> I removed lines 78 and 79 but the rest is still correct I think. >>> >>>>>> I don't understand changes in Unsafe_StaticFieldBaseFromClass(), >>>>>> it should return handle but you just return original jobject. >>>>> We're supposed to return the object to use as the base of unsafe static field references. That's just the java.lang.Class instance which was passed in so we simply return it. What would you expect it to do? I guess we might want to unhandle it and return a new local one in case the original one wasn't a local handle. Is that what you're getting at? >>>> Thank you for explaining. Code is good. >>> I've changed it to return a new local handle as that seems less surprising. >>> >>> @@ -704,7 +704,7 @@ UNSAFE_ENTRY(jobject, Unsafe_StaticField >>> if (clazz == NULL) { >>> THROW_0(vmSymbols::java_lang_NullPointerException()); >>> } >>> - return JNIHandles::make_local(env, java_lang_Class::as_klassOop(JNIHandles::resolve_non_null(clazz))); >>> + return JNIHandles::make_local(env, JNIHandles::resolve_non_null(clazz)); >>> UNSAFE_END >>> >>> UNSAFE_ENTRY(void, Unsafe_EnsureClassInitialized(JNIEnv *env, jobject unsafe, jobject clazz)) >>> >>> I've regenerated the webrev. >>> >>> tom >>> >>>> Vladimir >>>> >>>>> tom >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> I've updated the webrev with this change, fixed a couple macro names that still referenced InstanceKlass and fixed the alignment of the continuation slashes. >>>>>>> tom >>>>>>> On Feb 9, 2011, at 3:52 AM, Christian Thalinger wrote: >>>>>>>> On Feb 8, 2011, at 11:01 PM, Tom Rodriguez wrote: >>>>>>>>> http://cr.openjdk.java.net/~never/7017732 >>>>>>>> src/cpu/x86/vm/c1_CodeStubs_x86.cpp: >>>>>>>> >>>>>>>> 315 Register tmp = rax; >>>>>>>> 316 Register tmp2 = rbx; >>>>>>>> 317 if (_obj == tmp) tmp = rcx; >>>>>>>> 318 else if (_obj == tmp2) tmp = rcx; >>>>>>>> 319 __ push(tmp); >>>>>>>> 320 __ push(tmp2); >>>>>>>> 321 __ get_thread(tmp); >>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>> 324 __ pop(tmp2); >>>>>>>> 325 __ pop(tmp); >>>>>>>> >>>>>>>> Why do you change tmp if _obj == tmp2? I think line 318 isn't required at all since if _obj == tmp2 it gets saved and restored anyway. What about this: >>>>>>>> >>>>>>>> 315 Register tmp = rax; >>>>>>>> 316 Register tmp2 = rbx; >>>>>>>> 319 __ push(tmp); >>>>>>>> 320 __ push(tmp2); >>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>> 321 __ get_thread(tmp); >>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>> 324 __ pop(tmp2); >>>>>>>> 325 __ pop(tmp); >>>>>>>> >>>>>>>> -- Christian >> From john.coomes at oracle.com Thu Mar 10 20:38:44 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Mar 2011 04:38:44 +0000 Subject: hg: jdk7/hotspot: 6 new changesets Message-ID: <20110311043845.2FAA547068@hg.openjdk.java.net> Changeset: a1c8b847b753 Author: ohrstrom Date: 2011-02-28 10:56 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/a1c8b847b753 7021753: Add a build times report Summary: Report the build times at end of a jdkroot build. Reviewed-by: ohair ! Makefile ! make/Defs-internal.gmk ! make/corba-rules.gmk ! make/deploy-rules.gmk ! make/hotspot-rules.gmk ! make/install-rules.gmk ! make/jaxp-rules.gmk ! make/jaxws-rules.gmk ! make/jdk-rules.gmk ! make/langtools-rules.gmk ! make/sponsors-rules.gmk Changeset: 47ad81d343e8 Author: ohair Date: 2011-03-01 11:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/47ad81d343e8 7023111: Add webrev script to make/scripts Reviewed-by: darcy + make/scripts/webrev.ksh Changeset: 258b21c7f4af Author: ohair Date: 2011-03-01 11:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/258b21c7f4af Merge Changeset: 27384dd2d8ed Author: ohair Date: 2011-03-03 15:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/27384dd2d8ed Merge Changeset: c6f380693342 Author: ohair Date: 2011-03-09 16:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/c6f380693342 7026167: Broken fastdebug only build Reviewed-by: cl ! Makefile Changeset: ddc2fcb3682f Author: cl Date: 2011-03-10 17:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/ddc2fcb3682f Added tag jdk7-b133 for changeset c6f380693342 ! .hgtags From john.coomes at oracle.com Thu Mar 10 20:38:51 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Mar 2011 04:38:51 +0000 Subject: hg: jdk7/hotspot/corba: Added tag jdk7-b133 for changeset 671fe2e623ff Message-ID: <20110311043856.2C67547069@hg.openjdk.java.net> Changeset: 918003855fa0 Author: cl Date: 2011-03-10 17:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/918003855fa0 Added tag jdk7-b133 for changeset 671fe2e623ff ! .hgtags From john.coomes at oracle.com Thu Mar 10 20:39:02 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Mar 2011 04:39:02 +0000 Subject: hg: jdk7/hotspot/jaxp: Added tag jdk7-b133 for changeset 8e1148c7911b Message-ID: <20110311043902.E9B0D4706A@hg.openjdk.java.net> Changeset: 2473f7027ac5 Author: cl Date: 2011-03-10 17:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/2473f7027ac5 Added tag jdk7-b133 for changeset 8e1148c7911b ! .hgtags From john.coomes at oracle.com Thu Mar 10 20:39:09 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Mar 2011 04:39:09 +0000 Subject: hg: jdk7/hotspot/jaxws: Added tag jdk7-b133 for changeset 359d0c8c00a0 Message-ID: <20110311043909.C0ABC4706B@hg.openjdk.java.net> Changeset: 8393aae2eb24 Author: cl Date: 2011-03-10 17:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/8393aae2eb24 Added tag jdk7-b133 for changeset 359d0c8c00a0 ! .hgtags From john.coomes at oracle.com Thu Mar 10 20:39:43 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 11 Mar 2011 04:39:43 +0000 Subject: hg: jdk7/hotspot/jdk: 13 new changesets Message-ID: <20110311044228.07F1D4706D@hg.openjdk.java.net> Changeset: 7931291bc5d3 Author: herrick Date: 2011-03-01 17:09 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7931291bc5d3 7021567: need to create jnlp javadoc for 64 bit bundles. Summary: need to create jnlp javadoc for 64 bit bundles. Reviewed-by: igor, ohair ! make/common/Release.gmk Changeset: c53711f82bfb Author: igor Date: 2011-03-08 14:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c53711f82bfb Merge - test/java/lang/Thread/StopBeforeStart.java Changeset: eb54e565c491 Author: ohair Date: 2011-02-26 09:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/eb54e565c491 7016175: HTML generated from new JavaDoc has tags added from makefile Reviewed-by: jjg ! make/common/shared/Defs-javadoc.gmk ! make/docs/Makefile Changeset: 391a9ef69036 Author: ohair Date: 2011-02-26 10:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/391a9ef69036 Merge Changeset: e88c8381eaca Author: ohair Date: 2011-02-26 12:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e88c8381eaca 7022237: Fix use of \" in the new "release" file at the top of the install, windows issues Reviewed-by: ohrstrom ! make/common/Release.gmk Changeset: 123dd69407f9 Author: ohair Date: 2011-02-26 12:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/123dd69407f9 Merge Changeset: ed1d4691da29 Author: ohrstrom Date: 2011-02-28 10:56 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ed1d4691da29 7021753: Add a build times report Summary: Report the build times at end of a jdkroot build. Reviewed-by: ohair ! make/common/shared/Defs-utils.gmk Changeset: f32f0ae3d873 Author: ohair Date: 2011-03-02 12:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f32f0ae3d873 Merge Changeset: 869cba583dd4 Author: ohair Date: 2011-03-02 13:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/869cba583dd4 7020815: REBASE should not be required for windows jdk repo builds - can't build with VS 2010 Express Reviewed-by: prr ! make/common/shared/Defs-utils.gmk ! make/common/shared/Sanity.gmk Changeset: e5cd10425e7e Author: ohair Date: 2011-03-03 07:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e5cd10425e7e Merge - src/share/classes/java/dyn/NoAccessException.java - src/share/classes/java/dyn/Switcher.java - test/java/lang/Thread/StopBeforeStart.java Changeset: c588355b5bb7 Author: ohair Date: 2011-03-03 15:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c588355b5bb7 Merge Changeset: 5e5f68a01d12 Author: ohair Date: 2011-03-08 16:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5e5f68a01d12 Merge ! make/common/Release.gmk Changeset: e947a98ea3c1 Author: cl Date: 2011-03-10 17:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e947a98ea3c1 Added tag jdk7-b133 for changeset 5e5f68a01d12 ! .hgtags From john.cuthbertson at oracle.com Fri Mar 11 17:34:50 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Fri, 11 Mar 2011 17:34:50 -0800 Subject: RFR(M): 7009266: G1: assert(obj->is_oop_or_null(true )) failed: Error Message-ID: <4D7ACDBA.7020003@oracle.com> Hi Everyone, I'm looking for a few of volunteers to review the changes that fix this assertion failure. The latest changes can be found at: http://cr.openjdk.java.net/~johnc/7009266/webrev.3/ and include changes based upon earlier internal reviews. The earlier changes are also on cr.openjdk.java.net for reference. Background: The G1 garbage collector includes a concurrent marking algorithm that makes use of snapshot-at-the-beginning or SATB. With this algorithm the GC will mark all objects that are reachable at the start of marking; objects that are allocated since the start of marking are implicitly considered live. In order to populate the "snapshot" of the object graph that existed at the start of marking, G1 employs a write barrier. When an object is stored into another object's field the write-barrier records the previous value of that field as it was part of the "snapshot" and concurrent marking will trace the sub-graph that is reachable from this previous value. Unfortunately, in the presence of Reference objects, SATB might not be sufficient to mark a referent object as live. Consider that, at the start of marking, we have a weakly reachable object i.e. an object where the only pointer to that object. If the referent is obtained from the Reference object and stored to another object's field (making the referent now strongly reachable and hence live) the G1 write barrier will record the field's previous value but not the value of the referent. If the referent object is strongly reachable from some other object that will be traced by concurrent marking, _or_ there is a subsequent assignment to the field where we have written the referent (in which case we record the previous value - the referent - in an SATB buffer) then the referent will be marked live. Otherwise the referent will not be marked. That is the issue that was causing the failure in this CR. There was a Logger object that was only reachable through a WeakReference at the start of concurrent marking. During marking the Logger object is obtained from the WeakReference and stored into a field of a live object. The G1 write barrier recorded the previous value in the field (as it is part of the snapshot at the start of marking). Since there was no other assignment to the live object's field and there was no other strong reference to the Logger object, the Logger object was not marked. At the end of concurrent marking the Logger object was considered dead and the link between the WeakReference and the Logger was severed by clearing the referent field during reference processing. To solve this (entirely in Hotspot and causing a performance overhead for G1 only) it was decided that the best approach was to intrinsify the Reference.get() method in the JIT compilers and add new interpreter entry points so that the value in the referent field will be recorded in an SATB buffer by the G1 pre-barrier code. The changes for Zero and the C++ interpreters are place holder routines but should be straight forward to implement. None of the individual changes is large - they are just well distributed around the JVM. :) Testing: white box test; eyeballing the generated compiled and interpreter code; the failing Kitchensink big-app on x86 (32/64 bit), sparc (32/64 bit), Xint, Xcomp (client and server), with and without G1; the GC test suite with and without G1; and jprt. Thanks and regards, JohnC From erik.trimble at oracle.com Fri Mar 11 22:43:18 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Sat, 12 Mar 2011 06:43:18 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20110312064323.78B60470C1@hg.openjdk.java.net> Changeset: 70b50ac7e2af Author: cl Date: 2011-03-10 17:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/70b50ac7e2af Added tag jdk7-b133 for changeset 1b3a350709e4 ! .hgtags Changeset: 447e6faab4a8 Author: trims Date: 2011-03-11 11:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/447e6faab4a8 Merge Changeset: 02e6fc2effd8 Author: trims Date: 2011-03-11 22:41 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/02e6fc2effd8 Merge From john.coomes at oracle.com Tue Mar 15 19:23:09 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Wed, 16 Mar 2011 02:23:09 +0000 Subject: hg: hsx/hsx20/baseline: 7018056: large pages not always enabled by default Message-ID: <20110316022314.7ED73471A8@hg.openjdk.java.net> Changeset: 1554773eb449 Author: jcoomes Date: 2011-03-06 11:37 -0800 URL: http://hg.openjdk.java.net/hsx/hsx20/baseline/rev/1554773eb449 7018056: large pages not always enabled by default Reviewed-by: phh, kvn ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp From erik.trimble at oracle.com Tue Mar 15 19:39:54 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Wed, 16 Mar 2011 02:39:54 +0000 Subject: hg: hsx/hsx20/baseline: 2 new changesets Message-ID: <20110316023957.A82A6471AA@hg.openjdk.java.net> Changeset: e8d7ce95c7fb Author: trims Date: 2011-03-10 18:50 -0800 URL: http://hg.openjdk.java.net/hsx/hsx20/baseline/rev/e8d7ce95c7fb 7026619: Bump the HS20 build number to 11 Summary: Update the HS20 build number to 11 Reviewed-by: jcoomes ! make/hotspot_version Changeset: f0f676c5a2c6 Author: trims Date: 2011-03-15 19:30 -0700 URL: http://hg.openjdk.java.net/hsx/hsx20/baseline/rev/f0f676c5a2c6 Added tag hs20-b11 for changeset e8d7ce95c7fb ! .hgtags From tom.rodriguez at oracle.com Wed Mar 16 15:13:34 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 16 Mar 2011 15:13:34 -0700 Subject: review (L) for 7017732: move static fields into Class to prepare for perm gen removal In-Reply-To: References: <33AEF62A-EE62-48FF-B9D6-B38A73443590@oracle.com> <4D533AB9.2060206@oracle.com> <3311F28E-EDAF-4270-B807-15200E044856@oracle.com> <4D53448E.60706@oracle.com> <0BB30DC5-E9D8-484A-975B-2A91375DD1DA@oracle.com> <3C5028C8-1C34-4267-916B-D9BEA461521D@oracle.com> <4D76D0FF.7030507@oracle.com> Message-ID: <0E9900F0-432F-4136-AC39-4E8B03DA1518@oracle.com> Hopefully this is the final version of this webrev. I found and fixed a preexisting bug with ScavengeRootsInCode that boiled down to a race between updating the oops in the nmethod and rewriting the oops in the instruction stream. The fix is to call fix_oop_relocations after all the nmethods have been visited by the scavenger. That changes nmethod.cpp and codeCache.cpp which you can see in the updated version of the webrev. I plan on pushing this to hotspot-gc once the weekly sync and promotion has been done. Thanks for all the reviews. tom On Mar 8, 2011, at 8:23 PM, Tom Rodriguez wrote: > > On Mar 8, 2011, at 4:59 PM, Vladimir Kozlov wrote: > >> Looks good to me, at least parts which I understand. >> >> I would prefer JavaObjectsInPerm be diagnostic flag so we can change its value in product VM. Or experimental since we remove it later, right? > > JohnC didn't seem to want it to be in the product and I don't have a strong opinion either way. Why don't we leave it develop for now? > >> >> vmStructs.cpp: add separation comment for klass_offset: >> >> /**************************************/ >> /* java_lang_Class (NOTE: incomplete) */ >> /**************************************/ >> >> static_field(java_lang_Class, klass_offset, int) > > I added that along with the rest of the offset fields in case we ever want them later. > >> >> it also miss java_lang_Class::hc_number_of_fake_int_fields. > > The SA doesn't really need to that value so there's no point in adding it. I went ahead and deleted the entry for java_lang_Class::hc_number_of_fake_oop_fields since it's unused. > > I updated the webrevs. Thanks! > > tom > >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> I discovered that I hadn't tested with CDS on and that required me to change the way that the synthetic fields in Class are laid out. When using the classes from the shared archive the class file parser isn't runtime so the synthetic fields had to be at some well known offset. The current synthetic oop fields are allocated right after the header and I needed 2 new int fields so I chose to allocate them just after the header and have the synthetic oop fields directly follow those. That required some small changes to the SA to use the computed value for klass_offset. The allocation of the Java mirror had to change as well. >>> I also brought over support for allocating the mirrors in the normal heap which exposed a few bugs in the oop visitors for arrayKlass. Some of them weren't calling their super visitor so _java_mirror wasn't being visited. arrayKlassKlass::oop_oop_iterate_m was also forwarding to oop_oop_iterate and ignoring the MemRegion. >>> I also added a separate flag to control whether the Class is in perm or not instead of overloading ScavengeRootsInCode. I called it JavaObjectsInPerm but I'm open to changing the name. This can also be used for the String changes that Coomes has. It can also be used for debugging once ScavengeRootsInCode is always enabled. >>> I reran all my tests and also ran Tony's gc_test_suite with all the various collectors, which showed the oop visitor issues I found. I did testing with -Xshare:dump as well. I've updated the full webrev itself and I also generated a incremental webrev to show what I changed since the last review. >>> http://cr.openjdk.java.net/~never/7017732 >>> http://cr.openjdk.java.net/~never/7017732_incremental >>> tom >>> On Feb 10, 2011, at 1:07 AM, Christian Thalinger wrote: >>>> Yes, looks good. -- Christian >>>> >>>> On Feb 10, 2011, at 3:40 AM, Tom Rodriguez wrote: >>>>> On Feb 9, 2011, at 5:51 PM, Vladimir Kozlov wrote: >>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> I removed the no longer correct part. Did you want something added? >>>>>> Is next description is still valid? >>>>>> >>>>>> 77 // [EMBEDDED Java vtable ] size in words = vtable_len >>>>>> 78 // [EMBEDDED static oop fields ] size in words = static_oop_fields_size >>>>>> 79 // [ static non-oop fields ] size in words = static_field_size - static_oop_fields_size >>>>>> 80 // [EMBEDDED nonstatic oop-map blocks] size in words = nonstatic_oop_map_size >>>>> I removed lines 78 and 79 but the rest is still correct I think. >>>>> >>>>>>>> I don't understand changes in Unsafe_StaticFieldBaseFromClass(), >>>>>>>> it should return handle but you just return original jobject. >>>>>>> We're supposed to return the object to use as the base of unsafe static field references. That's just the java.lang.Class instance which was passed in so we simply return it. What would you expect it to do? I guess we might want to unhandle it and return a new local one in case the original one wasn't a local handle. Is that what you're getting at? >>>>>> Thank you for explaining. Code is good. >>>>> I've changed it to return a new local handle as that seems less surprising. >>>>> >>>>> @@ -704,7 +704,7 @@ UNSAFE_ENTRY(jobject, Unsafe_StaticField >>>>> if (clazz == NULL) { THROW_0(vmSymbols::java_lang_NullPointerException()); } - return JNIHandles::make_local(env, java_lang_Class::as_klassOop(JNIHandles::resolve_non_null(clazz))); + return JNIHandles::make_local(env, JNIHandles::resolve_non_null(clazz)); UNSAFE_END >>>>> UNSAFE_ENTRY(void, Unsafe_EnsureClassInitialized(JNIEnv *env, jobject unsafe, jobject clazz)) >>>>> >>>>> I've regenerated the webrev. >>>>> >>>>> tom >>>>> >>>>>> Vladimir >>>>>> >>>>>>> tom >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> Tom Rodriguez wrote: >>>>>>>>> I've updated the webrev with this change, fixed a couple macro names that still referenced InstanceKlass and fixed the alignment of the continuation slashes. >>>>>>>>> tom >>>>>>>>> On Feb 9, 2011, at 3:52 AM, Christian Thalinger wrote: >>>>>>>>>> On Feb 8, 2011, at 11:01 PM, Tom Rodriguez wrote: >>>>>>>>>>> http://cr.openjdk.java.net/~never/7017732 >>>>>>>>>> src/cpu/x86/vm/c1_CodeStubs_x86.cpp: >>>>>>>>>> >>>>>>>>>> 315 Register tmp = rax; >>>>>>>>>> 316 Register tmp2 = rbx; >>>>>>>>>> 317 if (_obj == tmp) tmp = rcx; >>>>>>>>>> 318 else if (_obj == tmp2) tmp = rcx; >>>>>>>>>> 319 __ push(tmp); >>>>>>>>>> 320 __ push(tmp2); >>>>>>>>>> 321 __ get_thread(tmp); >>>>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>>>> 324 __ pop(tmp2); >>>>>>>>>> 325 __ pop(tmp); >>>>>>>>>> >>>>>>>>>> Why do you change tmp if _obj == tmp2? I think line 318 isn't required at all since if _obj == tmp2 it gets saved and restored anyway. What about this: >>>>>>>>>> >>>>>>>>>> 315 Register tmp = rax; >>>>>>>>>> 316 Register tmp2 = rbx; >>>>>>>>>> 319 __ push(tmp); >>>>>>>>>> 320 __ push(tmp2); >>>>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>>>> 321 __ get_thread(tmp); >>>>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>>>> 324 __ pop(tmp2); >>>>>>>>>> 325 __ pop(tmp); >>>>>>>>>> >>>>>>>>>> -- Christian >>>> > From vladimir.kozlov at oracle.com Wed Mar 16 15:45:14 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Mar 2011 15:45:14 -0700 Subject: review (L) for 7017732: move static fields into Class to prepare for perm gen removal In-Reply-To: <0E9900F0-432F-4136-AC39-4E8B03DA1518@oracle.com> References: <33AEF62A-EE62-48FF-B9D6-B38A73443590@oracle.com> <4D533AB9.2060206@oracle.com> <3311F28E-EDAF-4270-B807-15200E044856@oracle.com> <4D53448E.60706@oracle.com> <0BB30DC5-E9D8-484A-975B-2A91375DD1DA@oracle.com> <3C5028C8-1C34-4267-916B-D9BEA461521D@oracle.com> <4D76D0FF.7030507@oracle.com> <0E9900F0-432F-4136-AC39-4E8B03DA1518@oracle.com> Message-ID: <4D813D7A.3080503@oracle.com> Tom, It would be nice if you create a separate bug for this issue. Is http://cr.openjdk.java.net/~never/7017732/ webrev is the latest? Changes in few files are empty: src/share/vm/memory/referenceProcessor.cpp src/share/vm/utilities/globalDefinitions.hpp src/share/vm/memory/space.cpp universe.cpp: could you move next code into a separate method (I mean, for example, set_offset_of_Class_static_fields())?: + // Cache the start of the static fields + instanceMirrorKlass::set_offset_of_static_fields(instanceMirrorKlass::cast(SystemDictionary::Class_klass())->size_helper() << LogHeapWordSize); compile.cpp: Could you put parentheses around expressions in conditions code?: + if ((tinst->const_oop() != NULL) && + (tinst->klass() == ciEnv::current()->Class_klass()) && + (tinst->offset() >= (tinst->klass()->as_instance_klass()->size_helper() * wordSize))) { and in the following assert. The rest is looks good. Vladimir Tom Rodriguez wrote: > Hopefully this is the final version of this webrev. I found and fixed a preexisting bug with ScavengeRootsInCode that boiled down to a race between updating the oops in the nmethod and rewriting the oops in the instruction stream. The fix is to call fix_oop_relocations after all the nmethods have been visited by the scavenger. That changes nmethod.cpp and codeCache.cpp which you can see in the updated version of the webrev. I plan on pushing this to hotspot-gc once the weekly sync and promotion has been done. Thanks for all the reviews. > > tom > > On Mar 8, 2011, at 8:23 PM, Tom Rodriguez wrote: > >> On Mar 8, 2011, at 4:59 PM, Vladimir Kozlov wrote: >> >>> Looks good to me, at least parts which I understand. >>> >>> I would prefer JavaObjectsInPerm be diagnostic flag so we can change its value in product VM. Or experimental since we remove it later, right? >> JohnC didn't seem to want it to be in the product and I don't have a strong opinion either way. Why don't we leave it develop for now? >> >>> vmStructs.cpp: add separation comment for klass_offset: >>> >>> /**************************************/ >>> /* java_lang_Class (NOTE: incomplete) */ >>> /**************************************/ >>> >>> static_field(java_lang_Class, klass_offset, int) >> I added that along with the rest of the offset fields in case we ever want them later. >> >>> it also miss java_lang_Class::hc_number_of_fake_int_fields. >> The SA doesn't really need to that value so there's no point in adding it. I went ahead and deleted the entry for java_lang_Class::hc_number_of_fake_oop_fields since it's unused. >> >> I updated the webrevs. Thanks! >> >> tom >> >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> I discovered that I hadn't tested with CDS on and that required me to change the way that the synthetic fields in Class are laid out. When using the classes from the shared archive the class file parser isn't runtime so the synthetic fields had to be at some well known offset. The current synthetic oop fields are allocated right after the header and I needed 2 new int fields so I chose to allocate them just after the header and have the synthetic oop fields directly follow those. That required some small changes to the SA to use the computed value for klass_offset. The allocation of the Java mirror had to change as well. >>>> I also brought over support for allocating the mirrors in the normal heap which exposed a few bugs in the oop visitors for arrayKlass. Some of them weren't calling their super visitor so _java_mirror wasn't being visited. arrayKlassKlass::oop_oop_iterate_m was also forwarding to oop_oop_iterate and ignoring the MemRegion. >>>> I also added a separate flag to control whether the Class is in perm or not instead of overloading ScavengeRootsInCode. I called it JavaObjectsInPerm but I'm open to changing the name. This can also be used for the String changes that Coomes has. It can also be used for debugging once ScavengeRootsInCode is always enabled. >>>> I reran all my tests and also ran Tony's gc_test_suite with all the various collectors, which showed the oop visitor issues I found. I did testing with -Xshare:dump as well. I've updated the full webrev itself and I also generated a incremental webrev to show what I changed since the last review. >>>> http://cr.openjdk.java.net/~never/7017732 >>>> http://cr.openjdk.java.net/~never/7017732_incremental >>>> tom >>>> On Feb 10, 2011, at 1:07 AM, Christian Thalinger wrote: >>>>> Yes, looks good. -- Christian >>>>> >>>>> On Feb 10, 2011, at 3:40 AM, Tom Rodriguez wrote: >>>>>> On Feb 9, 2011, at 5:51 PM, Vladimir Kozlov wrote: >>>>>> >>>>>>> Tom Rodriguez wrote: >>>>>>>> I removed the no longer correct part. Did you want something added? >>>>>>> Is next description is still valid? >>>>>>> >>>>>>> 77 // [EMBEDDED Java vtable ] size in words = vtable_len >>>>>>> 78 // [EMBEDDED static oop fields ] size in words = static_oop_fields_size >>>>>>> 79 // [ static non-oop fields ] size in words = static_field_size - static_oop_fields_size >>>>>>> 80 // [EMBEDDED nonstatic oop-map blocks] size in words = nonstatic_oop_map_size >>>>>> I removed lines 78 and 79 but the rest is still correct I think. >>>>>> >>>>>>>>> I don't understand changes in Unsafe_StaticFieldBaseFromClass(), >>>>>>>>> it should return handle but you just return original jobject. >>>>>>>> We're supposed to return the object to use as the base of unsafe static field references. That's just the java.lang.Class instance which was passed in so we simply return it. What would you expect it to do? I guess we might want to unhandle it and return a new local one in case the original one wasn't a local handle. Is that what you're getting at? >>>>>>> Thank you for explaining. Code is good. >>>>>> I've changed it to return a new local handle as that seems less surprising. >>>>>> >>>>>> @@ -704,7 +704,7 @@ UNSAFE_ENTRY(jobject, Unsafe_StaticField >>>>>> if (clazz == NULL) { THROW_0(vmSymbols::java_lang_NullPointerException()); } - return JNIHandles::make_local(env, java_lang_Class::as_klassOop(JNIHandles::resolve_non_null(clazz))); + return JNIHandles::make_local(env, JNIHandles::resolve_non_null(clazz)); UNSAFE_END >>>>>> UNSAFE_ENTRY(void, Unsafe_EnsureClassInitialized(JNIEnv *env, jobject unsafe, jobject clazz)) >>>>>> >>>>>> I've regenerated the webrev. >>>>>> >>>>>> tom >>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>>> tom >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>> I've updated the webrev with this change, fixed a couple macro names that still referenced InstanceKlass and fixed the alignment of the continuation slashes. >>>>>>>>>> tom >>>>>>>>>> On Feb 9, 2011, at 3:52 AM, Christian Thalinger wrote: >>>>>>>>>>> On Feb 8, 2011, at 11:01 PM, Tom Rodriguez wrote: >>>>>>>>>>>> http://cr.openjdk.java.net/~never/7017732 >>>>>>>>>>> src/cpu/x86/vm/c1_CodeStubs_x86.cpp: >>>>>>>>>>> >>>>>>>>>>> 315 Register tmp = rax; >>>>>>>>>>> 316 Register tmp2 = rbx; >>>>>>>>>>> 317 if (_obj == tmp) tmp = rcx; >>>>>>>>>>> 318 else if (_obj == tmp2) tmp = rcx; >>>>>>>>>>> 319 __ push(tmp); >>>>>>>>>>> 320 __ push(tmp2); >>>>>>>>>>> 321 __ get_thread(tmp); >>>>>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>>>>> 324 __ pop(tmp2); >>>>>>>>>>> 325 __ pop(tmp); >>>>>>>>>>> >>>>>>>>>>> Why do you change tmp if _obj == tmp2? I think line 318 isn't required at all since if _obj == tmp2 it gets saved and restored anyway. What about this: >>>>>>>>>>> >>>>>>>>>>> 315 Register tmp = rax; >>>>>>>>>>> 316 Register tmp2 = rbx; >>>>>>>>>>> 319 __ push(tmp); >>>>>>>>>>> 320 __ push(tmp2); >>>>>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>>>>> 321 __ get_thread(tmp); >>>>>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>>>>> 324 __ pop(tmp2); >>>>>>>>>>> 325 __ pop(tmp); >>>>>>>>>>> >>>>>>>>>>> -- Christian > From tom.rodriguez at oracle.com Wed Mar 16 16:17:49 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 16 Mar 2011 16:17:49 -0700 Subject: review (L) for 7017732: move static fields into Class to prepare for perm gen removal In-Reply-To: <4D813D7A.3080503@oracle.com> References: <33AEF62A-EE62-48FF-B9D6-B38A73443590@oracle.com> <4D533AB9.2060206@oracle.com> <3311F28E-EDAF-4270-B807-15200E044856@oracle.com> <4D53448E.60706@oracle.com> <0BB30DC5-E9D8-484A-975B-2A91375DD1DA@oracle.com> <3C5028C8-1C34-4267-916B-D9BEA461521D@oracle.com> <4D76D0FF.7030507@oracle.com> <0E9900F0-432F-4136-AC39-4E8B03DA1518@oracle.com> <4D813D7A.3080503@oracle.com> Message-ID: On Mar 16, 2011, at 3:45 PM, Vladimir Kozlov wrote: > Tom, > > It would be nice if you create a separate bug for this issue. I can but it's impossible to test it outside of the context of my changes. I guess it's possible some existing JSR292 bug has the same underlying cause. I'll make a separate changeset for this piece but I'm going to push them together. > > Is http://cr.openjdk.java.net/~never/7017732/ webrev is the latest? > Changes in few files are empty: > > src/share/vm/memory/referenceProcessor.cpp > src/share/vm/utilities/globalDefinitions.hpp > src/share/vm/memory/space.cpp I've removed them. > > universe.cpp: could you move next code into a separate method > (I mean, for example, set_offset_of_Class_static_fields())?: > > + // Cache the start of the static fields > + instanceMirrorKlass::set_offset_of_static_fields(instanceMirrorKlass::cast(SystemDictionary::Class_klass())->size_helper() << LogHeapWordSize); Where would this new function be? > > compile.cpp: Could you put parentheses around expressions in conditions code?: > > + if ((tinst->const_oop() != NULL) && > + (tinst->klass() == ciEnv::current()->Class_klass()) && > + (tinst->offset() >= (tinst->klass()->as_instance_klass()->size_helper() * wordSize))) { Why does that need parens? There's nothing even vaguely ambiguous here. > > and in the following assert. What parens does it need? To group the &&s? > > The rest is looks good. Thanks! tom > > Vladimir > > > Tom Rodriguez wrote: >> Hopefully this is the final version of this webrev. I found and fixed a preexisting bug with ScavengeRootsInCode that boiled down to a race between updating the oops in the nmethod and rewriting the oops in the instruction stream. The fix is to call fix_oop_relocations after all the nmethods have been visited by the scavenger. That changes nmethod.cpp and codeCache.cpp which you can see in the updated version of the webrev. I plan on pushing this to hotspot-gc once the weekly sync and promotion has been done. Thanks for all the reviews. >> tom >> On Mar 8, 2011, at 8:23 PM, Tom Rodriguez wrote: >>> On Mar 8, 2011, at 4:59 PM, Vladimir Kozlov wrote: >>> >>>> Looks good to me, at least parts which I understand. >>>> >>>> I would prefer JavaObjectsInPerm be diagnostic flag so we can change its value in product VM. Or experimental since we remove it later, right? >>> JohnC didn't seem to want it to be in the product and I don't have a strong opinion either way. Why don't we leave it develop for now? >>> >>>> vmStructs.cpp: add separation comment for klass_offset: >>>> >>>> /**************************************/ >>>> /* java_lang_Class (NOTE: incomplete) */ >>>> /**************************************/ >>>> >>>> static_field(java_lang_Class, klass_offset, int) >>> I added that along with the rest of the offset fields in case we ever want them later. >>> >>>> it also miss java_lang_Class::hc_number_of_fake_int_fields. >>> The SA doesn't really need to that value so there's no point in adding it. I went ahead and deleted the entry for java_lang_Class::hc_number_of_fake_oop_fields since it's unused. >>> >>> I updated the webrevs. Thanks! >>> >>> tom >>> >>>> Thanks, >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> I discovered that I hadn't tested with CDS on and that required me to change the way that the synthetic fields in Class are laid out. When using the classes from the shared archive the class file parser isn't runtime so the synthetic fields had to be at some well known offset. The current synthetic oop fields are allocated right after the header and I needed 2 new int fields so I chose to allocate them just after the header and have the synthetic oop fields directly follow those. That required some small changes to the SA to use the computed value for klass_offset. The allocation of the Java mirror had to change as well. >>>>> I also brought over support for allocating the mirrors in the normal heap which exposed a few bugs in the oop visitors for arrayKlass. Some of them weren't calling their super visitor so _java_mirror wasn't being visited. arrayKlassKlass::oop_oop_iterate_m was also forwarding to oop_oop_iterate and ignoring the MemRegion. >>>>> I also added a separate flag to control whether the Class is in perm or not instead of overloading ScavengeRootsInCode. I called it JavaObjectsInPerm but I'm open to changing the name. This can also be used for the String changes that Coomes has. It can also be used for debugging once ScavengeRootsInCode is always enabled. >>>>> I reran all my tests and also ran Tony's gc_test_suite with all the various collectors, which showed the oop visitor issues I found. I did testing with -Xshare:dump as well. I've updated the full webrev itself and I also generated a incremental webrev to show what I changed since the last review. >>>>> http://cr.openjdk.java.net/~never/7017732 >>>>> http://cr.openjdk.java.net/~never/7017732_incremental >>>>> tom >>>>> On Feb 10, 2011, at 1:07 AM, Christian Thalinger wrote: >>>>>> Yes, looks good. -- Christian >>>>>> >>>>>> On Feb 10, 2011, at 3:40 AM, Tom Rodriguez wrote: >>>>>>> On Feb 9, 2011, at 5:51 PM, Vladimir Kozlov wrote: >>>>>>> >>>>>>>> Tom Rodriguez wrote: >>>>>>>>> I removed the no longer correct part. Did you want something added? >>>>>>>> Is next description is still valid? >>>>>>>> >>>>>>>> 77 // [EMBEDDED Java vtable ] size in words = vtable_len >>>>>>>> 78 // [EMBEDDED static oop fields ] size in words = static_oop_fields_size >>>>>>>> 79 // [ static non-oop fields ] size in words = static_field_size - static_oop_fields_size >>>>>>>> 80 // [EMBEDDED nonstatic oop-map blocks] size in words = nonstatic_oop_map_size >>>>>>> I removed lines 78 and 79 but the rest is still correct I think. >>>>>>> >>>>>>>>>> I don't understand changes in Unsafe_StaticFieldBaseFromClass(), >>>>>>>>>> it should return handle but you just return original jobject. >>>>>>>>> We're supposed to return the object to use as the base of unsafe static field references. That's just the java.lang.Class instance which was passed in so we simply return it. What would you expect it to do? I guess we might want to unhandle it and return a new local one in case the original one wasn't a local handle. Is that what you're getting at? >>>>>>>> Thank you for explaining. Code is good. >>>>>>> I've changed it to return a new local handle as that seems less surprising. >>>>>>> >>>>>>> @@ -704,7 +704,7 @@ UNSAFE_ENTRY(jobject, Unsafe_StaticField >>>>>>> if (clazz == NULL) { THROW_0(vmSymbols::java_lang_NullPointerException()); } - return JNIHandles::make_local(env, java_lang_Class::as_klassOop(JNIHandles::resolve_non_null(clazz))); + return JNIHandles::make_local(env, JNIHandles::resolve_non_null(clazz)); UNSAFE_END UNSAFE_ENTRY(void, Unsafe_EnsureClassInitialized(JNIEnv *env, jobject unsafe, jobject clazz)) >>>>>>> >>>>>>> I've regenerated the webrev. >>>>>>> >>>>>>> tom >>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> tom >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>>> I've updated the webrev with this change, fixed a couple macro names that still referenced InstanceKlass and fixed the alignment of the continuation slashes. >>>>>>>>>>> tom >>>>>>>>>>> On Feb 9, 2011, at 3:52 AM, Christian Thalinger wrote: >>>>>>>>>>>> On Feb 8, 2011, at 11:01 PM, Tom Rodriguez wrote: >>>>>>>>>>>>> http://cr.openjdk.java.net/~never/7017732 >>>>>>>>>>>> src/cpu/x86/vm/c1_CodeStubs_x86.cpp: >>>>>>>>>>>> >>>>>>>>>>>> 315 Register tmp = rax; >>>>>>>>>>>> 316 Register tmp2 = rbx; >>>>>>>>>>>> 317 if (_obj == tmp) tmp = rcx; >>>>>>>>>>>> 318 else if (_obj == tmp2) tmp = rcx; >>>>>>>>>>>> 319 __ push(tmp); >>>>>>>>>>>> 320 __ push(tmp2); >>>>>>>>>>>> 321 __ get_thread(tmp); >>>>>>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>>>>>> 324 __ pop(tmp2); >>>>>>>>>>>> 325 __ pop(tmp); >>>>>>>>>>>> >>>>>>>>>>>> Why do you change tmp if _obj == tmp2? I think line 318 isn't required at all since if _obj == tmp2 it gets saved and restored anyway. What about this: >>>>>>>>>>>> >>>>>>>>>>>> 315 Register tmp = rax; >>>>>>>>>>>> 316 Register tmp2 = rbx; >>>>>>>>>>>> 319 __ push(tmp); >>>>>>>>>>>> 320 __ push(tmp2); >>>>>>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>>>>>> 321 __ get_thread(tmp); >>>>>>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>>>>>> 324 __ pop(tmp2); >>>>>>>>>>>> 325 __ pop(tmp); >>>>>>>>>>>> >>>>>>>>>>>> -- Christian From y.s.ramakrishna at oracle.com Wed Mar 16 17:05:39 2011 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Wed, 16 Mar 2011 17:05:39 -0700 Subject: review (L) for 7017732: move static fields into Class to prepare for perm gen removal In-Reply-To: <0E9900F0-432F-4136-AC39-4E8B03DA1518@oracle.com> References: <33AEF62A-EE62-48FF-B9D6-B38A73443590@oracle.com> <4D533AB9.2060206@oracle.com> <3311F28E-EDAF-4270-B807-15200E044856@oracle.com> <4D53448E.60706@oracle.com> <0BB30DC5-E9D8-484A-975B-2A91375DD1DA@oracle.com> <3C5028C8-1C34-4267-916B-D9BEA461521D@oracle.com> <4D76D0FF.7030507@oracle.com> <0E9900F0-432F-4136-AC39-4E8B03DA1518@oracle.com> Message-ID: <4D815053.2030506@oracle.com> Hi Tom -- ah, now that i went and looked at the code and the bug you filed (thanks!) i understand the problem, and your fix. I agree that there was a race before and that your moving the fix_oop_relocations() into that epilogue method effectively fixes that by delaying the latter until the scavenge is effectively complete. -- ramki PS: Ideally i'd like this to some day get integrated into a subsequent parallel weak oops phase of the GC infrastructure so that it can be done MT once weak oops processing is made entirely parallel, and also since it feels like the kind of work that's done for weak roots. I am guessing the lack of parallelism in this phase is nothing to lose one's sleep over at the moment (and may be never, but still FWIW). On 03/16/11 15:13, Tom Rodriguez wrote: > Hopefully this is the final version of this webrev. I found and fixed a preexisting bug with ScavengeRootsInCode that boiled down to a race between updating the oops in the nmethod and rewriting the oops in the instruction stream. The fix is to call fix_oop_relocations after all the nmethods have been visited by the scavenger. That changes nmethod.cpp and codeCache.cpp which you can see in the updated version of the webrev. I plan on pushing this to hotspot-gc once the weekly sync and promotion has been done. Thanks for all the reviews. > > tom From y.s.ramakrishna at oracle.com Wed Mar 16 17:10:57 2011 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Wed, 16 Mar 2011 17:10:57 -0700 Subject: review (L) for 7017732: move static fields into Class to prepare for perm gen removal In-Reply-To: <4D815053.2030506@oracle.com> References: <33AEF62A-EE62-48FF-B9D6-B38A73443590@oracle.com> <4D533AB9.2060206@oracle.com> <3311F28E-EDAF-4270-B807-15200E044856@oracle.com> <4D53448E.60706@oracle.com> <0BB30DC5-E9D8-484A-975B-2A91375DD1DA@oracle.com> <3C5028C8-1C34-4267-916B-D9BEA461521D@oracle.com> <4D76D0FF.7030507@oracle.com> <0E9900F0-432F-4136-AC39-4E8B03DA1518@oracle.com> <4D815053.2030506@oracle.com> Message-ID: <4D815191.5020900@oracle.com> Never mind that remark. I see that in the case of the parallel collectors, this does get done in parallel and is in fact MT-safe. Sorry for my confusion. -- ramki On 03/16/11 17:05, Y. S. Ramakrishna wrote: > Hi Tom -- > > ah, now that i went and looked at the code and the bug you filed (thanks!) > i understand the problem, and your fix. I agree that there was a race > before > and that your moving the fix_oop_relocations() into that epilogue method > effectively fixes that by delaying the latter until the scavenge is > effectively complete. > > -- ramki > > PS: Ideally i'd like this to some day get integrated into a subsequent > parallel > weak oops phase of the GC infrastructure so that it can be done MT once > weak oops processing is made entirely parallel, and also since it feels > like the kind of work that's done for weak roots. > I am guessing the lack of parallelism in this phase is nothing to lose > one's sleep over at the moment (and may be never, but still FWIW). > > On 03/16/11 15:13, Tom Rodriguez wrote: >> Hopefully this is the final version of this webrev. I found and fixed >> a preexisting bug with ScavengeRootsInCode that boiled down to a race >> between updating the oops in the nmethod and rewriting the oops in the >> instruction stream. The fix is to call fix_oop_relocations after all >> the nmethods have been visited by the scavenger. That changes >> nmethod.cpp and codeCache.cpp which you can see in the updated version >> of the webrev. I plan on pushing this to hotspot-gc once the weekly >> sync and promotion has been done. Thanks for all the reviews. >> >> tom From vladimir.kozlov at oracle.com Wed Mar 16 17:39:15 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Mar 2011 17:39:15 -0700 Subject: review (L) for 7017732: move static fields into Class to prepare for perm gen removal In-Reply-To: References: <33AEF62A-EE62-48FF-B9D6-B38A73443590@oracle.com> <4D533AB9.2060206@oracle.com> <3311F28E-EDAF-4270-B807-15200E044856@oracle.com> <4D53448E.60706@oracle.com> <0BB30DC5-E9D8-484A-975B-2A91375DD1DA@oracle.com> <3C5028C8-1C34-4267-916B-D9BEA461521D@oracle.com> <4D76D0FF.7030507@oracle.com> <0E9900F0-432F-4136-AC39-4E8B03DA1518@oracle.com> <4D813D7A.3080503@oracle.com> Message-ID: <4D815833.8000701@oracle.com> Tom Rodriguez wrote: > On Mar 16, 2011, at 3:45 PM, Vladimir Kozlov wrote: > >> Tom, >> >> It would be nice if you create a separate bug for this issue. > > I can but it's impossible to test it outside of the context of my changes. I guess it's possible some existing JSR292 bug has the same underlying cause. I'll make a separate changeset for this piece but I'm going to push them together. Pushing together is fine. I only want separate changesets. > >> universe.cpp: could you move next code into a separate method >> (I mean, for example, set_offset_of_Class_static_fields())?: >> >> + // Cache the start of the static fields >> + instanceMirrorKlass::set_offset_of_static_fields(instanceMirrorKlass::cast(SystemDictionary::Class_klass())->size_helper() << LogHeapWordSize); > > Where would this new function be? Can you do next since it is the only use of set_offset_of_static_fields()?: + static void set_offset_of_static_fields() { + int offset = cast(SystemDictionary::Class_klass())->size_helper() << LogHeapWordSize); + assert(_offset_of_static_fields == 0, "once"); + _offset_of_static_fields = offset; + } > >> compile.cpp: Could you put parentheses around expressions in conditions code?: >> >> + if ((tinst->const_oop() != NULL) && >> + (tinst->klass() == ciEnv::current()->Class_klass()) && >> + (tinst->offset() >= (tinst->klass()->as_instance_klass()->size_helper() * wordSize))) { > > Why does that need parens? There's nothing even vaguely ambiguous here. For a developer (me :) ) it is easier to read such expressions when they have parens. OK, you can put parens only around '*' expression. > >> and in the following assert. > > What parens does it need? To group the &&s? yes, to group &&s. Vladimir > >> The rest is looks good. > > Thanks! > > tom > >> Vladimir >> >> >> Tom Rodriguez wrote: >>> Hopefully this is the final version of this webrev. I found and fixed a preexisting bug with ScavengeRootsInCode that boiled down to a race between updating the oops in the nmethod and rewriting the oops in the instruction stream. The fix is to call fix_oop_relocations after all the nmethods have been visited by the scavenger. That changes nmethod.cpp and codeCache.cpp which you can see in the updated version of the webrev. I plan on pushing this to hotspot-gc once the weekly sync and promotion has been done. Thanks for all the reviews. >>> tom >>> On Mar 8, 2011, at 8:23 PM, Tom Rodriguez wrote: >>>> On Mar 8, 2011, at 4:59 PM, Vladimir Kozlov wrote: >>>> >>>>> Looks good to me, at least parts which I understand. >>>>> >>>>> I would prefer JavaObjectsInPerm be diagnostic flag so we can change its value in product VM. Or experimental since we remove it later, right? >>>> JohnC didn't seem to want it to be in the product and I don't have a strong opinion either way. Why don't we leave it develop for now? >>>> >>>>> vmStructs.cpp: add separation comment for klass_offset: >>>>> >>>>> /**************************************/ >>>>> /* java_lang_Class (NOTE: incomplete) */ >>>>> /**************************************/ >>>>> >>>>> static_field(java_lang_Class, klass_offset, int) >>>> I added that along with the rest of the offset fields in case we ever want them later. >>>> >>>>> it also miss java_lang_Class::hc_number_of_fake_int_fields. >>>> The SA doesn't really need to that value so there's no point in adding it. I went ahead and deleted the entry for java_lang_Class::hc_number_of_fake_oop_fields since it's unused. >>>> >>>> I updated the webrevs. Thanks! >>>> >>>> tom >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> I discovered that I hadn't tested with CDS on and that required me to change the way that the synthetic fields in Class are laid out. When using the classes from the shared archive the class file parser isn't runtime so the synthetic fields had to be at some well known offset. The current synthetic oop fields are allocated right after the header and I needed 2 new int fields so I chose to allocate them just after the header and have the synthetic oop fields directly follow those. That required some small changes to the SA to use the computed value for klass_offset. The allocation of the Java mirror had to change as well. >>>>>> I also brought over support for allocating the mirrors in the normal heap which exposed a few bugs in the oop visitors for arrayKlass. Some of them weren't calling their super visitor so _java_mirror wasn't being visited. arrayKlassKlass::oop_oop_iterate_m was also forwarding to oop_oop_iterate and ignoring the MemRegion. >>>>>> I also added a separate flag to control whether the Class is in perm or not instead of overloading ScavengeRootsInCode. I called it JavaObjectsInPerm but I'm open to changing the name. This can also be used for the String changes that Coomes has. It can also be used for debugging once ScavengeRootsInCode is always enabled. >>>>>> I reran all my tests and also ran Tony's gc_test_suite with all the various collectors, which showed the oop visitor issues I found. I did testing with -Xshare:dump as well. I've updated the full webrev itself and I also generated a incremental webrev to show what I changed since the last review. >>>>>> http://cr.openjdk.java.net/~never/7017732 >>>>>> http://cr.openjdk.java.net/~never/7017732_incremental >>>>>> tom >>>>>> On Feb 10, 2011, at 1:07 AM, Christian Thalinger wrote: >>>>>>> Yes, looks good. -- Christian >>>>>>> >>>>>>> On Feb 10, 2011, at 3:40 AM, Tom Rodriguez wrote: >>>>>>>> On Feb 9, 2011, at 5:51 PM, Vladimir Kozlov wrote: >>>>>>>> >>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>> I removed the no longer correct part. Did you want something added? >>>>>>>>> Is next description is still valid? >>>>>>>>> >>>>>>>>> 77 // [EMBEDDED Java vtable ] size in words = vtable_len >>>>>>>>> 78 // [EMBEDDED static oop fields ] size in words = static_oop_fields_size >>>>>>>>> 79 // [ static non-oop fields ] size in words = static_field_size - static_oop_fields_size >>>>>>>>> 80 // [EMBEDDED nonstatic oop-map blocks] size in words = nonstatic_oop_map_size >>>>>>>> I removed lines 78 and 79 but the rest is still correct I think. >>>>>>>> >>>>>>>>>>> I don't understand changes in Unsafe_StaticFieldBaseFromClass(), >>>>>>>>>>> it should return handle but you just return original jobject. >>>>>>>>>> We're supposed to return the object to use as the base of unsafe static field references. That's just the java.lang.Class instance which was passed in so we simply return it. What would you expect it to do? I guess we might want to unhandle it and return a new local one in case the original one wasn't a local handle. Is that what you're getting at? >>>>>>>>> Thank you for explaining. Code is good. >>>>>>>> I've changed it to return a new local handle as that seems less surprising. >>>>>>>> >>>>>>>> @@ -704,7 +704,7 @@ UNSAFE_ENTRY(jobject, Unsafe_StaticField >>>>>>>> if (clazz == NULL) { THROW_0(vmSymbols::java_lang_NullPointerException()); } - return JNIHandles::make_local(env, java_lang_Class::as_klassOop(JNIHandles::resolve_non_null(clazz))); + return JNIHandles::make_local(env, JNIHandles::resolve_non_null(clazz)); UNSAFE_END UNSAFE_ENTRY(void, Unsafe_EnsureClassInitialized(JNIEnv *env, jobject unsafe, jobject clazz )) >>>>>>>> >>>>>>>> I've regenerated the webrev. >>>>>>>> >>>>>>>> tom >>>>>>>> >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>>> tom >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>>>> I've updated the webrev with this change, fixed a couple macro names that still referenced InstanceKlass and fixed the alignment of the continuation slashes. >>>>>>>>>>>> tom >>>>>>>>>>>> On Feb 9, 2011, at 3:52 AM, Christian Thalinger wrote: >>>>>>>>>>>>> On Feb 8, 2011, at 11:01 PM, Tom Rodriguez wrote: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~never/7017732 >>>>>>>>>>>>> src/cpu/x86/vm/c1_CodeStubs_x86.cpp: >>>>>>>>>>>>> >>>>>>>>>>>>> 315 Register tmp = rax; >>>>>>>>>>>>> 316 Register tmp2 = rbx; >>>>>>>>>>>>> 317 if (_obj == tmp) tmp = rcx; >>>>>>>>>>>>> 318 else if (_obj == tmp2) tmp = rcx; >>>>>>>>>>>>> 319 __ push(tmp); >>>>>>>>>>>>> 320 __ push(tmp2); >>>>>>>>>>>>> 321 __ get_thread(tmp); >>>>>>>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>>>>>>> 324 __ pop(tmp2); >>>>>>>>>>>>> 325 __ pop(tmp); >>>>>>>>>>>>> >>>>>>>>>>>>> Why do you change tmp if _obj == tmp2? I think line 318 isn't required at all since if _obj == tmp2 it gets saved and restored anyway. What about this: >>>>>>>>>>>>> >>>>>>>>>>>>> 315 Register tmp = rax; >>>>>>>>>>>>> 316 Register tmp2 = rbx; >>>>>>>>>>>>> 319 __ push(tmp); >>>>>>>>>>>>> 320 __ push(tmp2); >>>>>>>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>>>>>>> 321 __ get_thread(tmp); >>>>>>>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>>>>>>> 324 __ pop(tmp2); >>>>>>>>>>>>> 325 __ pop(tmp); >>>>>>>>>>>>> >>>>>>>>>>>>> -- Christian > From tom.rodriguez at oracle.com Wed Mar 16 19:01:59 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 16 Mar 2011 19:01:59 -0700 Subject: review (L) for 7017732: move static fields into Class to prepare for perm gen removal In-Reply-To: <4D815833.8000701@oracle.com> References: <33AEF62A-EE62-48FF-B9D6-B38A73443590@oracle.com> <4D533AB9.2060206@oracle.com> <3311F28E-EDAF-4270-B807-15200E044856@oracle.com> <4D53448E.60706@oracle.com> <0BB30DC5-E9D8-484A-975B-2A91375DD1DA@oracle.com> <3C5028C8-1C34-4267-916B-D9BEA461521D@oracle.com> <4D76D0FF.7030507@oracle.com> <0E9900F0-432F-4136-AC39-4E8B03DA1518@oracle.com> <4D813D7A.3080503@oracle.com> <4D815833.8000701@oracle.com> Message-ID: <5987C053-0561-44FB-B0FD-7A13BAF7B5E4@oracle.com> On Mar 16, 2011, at 5:39 PM, Vladimir Kozlov wrote: > Tom Rodriguez wrote: >> On Mar 16, 2011, at 3:45 PM, Vladimir Kozlov wrote: >>> Tom, >>> >>> It would be nice if you create a separate bug for this issue. >> I can but it's impossible to test it outside of the context of my changes. I guess it's possible some existing JSR292 bug has the same underlying cause. I'll make a separate changeset for this piece but I'm going to push them together. > > Pushing together is fine. I only want separate changesets. Ok. > >>> universe.cpp: could you move next code into a separate method >>> (I mean, for example, set_offset_of_Class_static_fields())?: >>> >>> + // Cache the start of the static fields >>> + instanceMirrorKlass::set_offset_of_static_fields(instanceMirrorKlass::cast(SystemDictionary::Class_klass())->size_helper() << LogHeapWordSize); >> Where would this new function be? > > Can you do next since it is the only use of set_offset_of_static_fields()?: > > + static void set_offset_of_static_fields() { > + int offset = cast(SystemDictionary::Class_klass())->size_helper() << LogHeapWordSize); > + assert(_offset_of_static_fields == 0, "once"); > + _offset_of_static_fields = offset; > + } Yeah that looks better. I did: static void init_offset_of_static_fields() { // Cache the offset of the static fields in the Class instance assert(_offset_of_static_fields == 0, "once"); _offset_of_static_fields = instanceMirrorKlass::cast(SystemDictionary::Class_klass())->size_helper() << LogHeapWordSize; } > >>> compile.cpp: Could you put parentheses around expressions in conditions code?: >>> >>> + if ((tinst->const_oop() != NULL) && >>> + (tinst->klass() == ciEnv::current()->Class_klass()) && >>> + (tinst->offset() >= (tinst->klass()->as_instance_klass()->size_helper() * wordSize))) { >> Why does that need parens? There's nothing even vaguely ambiguous here. > > For a developer (me :) ) it is easier to read such expressions when they have parens. OK, you can put parens only around '*' expression. I agree it can make the grouping more obvious when you are mixing || and && in complex expressions, like a || b || c && d && e || f, but for simple expressions it seems like too much. Too many unnecessary parentheses is just as hard to read. It always leaves me with the feeling that maybe I'm misreading the expression since I have to go back and make sure they match the evaluation order I'm reading from the operators. Anyway, I'll add them around the *. > >>> and in the following assert. >> What parens does it need? To group the &&s? > > yes, to group &&s. Ok. tom > > Vladimir > >>> The rest is looks good. >> Thanks! >> tom >>> Vladimir >>> >>> >>> Tom Rodriguez wrote: >>>> Hopefully this is the final version of this webrev. I found and fixed a preexisting bug with ScavengeRootsInCode that boiled down to a race between updating the oops in the nmethod and rewriting the oops in the instruction stream. The fix is to call fix_oop_relocations after all the nmethods have been visited by the scavenger. That changes nmethod.cpp and codeCache.cpp which you can see in the updated version of the webrev. I plan on pushing this to hotspot-gc once the weekly sync and promotion has been done. Thanks for all the reviews. >>>> tom >>>> On Mar 8, 2011, at 8:23 PM, Tom Rodriguez wrote: >>>>> On Mar 8, 2011, at 4:59 PM, Vladimir Kozlov wrote: >>>>> >>>>>> Looks good to me, at least parts which I understand. >>>>>> >>>>>> I would prefer JavaObjectsInPerm be diagnostic flag so we can change its value in product VM. Or experimental since we remove it later, right? >>>>> JohnC didn't seem to want it to be in the product and I don't have a strong opinion either way. Why don't we leave it develop for now? >>>>> >>>>>> vmStructs.cpp: add separation comment for klass_offset: >>>>>> >>>>>> /**************************************/ >>>>>> /* java_lang_Class (NOTE: incomplete) */ >>>>>> /**************************************/ >>>>>> >>>>>> static_field(java_lang_Class, klass_offset, int) >>>>> I added that along with the rest of the offset fields in case we ever want them later. >>>>> >>>>>> it also miss java_lang_Class::hc_number_of_fake_int_fields. >>>>> The SA doesn't really need to that value so there's no point in adding it. I went ahead and deleted the entry for java_lang_Class::hc_number_of_fake_oop_fields since it's unused. >>>>> >>>>> I updated the webrevs. Thanks! >>>>> >>>>> tom >>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> I discovered that I hadn't tested with CDS on and that required me to change the way that the synthetic fields in Class are laid out. When using the classes from the shared archive the class file parser isn't runtime so the synthetic fields had to be at some well known offset. The current synthetic oop fields are allocated right after the header and I needed 2 new int fields so I chose to allocate them just after the header and have the synthetic oop fields directly follow those. That required some small changes to the SA to use the computed value for klass_offset. The allocation of the Java mirror had to change as well. >>>>>>> I also brought over support for allocating the mirrors in the normal heap which exposed a few bugs in the oop visitors for arrayKlass. Some of them weren't calling their super visitor so _java_mirror wasn't being visited. arrayKlassKlass::oop_oop_iterate_m was also forwarding to oop_oop_iterate and ignoring the MemRegion. >>>>>>> I also added a separate flag to control whether the Class is in perm or not instead of overloading ScavengeRootsInCode. I called it JavaObjectsInPerm but I'm open to changing the name. This can also be used for the String changes that Coomes has. It can also be used for debugging once ScavengeRootsInCode is always enabled. >>>>>>> I reran all my tests and also ran Tony's gc_test_suite with all the various collectors, which showed the oop visitor issues I found. I did testing with -Xshare:dump as well. I've updated the full webrev itself and I also generated a incremental webrev to show what I changed since the last review. >>>>>>> http://cr.openjdk.java.net/~never/7017732 >>>>>>> http://cr.openjdk.java.net/~never/7017732_incremental >>>>>>> tom >>>>>>> On Feb 10, 2011, at 1:07 AM, Christian Thalinger wrote: >>>>>>>> Yes, looks good. -- Christian >>>>>>>> >>>>>>>> On Feb 10, 2011, at 3:40 AM, Tom Rodriguez wrote: >>>>>>>>> On Feb 9, 2011, at 5:51 PM, Vladimir Kozlov wrote: >>>>>>>>> >>>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>>> I removed the no longer correct part. Did you want something added? >>>>>>>>>> Is next description is still valid? >>>>>>>>>> >>>>>>>>>> 77 // [EMBEDDED Java vtable ] size in words = vtable_len >>>>>>>>>> 78 // [EMBEDDED static oop fields ] size in words = static_oop_fields_size >>>>>>>>>> 79 // [ static non-oop fields ] size in words = static_field_size - static_oop_fields_size >>>>>>>>>> 80 // [EMBEDDED nonstatic oop-map blocks] size in words = nonstatic_oop_map_size >>>>>>>>> I removed lines 78 and 79 but the rest is still correct I think. >>>>>>>>> >>>>>>>>>>>> I don't understand changes in Unsafe_StaticFieldBaseFromClass(), >>>>>>>>>>>> it should return handle but you just return original jobject. >>>>>>>>>>> We're supposed to return the object to use as the base of unsafe static field references. That's just the java.lang.Class instance which was passed in so we simply return it. What would you expect it to do? I guess we might want to unhandle it and return a new local one in case the original one wasn't a local handle. Is that what you're getting at? >>>>>>>>>> Thank you for explaining. Code is good. >>>>>>>>> I've changed it to return a new local handle as that seems less surprising. >>>>>>>>> >>>>>>>>> @@ -704,7 +704,7 @@ UNSAFE_ENTRY(jobject, Unsafe_StaticField >>>>>>>>> if (clazz == NULL) { THROW_0(vmSymbols::java_lang_NullPointerException()); } - return JNIHandles::make_local(env, java_lang_Class::as_klassOop(JNIHandles::resolve_non_null(clazz))); + return JNIHandles::make_local(env, JNIHandles::resolve_non_null(clazz)); UNSAFE_END UNSAFE_ENTRY(void, Unsafe_EnsureClassInitialized(JNIEnv *env, jobject unsafe, jobject clazz > )) >>>>>>>>> >>>>>>>>> I've regenerated the webrev. >>>>>>>>> >>>>>>>>> tom >>>>>>>>> >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>>> tom >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>>>>> I've updated the webrev with this change, fixed a couple macro names that still referenced InstanceKlass and fixed the alignment of the continuation slashes. >>>>>>>>>>>>> tom >>>>>>>>>>>>> On Feb 9, 2011, at 3:52 AM, Christian Thalinger wrote: >>>>>>>>>>>>>> On Feb 8, 2011, at 11:01 PM, Tom Rodriguez wrote: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~never/7017732 >>>>>>>>>>>>>> src/cpu/x86/vm/c1_CodeStubs_x86.cpp: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 315 Register tmp = rax; >>>>>>>>>>>>>> 316 Register tmp2 = rbx; >>>>>>>>>>>>>> 317 if (_obj == tmp) tmp = rcx; >>>>>>>>>>>>>> 318 else if (_obj == tmp2) tmp = rcx; >>>>>>>>>>>>>> 319 __ push(tmp); >>>>>>>>>>>>>> 320 __ push(tmp2); >>>>>>>>>>>>>> 321 __ get_thread(tmp); >>>>>>>>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>>>>>>>> 324 __ pop(tmp2); >>>>>>>>>>>>>> 325 __ pop(tmp); >>>>>>>>>>>>>> >>>>>>>>>>>>>> Why do you change tmp if _obj == tmp2? I think line 318 isn't required at all since if _obj == tmp2 it gets saved and restored anyway. What about this: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 315 Register tmp = rax; >>>>>>>>>>>>>> 316 Register tmp2 = rbx; >>>>>>>>>>>>>> 319 __ push(tmp); >>>>>>>>>>>>>> 320 __ push(tmp2); >>>>>>>>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>>>>>>>> 321 __ get_thread(tmp); >>>>>>>>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>>>>>>>> 324 __ pop(tmp2); >>>>>>>>>>>>>> 325 __ pop(tmp); >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- Christian From vladimir.kozlov at oracle.com Wed Mar 16 19:15:27 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Mar 2011 19:15:27 -0700 Subject: review (L) for 7017732: move static fields into Class to prepare for perm gen removal In-Reply-To: <5987C053-0561-44FB-B0FD-7A13BAF7B5E4@oracle.com> References: <33AEF62A-EE62-48FF-B9D6-B38A73443590@oracle.com> <4D533AB9.2060206@oracle.com> <3311F28E-EDAF-4270-B807-15200E044856@oracle.com> <4D53448E.60706@oracle.com> <0BB30DC5-E9D8-484A-975B-2A91375DD1DA@oracle.com> <3C5028C8-1C34-4267-916B-D9BEA461521D@oracle.com> <4D76D0FF.7030507@oracle.com> <0E9900F0-432F-4136-AC39-4E8B03DA1518@oracle.com> <4D813D7A.3080503@oracle.com> <4D815833.8000701@oracle.com> <5987C053-0561-44FB-B0FD-7A13BAF7B5E4@oracle.com> Message-ID: <4D816EBF.7040208@oracle.com> Tom Rodriguez wrote: > On Mar 16, 2011, at 5:39 PM, Vladimir Kozlov wrote: > > Yeah that looks better. I did: > > static void init_offset_of_static_fields() { > // Cache the offset of the static fields in the Class instance > assert(_offset_of_static_fields == 0, "once"); > _offset_of_static_fields = instanceMirrorKlass::cast(SystemDictionary::Class_klass())->size_helper() << LogHeapWordSize; > } I think you don't need instanceMirrorKlass:: for cast() since it is inside this class. Vladimir > >>>> compile.cpp: Could you put parentheses around expressions in conditions code?: >>>> >>>> + if ((tinst->const_oop() != NULL) && >>>> + (tinst->klass() == ciEnv::current()->Class_klass()) && >>>> + (tinst->offset() >= (tinst->klass()->as_instance_klass()->size_helper() * wordSize))) { >>> Why does that need parens? There's nothing even vaguely ambiguous here. >> For a developer (me :) ) it is easier to read such expressions when they have parens. OK, you can put parens only around '*' expression. > > I agree it can make the grouping more obvious when you are mixing || and && in complex expressions, like a || b || c && d && e || f, but for simple expressions it seems like too much. Too many unnecessary parentheses is just as hard to read. It always leaves me with the feeling that maybe I'm misreading the expression since I have to go back and make sure they match the evaluation order I'm reading from the operators. Anyway, I'll add them around the *. > >>>> and in the following assert. >>> What parens does it need? To group the &&s? >> yes, to group &&s. > > Ok. > > tom > >> Vladimir >> >>>> The rest is looks good. >>> Thanks! >>> tom >>>> Vladimir >>>> >>>> >>>> Tom Rodriguez wrote: >>>>> Hopefully this is the final version of this webrev. I found and fixed a preexisting bug with ScavengeRootsInCode that boiled down to a race between updating the oops in the nmethod and rewriting the oops in the instruction stream. The fix is to call fix_oop_relocations after all the nmethods have been visited by the scavenger. That changes nmethod.cpp and codeCache.cpp which you can see in the updated version of the webrev. I plan on pushing this to hotspot-gc once the weekly sync and promotion has been done. Thanks for all the reviews. >>>>> tom >>>>> On Mar 8, 2011, at 8:23 PM, Tom Rodriguez wrote: >>>>>> On Mar 8, 2011, at 4:59 PM, Vladimir Kozlov wrote: >>>>>> >>>>>>> Looks good to me, at least parts which I understand. >>>>>>> >>>>>>> I would prefer JavaObjectsInPerm be diagnostic flag so we can change its value in product VM. Or experimental since we remove it later, right? >>>>>> JohnC didn't seem to want it to be in the product and I don't have a strong opinion either way. Why don't we leave it develop for now? >>>>>> >>>>>>> vmStructs.cpp: add separation comment for klass_offset: >>>>>>> >>>>>>> /**************************************/ >>>>>>> /* java_lang_Class (NOTE: incomplete) */ >>>>>>> /**************************************/ >>>>>>> >>>>>>> static_field(java_lang_Class, klass_offset, int) >>>>>> I added that along with the rest of the offset fields in case we ever want them later. >>>>>> >>>>>>> it also miss java_lang_Class::hc_number_of_fake_int_fields. >>>>>> The SA doesn't really need to that value so there's no point in adding it. I went ahead and deleted the entry for java_lang_Class::hc_number_of_fake_oop_fields since it's unused. >>>>>> >>>>>> I updated the webrevs. Thanks! >>>>>> >>>>>> tom >>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> Tom Rodriguez wrote: >>>>>>>> I discovered that I hadn't tested with CDS on and that required me to change the way that the synthetic fields in Class are laid out. When using the classes from the shared archive the class file parser isn't runtime so the synthetic fields had to be at some well known offset. The current synthetic oop fields are allocated right after the header and I needed 2 new int fields so I chose to allocate them just after the header and have the synthetic oop fields directly follow those. That required some small changes to the SA to use the computed value for klass_offset. The allocation of the Java mirror had to change as well. >>>>>>>> I also brought over support for allocating the mirrors in the normal heap which exposed a few bugs in the oop visitors for arrayKlass. Some of them weren't calling their super visitor so _java_mirror wasn't being visited. arrayKlassKlass::oop_oop_iterate_m was also forwarding to oop_oop_iterate and ignoring the MemRegion. >>>>>>>> I also added a separate flag to control whether the Class is in perm or not instead of overloading ScavengeRootsInCode. I called it JavaObjectsInPerm but I'm open to changing the name. This can also be used for the String changes that Coomes has. It can also be used for debugging once ScavengeRootsInCode is always enabled. >>>>>>>> I reran all my tests and also ran Tony's gc_test_suite with all the various collectors, which showed the oop visitor issues I found. I did testing with -Xshare:dump as well. I've updated the full webrev itself and I also generated a incremental webrev to show what I changed since the last review. >>>>>>>> http://cr.openjdk.java.net/~never/7017732 >>>>>>>> http://cr.openjdk.java.net/~never/7017732_incremental >>>>>>>> tom >>>>>>>> On Feb 10, 2011, at 1:07 AM, Christian Thalinger wrote: >>>>>>>>> Yes, looks good. -- Christian >>>>>>>>> >>>>>>>>> On Feb 10, 2011, at 3:40 AM, Tom Rodriguez wrote: >>>>>>>>>> On Feb 9, 2011, at 5:51 PM, Vladimir Kozlov wrote: >>>>>>>>>> >>>>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>>>> I removed the no longer correct part. Did you want something added? >>>>>>>>>>> Is next description is still valid? >>>>>>>>>>> >>>>>>>>>>> 77 // [EMBEDDED Java vtable ] size in words = vtable_len >>>>>>>>>>> 78 // [EMBEDDED static oop fields ] size in words = static_oop_fields_size >>>>>>>>>>> 79 // [ static non-oop fields ] size in words = static_field_size - static_oop_fields_size >>>>>>>>>>> 80 // [EMBEDDED nonstatic oop-map blocks] size in words = nonstatic_oop_map_size >>>>>>>>>> I removed lines 78 and 79 but the rest is still correct I think. >>>>>>>>>> >>>>>>>>>>>>> I don't understand changes in Unsafe_StaticFieldBaseFromClass(), >>>>>>>>>>>>> it should return handle but you just return original jobject. >>>>>>>>>>>> We're supposed to return the object to use as the base of unsafe static field references. That's just the java.lang.Class instance which was passed in so we simply return it. What would you expect it to do? I guess we might want to unhandle it and return a new local one in case the original one wasn't a local handle. Is that what you're getting at? >>>>>>>>>>> Thank you for explaining. Code is good. >>>>>>>>>> I've changed it to return a new local handle as that seems less surprising. >>>>>>>>>> >>>>>>>>>> @@ -704,7 +704,7 @@ UNSAFE_ENTRY(jobject, Unsafe_StaticField >>>>>>>>>> if (clazz == NULL) { THROW_0(vmSymbols::java_lang_NullPointerException()); } - return JNIHandles::make_local(env, java_lang_Class::as_klassOop(JNIHandles::resolve_non_null(clazz))); + return JNIHandles::make_local(env, JNIHandles::resolve_non_null(clazz)); UNSAFE_END UNSAFE_ENTRY(void, Unsafe_EnsureClassInitialized(JNIEnv *env, jobject unsafe, jobject cla zz >> )) >>>>>>>>>> I've regenerated the webrev. >>>>>>>>>> >>>>>>>>>> tom >>>>>>>>>> >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>>> tom >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Vladimir >>>>>>>>>>>>> >>>>>>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>>>>>> I've updated the webrev with this change, fixed a couple macro names that still referenced InstanceKlass and fixed the alignment of the continuation slashes. >>>>>>>>>>>>>> tom >>>>>>>>>>>>>> On Feb 9, 2011, at 3:52 AM, Christian Thalinger wrote: >>>>>>>>>>>>>>> On Feb 8, 2011, at 11:01 PM, Tom Rodriguez wrote: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~never/7017732 >>>>>>>>>>>>>>> src/cpu/x86/vm/c1_CodeStubs_x86.cpp: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 315 Register tmp = rax; >>>>>>>>>>>>>>> 316 Register tmp2 = rbx; >>>>>>>>>>>>>>> 317 if (_obj == tmp) tmp = rcx; >>>>>>>>>>>>>>> 318 else if (_obj == tmp2) tmp = rcx; >>>>>>>>>>>>>>> 319 __ push(tmp); >>>>>>>>>>>>>>> 320 __ push(tmp2); >>>>>>>>>>>>>>> 321 __ get_thread(tmp); >>>>>>>>>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>>>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>>>>>>>>> 324 __ pop(tmp2); >>>>>>>>>>>>>>> 325 __ pop(tmp); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Why do you change tmp if _obj == tmp2? I think line 318 isn't required at all since if _obj == tmp2 it gets saved and restored anyway. What about this: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 315 Register tmp = rax; >>>>>>>>>>>>>>> 316 Register tmp2 = rbx; >>>>>>>>>>>>>>> 319 __ push(tmp); >>>>>>>>>>>>>>> 320 __ push(tmp2); >>>>>>>>>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>>>>>>>>> 321 __ get_thread(tmp); >>>>>>>>>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>>>>>>>>> 324 __ pop(tmp2); >>>>>>>>>>>>>>> 325 __ pop(tmp); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- Christian > From tom.rodriguez at oracle.com Wed Mar 16 22:34:19 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 16 Mar 2011 22:34:19 -0700 Subject: review (L) for 7017732: move static fields into Class to prepare for perm gen removal In-Reply-To: <4D816EBF.7040208@oracle.com> References: <33AEF62A-EE62-48FF-B9D6-B38A73443590@oracle.com> <4D533AB9.2060206@oracle.com> <3311F28E-EDAF-4270-B807-15200E044856@oracle.com> <4D53448E.60706@oracle.com> <0BB30DC5-E9D8-484A-975B-2A91375DD1DA@oracle.com> <3C5028C8-1C34-4267-916B-D9BEA461521D@oracle.com> <4D76D0FF.7030507@oracle.com> <0E9900F0-432F-4136-AC39-4E8B03DA1518@oracle.com> <4D813D7A.3080503@oracle.com> <4D815833.8000701@oracle.com> <5987C053-0561-44FB-B0FD-7A13BAF7B5E4@oracle.com> <4D816EBF.7040208@oracle.com> Message-ID: <9849D115-8DD3-485D-9D21-4E4E284DA706@oracle.com> On Mar 16, 2011, at 7:15 PM, Vladimir Kozlov wrote: > Tom Rodriguez wrote: >> On Mar 16, 2011, at 5:39 PM, Vladimir Kozlov wrote: >> Yeah that looks better. I did: >> static void init_offset_of_static_fields() { >> // Cache the offset of the static fields in the Class instance assert(_offset_of_static_fields == 0, "once"); >> _offset_of_static_fields = instanceMirrorKlass::cast(SystemDictionary::Class_klass())->size_helper() << LogHeapWordSize; >> } > > I think you don't need instanceMirrorKlass:: for cast() since it is inside this class. I agree but I think it's more obvious what it's being to cast to with it. tom > > Vladimir > >>>>> compile.cpp: Could you put parentheses around expressions in conditions code?: >>>>> >>>>> + if ((tinst->const_oop() != NULL) && >>>>> + (tinst->klass() == ciEnv::current()->Class_klass()) && >>>>> + (tinst->offset() >= (tinst->klass()->as_instance_klass()->size_helper() * wordSize))) { >>>> Why does that need parens? There's nothing even vaguely ambiguous here. >>> For a developer (me :) ) it is easier to read such expressions when they have parens. OK, you can put parens only around '*' expression. >> I agree it can make the grouping more obvious when you are mixing || and && in complex expressions, like a || b || c && d && e || f, but for simple expressions it seems like too much. Too many unnecessary parentheses is just as hard to read. It always leaves me with the feeling that maybe I'm misreading the expression since I have to go back and make sure they match the evaluation order I'm reading from the operators. Anyway, I'll add them around the *. >>>>> and in the following assert. >>>> What parens does it need? To group the &&s? >>> yes, to group &&s. >> Ok. >> tom >>> Vladimir >>> >>>>> The rest is looks good. >>>> Thanks! >>>> tom >>>>> Vladimir >>>>> >>>>> >>>>> Tom Rodriguez wrote: >>>>>> Hopefully this is the final version of this webrev. I found and fixed a preexisting bug with ScavengeRootsInCode that boiled down to a race between updating the oops in the nmethod and rewriting the oops in the instruction stream. The fix is to call fix_oop_relocations after all the nmethods have been visited by the scavenger. That changes nmethod.cpp and codeCache.cpp which you can see in the updated version of the webrev. I plan on pushing this to hotspot-gc once the weekly sync and promotion has been done. Thanks for all the reviews. >>>>>> tom >>>>>> On Mar 8, 2011, at 8:23 PM, Tom Rodriguez wrote: >>>>>>> On Mar 8, 2011, at 4:59 PM, Vladimir Kozlov wrote: >>>>>>> >>>>>>>> Looks good to me, at least parts which I understand. >>>>>>>> >>>>>>>> I would prefer JavaObjectsInPerm be diagnostic flag so we can change its value in product VM. Or experimental since we remove it later, right? >>>>>>> JohnC didn't seem to want it to be in the product and I don't have a strong opinion either way. Why don't we leave it develop for now? >>>>>>> >>>>>>>> vmStructs.cpp: add separation comment for klass_offset: >>>>>>>> >>>>>>>> /**************************************/ >>>>>>>> /* java_lang_Class (NOTE: incomplete) */ >>>>>>>> /**************************************/ >>>>>>>> >>>>>>>> static_field(java_lang_Class, klass_offset, int) >>>>>>> I added that along with the rest of the offset fields in case we ever want them later. >>>>>>> >>>>>>>> it also miss java_lang_Class::hc_number_of_fake_int_fields. >>>>>>> The SA doesn't really need to that value so there's no point in adding it. I went ahead and deleted the entry for java_lang_Class::hc_number_of_fake_oop_fields since it's unused. >>>>>>> >>>>>>> I updated the webrevs. Thanks! >>>>>>> >>>>>>> tom >>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> Tom Rodriguez wrote: >>>>>>>>> I discovered that I hadn't tested with CDS on and that required me to change the way that the synthetic fields in Class are laid out. When using the classes from the shared archive the class file parser isn't runtime so the synthetic fields had to be at some well known offset. The current synthetic oop fields are allocated right after the header and I needed 2 new int fields so I chose to allocate them just after the header and have the synthetic oop fields directly follow those. That required some small changes to the SA to use the computed value for klass_offset. The allocation of the Java mirror had to change as well. >>>>>>>>> I also brought over support for allocating the mirrors in the normal heap which exposed a few bugs in the oop visitors for arrayKlass. Some of them weren't calling their super visitor so _java_mirror wasn't being visited. arrayKlassKlass::oop_oop_iterate_m was also forwarding to oop_oop_iterate and ignoring the MemRegion. >>>>>>>>> I also added a separate flag to control whether the Class is in perm or not instead of overloading ScavengeRootsInCode. I called it JavaObjectsInPerm but I'm open to changing the name. This can also be used for the String changes that Coomes has. It can also be used for debugging once ScavengeRootsInCode is always enabled. >>>>>>>>> I reran all my tests and also ran Tony's gc_test_suite with all the various collectors, which showed the oop visitor issues I found. I did testing with -Xshare:dump as well. I've updated the full webrev itself and I also generated a incremental webrev to show what I changed since the last review. >>>>>>>>> http://cr.openjdk.java.net/~never/7017732 >>>>>>>>> http://cr.openjdk.java.net/~never/7017732_incremental >>>>>>>>> tom >>>>>>>>> On Feb 10, 2011, at 1:07 AM, Christian Thalinger wrote: >>>>>>>>>> Yes, looks good. -- Christian >>>>>>>>>> >>>>>>>>>> On Feb 10, 2011, at 3:40 AM, Tom Rodriguez wrote: >>>>>>>>>>> On Feb 9, 2011, at 5:51 PM, Vladimir Kozlov wrote: >>>>>>>>>>> >>>>>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>>>>> I removed the no longer correct part. Did you want something added? >>>>>>>>>>>> Is next description is still valid? >>>>>>>>>>>> >>>>>>>>>>>> 77 // [EMBEDDED Java vtable ] size in words = vtable_len >>>>>>>>>>>> 78 // [EMBEDDED static oop fields ] size in words = static_oop_fields_size >>>>>>>>>>>> 79 // [ static non-oop fields ] size in words = static_field_size - static_oop_fields_size >>>>>>>>>>>> 80 // [EMBEDDED nonstatic oop-map blocks] size in words = nonstatic_oop_map_size >>>>>>>>>>> I removed lines 78 and 79 but the rest is still correct I think. >>>>>>>>>>> >>>>>>>>>>>>>> I don't understand changes in Unsafe_StaticFieldBaseFromClass(), >>>>>>>>>>>>>> it should return handle but you just return original jobject. >>>>>>>>>>>>> We're supposed to return the object to use as the base of unsafe static field references. That's just the java.lang.Class instance which was passed in so we simply return it. What would you expect it to do? I guess we might want to unhandle it and return a new local one in case the original one wasn't a local handle. Is that what you're getting at? >>>>>>>>>>>> Thank you for explaining. Code is good. >>>>>>>>>>> I've changed it to return a new local handle as that seems less surprising. >>>>>>>>>>> >>>>>>>>>>> @@ -704,7 +704,7 @@ UNSAFE_ENTRY(jobject, Unsafe_StaticField >>>>>>>>>>> if (clazz == NULL) { THROW_0(vmSymbols::java_lang_NullPointerException()); } - return JNIHandles::make_local(env, java_lang_Class::as_klassOop(JNIHandles::resolve_non_null(clazz))); + return JNIHandles::make_local(env, JNIHandles::resolve_non_null(clazz)); UNSAFE_END UNSAFE_ENTRY(void, Unsafe_EnsureClassInitialized(JNIEnv *env, jobject unsafe, jobject cla > zz >>> )) >>>>>>>>>>> I've regenerated the webrev. >>>>>>>>>>> >>>>>>>>>>> tom >>>>>>>>>>> >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>>> tom >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>>>>>>> I've updated the webrev with this change, fixed a couple macro names that still referenced InstanceKlass and fixed the alignment of the continuation slashes. >>>>>>>>>>>>>>> tom >>>>>>>>>>>>>>> On Feb 9, 2011, at 3:52 AM, Christian Thalinger wrote: >>>>>>>>>>>>>>>> On Feb 8, 2011, at 11:01 PM, Tom Rodriguez wrote: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~never/7017732 >>>>>>>>>>>>>>>> src/cpu/x86/vm/c1_CodeStubs_x86.cpp: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 315 Register tmp = rax; >>>>>>>>>>>>>>>> 316 Register tmp2 = rbx; >>>>>>>>>>>>>>>> 317 if (_obj == tmp) tmp = rcx; >>>>>>>>>>>>>>>> 318 else if (_obj == tmp2) tmp = rcx; >>>>>>>>>>>>>>>> 319 __ push(tmp); >>>>>>>>>>>>>>>> 320 __ push(tmp2); >>>>>>>>>>>>>>>> 321 __ get_thread(tmp); >>>>>>>>>>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>>>>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>>>>>>>>>> 324 __ pop(tmp2); >>>>>>>>>>>>>>>> 325 __ pop(tmp); >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Why do you change tmp if _obj == tmp2? I think line 318 isn't required at all since if _obj == tmp2 it gets saved and restored anyway. What about this: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 315 Register tmp = rax; >>>>>>>>>>>>>>>> 316 Register tmp2 = rbx; >>>>>>>>>>>>>>>> 319 __ push(tmp); >>>>>>>>>>>>>>>> 320 __ push(tmp2); >>>>>>>>>>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>>>>>>>>>> 321 __ get_thread(tmp); >>>>>>>>>>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>>>>>>>>>> 324 __ pop(tmp2); >>>>>>>>>>>>>>>> 325 __ pop(tmp); >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- Christian From vladimir.kozlov at oracle.com Thu Mar 17 09:32:38 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Mar 2011 09:32:38 -0700 Subject: review (L) for 7017732: move static fields into Class to prepare for perm gen removal In-Reply-To: <9849D115-8DD3-485D-9D21-4E4E284DA706@oracle.com> References: <33AEF62A-EE62-48FF-B9D6-B38A73443590@oracle.com> <4D533AB9.2060206@oracle.com> <3311F28E-EDAF-4270-B807-15200E044856@oracle.com> <4D53448E.60706@oracle.com> <0BB30DC5-E9D8-484A-975B-2A91375DD1DA@oracle.com> <3C5028C8-1C34-4267-916B-D9BEA461521D@oracle.com> <4D76D0FF.7030507@oracle.com> <0E9900F0-432F-4136-AC39-4E8B03DA1518@oracle.com> <4D813D7A.3080503@oracle.com> <4D815833.8000701@oracle.com> <5987C053-0561-44FB-B0FD-7A13BAF7B5E4@oracle.com> <4D816EBF.7040208@oracle.com> <9849D115-8DD3-485D-9D21-4E4E284DA706@oracle.com> Message-ID: <4D8237A6.8030705@oracle.com> OK. Vladimir On 3/16/11 10:34 PM, Tom Rodriguez wrote: > > On Mar 16, 2011, at 7:15 PM, Vladimir Kozlov wrote: > >> Tom Rodriguez wrote: >>> On Mar 16, 2011, at 5:39 PM, Vladimir Kozlov wrote: >>> Yeah that looks better. I did: >>> static void init_offset_of_static_fields() { >>> // Cache the offset of the static fields in the Class instance assert(_offset_of_static_fields == 0, "once"); >>> _offset_of_static_fields = instanceMirrorKlass::cast(SystemDictionary::Class_klass())->size_helper()<< LogHeapWordSize; >>> } >> >> I think you don't need instanceMirrorKlass:: for cast() since it is inside this class. > > I agree but I think it's more obvious what it's being to cast to with it. > > tom > >> >> Vladimir >> >>>>>> compile.cpp: Could you put parentheses around expressions in conditions code?: >>>>>> >>>>>> + if ((tinst->const_oop() != NULL)&& >>>>>> + (tinst->klass() == ciEnv::current()->Class_klass())&& >>>>>> + (tinst->offset()>= (tinst->klass()->as_instance_klass()->size_helper() * wordSize))) { >>>>> Why does that need parens? There's nothing even vaguely ambiguous here. >>>> For a developer (me :) ) it is easier to read such expressions when they have parens. OK, you can put parens only around '*' expression. >>> I agree it can make the grouping more obvious when you are mixing || and&& in complex expressions, like a || b || c&& d&& e || f, but for simple expressions it seems like too much. Too many unnecessary parentheses is just as hard to read. It always leaves me with the feeling that maybe I'm misreading the expression since I have to go back and make sure they match the evaluation order I'm reading from the operators. Anyway, I'll add them around the *. >>>>>> and in the following assert. >>>>> What parens does it need? To group the&&s? >>>> yes, to group&&s. >>> Ok. >>> tom >>>> Vladimir >>>> >>>>>> The rest is looks good. >>>>> Thanks! >>>>> tom >>>>>> Vladimir >>>>>> >>>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> Hopefully this is the final version of this webrev. I found and fixed a preexisting bug with ScavengeRootsInCode that boiled down to a race between updating the oops in the nmethod and rewriting the oops in the instruction stream. The fix is to call fix_oop_relocations after all the nmethods have been visited by the scavenger. That changes nmethod.cpp and codeCache.cpp which you can see in the updated version of the webrev. I plan on pushing this to hotspot-gc once the weekly sync and promotion has been done. Thanks for all the reviews. >>>>>>> tom >>>>>>> On Mar 8, 2011, at 8:23 PM, Tom Rodriguez wrote: >>>>>>>> On Mar 8, 2011, at 4:59 PM, Vladimir Kozlov wrote: >>>>>>>> >>>>>>>>> Looks good to me, at least parts which I understand. >>>>>>>>> >>>>>>>>> I would prefer JavaObjectsInPerm be diagnostic flag so we can change its value in product VM. Or experimental since we remove it later, right? >>>>>>>> JohnC didn't seem to want it to be in the product and I don't have a strong opinion either way. Why don't we leave it develop for now? >>>>>>>> >>>>>>>>> vmStructs.cpp: add separation comment for klass_offset: >>>>>>>>> >>>>>>>>> /**************************************/ >>>>>>>>> /* java_lang_Class (NOTE: incomplete) */ >>>>>>>>> /**************************************/ >>>>>>>>> >>>>>>>>> static_field(java_lang_Class, klass_offset, int) >>>>>>>> I added that along with the rest of the offset fields in case we ever want them later. >>>>>>>> >>>>>>>>> it also miss java_lang_Class::hc_number_of_fake_int_fields. >>>>>>>> The SA doesn't really need to that value so there's no point in adding it. I went ahead and deleted the entry for java_lang_Class::hc_number_of_fake_oop_fields since it's unused. >>>>>>>> >>>>>>>> I updated the webrevs. Thanks! >>>>>>>> >>>>>>>> tom >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>> I discovered that I hadn't tested with CDS on and that required me to change the way that the synthetic fields in Class are laid out. When using the classes from the shared archive the class file parser isn't runtime so the synthetic fields had to be at some well known offset. The current synthetic oop fields are allocated right after the header and I needed 2 new int fields so I chose to allocate them just after the header and have the synthetic oop fields directly follow those. That required some small changes to the SA to use the computed value for klass_offset. The allocation of the Java mirror had to change as well. >>>>>>>>>> I also brought over support for allocating the mirrors in the normal heap which exposed a few bugs in the oop visitors for arrayKlass. Some of them weren't calling their super visitor so _java_mirror wasn't being visited. arrayKlassKlass::oop_oop_iterate_m was also forwarding to oop_oop_iterate and ignoring the MemRegion. >>>>>>>>>> I also added a separate flag to control whether the Class is in perm or not instead of overloading ScavengeRootsInCode. I called it JavaObjectsInPerm but I'm open to changing the name. This can also be used for the String changes that Coomes has. It can also be used for debugging once ScavengeRootsInCode is always enabled. >>>>>>>>>> I reran all my tests and also ran Tony's gc_test_suite with all the various collectors, which showed the oop visitor issues I found. I did testing with -Xshare:dump as well. I've updated the full webrev itself and I also generated a incremental webrev to show what I changed since the last review. >>>>>>>>>> http://cr.openjdk.java.net/~never/7017732 >>>>>>>>>> http://cr.openjdk.java.net/~never/7017732_incremental >>>>>>>>>> tom >>>>>>>>>> On Feb 10, 2011, at 1:07 AM, Christian Thalinger wrote: >>>>>>>>>>> Yes, looks good. -- Christian >>>>>>>>>>> >>>>>>>>>>> On Feb 10, 2011, at 3:40 AM, Tom Rodriguez wrote: >>>>>>>>>>>> On Feb 9, 2011, at 5:51 PM, Vladimir Kozlov wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>>>>>> I removed the no longer correct part. Did you want something added? >>>>>>>>>>>>> Is next description is still valid? >>>>>>>>>>>>> >>>>>>>>>>>>> 77 // [EMBEDDED Java vtable ] size in words = vtable_len >>>>>>>>>>>>> 78 // [EMBEDDED static oop fields ] size in words = static_oop_fields_size >>>>>>>>>>>>> 79 // [ static non-oop fields ] size in words = static_field_size - static_oop_fields_size >>>>>>>>>>>>> 80 // [EMBEDDED nonstatic oop-map blocks] size in words = nonstatic_oop_map_size >>>>>>>>>>>> I removed lines 78 and 79 but the rest is still correct I think. >>>>>>>>>>>> >>>>>>>>>>>>>>> I don't understand changes in Unsafe_StaticFieldBaseFromClass(), >>>>>>>>>>>>>>> it should return handle but you just return original jobject. >>>>>>>>>>>>>> We're supposed to return the object to use as the base of unsafe static field references. That's just the java.lang.Class instance which was passed in so we simply return it. What would you expect it to do? I guess we might want to unhandle it and return a new local one in case the original one wasn't a local handle. Is that what you're getting at? >>>>>>>>>>>>> Thank you for explaining. Code is good. >>>>>>>>>>>> I've changed it to return a new local handle as that seems less surprising. >>>>>>>>>>>> >>>>>>>>>>>> @@ -704,7 +704,7 @@ UNSAFE_ENTRY(jobject, Unsafe_StaticField >>>>>>>>>>>> if (clazz == NULL) { THROW_0(vmSymbols::java_lang_NullPointerException()); } - return JNIHandles::make_local(env, java_lang_Class::as_klassOop(JNIHandles::resolve_non_null(clazz))); + return JNIHandles::make_local(env, JNIHandles::resolve_non_null(clazz)); UNSAFE_END UNSAFE_ENTRY(void, Unsafe_EnsureClassInitialized(JNIEnv *env, jobject unsafe, jobject c la >> zz >>>> )) >>>>>>>>>>>> I've regenerated the webrev. >>>>>>>>>>>> >>>>>>>>>>>> tom >>>>>>>>>>>> >>>>>>>>>>>>> Vladimir >>>>>>>>>>>>> >>>>>>>>>>>>>> tom >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>>>>>>>> I've updated the webrev with this change, fixed a couple macro names that still referenced InstanceKlass and fixed the alignment of the continuation slashes. >>>>>>>>>>>>>>>> tom >>>>>>>>>>>>>>>> On Feb 9, 2011, at 3:52 AM, Christian Thalinger wrote: >>>>>>>>>>>>>>>>> On Feb 8, 2011, at 11:01 PM, Tom Rodriguez wrote: >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~never/7017732 >>>>>>>>>>>>>>>>> src/cpu/x86/vm/c1_CodeStubs_x86.cpp: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 315 Register tmp = rax; >>>>>>>>>>>>>>>>> 316 Register tmp2 = rbx; >>>>>>>>>>>>>>>>> 317 if (_obj == tmp) tmp = rcx; >>>>>>>>>>>>>>>>> 318 else if (_obj == tmp2) tmp = rcx; >>>>>>>>>>>>>>>>> 319 __ push(tmp); >>>>>>>>>>>>>>>>> 320 __ push(tmp2); >>>>>>>>>>>>>>>>> 321 __ get_thread(tmp); >>>>>>>>>>>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>>>>>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>>>>>>>>>>> 324 __ pop(tmp2); >>>>>>>>>>>>>>>>> 325 __ pop(tmp); >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Why do you change tmp if _obj == tmp2? I think line 318 isn't required at all since if _obj == tmp2 it gets saved and restored anyway. What about this: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 315 Register tmp = rax; >>>>>>>>>>>>>>>>> 316 Register tmp2 = rbx; >>>>>>>>>>>>>>>>> 319 __ push(tmp); >>>>>>>>>>>>>>>>> 320 __ push(tmp2); >>>>>>>>>>>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>>>>>>>>>>> 321 __ get_thread(tmp); >>>>>>>>>>>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>>>>>>>>>>> 324 __ pop(tmp2); >>>>>>>>>>>>>>>>> 325 __ pop(tmp); >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- Christian > From christian.thalinger at oracle.com Thu Mar 17 09:50:09 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 17 Mar 2011 17:50:09 +0100 Subject: review (L) for 7017732: move static fields into Class to prepare for perm gen removal In-Reply-To: References: <33AEF62A-EE62-48FF-B9D6-B38A73443590@oracle.com> <4D533AB9.2060206@oracle.com> <3311F28E-EDAF-4270-B807-15200E044856@oracle.com> <4D53448E.60706@oracle.com> <0BB30DC5-E9D8-484A-975B-2A91375DD1DA@oracle.com> <3C5028C8-1C34-4267-916B-D9BEA461521D@oracle.com> <4D76D0FF.7030507@oracle.com> <0E9900F0-432F-4136-AC39-4E8B03DA1518@oracle.com> <4D813D7A.3080503@oracle.com> Message-ID: On Mar 17, 2011, at 12:17 AM, Tom Rodriguez wrote: > > On Mar 16, 2011, at 3:45 PM, Vladimir Kozlov wrote: > >> Tom, >> >> It would be nice if you create a separate bug for this issue. > > I can but it's impossible to test it outside of the context of my changes. I guess it's possible some existing JSR292 bug has the same underlying cause. That would be nice. I'll check all remaining bugs on my list as soon as this is pushed. -- Christian > I'll make a separate changeset for this piece but I'm going to push them together. > >> >> Is http://cr.openjdk.java.net/~never/7017732/ webrev is the latest? >> Changes in few files are empty: >> >> src/share/vm/memory/referenceProcessor.cpp >> src/share/vm/utilities/globalDefinitions.hpp >> src/share/vm/memory/space.cpp > > I've removed them. > >> >> universe.cpp: could you move next code into a separate method >> (I mean, for example, set_offset_of_Class_static_fields())?: >> >> + // Cache the start of the static fields >> + instanceMirrorKlass::set_offset_of_static_fields(instanceMirrorKlass::cast(SystemDictionary::Class_klass())->size_helper() << LogHeapWordSize); > > Where would this new function be? > >> >> compile.cpp: Could you put parentheses around expressions in conditions code?: >> >> + if ((tinst->const_oop() != NULL) && >> + (tinst->klass() == ciEnv::current()->Class_klass()) && >> + (tinst->offset() >= (tinst->klass()->as_instance_klass()->size_helper() * wordSize))) { > > Why does that need parens? There's nothing even vaguely ambiguous here. > >> >> and in the following assert. > > What parens does it need? To group the &&s? > >> >> The rest is looks good. > > Thanks! > > tom > >> >> Vladimir >> >> >> Tom Rodriguez wrote: >>> Hopefully this is the final version of this webrev. I found and fixed a preexisting bug with ScavengeRootsInCode that boiled down to a race between updating the oops in the nmethod and rewriting the oops in the instruction stream. The fix is to call fix_oop_relocations after all the nmethods have been visited by the scavenger. That changes nmethod.cpp and codeCache.cpp which you can see in the updated version of the webrev. I plan on pushing this to hotspot-gc once the weekly sync and promotion has been done. Thanks for all the reviews. >>> tom >>> On Mar 8, 2011, at 8:23 PM, Tom Rodriguez wrote: >>>> On Mar 8, 2011, at 4:59 PM, Vladimir Kozlov wrote: >>>> >>>>> Looks good to me, at least parts which I understand. >>>>> >>>>> I would prefer JavaObjectsInPerm be diagnostic flag so we can change its value in product VM. Or experimental since we remove it later, right? >>>> JohnC didn't seem to want it to be in the product and I don't have a strong opinion either way. Why don't we leave it develop for now? >>>> >>>>> vmStructs.cpp: add separation comment for klass_offset: >>>>> >>>>> /**************************************/ >>>>> /* java_lang_Class (NOTE: incomplete) */ >>>>> /**************************************/ >>>>> >>>>> static_field(java_lang_Class, klass_offset, int) >>>> I added that along with the rest of the offset fields in case we ever want them later. >>>> >>>>> it also miss java_lang_Class::hc_number_of_fake_int_fields. >>>> The SA doesn't really need to that value so there's no point in adding it. I went ahead and deleted the entry for java_lang_Class::hc_number_of_fake_oop_fields since it's unused. >>>> >>>> I updated the webrevs. Thanks! >>>> >>>> tom >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> I discovered that I hadn't tested with CDS on and that required me to change the way that the synthetic fields in Class are laid out. When using the classes from the shared archive the class file parser isn't runtime so the synthetic fields had to be at some well known offset. The current synthetic oop fields are allocated right after the header and I needed 2 new int fields so I chose to allocate them just after the header and have the synthetic oop fields directly follow those. That required some small changes to the SA to use the computed value for klass_offset. The allocation of the Java mirror had to change as well. >>>>>> I also brought over support for allocating the mirrors in the normal heap which exposed a few bugs in the oop visitors for arrayKlass. Some of them weren't calling their super visitor so _java_mirror wasn't being visited. arrayKlassKlass::oop_oop_iterate_m was also forwarding to oop_oop_iterate and ignoring the MemRegion. >>>>>> I also added a separate flag to control whether the Class is in perm or not instead of overloading ScavengeRootsInCode. I called it JavaObjectsInPerm but I'm open to changing the name. This can also be used for the String changes that Coomes has. It can also be used for debugging once ScavengeRootsInCode is always enabled. >>>>>> I reran all my tests and also ran Tony's gc_test_suite with all the various collectors, which showed the oop visitor issues I found. I did testing with -Xshare:dump as well. I've updated the full webrev itself and I also generated a incremental webrev to show what I changed since the last review. >>>>>> http://cr.openjdk.java.net/~never/7017732 >>>>>> http://cr.openjdk.java.net/~never/7017732_incremental >>>>>> tom >>>>>> On Feb 10, 2011, at 1:07 AM, Christian Thalinger wrote: >>>>>>> Yes, looks good. -- Christian >>>>>>> >>>>>>> On Feb 10, 2011, at 3:40 AM, Tom Rodriguez wrote: >>>>>>>> On Feb 9, 2011, at 5:51 PM, Vladimir Kozlov wrote: >>>>>>>> >>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>> I removed the no longer correct part. Did you want something added? >>>>>>>>> Is next description is still valid? >>>>>>>>> >>>>>>>>> 77 // [EMBEDDED Java vtable ] size in words = vtable_len >>>>>>>>> 78 // [EMBEDDED static oop fields ] size in words = static_oop_fields_size >>>>>>>>> 79 // [ static non-oop fields ] size in words = static_field_size - static_oop_fields_size >>>>>>>>> 80 // [EMBEDDED nonstatic oop-map blocks] size in words = nonstatic_oop_map_size >>>>>>>> I removed lines 78 and 79 but the rest is still correct I think. >>>>>>>> >>>>>>>>>>> I don't understand changes in Unsafe_StaticFieldBaseFromClass(), >>>>>>>>>>> it should return handle but you just return original jobject. >>>>>>>>>> We're supposed to return the object to use as the base of unsafe static field references. That's just the java.lang.Class instance which was passed in so we simply return it. What would you expect it to do? I guess we might want to unhandle it and return a new local one in case the original one wasn't a local handle. Is that what you're getting at? >>>>>>>>> Thank you for explaining. Code is good. >>>>>>>> I've changed it to return a new local handle as that seems less surprising. >>>>>>>> >>>>>>>> @@ -704,7 +704,7 @@ UNSAFE_ENTRY(jobject, Unsafe_StaticField >>>>>>>> if (clazz == NULL) { THROW_0(vmSymbols::java_lang_NullPointerException()); } - return JNIHandles::make_local(env, java_lang_Class::as_klassOop(JNIHandles::resolve_non_null(clazz))); + return JNIHandles::make_local(env, JNIHandles::resolve_non_null(clazz)); UNSAFE_END UNSAFE_ENTRY(void, Unsafe_EnsureClassInitialized(JNIEnv *env, jobject unsafe, jobject clazz)) >>>>>>>> >>>>>>>> I've regenerated the webrev. >>>>>>>> >>>>>>>> tom >>>>>>>> >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>>> tom >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>>>> I've updated the webrev with this change, fixed a couple macro names that still referenced InstanceKlass and fixed the alignment of the continuation slashes. >>>>>>>>>>>> tom >>>>>>>>>>>> On Feb 9, 2011, at 3:52 AM, Christian Thalinger wrote: >>>>>>>>>>>>> On Feb 8, 2011, at 11:01 PM, Tom Rodriguez wrote: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~never/7017732 >>>>>>>>>>>>> src/cpu/x86/vm/c1_CodeStubs_x86.cpp: >>>>>>>>>>>>> >>>>>>>>>>>>> 315 Register tmp = rax; >>>>>>>>>>>>> 316 Register tmp2 = rbx; >>>>>>>>>>>>> 317 if (_obj == tmp) tmp = rcx; >>>>>>>>>>>>> 318 else if (_obj == tmp2) tmp = rcx; >>>>>>>>>>>>> 319 __ push(tmp); >>>>>>>>>>>>> 320 __ push(tmp2); >>>>>>>>>>>>> 321 __ get_thread(tmp); >>>>>>>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>>>>>>> 324 __ pop(tmp2); >>>>>>>>>>>>> 325 __ pop(tmp); >>>>>>>>>>>>> >>>>>>>>>>>>> Why do you change tmp if _obj == tmp2? I think line 318 isn't required at all since if _obj == tmp2 it gets saved and restored anyway. What about this: >>>>>>>>>>>>> >>>>>>>>>>>>> 315 Register tmp = rax; >>>>>>>>>>>>> 316 Register tmp2 = rbx; >>>>>>>>>>>>> 319 __ push(tmp); >>>>>>>>>>>>> 320 __ push(tmp2); >>>>>>>>>>>>> 322 __ movptr(tmp2, Address(_obj, java_lang_Class::klass_offset_in_bytes())); >>>>>>>>>>>>> 321 __ get_thread(tmp); >>>>>>>>>>>>> 323 __ cmpptr(tmp, Address(tmp2, instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc))); >>>>>>>>>>>>> 324 __ pop(tmp2); >>>>>>>>>>>>> 325 __ pop(tmp); >>>>>>>>>>>>> >>>>>>>>>>>>> -- Christian From karen.kinnear at oracle.com Thu Mar 17 09:58:31 2011 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Thu, 17 Mar 2011 16:58:31 +0000 Subject: hg: jdk7/hotspot/hotspot: 10 new changesets Message-ID: <20110317165849.0DD4B47220@hg.openjdk.java.net> Changeset: 4f148718983e Author: bdelsart Date: 2011-03-10 17:44 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4f148718983e 7025485: leverage shared x86-only deoptimization code Summary: removed an ifdef IA32 around harmless code useful for some ports Reviewed-by: chrisphi, never ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp Changeset: 3d5a546351ef Author: phh Date: 2011-03-11 16:09 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3d5a546351ef 7023931: PcDescCache::find_pc_desc should not write _last_pc_desc Summary: Remove _last_pc_desc and use pcdescs[0] instead. Reviewed-by: dcubed, coleenp, ysr ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp Changeset: 4775a1e3e923 Author: acorn Date: 2011-03-14 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4775a1e3e923 Merge Changeset: 216d916d5c12 Author: dcubed Date: 2011-03-15 06:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/216d916d5c12 7024234: 2/3 jvmti tests fail assert(!_oops_are_stale) failed: oops are stale on Win-AMD64 Summary: Move initialization of the '_instance' field to avoid race with ServiceThread start. Reviewed-by: dholmes, kamg, never, dsamersoff, ysr, coleenp, acorn ! src/share/vm/runtime/serviceThread.cpp Changeset: 46a56fac55c7 Author: dcubed Date: 2011-03-15 06:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/46a56fac55c7 7024970: 2/3 assert(ServiceThread::is_service_thread(Thread::current())) failed: Service thread must post enqueue Summary: Change nmethod_lock() to also prevent zombification of the nmethod. CompiledMethodUnload events also need to lock the nmethod. Clean ups in nmethod::make_not_entrant_or_zombie() Reviewed-by: dholmes, kamg, never, dsamersoff, ysr, coleenp, acorn ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp Changeset: 65f880e2869b Author: dcubed Date: 2011-03-15 06:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/65f880e2869b Merge ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp Changeset: 8a3f8defe568 Author: coleenp Date: 2011-03-16 14:57 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8a3f8defe568 7019165: Incorrect symbols in pstack output after SymbolTable changes Summary: And out lsb which is set for symbols in constant pool slots to distinguish them from strings Reviewed-by: phh, dholmes, never, dcubed ! src/os/solaris/dtrace/libjvm_db.c Changeset: b9684d5ccb52 Author: vladidan Date: 2011-03-10 14:56 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b9684d5ccb52 7011490: Wrong computation results in Test6880034 Summary: incorrect handling of c2i deoptimization on little endian architectures Reviewed-by: never ! src/share/vm/c1/c1_LinearScan.cpp Changeset: bc57bfb5bfad Author: vladidan Date: 2011-03-16 10:47 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/bc57bfb5bfad Merge Changeset: 2074c95f707e Author: vladidan Date: 2011-03-16 23:45 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2074c95f707e Merge From james.melvin at oracle.com Thu Mar 17 11:17:29 2011 From: james.melvin at oracle.com (James Melvin) Date: Thu, 17 Mar 2011 14:17:29 -0400 Subject: JMX Agent work in JDK7... Message-ID: <4D825039.7090105@oracle.com> As part of the JVM Convergence effort, we plan to enhance the JDK JMX agent with select features from JRockit, including... 1. New commandline interface (jcmd) for basic JVM diagnostic commands 2. New Lifecycle support to independently start/stop the JMX agent 3. Support for select additional performance counters This work is planned for JDK7, but requires substantial codebase restructuring to align with HotSpot. Also, the project requires careful thought around package organization and associated public, private, and protected APIs. Work is ongoing and progressing nicely towards a likely end of March initial delivery. We'll provide updates and more details as the date approaches. - Jim From tom.rodriguez at oracle.com Thu Mar 17 14:44:44 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 17 Mar 2011 14:44:44 -0700 Subject: review (S) for 7028374: race in fix_oop_relocations for scavengeable nmethods Message-ID: <50CEE74D-A256-4EDB-9179-97E510D3D5BA@oracle.com> http://cr.openjdk.java.net/~never/7028374 7028374: race in fix_oop_relocations for scavengeable nmethods Reviewed-by: In ScavengeRootsInCode mode oops could sometimes be udpated after their relocations had been updated, resulting in stale oops in generated code. The fix is to move the rewriting of the relocations to the epilogue part of the scavenge nmethods logic. I also added verification of the CodeCache which would have detected this problem immediately. The statics in Class changes will be laid on top of these changes. Tested with statics changes with jbb. From vladimir.kozlov at oracle.com Thu Mar 17 16:28:39 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Mar 2011 16:28:39 -0700 Subject: review (S) for 7028374: race in fix_oop_relocations for scavengeable nmethods In-Reply-To: <50CEE74D-A256-4EDB-9179-97E510D3D5BA@oracle.com> References: <50CEE74D-A256-4EDB-9179-97E510D3D5BA@oracle.com> Message-ID: <4D829927.8020808@oracle.com> This looks good. Again I want parens around arithmetic expressions in assert checks in relocInfo_x86.cpp: + assert(*(int32_t*) disp == x - next_ip, "instructions must match"); + assert(*pd_address_in_code() == x + o, "instructions must match"); Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7028374 > > 7028374: race in fix_oop_relocations for scavengeable nmethods > Reviewed-by: > > In ScavengeRootsInCode mode oops could sometimes be udpated after > their relocations had been updated, resulting in stale oops in > generated code. The fix is to move the rewriting of the relocations > to the epilogue part of the scavenge nmethods logic. I also added > verification of the CodeCache which would have detected this problem > immediately. The statics in Class changes will be laid on top of > these changes. Tested with statics changes with jbb. From tom.rodriguez at oracle.com Thu Mar 17 16:34:02 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 17 Mar 2011 16:34:02 -0700 Subject: review (S) for 7028374: race in fix_oop_relocations for scavengeable nmethods In-Reply-To: <4D829927.8020808@oracle.com> References: <50CEE74D-A256-4EDB-9179-97E510D3D5BA@oracle.com> <4D829927.8020808@oracle.com> Message-ID: On Mar 17, 2011, at 4:28 PM, Vladimir Kozlov wrote: > This looks good. > > Again I want parens around arithmetic expressions in assert checks in relocInfo_x86.cpp: > > + assert(*(int32_t*) disp == x - next_ip, "instructions must match"); > + assert(*pd_address_in_code() == x + o, "instructions must match"); Ok. tom > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7028374 >> 7028374: race in fix_oop_relocations for scavengeable nmethods >> Reviewed-by: >> In ScavengeRootsInCode mode oops could sometimes be udpated after >> their relocations had been updated, resulting in stale oops in >> generated code. The fix is to move the rewriting of the relocations >> to the epilogue part of the scavenge nmethods logic. I also added >> verification of the CodeCache which would have detected this problem >> immediately. The statics in Class changes will be laid on top of >> these changes. Tested with statics changes with jbb. From erik.trimble at oracle.com Thu Mar 17 16:34:57 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Thu, 17 Mar 2011 23:34:57 +0000 Subject: hg: hsx/hsx20/master: 3 new changesets Message-ID: <20110317233502.59B5747241@hg.openjdk.java.net> Changeset: 1554773eb449 Author: jcoomes Date: 2011-03-06 11:37 -0800 URL: http://hg.openjdk.java.net/hsx/hsx20/master/rev/1554773eb449 7018056: large pages not always enabled by default Reviewed-by: phh, kvn ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp Changeset: e8d7ce95c7fb Author: trims Date: 2011-03-10 18:50 -0800 URL: http://hg.openjdk.java.net/hsx/hsx20/master/rev/e8d7ce95c7fb 7026619: Bump the HS20 build number to 11 Summary: Update the HS20 build number to 11 Reviewed-by: jcoomes ! make/hotspot_version Changeset: f0f676c5a2c6 Author: trims Date: 2011-03-15 19:30 -0700 URL: http://hg.openjdk.java.net/hsx/hsx20/master/rev/f0f676c5a2c6 Added tag hs20-b11 for changeset e8d7ce95c7fb ! .hgtags From john.coomes at oracle.com Thu Mar 17 20:32:42 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 18 Mar 2011 03:32:42 +0000 Subject: hg: jdk7/hotspot: Added tag jdk7-b134 for changeset ddc2fcb3682f Message-ID: <20110318033242.A06394724F@hg.openjdk.java.net> Changeset: 168d9382ebab Author: schien Date: 2011-03-17 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/168d9382ebab Added tag jdk7-b134 for changeset ddc2fcb3682f ! .hgtags From john.coomes at oracle.com Thu Mar 17 20:32:49 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 18 Mar 2011 03:32:49 +0000 Subject: hg: jdk7/hotspot/corba: Added tag jdk7-b134 for changeset 918003855fa0 Message-ID: <20110318033253.D123447250@hg.openjdk.java.net> Changeset: e0b72ae5dc5e Author: schien Date: 2011-03-17 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/e0b72ae5dc5e Added tag jdk7-b134 for changeset 918003855fa0 ! .hgtags From john.coomes at oracle.com Thu Mar 17 20:33:01 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 18 Mar 2011 03:33:01 +0000 Subject: hg: jdk7/hotspot/jaxp: 7 new changesets Message-ID: <20110318033301.35DF647251@hg.openjdk.java.net> Changeset: 877fd25c5a2f Author: ohair Date: 2011-03-02 12:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/877fd25c5a2f 7023289: jaxp 1.4.5 development jdk7 2nd integration Reviewed-by: joehw, mchung, alanb ! jaxp.properties Changeset: b693ccf23fb7 Author: lana Date: 2011-03-07 11:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/b693ccf23fb7 Merge Changeset: 02d4672e8c05 Author: lana Date: 2011-03-10 20:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/02d4672e8c05 Merge Changeset: e8be6b716643 Author: ohair Date: 2011-03-10 13:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/e8be6b716643 7025412: make381 issues with quotes in jdk/make/docs/Makefile and other places Reviewed-by: mchung ! make/Makefile Changeset: 1259c6d09d09 Author: mfang Date: 2011-03-14 12:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/1259c6d09d09 Merge Changeset: d56b326ae054 Author: ohair Date: 2011-03-15 15:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/d56b326ae054 Merge Changeset: 4aa9916693dc Author: schien Date: 2011-03-17 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/4aa9916693dc Added tag jdk7-b134 for changeset d56b326ae054 ! .hgtags From john.coomes at oracle.com Thu Mar 17 20:33:07 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 18 Mar 2011 03:33:07 +0000 Subject: hg: jdk7/hotspot/jaxws: 3 new changesets Message-ID: <20110318033307.DF60F47252@hg.openjdk.java.net> Changeset: ba12732b1453 Author: ohair Date: 2011-03-10 13:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/ba12732b1453 7025412: make381 issues with quotes in jdk/make/docs/Makefile and other places Reviewed-by: mchung ! make/Makefile Changeset: 545de8303fec Author: mfang Date: 2011-03-14 12:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/545de8303fec Merge Changeset: d5fc61f18043 Author: schien Date: 2011-03-17 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/d5fc61f18043 Added tag jdk7-b134 for changeset 545de8303fec ! .hgtags From john.coomes at oracle.com Thu Mar 17 20:36:06 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 18 Mar 2011 03:36:06 +0000 Subject: hg: jdk7/hotspot/jdk: 90 new changesets Message-ID: <20110318035149.9074F4725F@hg.openjdk.java.net> Changeset: 864b669d54d8 Author: lana Date: 2011-02-21 19:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/864b669d54d8 Merge - make/sun/jkernel/FILES_c_windows.gmk - make/sun/jkernel/FILES_java.gmk - make/sun/jkernel/Makefile - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java - src/share/classes/sun/jkernel/BackgroundDownloader.java - src/share/classes/sun/jkernel/Bundle.java - src/share/classes/sun/jkernel/BundleCheck.java - src/share/classes/sun/jkernel/ByteArrayToFromHexDigits.java - src/share/classes/sun/jkernel/DigestOutputStream.java - src/share/classes/sun/jkernel/DownloadManager.java - src/share/classes/sun/jkernel/KernelError.java - src/share/classes/sun/jkernel/Mutex.java - src/share/classes/sun/jkernel/StandaloneByteArrayAccess.java - src/share/classes/sun/jkernel/StandaloneMessageDigest.java - src/share/classes/sun/jkernel/StandaloneSHA.java - src/share/demo/zipfs - src/windows/native/sun/jkernel/DownloadDialog.cpp - src/windows/native/sun/jkernel/DownloadDialog.h - src/windows/native/sun/jkernel/DownloadHelper.cpp - src/windows/native/sun/jkernel/DownloadHelper.h - src/windows/native/sun/jkernel/graphics/bullet.bmp - src/windows/native/sun/jkernel/graphics/cautionshield32.bmp - src/windows/native/sun/jkernel/graphics/java-icon.ico - src/windows/native/sun/jkernel/graphics/masthead.bmp - src/windows/native/sun/jkernel/graphics/warningmasthead.bmp - src/windows/native/sun/jkernel/kernel.cpp - src/windows/native/sun/jkernel/kernel.def - src/windows/native/sun/jkernel/kernel.h - src/windows/native/sun/jkernel/kernel.rc - src/windows/native/sun/jkernel/kernel_de.rc - src/windows/native/sun/jkernel/kernel_en.rc - src/windows/native/sun/jkernel/kernel_es.rc - src/windows/native/sun/jkernel/kernel_fr.rc - src/windows/native/sun/jkernel/kernel_it.rc - src/windows/native/sun/jkernel/kernel_ja.rc - src/windows/native/sun/jkernel/kernel_ko.rc - src/windows/native/sun/jkernel/kernel_pt_BR.rc - src/windows/native/sun/jkernel/kernel_sv.rc - src/windows/native/sun/jkernel/kernel_zh.rc - src/windows/native/sun/jkernel/kernel_zh_TW.rc - src/windows/native/sun/jkernel/resource.h - src/windows/native/sun/jkernel/stdafx.cpp - src/windows/native/sun/jkernel/stdafx.h - src/windows/native/sun/jkernel/version.rc - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: 196d6e802721 Author: prr Date: 2011-02-28 10:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/196d6e802721 7004728: [parfait] potential memory leaks in XRender code Reviewed-by: bae, ceisserer ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: bbbf427a9007 Author: ceisserer Date: 2011-03-01 14:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/bbbf427a9007 6974985: Jave2Demo threw exceptions when xrender enabled in OEL5.5 Reviewed-by: prr ! make/sun/awt/mapfile-mawt-vers ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c ! src/solaris/native/sun/java2d/x11/XRSurfaceData.c Changeset: 01dcb496946e Author: ceisserer Date: 2011-03-03 16:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/01dcb496946e 7023589: Xrender : NullPointerException in sun.font.XRGlyphCache.freeGlyphs running Java 2D demo Reviewed-by: prr ! src/share/classes/sun/font/StrikeCache.java ! src/solaris/classes/sun/font/XRGlyphCache.java Changeset: f82f0af7de5b Author: prr Date: 2011-03-04 15:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f82f0af7de5b 7023591: Xrender: java2D font demo - text highlighting tab content is black Reviewed-by: flar ! src/share/classes/sun/java2d/pipe/AAShapePipe.java Changeset: 1356371db8c9 Author: lana Date: 2011-03-06 23:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1356371db8c9 Merge - src/share/classes/java/dyn/NoAccessException.java - src/share/classes/java/dyn/Switcher.java - test/java/lang/Thread/StopBeforeStart.java Changeset: df0de56682b7 Author: dcherepanov Date: 2011-02-24 13:01 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/df0de56682b7 6996708: The event on the tray icon does not trigger and there is no message printed. Reviewed-by: art, ant ! src/windows/native/sun/windows/awt_TrayIcon.cpp Changeset: 75d8c1200df8 Author: dcherepanov Date: 2011-02-25 13:58 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/75d8c1200df8 7020522: Need to reapply the fix for 6664512 Reviewed-by: art, mchung ! src/share/classes/sun/util/logging/PlatformLogger.java Changeset: c27520009762 Author: dcherepanov Date: 2011-02-25 15:33 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c27520009762 7009114: GTK FileDialog lies about it's Bounds Reviewed-by: art, anthony ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java ! src/solaris/native/sun/awt/gtk2_interface.c ! src/solaris/native/sun/awt/gtk2_interface.h ! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c ! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.h Changeset: de0f2f8563eb Author: lana Date: 2011-02-26 23:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/de0f2f8563eb Merge - make/sun/jkernel/FILES_c_windows.gmk - make/sun/jkernel/FILES_java.gmk - make/sun/jkernel/Makefile - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java - src/share/classes/sun/jkernel/BackgroundDownloader.java - src/share/classes/sun/jkernel/Bundle.java - src/share/classes/sun/jkernel/BundleCheck.java - src/share/classes/sun/jkernel/ByteArrayToFromHexDigits.java - src/share/classes/sun/jkernel/DigestOutputStream.java - src/share/classes/sun/jkernel/DownloadManager.java - src/share/classes/sun/jkernel/KernelError.java - src/share/classes/sun/jkernel/Mutex.java - src/share/classes/sun/jkernel/StandaloneByteArrayAccess.java - src/share/classes/sun/jkernel/StandaloneMessageDigest.java - src/share/classes/sun/jkernel/StandaloneSHA.java - src/share/demo/zipfs - src/windows/native/sun/jkernel/DownloadDialog.cpp - src/windows/native/sun/jkernel/DownloadDialog.h - src/windows/native/sun/jkernel/DownloadHelper.cpp - src/windows/native/sun/jkernel/DownloadHelper.h - src/windows/native/sun/jkernel/graphics/bullet.bmp - src/windows/native/sun/jkernel/graphics/cautionshield32.bmp - src/windows/native/sun/jkernel/graphics/java-icon.ico - src/windows/native/sun/jkernel/graphics/masthead.bmp - src/windows/native/sun/jkernel/graphics/warningmasthead.bmp - src/windows/native/sun/jkernel/kernel.cpp - src/windows/native/sun/jkernel/kernel.def - src/windows/native/sun/jkernel/kernel.h - src/windows/native/sun/jkernel/kernel.rc - src/windows/native/sun/jkernel/kernel_de.rc - src/windows/native/sun/jkernel/kernel_en.rc - src/windows/native/sun/jkernel/kernel_es.rc - src/windows/native/sun/jkernel/kernel_fr.rc - src/windows/native/sun/jkernel/kernel_it.rc - src/windows/native/sun/jkernel/kernel_ja.rc - src/windows/native/sun/jkernel/kernel_ko.rc - src/windows/native/sun/jkernel/kernel_pt_BR.rc - src/windows/native/sun/jkernel/kernel_sv.rc - src/windows/native/sun/jkernel/kernel_zh.rc - src/windows/native/sun/jkernel/kernel_zh_TW.rc - src/windows/native/sun/jkernel/resource.h - src/windows/native/sun/jkernel/stdafx.cpp - src/windows/native/sun/jkernel/stdafx.h - src/windows/native/sun/jkernel/version.rc - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: 024d040af4a3 Author: anthony Date: 2011-03-01 13:49 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/024d040af4a3 7022488: The security warning may disappear unexpectedly Summary: Initialize the fullScreenExclusiveModeState flag in the AwtWindow constructor Reviewed-by: art, dcherepanov ! src/windows/native/sun/windows/awt_Window.cpp Changeset: b5e609488bc8 Author: dcherepanov Date: 2011-03-01 15:24 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b5e609488bc8 6826397: PIT : Frame System Menu is not seen for when ALT + Space Bar is pressed in jdk7 b55 build. Reviewed-by: art, ant ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_Frame.h Changeset: 8cd20d3e5448 Author: lana Date: 2011-03-06 20:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8cd20d3e5448 Merge - src/share/classes/java/dyn/NoAccessException.java - src/share/classes/java/dyn/Switcher.java - test/java/lang/Thread/StopBeforeStart.java Changeset: 333bd91466bd Author: lana Date: 2011-03-07 14:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/333bd91466bd Merge ! make/sun/xawt/mapfile-vers Changeset: f8fdf9bca159 Author: okutsu Date: 2011-02-22 14:51 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f8fdf9bca159 7010379: fontconfig update for RHEL 6 Reviewed-by: peytoia ! make/sun/awt/Makefile Changeset: 5957bd3cfdc3 Author: okutsu Date: 2011-02-23 14:09 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5957bd3cfdc3 6623219: Font.canDisplayUpTo does not work with supplementary characters Reviewed-by: prr, peytoia ! src/share/classes/java/awt/Font.java + test/java/awt/FontClass/SurrogateTest/SupplementaryCanDisplayUpToTest.java Changeset: 30d112b3b6f2 Author: okutsu Date: 2011-02-23 16:50 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/30d112b3b6f2 6955047: (tz) javadoc for TimeZone.getDisplayName(boolean daylight, int style, Locale locale) is not clear 7021680: (tz) daylight savings time should be daylight saving time Reviewed-by: peytoia ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/TimeZone.java Changeset: ff611d9474cb Author: okutsu Date: 2011-02-24 15:09 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ff611d9474cb 7021989: Missing observesDaylightTime override in ZoneInfo Reviewed-by: peytoia ! src/share/classes/sun/util/calendar/ZoneInfo.java Changeset: 01c752a48b51 Author: okutsu Date: 2011-02-24 16:29 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/01c752a48b51 6772689: java.sql.Date.valueOf("2042-10-xx").toString() wrong in some time zones Reviewed-by: peytoia ! src/share/classes/sun/util/calendar/ZoneInfo.java + test/java/util/TimeZone/Bug6772689.java Changeset: e390ce4509c6 Author: alexp Date: 2011-02-28 18:20 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e390ce4509c6 6826074: JScrollPane does not revalidate the component hierarchy after scrolling Reviewed-by: anthony ! src/share/classes/javax/swing/DefaultDesktopManager.java ! src/share/classes/javax/swing/JViewport.java Changeset: 1ef5b85d41f2 Author: amenkov Date: 2011-02-28 18:36 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1ef5b85d41f2 7013521: AudioSystem.write for AIFF files closes source audio stream Reviewed-by: dav ! src/share/classes/com/sun/media/sound/AiffFileWriter.java ! src/share/classes/com/sun/media/sound/AuFileWriter.java ! src/share/classes/com/sun/media/sound/SunFileWriter.java ! src/share/classes/com/sun/media/sound/WaveFileWriter.java + test/javax/sound/sampled/FileWriter/WriterCloseInput.java Changeset: d4e3c1f2177a Author: amenkov Date: 2011-03-03 15:41 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d4e3c1f2177a 6938426: Concurrency bug in ALAW encoder causes random bursts of static/noise in output. Reviewed-by: stayer ! src/share/classes/com/sun/media/sound/AlawCodec.java + test/javax/sound/sampled/FileWriter/AlawEncoderSync.java Changeset: d3df100509ad Author: amenkov Date: 2011-03-03 15:45 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d3df100509ad 6801206: SoundTestSuite: test050 fails Reviewed-by: stayer ! src/share/classes/com/sun/media/sound/DirectAudioDevice.java + test/javax/sound/sampled/Clip/ClipSetPos.java Changeset: 4e732aba71bf Author: amenkov Date: 2011-03-03 15:57 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4e732aba71bf 6660470: RealTimeSequencer incorrectly opens (implicitly) synthesizer Reviewed-by: stayer ! src/share/classes/com/sun/media/sound/RealTimeSequencer.java ! src/share/classes/javax/sound/midi/MidiSystem.java + test/javax/sound/midi/Sequencer/SequencerImplicitSynthOpen.java Changeset: 67d4b2e2e5b1 Author: amenkov Date: 2011-03-03 16:40 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/67d4b2e2e5b1 6835393: MidiSystem fails to correctly read Sequence with SMPTE division Reviewed-by: stayer ! src/share/classes/com/sun/media/sound/StandardMidiFileReader.java + test/javax/sound/midi/File/SMPTESequence.java Changeset: 52bdb4237d5e Author: rupashka Date: 2011-03-03 17:47 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/52bdb4237d5e 6796710: Html content in JEditorPane is overlapping on swing components while resizing the application. Reviewed-by: alexp ! src/share/classes/javax/swing/text/html/CSSBorder.java + test/javax/swing/regtesthelpers/Util.java + test/javax/swing/text/CSSBorder/6796710/bug6796710.java Changeset: 7dfcf271b73b Author: alexp Date: 2011-03-03 18:23 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7dfcf271b73b 6653511: JComponent.safelyGetGraphics() may sometimes return null Reviewed-by: rupashka ! src/share/classes/javax/swing/JComponent.java Changeset: e4ca9353150a Author: alexp Date: 2011-03-03 18:27 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e4ca9353150a Merge Changeset: dc34da6a3fa1 Author: rupashka Date: 2011-03-05 18:27 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/dc34da6a3fa1 6760148: Certain fonts are not correctly soft wrapped when using JTextComponent.print() Reviewed-by: peterz ! src/share/classes/javax/swing/text/Utilities.java ! src/share/classes/javax/swing/text/WrappedPlainView.java Changeset: ca0f223b4be7 Author: lana Date: 2011-03-05 20:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ca0f223b4be7 Merge - make/sun/jkernel/FILES_c_windows.gmk - make/sun/jkernel/FILES_java.gmk - make/sun/jkernel/Makefile - src/share/classes/java/dyn/NoAccessException.java - src/share/classes/java/dyn/Switcher.java - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java ! src/share/classes/javax/swing/JComponent.java - src/share/classes/sun/jkernel/BackgroundDownloader.java - src/share/classes/sun/jkernel/Bundle.java - src/share/classes/sun/jkernel/BundleCheck.java - src/share/classes/sun/jkernel/ByteArrayToFromHexDigits.java - src/share/classes/sun/jkernel/DigestOutputStream.java - src/share/classes/sun/jkernel/DownloadManager.java - src/share/classes/sun/jkernel/KernelError.java - src/share/classes/sun/jkernel/Mutex.java - src/share/classes/sun/jkernel/StandaloneByteArrayAccess.java - src/share/classes/sun/jkernel/StandaloneMessageDigest.java - src/share/classes/sun/jkernel/StandaloneSHA.java - src/share/demo/zipfs - src/windows/native/sun/jkernel/DownloadDialog.cpp - src/windows/native/sun/jkernel/DownloadDialog.h - src/windows/native/sun/jkernel/DownloadHelper.cpp - src/windows/native/sun/jkernel/DownloadHelper.h - src/windows/native/sun/jkernel/graphics/bullet.bmp - src/windows/native/sun/jkernel/graphics/cautionshield32.bmp - src/windows/native/sun/jkernel/graphics/java-icon.ico - src/windows/native/sun/jkernel/graphics/masthead.bmp - src/windows/native/sun/jkernel/graphics/warningmasthead.bmp - src/windows/native/sun/jkernel/kernel.cpp - src/windows/native/sun/jkernel/kernel.def - src/windows/native/sun/jkernel/kernel.h - src/windows/native/sun/jkernel/kernel.rc - src/windows/native/sun/jkernel/kernel_de.rc - src/windows/native/sun/jkernel/kernel_en.rc - src/windows/native/sun/jkernel/kernel_es.rc - src/windows/native/sun/jkernel/kernel_fr.rc - src/windows/native/sun/jkernel/kernel_it.rc - src/windows/native/sun/jkernel/kernel_ja.rc - src/windows/native/sun/jkernel/kernel_ko.rc - src/windows/native/sun/jkernel/kernel_pt_BR.rc - src/windows/native/sun/jkernel/kernel_sv.rc - src/windows/native/sun/jkernel/kernel_zh.rc - src/windows/native/sun/jkernel/kernel_zh_TW.rc - src/windows/native/sun/jkernel/resource.h - src/windows/native/sun/jkernel/stdafx.cpp - src/windows/native/sun/jkernel/stdafx.h - src/windows/native/sun/jkernel/version.rc - test/java/lang/Thread/StopBeforeStart.java - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: e3a69b9be2b5 Author: lana Date: 2011-03-07 14:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e3a69b9be2b5 Merge Changeset: d26e79640fd4 Author: mduigou Date: 2011-02-21 14:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d26e79640fd4 7019705: Add -XX:+AggressiveOpts options to MOAT test Reviewed-by: alanb ! test/java/util/Collection/MOAT.java Changeset: dbdafe65af60 Author: alanb Date: 2011-02-21 13:54 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/dbdafe65af60 7020517: (fs) FileStore.equals returns true if both volumes have the same serial number Reviewed-by: chegar ! src/windows/classes/sun/nio/fs/WindowsFileStore.java ! test/java/nio/file/FileStore/Basic.java Changeset: d7cb44a4d08a Author: alanb Date: 2011-02-22 10:19 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d7cb44a4d08a Merge Changeset: 9d8a0369b906 Author: alanb Date: 2011-02-22 12:04 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9d8a0369b906 7020888: (file) Miscellaneous and trivial clean-ups (typos and opportunities to use suppressed exceptions) Reviewed-by: mduigou, chegar ! src/share/classes/java/io/BufferedReader.java ! src/share/classes/java/io/BufferedWriter.java ! src/share/classes/java/io/File.java ! src/share/classes/java/io/FilterOutputStream.java ! src/share/classes/java/io/PushbackInputStream.java ! src/share/classes/java/io/PushbackReader.java ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/SocketChannel.java ! src/share/classes/java/nio/file/CopyMoveHelper.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java ! test/java/lang/ProcessBuilder/Basic.java Changeset: bac152c6491a Author: alanb Date: 2011-02-22 14:28 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/bac152c6491a 7021327: Changes for 7020888 included changes to other files in error Reviewed-by: chegar ! src/share/classes/java/io/BufferedReader.java ! src/share/classes/java/io/BufferedWriter.java ! src/share/classes/java/io/FilterOutputStream.java ! src/share/classes/java/io/PushbackInputStream.java ! src/share/classes/java/io/PushbackReader.java ! test/java/lang/ProcessBuilder/Basic.java Changeset: b853414b8eef Author: michaelm Date: 2011-02-22 14:44 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b853414b8eef 6702400: ChunkedInputStream expecting -1 from int read, but int->char comparision is wrong Reviewed-by: chegar ! src/share/classes/sun/net/httpserver/ChunkedInputStream.java Changeset: 75216854fb53 Author: valeriep Date: 2011-02-22 12:01 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/75216854fb53 6604496: Support for CKM_AES_CTR (counter mode) Summary: Enhanced SunPKCS11 provider to support AES/CTR/NoPadding transformation. Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java + src/share/classes/sun/security/pkcs11/wrapper/CK_AES_CTR_PARAMS.java ! src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c + src/share/native/sun/security/pkcs11/wrapper/pkcs-11v2-20a3.h ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h ! test/sun/security/pkcs11/Cipher/TestSymmCiphers.java ! test/sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java Changeset: 84e339f1033b Author: smarks Date: 2011-02-22 15:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/84e339f1033b 7021209: convert lang, math, util to use try-with-resources Reviewed-by: alanb, darcy, naoto ! src/share/classes/java/lang/Package.java ! src/share/classes/java/util/Currency.java ! src/share/classes/sun/util/calendar/LocalGregorianCalendar.java ! src/solaris/classes/java/util/prefs/FileSystemPreferences.java ! test/java/lang/Character/CheckScript.java ! test/java/lang/Runtime/shutdown/ShutdownHooks.java ! test/java/lang/instrument/BootClassPath/Setup.java ! test/java/lang/instrument/ilib/Inject.java ! test/java/math/BigInteger/BigIntegerTest.java ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Formatter/FailingConstructors.java ! test/java/util/Locale/LocaleEnhanceTest.java ! test/java/util/ResourceBundle/Bug6204853.java ! test/java/util/Scanner/FailingConstructors.java Changeset: 892c3fc7249e Author: dl Date: 2011-02-23 14:56 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/892c3fc7249e 7017493: ConcurrentLinkedDeque: Unexpected initialization order can lead to crash due to use of Unsafe Reviewed-by: chegar ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/share/classes/java/util/concurrent/Phaser.java ! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! src/share/classes/java/util/concurrent/SynchronousQueue.java Changeset: 744c2773e3f7 Author: lana Date: 2011-02-23 10:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/744c2773e3f7 Merge - make/sun/jkernel/FILES_c_windows.gmk - make/sun/jkernel/FILES_java.gmk - make/sun/jkernel/Makefile - src/share/classes/sun/jkernel/BackgroundDownloader.java - src/share/classes/sun/jkernel/Bundle.java - src/share/classes/sun/jkernel/BundleCheck.java - src/share/classes/sun/jkernel/ByteArrayToFromHexDigits.java - src/share/classes/sun/jkernel/DigestOutputStream.java - src/share/classes/sun/jkernel/DownloadManager.java - src/share/classes/sun/jkernel/KernelError.java - src/share/classes/sun/jkernel/Mutex.java - src/share/classes/sun/jkernel/StandaloneByteArrayAccess.java - src/share/classes/sun/jkernel/StandaloneMessageDigest.java - src/share/classes/sun/jkernel/StandaloneSHA.java - src/windows/native/sun/jkernel/DownloadDialog.cpp - src/windows/native/sun/jkernel/DownloadDialog.h - src/windows/native/sun/jkernel/DownloadHelper.cpp - src/windows/native/sun/jkernel/DownloadHelper.h - src/windows/native/sun/jkernel/graphics/bullet.bmp - src/windows/native/sun/jkernel/graphics/cautionshield32.bmp - src/windows/native/sun/jkernel/graphics/java-icon.ico - src/windows/native/sun/jkernel/graphics/masthead.bmp - src/windows/native/sun/jkernel/graphics/warningmasthead.bmp - src/windows/native/sun/jkernel/kernel.cpp - src/windows/native/sun/jkernel/kernel.def - src/windows/native/sun/jkernel/kernel.h - src/windows/native/sun/jkernel/kernel.rc - src/windows/native/sun/jkernel/kernel_de.rc - src/windows/native/sun/jkernel/kernel_en.rc - src/windows/native/sun/jkernel/kernel_es.rc - src/windows/native/sun/jkernel/kernel_fr.rc - src/windows/native/sun/jkernel/kernel_it.rc - src/windows/native/sun/jkernel/kernel_ja.rc - src/windows/native/sun/jkernel/kernel_ko.rc - src/windows/native/sun/jkernel/kernel_pt_BR.rc - src/windows/native/sun/jkernel/kernel_sv.rc - src/windows/native/sun/jkernel/kernel_zh.rc - src/windows/native/sun/jkernel/kernel_zh_TW.rc - src/windows/native/sun/jkernel/resource.h - src/windows/native/sun/jkernel/stdafx.cpp - src/windows/native/sun/jkernel/stdafx.h - src/windows/native/sun/jkernel/version.rc ! test/java/util/Locale/LocaleEnhanceTest.java Changeset: 0f0d6b8f98cc Author: wetmore Date: 2011-02-23 22:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0f0d6b8f98cc 6844879: Source distribution should be more robustly built without the security source distribution Reviewed-by: ohair ! make/common/shared/Defs-java.gmk Changeset: c2c8f9c38fd1 Author: chegar Date: 2011-02-24 12:57 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c2c8f9c38fd1 7020136: java/net/URLConnection/RedirectLimit.java fails intermittently Summary: Increase the socket timeout and clean up the test Reviewed-by: alanb ! test/java/net/URLConnection/RedirectLimit.java Changeset: 1f41e41ef2db Author: chegar Date: 2011-02-24 13:42 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1f41e41ef2db 6849693: index of fdTable should be less than num. of fdTable in jdk7 Reviewed-by: alanb ! src/solaris/native/java/net/linux_close.c Changeset: 51ef29aafc1b Author: michaelm Date: 2011-02-24 18:35 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/51ef29aafc1b 6835668: Use of /usr/include/linux/ files creates a dependence on kernel-headers Reviewed-by: chegar ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/PlainSocketImpl.c Changeset: b74f1b830484 Author: smarks Date: 2011-02-24 22:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b74f1b830484 7022383: add reference to CR for ReadLongZipFileName test to problem list Reviewed-by: ohair ! test/ProblemList.txt Changeset: 32dc1cb2b995 Author: mchung Date: 2011-02-25 11:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/32dc1cb2b995 7021939: com.oracle.net is not a NON_CORE_PKGS Reviewed-by: ohair, alanb ! make/common/Release.gmk ! make/docs/NON_CORE_PKGS.gmk Changeset: 5dc98de2a35e Author: mchung Date: 2011-02-25 12:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5dc98de2a35e 7016707: Remove the BootClassLoaderHook for jkernel support Reviewed-by: alanb, ohair ! make/java/java/FILES_java.gmk ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/util/zip/ZipEntry.java - src/share/classes/sun/misc/BootClassLoaderHook.java ! src/share/classes/sun/misc/Launcher.java - test/sun/misc/BootClassLoaderHook/TestHook.java Changeset: 8887cb2f5d19 Author: smarks Date: 2011-02-25 02:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8887cb2f5d19 7021582: convert jar/zip code and tests to use try-with-resources Reviewed-by: alanb, dholmes, sherman ! src/share/classes/java/util/jar/JarFile.java ! test/java/util/jar/JarEntry/GetMethodsReturnClones.java ! test/java/util/jar/JarFile/ScanSignedJar.java ! test/java/util/zip/Available.java ! test/java/util/zip/FileBuilder.java ! test/java/util/zip/GZIP/Accordion.java ! test/java/util/zip/GZIP/GZIPInputStreamRead.java ! test/java/util/zip/InflateIn_DeflateOut.java ! test/java/util/zip/InfoZip.java ! test/java/util/zip/LargeZip.java ! test/java/util/zip/TestEmptyZip.java ! test/java/util/zip/ZipCoding.java ! test/java/util/zip/ZipFile/Assortment.java ! test/java/util/zip/ZipFile/Comment.java ! test/java/util/zip/ZipFile/CopyJar.java ! test/java/util/zip/ZipFile/CorruptedZipFiles.java ! test/java/util/zip/ZipFile/DeleteTempJar.java ! test/java/util/zip/ZipFile/EnumAfterClose.java ! test/java/util/zip/ZipFile/GetDirEntry.java ! test/java/util/zip/ZipFile/LargeZipFile.java ! test/java/util/zip/ZipFile/ManyEntries.java ! test/java/util/zip/ZipFile/ManyZipFiles.java ! test/java/util/zip/ZipFile/ReadAfterClose.java ! test/java/util/zip/ZipFile/ReadZip.java ! test/java/util/zip/ZipFile/ShortRead.java ! test/java/util/zip/zip.java Changeset: 29f25ba547fc Author: chegar Date: 2011-02-28 11:03 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/29f25ba547fc 7022269: clean up fscanf usage in Linux networking native code Reviewed-by: michaelm, alanb ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/net_util_md.c Changeset: a3b6c262195b Author: dholmes Date: 2011-02-28 06:40 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a3b6c262195b 7022386: gethostbyname_r needs a pointer aligned buffer passed to it Summary: Change buffer type to ensure pointer-alignment Reviewed-by: alanb, chegar ! src/solaris/native/java/net/Inet4AddressImpl.c Changeset: f4613b378874 Author: weijun Date: 2011-02-28 23:02 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f4613b378874 7021789: Remove jarsigner -crl option Reviewed-by: mullan ! src/share/classes/com/sun/jarsigner/ContentSignerParameters.java ! src/share/classes/java/security/CodeSigner.java - src/share/classes/sun/misc/JavaSecurityCodeSignerAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/JarSignerResources.java ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/tools/TimestampedSigner.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java ! test/sun/security/tools/jarsigner/crl.sh Changeset: f8bf888edf20 Author: weijun Date: 2011-03-01 16:22 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f8bf888edf20 7020531: test: java/security/cert/CertificateFactory/openssl/OpenSSLCert.java file not closed after run Reviewed-by: alanb, smarks ! test/ProblemList.txt ! test/java/security/cert/CertificateFactory/openssl/OpenSSLCert.java ! test/sun/security/tools/keytool/NewSize7.java Changeset: b7e763a573a4 Author: alanb Date: 2011-03-01 12:03 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b7e763a573a4 7023034: Files.createTempDirectory((Path)null, "temp") does not throw NPE Reviewed-by: forax ! src/share/classes/java/nio/file/Files.java ! test/java/nio/file/Files/TemporaryFiles.java Changeset: 98d2d57d9e73 Author: smarks Date: 2011-03-01 15:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/98d2d57d9e73 7022624: use try-with-resources in java.io tests Reviewed-by: alanb ! test/java/io/File/SetLastModified.java ! test/java/io/FileOutputStream/AtomicAppend.java ! test/java/io/OutputStreamWriter/Encode.java ! test/java/io/PrintStream/EncodingConstructor.java ! test/java/io/PrintStream/FailingConstructors.java ! test/java/io/Serializable/evolution/RenamePackage/install/SerialDriver.java ! test/java/io/Serializable/evolution/RenamePackage/test/SerialDriver.java Changeset: 895687e879ca Author: alanb Date: 2011-03-02 16:56 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/895687e879ca 7021987: native2ascii "file cannot be read" error message is broken Reviewed-by: lancea, mchung ! src/share/classes/sun/tools/native2ascii/Main.java ! test/sun/tools/native2ascii/Native2AsciiTests.sh Changeset: 75064373ed6b Author: michaelm Date: 2011-03-03 15:34 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/75064373ed6b 7018606: (process) test/java/lang/ProcessBuilder/Basic.java failing intermittently (win) Reviewed-by: alanb ! test/java/lang/ProcessBuilder/Basic.java Changeset: 7cfb0693eb33 Author: chegar Date: 2011-03-03 16:44 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7cfb0693eb33 7018137: HTML4 compliance issues Summary: move end list items tags to after nested list Reviewed-by: alanb ! src/share/classes/java/net/URI.java ! src/share/classes/java/net/package.html Changeset: 9b99a14375bc Author: chegar Date: 2011-03-03 16:48 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9b99a14375bc 6721694: java/lang/Thread/StartOOMTest.java fails with timeout or with crash Summary: the test is not suitable to be run automatically Reviewed-by: alanb ! test/java/lang/Thread/StartOOMTest.java Changeset: 732faed56eb0 Author: coffeys Date: 2011-03-03 16:51 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/732faed56eb0 6750362: Very large LDAP requests throw a OOM on LDAP servers which aren't aware of Paged Results Controls 6748156: add an new JNDI property to control the boolean flag WaitForReply Reviewed-by: vinnie, robm ! src/share/classes/com/sun/jndi/ldap/Connection.java ! src/share/classes/com/sun/jndi/ldap/LdapClient.java ! src/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/share/classes/com/sun/jndi/ldap/LdapRequest.java + test/com/sun/jndi/ldap/NoWaitForReplyTest.java Changeset: 0bd32f96187d Author: coffeys Date: 2011-03-03 17:00 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0bd32f96187d Merge Changeset: b645b5bc460b Author: michaelm Date: 2011-03-03 17:14 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b645b5bc460b 7024264: HttpURLConnection/NetPermission doc issue Reviewed-by: chegar ! src/share/classes/java/net/HttpURLConnection.java ! src/share/classes/java/net/NetPermission.java Changeset: 6e596210bf01 Author: michaelm Date: 2011-03-03 17:16 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6e596210bf01 Merge Changeset: 2fb9e2d4ef46 Author: alanb Date: 2011-03-04 09:29 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2fb9e2d4ef46 6944810: (ch) Assert failure in sun.nio.ch.PendingIoCache.clearPendingIoMap [win] Reviewed-by: chegar ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/windows/classes/sun/nio/ch/PendingIoCache.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java ! test/ProblemList.txt Changeset: 259011d14d48 Author: alanb Date: 2011-03-04 09:33 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/259011d14d48 Merge Changeset: c4bd93431a20 Author: ksrini Date: 2011-03-04 09:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c4bd93431a20 7023963: (misc) fix diamond anon instances in the jdk Reviewed-by: alanb, mchung, mcimadamore, dholmes ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipDirectoryStream.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java Changeset: 90b7926884a8 Author: sherman Date: 2011-03-04 11:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/90b7926884a8 7023244: (zipfs) langtools CompileTest fails on read-only file system Summary: replaced checkAccess with Files.isWritable() Reviewed-by: alanb ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java Changeset: 7b6ad3027f3d Author: alanb Date: 2011-03-04 21:26 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7b6ad3027f3d 7023403: (ch) sun.nio.ch.SolarisEventPort.startPoll failed with AssertionError Reviewed-by: forax ! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java Changeset: 28bedf6eba87 Author: alanb Date: 2011-03-04 21:28 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/28bedf6eba87 Merge Changeset: 339342f311cc Author: coffeys Date: 2011-03-07 14:43 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/339342f311cc 7025105: TEST_BUG test/com/sun/jndi/ldap/NoWaitForReplyTest.java should be cleaned up Reviewed-by: alanb ! test/com/sun/jndi/ldap/NoWaitForReplyTest.java Changeset: bc0c58d65e97 Author: mullan Date: 2011-03-07 13:20 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/bc0c58d65e97 7022467: SecretKeyFactory doesn't support algorithm "AES" on Windows and Linux Reviewed-by: wetmore, valeriep ! src/share/classes/javax/crypto/SecretKeyFactory.java Changeset: 62b0337d1369 Author: mullan Date: 2011-03-07 13:44 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/62b0337d1369 Merge Changeset: 6d5a992dbac2 Author: lana Date: 2011-03-07 11:36 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6d5a992dbac2 Merge ! make/common/Release.gmk - src/share/classes/java/dyn/NoAccessException.java - src/share/classes/java/dyn/Switcher.java Changeset: a52da0bada39 Author: valeriep Date: 2011-03-07 14:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a52da0bada39 6994008: PKCS11 should support "RSA" and "RSA/ECB/NoPadding" ciphers Summary: Add support for RSA_X_509 mechanism and aliasing of "RSA" to "RSA/ECB/PKCS1Padding". Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! test/sun/security/pkcs11/Cipher/TestRSACipher.java ! test/sun/security/pkcs11/Cipher/TestRSACipherWrap.java + test/sun/security/pkcs11/Cipher/TestRawRSACipher.java Changeset: 0b6d82c838d4 Author: lana Date: 2011-03-07 14:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0b6d82c838d4 Merge - src/share/classes/sun/misc/BootClassLoaderHook.java - src/share/classes/sun/misc/JavaSecurityCodeSignerAccess.java - test/sun/misc/BootClassLoaderHook/TestHook.java Changeset: 663c7623b96b Author: alanb Date: 2011-03-08 10:32 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/663c7623b96b 7025468: Tests using diamond with anonymous inner classes needs to be reverted Reviewed-by: dholmes, forax ! test/java/nio/file/DirectoryStream/Basic.java ! test/java/util/PriorityQueue/NoNulls.java Changeset: c0bf0f19897a Author: lana Date: 2011-03-10 19:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c0bf0f19897a Merge Changeset: c975c4fbca20 Author: lana Date: 2011-03-10 20:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c975c4fbca20 Merge ! make/common/Release.gmk - src/share/classes/sun/misc/BootClassLoaderHook.java - src/share/classes/sun/misc/JavaSecurityCodeSignerAccess.java - test/sun/misc/BootClassLoaderHook/TestHook.java Changeset: 6aeed99af874 Author: mchung Date: 2011-03-09 23:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6aeed99af874 7025631: Remove the modules build support from jdk 7 Reviewed-by: alanb, ohair ! make/Makefile ! make/com/sun/crypto/provider/Makefile ! make/com/sun/java/pack/Makefile ! make/com/sun/java/pack/prop/Makefile ! make/com/sun/jndi/cosnaming/Makefile ! make/com/sun/jndi/dns/Makefile ! make/com/sun/jndi/ldap/Makefile ! make/com/sun/jndi/rmi/registry/Makefile ! make/com/sun/nio/sctp/Makefile ! make/com/sun/org/apache/xml/Makefile ! make/com/sun/rowset/Makefile ! make/com/sun/script/Makefile ! make/com/sun/security/auth/module/Makefile ! make/com/sun/servicetag/Makefile ! make/com/sun/tools/attach/Makefile ! make/common/Defs.gmk ! make/common/Demo.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! make/common/Release.gmk ! make/common/Sanity.gmk ! make/common/Subdirs.gmk ! make/common/shared/Sanity.gmk ! make/java/awt/Makefile ! make/java/fdlibm/Makefile ! make/java/instrument/Makefile ! make/java/java/Makefile ! make/java/java_crw_demo/Makefile ! make/java/java_hprof_demo/Makefile ! make/java/jli/Makefile ! make/java/jvm/Makefile ! make/java/logging/Makefile ! make/java/main/java/Makefile ! make/java/main/javaw/Makefile ! make/java/management/Makefile ! make/java/net/Makefile ! make/java/nio/Makefile ! make/java/npt/Makefile ! make/java/redist/Makefile ! make/java/redist/fonts/Makefile ! make/java/redist/sajdi/Makefile ! make/java/security/Makefile ! make/java/sql/Makefile ! make/java/text/base/Makefile ! make/java/verify/Makefile ! make/java/zip/Makefile ! make/javax/crypto/Makefile ! make/javax/imageio/Makefile ! make/javax/print/Makefile ! make/javax/sound/Makefile ! make/javax/sound/jsoundalsa/Makefile ! make/javax/sound/jsoundds/Makefile ! make/javax/sql/Makefile ! make/javax/swing/Makefile ! make/javax/swing/plaf/Makefile ! make/jpda/back/Makefile ! make/jpda/transport/Makefile ! make/jpda/transport/shmem/Makefile ! make/jpda/transport/socket/Makefile ! make/jpda/tty/Makefile ! make/launchers/Makefile ! make/mkdemo/jvmti/Makefile ! make/mkdemo/management/Makefile ! make/mksample/dtrace/Makefile ! make/mksample/jmx/jmx-scandir/Makefile ! make/mksample/nbproject/Makefile ! make/mksample/nio/file/Makefile ! make/mksample/nio/multicast/Makefile ! make/mksample/nio/server/Makefile ! make/mksample/scripting/scriptpad/Makefile ! make/mksample/webservices/EbayClient/Makefile ! make/mksample/webservices/EbayServer/Makefile ! make/sun/applet/Makefile ! make/sun/awt/Makefile ! make/sun/cmm/Makefile ! make/sun/cmm/kcms/Makefile ! make/sun/cmm/lcms/Makefile ! make/sun/dcpr/Makefile ! make/sun/font/Makefile ! make/sun/font/t2k/Makefile ! make/sun/headless/Makefile ! make/sun/image/generic/Makefile ! make/sun/image/vis/Makefile ! make/sun/jar/Makefile ! make/sun/javazic/Makefile ! make/sun/jawt/Makefile ! make/sun/jconsole/Makefile ! make/sun/jdbc/Makefile ! make/sun/jdga/Makefile ! make/sun/jpeg/Makefile ! make/sun/launcher/Makefile ! make/sun/management/Makefile ! make/sun/native2ascii/Makefile ! make/sun/net/others/Makefile ! make/sun/net/spi/nameservice/dns/Makefile ! make/sun/nio/cs/Makefile ! make/sun/org/mozilla/javascript/Makefile ! make/sun/pisces/Makefile ! make/sun/rmi/cgi/Makefile ! make/sun/rmi/oldtools/Makefile ! make/sun/rmi/registry/Makefile ! make/sun/rmi/rmi/Makefile ! make/sun/rmi/rmic/Makefile ! make/sun/rmi/rmid/Makefile ! make/sun/security/ec/Makefile ! make/sun/security/jgss/wrapper/Makefile ! make/sun/security/krb5/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile ! make/sun/security/smartcardio/Makefile ! make/sun/security/tools/Makefile ! make/sun/serialver/Makefile ! make/sun/splashscreen/Makefile ! make/sun/text/Makefile ! make/sun/tools/Makefile ! make/sun/tracing/dtrace/Makefile ! make/sun/xawt/Makefile Changeset: 1657b854c956 Author: mchung Date: 2011-03-09 23:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1657b854c956 7026228: Remove make/modules and make/common/Modules.gmk Reviewed-by: alanb, ohair - make/common/Modules.gmk - make/java/nio/mxbean/Makefile - make/modules/Makefile - make/modules/bootmodule.roots - make/modules/jdk7.depconfig - make/modules/modules.config - make/modules/modules.group - make/modules/optional.depconfig - make/modules/tools/Makefile - make/modules/tools/build.xml - make/modules/tools/nbproject/project.properties - make/modules/tools/nbproject/project.xml - make/modules/tools/src/com/sun/classanalyzer/AnnotatedDependency.java - make/modules/tools/src/com/sun/classanalyzer/AnnotationParser.java - make/modules/tools/src/com/sun/classanalyzer/BootAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/CheckDeps.java - make/modules/tools/src/com/sun/classanalyzer/ClassAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ClassFileParser.java - make/modules/tools/src/com/sun/classanalyzer/ClassPath.java - make/modules/tools/src/com/sun/classanalyzer/CodeAttributeParser.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolParser.java - make/modules/tools/src/com/sun/classanalyzer/DependencyConfig.java - make/modules/tools/src/com/sun/classanalyzer/Klass.java - make/modules/tools/src/com/sun/classanalyzer/Module.java - make/modules/tools/src/com/sun/classanalyzer/ModuleConfig.java - make/modules/tools/src/com/sun/classanalyzer/ResolutionInfo.java - make/modules/tools/src/com/sun/classanalyzer/ResourceFile.java - make/modules/tools/src/com/sun/classanalyzer/ShowDeps.java Changeset: c28f5ac2d5f8 Author: ohair Date: 2011-03-10 14:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c28f5ac2d5f8 7025412: make381 issues with quotes in jdk/make/docs/Makefile and other places Reviewed-by: mchung, herrick ! make/common/shared/Defs-javadoc.gmk ! make/common/shared/Sanity.gmk ! make/docs/Makefile ! make/javax/crypto/Defs-jce.gmk Changeset: 38be400c2608 Author: asaha Date: 2011-03-09 16:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/38be400c2608 6908562: JFB Custom Revision Version Build/Makefile changes Reviewed-by: ohair, ksrini, katleman ! make/common/Release.gmk ! make/common/shared/Defs.gmk Changeset: fc680f496eaf Author: asaha Date: 2011-03-14 12:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/fc680f496eaf Merge - make/common/Modules.gmk ! make/common/Release.gmk - make/java/nio/mxbean/Makefile - make/modules/Makefile - make/modules/bootmodule.roots - make/modules/jdk7.depconfig - make/modules/modules.config - make/modules/modules.group - make/modules/optional.depconfig - make/modules/tools/Makefile - make/modules/tools/build.xml - make/modules/tools/nbproject/project.properties - make/modules/tools/nbproject/project.xml - make/modules/tools/src/com/sun/classanalyzer/AnnotatedDependency.java - make/modules/tools/src/com/sun/classanalyzer/AnnotationParser.java - make/modules/tools/src/com/sun/classanalyzer/BootAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/CheckDeps.java - make/modules/tools/src/com/sun/classanalyzer/ClassAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ClassFileParser.java - make/modules/tools/src/com/sun/classanalyzer/ClassPath.java - make/modules/tools/src/com/sun/classanalyzer/CodeAttributeParser.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolParser.java - make/modules/tools/src/com/sun/classanalyzer/DependencyConfig.java - make/modules/tools/src/com/sun/classanalyzer/Klass.java - make/modules/tools/src/com/sun/classanalyzer/Module.java - make/modules/tools/src/com/sun/classanalyzer/ModuleConfig.java - make/modules/tools/src/com/sun/classanalyzer/ResolutionInfo.java - make/modules/tools/src/com/sun/classanalyzer/ResourceFile.java - make/modules/tools/src/com/sun/classanalyzer/ShowDeps.java Changeset: b1215d1f015b Author: ohair Date: 2011-03-15 15:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b1215d1f015b Merge - make/common/Modules.gmk ! make/common/Release.gmk - make/java/nio/mxbean/Makefile - make/modules/Makefile - make/modules/bootmodule.roots - make/modules/jdk7.depconfig - make/modules/modules.config - make/modules/modules.group - make/modules/optional.depconfig - make/modules/tools/Makefile - make/modules/tools/build.xml - make/modules/tools/nbproject/project.properties - make/modules/tools/nbproject/project.xml - make/modules/tools/src/com/sun/classanalyzer/AnnotatedDependency.java - make/modules/tools/src/com/sun/classanalyzer/AnnotationParser.java - make/modules/tools/src/com/sun/classanalyzer/BootAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/CheckDeps.java - make/modules/tools/src/com/sun/classanalyzer/ClassAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ClassFileParser.java - make/modules/tools/src/com/sun/classanalyzer/ClassPath.java - make/modules/tools/src/com/sun/classanalyzer/CodeAttributeParser.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolParser.java - make/modules/tools/src/com/sun/classanalyzer/DependencyConfig.java - make/modules/tools/src/com/sun/classanalyzer/Klass.java - make/modules/tools/src/com/sun/classanalyzer/Module.java - make/modules/tools/src/com/sun/classanalyzer/ModuleConfig.java - make/modules/tools/src/com/sun/classanalyzer/ResolutionInfo.java - make/modules/tools/src/com/sun/classanalyzer/ResourceFile.java - make/modules/tools/src/com/sun/classanalyzer/ShowDeps.java ! make/sun/awt/Makefile Changeset: 3de1fed4b9ec Author: ohair Date: 2011-03-15 15:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3de1fed4b9ec 6710813: SwingSet2 source display tabs do not work since JDK 7 b20 6685150: make/mkdemo/jpda/Makefile creates jpda.jar and src.zip instead of examples.jar Reviewed-by: prr ! make/common/Demo.gmk ! make/mkdemo/jfc/SwingSet2/Makefile ! make/mkdemo/jpda/Makefile Changeset: f5ecfc9e274c Author: ohair Date: 2011-03-15 23:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f5ecfc9e274c Merge - src/share/classes/sun/misc/BootClassLoaderHook.java - src/share/classes/sun/misc/JavaSecurityCodeSignerAccess.java - test/sun/misc/BootClassLoaderHook/TestHook.java Changeset: d6c6d9566126 Author: katleman Date: 2011-03-16 09:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d6c6d9566126 6973319: incorrect spec version in jdk 7 rt.jar manifest Reviewed-by: ohair ! make/tools/manifest.mf Changeset: 76a2ea69f47f Author: katleman Date: 2011-03-16 09:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/76a2ea69f47f 7022473: JDK7 still runs /etc/prtconf to find memory size Reviewed-by: ohair ! make/common/shared/Platform.gmk Changeset: 554adcfb615e Author: ohair Date: 2011-03-16 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/554adcfb615e 7027923: Disable VS2003 use in preparation for all VS2003 make logic removal Reviewed-by: prr ! make/common/shared/Compiler-msvc.gmk Changeset: 0653cab602f2 Author: schien Date: 2011-03-17 14:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0653cab602f2 Added tag jdk7-b134 for changeset 554adcfb615e ! .hgtags From christian.thalinger at oracle.com Fri Mar 18 11:02:12 2011 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Fri, 18 Mar 2011 18:02:12 +0000 Subject: hg: jdk7/hotspot/hotspot: 13 new changesets Message-ID: <20110318180235.46AAD47285@hg.openjdk.java.net> Changeset: 5d8f5a6dced7 Author: iveresov Date: 2011-03-04 15:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5d8f5a6dced7 7020403: Add AdvancedCompilationPolicy for tiered Summary: This implements adaptive tiered compilation policy. Reviewed-by: kvn, never ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.hpp + src/share/vm/runtime/advancedThresholdPolicy.cpp + src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/compilationPolicy.cpp Changeset: 4cd9add59b1e Author: never Date: 2011-03-04 20:01 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4cd9add59b1e 7024866: # assert(limit == NULL || limit <= nm->code_end()) failed: in bounds Reviewed-by: kvn, iveresov ! src/share/vm/code/nmethod.cpp Changeset: 8ec5e1f45ea1 Author: never Date: 2011-03-04 22:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8ec5e1f45ea1 Merge Changeset: 8e72cd29b15d Author: kvn Date: 2011-03-05 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8e72cd29b15d 6589823: Error: meet not symmetric Summary: arrays pointers meet must fall to bottom if exact array klasses in upper lattice are not equal or super klass is exact. Reviewed-by: never ! src/share/vm/opto/type.cpp Changeset: 425688247f3d Author: never Date: 2011-03-06 22:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/425688247f3d 6965570: assert(!needs_patching && x->is_loaded(),"how do we know it's volatile if it's not loaded") Reviewed-by: iveresov ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_ValueMap.hpp Changeset: 1c0cf339481b Author: kvn Date: 2011-03-09 09:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1c0cf339481b 7025742: Can not use CodeCache::unallocated_capacity() with fragmented CodeCache Summary: Use largest_free_block() instead of unallocated_capacity(). Reviewed-by: iveresov, never, ysr ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/memory/heap.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/runtime/sweeper.cpp Changeset: 83f08886981c Author: kvn Date: 2011-03-11 07:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/83f08886981c 7026631: field _klass is incorrectly set for dual type of TypeAryPtr::OOPS Summary: add missing check this->dual() != TypeAryPtr::OOPS into TypeAryPtr::klass(). Reviewed-by: never ! src/share/vm/opto/type.cpp Changeset: 799d8ccf63cf Author: jrose Date: 2011-03-11 21:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/799d8ccf63cf Merge ! src/share/vm/oops/methodOop.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 72dee110246f Author: jrose Date: 2011-03-11 22:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/72dee110246f 6839872: remove implementation inheritance from JSR 292 APIs Summary: consolidate runtime support in java.dyn.MethodHandleNatives; include transitional compatibility logic Reviewed-by: twisti ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/globals.hpp Changeset: 8033953d67ff Author: jrose Date: 2011-03-11 22:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8033953d67ff 7012648: move JSR 292 to package java.lang.invoke and adjust names Summary: package and class renaming only; delete unused methods and classes Reviewed-by: twisti ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciCallSite.cpp ! src/share/vm/ci/ciCallSite.hpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/prims/nativeLookup.cpp Changeset: 82de9bd880e3 Author: kvn Date: 2011-03-17 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/82de9bd880e3 7028394: Newer AMD Processor Prefetch Defaults Summary: This new default has shown improvement across many workloads. Reviewed-by: kvn Contributed-by: tom.deneau at amd.com ! src/cpu/x86/vm/vm_version_x86.cpp Changeset: d2134498fd3f Author: jrose Date: 2011-03-17 18:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d2134498fd3f 7011865: JSR 292 CTW fails: !THREAD->is_Compiler_thread() failed: Can not load classes with the Compiler thre Reviewed-by: kvn, never ! src/share/vm/interpreter/linkResolver.cpp Changeset: fc5ebbb2d1a8 Author: twisti Date: 2011-03-18 01:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fc5ebbb2d1a8 Merge ! src/share/vm/code/nmethod.cpp From john.coomes at oracle.com Fri Mar 18 13:04:04 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 18 Mar 2011 20:04:04 +0000 Subject: hg: jdk7/hotspot/hotspot: 10 new changesets Message-ID: <20110318200422.48C244728A@hg.openjdk.java.net> Changeset: 1216415d8e35 Author: tonyp Date: 2011-03-04 17:13 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1216415d8e35 7014923: G1: code cleanup Summary: Some G1 code cleanup. Reviewed-by: johnc, jcoomes, jwilhelm ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegionSets.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: a2c2eac1ca62 Author: jcoomes Date: 2011-03-06 11:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a2c2eac1ca62 7018056: large pages not always enabled by default Reviewed-by: phh, kvn ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp Changeset: c93aa6caa02f Author: brutisso Date: 2011-03-03 22:58 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c93aa6caa02f 7022943: G1: improve logging to avoid interleaved numbers Summary: Introduced buffered loggging to make sure that log lines are logged one line at a time Reviewed-by: stefank, johnc, dsamersoff ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: 04d1138b4cce Author: brutisso Date: 2011-03-03 11:35 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/04d1138b4cce 7023747: G1: too strict assert in RefineRecordRefsIntoCSCardTableEntryClosure::do_card_ptr in g1RemSet.cpp Summary: Made sure that the assert looks at ParallelGCThreads. Reviewed-by: stefank, tonyp, jwilhelm, johnc ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: a181f3a124dd Author: ysr Date: 2011-03-14 21:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a181f3a124dd 6987703: iCMS: Intermittent hang with gc/gctests/CallGC/CallGC01 and +ExplicitGCInvokesConcurrent Summary: Count enable_icms() and disable_icms() events so as to prevent inteference between concurrent calls, which can cause the iCMS thread to be left stranded in icms_wait() with an unserviced request and no young allocations to unwedge it. Reviewed-by: jcoomes, poonam ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.hpp Changeset: 1fb790245268 Author: jwilhelm Date: 2011-03-11 16:35 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1fb790245268 6820066: Check that -XX:ParGCArrayScanChunk has a value larger than zero. Summary: Check that -XX:ParGCArrayScanChunk has a value larger than zero. Reviewed-by: johnc, jmasa, ysr ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 1abd292f8c38 Author: jwilhelm Date: 2011-03-15 09:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1abd292f8c38 Merge Changeset: dde920245681 Author: ysr Date: 2011-03-16 10:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/dde920245681 6896099: Integrate CMS heap ergo with default heap sizing ergo 6627787: CMS: JVM refuses to start up with -Xms16m -Xmx16m 7000125: CMS: Anti-monotone young gen sizing with respect to maximum whole heap size specification 7027529: CMS: retire CMSUseOldDefaults flag Summary: Simplify CMS heap sizing code, relying on ergonomic initial sizing consistent with other collectors for the most part, controlling only young gen sizing to rein in pause times. Make CMS young gen sizing default statically cpu-dependant. Remove inconsistencies wrt generation sizing and policy code, allowing for the fixing for 6627787 and 7000125. For 7027529, retire the flag CMSUseOldDefaults which had been introduced as a bridge from JDK 5 to JDK 6 a number of years ago. Reviewed-by: brutisso, poonam ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 92da084fefc9 Author: ysr Date: 2011-03-17 10:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/92da084fefc9 6668573: CMS: reference processing crash if ParallelCMSThreads > ParallelGCThreads Summary: Use _max_num_q = max(discovery_degree, processing_degree), and let balance_queues() redistribute from discovery_degree to processing_degree of queues. This should also allow a more dynamic and flexible parallelism policy in the future. Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp Changeset: 048f98400b8e Author: jcoomes Date: 2011-03-18 09:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/048f98400b8e Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp From erik.trimble at oracle.com Fri Mar 18 17:22:35 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Sat, 19 Mar 2011 00:22:35 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20110319002247.0B3A74729C@hg.openjdk.java.net> Changeset: 2707f76d15e3 Author: schien Date: 2011-03-17 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2707f76d15e3 Added tag jdk7-b134 for changeset 447e6faab4a8 ! .hgtags Changeset: fc1b183bfc0a Author: trims Date: 2011-03-17 17:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fc1b183bfc0a Added tag hs21-b04 for changeset 3c76374706ea ! .hgtags Changeset: e97ad5d5c990 Author: trims Date: 2011-03-18 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e97ad5d5c990 Merge Changeset: b898f0fc3ced Author: trims Date: 2011-03-18 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b898f0fc3ced 7028846: Bump the HS21 build number to 05 Summary: Update the HS21 build number to 05 Reviewed-by: jcoomes ! make/hotspot_version From john.coomes at oracle.com Fri Mar 18 22:20:23 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 19 Mar 2011 05:20:23 +0000 Subject: hg: jdk7/hotspot/langtools: 85 new changesets Message-ID: <20110319052308.41757472B0@hg.openjdk.java.net> Changeset: 73ab0b128918 Author: jjg Date: 2011-01-24 16:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/73ab0b128918 6963934: JCCompilationUnit.getImports does not report all imports Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/tree/T6963934.java Changeset: 22a040cbf0e0 Author: jjg Date: 2011-01-24 16:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/22a040cbf0e0 6581775: Fix the white space problem in javac shell tests Reviewed-by: mcimadamore ! test/tools/javac/ClassPathTest/ClassPathTest.sh ! test/tools/javac/ExtDirs/ExtDirs.sh ! test/tools/javac/Paths/Help.sh ! test/tools/javac/javazip/Test.sh ! test/tools/javac/versions/check.sh Changeset: a8437c34fdc7 Author: jjg Date: 2011-01-24 16:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/a8437c34fdc7 6988106: javac report 'java.lang.IllegalMonitorStateException' Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/file/CacheFSInfo.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java + src/share/classes/com/sun/tools/javac/file/ZipFileIndexCache.java ! test/tools/javac/T6725036.java Changeset: 7f8794f9cc14 Author: darcy Date: 2011-01-25 17:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/7f8794f9cc14 7013420: Project Coin: remove general expression support from try-with-resources statement Reviewed-by: mcimadamore, jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/TryWithResources/BadTwrSyntax.out ! test/tools/javac/TryWithResources/DuplicateResource.java + test/tools/javac/TryWithResources/ExplicitFinal.java ! test/tools/javac/TryWithResources/ImplicitFinal.java ! test/tools/javac/TryWithResources/ImplicitFinal.out ! test/tools/javac/TryWithResources/TwrFlow.java ! test/tools/javac/TryWithResources/TwrFlow.out - test/tools/javac/TryWithResources/TwrInference.java - test/tools/javac/TryWithResources/TwrIntersection.java - test/tools/javac/TryWithResources/TwrIntersection02.java - test/tools/javac/TryWithResources/TwrIntersection02.out ! test/tools/javac/TryWithResources/TwrMultiCatch.java ! test/tools/javac/TryWithResources/TwrOnNonResource.java ! test/tools/javac/TryWithResources/TwrOnNonResource.out + test/tools/javac/diags/examples/TryResourceTrailingSemi.java Changeset: df371fd16386 Author: jjg Date: 2011-01-26 11:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/df371fd16386 6554097: "final" confuses @SuppressWarnings Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/T6554097.java + test/tools/javac/T6554097.out Changeset: 3da26790ccb7 Author: jjg Date: 2011-01-26 13:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/3da26790ccb7 7013272: Automatically generate info about how compiler resource keys are used Reviewed-by: mcimadamore ! make/build.xml ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/ArgTypeCompilerFactory.java ! test/tools/javac/diags/Example.java + test/tools/javac/diags/MessageFile.java + test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/RunExamples.java Changeset: 92ab09ed59fd Author: jjh Date: 2011-01-28 00:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/92ab09ed59fd 7015482: jtreg test tools/javac/diags/MessageInfo.java fails when test/ dir is not in langtools repo Summary: Don't fail if the needed file isn't present, if running under jtreg. Reviewed-by: jjg ! test/tools/javac/diags/MessageInfo.java Changeset: 2088e674f0e0 Author: mcimadamore Date: 2011-01-28 12:01 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/2088e674f0e0 6910550: javac 1.5.0_17 fails with incorrect error message Summary: multiple clashing members declared in same class should be added to the class' scope in order to avoid downstream spurious diagnostics Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/generics/6910550/T6910550a.java + test/tools/javac/generics/6910550/T6910550a.out + test/tools/javac/generics/6910550/T6910550b.java + test/tools/javac/generics/6910550/T6910550b.out + test/tools/javac/generics/6910550/T6910550c.java + test/tools/javac/generics/6910550/T6910550c.out + test/tools/javac/generics/6910550/T6910550d.java + test/tools/javac/generics/6910550/T6910550d.out + test/tools/javac/generics/6910550/T6910550e.java + test/tools/javac/generics/6910550/T6910550e.out Changeset: 5a43b245aed1 Author: mcimadamore Date: 2011-01-28 12:03 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/5a43b245aed1 6313164: javac generates code that fails byte code verification for the varargs feature Summary: method applicability check should fail if formal varargs element type is not accessible Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/InaccessibleVarargsType/InaccessibleVarargsType.java + test/tools/javac/diags/examples/InaccessibleVarargsType/p1/A.java + test/tools/javac/diags/examples/InaccessibleVarargsType/p1/B.java ! test/tools/javac/generics/inference/6638712/T6638712c.out ! test/tools/javac/generics/inference/6638712/T6638712d.out + test/tools/javac/varargs/6313164/T6313164.java + test/tools/javac/varargs/6313164/T6313164.out + test/tools/javac/varargs/6313164/p1/A.java + test/tools/javac/varargs/6313164/p1/B.java + test/tools/javac/varargs/6313164/p1/C.java Changeset: 17bafae67e9d Author: mcimadamore Date: 2011-01-28 12:06 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/17bafae67e9d 6838943: inference: javac is not handling type-variable substitution properly Summary: free type-variables are being replaced with type-variables bound to forall type leading to unsoundness Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/generics/inference/6838943/T6838943.java + test/tools/javac/generics/inference/6838943/T6838943.out Changeset: babf86a1ac92 Author: alanb Date: 2011-01-28 09:25 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/babf86a1ac92 7006126: (fs) Updates to file system API (1/2011) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/nio/PathFileObject.java ! test/tools/javac/nio/compileTest/CompileTest.java Changeset: df3394337b04 Author: alanb Date: 2011-01-28 12:36 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/df3394337b04 Merge Changeset: 7a75a1803c7a Author: darcy Date: 2011-01-28 16:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/7a75a1803c7a 7015530: Reiterate API specializations in javax.lang.model.elment subinterfaces Reviewed-by: jjg ! src/share/classes/javax/lang/model/element/Element.java ! src/share/classes/javax/lang/model/element/ExecutableElement.java ! src/share/classes/javax/lang/model/element/PackageElement.java ! src/share/classes/javax/lang/model/element/TypeElement.java ! src/share/classes/javax/lang/model/element/TypeParameterElement.java ! src/share/classes/javax/lang/model/element/VariableElement.java Changeset: 2ab47c4cd618 Author: darcy Date: 2011-01-31 19:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/2ab47c4cd618 7014734: Project Coin: Allow optional trailing semicolon to terminate resources list in try-with-resources Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/TryWithResources/BadTwrSyntax.java ! test/tools/javac/TryWithResources/BadTwrSyntax.out - test/tools/javac/diags/examples/TryResourceTrailingSemi.java Changeset: cad51b6eb7a6 Author: darcy Date: 2011-02-01 10:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/cad51b6eb7a6 6961571: Update visitors to support ARM's ElementKind.RESOURCE_VARIABLE Reviewed-by: jjg + src/share/classes/javax/lang/model/type/DisjunctiveType.java ! src/share/classes/javax/lang/model/type/TypeKind.java ! src/share/classes/javax/lang/model/type/TypeVisitor.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor6.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor7.java ! src/share/classes/javax/lang/model/util/ElementScanner6.java ! src/share/classes/javax/lang/model/util/ElementScanner7.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor7.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor7.java ! src/share/classes/javax/lang/model/util/Types.java ! test/tools/javac/processing/model/element/TestResourceVariable.java Changeset: 899f7c3d9426 Author: mcimadamore Date: 2011-02-03 09:35 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/899f7c3d9426 6594914: @SuppressWarnings("deprecation") does not not work for the type of a variable Summary: Lint warnings generated during MemberEnter might ignore @SuppressWarnings annotations Reviewed-by: jjg + src/share/classes/com/sun/tools/javac/code/DeferredLintHandler.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/warnings/6594914/DeprecatedClass.java + test/tools/javac/warnings/6594914/T6594914a.java + test/tools/javac/warnings/6594914/T6594914a.out + test/tools/javac/warnings/6594914/T6594914b.java + test/tools/javac/warnings/6594914/T6594914b.out Changeset: 875262e89b52 Author: mcimadamore Date: 2011-02-03 09:36 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/875262e89b52 5017953: spurious cascaded diagnostics when name not found Summary: when an operator is applied to one or more erroneous operands, spurious diagnostics are generated Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/5017953/T5017953.java + test/tools/javac/5017953/T5017953.out ! test/tools/javac/6491592/T6491592.out Changeset: 03cf47d4de15 Author: mcimadamore Date: 2011-02-03 09:37 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/03cf47d4de15 6969184: poor error recovery after symbol not found Summary: generic type-well formedness check should ignore erroneous symbols Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/6969184/T6969184.java + test/tools/javac/generics/6969184/T6969184.out Changeset: afe226180744 Author: mcimadamore Date: 2011-02-03 09:38 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/afe226180744 7014715: javac returns different error code for certain failure(s) Summary: javac silently crashes when emitting certain kinds of resolution diagnostics Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/AnonStaticMember_2.java + test/tools/javac/AnonStaticMember_2.out ! test/tools/javac/InterfaceInInner.java + test/tools/javac/InterfaceInInner.out ! test/tools/javac/QualifiedNew.java + test/tools/javac/QualifiedNew.out ! test/tools/javac/T6247324.out ! test/tools/javac/generics/diamond/neg/Neg01.out ! test/tools/javac/generics/inference/6943278/T6943278.out Changeset: 9e6a09375d37 Author: lana Date: 2011-02-04 17:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/9e6a09375d37 Merge Changeset: 3aa269645199 Author: mcimadamore Date: 2011-02-07 18:09 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/3aa269645199 7017414: before the move of JSR 292 to package java.lang.invoke, javac must recognize the new package Summary: added support for future 292 package (support for old location 'java.dyn' will be removed in followup changeset) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/util/Names.java Changeset: 96d4226bdd60 Author: mcimadamore Date: 2011-02-07 18:10 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/96d4226bdd60 7007615: java_util/generics/phase2/NameClashTest02 fails since jdk7/pit/b123. Summary: override clash algorithm is not implemented correctly Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/NameClashSameErasureNoHide.java ! test/tools/javac/diags/examples/NameClashSameErasureNoOverride.java + test/tools/javac/diags/examples/NameClashSameErasureNoOverride1.java ! test/tools/javac/generics/5009937/T5009937.out ! test/tools/javac/generics/6182950/T6182950b.out ! test/tools/javac/generics/6476118/T6476118a.out ! test/tools/javac/generics/6476118/T6476118b.out ! test/tools/javac/generics/6476118/T6476118c.java ! test/tools/javac/generics/6476118/T6476118c.out ! test/tools/javac/generics/6985719/T6985719e.out ! test/tools/javac/generics/6985719/T6985719f.out ! test/tools/javac/generics/6985719/T6985719g.out ! test/tools/javac/generics/6985719/T6985719h.out + test/tools/javac/generics/7007615/T7007615.java + test/tools/javac/generics/7007615/T7007615.out + test/tools/javac/generics/7007615/acc1/AccessibilityCheck01.java + test/tools/javac/generics/7007615/acc1/p1/C.java + test/tools/javac/generics/7007615/acc1/p1/D.java + test/tools/javac/generics/7007615/acc1/p2/E.java + test/tools/javac/generics/7007615/acc2/AccessibilityCheck02.java + test/tools/javac/generics/7007615/acc2/AccessibilityCheck02.out + test/tools/javac/generics/7007615/acc2/p1/C.java + test/tools/javac/generics/7007615/acc2/p1/D.java + test/tools/javac/generics/7007615/acc2/p2/E.java ! test/tools/javac/scope/HashCollisionTest.java ! test/tools/javac/scope/StarImportTest.java Changeset: 56b77a38618c Author: jjg Date: 2011-02-07 11:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/56b77a38618c 7017675: typo in JavacParser for allowUnderscoresInLiterals Reviewed-by: dlsmith Contributed-by: peter.b.kessler at oracle.com ! src/share/classes/com/sun/tools/javac/parser/Scanner.java Changeset: 2cbaa43eb075 Author: lana Date: 2011-02-14 16:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/2cbaa43eb075 Merge - test/tools/javac/TryWithResources/TwrInference.java - test/tools/javac/TryWithResources/TwrIntersection.java - test/tools/javac/TryWithResources/TwrIntersection02.java - test/tools/javac/TryWithResources/TwrIntersection02.out Changeset: a21c7f194d31 Author: mfang Date: 2011-02-10 16:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/a21c7f194d31 7017734: jdk7 message drop 1 translation integration Reviewed-by: ogino, yhuang ! src/share/classes/com/sun/tools/apt/resources/apt_ja.properties ! src/share/classes/com/sun/tools/apt/resources/apt_zh_CN.properties ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_ja.properties ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_zh_CN.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_ja.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_ja.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_zh_CN.properties Changeset: 4cdea0752a48 Author: mfang Date: 2011-02-11 22:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/4cdea0752a48 Merge Changeset: 26071d11c613 Author: mfang Date: 2011-02-11 23:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/26071d11c613 Merge Changeset: 7a98db8cbfce Author: ohair Date: 2011-02-15 12:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/7a98db8cbfce Merge Changeset: 6cdb76cf4d1a Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/6cdb76cf4d1a Added tag jdk7-b130 for changeset 7a98db8cbfce ! .hgtags Changeset: 22ea7d483794 Author: ohair Date: 2011-02-16 13:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/22ea7d483794 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: 67221b8643b4 Author: cl Date: 2011-02-23 15:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/67221b8643b4 Merge Changeset: 80bbd1da4a72 Author: cl Date: 2011-02-24 15:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/80bbd1da4a72 Added tag jdk7-b131 for changeset 67221b8643b4 ! .hgtags Changeset: c6cb387190ee Author: jjg Date: 2011-02-09 14:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/c6cb387190ee 7016750: tools/javac/nio/CompileTest failing in nightly test Reviewed-by: mcimadamore ! test/tools/javac/nio/compileTest/CompileTest.java Changeset: 3ce4e1a07e92 Author: jjg Date: 2011-02-09 14:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/3ce4e1a07e92 7010792: remove bad debugging method from javac Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/Scanner.java Changeset: bfa59f3e84bd Author: jjg Date: 2011-02-09 18:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/bfa59f3e84bd 7018447: langtools launcher template fails if tools run from their own directory Reviewed-by: jjg Contributed-by: daniel.smith at oracle.com ! src/share/bin/launcher.sh-template Changeset: a19b1f4f23c9 Author: jjg Date: 2011-02-10 14:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/a19b1f4f23c9 7018098: CacheFSInfo persists too long Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/CacheFSInfo.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/file/T7018098.java Changeset: 747a7601b6d6 Author: jjg Date: 2011-02-10 14:27 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/747a7601b6d6 7018452: langtools not buildable on Mac Reviewed-by: ohair ! make/build.xml Changeset: e0c16199b2e0 Author: jjg Date: 2011-02-10 15:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/e0c16199b2e0 6485027: javac incorrectly handles relative paths in manifest classpath Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/Paths.java ! test/tools/javac/Paths/Class-Path.sh + test/tools/javac/Paths/Class-Path2.sh ! test/tools/javac/Paths/Diagnostics.sh Changeset: bfeed79c70aa Author: jjg Date: 2011-02-11 17:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/bfeed79c70aa 6505047: javax.lang.model.element.Element.getEnclosingElement() doesn't return null for type parameter Reviewed-by: darcy + test/tools/javac/processing/model/element/TestTypeParameter.java Changeset: ef6c66215a93 Author: jjg Date: 2011-02-14 14:27 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/ef6c66215a93 7008433: Minor copyright changes Reviewed-by: jjg Contributed-by: kelly.ohair at oracle.com ! test/tools/javac/4917091/Test255.java ! test/tools/javac/4917091/Test256a.java ! test/tools/javac/4917091/Test256b.java Changeset: 351027202f60 Author: mcimadamore Date: 2011-02-15 11:49 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/351027202f60 7017664: Add listeners infrastracture to javac scopes Summary: Add listeners to javac scopes, added CompoundScope and correct invalidation logic for ImplementationCache Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/scope/7017664/CompoundScopeTest.java + test/tools/javac/scope/7017664/ImplementationCacheTest.java Changeset: fa0e4e1916f4 Author: mcimadamore Date: 2011-02-15 11:51 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/fa0e4e1916f4 7017104: improve error reporting for uncaught/undeclared exceptions from try-with-resources Summary: twr should generate better error message when uncaught exceptions are thrown by implicit call of close() method Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/TryWithResources/ResourceInterface.out ! test/tools/javac/TryWithResources/TwrFlow.out + test/tools/javac/diags/examples/UnreportedExceptionImplicitClose.java Changeset: 846d6644bb70 Author: lana Date: 2011-02-15 08:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/846d6644bb70 Merge Changeset: 0c24826853b2 Author: dlsmith Date: 2011-02-16 10:27 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/0c24826853b2 6990136: Cleanup use of Type.clone() Summary: Introduced factory methods in class Types which can be used rather than clone(). Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java Changeset: 4ce95dc0b908 Author: mcimadamore Date: 2011-02-18 12:28 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/4ce95dc0b908 7020043: Project Coin: diamond allowed on non-generic type Summary: Diamond oerator should be disallowed on non-generic class types (i.e. String) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/generics/diamond/neg/Neg12.java + test/tools/javac/generics/diamond/neg/Neg12.out Changeset: 3d45cc94ee0f Author: ksrini Date: 2011-02-18 08:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/3d45cc94ee0f 7018859: javac turn off the Zip optimization by default Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! test/tools/javac/4241573/T4241573.java ! test/tools/javac/6508981/TestInferBinaryName.java ! test/tools/javac/api/6411310/Test.java ! test/tools/javac/api/T6838467.java ! test/tools/javac/api/T6877206.java Changeset: 51e643f41a3a Author: mcimadamore Date: 2011-02-18 16:17 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/51e643f41a3a 7020626: diamond: add diagnostic test for diamond and non-generic classes Summary: Fix failure in regression test CheckExamples Reviewed-by: jjg + test/tools/javac/diags/examples/DiamondNonGeneric.java Changeset: 75e25df50873 Author: darcy Date: 2011-02-18 15:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/75e25df50873 7020047: Project Coin: generate null-check around try-with-resources close call Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/TryWithResources/TwrNullTests.java Changeset: de5524670f80 Author: lana Date: 2011-02-21 14:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/de5524670f80 Merge Changeset: e3d011d59a33 Author: lana Date: 2011-02-24 18:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/e3d011d59a33 Merge Changeset: e77e98f936e8 Author: katleman Date: 2011-03-03 14:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/e77e98f936e8 Added tag jdk7-b132 for changeset e3d011d59a33 ! .hgtags Changeset: 0d056b7b93de Author: cl Date: 2011-03-10 17:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/0d056b7b93de Added tag jdk7-b133 for changeset e77e98f936e8 ! .hgtags Changeset: 015dc9a63efc Author: mcimadamore Date: 2011-02-23 14:16 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/015dc9a63efc 7020657: Javac rejects a fairly common idiom with raw override and interfaces Summary: name clash should not be reported if subinterface/implementing class resolves the clash by defining common overrider Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/7020657/T7020657neg.java + test/tools/javac/generics/7020657/T7020657neg.out + test/tools/javac/generics/7020657/T7020657pos.java Changeset: 3ab7bb46c5c1 Author: mcimadamore Date: 2011-02-23 14:17 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/3ab7bb46c5c1 7019631: issues in test headers in b130 Summary: fix to test headers not containing correct bug ID Reviewed-by: jjg ! test/tools/javac/AnonStaticMember_2.java ! test/tools/javac/InterfaceInInner.java ! test/tools/javac/QualifiedNew.java ! test/tools/javac/generics/6969184/T6969184.java Changeset: 4b0491db73af Author: lana Date: 2011-02-23 10:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/4b0491db73af Merge Changeset: 3e30c95da3c6 Author: jjh Date: 2011-02-24 08:40 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/3e30c95da3c6 7018753: tools/javac/varargs/warning/Warn5.java times out on slow machines Summary: Use a single file manager for all JavacTasks Reviewed-by: jjg, mcimadamore ! test/tools/javac/varargs/6199075/T6199075.java ! test/tools/javac/varargs/warning/Warn4.java ! test/tools/javac/varargs/warning/Warn5.java Changeset: 8f0dcb9499db Author: jjg Date: 2011-02-25 12:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/8f0dcb9499db 7021650: fix Context issues Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/util/Bark.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/file/CacheFSInfo.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/Context.java ! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/JavadocTodo.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! test/tools/javac/diags/ArgTypeCompilerFactory.java ! test/tools/javac/diags/Example.java + test/tools/javac/util/context/T7021650.java Changeset: 23b64ad3eec8 Author: jjg Date: 2011-02-25 12:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/23b64ad3eec8 7022310: test/tools/javac/diags/Example: args added twice Reviewed-by: mcimadamore ! test/tools/javac/diags/Example.java Changeset: 9286a5d1fae3 Author: mcimadamore Date: 2011-02-28 11:48 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/9286a5d1fae3 7015430: Incorrect thrown type determined for unchecked invocations Summary: Thrown types do not get updated after 15.12.2.8, and do not get erased as per 15.12.2.6 Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/7015430/T7015430.java + test/tools/javac/generics/7015430/T7015430.out Changeset: 9f9df9684cfc Author: mcimadamore Date: 2011-02-28 11:50 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/9f9df9684cfc 7015715: lub gets stuck on type with complex supertype Summary: lub should not scan supertypes unnecessarily Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/generics/inference/T7015715.java Changeset: 9029f694e5df Author: jjg Date: 2011-02-28 12:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/9029f694e5df 7022337: repeated warnings about bootclasspath not set Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java - test/tools/javac/T6900037.java - test/tools/javac/T6900037.out + test/tools/javac/options/T6900037.java + test/tools/javac/options/T6900037.out + test/tools/javac/options/T7022337.java Changeset: bf9f162c7104 Author: jjg Date: 2011-02-28 13:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/bf9f162c7104 7022741: warning counts are wrong after anno processing Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/processing/TestWarnErrorCount.java ! test/tools/javac/processing/warnings/gold_0.out ! test/tools/javac/processing/warnings/gold_sv_warn_0_2.out ! test/tools/javac/processing/warnings/gold_sv_warn_2_3.out ! test/tools/javac/processing/warnings/gold_sv_warn_5_6.out Changeset: 67d6b2df47ba Author: jjg Date: 2011-02-28 13:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/67d6b2df47ba 7022711: compiler crash in try-with-resources Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Kinds.java + test/tools/javac/TryWithResources/T7022711.java + test/tools/javac/TryWithResources/T7022711.out Changeset: 938dda0bec17 Author: jjg Date: 2011-03-01 12:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/938dda0bec17 7021183: 269: assertion failure getting enclosing element of an undefined name Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symtab.java + test/tools/javac/processing/model/TestSymtabItems.java Changeset: 02b699d97a55 Author: mcimadamore Date: 2011-03-02 10:56 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/02b699d97a55 6541876: "Enclosing Instance" error new in 1.6 Summary: unqualified 'this' should not be selected in a qualified super() call in a default constructor Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/implicitThis/6541876/T6541876a.java + test/tools/javac/implicitThis/6541876/T6541876b.java ! test/tools/javac/implicitThis/NewBeforeOuterConstructed3.java ! test/tools/javac/nested/4903103/T4903103.java Changeset: 2a5c919f20b8 Author: jjg Date: 2011-03-02 14:03 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/2a5c919f20b8 6986895: compiler gives misleading message for no input files Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/resources/javac.properties + test/tools/javac/options/T6986895.java Changeset: 3085d0089546 Author: jjg Date: 2011-03-02 21:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/3085d0089546 6986892: confusing warning given after errors in annotation processing Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java + test/tools/javac/processing/warnings/UseImplicit/C1.java + test/tools/javac/processing/warnings/UseImplicit/TestProcUseImplicitWarning.java + test/tools/javac/processing/warnings/UseImplicit/err.out + test/tools/javac/processing/warnings/UseImplicit/p/C2.java + test/tools/javac/processing/warnings/UseImplicit/warn.out Changeset: 4baab658f357 Author: jjg Date: 2011-03-02 21:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/4baab658f357 6639645: Modeling type implementing missing interfaces Reviewed-by: darcy, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! test/tools/javac/api/6557752/T6557752.java + test/tools/javac/processing/model/element/TestMissingElement/InvalidSource.java + test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java + test/tools/javac/processing/model/element/TestMissingElement2/Generator.java + test/tools/javac/processing/model/element/TestMissingElement2/TestMissingClass.java + test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericClass1.java + test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericClass2.java + test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericInterface1.java + test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericInterface2.java + test/tools/javac/processing/model/element/TestMissingElement2/TestMissingInterface.java Changeset: e9b8fbb30f5a Author: mcimadamore Date: 2011-03-03 09:43 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/e9b8fbb30f5a 7023233: False positive for -Xlint:try with nested try with resources blocks Summary: Wrong lint warning issued about unused resource when nested try-with-resource blocks are found Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java + test/tools/javac/TryWithResources/UnusedResourcesTest.java Changeset: c15d788cb381 Author: mcimadamore Date: 2011-03-03 17:32 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/c15d788cb381 7023703: Valid code doesn't compile Summary: leftovers cause problems when analyzing loops in Flow.java Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java + test/tools/javac/7023703/T7023703neg.java + test/tools/javac/7023703/T7023703neg.out + test/tools/javac/7023703/T7023703pos.java Changeset: 32565546784b Author: mcimadamore Date: 2011-03-03 17:34 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/32565546784b 7022054: Invalid compiler error on covariant overriding methods with the same erasure Summary: Rules for method clash use notion of subsignature, which is sometimes too strict and incompatible with JDK 6 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/7022054/T7022054neg1.java + test/tools/javac/generics/7022054/T7022054neg1.out + test/tools/javac/generics/7022054/T7022054neg2.java + test/tools/javac/generics/7022054/T7022054neg2.out + test/tools/javac/generics/7022054/T7022054pos1.java + test/tools/javac/generics/7022054/T7022054pos2.java Changeset: 8fb48a9ac9ec Author: mcimadamore Date: 2011-03-03 18:05 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/8fb48a9ac9ec 7024212: TestWarnErrorCount fails Summary: TestWarnErrorCount should be executed with -Xlint:all,-path to avoid spurious failures Reviewed-by: jjg ! test/tools/javac/processing/TestWarnErrorCount.java Changeset: 7798e3a5ecf5 Author: jjg Date: 2011-03-04 11:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/7798e3a5ecf5 6966736: javac verbose output is inconsistent Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/main/AptJavaCompiler.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/util/Log.java Changeset: ebf7c13df6c0 Author: jjg Date: 2011-03-04 19:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/ebf7c13df6c0 6866185: Util.getPackageSourcePath should use lastIndexOf not indexOf and related cleanup Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterizedTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java ! src/share/classes/com/sun/tools/javadoc/WildcardTypeImpl.java Changeset: 4ee7de0684f5 Author: jjg Date: 2011-03-04 19:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/4ee7de0684f5 6227454: package.html and overview.html may not be read fully Reviewed-by: bpatel ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties + test/tools/javadoc/6227454/Test.java Changeset: 5e6c661891da Author: jjg Date: 2011-03-04 19:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/5e6c661891da 6964914: javadoc does not output number of warnings using user written doclet Reviewed-by: bpatel ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java ! src/share/classes/com/sun/tools/javadoc/Start.java + test/tools/javadoc/6964914/Error.java + test/tools/javadoc/6964914/JavacWarning.java + test/tools/javadoc/6964914/JavadocWarning.java + test/tools/javadoc/6964914/Test.java + test/tools/javadoc/6964914/TestStdDoclet.java + test/tools/javadoc/6964914/TestUserDoclet.java + test/tools/javadoc/T6968833.java Changeset: 74f0c05c51eb Author: mcimadamore Date: 2011-03-07 14:11 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/74f0c05c51eb 7024568: Very long method resolution causing OOM error Summary: Resolve.findMethod scans same receiver type more than once in certain inheritance graphs Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/7024568/T7024568.java + test/tools/javac/7024568/T7024568.out Changeset: ca32f2986301 Author: mcimadamore Date: 2011-03-07 14:31 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/ca32f2986301 7020044: Project Coin: diamond erroneous allowed on some anonymous inner classes Summary: Disallow diamond on anonymous innner class creation expression (as per JSR 334's EDR) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/DiamondAndAnonClass.java - test/tools/javac/diags/examples/DiamondInvalidArg.java - test/tools/javac/diags/examples/DiamondInvalidArgs.java ! test/tools/javac/generics/diamond/6996914/T6996914a.java ! test/tools/javac/generics/diamond/6996914/T6996914b.java ! test/tools/javac/generics/diamond/T6939780.java ! test/tools/javac/generics/diamond/T6939780.out ! test/tools/javac/generics/diamond/neg/Neg01.java ! test/tools/javac/generics/diamond/neg/Neg01.out ! test/tools/javac/generics/diamond/neg/Neg02.java ! test/tools/javac/generics/diamond/neg/Neg02.out ! test/tools/javac/generics/diamond/neg/Neg03.java ! test/tools/javac/generics/diamond/neg/Neg03.out ! test/tools/javac/generics/diamond/neg/Neg04.java ! test/tools/javac/generics/diamond/neg/Neg04.out ! test/tools/javac/generics/diamond/neg/Neg05.java ! test/tools/javac/generics/diamond/neg/Neg05.out ! test/tools/javac/generics/diamond/neg/Neg06.java ! test/tools/javac/generics/diamond/neg/Neg06.out ! test/tools/javac/generics/diamond/neg/Neg07.java ! test/tools/javac/generics/diamond/neg/Neg07.out ! test/tools/javac/generics/diamond/neg/Neg08.java ! test/tools/javac/generics/diamond/neg/Neg08.out ! test/tools/javac/generics/diamond/neg/Neg09.java ! test/tools/javac/generics/diamond/neg/Neg09.out ! test/tools/javac/generics/diamond/neg/Neg10.java ! test/tools/javac/generics/diamond/neg/Neg11.java - test/tools/javac/generics/diamond/neg/Neg12.java - test/tools/javac/generics/diamond/neg/Neg12.out ! test/tools/javac/generics/diamond/pos/Pos01.java ! test/tools/javac/generics/diamond/pos/Pos02.java ! test/tools/javac/generics/diamond/pos/Pos03.java ! test/tools/javac/generics/diamond/pos/Pos04.java ! test/tools/javac/generics/diamond/pos/Pos05.java + test/tools/javac/generics/diamond/pos/Pos06.java + test/tools/javac/generics/diamond/pos/Pos07.java - test/tools/javac/multicatch/Neg05.java - test/tools/javac/multicatch/Neg05.out + test/tools/javac/multicatch/Pos09.java Changeset: b1b898c00b71 Author: lana Date: 2011-03-07 11:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/b1b898c00b71 Merge Changeset: cb9493a80341 Author: jjg Date: 2011-03-07 13:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/cb9493a80341 6980021: javac should document @file command line option Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/main/OptionName.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java ! src/share/classes/com/sun/tools/javac/resources/javac.properties ! test/tools/javac/diags/CheckResourceKeys.java Changeset: d7dfa105f159 Author: lana Date: 2011-03-10 20:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/d7dfa105f159 Merge - test/tools/javac/T6900037.java - test/tools/javac/T6900037.out - test/tools/javac/diags/examples/DiamondInvalidArg.java - test/tools/javac/diags/examples/DiamondInvalidArgs.java - test/tools/javac/generics/diamond/neg/Neg12.java - test/tools/javac/generics/diamond/neg/Neg12.out - test/tools/javac/multicatch/Neg05.java - test/tools/javac/multicatch/Neg05.out Changeset: 0f19e1e98b42 Author: mfang Date: 2011-03-08 23:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/0f19e1e98b42 7025324: NLS: t13y fix for 7022005 [ja,zh_CN] javadoc, part of navigation bar in generated html are not translated Reviewed-by: yhuang, ogino, jennyh ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties Changeset: 654336cabc5a Author: mfang Date: 2011-03-13 14:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/654336cabc5a Merge Changeset: 3d7acdbb72ca Author: ohair Date: 2011-03-15 15:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/3d7acdbb72ca Merge Changeset: 9d0a61ac567b Author: schien Date: 2011-03-17 14:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/9d0a61ac567b Added tag jdk7-b134 for changeset 3d7acdbb72ca ! .hgtags From John.Coomes at oracle.com Sun Mar 20 12:19:00 2011 From: John.Coomes at oracle.com (John Coomes) Date: Sun, 20 Mar 2011 12:19:00 -0700 Subject: review request (S/M): 6962931 move interned strings out of perm gen In-Reply-To: References: <19804.4904.199261.456867@oracle.com> <5AC4655F-8423-4BD9-873C-7578DF5DF049@oracle.com> <4D5D4AEC.6000401@oracle.com> Message-ID: <19846.21284.596969.867220@oracle.com> Tom Rodriguez (tom.rodriguez at oracle.com) wrote: > On Feb 17, 2011, at 8:21 AM, Coleen Phillimore wrote: > > The option ScavengeRootsInCode is a bit confusing since this is > > moving all strings out of permgen so shouldn't depend on a flag > > that has meaning to the compiler. I'd like to see the code > > conditional on this flag removed. > > Currently ScavengeRootsInCode controls two things. One is the GC > machinery that supports embedding scavengeable oops into compiled > code and the other is which kinds of oops the compiler considers to > be embeddable. The first part will become required behaviour by the > end of 7 since invokedynamic requires it so at some point all tests > which are comparing ScavengeRootsInCode with 0 should be simplified > so that it's no longer optional. We could do that now but it might > be worth waiting a little while so that we can use that flag to > narrow down problems by turning it off. > > Anyway, I agree that controlling it through ScavengeRootsInCode is > odd. Maybe we need a separate temporary flag for putting Strings > and Classes in perm? Until perm goes away completely we can still > allocate them there and things would continue to work fine. Background for the list: Tom's changes for 7017732 (move static fields to Class) introduced globals.hpp var JavaObjectsInPerm, which sets ScavengeRootsInCode to 1 if necessary. After syncing with 7017732, I've updated the interned strings code to use JavaObjectsInPerm; I also moved PSScavengeRootsClosure so we don't need a second copy in psScavenge.cpp. The updated webrev is http://cr.openjdk.java.net/~jcoomes/6962931-intern/ For reviewers of the previous round, that page has a link to a separate webrev with just the post-sync changes. > > The other comment I have is based on ignorance. Isn't "tenured' > > the old generation? So create_tenured_from_unicode() calls > > basic_create() with a tenured flag and it either allocates the > > string in permgen or eden, so it doesn't make sense if I have the > > correct meaning of tenured. > > That's a long time oddity. I think it probably dates to the time > when there was no perm gen and meta data was simply in tenured mixed > with other data. It will be corrected by the time we are done since > it will simply go away. I'll add a note to the perm gen removal project page so it doesn't get forgotten. -John > > This would be fixed if the conditional code is removed also, if not, the names should be changed. There is also a create_from_unicode() that is uncalled, presumably because someone added create_tenured_from_unicode(). > > > > Thanks, > > Coleen > > > > On 2/16/2011 2:05 PM, Tom Rodriguez wrote: > >> I had assumed we'd be switching so that strings were always outside perm by default. ScavengeRootsInCode must be != 0 once invokedynamic is enabled by default and since that's definitely going to be enabled in 7 don't we want to turn all this on? > >> > >> tom > >> > >> On Feb 16, 2011, at 10:10 AM, John Coomes wrote: > >> > >>> This moves interned strings from the perm gen into the regular heap. > >>> The code was written by Tom Rodriguez; I've added a minor fix and done > >>> the testing. More info in the webrev: > >>> > >>> http://cr.openjdk.java.net/~jcoomes/6962931-intern/ > >>> > >>> Thanks for any feedback. > >>> > >>> -John > >>> > > > From mlists at juma.me.uk Sun Mar 20 12:55:36 2011 From: mlists at juma.me.uk (Ismael Juma) Date: Sun, 20 Mar 2011 19:55:36 +0000 (UTC) Subject: review request (S/M): 6962931 move interned strings out of =?utf-8?b?cGVybQlnZW4=?= References: <19804.4904.199261.456867@oracle.com> <5AC4655F-8423-4BD9-873C-7578DF5DF049@oracle.com> <4D5D4AEC.6000401@oracle.com> <19846.21284.596969.867220@oracle.com> Message-ID: John Coomes writes: > I'll add a note to the perm gen removal project page so it doesn't get > forgotten. Is this page publicly available? Best, Ismael From John.Coomes at oracle.com Sun Mar 20 13:11:09 2011 From: John.Coomes at oracle.com (John Coomes) Date: Sun, 20 Mar 2011 13:11:09 -0700 Subject: review request (S/M): 6962931 move interned strings out of =?utf-8?b?cGVybQlnZW4=?= In-Reply-To: References: <19804.4904.199261.456867@oracle.com> <5AC4655F-8423-4BD9-873C-7578DF5DF049@oracle.com> <4D5D4AEC.6000401@oracle.com> <19846.21284.596969.867220@oracle.com> Message-ID: <19846.24413.581638.679158@oracle.com> Ismael Juma (mlists at juma.me.uk) wrote: > John Coomes writes: > > I'll add a note to the perm gen removal project page so it doesn't get > > forgotten. > > Is this page publicly available? Hi Ismael, Unfortunately no. As I understand it (I'm not directly involved in the process, so take this with a grain of salt), the public bug db is the current priority, followed by public planning infrastructure. -John From mlists at juma.me.uk Sun Mar 20 13:14:47 2011 From: mlists at juma.me.uk (Ismael Juma) Date: Sun, 20 Mar 2011 20:14:47 +0000 (UTC) Subject: review request (S/M): 6962931 move interned strings out =?utf-8?b?b2YJcGVybQlnZW4=?= References: <19804.4904.199261.456867@oracle.com> <5AC4655F-8423-4BD9-873C-7578DF5DF049@oracle.com> <4D5D4AEC.6000401@oracle.com> <19846.21284.596969.867220@oracle.com> <19846.24413.581638.679158@oracle.com> Message-ID: John Coomes writes: > Unfortunately no. As I understand it (I'm not directly involved in > the process, so take this with a grain of salt), the public bug db is > the current priority, followed by public planning infrastructure. Thanks for the quick reply. Best, Ismael From tom.rodriguez at oracle.com Mon Mar 21 10:38:30 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 21 Mar 2011 10:38:30 -0700 Subject: review (XS) for 7029509: nightly failures after static fields in Class Message-ID: http://cr.openjdk.java.net/~never/7029509 7029509: nightly failures after static fields in Class Reviewed-by: There were a few failures in hotspot-gc after the static fields in Classes change. Two failures are because of missed places where the address of static fields were computed. The third is because only real Java klasses have a mirror now so they should be skipped when updating the class redefinition statistics. Tested with nsk hprof, heapdump and the nsk/jvmti/scenarios tests. From vladimir.kozlov at oracle.com Mon Mar 21 11:26:22 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Mar 2011 11:26:22 -0700 Subject: review (XS) for 7029509: nightly failures after static fields in Class In-Reply-To: References: Message-ID: <4D87984E.7010909@oracle.com> Looks good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7029509 > > 7029509: nightly failures after static fields in Class > Reviewed-by: > > There were a few failures in hotspot-gc after the static fields in > Classes change. Two failures are because of missed places where the > address of static fields were computed. The third is because only > real Java klasses have a mirror now so they should be skipped when > updating the class redefinition statistics. Tested with nsk hprof, > heapdump and the nsk/jvmti/scenarios tests. From daniel.daugherty at oracle.com Mon Mar 21 12:35:18 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 21 Mar 2011 13:35:18 -0600 Subject: review (XS) for 7029509: nightly failures after static fields in Class In-Reply-To: References: Message-ID: <4D87A876.8000907@oracle.com> On 3/21/2011 11:38 AM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7029509 > Thumbs up. src/share/vm/prims/jvmtiRedefineClasses.cpp It looks like this fix would be applicable even in the absence of moving static fields. src/share/vm/prims/jvmtiTagMap.cpp No comments. src/share/vm/services/heapDumper.cpp No comments. Dan > 7029509: nightly failures after static fields in Class > Reviewed-by: > > There were a few failures in hotspot-gc after the static fields in > Classes change. Two failures are because of missed places where the > address of static fields were computed. The third is because only > real Java klasses have a mirror now so they should be skipped when > updating the class redefinition statistics. Tested with nsk hprof, > heapdump and the nsk/jvmti/scenarios tests. > From christian.thalinger at oracle.com Tue Mar 22 05:05:32 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 22 Mar 2011 13:05:32 +0100 Subject: Request for review (S): 7029805: JSR 292 compiler/6991596/Test6991596.java fails in nightly Message-ID: <6B328891-30B0-47FE-AA84-5535AB4B6AD5@oracle.com> http://cr.openjdk.java.net/~twisti/7029805/ 7029805: JSR 292 compiler/6991596/Test6991596.java fails in nightly Summary: Both JSR 292 compiler tests were moved with 6839872 to the jdk repository Reviewed-by: Both JSR 292 compiler tests were moved with 6839872 to the jdk repository. 7017465 addresses the same problem for HSX 20. This patch removes the tests from the hotspot repository. test/compiler/6991596/Test6991596.java test/compiler/6987555/Test6987555.java From tom.rodriguez at oracle.com Tue Mar 22 10:52:57 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 22 Mar 2011 10:52:57 -0700 Subject: Request for review (S): 7029805: JSR 292 compiler/6991596/Test6991596.java fails in nightly In-Reply-To: <6B328891-30B0-47FE-AA84-5535AB4B6AD5@oracle.com> References: <6B328891-30B0-47FE-AA84-5535AB4B6AD5@oracle.com> Message-ID: Looks good. tom On Mar 22, 2011, at 5:05 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7029805/ > > 7029805: JSR 292 compiler/6991596/Test6991596.java fails in nightly > Summary: Both JSR 292 compiler tests were moved with 6839872 to the jdk repository > Reviewed-by: > > Both JSR 292 compiler tests were moved with 6839872 to the jdk > repository. 7017465 addresses the same problem for HSX 20. This > patch removes the tests from the hotspot repository. > > test/compiler/6991596/Test6991596.java > test/compiler/6987555/Test6987555.java > From christian.thalinger at oracle.com Tue Mar 22 10:55:57 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 22 Mar 2011 18:55:57 +0100 Subject: Request for review (S): 7029805: JSR 292 compiler/6991596/Test6991596.java fails in nightly In-Reply-To: References: <6B328891-30B0-47FE-AA84-5535AB4B6AD5@oracle.com> Message-ID: <6EC01967-FCD8-448E-9151-52774A19399D@oracle.com> On Mar 22, 2011, at 6:52 PM, Tom Rodriguez wrote: > Looks good. Thank you, Tom. -- Christian > > tom > > On Mar 22, 2011, at 5:05 AM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/7029805/ >> >> 7029805: JSR 292 compiler/6991596/Test6991596.java fails in nightly >> Summary: Both JSR 292 compiler tests were moved with 6839872 to the jdk repository >> Reviewed-by: >> >> Both JSR 292 compiler tests were moved with 6839872 to the jdk >> repository. 7017465 addresses the same problem for HSX 20. This >> patch removes the tests from the hotspot repository. >> >> test/compiler/6991596/Test6991596.java >> test/compiler/6987555/Test6987555.java From john.r.rose at oracle.com Wed Mar 23 02:13:39 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 23 Mar 2011 09:13:39 +0000 Subject: hg: jdk7/hotspot/jdk: 6839872: remove implementation inheritance from JSR 292 APIs Message-ID: <20110323091413.E8C89473D1@hg.openjdk.java.net> Changeset: 5acc8cf00539 Author: jrose Date: 2011-03-18 00:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5acc8cf00539 6839872: remove implementation inheritance from JSR 292 APIs Summary: move everything into a single package; remove all multi-package machinery Reviewed-by: twisti, forax + src/share/classes/java/dyn/AdapterMethodHandle.java + src/share/classes/java/dyn/BoundMethodHandle.java ! src/share/classes/java/dyn/CallSite.java ! src/share/classes/java/dyn/ClassValue.java + src/share/classes/java/dyn/DirectMethodHandle.java + src/share/classes/java/dyn/FilterGeneric.java + src/share/classes/java/dyn/FilterOneArgument.java + src/share/classes/java/dyn/FromGeneric.java ! src/share/classes/java/dyn/InvokeDynamic.java + src/share/classes/java/dyn/InvokeGeneric.java + src/share/classes/java/dyn/Invokers.java ! src/share/classes/java/dyn/Linkage.java + src/share/classes/java/dyn/MemberName.java ! src/share/classes/java/dyn/MethodHandle.java + src/share/classes/java/dyn/MethodHandleImpl.java + src/share/classes/java/dyn/MethodHandleNatives.java + src/share/classes/java/dyn/MethodHandleStatics.java ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/java/dyn/MethodType.java ! src/share/classes/java/dyn/MethodTypeForm.java ! src/share/classes/java/dyn/MutableCallSite.java + src/share/classes/java/dyn/SpreadGeneric.java + src/share/classes/java/dyn/ToGeneric.java ! src/share/classes/java/dyn/VolatileCallSite.java ! src/share/classes/java/dyn/WrongMethodTypeException.java - src/share/classes/sun/dyn/Access.java - src/share/classes/sun/dyn/AdapterMethodHandle.java - src/share/classes/sun/dyn/BoundMethodHandle.java - src/share/classes/sun/dyn/CallSiteImpl.java - src/share/classes/sun/dyn/DirectMethodHandle.java - src/share/classes/sun/dyn/FilterGeneric.java - src/share/classes/sun/dyn/FilterOneArgument.java - src/share/classes/sun/dyn/FromGeneric.java - src/share/classes/sun/dyn/InvokeGeneric.java - src/share/classes/sun/dyn/Invokers.java - src/share/classes/sun/dyn/MemberName.java - src/share/classes/sun/dyn/MethodHandleImpl.java - src/share/classes/sun/dyn/MethodHandleNatives.java - src/share/classes/sun/dyn/MethodTypeImpl.java - src/share/classes/sun/dyn/SpreadGeneric.java - src/share/classes/sun/dyn/ToGeneric.java ! src/share/classes/sun/dyn/util/ValueConversions.java ! src/share/classes/sun/dyn/util/VerifyAccess.java + test/java/dyn/6987555/Test6987555.java + test/java/dyn/6991596/Test6991596.java ! test/java/dyn/MethodTypeTest.java From christian.thalinger at oracle.com Wed Mar 23 08:32:14 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 23 Mar 2011 16:32:14 +0100 Subject: segmentation fault in the jvm In-Reply-To: <4D8A0D60.5080604@csail.mit.edu> References: <4D8A0D60.5080604@csail.mit.edu> Message-ID: <9F3CDB65-DA02-46D6-9865-76428C0555B7@oracle.com> [Bcc'ing jdk7-dev.] On Mar 23, 2011, at 4:10 PM, Stefanie Tellex wrote: > Hi, > > Not sure if this is the right place to report this, The right list would be: hotspot-dev at openjdk.java.net > but I have a Java program that reliably seg faults the JVM when run under GDB. It doesn't seem to happen (quickly) when I run it without gdb. It also doesn't seem to happen if I turn off the JIT, although the original seg fault that triggered this (part of a much larger program) would still happen with the JIT turned off, although it took longer. > > The program is attached, and the command I am running is this: > > gdb --args $JAVA_HOME/jre/bin/java -classpath . Test > > The java program loops forever. It gets through about 10 iterations and then seg faults with this backtrace: > > (gdb) bt > #0 0xb4192300 in ?? () > Cannot access memory at address 0x234 What you are seeing is that compiled code uses various signals for different things, like implicit null-pointer checks. It happens when running in GDB because the debugger handles such signals by default. When you run the java command in GDB in compiled mode (-Xcomp) you will see something like: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x1beb70 (LWP 13690)] 0xf4e74fcc in ?? () Ignoring SEGSEGV signals and continuing should run the java command fine: (gdb) handle SIGSEGV noprint Signal Stop Print Pass to program Description SIGSEGV No No Yes Segmentation fault (gdb) c Continuing. Usage: java [-options] class [args...] ... Hope that helps. -- Christian > > > I also wrote a simple JNI program (attached in the tar.gz) that creates the JVM and calls Test programmatically. When I run it, it seg faults after about 10 iterations, (sometimes more, sometimes fewer, every once in a while it will run for quite a long time). > (gdb) bt > #0 0x41171329 in ?? () > #1 0x4107f3bd in ?? () > #2 0x40400dc3 in JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) () > from /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so > #3 0x405f2569 in os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*) () from /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so > #4 0x403fe907 in JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) () > from /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so > #5 0x40420a73 in jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) () > from /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so > #6 0x4044b2bb in jni_NewObjectV () from /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so > #7 0x40471542 in checked_jni_NewObjectV () from /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so > #8 0x08048a71 in JNIEnv_::NewObject (this=0x806353c, clazz=0x806475c, methodID=0x80eb088) > at /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//include/jni.h:872 > #9 0x080488ab in jvm_test () at c/create_jvm.cxx:63 > #10 0x08048a16 in main () at c/create_jvm.cxx:116 > > > I ran the same program in valgrind and I get lots of errors about call_helper doing invalid writes: > > ==24756== > ==24756== Invalid write of size 4 > ==24756== at 0x5494416: ??? > ==24756== by 0x548C0F6: ??? > ==24756== by 0x548BD04: ??? > ==24756== by 0x548BE29: ??? > ==24756== by 0x54893BC: ??? > ==24756== by 0x440ADC2: JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) (in /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) > ==24756== by 0x45FC568: os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*) (in /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) > ==24756== by 0x4408906: JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) (in /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) > ==24756== by 0x44B0A0F: JVM_DoPrivileged (in /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) > ==24756== by 0x540E07A: Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedExceptionAction_2 (AccessController.c:67) > ==24756== by 0x549571A: ??? > ==24756== by 0x548BE29: ??? > ==24756== Address 0xbe951754 is not stack'd, malloc'd or (recently) free'd > > > I've reproduced this against 1.7 as well as 1.6 and 1.5. > > There are some bugs that seem to refer to this problem, although they don't seem to be fixed or to have reproduction instructions. > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7016961 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7016303 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7017562 > > Any hints would be appreciated. > > Stefanie From stefie10 at csail.mit.edu Wed Mar 23 09:31:26 2011 From: stefie10 at csail.mit.edu (Stefanie Tellex) Date: Wed, 23 Mar 2011 12:31:26 -0400 Subject: segmentation fault in the jvm In-Reply-To: <9F3CDB65-DA02-46D6-9865-76428C0555B7@oracle.com> References: <4D8A0D60.5080604@csail.mit.edu> <9F3CDB65-DA02-46D6-9865-76428C0555B7@oracle.com> Message-ID: <4D8A205E.4090106@csail.mit.edu> Thanks for your reply. What is the recommended way to debug "legitimate" seg faults when invoking the JVM? I am creating a JVM using the invocation API, and getting a seg fault, probably because of a memory problem in our C code. It says "Command terminated by signal 11" when running without gdb, but no stack trace. After I got that, I ran the program in gdb to try to debug it, and eventually isolated the problem to the test case I sent out before. But it seems like that's not related to the original problem...? Thanks, Stefanie On 03/23/2011 11:32 AM, Christian Thalinger wrote: > [Bcc'ing jdk7-dev.] > > On Mar 23, 2011, at 4:10 PM, Stefanie Tellex wrote: >> Hi, >> >> Not sure if this is the right place to report this, > > The right list would be: hotspot-dev at openjdk.java.net > >> but I have a Java program that reliably seg faults the JVM when run under GDB. It doesn't seem to happen (quickly) when I run it without gdb. It also doesn't seem to happen if I turn off the JIT, although the original seg fault that triggered this (part of a much larger program) would still happen with the JIT turned off, although it took longer. >> >> The program is attached, and the command I am running is this: >> >> gdb --args $JAVA_HOME/jre/bin/java -classpath . Test >> >> The java program loops forever. It gets through about 10 iterations and then seg faults with this backtrace: >> >> (gdb) bt >> #0 0xb4192300 in ?? () >> Cannot access memory at address 0x234 > > What you are seeing is that compiled code uses various signals for different things, like implicit null-pointer checks. It happens when running in GDB because the debugger handles such signals by default. > > When you run the java command in GDB in compiled mode (-Xcomp) you will see something like: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x1beb70 (LWP 13690)] > 0xf4e74fcc in ?? () > > Ignoring SEGSEGV signals and continuing should run the java command fine: > > (gdb) handle SIGSEGV noprint > Signal Stop Print Pass to program Description > SIGSEGV No No Yes Segmentation fault > (gdb) c > Continuing. > Usage: java [-options] class [args...] > ... > > Hope that helps. > > -- Christian > >> >> >> I also wrote a simple JNI program (attached in the tar.gz) that creates the JVM and calls Test programmatically. When I run it, it seg faults after about 10 iterations, (sometimes more, sometimes fewer, every once in a while it will run for quite a long time). >> (gdb) bt >> #0 0x41171329 in ?? () >> #1 0x4107f3bd in ?? () >> #2 0x40400dc3 in JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) () >> from /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >> #3 0x405f2569 in os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*) () from /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >> #4 0x403fe907 in JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) () >> from /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >> #5 0x40420a73 in jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) () >> from /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >> #6 0x4044b2bb in jni_NewObjectV () from /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >> #7 0x40471542 in checked_jni_NewObjectV () from /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >> #8 0x08048a71 in JNIEnv_::NewObject (this=0x806353c, clazz=0x806475c, methodID=0x80eb088) >> at /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//include/jni.h:872 >> #9 0x080488ab in jvm_test () at c/create_jvm.cxx:63 >> #10 0x08048a16 in main () at c/create_jvm.cxx:116 >> >> >> I ran the same program in valgrind and I get lots of errors about call_helper doing invalid writes: >> >> ==24756== >> ==24756== Invalid write of size 4 >> ==24756== at 0x5494416: ??? >> ==24756== by 0x548C0F6: ??? >> ==24756== by 0x548BD04: ??? >> ==24756== by 0x548BE29: ??? >> ==24756== by 0x54893BC: ??? >> ==24756== by 0x440ADC2: JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) (in /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >> ==24756== by 0x45FC568: os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*) (in /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >> ==24756== by 0x4408906: JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) (in /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >> ==24756== by 0x44B0A0F: JVM_DoPrivileged (in /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >> ==24756== by 0x540E07A: Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedExceptionAction_2 (AccessController.c:67) >> ==24756== by 0x549571A: ??? >> ==24756== by 0x548BE29: ??? >> ==24756== Address 0xbe951754 is not stack'd, malloc'd or (recently) free'd >> >> >> I've reproduced this against 1.7 as well as 1.6 and 1.5. >> >> There are some bugs that seem to refer to this problem, although they don't seem to be fixed or to have reproduction instructions. >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7016961 >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7016303 >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7017562 >> >> Any hints would be appreciated. >> >> Stefanie > > From stefie10 at csail.mit.edu Wed Mar 23 09:39:44 2011 From: stefie10 at csail.mit.edu (Stefanie Tellex) Date: Wed, 23 Mar 2011 12:39:44 -0400 Subject: segmentation fault in the jvm In-Reply-To: <4D8A205E.4090106@csail.mit.edu> References: <4D8A0D60.5080604@csail.mit.edu> <9F3CDB65-DA02-46D6-9865-76428C0555B7@oracle.com> <4D8A205E.4090106@csail.mit.edu> Message-ID: <4D8A2250.4060204@csail.mit.edu> To partially answer my own question, what I'm doing now based on Christian's information is pressing "c" in gdb to tell it to ignore the seg fault and keep going. Eventually it gets to my seg fault, which has a non-jvm stack trace... Stefanie On 03/23/2011 12:31 PM, Stefanie Tellex wrote: > Thanks for your reply. > > What is the recommended way to debug "legitimate" seg faults when > invoking the JVM? > > I am creating a JVM using the invocation API, and getting a seg fault, > probably because of a memory problem in our C code. It says "Command > terminated by signal 11" when running without gdb, but no stack trace. > > After I got that, I ran the program in gdb to try to debug it, and > eventually isolated the problem to the test case I sent out before. But > it seems like that's not related to the original problem...? > > Thanks, > > Stefanie > > On 03/23/2011 11:32 AM, Christian Thalinger wrote: >> [Bcc'ing jdk7-dev.] >> >> On Mar 23, 2011, at 4:10 PM, Stefanie Tellex wrote: >>> Hi, >>> >>> Not sure if this is the right place to report this, >> >> The right list would be: hotspot-dev at openjdk.java.net >> >>> but I have a Java program that reliably seg faults the JVM when run >>> under GDB. It doesn't seem to happen (quickly) when I run it without >>> gdb. It also doesn't seem to happen if I turn off the JIT, although >>> the original seg fault that triggered this (part of a much larger >>> program) would still happen with the JIT turned off, although it took >>> longer. >>> >>> The program is attached, and the command I am running is this: >>> >>> gdb --args $JAVA_HOME/jre/bin/java -classpath . Test >>> >>> The java program loops forever. It gets through about 10 iterations >>> and then seg faults with this backtrace: >>> >>> (gdb) bt >>> #0 0xb4192300 in ?? () >>> Cannot access memory at address 0x234 >> >> What you are seeing is that compiled code uses various signals for >> different things, like implicit null-pointer checks. It happens when >> running in GDB because the debugger handles such signals by default. >> >> When you run the java command in GDB in compiled mode (-Xcomp) you >> will see something like: >> >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 0x1beb70 (LWP 13690)] >> 0xf4e74fcc in ?? () >> >> Ignoring SEGSEGV signals and continuing should run the java command fine: >> >> (gdb) handle SIGSEGV noprint >> Signal Stop Print Pass to program Description >> SIGSEGV No No Yes Segmentation fault >> (gdb) c >> Continuing. >> Usage: java [-options] class [args...] >> ... >> >> Hope that helps. >> >> -- Christian >> >>> >>> >>> I also wrote a simple JNI program (attached in the tar.gz) that >>> creates the JVM and calls Test programmatically. When I run it, it >>> seg faults after about 10 iterations, (sometimes more, sometimes >>> fewer, every once in a while it will run for quite a long time). >>> (gdb) bt >>> #0 0x41171329 in ?? () >>> #1 0x4107f3bd in ?? () >>> #2 0x40400dc3 in JavaCalls::call_helper(JavaValue*, methodHandle*, >>> JavaCallArguments*, Thread*) () >>> from >>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>> >>> #3 0x405f2569 in os::os_exception_wrapper(void (*)(JavaValue*, >>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, >>> methodHandle*, JavaCallArguments*, Thread*) () from >>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>> >>> #4 0x403fe907 in JavaCalls::call(JavaValue*, methodHandle, >>> JavaCallArguments*, Thread*) () >>> from >>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>> >>> #5 0x40420a73 in jni_invoke_nonstatic(JNIEnv_*, JavaValue*, >>> _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) () >>> from >>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>> >>> #6 0x4044b2bb in jni_NewObjectV () from >>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>> >>> #7 0x40471542 in checked_jni_NewObjectV () from >>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>> >>> #8 0x08048a71 in JNIEnv_::NewObject (this=0x806353c, clazz=0x806475c, >>> methodID=0x80eb088) >>> at /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//include/jni.h:872 >>> #9 0x080488ab in jvm_test () at c/create_jvm.cxx:63 >>> #10 0x08048a16 in main () at c/create_jvm.cxx:116 >>> >>> >>> I ran the same program in valgrind and I get lots of errors about >>> call_helper doing invalid writes: >>> >>> ==24756== >>> ==24756== Invalid write of size 4 >>> ==24756== at 0x5494416: ??? >>> ==24756== by 0x548C0F6: ??? >>> ==24756== by 0x548BD04: ??? >>> ==24756== by 0x548BE29: ??? >>> ==24756== by 0x54893BC: ??? >>> ==24756== by 0x440ADC2: JavaCalls::call_helper(JavaValue*, >>> methodHandle*, JavaCallArguments*, Thread*) (in >>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >>> >>> ==24756== by 0x45FC568: os::os_exception_wrapper(void (*)(JavaValue*, >>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, >>> methodHandle*, JavaCallArguments*, Thread*) (in >>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >>> >>> ==24756== by 0x4408906: JavaCalls::call(JavaValue*, methodHandle, >>> JavaCallArguments*, Thread*) (in >>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >>> >>> ==24756== by 0x44B0A0F: JVM_DoPrivileged (in >>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >>> >>> ==24756== by 0x540E07A: >>> Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedExceptionAction_2 >>> (AccessController.c:67) >>> ==24756== by 0x549571A: ??? >>> ==24756== by 0x548BE29: ??? >>> ==24756== Address 0xbe951754 is not stack'd, malloc'd or (recently) >>> free'd >>> >>> >>> I've reproduced this against 1.7 as well as 1.6 and 1.5. >>> >>> There are some bugs that seem to refer to this problem, although they >>> don't seem to be fixed or to have reproduction instructions. >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7016961 >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7016303 >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7017562 >>> >>> Any hints would be appreciated. >>> >>> Stefanie >> >> > From tom.rodriguez at oracle.com Wed Mar 23 09:39:56 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 23 Mar 2011 09:39:56 -0700 Subject: review (XS) for 7030300: more nightly failures after statics in Class changes Message-ID: http://cr.openjdk.java.net/~never/7030300 7030300: more nightly failures after statics in Class changes Reviewed-by: Yet another place that needs to be updated when writing static field values and the c1 CodeStubs changes need to be compressed oops aware. Tested with failing tests from nightly. From igor.veresov at oracle.com Wed Mar 23 09:56:08 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 23 Mar 2011 09:56:08 -0700 Subject: review (XS) for 7030300: more nightly failures after statics in Class changes In-Reply-To: References: Message-ID: <4D8A2628.1050500@oracle.com> Looks good. igor On 3/23/11 9:39 AM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7030300 > > 7030300: more nightly failures after statics in Class changes > Reviewed-by: > > Yet another place that needs to be updated when writing static field > values and the c1 CodeStubs changes need to be compressed oops aware. > Tested with failing tests from nightly. From tom.rodriguez at oracle.com Wed Mar 23 10:01:06 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 23 Mar 2011 10:01:06 -0700 Subject: segmentation fault in the jvm In-Reply-To: <4D8A2250.4060204@csail.mit.edu> References: <4D8A0D60.5080604@csail.mit.edu> <9F3CDB65-DA02-46D6-9865-76428C0555B7@oracle.com> <4D8A205E.4090106@csail.mit.edu> <4D8A2250.4060204@csail.mit.edu> Message-ID: <8D98AF1C-D99B-44A3-8295-7D926E192A66@oracle.com> I normally run with SEGV ignored and set a breakpoint in our crash reporting path. So something like: handle SIGSEGV noprint nostop pass break VMError::report_and_die The only down side is that you're actually in the signal handler but gdb should be able to get the real register state at the SEGV from the ucontext so you should be able to debug it. I don't know if gdb allows something like this but in dbx you can say this: when sig SEGV { if [ "$loadobj" != "" ]; then stop; fi } which stops on a SEGV that's reported against a library instead of dynamically generated code. tom On Mar 23, 2011, at 9:39 AM, Stefanie Tellex wrote: > To partially answer my own question, what I'm doing now based on Christian's information is pressing "c" in gdb to tell it to ignore the seg fault and keep going. > > Eventually it gets to my seg fault, which has a non-jvm stack trace... > > Stefanie > > On 03/23/2011 12:31 PM, Stefanie Tellex wrote: >> Thanks for your reply. >> >> What is the recommended way to debug "legitimate" seg faults when >> invoking the JVM? >> >> I am creating a JVM using the invocation API, and getting a seg fault, >> probably because of a memory problem in our C code. It says "Command >> terminated by signal 11" when running without gdb, but no stack trace. >> >> After I got that, I ran the program in gdb to try to debug it, and >> eventually isolated the problem to the test case I sent out before. But >> it seems like that's not related to the original problem...? >> >> Thanks, >> >> Stefanie >> >> On 03/23/2011 11:32 AM, Christian Thalinger wrote: >>> [Bcc'ing jdk7-dev.] >>> >>> On Mar 23, 2011, at 4:10 PM, Stefanie Tellex wrote: >>>> Hi, >>>> >>>> Not sure if this is the right place to report this, >>> >>> The right list would be: hotspot-dev at openjdk.java.net >>> >>>> but I have a Java program that reliably seg faults the JVM when run >>>> under GDB. It doesn't seem to happen (quickly) when I run it without >>>> gdb. It also doesn't seem to happen if I turn off the JIT, although >>>> the original seg fault that triggered this (part of a much larger >>>> program) would still happen with the JIT turned off, although it took >>>> longer. >>>> >>>> The program is attached, and the command I am running is this: >>>> >>>> gdb --args $JAVA_HOME/jre/bin/java -classpath . Test >>>> >>>> The java program loops forever. It gets through about 10 iterations >>>> and then seg faults with this backtrace: >>>> >>>> (gdb) bt >>>> #0 0xb4192300 in ?? () >>>> Cannot access memory at address 0x234 >>> >>> What you are seeing is that compiled code uses various signals for >>> different things, like implicit null-pointer checks. It happens when >>> running in GDB because the debugger handles such signals by default. >>> >>> When you run the java command in GDB in compiled mode (-Xcomp) you >>> will see something like: >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> [Switching to Thread 0x1beb70 (LWP 13690)] >>> 0xf4e74fcc in ?? () >>> >>> Ignoring SEGSEGV signals and continuing should run the java command fine: >>> >>> (gdb) handle SIGSEGV noprint >>> Signal Stop Print Pass to program Description >>> SIGSEGV No No Yes Segmentation fault >>> (gdb) c >>> Continuing. >>> Usage: java [-options] class [args...] >>> ... >>> >>> Hope that helps. >>> >>> -- Christian >>> >>>> >>>> >>>> I also wrote a simple JNI program (attached in the tar.gz) that >>>> creates the JVM and calls Test programmatically. When I run it, it >>>> seg faults after about 10 iterations, (sometimes more, sometimes >>>> fewer, every once in a while it will run for quite a long time). >>>> (gdb) bt >>>> #0 0x41171329 in ?? () >>>> #1 0x4107f3bd in ?? () >>>> #2 0x40400dc3 in JavaCalls::call_helper(JavaValue*, methodHandle*, >>>> JavaCallArguments*, Thread*) () >>>> from >>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>> >>>> #3 0x405f2569 in os::os_exception_wrapper(void (*)(JavaValue*, >>>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, >>>> methodHandle*, JavaCallArguments*, Thread*) () from >>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>> >>>> #4 0x403fe907 in JavaCalls::call(JavaValue*, methodHandle, >>>> JavaCallArguments*, Thread*) () >>>> from >>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>> >>>> #5 0x40420a73 in jni_invoke_nonstatic(JNIEnv_*, JavaValue*, >>>> _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) () >>>> from >>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>> >>>> #6 0x4044b2bb in jni_NewObjectV () from >>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>> >>>> #7 0x40471542 in checked_jni_NewObjectV () from >>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>> >>>> #8 0x08048a71 in JNIEnv_::NewObject (this=0x806353c, clazz=0x806475c, >>>> methodID=0x80eb088) >>>> at /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//include/jni.h:872 >>>> #9 0x080488ab in jvm_test () at c/create_jvm.cxx:63 >>>> #10 0x08048a16 in main () at c/create_jvm.cxx:116 >>>> >>>> >>>> I ran the same program in valgrind and I get lots of errors about >>>> call_helper doing invalid writes: >>>> >>>> ==24756== >>>> ==24756== Invalid write of size 4 >>>> ==24756== at 0x5494416: ??? >>>> ==24756== by 0x548C0F6: ??? >>>> ==24756== by 0x548BD04: ??? >>>> ==24756== by 0x548BE29: ??? >>>> ==24756== by 0x54893BC: ??? >>>> ==24756== by 0x440ADC2: JavaCalls::call_helper(JavaValue*, >>>> methodHandle*, JavaCallArguments*, Thread*) (in >>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >>>> >>>> ==24756== by 0x45FC568: os::os_exception_wrapper(void (*)(JavaValue*, >>>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, >>>> methodHandle*, JavaCallArguments*, Thread*) (in >>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >>>> >>>> ==24756== by 0x4408906: JavaCalls::call(JavaValue*, methodHandle, >>>> JavaCallArguments*, Thread*) (in >>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >>>> >>>> ==24756== by 0x44B0A0F: JVM_DoPrivileged (in >>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >>>> >>>> ==24756== by 0x540E07A: >>>> Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedExceptionAction_2 >>>> (AccessController.c:67) >>>> ==24756== by 0x549571A: ??? >>>> ==24756== by 0x548BE29: ??? >>>> ==24756== Address 0xbe951754 is not stack'd, malloc'd or (recently) >>>> free'd >>>> >>>> >>>> I've reproduced this against 1.7 as well as 1.6 and 1.5. >>>> >>>> There are some bugs that seem to refer to this problem, although they >>>> don't seem to be fixed or to have reproduction instructions. >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7016961 >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7016303 >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7017562 >>>> >>>> Any hints would be appreciated. >>>> >>>> Stefanie >>> >>> >> > From stefie10 at csail.mit.edu Wed Mar 23 10:15:07 2011 From: stefie10 at csail.mit.edu (Stefanie Tellex) Date: Wed, 23 Mar 2011 13:15:07 -0400 Subject: segmentation fault in the jvm In-Reply-To: <8D98AF1C-D99B-44A3-8295-7D926E192A66@oracle.com> References: <4D8A0D60.5080604@csail.mit.edu> <9F3CDB65-DA02-46D6-9865-76428C0555B7@oracle.com> <4D8A205E.4090106@csail.mit.edu> <4D8A2250.4060204@csail.mit.edu> <8D98AF1C-D99B-44A3-8295-7D926E192A66@oracle.com> Message-ID: <4D8A2A9B.1080805@csail.mit.edu> Is there a technical reason why the JVM deliberately throws signal 11? It seems like an implicit null pointer check would only actually throw signal 11 if there was a pointer that was really null... and then wouldn't I see a NullPointerException or something? Stefanie On 03/23/2011 01:01 PM, Tom Rodriguez wrote: > I normally run with SEGV ignored and set a breakpoint in our crash reporting path. So something like: > > handle SIGSEGV noprint nostop pass > break VMError::report_and_die > > The only down side is that you're actually in the signal handler but gdb should be able to get the real register state at the SEGV from the ucontext so you should be able to debug it. > > I don't know if gdb allows something like this but in dbx you can say this: > > when sig SEGV { > if [ "$loadobj" != "" ]; then > stop; > fi > } > > which stops on a SEGV that's reported against a library instead of dynamically generated code. > > tom > > On Mar 23, 2011, at 9:39 AM, Stefanie Tellex wrote: > >> To partially answer my own question, what I'm doing now based on Christian's information is pressing "c" in gdb to tell it to ignore the seg fault and keep going. >> >> Eventually it gets to my seg fault, which has a non-jvm stack trace... >> >> Stefanie >> >> On 03/23/2011 12:31 PM, Stefanie Tellex wrote: >>> Thanks for your reply. >>> >>> What is the recommended way to debug "legitimate" seg faults when >>> invoking the JVM? >>> >>> I am creating a JVM using the invocation API, and getting a seg fault, >>> probably because of a memory problem in our C code. It says "Command >>> terminated by signal 11" when running without gdb, but no stack trace. >>> >>> After I got that, I ran the program in gdb to try to debug it, and >>> eventually isolated the problem to the test case I sent out before. But >>> it seems like that's not related to the original problem...? >>> >>> Thanks, >>> >>> Stefanie >>> >>> On 03/23/2011 11:32 AM, Christian Thalinger wrote: >>>> [Bcc'ing jdk7-dev.] >>>> >>>> On Mar 23, 2011, at 4:10 PM, Stefanie Tellex wrote: >>>>> Hi, >>>>> >>>>> Not sure if this is the right place to report this, >>>> >>>> The right list would be: hotspot-dev at openjdk.java.net >>>> >>>>> but I have a Java program that reliably seg faults the JVM when run >>>>> under GDB. It doesn't seem to happen (quickly) when I run it without >>>>> gdb. It also doesn't seem to happen if I turn off the JIT, although >>>>> the original seg fault that triggered this (part of a much larger >>>>> program) would still happen with the JIT turned off, although it took >>>>> longer. >>>>> >>>>> The program is attached, and the command I am running is this: >>>>> >>>>> gdb --args $JAVA_HOME/jre/bin/java -classpath . Test >>>>> >>>>> The java program loops forever. It gets through about 10 iterations >>>>> and then seg faults with this backtrace: >>>>> >>>>> (gdb) bt >>>>> #0 0xb4192300 in ?? () >>>>> Cannot access memory at address 0x234 >>>> >>>> What you are seeing is that compiled code uses various signals for >>>> different things, like implicit null-pointer checks. It happens when >>>> running in GDB because the debugger handles such signals by default. >>>> >>>> When you run the java command in GDB in compiled mode (-Xcomp) you >>>> will see something like: >>>> >>>> Program received signal SIGSEGV, Segmentation fault. >>>> [Switching to Thread 0x1beb70 (LWP 13690)] >>>> 0xf4e74fcc in ?? () >>>> >>>> Ignoring SEGSEGV signals and continuing should run the java command fine: >>>> >>>> (gdb) handle SIGSEGV noprint >>>> Signal Stop Print Pass to program Description >>>> SIGSEGV No No Yes Segmentation fault >>>> (gdb) c >>>> Continuing. >>>> Usage: java [-options] class [args...] >>>> ... >>>> >>>> Hope that helps. >>>> >>>> -- Christian >>>> >>>>> >>>>> >>>>> I also wrote a simple JNI program (attached in the tar.gz) that >>>>> creates the JVM and calls Test programmatically. When I run it, it >>>>> seg faults after about 10 iterations, (sometimes more, sometimes >>>>> fewer, every once in a while it will run for quite a long time). >>>>> (gdb) bt >>>>> #0 0x41171329 in ?? () >>>>> #1 0x4107f3bd in ?? () >>>>> #2 0x40400dc3 in JavaCalls::call_helper(JavaValue*, methodHandle*, >>>>> JavaCallArguments*, Thread*) () >>>>> from >>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>>> >>>>> #3 0x405f2569 in os::os_exception_wrapper(void (*)(JavaValue*, >>>>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, >>>>> methodHandle*, JavaCallArguments*, Thread*) () from >>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>>> >>>>> #4 0x403fe907 in JavaCalls::call(JavaValue*, methodHandle, >>>>> JavaCallArguments*, Thread*) () >>>>> from >>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>>> >>>>> #5 0x40420a73 in jni_invoke_nonstatic(JNIEnv_*, JavaValue*, >>>>> _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) () >>>>> from >>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>>> >>>>> #6 0x4044b2bb in jni_NewObjectV () from >>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>>> >>>>> #7 0x40471542 in checked_jni_NewObjectV () from >>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>>> >>>>> #8 0x08048a71 in JNIEnv_::NewObject (this=0x806353c, clazz=0x806475c, >>>>> methodID=0x80eb088) >>>>> at /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//include/jni.h:872 >>>>> #9 0x080488ab in jvm_test () at c/create_jvm.cxx:63 >>>>> #10 0x08048a16 in main () at c/create_jvm.cxx:116 >>>>> >>>>> >>>>> I ran the same program in valgrind and I get lots of errors about >>>>> call_helper doing invalid writes: >>>>> >>>>> ==24756== >>>>> ==24756== Invalid write of size 4 >>>>> ==24756== at 0x5494416: ??? >>>>> ==24756== by 0x548C0F6: ??? >>>>> ==24756== by 0x548BD04: ??? >>>>> ==24756== by 0x548BE29: ??? >>>>> ==24756== by 0x54893BC: ??? >>>>> ==24756== by 0x440ADC2: JavaCalls::call_helper(JavaValue*, >>>>> methodHandle*, JavaCallArguments*, Thread*) (in >>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >>>>> >>>>> ==24756== by 0x45FC568: os::os_exception_wrapper(void (*)(JavaValue*, >>>>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, >>>>> methodHandle*, JavaCallArguments*, Thread*) (in >>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >>>>> >>>>> ==24756== by 0x4408906: JavaCalls::call(JavaValue*, methodHandle, >>>>> JavaCallArguments*, Thread*) (in >>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >>>>> >>>>> ==24756== by 0x44B0A0F: JVM_DoPrivileged (in >>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >>>>> >>>>> ==24756== by 0x540E07A: >>>>> Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedExceptionAction_2 >>>>> (AccessController.c:67) >>>>> ==24756== by 0x549571A: ??? >>>>> ==24756== by 0x548BE29: ??? >>>>> ==24756== Address 0xbe951754 is not stack'd, malloc'd or (recently) >>>>> free'd >>>>> >>>>> >>>>> I've reproduced this against 1.7 as well as 1.6 and 1.5. >>>>> >>>>> There are some bugs that seem to refer to this problem, although they >>>>> don't seem to be fixed or to have reproduction instructions. >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7016961 >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7016303 >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7017562 >>>>> >>>>> Any hints would be appreciated. >>>>> >>>>> Stefanie >>>> >>>> >>> >> > From tom.rodriguez at oracle.com Wed Mar 23 10:31:11 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 23 Mar 2011 10:31:11 -0700 Subject: segmentation fault in the jvm In-Reply-To: <4D8A2A9B.1080805@csail.mit.edu> References: <4D8A0D60.5080604@csail.mit.edu> <9F3CDB65-DA02-46D6-9865-76428C0555B7@oracle.com> <4D8A205E.4090106@csail.mit.edu> <4D8A2250.4060204@csail.mit.edu> <8D98AF1C-D99B-44A3-8295-7D926E192A66@oracle.com> <4D8A2A9B.1080805@csail.mit.edu> Message-ID: On Mar 23, 2011, at 10:15 AM, Stefanie Tellex wrote: > Is there a technical reason why the JVM deliberately throws signal 11? We don't throw it. Java code is producing an NPE. Using signals for this is more efficient for NPE checking that emitting explicit checks given that NPE is generally infrequent. So it's trading trapping overhead for execution efficiency. Older versions of the server compiler would sometimes convert regular "if (o == null)" checks into trapping instructions but that has been fixed for a while. > > It seems like an implicit null pointer check would only actually throw signal 11 if there was a pointer that was really null... and then wouldn't I see a NullPointerException or something? NPEs are occasionally thrown and swallowed by normal Java programs. tom > > Stefanie > > On 03/23/2011 01:01 PM, Tom Rodriguez wrote: >> I normally run with SEGV ignored and set a breakpoint in our crash reporting path. So something like: >> >> handle SIGSEGV noprint nostop pass >> break VMError::report_and_die >> >> The only down side is that you're actually in the signal handler but gdb should be able to get the real register state at the SEGV from the ucontext so you should be able to debug it. >> >> I don't know if gdb allows something like this but in dbx you can say this: >> >> when sig SEGV { >> if [ "$loadobj" != "" ]; then >> stop; >> fi >> } >> >> which stops on a SEGV that's reported against a library instead of dynamically generated code. >> >> tom >> >> On Mar 23, 2011, at 9:39 AM, Stefanie Tellex wrote: >> >>> To partially answer my own question, what I'm doing now based on Christian's information is pressing "c" in gdb to tell it to ignore the seg fault and keep going. >>> >>> Eventually it gets to my seg fault, which has a non-jvm stack trace... >>> >>> Stefanie >>> >>> On 03/23/2011 12:31 PM, Stefanie Tellex wrote: >>>> Thanks for your reply. >>>> >>>> What is the recommended way to debug "legitimate" seg faults when >>>> invoking the JVM? >>>> >>>> I am creating a JVM using the invocation API, and getting a seg fault, >>>> probably because of a memory problem in our C code. It says "Command >>>> terminated by signal 11" when running without gdb, but no stack trace. >>>> >>>> After I got that, I ran the program in gdb to try to debug it, and >>>> eventually isolated the problem to the test case I sent out before. But >>>> it seems like that's not related to the original problem...? >>>> >>>> Thanks, >>>> >>>> Stefanie >>>> >>>> On 03/23/2011 11:32 AM, Christian Thalinger wrote: >>>>> [Bcc'ing jdk7-dev.] >>>>> >>>>> On Mar 23, 2011, at 4:10 PM, Stefanie Tellex wrote: >>>>>> Hi, >>>>>> >>>>>> Not sure if this is the right place to report this, >>>>> >>>>> The right list would be: hotspot-dev at openjdk.java.net >>>>> >>>>>> but I have a Java program that reliably seg faults the JVM when run >>>>>> under GDB. It doesn't seem to happen (quickly) when I run it without >>>>>> gdb. It also doesn't seem to happen if I turn off the JIT, although >>>>>> the original seg fault that triggered this (part of a much larger >>>>>> program) would still happen with the JIT turned off, although it took >>>>>> longer. >>>>>> >>>>>> The program is attached, and the command I am running is this: >>>>>> >>>>>> gdb --args $JAVA_HOME/jre/bin/java -classpath . Test >>>>>> >>>>>> The java program loops forever. It gets through about 10 iterations >>>>>> and then seg faults with this backtrace: >>>>>> >>>>>> (gdb) bt >>>>>> #0 0xb4192300 in ?? () >>>>>> Cannot access memory at address 0x234 >>>>> >>>>> What you are seeing is that compiled code uses various signals for >>>>> different things, like implicit null-pointer checks. It happens when >>>>> running in GDB because the debugger handles such signals by default. >>>>> >>>>> When you run the java command in GDB in compiled mode (-Xcomp) you >>>>> will see something like: >>>>> >>>>> Program received signal SIGSEGV, Segmentation fault. >>>>> [Switching to Thread 0x1beb70 (LWP 13690)] >>>>> 0xf4e74fcc in ?? () >>>>> >>>>> Ignoring SEGSEGV signals and continuing should run the java command fine: >>>>> >>>>> (gdb) handle SIGSEGV noprint >>>>> Signal Stop Print Pass to program Description >>>>> SIGSEGV No No Yes Segmentation fault >>>>> (gdb) c >>>>> Continuing. >>>>> Usage: java [-options] class [args...] >>>>> ... >>>>> >>>>> Hope that helps. >>>>> >>>>> -- Christian >>>>> >>>>>> >>>>>> >>>>>> I also wrote a simple JNI program (attached in the tar.gz) that >>>>>> creates the JVM and calls Test programmatically. When I run it, it >>>>>> seg faults after about 10 iterations, (sometimes more, sometimes >>>>>> fewer, every once in a while it will run for quite a long time). >>>>>> (gdb) bt >>>>>> #0 0x41171329 in ?? () >>>>>> #1 0x4107f3bd in ?? () >>>>>> #2 0x40400dc3 in JavaCalls::call_helper(JavaValue*, methodHandle*, >>>>>> JavaCallArguments*, Thread*) () >>>>>> from >>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>>>> >>>>>> #3 0x405f2569 in os::os_exception_wrapper(void (*)(JavaValue*, >>>>>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, >>>>>> methodHandle*, JavaCallArguments*, Thread*) () from >>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>>>> >>>>>> #4 0x403fe907 in JavaCalls::call(JavaValue*, methodHandle, >>>>>> JavaCallArguments*, Thread*) () >>>>>> from >>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>>>> >>>>>> #5 0x40420a73 in jni_invoke_nonstatic(JNIEnv_*, JavaValue*, >>>>>> _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) () >>>>>> from >>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>>>> >>>>>> #6 0x4044b2bb in jni_NewObjectV () from >>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>>>> >>>>>> #7 0x40471542 in checked_jni_NewObjectV () from >>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>>>> >>>>>> #8 0x08048a71 in JNIEnv_::NewObject (this=0x806353c, clazz=0x806475c, >>>>>> methodID=0x80eb088) >>>>>> at /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//include/jni.h:872 >>>>>> #9 0x080488ab in jvm_test () at c/create_jvm.cxx:63 >>>>>> #10 0x08048a16 in main () at c/create_jvm.cxx:116 >>>>>> >>>>>> >>>>>> I ran the same program in valgrind and I get lots of errors about >>>>>> call_helper doing invalid writes: >>>>>> >>>>>> ==24756== >>>>>> ==24756== Invalid write of size 4 >>>>>> ==24756== at 0x5494416: ??? >>>>>> ==24756== by 0x548C0F6: ??? >>>>>> ==24756== by 0x548BD04: ??? >>>>>> ==24756== by 0x548BE29: ??? >>>>>> ==24756== by 0x54893BC: ??? >>>>>> ==24756== by 0x440ADC2: JavaCalls::call_helper(JavaValue*, >>>>>> methodHandle*, JavaCallArguments*, Thread*) (in >>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >>>>>> >>>>>> ==24756== by 0x45FC568: os::os_exception_wrapper(void (*)(JavaValue*, >>>>>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, >>>>>> methodHandle*, JavaCallArguments*, Thread*) (in >>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >>>>>> >>>>>> ==24756== by 0x4408906: JavaCalls::call(JavaValue*, methodHandle, >>>>>> JavaCallArguments*, Thread*) (in >>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >>>>>> >>>>>> ==24756== by 0x44B0A0F: JVM_DoPrivileged (in >>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >>>>>> >>>>>> ==24756== by 0x540E07A: >>>>>> Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedExceptionAction_2 >>>>>> (AccessController.c:67) >>>>>> ==24756== by 0x549571A: ??? >>>>>> ==24756== by 0x548BE29: ??? >>>>>> ==24756== Address 0xbe951754 is not stack'd, malloc'd or (recently) >>>>>> free'd >>>>>> >>>>>> >>>>>> I've reproduced this against 1.7 as well as 1.6 and 1.5. >>>>>> >>>>>> There are some bugs that seem to refer to this problem, although they >>>>>> don't seem to be fixed or to have reproduction instructions. >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7016961 >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7016303 >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7017562 >>>>>> >>>>>> Any hints would be appreciated. >>>>>> >>>>>> Stefanie >>>>> >>>>> >>>> >>> >> > From John.Coomes at oracle.com Wed Mar 23 10:39:21 2011 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 23 Mar 2011 10:39:21 -0700 Subject: review (XS) for 7030300: more nightly failures after statics in Class changes In-Reply-To: References: Message-ID: <19850.12361.912666.239964@oracle.com> Tom Rodriguez (tom.rodriguez at oracle.com) wrote: > http://cr.openjdk.java.net/~never/7030300 > > 7030300: more nightly failures after statics in Class changes > Reviewed-by: > > Yet another place that needs to be updated when writing static field > values and the c1 CodeStubs changes need to be compressed oops aware. > Tested with failing tests from nightly. Looks good to me. -John From stefie10 at csail.mit.edu Wed Mar 23 10:40:40 2011 From: stefie10 at csail.mit.edu (Stefanie Tellex) Date: Wed, 23 Mar 2011 13:40:40 -0400 Subject: segmentation fault in the jvm In-Reply-To: References: <4D8A0D60.5080604@csail.mit.edu> <9F3CDB65-DA02-46D6-9865-76428C0555B7@oracle.com> <4D8A205E.4090106@csail.mit.edu> <4D8A2250.4060204@csail.mit.edu> <8D98AF1C-D99B-44A3-8295-7D926E192A66@oracle.com> <4D8A2A9B.1080805@csail.mit.edu> Message-ID: <4D8A3098.9070608@csail.mit.edu> Is this documented anywhere? I looked around quite a while while debugging this problem and couldn't find anything. Things like the "-Xrs" jvm option are making more sense now, but it would be nice if there was a FAQ about running gdb and the jvm, or debugging seg faults in general with the jvm. Stefanie On 03/23/2011 01:31 PM, Tom Rodriguez wrote: > > On Mar 23, 2011, at 10:15 AM, Stefanie Tellex wrote: > >> Is there a technical reason why the JVM deliberately throws signal 11? > > We don't throw it. Java code is producing an NPE. Using signals for this is more efficient for NPE checking that emitting explicit checks given that NPE is generally infrequent. So it's trading trapping overhead for execution efficiency. Older versions of the server compiler would sometimes convert regular "if (o == null)" checks into trapping instructions but that has been fixed for a while. > >> >> It seems like an implicit null pointer check would only actually throw signal 11 if there was a pointer that was really null... and then wouldn't I see a NullPointerException or something? > > NPEs are occasionally thrown and swallowed by normal Java programs. > > tom > >> >> Stefanie >> >> On 03/23/2011 01:01 PM, Tom Rodriguez wrote: >>> I normally run with SEGV ignored and set a breakpoint in our crash reporting path. So something like: >>> >>> handle SIGSEGV noprint nostop pass >>> break VMError::report_and_die >>> >>> The only down side is that you're actually in the signal handler but gdb should be able to get the real register state at the SEGV from the ucontext so you should be able to debug it. >>> >>> I don't know if gdb allows something like this but in dbx you can say this: >>> >>> when sig SEGV { >>> if [ "$loadobj" != "" ]; then >>> stop; >>> fi >>> } >>> >>> which stops on a SEGV that's reported against a library instead of dynamically generated code. >>> >>> tom >>> >>> On Mar 23, 2011, at 9:39 AM, Stefanie Tellex wrote: >>> >>>> To partially answer my own question, what I'm doing now based on Christian's information is pressing "c" in gdb to tell it to ignore the seg fault and keep going. >>>> >>>> Eventually it gets to my seg fault, which has a non-jvm stack trace... >>>> >>>> Stefanie >>>> >>>> On 03/23/2011 12:31 PM, Stefanie Tellex wrote: >>>>> Thanks for your reply. >>>>> >>>>> What is the recommended way to debug "legitimate" seg faults when >>>>> invoking the JVM? >>>>> >>>>> I am creating a JVM using the invocation API, and getting a seg fault, >>>>> probably because of a memory problem in our C code. It says "Command >>>>> terminated by signal 11" when running without gdb, but no stack trace. >>>>> >>>>> After I got that, I ran the program in gdb to try to debug it, and >>>>> eventually isolated the problem to the test case I sent out before. But >>>>> it seems like that's not related to the original problem...? >>>>> >>>>> Thanks, >>>>> >>>>> Stefanie >>>>> >>>>> On 03/23/2011 11:32 AM, Christian Thalinger wrote: >>>>>> [Bcc'ing jdk7-dev.] >>>>>> >>>>>> On Mar 23, 2011, at 4:10 PM, Stefanie Tellex wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Not sure if this is the right place to report this, >>>>>> >>>>>> The right list would be: hotspot-dev at openjdk.java.net >>>>>> >>>>>>> but I have a Java program that reliably seg faults the JVM when run >>>>>>> under GDB. It doesn't seem to happen (quickly) when I run it without >>>>>>> gdb. It also doesn't seem to happen if I turn off the JIT, although >>>>>>> the original seg fault that triggered this (part of a much larger >>>>>>> program) would still happen with the JIT turned off, although it took >>>>>>> longer. >>>>>>> >>>>>>> The program is attached, and the command I am running is this: >>>>>>> >>>>>>> gdb --args $JAVA_HOME/jre/bin/java -classpath . Test >>>>>>> >>>>>>> The java program loops forever. It gets through about 10 iterations >>>>>>> and then seg faults with this backtrace: >>>>>>> >>>>>>> (gdb) bt >>>>>>> #0 0xb4192300 in ?? () >>>>>>> Cannot access memory at address 0x234 >>>>>> >>>>>> What you are seeing is that compiled code uses various signals for >>>>>> different things, like implicit null-pointer checks. It happens when >>>>>> running in GDB because the debugger handles such signals by default. >>>>>> >>>>>> When you run the java command in GDB in compiled mode (-Xcomp) you >>>>>> will see something like: >>>>>> >>>>>> Program received signal SIGSEGV, Segmentation fault. >>>>>> [Switching to Thread 0x1beb70 (LWP 13690)] >>>>>> 0xf4e74fcc in ?? () >>>>>> >>>>>> Ignoring SEGSEGV signals and continuing should run the java command fine: >>>>>> >>>>>> (gdb) handle SIGSEGV noprint >>>>>> Signal Stop Print Pass to program Description >>>>>> SIGSEGV No No Yes Segmentation fault >>>>>> (gdb) c >>>>>> Continuing. >>>>>> Usage: java [-options] class [args...] >>>>>> ... >>>>>> >>>>>> Hope that helps. >>>>>> >>>>>> -- Christian >>>>>> >>>>>>> >>>>>>> >>>>>>> I also wrote a simple JNI program (attached in the tar.gz) that >>>>>>> creates the JVM and calls Test programmatically. When I run it, it >>>>>>> seg faults after about 10 iterations, (sometimes more, sometimes >>>>>>> fewer, every once in a while it will run for quite a long time). >>>>>>> (gdb) bt >>>>>>> #0 0x41171329 in ?? () >>>>>>> #1 0x4107f3bd in ?? () >>>>>>> #2 0x40400dc3 in JavaCalls::call_helper(JavaValue*, methodHandle*, >>>>>>> JavaCallArguments*, Thread*) () >>>>>>> from >>>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>>>>> >>>>>>> #3 0x405f2569 in os::os_exception_wrapper(void (*)(JavaValue*, >>>>>>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, >>>>>>> methodHandle*, JavaCallArguments*, Thread*) () from >>>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>>>>> >>>>>>> #4 0x403fe907 in JavaCalls::call(JavaValue*, methodHandle, >>>>>>> JavaCallArguments*, Thread*) () >>>>>>> from >>>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>>>>> >>>>>>> #5 0x40420a73 in jni_invoke_nonstatic(JNIEnv_*, JavaValue*, >>>>>>> _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) () >>>>>>> from >>>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>>>>> >>>>>>> #6 0x4044b2bb in jni_NewObjectV () from >>>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>>>>> >>>>>>> #7 0x40471542 in checked_jni_NewObjectV () from >>>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>>>>> >>>>>>> #8 0x08048a71 in JNIEnv_::NewObject (this=0x806353c, clazz=0x806475c, >>>>>>> methodID=0x80eb088) >>>>>>> at /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//include/jni.h:872 >>>>>>> #9 0x080488ab in jvm_test () at c/create_jvm.cxx:63 >>>>>>> #10 0x08048a16 in main () at c/create_jvm.cxx:116 >>>>>>> >>>>>>> >>>>>>> I ran the same program in valgrind and I get lots of errors about >>>>>>> call_helper doing invalid writes: >>>>>>> >>>>>>> ==24756== >>>>>>> ==24756== Invalid write of size 4 >>>>>>> ==24756== at 0x5494416: ??? >>>>>>> ==24756== by 0x548C0F6: ??? >>>>>>> ==24756== by 0x548BD04: ??? >>>>>>> ==24756== by 0x548BE29: ??? >>>>>>> ==24756== by 0x54893BC: ??? >>>>>>> ==24756== by 0x440ADC2: JavaCalls::call_helper(JavaValue*, >>>>>>> methodHandle*, JavaCallArguments*, Thread*) (in >>>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >>>>>>> >>>>>>> ==24756== by 0x45FC568: os::os_exception_wrapper(void (*)(JavaValue*, >>>>>>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, >>>>>>> methodHandle*, JavaCallArguments*, Thread*) (in >>>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >>>>>>> >>>>>>> ==24756== by 0x4408906: JavaCalls::call(JavaValue*, methodHandle, >>>>>>> JavaCallArguments*, Thread*) (in >>>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >>>>>>> >>>>>>> ==24756== by 0x44B0A0F: JVM_DoPrivileged (in >>>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >>>>>>> >>>>>>> ==24756== by 0x540E07A: >>>>>>> Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedExceptionAction_2 >>>>>>> (AccessController.c:67) >>>>>>> ==24756== by 0x549571A: ??? >>>>>>> ==24756== by 0x548BE29: ??? >>>>>>> ==24756== Address 0xbe951754 is not stack'd, malloc'd or (recently) >>>>>>> free'd >>>>>>> >>>>>>> >>>>>>> I've reproduced this against 1.7 as well as 1.6 and 1.5. >>>>>>> >>>>>>> There are some bugs that seem to refer to this problem, although they >>>>>>> don't seem to be fixed or to have reproduction instructions. >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7016961 >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7016303 >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7017562 >>>>>>> >>>>>>> Any hints would be appreciated. >>>>>>> >>>>>>> Stefanie >>>>>> >>>>>> >>>>> >>>> >>> >> > From daniel.daugherty at oracle.com Wed Mar 23 10:50:45 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 23 Mar 2011 11:50:45 -0600 Subject: review (XS) for 7030300: more nightly failures after statics in Class changes In-Reply-To: References: Message-ID: <4D8A32F5.9090400@oracle.com> On 3/23/2011 10:39 AM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7030300 > Thumbs up! Are these changes applicable in a pre-static fields move world? Dan agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java No comments. src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp No comments. src/cpu/x86/vm/c1_CodeStubs_x86.cpp No comments. > 7030300: more nightly failures after statics in Class changes > Reviewed-by: > > Yet another place that needs to be updated when writing static field > values and the c1 CodeStubs changes need to be compressed oops aware. > Tested with failing tests from nightly. > From tom.rodriguez at oracle.com Wed Mar 23 10:52:10 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 23 Mar 2011 10:52:10 -0700 Subject: segmentation fault in the jvm In-Reply-To: <4D8A3098.9070608@csail.mit.edu> References: <4D8A0D60.5080604@csail.mit.edu> <9F3CDB65-DA02-46D6-9865-76428C0555B7@oracle.com> <4D8A205E.4090106@csail.mit.edu> <4D8A2250.4060204@csail.mit.edu> <8D98AF1C-D99B-44A3-8295-7D926E192A66@oracle.com> <4D8A2A9B.1080805@csail.mit.edu> <4D8A3098.9070608@csail.mit.edu> Message-ID: <4302B992-7700-42A4-BBB0-D98F3151B4FE@oracle.com> Note in these explicit terms but the troubleshooting guide does say this: http://www.oracle.com/technetwork/java/javase/bugreports-140511.html#gbkzk Java specific: If the process received SIGSEGV or SIGILL but no core dump, it is possible that the process handled it. For example, HotSpot VM uses the SIGSEGV signal for legitimate purposes, such as throwing NullPointerException, deoptimization, and so forth. The signal is unhandled by the Java VM only if the current instruction (PC) falls outside Java VM generated code. These are the only cases in which HotSpot dumps core. http://www.oracle.com/technetwork/java/javase/bugreports-140511.html#gbkzk There was also this thread on hotspot-dev. http://mail.openjdk.java.net/pipermail/hotspot-dev/2007-October/000174.html tom On Mar 23, 2011, at 10:40 AM, Stefanie Tellex wrote: > Is this documented anywhere? > > I looked around quite a while while debugging this problem and couldn't find anything. > > Things like the "-Xrs" jvm option are making more sense now, but it would be nice if there was a FAQ about running gdb and the jvm, or debugging seg faults in general with the jvm. > > Stefanie > > On 03/23/2011 01:31 PM, Tom Rodriguez wrote: >> >> On Mar 23, 2011, at 10:15 AM, Stefanie Tellex wrote: >> >>> Is there a technical reason why the JVM deliberately throws signal 11? >> >> We don't throw it. Java code is producing an NPE. Using signals for this is more efficient for NPE checking that emitting explicit checks given that NPE is generally infrequent. So it's trading trapping overhead for execution efficiency. Older versions of the server compiler would sometimes convert regular "if (o == null)" checks into trapping instructions but that has been fixed for a while. >> >>> >>> It seems like an implicit null pointer check would only actually throw signal 11 if there was a pointer that was really null... and then wouldn't I see a NullPointerException or something? >> >> NPEs are occasionally thrown and swallowed by normal Java programs. >> >> tom >> >>> >>> Stefanie >>> >>> On 03/23/2011 01:01 PM, Tom Rodriguez wrote: >>>> I normally run with SEGV ignored and set a breakpoint in our crash reporting path. So something like: >>>> >>>> handle SIGSEGV noprint nostop pass >>>> break VMError::report_and_die >>>> >>>> The only down side is that you're actually in the signal handler but gdb should be able to get the real register state at the SEGV from the ucontext so you should be able to debug it. >>>> >>>> I don't know if gdb allows something like this but in dbx you can say this: >>>> >>>> when sig SEGV { >>>> if [ "$loadobj" != "" ]; then >>>> stop; >>>> fi >>>> } >>>> >>>> which stops on a SEGV that's reported against a library instead of dynamically generated code. >>>> >>>> tom >>>> >>>> On Mar 23, 2011, at 9:39 AM, Stefanie Tellex wrote: >>>> >>>>> To partially answer my own question, what I'm doing now based on Christian's information is pressing "c" in gdb to tell it to ignore the seg fault and keep going. >>>>> >>>>> Eventually it gets to my seg fault, which has a non-jvm stack trace... >>>>> >>>>> Stefanie >>>>> >>>>> On 03/23/2011 12:31 PM, Stefanie Tellex wrote: >>>>>> Thanks for your reply. >>>>>> >>>>>> What is the recommended way to debug "legitimate" seg faults when >>>>>> invoking the JVM? >>>>>> >>>>>> I am creating a JVM using the invocation API, and getting a seg fault, >>>>>> probably because of a memory problem in our C code. It says "Command >>>>>> terminated by signal 11" when running without gdb, but no stack trace. >>>>>> >>>>>> After I got that, I ran the program in gdb to try to debug it, and >>>>>> eventually isolated the problem to the test case I sent out before. But >>>>>> it seems like that's not related to the original problem...? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Stefanie >>>>>> >>>>>> On 03/23/2011 11:32 AM, Christian Thalinger wrote: >>>>>>> [Bcc'ing jdk7-dev.] >>>>>>> >>>>>>> On Mar 23, 2011, at 4:10 PM, Stefanie Tellex wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Not sure if this is the right place to report this, >>>>>>> >>>>>>> The right list would be: hotspot-dev at openjdk.java.net >>>>>>> >>>>>>>> but I have a Java program that reliably seg faults the JVM when run >>>>>>>> under GDB. It doesn't seem to happen (quickly) when I run it without >>>>>>>> gdb. It also doesn't seem to happen if I turn off the JIT, although >>>>>>>> the original seg fault that triggered this (part of a much larger >>>>>>>> program) would still happen with the JIT turned off, although it took >>>>>>>> longer. >>>>>>>> >>>>>>>> The program is attached, and the command I am running is this: >>>>>>>> >>>>>>>> gdb --args $JAVA_HOME/jre/bin/java -classpath . Test >>>>>>>> >>>>>>>> The java program loops forever. It gets through about 10 iterations >>>>>>>> and then seg faults with this backtrace: >>>>>>>> >>>>>>>> (gdb) bt >>>>>>>> #0 0xb4192300 in ?? () >>>>>>>> Cannot access memory at address 0x234 >>>>>>> >>>>>>> What you are seeing is that compiled code uses various signals for >>>>>>> different things, like implicit null-pointer checks. It happens when >>>>>>> running in GDB because the debugger handles such signals by default. >>>>>>> >>>>>>> When you run the java command in GDB in compiled mode (-Xcomp) you >>>>>>> will see something like: >>>>>>> >>>>>>> Program received signal SIGSEGV, Segmentation fault. >>>>>>> [Switching to Thread 0x1beb70 (LWP 13690)] >>>>>>> 0xf4e74fcc in ?? () >>>>>>> >>>>>>> Ignoring SEGSEGV signals and continuing should run the java command fine: >>>>>>> >>>>>>> (gdb) handle SIGSEGV noprint >>>>>>> Signal Stop Print Pass to program Description >>>>>>> SIGSEGV No No Yes Segmentation fault >>>>>>> (gdb) c >>>>>>> Continuing. >>>>>>> Usage: java [-options] class [args...] >>>>>>> ... >>>>>>> >>>>>>> Hope that helps. >>>>>>> >>>>>>> -- Christian >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I also wrote a simple JNI program (attached in the tar.gz) that >>>>>>>> creates the JVM and calls Test programmatically. When I run it, it >>>>>>>> seg faults after about 10 iterations, (sometimes more, sometimes >>>>>>>> fewer, every once in a while it will run for quite a long time). >>>>>>>> (gdb) bt >>>>>>>> #0 0x41171329 in ?? () >>>>>>>> #1 0x4107f3bd in ?? () >>>>>>>> #2 0x40400dc3 in JavaCalls::call_helper(JavaValue*, methodHandle*, >>>>>>>> JavaCallArguments*, Thread*) () >>>>>>>> from >>>>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>>>>>> >>>>>>>> #3 0x405f2569 in os::os_exception_wrapper(void (*)(JavaValue*, >>>>>>>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, >>>>>>>> methodHandle*, JavaCallArguments*, Thread*) () from >>>>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>>>>>> >>>>>>>> #4 0x403fe907 in JavaCalls::call(JavaValue*, methodHandle, >>>>>>>> JavaCallArguments*, Thread*) () >>>>>>>> from >>>>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>>>>>> >>>>>>>> #5 0x40420a73 in jni_invoke_nonstatic(JNIEnv_*, JavaValue*, >>>>>>>> _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) () >>>>>>>> from >>>>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>>>>>> >>>>>>>> #6 0x4044b2bb in jni_NewObjectV () from >>>>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>>>>>> >>>>>>>> #7 0x40471542 in checked_jni_NewObjectV () from >>>>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//jre/lib/i386/client/libjvm.so >>>>>>>> >>>>>>>> #8 0x08048a71 in JNIEnv_::NewObject (this=0x806353c, clazz=0x806475c, >>>>>>>> methodID=0x80eb088) >>>>>>>> at /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug//include/jni.h:872 >>>>>>>> #9 0x080488ab in jvm_test () at c/create_jvm.cxx:63 >>>>>>>> #10 0x08048a16 in main () at c/create_jvm.cxx:116 >>>>>>>> >>>>>>>> >>>>>>>> I ran the same program in valgrind and I get lots of errors about >>>>>>>> call_helper doing invalid writes: >>>>>>>> >>>>>>>> ==24756== >>>>>>>> ==24756== Invalid write of size 4 >>>>>>>> ==24756== at 0x5494416: ??? >>>>>>>> ==24756== by 0x548C0F6: ??? >>>>>>>> ==24756== by 0x548BD04: ??? >>>>>>>> ==24756== by 0x548BE29: ??? >>>>>>>> ==24756== by 0x54893BC: ??? >>>>>>>> ==24756== by 0x440ADC2: JavaCalls::call_helper(JavaValue*, >>>>>>>> methodHandle*, JavaCallArguments*, Thread*) (in >>>>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >>>>>>>> >>>>>>>> ==24756== by 0x45FC568: os::os_exception_wrapper(void (*)(JavaValue*, >>>>>>>> methodHandle*, JavaCallArguments*, Thread*), JavaValue*, >>>>>>>> methodHandle*, JavaCallArguments*, Thread*) (in >>>>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >>>>>>>> >>>>>>>> ==24756== by 0x4408906: JavaCalls::call(JavaValue*, methodHandle, >>>>>>>> JavaCallArguments*, Thread*) (in >>>>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >>>>>>>> >>>>>>>> ==24756== by 0x44B0A0F: JVM_DoPrivileged (in >>>>>>>> /home/stefie10/Downloads/jdk7/jdk1.7.0/fastdebug/jre/lib/i386/client/libjvm.so) >>>>>>>> >>>>>>>> ==24756== by 0x540E07A: >>>>>>>> Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedExceptionAction_2 >>>>>>>> (AccessController.c:67) >>>>>>>> ==24756== by 0x549571A: ??? >>>>>>>> ==24756== by 0x548BE29: ??? >>>>>>>> ==24756== Address 0xbe951754 is not stack'd, malloc'd or (recently) >>>>>>>> free'd >>>>>>>> >>>>>>>> >>>>>>>> I've reproduced this against 1.7 as well as 1.6 and 1.5. >>>>>>>> >>>>>>>> There are some bugs that seem to refer to this problem, although they >>>>>>>> don't seem to be fixed or to have reproduction instructions. >>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7016961 >>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7016303 >>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7017562 >>>>>>>> >>>>>>>> Any hints would be appreciated. >>>>>>>> >>>>>>>> Stefanie >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From tom.rodriguez at oracle.com Wed Mar 23 10:53:19 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 23 Mar 2011 10:53:19 -0700 Subject: review (XS) for 7030300: more nightly failures after statics in Class changes In-Reply-To: <4D8A32F5.9090400@oracle.com> References: <4D8A32F5.9090400@oracle.com> Message-ID: <95F6E7D5-7E9C-405D-BEF1-DCAFBB238DB2@oracle.com> On Mar 23, 2011, at 10:50 AM, Daniel D. Daugherty wrote: > On 3/23/2011 10:39 AM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7030300 >> > > Thumbs up! > > Are these changes applicable in a pre-static fields move world? No. The CodeStubs changes didn't look like that previously and the hprof bin writer changes are because of the statics changes. Thanks! tom > > Dan > > > agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java > No comments. > > src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp > No comments. > > src/cpu/x86/vm/c1_CodeStubs_x86.cpp > No comments. > > >> 7030300: more nightly failures after statics in Class changes >> Reviewed-by: >> >> Yet another place that needs to be updated when writing static field >> values and the c1 CodeStubs changes need to be compressed oops aware. >> Tested with failing tests from nightly. >> From tom.rodriguez at oracle.com Wed Mar 23 10:53:49 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 23 Mar 2011 10:53:49 -0700 Subject: review (XS) for 7030300: more nightly failures after statics in Class changes In-Reply-To: <19850.12361.912666.239964@oracle.com> References: <19850.12361.912666.239964@oracle.com> Message-ID: Thanks John and Igor! tom On Mar 23, 2011, at 10:39 AM, John Coomes wrote: > Tom Rodriguez (tom.rodriguez at oracle.com) wrote: >> http://cr.openjdk.java.net/~never/7030300 >> >> 7030300: more nightly failures after statics in Class changes >> Reviewed-by: >> >> Yet another place that needs to be updated when writing static field >> values and the c1 CodeStubs changes need to be compressed oops aware. >> Tested with failing tests from nightly. > > Looks good to me. > > -John > From john.r.rose at oracle.com Thu Mar 24 13:48:36 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 24 Mar 2011 20:48:36 +0000 Subject: hg: jdk7/hotspot/jdk: 16 new changesets Message-ID: <20110324205142.8E3454743E@hg.openjdk.java.net> Changeset: 1c7cac250f71 Author: asaha Date: 2011-03-21 21:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1c7cac250f71 7029704: JFB: Refix JFB Custom Revision Version Build/Makefile changes Reviewed-by: mr, ohair ! make/common/Defs.gmk ! make/common/Release.gmk Changeset: e390396bc938 Author: katakai Date: 2011-02-26 03:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e390396bc938 6998391: Serbian (Latin) locale support Reviewed-by: naoto ! make/java/text/base/FILES_java.gmk ! make/java/util/FILES_properties.gmk ! src/share/classes/java/text/SimpleDateFormat.java + src/share/classes/sun/text/resources/CollationData_sr_Latn.java + src/share/classes/sun/text/resources/FormatData_sr_Latn.java + src/share/classes/sun/text/resources/FormatData_sr_Latn_BA.java + src/share/classes/sun/text/resources/FormatData_sr_Latn_ME.java + src/share/classes/sun/text/resources/FormatData_sr_Latn_RS.java + src/share/classes/sun/util/resources/CalendarData_sr_Latn_BA.properties + src/share/classes/sun/util/resources/CalendarData_sr_Latn_ME.properties + src/share/classes/sun/util/resources/CalendarData_sr_Latn_RS.properties + src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_BA.properties + src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_ME.properties + src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_RS.properties ! src/share/classes/sun/util/resources/LocaleData.java + src/share/classes/sun/util/resources/LocaleNames_sr_Latn.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 0fc1f64bbd73 Author: mfang Date: 2011-03-04 14:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0fc1f64bbd73 Merge - src/share/classes/java/dyn/NoAccessException.java - src/share/classes/java/dyn/Switcher.java - test/java/lang/Thread/StopBeforeStart.java Changeset: a574a067d85a Author: mfang Date: 2011-03-05 14:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a574a067d85a 7016542: NLS: obsolete resources in MsgAppletViewer.java should be removed Reviewed-by: igor ! src/share/classes/sun/applet/resources/MsgAppletViewer.java Changeset: c3c9fda4591e Author: mfang Date: 2011-03-07 12:08 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c3c9fda4591e 7025267: NLS: t13y fix for 7021689 [ja] Notepad demo throws NPE Reviewed-by: ogino ! src/share/demo/jfc/Notepad/resources/Notepad.properties ! src/share/demo/jfc/Notepad/resources/Notepad_ja.properties ! src/share/demo/jfc/Notepad/resources/Notepad_zh_CN.properties Changeset: 9e4d258ac919 Author: mfang Date: 2011-03-07 12:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9e4d258ac919 7021693: [ja, zh_CN] jconsole throws exception and fail to start in ja and zh_CN locales Reviewed-by: ogino ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java Changeset: abe08bf657e3 Author: mfang Date: 2011-03-07 12:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/abe08bf657e3 7025303: NLS: t13y fix for 7021691 Most log level words are not translated in java logging Reviewed-by: yhuang ! src/share/classes/sun/util/logging/resources/logging.properties Changeset: 21737a3e16fb Author: mfang Date: 2011-03-09 14:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/21737a3e16fb Merge Changeset: 5ed7b3d84957 Author: yhuang Date: 2011-03-11 05:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5ed7b3d84957 7019267: Currency Display Names are not localized into pt_BR. Reviewed-by: naoto ! make/java/util/FILES_properties.gmk + src/share/classes/sun/util/resources/CurrencyNames_pt.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: e64ef0cd99ad Author: yhuang Date: 2011-03-11 05:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e64ef0cd99ad Merge Changeset: af4793ab50fb Author: mfang Date: 2011-03-19 19:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/af4793ab50fb Merge - make/common/Modules.gmk - make/java/nio/mxbean/Makefile - make/modules/Makefile - make/modules/bootmodule.roots - make/modules/jdk7.depconfig - make/modules/modules.config - make/modules/modules.group - make/modules/optional.depconfig - make/modules/tools/Makefile - make/modules/tools/build.xml - make/modules/tools/nbproject/project.properties - make/modules/tools/nbproject/project.xml - make/modules/tools/src/com/sun/classanalyzer/AnnotatedDependency.java - make/modules/tools/src/com/sun/classanalyzer/AnnotationParser.java - make/modules/tools/src/com/sun/classanalyzer/BootAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/CheckDeps.java - make/modules/tools/src/com/sun/classanalyzer/ClassAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ClassFileParser.java - make/modules/tools/src/com/sun/classanalyzer/ClassPath.java - make/modules/tools/src/com/sun/classanalyzer/CodeAttributeParser.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolParser.java - make/modules/tools/src/com/sun/classanalyzer/DependencyConfig.java - make/modules/tools/src/com/sun/classanalyzer/Klass.java - make/modules/tools/src/com/sun/classanalyzer/Module.java - make/modules/tools/src/com/sun/classanalyzer/ModuleConfig.java - make/modules/tools/src/com/sun/classanalyzer/ResolutionInfo.java - make/modules/tools/src/com/sun/classanalyzer/ResourceFile.java - make/modules/tools/src/com/sun/classanalyzer/ShowDeps.java - src/share/classes/sun/misc/BootClassLoaderHook.java - src/share/classes/sun/misc/JavaSecurityCodeSignerAccess.java - test/sun/misc/BootClassLoaderHook/TestHook.java Changeset: 258072f4db19 Author: yhuang Date: 2011-03-20 23:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/258072f4db19 7020960: CurrencyNames_sr_RS.properties is missing. Reviewed-by: naoto ! make/java/util/FILES_properties.gmk + src/share/classes/sun/util/resources/CurrencyNames_sr_RS.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: f9d15fd48919 Author: mfang Date: 2011-03-21 11:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f9d15fd48919 Merge Changeset: d8ced728159f Author: mfang Date: 2011-03-22 12:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d8ced728159f Merge Changeset: 9c1e4e0ab69f Author: jrose Date: 2011-03-23 23:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9c1e4e0ab69f 7012648: move JSR 292 to package java.lang.invoke and adjust names Summary: package and class renaming only; delete unused methods and classes; add @since tags; no code changes Reviewed-by: twisti ! make/common/Release.gmk ! make/docs/CORE_PKGS.gmk ! make/java/Makefile - make/java/dyn/Makefile + make/java/invoke/Makefile - src/share/classes/java/dyn/ConstantCallSite.java - src/share/classes/java/dyn/InvokeDynamicBootstrapError.java - src/share/classes/java/dyn/Linkage.java - src/share/classes/java/dyn/SwitchPoint.java - src/share/classes/java/dyn/package-info.java + src/share/classes/java/lang/BootstrapMethodError.java ! src/share/classes/java/lang/ClassValue.java < src/share/classes/java/dyn/ClassValue.java ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java < src/share/classes/java/dyn/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/BoundMethodHandle.java < src/share/classes/java/dyn/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java < src/share/classes/java/dyn/CallSite.java + src/share/classes/java/lang/invoke/ConstantCallSite.java ! src/share/classes/java/lang/invoke/DirectMethodHandle.java < src/share/classes/java/dyn/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/FilterGeneric.java < src/share/classes/java/dyn/FilterGeneric.java ! src/share/classes/java/lang/invoke/FilterOneArgument.java < src/share/classes/java/dyn/FilterOneArgument.java ! src/share/classes/java/lang/invoke/FromGeneric.java < src/share/classes/java/dyn/FromGeneric.java ! src/share/classes/java/lang/invoke/InvokeDynamic.java < src/share/classes/java/dyn/InvokeDynamic.java ! src/share/classes/java/lang/invoke/InvokeGeneric.java < src/share/classes/java/dyn/InvokeGeneric.java ! src/share/classes/java/lang/invoke/Invokers.java < src/share/classes/java/dyn/Invokers.java ! src/share/classes/java/lang/invoke/MemberName.java < src/share/classes/java/dyn/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java < src/share/classes/java/dyn/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java < src/share/classes/java/dyn/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java < src/share/classes/java/dyn/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java < src/share/classes/java/dyn/MethodHandleStatics.java ! src/share/classes/java/lang/invoke/MethodHandles.java < src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java < src/share/classes/java/dyn/MethodType.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java < src/share/classes/java/dyn/MethodTypeForm.java ! src/share/classes/java/lang/invoke/MutableCallSite.java < src/share/classes/java/dyn/MutableCallSite.java ! src/share/classes/java/lang/invoke/SpreadGeneric.java < src/share/classes/java/dyn/SpreadGeneric.java + src/share/classes/java/lang/invoke/SwitchPoint.java ! src/share/classes/java/lang/invoke/ToGeneric.java < src/share/classes/java/dyn/ToGeneric.java ! src/share/classes/java/lang/invoke/VolatileCallSite.java < src/share/classes/java/dyn/VolatileCallSite.java ! src/share/classes/java/lang/invoke/WrongMethodTypeException.java < src/share/classes/java/dyn/WrongMethodTypeException.java + src/share/classes/java/lang/invoke/package-info.java - src/share/classes/sun/dyn/WrapperInstance.java - src/share/classes/sun/dyn/anon/AnonymousClassLoader.java - src/share/classes/sun/dyn/anon/ConstantPoolParser.java - src/share/classes/sun/dyn/anon/ConstantPoolPatch.java - src/share/classes/sun/dyn/anon/ConstantPoolVisitor.java - src/share/classes/sun/dyn/anon/InvalidConstantPoolFormatException.java - src/share/classes/sun/dyn/empty/Empty.java - src/share/classes/sun/dyn/package-info.java - src/share/classes/sun/dyn/util/BytecodeDescriptor.java - src/share/classes/sun/dyn/util/BytecodeName.java - src/share/classes/sun/dyn/util/VerifyType.java - src/share/classes/sun/dyn/util/Wrapper.java - src/share/classes/sun/dyn/util/package-info.java + src/share/classes/sun/invoke/WrapperInstance.java + src/share/classes/sun/invoke/anon/AnonymousClassLoader.java + src/share/classes/sun/invoke/anon/ConstantPoolParser.java + src/share/classes/sun/invoke/anon/ConstantPoolPatch.java + src/share/classes/sun/invoke/anon/ConstantPoolVisitor.java + src/share/classes/sun/invoke/anon/InvalidConstantPoolFormatException.java + src/share/classes/sun/invoke/empty/Empty.java + src/share/classes/sun/invoke/package-info.java + src/share/classes/sun/invoke/util/BytecodeDescriptor.java + src/share/classes/sun/invoke/util/BytecodeName.java ! src/share/classes/sun/invoke/util/ValueConversions.java < src/share/classes/sun/dyn/util/ValueConversions.java ! src/share/classes/sun/invoke/util/VerifyAccess.java < src/share/classes/sun/dyn/util/VerifyAccess.java + src/share/classes/sun/invoke/util/VerifyType.java + src/share/classes/sun/invoke/util/Wrapper.java + src/share/classes/sun/invoke/util/package-info.java ! src/share/native/common/check_code.c - test/java/dyn/ClassValueTest.java - test/java/dyn/InvokeDynamicPrintArgs.java - test/java/dyn/InvokeGenericTest.java - test/java/dyn/JavaDocExamplesTest.java - test/java/dyn/MethodHandlesTest.java - test/java/dyn/indify/Indify.java ! test/java/lang/invoke/6987555/Test6987555.java < test/java/dyn/6987555/Test6987555.java ! test/java/lang/invoke/6991596/Test6991596.java < test/java/dyn/6991596/Test6991596.java + test/java/lang/invoke/ClassValueTest.java + test/java/lang/invoke/InvokeDynamicPrintArgs.java + test/java/lang/invoke/InvokeGenericTest.java + test/java/lang/invoke/JavaDocExamplesTest.java + test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/MethodTypeTest.java < test/java/dyn/MethodTypeTest.java + test/java/lang/invoke/indify/Indify.java Changeset: 4770b99ba850 Author: jrose Date: 2011-03-24 00:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4770b99ba850 Merge ! make/common/Release.gmk - make/java/dyn/Makefile - src/share/classes/java/dyn/CallSite.java - src/share/classes/java/dyn/ClassValue.java - src/share/classes/java/dyn/ConstantCallSite.java - src/share/classes/java/dyn/InvokeDynamic.java - src/share/classes/java/dyn/InvokeDynamicBootstrapError.java - src/share/classes/java/dyn/Linkage.java - src/share/classes/java/dyn/MethodHandle.java - src/share/classes/java/dyn/MethodHandles.java - src/share/classes/java/dyn/MethodType.java - src/share/classes/java/dyn/MethodTypeForm.java - src/share/classes/java/dyn/MutableCallSite.java - src/share/classes/java/dyn/SwitchPoint.java - src/share/classes/java/dyn/VolatileCallSite.java - src/share/classes/java/dyn/WrongMethodTypeException.java - src/share/classes/java/dyn/package-info.java - src/share/classes/sun/dyn/Access.java - src/share/classes/sun/dyn/AdapterMethodHandle.java - src/share/classes/sun/dyn/BoundMethodHandle.java - src/share/classes/sun/dyn/CallSiteImpl.java - src/share/classes/sun/dyn/DirectMethodHandle.java - src/share/classes/sun/dyn/FilterGeneric.java - src/share/classes/sun/dyn/FilterOneArgument.java - src/share/classes/sun/dyn/FromGeneric.java - src/share/classes/sun/dyn/InvokeGeneric.java - src/share/classes/sun/dyn/Invokers.java - src/share/classes/sun/dyn/MemberName.java - src/share/classes/sun/dyn/MethodHandleImpl.java - src/share/classes/sun/dyn/MethodHandleNatives.java - src/share/classes/sun/dyn/MethodTypeImpl.java - src/share/classes/sun/dyn/SpreadGeneric.java - src/share/classes/sun/dyn/ToGeneric.java - src/share/classes/sun/dyn/WrapperInstance.java - src/share/classes/sun/dyn/anon/AnonymousClassLoader.java - src/share/classes/sun/dyn/anon/ConstantPoolParser.java - src/share/classes/sun/dyn/anon/ConstantPoolPatch.java - src/share/classes/sun/dyn/anon/ConstantPoolVisitor.java - src/share/classes/sun/dyn/anon/InvalidConstantPoolFormatException.java - src/share/classes/sun/dyn/empty/Empty.java - src/share/classes/sun/dyn/package-info.java - src/share/classes/sun/dyn/util/BytecodeDescriptor.java - src/share/classes/sun/dyn/util/BytecodeName.java - src/share/classes/sun/dyn/util/ValueConversions.java - src/share/classes/sun/dyn/util/VerifyAccess.java - src/share/classes/sun/dyn/util/VerifyType.java - src/share/classes/sun/dyn/util/Wrapper.java - src/share/classes/sun/dyn/util/package-info.java - test/java/dyn/ClassValueTest.java - test/java/dyn/InvokeDynamicPrintArgs.java - test/java/dyn/InvokeGenericTest.java - test/java/dyn/JavaDocExamplesTest.java - test/java/dyn/MethodHandlesTest.java - test/java/dyn/MethodTypeTest.java - test/java/dyn/indify/Indify.java From john.coomes at oracle.com Fri Mar 25 02:57:44 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 Mar 2011 09:57:44 +0000 Subject: hg: jdk7/hotspot/hotspot: 7 new changesets Message-ID: <20110325095802.162F04746E@hg.openjdk.java.net> Changeset: d673ef06fe96 Author: never Date: 2011-03-18 15:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d673ef06fe96 7028374: race in fix_oop_relocations for scavengeable nmethods Reviewed-by: kvn ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/x86/vm/relocInfo_x86.cpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/memory/universe.cpp Changeset: c7f3d0b4570f Author: never Date: 2011-03-18 16:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c7f3d0b4570f 7017732: move static fields into Class to prepare for perm gen removal Reviewed-by: kvn, coleenp, twisti, stefank ! agent/src/share/classes/sun/jvm/hotspot/jdi/FieldImpl.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/IntField.java ! agent/src/share/classes/sun/jvm/hotspot/oops/OopField.java ! agent/src/share/classes/sun/jvm/hotspot/oops/OopUtilities.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/test/jdi/sasanity.sh ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/dump_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciCPCache.cpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciInstance.cpp ! src/share/vm/ci/ciInstance.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/compactingPermGenGen.hpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/arrayKlassKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp + src/share/vm/oops/instanceMirrorKlass.cpp + src/share/vm/oops/instanceMirrorKlass.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassKlass.cpp ! src/share/vm/oops/klassOop.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/objArrayKlassKlass.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/shark/sharkNativeWrapper.cpp Changeset: 57552dca1708 Author: never Date: 2011-03-21 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/57552dca1708 7029509: nightly failures after static fields in Class Reviewed-by: kvn ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/services/heapDumper.cpp Changeset: 924777755fad Author: jcoomes Date: 2011-03-21 18:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/924777755fad 6962930: make the string table size configurable Reviewed-by: never, phh, stefank, kamg, dholmes, coleenp ! agent/src/share/classes/sun/jvm/hotspot/memory/StringTable.java ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: b099aaf51bf8 Author: jcoomes Date: 2011-03-22 13:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b099aaf51bf8 6962931: move interned strings out of the perm gen Reviewed-by: never, coleenp, ysr, jwilhelm ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/globals.hpp Changeset: 32f7097f9d8f Author: never Date: 2011-03-23 10:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/32f7097f9d8f 7030300: more nightly failures after statics in Class changes Reviewed-by: iveresov, jcoomes, dcubed ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp Changeset: f195ebb181b8 Author: jcoomes Date: 2011-03-24 23:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f195ebb181b8 Merge From john.coomes at oracle.com Fri Mar 25 05:29:05 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 Mar 2011 12:29:05 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20110325122912.708D64747D@hg.openjdk.java.net> Changeset: 3ef1a1866a60 Author: twisti Date: 2011-03-21 02:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3ef1a1866a60 7027232: JSR 292: wrong numeric value returned by MH on solaris-sparc Reviewed-by: kvn, never ! src/cpu/sparc/vm/methodHandles_sparc.cpp Changeset: 9dc311b8473e Author: kvn Date: 2011-03-21 11:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9dc311b8473e 7008866: Missing loop predicate for loop with multiple entries Summary: Add predicates when loop head bytecode is parsed instead of when back branch bytecode is parsed. Reviewed-by: never ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/stringopts.cpp Changeset: 0a5d9566b8a4 Author: twisti Date: 2011-03-23 04:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0a5d9566b8a4 7029805: JSR 292 compiler/6991596/Test6991596.java fails in nightly Summary: Both JSR 292 compiler tests were moved with 6839872 to the jdk repository Reviewed-by: never - test/compiler/6987555/Test6987555.java - test/compiler/6991596/Test6991596.java Changeset: 0e3ed5a14f73 Author: jcoomes Date: 2011-03-24 23:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0e3ed5a14f73 Merge ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/stringopts.cpp - test/compiler/6987555/Test6987555.java - test/compiler/6991596/Test6991596.java From john.coomes at oracle.com Fri Mar 25 08:00:31 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 25 Mar 2011 15:00:31 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20110325150037.4871B47485@hg.openjdk.java.net> Changeset: 083f13976b51 Author: dholmes Date: 2011-03-21 22:16 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/083f13976b51 6535709: interrupt of wait()ing thread isn't triggerring InterruptedException - test intwait3 Summary: only clear the interrupt state if we will report that it was set Reviewed-by: dcubed, alanb, phh, coleenp, dice ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/osThread.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: fc416c2556ec Author: mchung Date: 2011-03-22 18:04 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fc416c2556ec 7025628: Remove the temporary hack added for jdk modularization in hotspot Summary: Removed Reviewed-by: ohair, coleenp ! src/share/vm/runtime/os.cpp Changeset: 006b3750a4d4 Author: jcoomes Date: 2011-03-24 23:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/006b3750a4d4 Merge ! src/share/vm/runtime/vmStructs.cpp From tom.rodriguez at oracle.com Fri Mar 25 09:49:22 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 25 Mar 2011 09:49:22 -0700 Subject: review (S) for 7022204: LogFile wildcarding should use %p instead of star Message-ID: <5C57C18E-0EC1-4662-A5E5-B14E03BB9E41@oracle.com> http://cr.openjdk.java.net/~never/7022204 7022204: LogFile wildcarding should use %p instead of star Reviewed-by: Currently to get wildcarding in the LogFile name you have to use * which is very unfriendly for shell scripts. We should use %p as we do in other places. It still accepts * and will convert it in preference to %p. I considered switching to using Arguments::copy_expand_pid but it would change the behaviour of the flag in an incompatible way so I just augmented the existing logic slightly. Tested with various command line flags From john.r.rose at oracle.com Fri Mar 25 10:52:09 2011 From: john.r.rose at oracle.com (John Rose) Date: Fri, 25 Mar 2011 10:52:09 -0700 Subject: review (S) for 7022204: LogFile wildcarding should use %p instead of star In-Reply-To: <5C57C18E-0EC1-4662-A5E5-B14E03BB9E41@oracle.com> References: <5C57C18E-0EC1-4662-A5E5-B14E03BB9E41@oracle.com> Message-ID: <5044D643-B0A6-427F-817B-0009B2272F9E@oracle.com> Reviewed; thanks. -- John On Mar 25, 2011, at 9:49 AM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7022204 > > 7022204: LogFile wildcarding should use %p instead of star > Reviewed-by: > > Currently to get wildcarding in the LogFile name you have to use * > which is very unfriendly for shell scripts. We should use %p as we do > in other places. It still accepts * and will convert it in preference > to %p. I considered switching to using Arguments::copy_expand_pid but > it would change the behaviour of the flag in an incompatible way so I > just augmented the existing logic slightly. Tested with various > command line flags From tom.rodriguez at oracle.com Fri Mar 25 11:34:37 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 25 Mar 2011 11:34:37 -0700 Subject: review (S) for 7022204: LogFile wildcarding should use %p instead of star In-Reply-To: <5044D643-B0A6-427F-817B-0009B2272F9E@oracle.com> References: <5C57C18E-0EC1-4662-A5E5-B14E03BB9E41@oracle.com> <5044D643-B0A6-427F-817B-0009B2272F9E@oracle.com> Message-ID: Thanks John and Coleen. tom On Mar 25, 2011, at 10:52 AM, John Rose wrote: > Reviewed; thanks. -- John > > On Mar 25, 2011, at 9:49 AM, Tom Rodriguez wrote: > >> http://cr.openjdk.java.net/~never/7022204 >> >> 7022204: LogFile wildcarding should use %p instead of star >> Reviewed-by: >> >> Currently to get wildcarding in the LogFile name you have to use * >> which is very unfriendly for shell scripts. We should use %p as we do >> in other places. It still accepts * and will convert it in preference >> to %p. I considered switching to using Arguments::copy_expand_pid but >> it would change the behaviour of the flag in an incompatible way so I >> just augmented the existing logic slightly. Tested with various >> command line flags > From dbhole at redhat.com Fri Mar 25 19:59:52 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Fri, 25 Mar 2011 22:59:52 -0400 Subject: Output register allocation constrain fix for HotSpot Message-ID: <20110326025952.GA31265@redhat.com> Hi, When trying to build IcedTea with GCC 4.6, we encountered an error that stems from incorrect register allocation in release_store_fence(volatile jbyte* p, jbyte v) in orderAccess_linux_x86.inline.hpp. Specifically, the inline assembly call trying to do an atomic 8-bit exchange sets the output register constrain to r. The older versions GCC (by chance) ended up assigning the l-part of one of the a/b/c/d registers. However with 4.6, it attempts to do this with the %*bp register. This is fine on x86_64, but on i686 the bp register cannot be addressed in 8-bit (%bpl). This leads to a compilation failure: /builddir/build/BUILD/icedtea6-1.10/openjdk-ecj/hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp: Assembler messages: /builddir/build/BUILD/icedtea6-1.10/openjdk-ecj/hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp:160: Error: bad register name `%bpl' /builddir/build/BUILD/icedtea6-1.10/openjdk-ecj/hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp:160: Error: bad register name `%bpl' It is possible to make it work on both 32 and 64-bit by constraining the output register further to only be one of a/b/c/d (=q). Though it was only that function that caused an error, I think it'd be best to change both uses of xchgb in orderAccess_linux_x86.inline.hpp to use =q. Here is the webrev for it: http://cr.openjdk.java.net/~dbhole/register-allocation-fix/webrev.00/ If there are no issues, I'd be happy to push the above change. Cheers, Deepak From David.Holmes at oracle.com Fri Mar 25 20:10:08 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 26 Mar 2011 13:10:08 +1000 Subject: Output register allocation constrain fix for HotSpot In-Reply-To: <20110326025952.GA31265@redhat.com> References: <20110326025952.GA31265@redhat.com> Message-ID: <4D8D5910.6010901@oracle.com> Hi Deepak, I've filed "7031385 incorrect register allocation in release_store_fence on linux x86" for this issue. David Holmes Deepak Bhole said the following on 03/26/11 12:59: > Hi, > > When trying to build IcedTea with GCC 4.6, we encountered an error that > stems from incorrect register allocation in release_store_fence(volatile > jbyte* p, jbyte v) in orderAccess_linux_x86.inline.hpp. > > Specifically, the inline assembly call trying to do an atomic 8-bit > exchange sets the output register constrain to r. The older versions GCC > (by chance) ended up assigning the l-part of one of the a/b/c/d > registers. However with 4.6, it attempts to do this with the > %*bp register. This is fine on x86_64, but on i686 the bp register > cannot be addressed in 8-bit (%bpl). This leads to a compilation > failure: > > /builddir/build/BUILD/icedtea6-1.10/openjdk-ecj/hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp: Assembler messages: > /builddir/build/BUILD/icedtea6-1.10/openjdk-ecj/hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp:160: Error: bad register name `%bpl' > /builddir/build/BUILD/icedtea6-1.10/openjdk-ecj/hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp:160: Error: bad register name `%bpl' > > It is possible to make it work on both 32 and 64-bit by constraining the > output register further to only be one of a/b/c/d (=q). > > Though it was only that function that caused an error, I think it'd be > best to change both uses of xchgb in orderAccess_linux_x86.inline.hpp to > use =q. Here is the webrev for it: > http://cr.openjdk.java.net/~dbhole/register-allocation-fix/webrev.00/ > > If there are no issues, I'd be happy to push the above change. > > Cheers, > Deepak From David.Holmes at oracle.com Fri Mar 25 20:11:45 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 26 Mar 2011 13:11:45 +1000 Subject: Output register allocation constrain fix for HotSpot In-Reply-To: <20110326025952.GA31265@redhat.com> References: <20110326025952.GA31265@redhat.com> Message-ID: <4D8D5971.5000207@oracle.com> Forgot to mention that you can't push directly to Hotspot as it needs to go through our internal JPRT submission system. So someone from the runtime team will have to shepherd this for you. David Deepak Bhole said the following on 03/26/11 12:59: > Hi, > > When trying to build IcedTea with GCC 4.6, we encountered an error that > stems from incorrect register allocation in release_store_fence(volatile > jbyte* p, jbyte v) in orderAccess_linux_x86.inline.hpp. > > Specifically, the inline assembly call trying to do an atomic 8-bit > exchange sets the output register constrain to r. The older versions GCC > (by chance) ended up assigning the l-part of one of the a/b/c/d > registers. However with 4.6, it attempts to do this with the > %*bp register. This is fine on x86_64, but on i686 the bp register > cannot be addressed in 8-bit (%bpl). This leads to a compilation > failure: > > /builddir/build/BUILD/icedtea6-1.10/openjdk-ecj/hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp: Assembler messages: > /builddir/build/BUILD/icedtea6-1.10/openjdk-ecj/hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp:160: Error: bad register name `%bpl' > /builddir/build/BUILD/icedtea6-1.10/openjdk-ecj/hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp:160: Error: bad register name `%bpl' > > It is possible to make it work on both 32 and 64-bit by constraining the > output register further to only be one of a/b/c/d (=q). > > Though it was only that function that caused an error, I think it'd be > best to change both uses of xchgb in orderAccess_linux_x86.inline.hpp to > use =q. Here is the webrev for it: > http://cr.openjdk.java.net/~dbhole/register-allocation-fix/webrev.00/ > > If there are no issues, I'd be happy to push the above change. > > Cheers, > Deepak From erik.trimble at oracle.com Sat Mar 26 04:22:24 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Sat, 26 Mar 2011 11:22:24 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20110326112233.C3005474C3@hg.openjdk.java.net> Changeset: 7449da4cdab5 Author: schien Date: 2011-03-24 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7449da4cdab5 Added tag jdk7-b135 for changeset b898f0fc3ced ! .hgtags Changeset: 661c46a8434c Author: trims Date: 2011-03-25 17:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/661c46a8434c Added tag hs21-b05 for changeset b898f0fc3ced ! .hgtags Changeset: c10b82a05d58 Author: trims Date: 2011-03-25 18:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c10b82a05d58 Merge - test/compiler/6987555/Test6987555.java - test/compiler/6991596/Test6991596.java Changeset: bd586e392d93 Author: trims Date: 2011-03-25 18:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/bd586e392d93 7031227: Bump the HS21 build number to 06 Summary: Update the HS21 build number to 06 Reviewed-by: jcoomes ! make/hotspot_version From john.cuthbertson at oracle.com Mon Mar 28 10:35:28 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 28 Mar 2011 10:35:28 -0700 Subject: RFR(M): 7009266: G1: assert(obj->is_oop_or_null(true )) failed: Error In-Reply-To: <4D7ACDBA.7020003@oracle.com> References: <4D7ACDBA.7020003@oracle.com> Message-ID: <4D90C6E0.9000901@oracle.com> Hi Everyone, A new webrev with changes based upon comments from Tom can be found at: http://cr.openjdk.java.net/~johnc/7009266/webrev.4/. The latest changes include inserting a suitably guarded barrier call in case the referent field of a Reference object is being read/fetched using JNI, reflection, or Unsafe. Thanks, JohnC On 3/11/2011 5:34 PM, John Cuthbertson wrote: > Hi Everyone, > > I'm looking for a few of volunteers to review the changes that fix > this assertion failure. The latest changes can be found at: > http://cr.openjdk.java.net/~johnc/7009266/webrev.3/ and include > changes based upon earlier internal reviews. The earlier changes are > also on cr.openjdk.java.net for reference. > > Background: > The G1 garbage collector includes a concurrent marking algorithm that > makes use of snapshot-at-the-beginning or SATB. With this algorithm > the GC will mark all objects that are reachable at the start of > marking; objects that are allocated since the start of marking are > implicitly considered live. In order to populate the "snapshot" of the > object graph that existed at the start of marking, G1 employs a write > barrier. When an object is stored into another object's field the > write-barrier records the previous value of that field as it was part > of the "snapshot" and concurrent marking will trace the sub-graph that > is reachable from this previous value. > > Unfortunately, in the presence of Reference objects, SATB might not be > sufficient to mark a referent object as live. Consider that, at the > start of marking, we have a weakly reachable object i.e. an object > where the only pointer to that object. If the referent is obtained > from the Reference object and stored to another object's field (making > the referent now strongly reachable and hence live) the G1 write > barrier will record the field's previous value but not the value of > the referent. > > If the referent object is strongly reachable from some other object > that will be traced by concurrent marking, _or_ there is a subsequent > assignment to the field where we have written the referent (in which > case we record the previous value - the referent - in an SATB buffer) > then the referent will be marked live. Otherwise the referent will not > be marked. > > That is the issue that was causing the failure in this CR. There was a > Logger object that was only reachable through a WeakReference at the > start of concurrent marking. During marking the Logger object is > obtained from the WeakReference and stored into a field of a live > object. The G1 write barrier recorded the previous value in the field > (as it is part of the snapshot at the start of marking). Since there > was no other assignment to the live object's field and there was no > other strong reference to the Logger object, the Logger object was not > marked. At the end of concurrent marking the Logger object was > considered dead and the link between the WeakReference and the Logger > was severed by clearing the referent field during reference processing. > > To solve this (entirely in Hotspot and causing a performance overhead > for G1 only) it was decided that the best approach was to intrinsify > the Reference.get() method in the JIT compilers and add new > interpreter entry points so that the value in the referent field will > be recorded in an SATB buffer by the G1 pre-barrier code. > > The changes for Zero and the C++ interpreters are place holder > routines but should be straight forward to implement. > > None of the individual changes is large - they are just well > distributed around the JVM. :) > > Testing: white box test; eyeballing the generated compiled and > interpreter code; the failing Kitchensink big-app on x86 (32/64 bit), > sparc (32/64 bit), Xint, Xcomp (client and server), with and without > G1; the GC test suite with and without G1; and jprt. > > Thanks and regards, > > JohnC From christian.thalinger at oracle.com Mon Mar 28 10:41:39 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 28 Mar 2011 19:41:39 +0200 Subject: Request for review (S): 6817525: turn on method handle functionality by default for JSR 292 Message-ID: http://cr.openjdk.java.net/~twisti/6817525/ 6817525: turn on method handle functionality by default for JSR 292 Summary: After appropriate testing, we need to turn on EnableMethodHandles and EnableInvokeDynamic by default. Reviewed-by: After appropriate testing, we need to turn on EnableMethodHandles and EnableInvokeDynamic by default. From vladimir.kozlov at oracle.com Mon Mar 28 12:09:26 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 28 Mar 2011 12:09:26 -0700 Subject: RFR(M): 7009266: G1: assert(obj->is_oop_or_null(true )) failed: Error In-Reply-To: <4D90C6E0.9000901@oracle.com> References: <4D7ACDBA.7020003@oracle.com> <4D90C6E0.9000901@oracle.com> Message-ID: <4D90DCE6.3000804@oracle.com> You need to regenerated webrev since callGenerator.hpp and callGenerator.cpp are empty now. unsafe.cpp: + // We could be accessing the the referent field in a reference ^ Why you are not using update_barrier_set_pre (as in Unsafe_CompareAndSwapObject)? you left test outputs: + tty->print_cr("####### Unsafe_GetObject: offset = " INTX_FORMAT, offset); tty->print_cr("####### Unsafe_GetObject: need a G1 barrier"); Vladimir John Cuthbertson wrote: > Hi Everyone, > > A new webrev with changes based upon comments from Tom can be found at: > http://cr.openjdk.java.net/~johnc/7009266/webrev.4/. > > The latest changes include inserting a suitably guarded barrier call in > case the referent field of a Reference object is being read/fetched > using JNI, reflection, or Unsafe. > > Thanks, > > JohnC > > On 3/11/2011 5:34 PM, John Cuthbertson wrote: >> Hi Everyone, >> >> I'm looking for a few of volunteers to review the changes that fix >> this assertion failure. The latest changes can be found at: >> http://cr.openjdk.java.net/~johnc/7009266/webrev.3/ and include >> changes based upon earlier internal reviews. The earlier changes are >> also on cr.openjdk.java.net for reference. >> >> Background: >> The G1 garbage collector includes a concurrent marking algorithm that >> makes use of snapshot-at-the-beginning or SATB. With this algorithm >> the GC will mark all objects that are reachable at the start of >> marking; objects that are allocated since the start of marking are >> implicitly considered live. In order to populate the "snapshot" of the >> object graph that existed at the start of marking, G1 employs a write >> barrier. When an object is stored into another object's field the >> write-barrier records the previous value of that field as it was part >> of the "snapshot" and concurrent marking will trace the sub-graph that >> is reachable from this previous value. >> >> Unfortunately, in the presence of Reference objects, SATB might not be >> sufficient to mark a referent object as live. Consider that, at the >> start of marking, we have a weakly reachable object i.e. an object >> where the only pointer to that object. If the referent is obtained >> from the Reference object and stored to another object's field (making >> the referent now strongly reachable and hence live) the G1 write >> barrier will record the field's previous value but not the value of >> the referent. >> >> If the referent object is strongly reachable from some other object >> that will be traced by concurrent marking, _or_ there is a subsequent >> assignment to the field where we have written the referent (in which >> case we record the previous value - the referent - in an SATB buffer) >> then the referent will be marked live. Otherwise the referent will not >> be marked. >> >> That is the issue that was causing the failure in this CR. There was a >> Logger object that was only reachable through a WeakReference at the >> start of concurrent marking. During marking the Logger object is >> obtained from the WeakReference and stored into a field of a live >> object. The G1 write barrier recorded the previous value in the field >> (as it is part of the snapshot at the start of marking). Since there >> was no other assignment to the live object's field and there was no >> other strong reference to the Logger object, the Logger object was not >> marked. At the end of concurrent marking the Logger object was >> considered dead and the link between the WeakReference and the Logger >> was severed by clearing the referent field during reference processing. >> >> To solve this (entirely in Hotspot and causing a performance overhead >> for G1 only) it was decided that the best approach was to intrinsify >> the Reference.get() method in the JIT compilers and add new >> interpreter entry points so that the value in the referent field will >> be recorded in an SATB buffer by the G1 pre-barrier code. >> >> The changes for Zero and the C++ interpreters are place holder >> routines but should be straight forward to implement. >> >> None of the individual changes is large - they are just well >> distributed around the JVM. :) >> >> Testing: white box test; eyeballing the generated compiled and >> interpreter code; the failing Kitchensink big-app on x86 (32/64 bit), >> sparc (32/64 bit), Xint, Xcomp (client and server), with and without >> G1; the GC test suite with and without G1; and jprt. >> >> Thanks and regards, >> >> JohnC > From vladimir.kozlov at oracle.com Mon Mar 28 12:15:38 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 28 Mar 2011 12:15:38 -0700 Subject: Request for review (S): 6817525: turn on method handle functionality by default for JSR 292 In-Reply-To: References: Message-ID: <4D90DE5A.8060701@oracle.com> thread.cpp no diffs? Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6817525/ > > 6817525: turn on method handle functionality by default for JSR 292 > Summary: After appropriate testing, we need to turn on EnableMethodHandles and EnableInvokeDynamic by default. > Reviewed-by: > > After appropriate testing, we need to turn on EnableMethodHandles and > EnableInvokeDynamic by default. > From christian.thalinger at oracle.com Mon Mar 28 12:32:10 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 28 Mar 2011 21:32:10 +0200 Subject: Request for review (S): 6817525: turn on method handle functionality by default for JSR 292 In-Reply-To: <4D90DE5A.8060701@oracle.com> References: <4D90DE5A.8060701@oracle.com> Message-ID: <8E110BA6-5697-4F95-85AA-1ACD46AC83E7@oracle.com> On Mar 28, 2011, at 9:15 PM, Vladimir Kozlov wrote: > thread.cpp no diffs? It's a small indent leftover: http://cr.openjdk.java.net/~twisti/6817525/src/share/vm/runtime/thread.cpp.patch -- Christian > > Vladimir > > Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/6817525/ >> 6817525: turn on method handle functionality by default for JSR 292 >> Summary: After appropriate testing, we need to turn on EnableMethodHandles and EnableInvokeDynamic by default. >> Reviewed-by: >> After appropriate testing, we need to turn on EnableMethodHandles and >> EnableInvokeDynamic by default. From john.cuthbertson at oracle.com Mon Mar 28 12:41:54 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 28 Mar 2011 12:41:54 -0700 Subject: RFR(M): 7009266: G1: assert(obj->is_oop_or_null(true )) failed: Error In-Reply-To: <4D90DCE6.3000804@oracle.com> References: <4D7ACDBA.7020003@oracle.com> <4D90C6E0.9000901@oracle.com> <4D90DCE6.3000804@oracle.com> Message-ID: <4D90E482.4050402@oracle.com> Hi Vladimir, On 03/28/11 12:09, Vladimir Kozlov wrote: > You need to regenerated webrev since callGenerator.hpp and > callGenerator.cpp are empty now. OK. I'll make the changes and re-generate > > unsafe.cpp: > + // We could be accessing the the referent field in a reference > ^ > Oops. > Why you are not using update_barrier_set_pre (as in > Unsafe_CompareAndSwapObject)? I didn't know it existed. I'll take a look and see if it's suitable. > > you left test outputs: > + tty->print_cr("####### Unsafe_GetObject: offset = " INTX_FORMAT, > offset); > tty->print_cr("####### Unsafe_GetObject: need a G1 barrier"); > Oops again. I thought I caught all of these. Thanks, JohnC From john.r.rose at oracle.com Mon Mar 28 12:49:49 2011 From: john.r.rose at oracle.com (John Rose) Date: Mon, 28 Mar 2011 12:49:49 -0700 Subject: Request for review (S): 6817525: turn on method handle functionality by default for JSR 292 In-Reply-To: References: Message-ID: <8242083B-D624-497F-BBB5-6B196B75AF0A@oracle.com> EnableInvokeDynamic and related switches may be useful for diagnostic testing, for root cause analysis. And they are needed to differentiate behavior of 1.6 from 1.7. But they are probably not useful as full product switches. Unless there's a reason against it, we should categorize them as diagnostic switches. This will affect the messages in methodHandles.cpp as well as the defs in globals.hpp. Also, in arguments.cpp, I suggest replacing "supported since 1.7" by "not supported before 1.7", which is logically more precise. Thanks! -- John On Mar 28, 2011, at 10:41 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6817525/ > > 6817525: turn on method handle functionality by default for JSR 292 > Summary: After appropriate testing, we need to turn on EnableMethodHandles and EnableInvokeDynamic by default. > Reviewed-by: > > After appropriate testing, we need to turn on EnableMethodHandles and > EnableInvokeDynamic by default. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110328/2847814d/attachment.html From christian.thalinger at oracle.com Mon Mar 28 12:55:55 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 28 Mar 2011 21:55:55 +0200 Subject: Request for review (S): 6817525: turn on method handle functionality by default for JSR 292 In-Reply-To: <8242083B-D624-497F-BBB5-6B196B75AF0A@oracle.com> References: <8242083B-D624-497F-BBB5-6B196B75AF0A@oracle.com> Message-ID: On Mar 28, 2011, at 9:49 PM, John Rose wrote: > EnableInvokeDynamic and related switches may be useful for diagnostic testing, for root cause analysis. And they are needed to differentiate behavior of 1.6 from 1.7. But they are probably not useful as full product switches. Unless there's a reason against it, we should categorize them as diagnostic switches. This will affect the messages in methodHandles.cpp as well as the defs in globals.hpp. Okay. I will change them to diagnostic switches. > > Also, in arguments.cpp, I suggest replacing "supported since 1.7" by "not supported before 1.7", which is logically more precise. I agree. -- Christian > > Thanks! > > -- John > > On Mar 28, 2011, at 10:41 AM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/6817525/ >> >> 6817525: turn on method handle functionality by default for JSR 292 >> Summary: After appropriate testing, we need to turn on EnableMethodHandles and EnableInvokeDynamic by default. >> Reviewed-by: >> >> After appropriate testing, we need to turn on EnableMethodHandles and >> EnableInvokeDynamic by default. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110328/13b4fd54/attachment.html From tom.rodriguez at oracle.com Mon Mar 28 12:58:29 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 28 Mar 2011 12:58:29 -0700 Subject: Request for review (S): 6817525: turn on method handle functionality by default for JSR 292 In-Reply-To: <8242083B-D624-497F-BBB5-6B196B75AF0A@oracle.com> References: <8242083B-D624-497F-BBB5-6B196B75AF0A@oracle.com> Message-ID: <98121B5B-3786-488B-AB18-1EFAEEB708AE@oracle.com> On Mar 28, 2011, at 12:49 PM, John Rose wrote: > EnableInvokeDynamic and related switches may be useful for diagnostic testing, for root cause analysis. And they are needed to differentiate behavior of 1.6 from 1.7. But they are probably not useful as full product switches. Unless there's a reason against it, we should categorize them as diagnostic switches. This will affect the messages in methodHandles.cpp as well as the defs in globals.hpp. Why do we need the related switches as separate flags at all? EnableInvokeDynamic is required for 7 and the others are all implied by EnableInvokeDynamic. I don't see how they can be turned on or off independently in a meaningful way. I think it's more confusing having all these separate subflags. tom > > Also, in arguments.cpp, I suggest replacing "supported since 1.7" by "not supported before 1.7", which is logically more precise. > > Thanks! > > -- John > > On Mar 28, 2011, at 10:41 AM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/6817525/ >> >> 6817525: turn on method handle functionality by default for JSR 292 >> Summary: After appropriate testing, we need to turn on EnableMethodHandles and EnableInvokeDynamic by default. >> Reviewed-by: >> >> After appropriate testing, we need to turn on EnableMethodHandles and >> EnableInvokeDynamic by default. From tom.rodriguez at oracle.com Mon Mar 28 13:00:24 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 28 Mar 2011 13:00:24 -0700 Subject: RFR(M): 7009266: G1: assert(obj->is_oop_or_null(true )) failed: Error In-Reply-To: <4D90C6E0.9000901@oracle.com> References: <4D7ACDBA.7020003@oracle.com> <4D90C6E0.9000901@oracle.com> Message-ID: <316080F8-7FC4-4CCA-AFE0-915E09FD1BDE@oracle.com> c1_LIRGenerator.cpp: you can't write the branches as you've done them. The register allocator only understands block based control flow and the special case of CodeStubs. It's a limitation of the LIR that unfortunately isn't checked for by any existing asserts. It will work until the allocator decides to place a spill in the middle of your control flow. So you either need to write the guard in the high level IR during parsing or you need to implement it in assembly in a stub on the side. You should also try to constant fold some of these tests by hand since the LIR won't do that for you and in 99.99% of the cases they won't be needed. library_call.cpp: Can you put in the some guards to skip the code generation in cases where it's obviously not needed? Otherwise we're generating a bunch of goo during parsing that we'll just have to optimize away. Something like: TypeX* otype = offset->find_intptr_t_type(); if (otype != NULL && otype->is_con() && otype->get_con() != java_lang_ref_Reference::_reference_offset) { // Constant offset but not the reference_offset so just return return; } TypeOopPtr* btype = base_oop->isa_oop_ptr(); if (btype != NULL && btype->isa_ary_ptr()) { // Array type so nothing to do return; } will filter most uses out completely. Testing for TypeInstPtr would be slightly more complicated though I think something like if (byte->isa_instr_ptr() && !byte->isa_inst_ptr()->klass->is_subtype_of(env()->Reference_klass()) && !env()->Reference_klass()->is_subtype_of(byte->isa_instptr()->klass()) { return; } would work. Actually I don't think you should be testing against reference_type since we can't statically optimize those checks. A regular instance of check can be optimized away if have good type information for the object. Other than the constant formation it's no more expensive than the check you wrote. tom On Mar 28, 2011, at 10:35 AM, John Cuthbertson wrote: > Hi Everyone, > > A new webrev with changes based upon comments from Tom can be found at: http://cr.openjdk.java.net/~johnc/7009266/webrev.4/. > > The latest changes include inserting a suitably guarded barrier call in case the referent field of a Reference object is being read/fetched using JNI, reflection, or Unsafe. > > Thanks, > > JohnC > > On 3/11/2011 5:34 PM, John Cuthbertson wrote: >> Hi Everyone, >> >> I'm looking for a few of volunteers to review the changes that fix this assertion failure. The latest changes can be found at: http://cr.openjdk.java.net/~johnc/7009266/webrev.3/ and include changes based upon earlier internal reviews. The earlier changes are also on cr.openjdk.java.net for reference. >> >> Background: >> The G1 garbage collector includes a concurrent marking algorithm that makes use of snapshot-at-the-beginning or SATB. With this algorithm the GC will mark all objects that are reachable at the start of marking; objects that are allocated since the start of marking are implicitly considered live. In order to populate the "snapshot" of the object graph that existed at the start of marking, G1 employs a write barrier. When an object is stored into another object's field the write-barrier records the previous value of that field as it was part of the "snapshot" and concurrent marking will trace the sub-graph that is reachable from this previous value. >> >> Unfortunately, in the presence of Reference objects, SATB might not be sufficient to mark a referent object as live. Consider that, at the start of marking, we have a weakly reachable object i.e. an object where the only pointer to that object. If the referent is obtained from the Reference object and stored to another object's field (making the referent now strongly reachable and hence live) the G1 write barrier will record the field's previous value but not the value of the referent. >> >> If the referent object is strongly reachable from some other object that will be traced by concurrent marking, _or_ there is a subsequent assignment to the field where we have written the referent (in which case we record the previous value - the referent - in an SATB buffer) then the referent will be marked live. Otherwise the referent will not be marked. >> >> That is the issue that was causing the failure in this CR. There was a Logger object that was only reachable through a WeakReference at the start of concurrent marking. During marking the Logger object is obtained from the WeakReference and stored into a field of a live object. The G1 write barrier recorded the previous value in the field (as it is part of the snapshot at the start of marking). Since there was no other assignment to the live object's field and there was no other strong reference to the Logger object, the Logger object was not marked. At the end of concurrent marking the Logger object was considered dead and the link between the WeakReference and the Logger was severed by clearing the referent field during reference processing. >> >> To solve this (entirely in Hotspot and causing a performance overhead for G1 only) it was decided that the best approach was to intrinsify the Reference.get() method in the JIT compilers and add new interpreter entry points so that the value in the referent field will be recorded in an SATB buffer by the G1 pre-barrier code. >> >> The changes for Zero and the C++ interpreters are place holder routines but should be straight forward to implement. >> >> None of the individual changes is large - they are just well distributed around the JVM. :) >> >> Testing: white box test; eyeballing the generated compiled and interpreter code; the failing Kitchensink big-app on x86 (32/64 bit), sparc (32/64 bit), Xint, Xcomp (client and server), with and without G1; the GC test suite with and without G1; and jprt. >> >> Thanks and regards, >> >> JohnC > From john.r.rose at oracle.com Mon Mar 28 14:14:30 2011 From: john.r.rose at oracle.com (John Rose) Date: Mon, 28 Mar 2011 14:14:30 -0700 Subject: Request for review (S): 6817525: turn on method handle functionality by default for JSR 292 In-Reply-To: <98121B5B-3786-488B-AB18-1EFAEEB708AE@oracle.com> References: <8242083B-D624-497F-BBB5-6B196B75AF0A@oracle.com> <98121B5B-3786-488B-AB18-1EFAEEB708AE@oracle.com> Message-ID: <3AA5B061-AB12-4EEB-9684-E9BF102D1563@oracle.com> On Mar 28, 2011, at 12:58 PM, Tom Rodriguez wrote: > Why do we need the related switches as separate flags at all? EnableInvokeDynamic is required for 7 and the others are all implied by EnableInvokeDynamic. I don't see how they can be turned on or off independently in a meaningful way. I think it's more confusing having all these separate subflags. Merging them up to a single flag would be OK with me. (And since it's diagnostic, I don't care too much what the name is.) -- John From ahughes at redhat.com Tue Mar 29 07:26:06 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Tue, 29 Mar 2011 15:26:06 +0100 Subject: Is i686 the minimum required for HotSpot on x86? Message-ID: <20110329142606.GW6143@rivendell.middle-earth.co.uk> We've just had a bug report for IcedTea which suggests that HotSpot fails on any x86 platform below i686. The report is: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=682 and shows a failure caused by an attempt by the JIT to emit an instruction which isn't present on i586. Does HotSpot require i686 as a minimum? Or is there something else at fault here? Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From christian.thalinger at oracle.com Tue Mar 29 07:35:12 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 29 Mar 2011 16:35:12 +0200 Subject: Is i686 the minimum required for HotSpot on x86? In-Reply-To: <20110329142606.GW6143@rivendell.middle-earth.co.uk> References: <20110329142606.GW6143@rivendell.middle-earth.co.uk> Message-ID: On Mar 29, 2011, at 4:26 PM, Dr Andrew John Hughes wrote: > We've just had a bug report for IcedTea which suggests that > HotSpot fails on any x86 platform below i686. > > The report is: > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=682 > > and shows a failure caused by an attempt by the JIT to emit > an instruction which isn't present on i586. > > Does HotSpot require i686 as a minimum? Or is there something > else at fault here? There is a switch -XX:+Use486InstrsOnly but I have an open bug for that one: 6808665: Use486InstrsOnly aborts 32-bit VM -- Christian From vladimir.kozlov at oracle.com Tue Mar 29 08:23:15 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Mar 2011 08:23:15 -0700 Subject: Is i686 the minimum required for HotSpot on x86? In-Reply-To: <20110329142606.GW6143@rivendell.middle-earth.co.uk> References: <20110329142606.GW6143@rivendell.middle-earth.co.uk> Message-ID: <4D91F963.8080007@oracle.com> Andrew, It would be nice to have call stack trace. I looked on attached hs_er* files and non of them has it. JIT (Client VM) should not emit cmov instruction if it is not supported. Also there was suggestion in the report about running with -Xint, did it help? I surprise someone still try to run Hotspot on i586 ;) I can't even find P4 around here. And we definitely do not test on such machine (i586) so it is not supported. Vladimir On 3/29/11 7:26 AM, Dr Andrew John Hughes wrote: > We've just had a bug report for IcedTea which suggests that > HotSpot fails on any x86 platform below i686. > > The report is: > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=682 > > and shows a failure caused by an attempt by the JIT to emit > an instruction which isn't present on i586. > > Does HotSpot require i686 as a minimum? Or is there something > else at fault here? > > Thanks, From christian.thalinger at oracle.com Tue Mar 29 08:31:09 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 29 Mar 2011 17:31:09 +0200 Subject: Is i686 the minimum required for HotSpot on x86? In-Reply-To: References: <20110329142606.GW6143@rivendell.middle-earth.co.uk> Message-ID: <92D1C49C-5F83-46DD-8F5C-4CB42C77C454@oracle.com> On Mar 29, 2011, at 4:35 PM, Christian Thalinger wrote: > On Mar 29, 2011, at 4:26 PM, Dr Andrew John Hughes wrote: >> We've just had a bug report for IcedTea which suggests that >> HotSpot fails on any x86 platform below i686. >> >> The report is: >> >> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=682 >> >> and shows a failure caused by an attempt by the JIT to emit >> an instruction which isn't present on i586. >> >> Does HotSpot require i686 as a minimum? Or is there something >> else at fault here? > > There is a switch -XX:+Use486InstrsOnly but I have an open bug for that one: > > 6808665: Use486InstrsOnly aborts 32-bit VM Looking a little closer this could actually be my fault. I added unguarded cmov instructions to C1 with: 6919934: JSR 292 needs to support x86 C1 http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3cf667df43ef And that was delivered in HS18b01. I will fix that. -- Christian From christian.thalinger at oracle.com Tue Mar 29 08:46:35 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 29 Mar 2011 17:46:35 +0200 Subject: Request for review (S): 6817525: turn on method handle functionality by default for JSR 292 In-Reply-To: <3AA5B061-AB12-4EEB-9684-E9BF102D1563@oracle.com> References: <8242083B-D624-497F-BBB5-6B196B75AF0A@oracle.com> <98121B5B-3786-488B-AB18-1EFAEEB708AE@oracle.com> <3AA5B061-AB12-4EEB-9684-E9BF102D1563@oracle.com> Message-ID: On Mar 28, 2011, at 11:14 PM, John Rose wrote: > On Mar 28, 2011, at 12:58 PM, Tom Rodriguez wrote: > >> Why do we need the related switches as separate flags at all? EnableInvokeDynamic is required for 7 and the others are all implied by EnableInvokeDynamic. I don't see how they can be turned on or off independently in a meaningful way. I think it's more confusing having all these separate subflags. > > Merging them up to a single flag would be OK with me. (And since it's diagnostic, I don't care too much what the name is.) The obvious name is EnableJSR292. The change is now much bigger but almost all changes are trivial renames: http://cr.openjdk.java.net/~twisti/6817525/ I did a lot of testing with JRuby tests today and except a couple of (expected) hiccups it looks good. -- Christian From tom.rodriguez at oracle.com Tue Mar 29 08:55:27 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 29 Mar 2011 08:55:27 -0700 Subject: Request for review (S): 6817525: turn on method handle functionality by default for JSR 292 In-Reply-To: References: <8242083B-D624-497F-BBB5-6B196B75AF0A@oracle.com> <98121B5B-3786-488B-AB18-1EFAEEB708AE@oracle.com> <3AA5B061-AB12-4EEB-9684-E9BF102D1563@oracle.com> Message-ID: <3AA15588-6D44-4C4F-AC38-798C955E4C59@oracle.com> Looks good. tom On Mar 29, 2011, at 8:46 AM, Christian Thalinger wrote: > On Mar 28, 2011, at 11:14 PM, John Rose wrote: >> On Mar 28, 2011, at 12:58 PM, Tom Rodriguez wrote: >> >>> Why do we need the related switches as separate flags at all? EnableInvokeDynamic is required for 7 and the others are all implied by EnableInvokeDynamic. I don't see how they can be turned on or off independently in a meaningful way. I think it's more confusing having all these separate subflags. >> >> Merging them up to a single flag would be OK with me. (And since it's diagnostic, I don't care too much what the name is.) > > The obvious name is EnableJSR292. The change is now much bigger but almost all changes are trivial renames: > > http://cr.openjdk.java.net/~twisti/6817525/ > > I did a lot of testing with JRuby tests today and except a couple of (expected) hiccups it looks good. > > -- Christian From vladimir.kozlov at oracle.com Tue Mar 29 08:58:39 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Mar 2011 08:58:39 -0700 Subject: Request for review (S): 6817525: turn on method handle functionality by default for JSR 292 In-Reply-To: References: <8242083B-D624-497F-BBB5-6B196B75AF0A@oracle.com> <98121B5B-3786-488B-AB18-1EFAEEB708AE@oracle.com> <3AA5B061-AB12-4EEB-9684-E9BF102D1563@oracle.com> Message-ID: <4D9201AF.3090605@oracle.com> I would prefer the old EnableInvokeDynamic which is more informative I think. Otherwise looks good. Vladimir Christian Thalinger wrote: > On Mar 28, 2011, at 11:14 PM, John Rose wrote: >> On Mar 28, 2011, at 12:58 PM, Tom Rodriguez wrote: >> >>> Why do we need the related switches as separate flags at all? EnableInvokeDynamic is required for 7 and the others are all implied by EnableInvokeDynamic. I don't see how they can be turned on or off independently in a meaningful way. I think it's more confusing having all these separate subflags. >> Merging them up to a single flag would be OK with me. (And since it's diagnostic, I don't care too much what the name is.) > > The obvious name is EnableJSR292. The change is now much bigger but almost all changes are trivial renames: > > http://cr.openjdk.java.net/~twisti/6817525/ > > I did a lot of testing with JRuby tests today and except a couple of (expected) hiccups it looks good. > > -- Christian From john.pampuch at oracle.com Tue Mar 29 09:12:22 2011 From: john.pampuch at oracle.com (John Pampuch) Date: Tue, 29 Mar 2011 09:12:22 -0700 Subject: Request for review (S): 6817525: turn on method handle functionality by default for JSR 292 In-Reply-To: <4D9201AF.3090605@oracle.com> References: <8242083B-D624-497F-BBB5-6B196B75AF0A@oracle.com> <98121B5B-3786-488B-AB18-1EFAEEB708AE@oracle.com> <3AA5B061-AB12-4EEB-9684-E9BF102D1563@oracle.com> <4D9201AF.3090605@oracle.com> Message-ID: <4D9204E6.5090903@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110329/a11745a8/attachment.html From paul.hohensee at oracle.com Tue Mar 29 09:33:24 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 29 Mar 2011 12:33:24 -0400 Subject: Request for review (S): 6817525: turn on method handle functionality by default for JSR 292 In-Reply-To: <4D9204E6.5090903@oracle.com> References: <8242083B-D624-497F-BBB5-6B196B75AF0A@oracle.com> <98121B5B-3786-488B-AB18-1EFAEEB708AE@oracle.com> <3AA5B061-AB12-4EEB-9684-E9BF102D1563@oracle.com> <4D9201AF.3090605@oracle.com> <4D9204E6.5090903@oracle.com> Message-ID: <4D9209D4.5070401@oracle.com> I'd say the same: EnableJSR292 is a JCP process memento. If, as Tom says, you intend to enable all these features as a set, then I'd generify EnableInvokeDynamic by replacing it with, say, EnableDynamic. The latter is non-specific enough to cover the field and isn't tied to a specific JSR. Paul On 3/29/11 12:12 PM, John Pampuch wrote: > I think I agree with Vladimir. The name JSR-292 is an anomaly of the > process, and doesn't really communicate much. I don't think we > generally use the JSR ID for similar choices elsewhere either. > > -John > > On 3/29/11 8:58 AM, Vladimir Kozlov wrote: >> I would prefer the old EnableInvokeDynamic which is more informative >> I think. Otherwise looks good. >> >> Vladimir >> >> Christian Thalinger wrote: >>> On Mar 28, 2011, at 11:14 PM, John Rose wrote: >>>> On Mar 28, 2011, at 12:58 PM, Tom Rodriguez wrote: >>>> >>>>> Why do we need the related switches as separate flags at all? >>>>> EnableInvokeDynamic is required for 7 and the others are all >>>>> implied by EnableInvokeDynamic. I don't see how they can be >>>>> turned on or off independently in a meaningful way. I think it's >>>>> more confusing having all these separate subflags. >>>> Merging them up to a single flag would be OK with me. (And since >>>> it's diagnostic, I don't care too much what the name is.) >>> >>> The obvious name is EnableJSR292. The change is now much bigger but >>> almost all changes are trivial renames: >>> >>> http://cr.openjdk.java.net/~twisti/6817525/ >>> >>> I did a lot of testing with JRuby tests today and except a couple of >>> (expected) hiccups it looks good. >>> >>> -- Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110329/8df8cc37/attachment.html From tom.rodriguez at oracle.com Tue Mar 29 09:39:41 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 29 Mar 2011 09:39:41 -0700 Subject: Request for review (S): 6817525: turn on method handle functionality by default for JSR 292 In-Reply-To: <4D9209D4.5070401@oracle.com> References: <8242083B-D624-497F-BBB5-6B196B75AF0A@oracle.com> <98121B5B-3786-488B-AB18-1EFAEEB708AE@oracle.com> <3AA5B061-AB12-4EEB-9684-E9BF102D1563@oracle.com> <4D9201AF.3090605@oracle.com> <4D9204E6.5090903@oracle.com> <4D9209D4.5070401@oracle.com> Message-ID: <29660580-5624-46B9-9EE3-68AAD8787DC0@oracle.com> I don't think there's much to recommend EnableDynamic over just sticking with EnableInvokeDynamic. It's already well known to anyone doing JSR292 hacking and no one else should really ever know or care about its existence. tom On Mar 29, 2011, at 9:33 AM, Paul Hohensee wrote: > I'd say the same: EnableJSR292 is a JCP process memento. If, as Tom says, > you intend to enable all these features as a set, then I'd generify EnableInvokeDynamic > by replacing it with, say, EnableDynamic. The latter is non-specific enough to > cover the field and isn't tied to a specific JSR. > > Paul > > On 3/29/11 12:12 PM, John Pampuch wrote: >> I think I agree with Vladimir. The name JSR-292 is an anomaly of the process, and doesn't really communicate much. I don't think we generally use the JSR ID for similar choices elsewhere either. >> >> -John >> >> On 3/29/11 8:58 AM, Vladimir Kozlov wrote: >>> I would prefer the old EnableInvokeDynamic which is more informative I think. Otherwise looks good. >>> >>> Vladimir >>> >>> Christian Thalinger wrote: >>>> On Mar 28, 2011, at 11:14 PM, John Rose wrote: >>>>> On Mar 28, 2011, at 12:58 PM, Tom Rodriguez wrote: >>>>> >>>>>> Why do we need the related switches as separate flags at all? EnableInvokeDynamic is required for 7 and the others are all implied by EnableInvokeDynamic. I don't see how they can be turned on or off independently in a meaningful way. I think it's more confusing having all these separate subflags. >>>>> Merging them up to a single flag would be OK with me. (And since it's diagnostic, I don't care too much what the name is.) >>>> >>>> The obvious name is EnableJSR292. The change is now much bigger but almost all changes are trivial renames: >>>> >>>> http://cr.openjdk.java.net/~twisti/6817525/ >>>> >>>> I did a lot of testing with JRuby tests today and except a couple of (expected) hiccups it looks good. >>>> >>>> -- Christian From jesper.wilhelmsson at oracle.com Tue Mar 29 09:46:42 2011 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 29 Mar 2011 18:46:42 +0200 Subject: Request for review (S): 6817525: turn on method handle functionality by default for JSR 292 In-Reply-To: <4D9209D4.5070401@oracle.com> References: <8242083B-D624-497F-BBB5-6B196B75AF0A@oracle.com> <98121B5B-3786-488B-AB18-1EFAEEB708AE@oracle.com> <3AA5B061-AB12-4EEB-9684-E9BF102D1563@oracle.com> <4D9201AF.3090605@oracle.com> <4D9204E6.5090903@oracle.com> <4D9209D4.5070401@oracle.com> Message-ID: <4D920CF2.1050302@oracle.com> Paul, I have to disagree here, we can not have a flag called EnableDynamic. Dynamic what? The name doesn't say what the flag is used for. It could be anything from dynamic sizing of any given part of the VM to dynamic climate control. There must be a better name. /Jesper On 03/29/2011 06:33 PM, Paul Hohensee wrote: > I'd say the same: EnableJSR292 is a JCP process memento. If, as Tom says, > you intend to enable all these features as a set, then I'd generify > EnableInvokeDynamic > by replacing it with, say, EnableDynamic. The latter is non-specific enough to > cover the field and isn't tied to a specific JSR. > > Paul > > On 3/29/11 12:12 PM, John Pampuch wrote: >> I think I agree with Vladimir. The name JSR-292 is an anomaly of the >> process, and doesn't really communicate much. I don't think we generally use >> the JSR ID for similar choices elsewhere either. >> >> -John >> >> On 3/29/11 8:58 AM, Vladimir Kozlov wrote: >>> I would prefer the old EnableInvokeDynamic which is more informative I >>> think. Otherwise looks good. >>> >>> Vladimir >>> >>> Christian Thalinger wrote: >>>> On Mar 28, 2011, at 11:14 PM, John Rose wrote: >>>>> On Mar 28, 2011, at 12:58 PM, Tom Rodriguez wrote: >>>>> >>>>>> Why do we need the related switches as separate flags at all? >>>>>> EnableInvokeDynamic is required for 7 and the others are all implied by >>>>>> EnableInvokeDynamic. I don't see how they can be turned on or off >>>>>> independently in a meaningful way. I think it's more confusing having >>>>>> all these separate subflags. >>>>> Merging them up to a single flag would be OK with me. (And since it's >>>>> diagnostic, I don't care too much what the name is.) >>>> >>>> The obvious name is EnableJSR292. The change is now much bigger but almost >>>> all changes are trivial renames: >>>> >>>> http://cr.openjdk.java.net/~twisti/6817525/ >>>> >>>> I did a lot of testing with JRuby tests today and except a couple of >>>> (expected) hiccups it looks good. >>>> >>>> -- Christian From tom.rodriguez at oracle.com Tue Mar 29 09:48:44 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 29 Mar 2011 09:48:44 -0700 Subject: Request for review (S): 6817525: turn on method handle functionality by default for JSR 292 In-Reply-To: <4D9209D4.5070401@oracle.com> References: <8242083B-D624-497F-BBB5-6B196B75AF0A@oracle.com> <98121B5B-3786-488B-AB18-1EFAEEB708AE@oracle.com> <3AA5B061-AB12-4EEB-9684-E9BF102D1563@oracle.com> <4D9201AF.3090605@oracle.com> <4D9204E6.5090903@oracle.com> <4D9209D4.5070401@oracle.com> Message-ID: <8BA92ADF-1CFB-4777-B5E1-CED2B686E0A5@oracle.com> Additionally all our existing testing is turning it on using -XX:+EnableInvokeDynamic so unless we want to flag a flag day we should stick with that. I assume that EnableMethodHandles and AnonymousClasses aren't explicitly turned on as part of any of our testing? Otherwise we might want to accept them and convert them into EnableInvokeDynamic, at least for a little while to ease the transition. tom On Mar 29, 2011, at 9:33 AM, Paul Hohensee wrote: > I'd say the same: EnableJSR292 is a JCP process memento. If, as Tom says, > you intend to enable all these features as a set, then I'd generify EnableInvokeDynamic > by replacing it with, say, EnableDynamic. The latter is non-specific enough to > cover the field and isn't tied to a specific JSR. > > Paul > > On 3/29/11 12:12 PM, John Pampuch wrote: >> I think I agree with Vladimir. The name JSR-292 is an anomaly of the process, and doesn't really communicate much. I don't think we generally use the JSR ID for similar choices elsewhere either. >> >> -John >> >> On 3/29/11 8:58 AM, Vladimir Kozlov wrote: >>> I would prefer the old EnableInvokeDynamic which is more informative I think. Otherwise looks good. >>> >>> Vladimir >>> >>> Christian Thalinger wrote: >>>> On Mar 28, 2011, at 11:14 PM, John Rose wrote: >>>>> On Mar 28, 2011, at 12:58 PM, Tom Rodriguez wrote: >>>>> >>>>>> Why do we need the related switches as separate flags at all? EnableInvokeDynamic is required for 7 and the others are all implied by EnableInvokeDynamic. I don't see how they can be turned on or off independently in a meaningful way. I think it's more confusing having all these separate subflags. >>>>> Merging them up to a single flag would be OK with me. (And since it's diagnostic, I don't care too much what the name is.) >>>> >>>> The obvious name is EnableJSR292. The change is now much bigger but almost all changes are trivial renames: >>>> >>>> http://cr.openjdk.java.net/~twisti/6817525/ >>>> >>>> I did a lot of testing with JRuby tests today and except a couple of (expected) hiccups it looks good. >>>> >>>> -- Christian From christian.thalinger at oracle.com Tue Mar 29 09:55:22 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 29 Mar 2011 18:55:22 +0200 Subject: Request for review (S): 6817525: turn on method handle functionality by default for JSR 292 In-Reply-To: <8BA92ADF-1CFB-4777-B5E1-CED2B686E0A5@oracle.com> References: <8242083B-D624-497F-BBB5-6B196B75AF0A@oracle.com> <98121B5B-3786-488B-AB18-1EFAEEB708AE@oracle.com> <3AA5B061-AB12-4EEB-9684-E9BF102D1563@oracle.com> <4D9201AF.3090605@oracle.com> <4D9204E6.5090903@oracle.com> <4D9209D4.5070401@oracle.com> <8BA92ADF-1CFB-4777-B5E1-CED2B686E0A5@oracle.com> Message-ID: <555FDA71-32A1-418B-A44C-CC2DE1A67F4E@oracle.com> On Mar 29, 2011, at 6:48 PM, Tom Rodriguez wrote: > Additionally all our existing testing is turning it on using -XX:+EnableInvokeDynamic so unless we want to flag a flag day we should stick with that. I assume that EnableMethodHandles and AnonymousClasses aren't explicitly turned on as part of any of our testing? Otherwise we might want to accept them and convert them into EnableInvokeDynamic, at least for a little while to ease the transition. The jdk tests use EnableMethodHandles but not EnableInvokeDynamic: $ ack EnableMethodHandles jdk/test/ test/java/dyn/InvokeGenericTest.java 29: * @run junit/othervm -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles test.java.dyn.InvokeGenericTest test/java/dyn/JavaDocExamplesTest.java 29: * @run junit/othervm -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles test.java.dyn.JavaDocExamplesTest 37: -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles \ test/java/dyn/MethodHandlesTest.java 29: * @run junit/othervm -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles test.java.dyn.MethodHandlesTest test/java/dyn/MethodTypeTest.java 29: * @run junit/othervm -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles test.java.dyn.MethodTypeTest I don't know about other tests. -- Christian > > tom > > On Mar 29, 2011, at 9:33 AM, Paul Hohensee wrote: > >> I'd say the same: EnableJSR292 is a JCP process memento. If, as Tom says, >> you intend to enable all these features as a set, then I'd generify EnableInvokeDynamic >> by replacing it with, say, EnableDynamic. The latter is non-specific enough to >> cover the field and isn't tied to a specific JSR. >> >> Paul >> >> On 3/29/11 12:12 PM, John Pampuch wrote: >>> I think I agree with Vladimir. The name JSR-292 is an anomaly of the process, and doesn't really communicate much. I don't think we generally use the JSR ID for similar choices elsewhere either. >>> >>> -John >>> >>> On 3/29/11 8:58 AM, Vladimir Kozlov wrote: >>>> I would prefer the old EnableInvokeDynamic which is more informative I think. Otherwise looks good. >>>> >>>> Vladimir >>>> >>>> Christian Thalinger wrote: >>>>> On Mar 28, 2011, at 11:14 PM, John Rose wrote: >>>>>> On Mar 28, 2011, at 12:58 PM, Tom Rodriguez wrote: >>>>>> >>>>>>> Why do we need the related switches as separate flags at all? EnableInvokeDynamic is required for 7 and the others are all implied by EnableInvokeDynamic. I don't see how they can be turned on or off independently in a meaningful way. I think it's more confusing having all these separate subflags. >>>>>> Merging them up to a single flag would be OK with me. (And since it's diagnostic, I don't care too much what the name is.) >>>>> >>>>> The obvious name is EnableJSR292. The change is now much bigger but almost all changes are trivial renames: >>>>> >>>>> http://cr.openjdk.java.net/~twisti/6817525/ >>>>> >>>>> I did a lot of testing with JRuby tests today and except a couple of (expected) hiccups it looks good. >>>>> >>>>> -- Christian From dmytro_sheyko at hotmail.com Tue Mar 29 09:55:33 2011 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Tue, 29 Mar 2011 23:55:33 +0700 Subject: 7030249: Eliminate use of LoadLibrary and other clean-ups In-Reply-To: <4D91FF9E.1090003@oracle.com> References: , <4D91FF9E.1090003@oracle.com> Message-ID: Maybe we should follow this approach (i.e. prefer GetModuleHandleEx to GetModuleHandle) in other places as well. I found there suspect cases: ./jdk/src/windows/native/java/lang/java_props_md.c: GetModuleHandle(TEXT("kernel32.dll")), ./jdk/test/java/util/Locale/data/deflocale.c: HMODULE hmod = GetModuleHandle(L"kernel32"); ./hotspot/src/os/windows/vm/perfMemory_windows.cpp: GetProcAddress(GetModuleHandle(TEXT("advapi32.dll")), ./hotspot/src/os/windows/vm/os_windows.cpp: hmod = GetModuleHandle("NTDLL.DLL"); ./hotspot/src/os/windows/vm/os_windows.cpp: HMODULE hKernel32 = GetModuleHandle(TEXT("kernel32.dll")); ./hotspot/src/os/windows/vm/os_windows.cpp: HINSTANCE kernel32 = LoadLibrary("Kernel32.DLL") ; ./hotspot/src/os/windows/vm/os_windows.cpp: HINSTANCE psapi = LoadLibrary( "PSAPI.DLL" ) ; Regards, Dmytro Date: Tue, 29 Mar 2011 16:49:50 +0100 From: Alan.Bateman at oracle.com To: dmytro_sheyko at hotmail.com CC: core-libs-dev at openjdk.java.net Subject: Re: 7030249: Eliminate use of LoadLibrary and other clean-ups Message body Dmytro Sheyko wrote: : Why we obtain HMODULE for kernel32 this way: // get handle to kernel32 if (GetModuleHandleExW((GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS | GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT), (LPCWSTR)&CreateFileW, &h) != 0) { ... instead of handle = GetModuleHandle("kernel32"); GetModuleHandleExW allows you to provide the address of a function in the library that you need the handle for and so you avoid issues when multiple libraries with the same name are loaded. : Also according to MSDN GetModuleHandleEx requires at minimum "Windows XP" or "Windows Server 2003". It means that we do not support "Windows 2000", right? I don't think it's been possible to install or run jdk7 on Windows 2000 for some time. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110329/dcc01a09/attachment.html From paul.hohensee at oracle.com Tue Mar 29 10:01:59 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 29 Mar 2011 13:01:59 -0400 Subject: Request for review (S): 6817525: turn on method handle functionality by default for JSR 292 In-Reply-To: <29660580-5624-46B9-9EE3-68AAD8787DC0@oracle.com> References: <8242083B-D624-497F-BBB5-6B196B75AF0A@oracle.com> <98121B5B-3786-488B-AB18-1EFAEEB708AE@oracle.com> <3AA5B061-AB12-4EEB-9684-E9BF102D1563@oracle.com> <4D9201AF.3090605@oracle.com> <4D9204E6.5090903@oracle.com> <4D9209D4.5070401@oracle.com> <29660580-5624-46B9-9EE3-68AAD8787DC0@oracle.com> Message-ID: <4D921087.7080103@oracle.com> In that case, fine by me. Paul On 3/29/11 12:39 PM, Tom Rodriguez wrote: > I don't think there's much to recommend EnableDynamic over just sticking with EnableInvokeDynamic. It's already well known to anyone doing JSR292 hacking and no one else should really ever know or care about its existence. > > tom > > On Mar 29, 2011, at 9:33 AM, Paul Hohensee wrote: > >> I'd say the same: EnableJSR292 is a JCP process memento. If, as Tom says, >> you intend to enable all these features as a set, then I'd generify EnableInvokeDynamic >> by replacing it with, say, EnableDynamic. The latter is non-specific enough to >> cover the field and isn't tied to a specific JSR. >> >> Paul >> >> On 3/29/11 12:12 PM, John Pampuch wrote: >>> I think I agree with Vladimir. The name JSR-292 is an anomaly of the process, and doesn't really communicate much. I don't think we generally use the JSR ID for similar choices elsewhere either. >>> >>> -John >>> >>> On 3/29/11 8:58 AM, Vladimir Kozlov wrote: >>>> I would prefer the old EnableInvokeDynamic which is more informative I think. Otherwise looks good. >>>> >>>> Vladimir >>>> >>>> Christian Thalinger wrote: >>>>> On Mar 28, 2011, at 11:14 PM, John Rose wrote: >>>>>> On Mar 28, 2011, at 12:58 PM, Tom Rodriguez wrote: >>>>>> >>>>>>> Why do we need the related switches as separate flags at all? EnableInvokeDynamic is required for 7 and the others are all implied by EnableInvokeDynamic. I don't see how they can be turned on or off independently in a meaningful way. I think it's more confusing having all these separate subflags. >>>>>> Merging them up to a single flag would be OK with me. (And since it's diagnostic, I don't care too much what the name is.) >>>>> The obvious name is EnableJSR292. The change is now much bigger but almost all changes are trivial renames: >>>>> >>>>> http://cr.openjdk.java.net/~twisti/6817525/ >>>>> >>>>> I did a lot of testing with JRuby tests today and except a couple of (expected) hiccups it looks good. >>>>> >>>>> -- Christian From tom.rodriguez at oracle.com Tue Mar 29 10:58:13 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 29 Mar 2011 10:58:13 -0700 Subject: review (S) for 7031614: jmap -permstat fails with java.lang.InternalError in sun.jvm.hotspot.oops.OopField.getValue Message-ID: <4E47A281-4363-419A-B17E-62891E7FF90B@oracle.com> http://cr.openjdk.java.net/~never/7031614 7031614: jmap -permstat fails with java.lang.InternalError in sun.jvm.hotspot.oops.OopField.getValue Reviewed-by: There were some places that were finding static fields by iterating over the InstanceKlass object which I missed in my original changes. I added an iterateStaticFields that hides the owner the static fields and uses the OopVisitor.getObj to return the proper object. I inspected all the iterateFields call sites to make sure I didn't miss any. Additionally iteration of the mirror wasn't visiting the static fields so some roots might be missed by the reverse pointers analysis. There is heap iteration code in the SA and the InstanceMirrorKlass wasn't plugged into the the oop sizing logic in the SA which caused some searches to fail. I needed to add access to oop_size so I moved the java_lang_Class style utilities into their own class and made them like normal SA style classes. Tested with the full tmtools suite that showed these issues plus some other which don't appear to have been reported. From vladimir.kozlov at oracle.com Tue Mar 29 11:41:01 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Mar 2011 11:41:01 -0700 Subject: review (S) for 7031614: jmap -permstat fails with java.lang.InternalError in sun.jvm.hotspot.oops.OopField.getValue In-Reply-To: <4E47A281-4363-419A-B17E-62891E7FF90B@oracle.com> References: <4E47A281-4363-419A-B17E-62891E7FF90B@oracle.com> Message-ID: <4D9227BD.9020802@oracle.com> Looks good but I would not call it small (S) ;) ObjectHeap.java: 369 // lookup but since it's no used for these currently ^ not? InstanceMirrorKlass.java: why you need such spacing? 47 Type type = db.lookupType("instanceMirrorKlass"); java_lang_Class.java: 55 // klass and oop_size are a HotSpot magic field and hence we ^ ^ fields Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7031614 > > 7031614: jmap -permstat fails with java.lang.InternalError in sun.jvm.hotspot.oops.OopField.getValue > Reviewed-by: > > There were some places that were finding static fields by iterating > over the InstanceKlass object which I missed in my original changes. > I added an iterateStaticFields that hides the owner the static fields > and uses the OopVisitor.getObj to return the proper object. I > inspected all the iterateFields call sites to make sure I didn't miss > any. Additionally iteration of the mirror wasn't visiting the static > fields so some roots might be missed by the reverse pointers analysis. > There is heap iteration code in the SA and the InstanceMirrorKlass > wasn't plugged into the the oop sizing logic in the SA which caused > some searches to fail. I needed to add access to oop_size so I moved > the java_lang_Class style utilities into their own class and made them > like normal SA style classes. Tested with the full tmtools suite that > showed these issues plus some other which don't appear to have been > reported. > From christian.thalinger at oracle.com Tue Mar 29 11:41:27 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 29 Mar 2011 20:41:27 +0200 Subject: Request for review (S): 6817525: turn on method handle functionality by default for JSR 292 In-Reply-To: <8BA92ADF-1CFB-4777-B5E1-CED2B686E0A5@oracle.com> References: <8242083B-D624-497F-BBB5-6B196B75AF0A@oracle.com> <98121B5B-3786-488B-AB18-1EFAEEB708AE@oracle.com> <3AA5B061-AB12-4EEB-9684-E9BF102D1563@oracle.com> <4D9201AF.3090605@oracle.com> <4D9204E6.5090903@oracle.com> <4D9209D4.5070401@oracle.com> <8BA92ADF-1CFB-4777-B5E1-CED2B686E0A5@oracle.com> Message-ID: <5AA4DF7C-97DC-498F-BECC-B290EE33E7AB@oracle.com> On Mar 29, 2011, at 6:48 PM, Tom Rodriguez wrote: > Additionally all our existing testing is turning it on using -XX:+EnableInvokeDynamic so unless we want to flag a flag day we should stick with that. I assume that EnableMethodHandles and AnonymousClasses aren't explicitly turned on as part of any of our testing? Otherwise we might want to accept them and convert them into EnableInvokeDynamic, at least for a little while to ease the transition. I changed it to EnableInvokeDynamic and kept the other options which turn on EnableInvokeDynamic if true. But if we change EnableInvokeDynamic from an experimental to a diagnostic flag we will run into trouble with tests anyway: $ java -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic Unrecognized VM option '+EnableInvokeDynamic' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. -- Christian > > tom > > On Mar 29, 2011, at 9:33 AM, Paul Hohensee wrote: > >> I'd say the same: EnableJSR292 is a JCP process memento. If, as Tom says, >> you intend to enable all these features as a set, then I'd generify EnableInvokeDynamic >> by replacing it with, say, EnableDynamic. The latter is non-specific enough to >> cover the field and isn't tied to a specific JSR. >> >> Paul >> >> On 3/29/11 12:12 PM, John Pampuch wrote: >>> I think I agree with Vladimir. The name JSR-292 is an anomaly of the process, and doesn't really communicate much. I don't think we generally use the JSR ID for similar choices elsewhere either. >>> >>> -John >>> >>> On 3/29/11 8:58 AM, Vladimir Kozlov wrote: >>>> I would prefer the old EnableInvokeDynamic which is more informative I think. Otherwise looks good. >>>> >>>> Vladimir >>>> >>>> Christian Thalinger wrote: >>>>> On Mar 28, 2011, at 11:14 PM, John Rose wrote: >>>>>> On Mar 28, 2011, at 12:58 PM, Tom Rodriguez wrote: >>>>>> >>>>>>> Why do we need the related switches as separate flags at all? EnableInvokeDynamic is required for 7 and the others are all implied by EnableInvokeDynamic. I don't see how they can be turned on or off independently in a meaningful way. I think it's more confusing having all these separate subflags. >>>>>> Merging them up to a single flag would be OK with me. (And since it's diagnostic, I don't care too much what the name is.) >>>>> >>>>> The obvious name is EnableJSR292. The change is now much bigger but almost all changes are trivial renames: >>>>> >>>>> http://cr.openjdk.java.net/~twisti/6817525/ >>>>> >>>>> I did a lot of testing with JRuby tests today and except a couple of (expected) hiccups it looks good. >>>>> >>>>> -- Christian From vladimir.kozlov at oracle.com Tue Mar 29 11:47:14 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Mar 2011 11:47:14 -0700 Subject: Request for review (S): 6817525: turn on method handle functionality by default for JSR 292 In-Reply-To: <5AA4DF7C-97DC-498F-BECC-B290EE33E7AB@oracle.com> References: <8242083B-D624-497F-BBB5-6B196B75AF0A@oracle.com> <98121B5B-3786-488B-AB18-1EFAEEB708AE@oracle.com> <3AA5B061-AB12-4EEB-9684-E9BF102D1563@oracle.com> <4D9201AF.3090605@oracle.com> <4D9204E6.5090903@oracle.com> <4D9209D4.5070401@oracle.com> <8BA92ADF-1CFB-4777-B5E1-CED2B686E0A5@oracle.com> <5AA4DF7C-97DC-498F-BECC-B290EE33E7AB@oracle.com> Message-ID: <4D922932.5020509@oracle.com> It should be product flag from now on. Vladimir Christian Thalinger wrote: > On Mar 29, 2011, at 6:48 PM, Tom Rodriguez wrote: >> Additionally all our existing testing is turning it on using -XX:+EnableInvokeDynamic so unless we want to flag a flag day we should stick with that. I assume that EnableMethodHandles and AnonymousClasses aren't explicitly turned on as part of any of our testing? Otherwise we might want to accept them and convert them into EnableInvokeDynamic, at least for a little while to ease the transition. > > I changed it to EnableInvokeDynamic and kept the other options which turn on EnableInvokeDynamic if true. But if we change EnableInvokeDynamic from an experimental to a diagnostic flag we will run into trouble with tests anyway: > > $ java -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic > Unrecognized VM option '+EnableInvokeDynamic' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > -- Christian > >> tom >> >> On Mar 29, 2011, at 9:33 AM, Paul Hohensee wrote: >> >>> I'd say the same: EnableJSR292 is a JCP process memento. If, as Tom says, >>> you intend to enable all these features as a set, then I'd generify EnableInvokeDynamic >>> by replacing it with, say, EnableDynamic. The latter is non-specific enough to >>> cover the field and isn't tied to a specific JSR. >>> >>> Paul >>> >>> On 3/29/11 12:12 PM, John Pampuch wrote: >>>> I think I agree with Vladimir. The name JSR-292 is an anomaly of the process, and doesn't really communicate much. I don't think we generally use the JSR ID for similar choices elsewhere either. >>>> >>>> -John >>>> >>>> On 3/29/11 8:58 AM, Vladimir Kozlov wrote: >>>>> I would prefer the old EnableInvokeDynamic which is more informative I think. Otherwise looks good. >>>>> >>>>> Vladimir >>>>> >>>>> Christian Thalinger wrote: >>>>>> On Mar 28, 2011, at 11:14 PM, John Rose wrote: >>>>>>> On Mar 28, 2011, at 12:58 PM, Tom Rodriguez wrote: >>>>>>> >>>>>>>> Why do we need the related switches as separate flags at all? EnableInvokeDynamic is required for 7 and the others are all implied by EnableInvokeDynamic. I don't see how they can be turned on or off independently in a meaningful way. I think it's more confusing having all these separate subflags. >>>>>>> Merging them up to a single flag would be OK with me. (And since it's diagnostic, I don't care too much what the name is.) >>>>>> The obvious name is EnableJSR292. The change is now much bigger but almost all changes are trivial renames: >>>>>> >>>>>> http://cr.openjdk.java.net/~twisti/6817525/ >>>>>> >>>>>> I did a lot of testing with JRuby tests today and except a couple of (expected) hiccups it looks good. >>>>>> >>>>>> -- Christian > > From christian.thalinger at oracle.com Tue Mar 29 11:52:04 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 29 Mar 2011 20:52:04 +0200 Subject: Request for review (S): 6817525: turn on method handle functionality by default for JSR 292 In-Reply-To: <4D922932.5020509@oracle.com> References: <8242083B-D624-497F-BBB5-6B196B75AF0A@oracle.com> <98121B5B-3786-488B-AB18-1EFAEEB708AE@oracle.com> <3AA5B061-AB12-4EEB-9684-E9BF102D1563@oracle.com> <4D9201AF.3090605@oracle.com> <4D9204E6.5090903@oracle.com> <4D9209D4.5070401@oracle.com> <8BA92ADF-1CFB-4777-B5E1-CED2B686E0A5@oracle.com> <5AA4DF7C-97DC-498F-BECC-B290EE33E7AB@oracle.com> <4D922932.5020509@oracle.com> Message-ID: <5FF8FE73-9BDF-4339-AE2C-B5F1091C9B5D@oracle.com> On Mar 29, 2011, at 8:47 PM, Vladimir Kozlov wrote: > It should be product flag from now on. I agree. John wrote in an earlier email: "EnableInvokeDynamic and related switches may be useful for diagnostic testing, for root cause analysis. And they are needed to differentiate behavior of 1.6 from 1.7. But they are probably not useful as full product switches. Unless there's a reason against it, we should categorize them as diagnostic switches." But I seems there is a reason against it. -- Christian > > Vladimir > > Christian Thalinger wrote: >> On Mar 29, 2011, at 6:48 PM, Tom Rodriguez wrote: >>> Additionally all our existing testing is turning it on using -XX:+EnableInvokeDynamic so unless we want to flag a flag day we should stick with that. I assume that EnableMethodHandles and AnonymousClasses aren't explicitly turned on as part of any of our testing? Otherwise we might want to accept them and convert them into EnableInvokeDynamic, at least for a little while to ease the transition. >> I changed it to EnableInvokeDynamic and kept the other options which turn on EnableInvokeDynamic if true. But if we change EnableInvokeDynamic from an experimental to a diagnostic flag we will run into trouble with tests anyway: >> $ java -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic >> Unrecognized VM option '+EnableInvokeDynamic' >> Error: Could not create the Java Virtual Machine. >> Error: A fatal exception has occurred. Program will exit. >> -- Christian >>> tom >>> >>> On Mar 29, 2011, at 9:33 AM, Paul Hohensee wrote: >>> >>>> I'd say the same: EnableJSR292 is a JCP process memento. If, as Tom says, >>>> you intend to enable all these features as a set, then I'd generify EnableInvokeDynamic >>>> by replacing it with, say, EnableDynamic. The latter is non-specific enough to >>>> cover the field and isn't tied to a specific JSR. >>>> >>>> Paul >>>> >>>> On 3/29/11 12:12 PM, John Pampuch wrote: >>>>> I think I agree with Vladimir. The name JSR-292 is an anomaly of the process, and doesn't really communicate much. I don't think we generally use the JSR ID for similar choices elsewhere either. >>>>> >>>>> -John >>>>> >>>>> On 3/29/11 8:58 AM, Vladimir Kozlov wrote: >>>>>> I would prefer the old EnableInvokeDynamic which is more informative I think. Otherwise looks good. >>>>>> Vladimir >>>>>> Christian Thalinger wrote: >>>>>>> On Mar 28, 2011, at 11:14 PM, John Rose wrote: >>>>>>>> On Mar 28, 2011, at 12:58 PM, Tom Rodriguez wrote: >>>>>>>>> Why do we need the related switches as separate flags at all? EnableInvokeDynamic is required for 7 and the others are all implied by EnableInvokeDynamic. I don't see how they can be turned on or off independently in a meaningful way. I think it's more confusing having all these separate subflags. >>>>>>>> Merging them up to a single flag would be OK with me. (And since it's diagnostic, I don't care too much what the name is.) >>>>>>> The obvious name is EnableJSR292. The change is now much bigger but almost all changes are trivial renames: >>>>>>> http://cr.openjdk.java.net/~twisti/6817525/ >>>>>>> I did a lot of testing with JRuby tests today and except a couple of (expected) hiccups it looks good. >>>>>>> -- Christian From tom.rodriguez at oracle.com Tue Mar 29 13:58:19 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 29 Mar 2011 13:58:19 -0700 Subject: review (S) for 7031614: jmap -permstat fails with java.lang.InternalError in sun.jvm.hotspot.oops.OopField.getValue In-Reply-To: <4D9227BD.9020802@oracle.com> References: <4E47A281-4363-419A-B17E-62891E7FF90B@oracle.com> <4D9227BD.9020802@oracle.com> Message-ID: <90889F70-39B0-4FFF-B508-1B00F60E8929@oracle.com> On Mar 29, 2011, at 11:41 AM, Vladimir Kozlov wrote: > Looks good but I would not call it small (S) ;) > > ObjectHeap.java: > 369 // lookup but since it's no used for these currently > ^ not? > > InstanceMirrorKlass.java: why you need such spacing? > 47 Type type = db.lookupType("instanceMirrorKlass"); > > java_lang_Class.java: > 55 // klass and oop_size are a HotSpot magic field and hence we > ^ ^ fields I've fixed all those. Thanks. tom > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7031614 >> 7031614: jmap -permstat fails with java.lang.InternalError in sun.jvm.hotspot.oops.OopField.getValue >> Reviewed-by: >> There were some places that were finding static fields by iterating >> over the InstanceKlass object which I missed in my original changes. >> I added an iterateStaticFields that hides the owner the static fields >> and uses the OopVisitor.getObj to return the proper object. I >> inspected all the iterateFields call sites to make sure I didn't miss >> any. Additionally iteration of the mirror wasn't visiting the static >> fields so some roots might be missed by the reverse pointers analysis. >> There is heap iteration code in the SA and the InstanceMirrorKlass >> wasn't plugged into the the oop sizing logic in the SA which caused >> some searches to fail. I needed to add access to oop_size so I moved >> the java_lang_Class style utilities into their own class and made them >> like normal SA style classes. Tested with the full tmtools suite that >> showed these issues plus some other which don't appear to have been >> reported. From vladimir.kozlov at oracle.com Tue Mar 29 14:00:01 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Mar 2011 14:00:01 -0700 Subject: review (S) for 7031614: jmap -permstat fails with java.lang.InternalError in sun.jvm.hotspot.oops.OopField.getValue In-Reply-To: <90889F70-39B0-4FFF-B508-1B00F60E8929@oracle.com> References: <4E47A281-4363-419A-B17E-62891E7FF90B@oracle.com> <4D9227BD.9020802@oracle.com> <90889F70-39B0-4FFF-B508-1B00F60E8929@oracle.com> Message-ID: <4D924851.5070002@oracle.com> Good. Vladimir Tom Rodriguez wrote: > On Mar 29, 2011, at 11:41 AM, Vladimir Kozlov wrote: > >> Looks good but I would not call it small (S) ;) >> >> ObjectHeap.java: >> 369 // lookup but since it's no used for these currently >> ^ not? >> >> InstanceMirrorKlass.java: why you need such spacing? >> 47 Type type = db.lookupType("instanceMirrorKlass"); >> >> java_lang_Class.java: >> 55 // klass and oop_size are a HotSpot magic field and hence we >> ^ ^ fields > > I've fixed all those. Thanks. > > tom > >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7031614 >>> 7031614: jmap -permstat fails with java.lang.InternalError in sun.jvm.hotspot.oops.OopField.getValue >>> Reviewed-by: >>> There were some places that were finding static fields by iterating >>> over the InstanceKlass object which I missed in my original changes. >>> I added an iterateStaticFields that hides the owner the static fields >>> and uses the OopVisitor.getObj to return the proper object. I >>> inspected all the iterateFields call sites to make sure I didn't miss >>> any. Additionally iteration of the mirror wasn't visiting the static >>> fields so some roots might be missed by the reverse pointers analysis. >>> There is heap iteration code in the SA and the InstanceMirrorKlass >>> wasn't plugged into the the oop sizing logic in the SA which caused >>> some searches to fail. I needed to add access to oop_size so I moved >>> the java_lang_Class style utilities into their own class and made them >>> like normal SA style classes. Tested with the full tmtools suite that >>> showed these issues plus some other which don't appear to have been >>> reported. > From ahughes at redhat.com Tue Mar 29 15:44:52 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Tue, 29 Mar 2011 23:44:52 +0100 Subject: Is i686 the minimum required for HotSpot on x86? In-Reply-To: <92D1C49C-5F83-46DD-8F5C-4CB42C77C454@oracle.com> References: <20110329142606.GW6143@rivendell.middle-earth.co.uk> <92D1C49C-5F83-46DD-8F5C-4CB42C77C454@oracle.com> Message-ID: <20110329224450.GY6143@rivendell.middle-earth.co.uk> On 17:31 Tue 29 Mar , Christian Thalinger wrote: > On Mar 29, 2011, at 4:35 PM, Christian Thalinger wrote: > > On Mar 29, 2011, at 4:26 PM, Dr Andrew John Hughes wrote: > >> We've just had a bug report for IcedTea which suggests that > >> HotSpot fails on any x86 platform below i686. > >> > >> The report is: > >> > >> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=682 > >> > >> and shows a failure caused by an attempt by the JIT to emit > >> an instruction which isn't present on i586. > >> > >> Does HotSpot require i686 as a minimum? Or is there something > >> else at fault here? > > > > There is a switch -XX:+Use486InstrsOnly but I have an open bug for that one: > > > > 6808665: Use486InstrsOnly aborts 32-bit VM > > Looking a little closer this could actually be my fault. I added unguarded cmov instructions to C1 with: > > 6919934: JSR 292 needs to support x86 C1 > > http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3cf667df43ef > > And that was delivered in HS18b01. I will fix that. > > -- Christian Ah thanks for finding the issue! I await the fix. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Tue Mar 29 16:00:08 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 30 Mar 2011 00:00:08 +0100 Subject: Is i686 the minimum required for HotSpot on x86? In-Reply-To: <4D91F963.8080007@oracle.com> References: <20110329142606.GW6143@rivendell.middle-earth.co.uk> <4D91F963.8080007@oracle.com> Message-ID: <20110329230008.GZ6143@rivendell.middle-earth.co.uk> On 08:23 Tue 29 Mar , Vladimir Kozlov wrote: > Andrew, > > It would be nice to have call stack trace. I looked on attached hs_er* files and non of them has it. JIT (Client VM) > should not emit cmov instruction if it is not supported. Also there was suggestion in the report about running with > -Xint, did it help? I surprise someone still try to run Hotspot on i586 ;) I can't even find P4 around here. And we > definitely do not test on such machine (i586) so it is not supported. > I've prompted on the bug about the -Xint check. It sounds like twisti has found the issue anyway. I don't even have an x86 box I'd want to try compiling OpenJDK on. The only x86 box I still have is a 233MHz one I use for basic stuff like DNS, proxy, etc. and even that's i686. Presumably, someone else thought of this and that's why there's the switch twisti mentioned that allows you to only use certain instructions :-) > Vladimir > > On 3/29/11 7:26 AM, Dr Andrew John Hughes wrote: > > We've just had a bug report for IcedTea which suggests that > > HotSpot fails on any x86 platform below i686. > > > > The report is: > > > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=682 > > > > and shows a failure caused by an attempt by the JIT to emit > > an instruction which isn't present on i586. > > > > Does HotSpot require i686 as a minimum? Or is there something > > else at fault here? > > > > Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From tom.rodriguez at oracle.com Tue Mar 29 17:25:38 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 29 Mar 2011 17:25:38 -0700 Subject: review (XS) for 7032306: Fastdebug build failure on Solaris with SS11 compilers Message-ID: http://cr.openjdk.java.net/~never/7032306 7032306: Fastdebug build failure on Solaris with SS11 compilers Reviewed-by: CHECK_UNHANDLED_OOPS makes some expressions ambiguous with older compilers. The fix is to make the test against NULL explicit. Tested by building fastdebug with SS11 compilers. From erik.trimble at oracle.com Tue Mar 29 18:15:56 2011 From: erik.trimble at oracle.com (Erik Trimble) Date: Tue, 29 Mar 2011 18:15:56 -0700 Subject: Is i686 the minimum required for HotSpot on x86? In-Reply-To: <20110329230008.GZ6143@rivendell.middle-earth.co.uk> References: <20110329142606.GW6143@rivendell.middle-earth.co.uk> <4D91F963.8080007@oracle.com> <20110329230008.GZ6143@rivendell.middle-earth.co.uk> Message-ID: <4D92844C.8030207@oracle.com> On 3/29/2011 4:00 PM, Dr Andrew John Hughes wrote: > On 08:23 Tue 29 Mar , Vladimir Kozlov wrote: >> Andrew, >> >> It would be nice to have call stack trace. I looked on attached hs_er* files and non of them has it. JIT (Client VM) >> should not emit cmov instruction if it is not supported. Also there was suggestion in the report about running with >> -Xint, did it help? I surprise someone still try to run Hotspot on i586 ;) I can't even find P4 around here. And we >> definitely do not test on such machine (i586) so it is not supported. >> > I've prompted on the bug about the -Xint check. It sounds like twisti has found the issue anyway. > > I don't even have an x86 box I'd want to try compiling OpenJDK on. The only x86 box I still have is a 233MHz one > I use for basic stuff like DNS, proxy, etc. and even that's i686. Presumably, someone else thought of this and > that's why there's the switch twisti mentioned that allows you to only use certain instructions :-) > Actually, that brings up a good point. I can't think of any current x86 CPU that isn't a superset of i686. Are there any such beasts? I ask, simply because at some point, we (i.e. the community, not Oracle) should probably be making some statement/decision about minimum supported configuration. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA From tom.rodriguez at oracle.com Tue Mar 29 20:39:40 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 29 Mar 2011 20:39:40 -0700 Subject: review (XS) for 7032306: Fastdebug build failure on Solaris with SS11 compilers Message-ID: Resending... http://cr.openjdk.java.net/~never/7032306 7032306: Fastdebug build failure on Solaris with SS11 compilers Reviewed-by: CHECK_UNHANDLED_OOPS makes some expressions ambiguous with older compilers. The fix is to make the test against NULL explicit. Tested by building fastdebug with SS11 compilers. From igor.veresov at oracle.com Tue Mar 29 20:49:44 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 29 Mar 2011 20:49:44 -0700 Subject: review (XS) for 7032306: Fastdebug build failure on Solaris with SS11 compilers In-Reply-To: References: Message-ID: <4D92A858.1030002@oracle.com> Looks good. igor On 3/29/11 8:39 PM, Tom Rodriguez wrote: > Resending... > > http://cr.openjdk.java.net/~never/7032306 > > 7032306: Fastdebug build failure on Solaris with SS11 compilers > Reviewed-by: > > CHECK_UNHANDLED_OOPS makes some expressions ambiguous with older > compilers. The fix is to make the test against NULL explicit. Tested > by building fastdebug with SS11 compilers. > From vladimir.kozlov at oracle.com Tue Mar 29 21:29:23 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Mar 2011 21:29:23 -0700 Subject: review (XS) for 7032306: Fastdebug build failure on Solaris with SS11 compilers In-Reply-To: References: Message-ID: <4D92B1A3.9060207@oracle.com> Good. Vladimir On 3/29/11 8:39 PM, Tom Rodriguez wrote: > Resending... > > http://cr.openjdk.java.net/~never/7032306 > > 7032306: Fastdebug build failure on Solaris with SS11 compilers > Reviewed-by: > > CHECK_UNHANDLED_OOPS makes some expressions ambiguous with older > compilers. The fix is to make the test against NULL explicit. Tested > by building fastdebug with SS11 compilers. > From tom.rodriguez at oracle.com Tue Mar 29 22:05:37 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 29 Mar 2011 22:05:37 -0700 Subject: review (XS) for 7032306: Fastdebug build failure on Solaris with SS11 compilers In-Reply-To: <4D92B1A3.9060207@oracle.com> References: <4D92B1A3.9060207@oracle.com> Message-ID: <248A8166-8FAE-44F5-AE3D-5B507DA09ED6@oracle.com> Thanks Vladimir and Igor. tom On Mar 29, 2011, at 9:29 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 3/29/11 8:39 PM, Tom Rodriguez wrote: >> Resending... >> >> http://cr.openjdk.java.net/~never/7032306 >> >> 7032306: Fastdebug build failure on Solaris with SS11 compilers >> Reviewed-by: >> >> CHECK_UNHANDLED_OOPS makes some expressions ambiguous with older >> compilers. The fix is to make the test against NULL explicit. Tested >> by building fastdebug with SS11 compilers. >> From christian.thalinger at oracle.com Wed Mar 30 01:33:15 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 30 Mar 2011 10:33:15 +0200 Subject: Is i686 the minimum required for HotSpot on x86? In-Reply-To: <20110329224450.GY6143@rivendell.middle-earth.co.uk> References: <20110329142606.GW6143@rivendell.middle-earth.co.uk> <92D1C49C-5F83-46DD-8F5C-4CB42C77C454@oracle.com> <20110329224450.GY6143@rivendell.middle-earth.co.uk> Message-ID: <69823411-6A1B-4E78-8660-6EF1D1907352@oracle.com> On Mar 30, 2011, at 12:44 AM, Dr Andrew John Hughes wrote: > On 17:31 Tue 29 Mar , Christian Thalinger wrote: >> On Mar 29, 2011, at 4:35 PM, Christian Thalinger wrote: >>> On Mar 29, 2011, at 4:26 PM, Dr Andrew John Hughes wrote: >>>> We've just had a bug report for IcedTea which suggests that >>>> HotSpot fails on any x86 platform below i686. >>>> >>>> The report is: >>>> >>>> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=682 >>>> >>>> and shows a failure caused by an attempt by the JIT to emit >>>> an instruction which isn't present on i586. >>>> >>>> Does HotSpot require i686 as a minimum? Or is there something >>>> else at fault here? >>> >>> There is a switch -XX:+Use486InstrsOnly but I have an open bug for that one: >>> >>> 6808665: Use486InstrsOnly aborts 32-bit VM >> >> Looking a little closer this could actually be my fault. I added unguarded cmov instructions to C1 with: >> >> 6919934: JSR 292 needs to support x86 C1 >> >> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3cf667df43ef >> >> And that was delivered in HS18b01. I will fix that. >> >> -- Christian > > Ah thanks for finding the issue! I await the fix. 7032388: guarantee(VM_Version::supports_cmov()) failed: illegal instruction on i586 after 6919934 -- Christian From Dmitry.Samersoff at oracle.com Wed Mar 30 03:14:13 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 30 Mar 2011 14:14:13 +0400 Subject: Is i686 the minimum required for HotSpot on x86? In-Reply-To: <4D92844C.8030207@oracle.com> References: <20110329142606.GW6143@rivendell.middle-earth.co.uk> <4D91F963.8080007@oracle.com> <20110329230008.GZ6143@rivendell.middle-earth.co.uk> <4D92844C.8030207@oracle.com> Message-ID: <4D930275.4060609@oracle.com> Erik, Can't say for i686 superset but lots of x86 compatible CPUs (AMD K6, VIA Eden etc) primary used in embedded space doesn't have cmov instruction. So IMHO, we should care about it. -Dmitry On 2011-03-30 05:15, Erik Trimble wrote: > On 3/29/2011 4:00 PM, Dr Andrew John Hughes wrote: >> On 08:23 Tue 29 Mar , Vladimir Kozlov wrote: >>> Andrew, >>> >>> It would be nice to have call stack trace. I looked on attached >>> hs_er* files and non of them has it. JIT (Client VM) >>> should not emit cmov instruction if it is not supported. Also there >>> was suggestion in the report about running with >>> -Xint, did it help? I surprise someone still try to run Hotspot on >>> i586 ;) I can't even find P4 around here. And we >>> definitely do not test on such machine (i586) so it is not supported. >>> >> I've prompted on the bug about the -Xint check. It sounds like twisti >> has found the issue anyway. >> >> I don't even have an x86 box I'd want to try compiling OpenJDK on. The >> only x86 box I still have is a 233MHz one >> I use for basic stuff like DNS, proxy, etc. and even that's i686. >> Presumably, someone else thought of this and >> that's why there's the switch twisti mentioned that allows you to only >> use certain instructions :-) >> > > Actually, that brings up a good point. I can't think of any current x86 > CPU that isn't a superset of i686. > > Are there any such beasts? I ask, simply because at some point, we (i.e. > the community, not Oracle) should probably be making some > statement/decision about minimum supported configuration. > > > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From patrik.akerfeldt at gmail.com Wed Mar 30 06:13:51 2011 From: patrik.akerfeldt at gmail.com (=?ISO-8859-1?Q?Patrik_=C5kerfeldt?=) Date: Wed, 30 Mar 2011 15:13:51 +0200 Subject: Loading libraries on Linux Message-ID: I have this java application that uses a closed source third party java interface. This interface, in turn, loads a shared object from the system. The package delivering these shared object is installed separately and I do not want my java application to have knowledge about where it is installed (i.e. specify my own LD_LIBRARY_PATH). And so I tried to add the libraries to ld.so.conf.d/ and cache them with /sbin/ldconfig. We are running RHEL5 btw. The thing is that caching them with ldconfig has no effect at all. By looking at the byte code from the closed source java interface I see they load the libraries using System.loadLibrary(). Someone told me that System.loadLibrary() uses dlopen underneath (on Linux). To test this further, I wrote two very simple test tools, one in java that loads a library using System.loadLibrary() and another one in C which uses dlopen to load a library or void* dlhandle = dlopen(argv[1], RTLD_NOW); to be exact. Then I configured ldconfig with a folder containing libraries under /opt/somefolder/ and run the two tools. The Java application was unable to load the library whilst dlopen did the trick. Removing the folder from ldconfig and running again shows that none of them succeeds as expected. And furthermore, if I create a symbolic link (or just do a plain copy) of the library into /usr/lib, both dlopen and the Java application loads the library. I tried to work my way through the openjdk source to find the dlopen call but was unsuccessful. Can someone please tell me if the behavior I'm experiencing is expected? I'm happy to give further information if needed. Thanks, Patrik ?kerfeldt From paul.hohensee at oracle.com Wed Mar 30 07:13:00 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 30 Mar 2011 10:13:00 -0400 Subject: Is i686 the minimum required for HotSpot on x86? In-Reply-To: <4D930275.4060609@oracle.com> References: <20110329142606.GW6143@rivendell.middle-earth.co.uk> <4D91F963.8080007@oracle.com> <20110329230008.GZ6143@rivendell.middle-earth.co.uk> <4D92844C.8030207@oracle.com> <4D930275.4060609@oracle.com> Message-ID: <4D933A6C.4080609@oracle.com> I don't speak for Oracle, but we do indeed care about it as long as we ship the current version of Hotspot on operating systems that run on older chips. So we're treating the problem as a bug and will fix it. Paul On 3/30/11 6:14 AM, Dmitry Samersoff wrote: > Erik, > > Can't say for i686 superset but lots of x86 compatible CPUs (AMD K6, > VIA Eden etc) primary used in embedded space doesn't have cmov > instruction. > > So IMHO, we should care about it. > > -Dmitry > > On 2011-03-30 05:15, Erik Trimble wrote: >> On 3/29/2011 4:00 PM, Dr Andrew John Hughes wrote: >>> On 08:23 Tue 29 Mar , Vladimir Kozlov wrote: >>>> Andrew, >>>> >>>> It would be nice to have call stack trace. I looked on attached >>>> hs_er* files and non of them has it. JIT (Client VM) >>>> should not emit cmov instruction if it is not supported. Also there >>>> was suggestion in the report about running with >>>> -Xint, did it help? I surprise someone still try to run Hotspot on >>>> i586 ;) I can't even find P4 around here. And we >>>> definitely do not test on such machine (i586) so it is not supported. >>>> >>> I've prompted on the bug about the -Xint check. It sounds like twisti >>> has found the issue anyway. >>> >>> I don't even have an x86 box I'd want to try compiling OpenJDK on. The >>> only x86 box I still have is a 233MHz one >>> I use for basic stuff like DNS, proxy, etc. and even that's i686. >>> Presumably, someone else thought of this and >>> that's why there's the switch twisti mentioned that allows you to only >>> use certain instructions :-) >>> >> >> Actually, that brings up a good point. I can't think of any current x86 >> CPU that isn't a superset of i686. >> >> Are there any such beasts? I ask, simply because at some point, we (i.e. >> the community, not Oracle) should probably be making some >> statement/decision about minimum supported configuration. >> >> >> > > From christian.thalinger at oracle.com Wed Mar 30 07:25:29 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 30 Mar 2011 16:25:29 +0200 Subject: Request for review (S): 6817525: turn on method handle functionality by default for JSR 292 In-Reply-To: <5FF8FE73-9BDF-4339-AE2C-B5F1091C9B5D@oracle.com> References: <8242083B-D624-497F-BBB5-6B196B75AF0A@oracle.com> <98121B5B-3786-488B-AB18-1EFAEEB708AE@oracle.com> <3AA5B061-AB12-4EEB-9684-E9BF102D1563@oracle.com> <4D9201AF.3090605@oracle.com> <4D9204E6.5090903@oracle.com> <4D9209D4.5070401@oracle.com> <8BA92ADF-1CFB-4777-B5E1-CED2B686E0A5@oracle.com> <5AA4DF7C-97DC-498F-BECC-B290EE33E7AB@oracle.com> <4D922932.5020509@oracle.com> <5FF8FE73-9BDF-4339-AE2C-B5F1091C9B5D@oracle.com> Message-ID: On Mar 29, 2011, at 8:52 PM, Christian Thalinger wrote: > On Mar 29, 2011, at 8:47 PM, Vladimir Kozlov wrote: >> It should be product flag from now on. > > I agree. John wrote in an earlier email: > > "EnableInvokeDynamic and related switches may be useful for diagnostic testing, for root cause analysis. And they are needed to differentiate behavior of 1.6 from 1.7. But they are probably not useful as full product switches. Unless there's a reason against it, we should categorize them as diagnostic switches." > > But I seems there is a reason against it. Alright, there was more discussion about this and we go with a diagnostic flag. EnableMethodHandles and AnonymousClasses will be removed in the future when there was time to change testing. The webrev is updated and contains a little more context as comment. -- Christian From erik.trimble at oracle.com Wed Mar 30 07:34:57 2011 From: erik.trimble at oracle.com (Erik Trimble) Date: Wed, 30 Mar 2011 07:34:57 -0700 Subject: Is i686 the minimum required for HotSpot on x86? In-Reply-To: <4D933A6C.4080609@oracle.com> References: <20110329142606.GW6143@rivendell.middle-earth.co.uk> <4D91F963.8080007@oracle.com> <20110329230008.GZ6143@rivendell.middle-earth.co.uk> <4D92844C.8030207@oracle.com> <4D930275.4060609@oracle.com> <4D933A6C.4080609@oracle.com> Message-ID: <4D933F91.4080901@oracle.com> I was assuming that, Paul. Of course, the minimum supported OSes for JDK7 now have a *very* hard time running on a i586... In any case, Dmitry's comment is what I was after; that all said, we still should come up with some sort of baseline support ISA, whatever it is. In the same way that we have for SPARC, and should likely have for PPC, ARM, Power, and any other ISA that OpenJDK is intended to run on. We state this about OSes, we should state this about ISAs, too. -Erik On 3/30/2011 7:13 AM, Paul Hohensee wrote: > I don't speak for Oracle, but we do indeed care about it as long as we > ship > the current version of Hotspot on operating systems that run on older > chips. > So we're treating the problem as a bug and will fix it. > > Paul > > On 3/30/11 6:14 AM, Dmitry Samersoff wrote: >> Erik, >> >> Can't say for i686 superset but lots of x86 compatible CPUs (AMD K6, >> VIA Eden etc) primary used in embedded space doesn't have cmov >> instruction. >> >> So IMHO, we should care about it. >> >> -Dmitry >> >> On 2011-03-30 05:15, Erik Trimble wrote: >>> On 3/29/2011 4:00 PM, Dr Andrew John Hughes wrote: >>>> On 08:23 Tue 29 Mar , Vladimir Kozlov wrote: >>>>> Andrew, >>>>> >>>>> It would be nice to have call stack trace. I looked on attached >>>>> hs_er* files and non of them has it. JIT (Client VM) >>>>> should not emit cmov instruction if it is not supported. Also there >>>>> was suggestion in the report about running with >>>>> -Xint, did it help? I surprise someone still try to run Hotspot on >>>>> i586 ;) I can't even find P4 around here. And we >>>>> definitely do not test on such machine (i586) so it is not supported. >>>>> >>>> I've prompted on the bug about the -Xint check. It sounds like twisti >>>> has found the issue anyway. >>>> >>>> I don't even have an x86 box I'd want to try compiling OpenJDK on. The >>>> only x86 box I still have is a 233MHz one >>>> I use for basic stuff like DNS, proxy, etc. and even that's i686. >>>> Presumably, someone else thought of this and >>>> that's why there's the switch twisti mentioned that allows you to only >>>> use certain instructions :-) >>>> >>> >>> Actually, that brings up a good point. I can't think of any current x86 >>> CPU that isn't a superset of i686. >>> >>> Are there any such beasts? I ask, simply because at some point, we >>> (i.e. >>> the community, not Oracle) should probably be making some >>> statement/decision about minimum supported configuration. >>> >>> >>> >> >> -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA From daniel.daugherty at oracle.com Wed Mar 30 07:38:24 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 30 Mar 2011 08:38:24 -0600 Subject: review (S) for 7031614: jmap -permstat fails with java.lang.InternalError in sun.jvm.hotspot.oops.OopField.getValue In-Reply-To: <4E47A281-4363-419A-B17E-62891E7FF90B@oracle.com> References: <4E47A281-4363-419A-B17E-62891E7FF90B@oracle.com> Message-ID: <4D934060.5030904@oracle.com> Added serviceability-dev at ... since this affects SA code... On 3/29/2011 11:58 AM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7031614 > Please update copyright years as needed. I could be wrong here but some of what you've uncovered here appears to be applicable to older SA (pre-static field move). In particular the oop sizing stuff and static field visitation during mirror processing. Did you also get a chance to run the nsk.sajdi subsuite? Thumbs up. Dan agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java No comments. agent/src/share/classes/sun/jvm/hotspot/oops/Instance.java No comments. agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 478 - delete blank line? agent/src/share/classes/sun/jvm/hotspot/oops/InstanceMirrorKlass.java No comments. agent/src/share/classes/sun/jvm/hotspot/jdi/ClassObjectReferenceImpl.java No comments. agent/src/share/classes/sun/jvm/hotspot/oops/Oop.java No comments. agent/src/share/classes/sun/jvm/hotspot/oops/OopUtilities.java No comments. agent/src/share/classes/sun/jvm/hotspot/oops/java_lang_Class.java No comments. agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java No comments. agent/src/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java No comments. agent/src/share/classes/sun/jvm/hotspot/utilities/HeapGXLWriter.java No comments. agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java No comments. agent/src/share/classes/sun/jvm/hotspot/utilities/ReversePtrsAnalysis.java No comments. agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaFactoryImpl.java No comments. src/share/vm/oops/instanceMirrorKlass.hpp No comments. src/share/vm/runtime/vmStructs.cpp No comments. > 7031614: jmap -permstat fails with java.lang.InternalError in sun.jvm.hotspot.oops.OopField.getValue > Reviewed-by: > > There were some places that were finding static fields by iterating > over the InstanceKlass object which I missed in my original changes. > I added an iterateStaticFields that hides the owner the static fields > and uses the OopVisitor.getObj to return the proper object. I > inspected all the iterateFields call sites to make sure I didn't miss > any. Additionally iteration of the mirror wasn't visiting the static > fields so some roots might be missed by the reverse pointers analysis. > There is heap iteration code in the SA and the InstanceMirrorKlass > wasn't plugged into the the oop sizing logic in the SA which caused > some searches to fail. I needed to add access to oop_size so I moved > the java_lang_Class style utilities into their own class and made them > like normal SA style classes. Tested with the full tmtools suite that > showed these issues plus some other which don't appear to have been > reported. > > From tom.rodriguez at oracle.com Wed Mar 30 07:48:44 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 30 Mar 2011 07:48:44 -0700 Subject: review (S) for 7031614: jmap -permstat fails with java.lang.InternalError in sun.jvm.hotspot.oops.OopField.getValue In-Reply-To: <4D934060.5030904@oracle.com> References: <4E47A281-4363-419A-B17E-62891E7FF90B@oracle.com> <4D934060.5030904@oracle.com> Message-ID: <2587EB2C-B8CD-4599-93BD-70DF60321B11@oracle.com> On Mar 30, 2011, at 7:38 AM, Daniel D. Daugherty wrote: > Added serviceability-dev at ... since this affects SA code... > > > On 3/29/2011 11:58 AM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7031614 >> > > Please update copyright years as needed. I did. > > I could be wrong here but some of what you've uncovered here > appears to be applicable to older SA (pre-static field move). > In particular the oop sizing stuff and static field visitation > during mirror processing. It's not applicable to older ones. It used to get processed through the instance klass but when I moved them to Class they weren't being visited since I hadn't updated the SA. > > Did you also get a chance to run the nsk.sajdi subsuite? Yes. It was clean as well. None of these paths appear to be exercised by sajdi or I would have found it earlier. > > Thumbs up. Thanks! tom > > Dan > > > agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java > No comments. > > agent/src/share/classes/sun/jvm/hotspot/oops/Instance.java > No comments. > > agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java > line 478 - delete blank line? > > agent/src/share/classes/sun/jvm/hotspot/oops/InstanceMirrorKlass.java > No comments. > > agent/src/share/classes/sun/jvm/hotspot/jdi/ClassObjectReferenceImpl.java > No comments. > > agent/src/share/classes/sun/jvm/hotspot/oops/Oop.java > No comments. > > agent/src/share/classes/sun/jvm/hotspot/oops/OopUtilities.java > No comments. > > agent/src/share/classes/sun/jvm/hotspot/oops/java_lang_Class.java > No comments. > > agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java > No comments. > > agent/src/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java > No comments. > > agent/src/share/classes/sun/jvm/hotspot/utilities/HeapGXLWriter.java > No comments. > > agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java > No comments. > > agent/src/share/classes/sun/jvm/hotspot/utilities/ReversePtrsAnalysis.java > No comments. > > agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaFactoryImpl.java > No comments. > > src/share/vm/oops/instanceMirrorKlass.hpp > No comments. > > src/share/vm/runtime/vmStructs.cpp > No comments. > > >> 7031614: jmap -permstat fails with java.lang.InternalError in sun.jvm.hotspot.oops.OopField.getValue >> Reviewed-by: >> >> There were some places that were finding static fields by iterating >> over the InstanceKlass object which I missed in my original changes. >> I added an iterateStaticFields that hides the owner the static fields >> and uses the OopVisitor.getObj to return the proper object. I >> inspected all the iterateFields call sites to make sure I didn't miss >> any. Additionally iteration of the mirror wasn't visiting the static >> fields so some roots might be missed by the reverse pointers analysis. >> There is heap iteration code in the SA and the InstanceMirrorKlass >> wasn't plugged into the the oop sizing logic in the SA which caused >> some searches to fail. I needed to add access to oop_size so I moved >> the java_lang_Class style utilities into their own class and made them >> like normal SA style classes. Tested with the full tmtools suite that >> showed these issues plus some other which don't appear to have been >> reported. >> >> From daniel.daugherty at oracle.com Wed Mar 30 07:56:29 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 30 Mar 2011 08:56:29 -0600 Subject: review (S) for 7031614: jmap -permstat fails with java.lang.InternalError in sun.jvm.hotspot.oops.OopField.getValue In-Reply-To: <2587EB2C-B8CD-4599-93BD-70DF60321B11@oracle.com> References: <4E47A281-4363-419A-B17E-62891E7FF90B@oracle.com> <4D934060.5030904@oracle.com> <2587EB2C-B8CD-4599-93BD-70DF60321B11@oracle.com> Message-ID: <4D93449D.5070004@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110330/28a152b5/attachment.html From ahughes at redhat.com Wed Mar 30 09:26:39 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 30 Mar 2011 17:26:39 +0100 Subject: [PATCH REVIEW]: Include Shark code in the build again Message-ID: <20110330162639.GL6143@rivendell.middle-earth.co.uk> In this HotSpot change: changeset: 1932:f95d63e2154a user: stefank date: Tue Nov 23 13:22:55 2010 -0800 summary: 6989984: Use standard include model for Hospot changes are made to how the files to compile are collated in the Makefiles. Namely, this line is added: +CORE_PATHS := $(shell find $(GAMMADIR)/src/share/vm/* -type d \! \( -name adlc -o -name c1 -o -name gc_implementation -o -name opto -o -name shark -o -name libadt \)) which filters various configuration-specific files out, when compiling the list of core files to compile. Sadly, the Shark files are then never added back in, so it never gets built. Shark builds succeed but you don't get a Shark VM. This change (arrived at by both myself and Gary Benson separately): http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04-1/ fixes the issue by adding Shark back into the mix. Kelly, can you approve these build changes? Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From kelly.ohair at oracle.com Wed Mar 30 09:42:57 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 30 Mar 2011 09:42:57 -0700 Subject: [PATCH REVIEW]: Include Shark code in the build again In-Reply-To: <20110330162639.GL6143@rivendell.middle-earth.co.uk> References: <20110330162639.GL6143@rivendell.middle-earth.co.uk> Message-ID: On Mar 30, 2011, at 9:26 AM, Dr Andrew John Hughes wrote: > This change (arrived at by both myself and Gary Benson separately): > > http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04-1/ > > fixes the issue by adding Shark back into the mix. > > Kelly, can you approve these build changes? Looks fine to me. --- Although overall, I don't understand why someone used so many := assignments. I usually reserve := for special assignments that require a shell or complex evaluation. The := forces an expansion of the right side on the spot, so any later changes to the variables used on the right will have no impact on your variable. In Makefiles, that's usually what you don't want, but I suppose there are cases where that is expected. By using := all the time, you have created a specific order dependency on the variables, but whatever, ... -kto -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110330/6f2e7f92/attachment.html From ahughes at redhat.com Wed Mar 30 13:31:15 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 30 Mar 2011 21:31:15 +0100 Subject: [PATCH REVIEW]: Include Shark code in the build again In-Reply-To: References: <20110330162639.GL6143@rivendell.middle-earth.co.uk> Message-ID: <20110330203115.GA6143@rivendell.middle-earth.co.uk> On 09:42 Wed 30 Mar , Kelly O'Hair wrote: > > On Mar 30, 2011, at 9:26 AM, Dr Andrew John Hughes wrote: > > > This change (arrived at by both myself and Gary Benson separately): > > > > http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04-1/ > > > > fixes the issue by adding Shark back into the mix. > > > > Kelly, can you approve these build changes? > > Looks fine to me. > Thanks, so now I just need a HotSpot dev to give it a bug ID and push it through their JPRT thing... > --- > Although overall, I don't understand why someone used so many := assignments. > I usually reserve := for special assignments that require a shell or complex evaluation. > The := forces an expansion of the right side on the spot, so any later changes to the > variables used on the right will have no impact on your variable. In Makefiles, that's > usually what you don't want, but I suppose there are cases where that is expected. > By using := all the time, you have created a specific order dependency on the variables, but > whatever, ... > I've never really used := either, and I see your point, but that's not really something to change in this changeset :-) > -kto > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From karen.kinnear at oracle.com Wed Mar 30 23:57:47 2011 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Thu, 31 Mar 2011 06:57:47 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20110331065755.1FC3D4765A@hg.openjdk.java.net> Changeset: 74e790c48cd4 Author: sla Date: 2011-03-28 12:48 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/74e790c48cd4 7031571: Generate native VS2010 project files Reviewed-by: hosterda, stefank, brutisso ! make/windows/create.bat ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/rules.make ! src/share/tools/ProjectCreator/Util.java ! src/share/tools/ProjectCreator/WinGammaPlatform.java + src/share/tools/ProjectCreator/WinGammaPlatformVC10.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java Changeset: df553e4a797b Author: acorn Date: 2011-03-30 17:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/df553e4a797b Merge From mturk at redhat.com Thu Mar 31 02:33:47 2011 From: mturk at redhat.com (Mladen Turk) Date: Thu, 31 Mar 2011 11:33:47 +0200 Subject: [PATCH] Fix compile warnings due to duplicate name macros Message-ID: <4D944A7B.8020407@redhat.com> Hi, Patch fixes the compile warning: In file included from ../../../src/share/native/java/io/FileInputStream.c:38:0: ../../../src/solaris/native/java/io/io_util_md.h:68:0: warning: "SET_HANDLE" redefined ../../../src/share/javavm/include/typedefs.h:80:0: note: this is the location of the previous definition due to macros having the same name but different purpose. Patch is a trivial and just makes sure the macros don't have the same name. Regards -- ^TM -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jdk6-rmdupmacros.patch Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110331/0e1394f7/attachment.ksh From David.Holmes at oracle.com Thu Mar 31 03:15:35 2011 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 31 Mar 2011 20:15:35 +1000 Subject: [PATCH REVIEW]: Include Shark code in the build again In-Reply-To: <20110330203115.GA6143@rivendell.middle-earth.co.uk> References: <20110330162639.GL6143@rivendell.middle-earth.co.uk> <20110330203115.GA6143@rivendell.middle-earth.co.uk> Message-ID: <4D945447.1030906@oracle.com> Dr Andrew John Hughes said the following on 03/31/11 06:31: > On 09:42 Wed 30 Mar , Kelly O'Hair wrote: >> On Mar 30, 2011, at 9:26 AM, Dr Andrew John Hughes wrote: >> >>> This change (arrived at by both myself and Gary Benson separately): >>> >>> http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04-1/ >>> >>> fixes the issue by adding Shark back into the mix. >>> >>> Kelly, can you approve these build changes? >> Looks fine to me. >> > > Thanks, so now I just need a HotSpot dev to give it a bug ID and push it through > their JPRT thing... 7032775 filed ... working on the push David >> --- >> Although overall, I don't understand why someone used so many := assignments. >> I usually reserve := for special assignments that require a shell or complex evaluation. >> The := forces an expansion of the right side on the spot, so any later changes to the >> variables used on the right will have no impact on your variable. In Makefiles, that's >> usually what you don't want, but I suppose there are cases where that is expected. >> By using := all the time, you have created a specific order dependency on the variables, but >> whatever, ... >> > > I've never really used := either, and I see your point, but that's not really something to change > in this changeset :-) > >> -kto >> > From christian.thalinger at oracle.com Thu Mar 31 03:27:23 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 31 Mar 2011 12:27:23 +0200 Subject: Is i686 the minimum required for HotSpot on x86? In-Reply-To: <69823411-6A1B-4E78-8660-6EF1D1907352@oracle.com> References: <20110329142606.GW6143@rivendell.middle-earth.co.uk> <92D1C49C-5F83-46DD-8F5C-4CB42C77C454@oracle.com> <20110329224450.GY6143@rivendell.middle-earth.co.uk> <69823411-6A1B-4E78-8660-6EF1D1907352@oracle.com> Message-ID: On Mar 30, 2011, at 10:33 AM, Christian Thalinger wrote: > On Mar 30, 2011, at 12:44 AM, Dr Andrew John Hughes wrote: >> On 17:31 Tue 29 Mar , Christian Thalinger wrote: >>> On Mar 29, 2011, at 4:35 PM, Christian Thalinger wrote: >>>> On Mar 29, 2011, at 4:26 PM, Dr Andrew John Hughes wrote: >>>>> We've just had a bug report for IcedTea which suggests that >>>>> HotSpot fails on any x86 platform below i686. >>>>> >>>>> The report is: >>>>> >>>>> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=682 >>>>> >>>>> and shows a failure caused by an attempt by the JIT to emit >>>>> an instruction which isn't present on i586. >>>>> >>>>> Does HotSpot require i686 as a minimum? Or is there something >>>>> else at fault here? >>>> >>>> There is a switch -XX:+Use486InstrsOnly but I have an open bug for that one: >>>> >>>> 6808665: Use486InstrsOnly aborts 32-bit VM >>> >>> Looking a little closer this could actually be my fault. I added unguarded cmov instructions to C1 with: >>> >>> 6919934: JSR 292 needs to support x86 C1 >>> >>> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3cf667df43ef >>> >>> And that was delivered in HS18b01. I will fix that. >>> >>> -- Christian >> >> Ah thanks for finding the issue! I await the fix. > > 7032388: guarantee(VM_Version::supports_cmov()) failed: illegal instruction on i586 after 6919934 I case you haven't seen it: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/09f96c3ff1ad Can you apply that patch to IcedTea and ask the bug submitter to try again? -- Christian From ahughes at redhat.com Thu Mar 31 07:36:32 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 31 Mar 2011 15:36:32 +0100 Subject: [PATCH REVIEW]: Include Shark code in the build again In-Reply-To: <4D945447.1030906@oracle.com> References: <20110330162639.GL6143@rivendell.middle-earth.co.uk> <20110330203115.GA6143@rivendell.middle-earth.co.uk> <4D945447.1030906@oracle.com> Message-ID: <20110331143632.GR6143@rivendell.middle-earth.co.uk> On 20:15 Thu 31 Mar , David Holmes wrote: > Dr Andrew John Hughes said the following on 03/31/11 06:31: > > On 09:42 Wed 30 Mar , Kelly O'Hair wrote: > >> On Mar 30, 2011, at 9:26 AM, Dr Andrew John Hughes wrote: > >> > >>> This change (arrived at by both myself and Gary Benson separately): > >>> > >>> http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04-1/ > >>> > >>> fixes the issue by adding Shark back into the mix. > >>> > >>> Kelly, can you approve these build changes? > >> Looks fine to me. > >> > > > > Thanks, so now I just need a HotSpot dev to give it a bug ID and push it through > > their JPRT thing... > > 7032775 filed ... working on the push > Thanks David. > David > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Thu Mar 31 07:53:17 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 31 Mar 2011 15:53:17 +0100 Subject: Is i686 the minimum required for HotSpot on x86? In-Reply-To: References: <20110329142606.GW6143@rivendell.middle-earth.co.uk> <92D1C49C-5F83-46DD-8F5C-4CB42C77C454@oracle.com> <20110329224450.GY6143@rivendell.middle-earth.co.uk> <69823411-6A1B-4E78-8660-6EF1D1907352@oracle.com> Message-ID: <20110331145317.GX6143@rivendell.middle-earth.co.uk> On 12:27 Thu 31 Mar , Christian Thalinger wrote: > On Mar 30, 2011, at 10:33 AM, Christian Thalinger wrote: > > On Mar 30, 2011, at 12:44 AM, Dr Andrew John Hughes wrote: > >> On 17:31 Tue 29 Mar , Christian Thalinger wrote: > >>> On Mar 29, 2011, at 4:35 PM, Christian Thalinger wrote: > >>>> On Mar 29, 2011, at 4:26 PM, Dr Andrew John Hughes wrote: > >>>>> We've just had a bug report for IcedTea which suggests that > >>>>> HotSpot fails on any x86 platform below i686. > >>>>> > >>>>> The report is: > >>>>> > >>>>> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=682 > >>>>> > >>>>> and shows a failure caused by an attempt by the JIT to emit > >>>>> an instruction which isn't present on i586. > >>>>> > >>>>> Does HotSpot require i686 as a minimum? Or is there something > >>>>> else at fault here? > >>>> > >>>> There is a switch -XX:+Use486InstrsOnly but I have an open bug for that one: > >>>> > >>>> 6808665: Use486InstrsOnly aborts 32-bit VM > >>> > >>> Looking a little closer this could actually be my fault. I added unguarded cmov instructions to C1 with: > >>> > >>> 6919934: JSR 292 needs to support x86 C1 > >>> > >>> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3cf667df43ef > >>> > >>> And that was delivered in HS18b01. I will fix that. > >>> > >>> -- Christian > >> > >> Ah thanks for finding the issue! I await the fix. > > > > 7032388: guarantee(VM_Version::supports_cmov()) failed: illegal instruction on i586 after 6919934 > > I case you haven't seen it: > > http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/09f96c3ff1ad > > Can you apply that patch to IcedTea and ask the bug submitter to try again? > First part is already done :-) I'll try and get it approved for the 1.10.1 release on Monday, then it can get out in the distros. > -- Christian -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From tom.rodriguez at oracle.com Thu Mar 31 11:00:57 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 31 Mar 2011 11:00:57 -0700 Subject: review (S) for 7032129: Native memory usage grow unexpectedly for vm/oom/*InternedString tests Message-ID: http://cr.openjdk.java.net/~never/7032129 7032129: Native memory usage grow unexpectedly for vm/oom/*InternedString tests Reviewed-by: StringTable::verify uses as_unicode_string to verify the hash code we keep in the table but the only resource mark is outside the loop. This means that verification makes a copy of the entire StringTable in a resource area. Now that interned strings aren't in perm the StringTable can become as large as the Java heap which means verification can overflow the address space. The fix is to compute the hash directly from the char[] instead of making a copy. I moved the hash_string logic into java_lang_String and updated the users appropriately. Tested with test case that allocates interned strings until we run out of heap. From vladimir.kozlov at oracle.com Thu Mar 31 11:12:48 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Mar 2011 11:12:48 -0700 Subject: review (S) for 7032129: Native memory usage grow unexpectedly for vm/oom/*InternedString tests In-Reply-To: References: Message-ID: <4D94C420.4030605@oracle.com> Looks good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7032129 > > 7032129: Native memory usage grow unexpectedly for vm/oom/*InternedString tests > Reviewed-by: > > StringTable::verify uses as_unicode_string to verify the hash code we > keep in the table but the only resource mark is outside the loop. > This means that verification makes a copy of the entire StringTable in > a resource area. Now that interned strings aren't in perm the > StringTable can become as large as the Java heap which means > verification can overflow the address space. The fix is to compute > the hash directly from the char[] instead of making a copy. I moved > the hash_string logic into java_lang_String and updated the users > appropriately. Tested with test case that allocates interned strings > until we run out of heap. > From keith.mcguigan at oracle.com Thu Mar 31 11:35:24 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Thu, 31 Mar 2011 14:35:24 -0400 Subject: review (S) for 7032129: Native memory usage grow unexpectedly for vm/oom/*InternedString tests In-Reply-To: References: Message-ID: <801E9AA1-CC98-4CF0-B07A-74AAF05DE4DC@oracle.com> Looks good. On Mar 31, 2011, at 2:00 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7032129 > > 7032129: Native memory usage grow unexpectedly for vm/oom/ > *InternedString tests > Reviewed-by: > > StringTable::verify uses as_unicode_string to verify the hash code we > keep in the table but the only resource mark is outside the loop. > This means that verification makes a copy of the entire StringTable in > a resource area. Now that interned strings aren't in perm the > StringTable can become as large as the Java heap which means > verification can overflow the address space. The fix is to compute > the hash directly from the char[] instead of making a copy. I moved > the hash_string logic into java_lang_String and updated the users > appropriately. Tested with test case that allocates interned strings > until we run out of heap. > From tom.rodriguez at oracle.com Thu Mar 31 11:39:12 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 31 Mar 2011 11:39:12 -0700 Subject: review (S) for 7032129: Native memory usage grow unexpectedly for vm/oom/*InternedString tests In-Reply-To: <801E9AA1-CC98-4CF0-B07A-74AAF05DE4DC@oracle.com> References: <801E9AA1-CC98-4CF0-B07A-74AAF05DE4DC@oracle.com> Message-ID: Thanks Keith and Vladimir. tom On Mar 31, 2011, at 11:35 AM, Keith McGuigan wrote: > > Looks good. > > On Mar 31, 2011, at 2:00 PM, Tom Rodriguez wrote: > >> http://cr.openjdk.java.net/~never/7032129 >> >> 7032129: Native memory usage grow unexpectedly for vm/oom/*InternedString tests >> Reviewed-by: >> >> StringTable::verify uses as_unicode_string to verify the hash code we >> keep in the table but the only resource mark is outside the loop. >> This means that verification makes a copy of the entire StringTable in >> a resource area. Now that interned strings aren't in perm the >> StringTable can become as large as the Java heap which means >> verification can overflow the address space. The fix is to compute >> the hash directly from the char[] instead of making a copy. I moved >> the hash_string logic into java_lang_String and updated the users >> appropriately. Tested with test case that allocates interned strings >> until we run out of heap. >> > From John.Coomes at oracle.com Thu Mar 31 11:46:41 2011 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 31 Mar 2011 11:46:41 -0700 Subject: review (S) for 7032129: Native memory usage grow unexpectedly for vm/oom/*InternedString tests In-Reply-To: References: Message-ID: <19860.52241.303836.940343@oracle.com> Tom Rodriguez (tom.rodriguez at oracle.com) wrote: > http://cr.openjdk.java.net/~never/7032129 > > 7032129: Native memory usage grow unexpectedly for vm/oom/*InternedString tests > Reviewed-by: > > StringTable::verify uses as_unicode_string to verify the hash code we > keep in the table but the only resource mark is outside the loop. > This means that verification makes a copy of the entire StringTable in > a resource area. Now that interned strings aren't in perm the > StringTable can become as large as the Java heap which means > verification can overflow the address space. The fix is to compute > the hash directly from the char[] instead of making a copy. I moved > the hash_string logic into java_lang_String and updated the users > appropriately. Tested with test case that allocates interned strings > until we run out of heap. Looks good to me. -John From tom.rodriguez at oracle.com Thu Mar 31 12:02:46 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 31 Mar 2011 12:02:46 -0700 Subject: review (S) for 7032129: Native memory usage grow unexpectedly for vm/oom/*InternedString tests In-Reply-To: <19860.52241.303836.940343@oracle.com> References: <19860.52241.303836.940343@oracle.com> Message-ID: Thanks! tom On Mar 31, 2011, at 11:46 AM, John Coomes wrote: > Tom Rodriguez (tom.rodriguez at oracle.com) wrote: >> http://cr.openjdk.java.net/~never/7032129 >> >> 7032129: Native memory usage grow unexpectedly for vm/oom/*InternedString tests >> Reviewed-by: >> >> StringTable::verify uses as_unicode_string to verify the hash code we >> keep in the table but the only resource mark is outside the loop. >> This means that verification makes a copy of the entire StringTable in >> a resource area. Now that interned strings aren't in perm the >> StringTable can become as large as the Java heap which means >> verification can overflow the address space. The fix is to compute >> the hash directly from the char[] instead of making a copy. I moved >> the hash_string logic into java_lang_String and updated the users >> appropriately. Tested with test case that allocates interned strings >> until we run out of heap. > > Looks good to me. > > -John >