From chris.hegarty at oracle.com Sun Jan 1 03:54:21 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sun, 01 Jan 2012 11:54:21 +0000 Subject: hg: jdk8/tl/jdk: 7125055: ContentHandler.getContent API changed in error Message-ID: <20120101115447.590E647858@hg.openjdk.java.net> Changeset: 5aeefe0e5d8c Author: chegar Date: 2012-01-01 09:24 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5aeefe0e5d8c 7125055: ContentHandler.getContent API changed in error Reviewed-by: alanb ! src/share/classes/java/net/ContentHandler.java ! src/share/classes/sun/net/www/content/image/gif.java ! src/share/classes/sun/net/www/content/image/jpeg.java ! src/share/classes/sun/net/www/content/image/png.java ! src/share/classes/sun/net/www/content/image/x_xbitmap.java ! src/share/classes/sun/net/www/content/image/x_xpixmap.java From paul.hohensee at oracle.com Sun Jan 1 14:28:35 2012 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Sun, 01 Jan 2012 22:28:35 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7125934: Add a fast unordered timestamp capability to Hotspot on x86/x64 Message-ID: <20120101222837.D612B47859@hg.openjdk.java.net> Changeset: 7ab5f6318694 Author: phh Date: 2012-01-01 11:17 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7ab5f6318694 7125934: Add a fast unordered timestamp capability to Hotspot on x86/x64 Summary: Add rdtsc detection and inline generation. Reviewed-by: kamg, dholmes Contributed-by: karen.kinnear at oracle.com ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/os_bsd_x86.inline.hpp ! src/os_cpu/linux_x86/vm/os_linux_x86.hpp + src/os_cpu/linux_x86/vm/os_linux_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.hpp + src/os_cpu/solaris_x86/vm/os_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/os_cpu/solaris_x86/vm/solaris_x86_64.il ! src/os_cpu/windows_x86/vm/os_windows_x86.hpp + src/os_cpu/windows_x86/vm/os_windows_x86.inline.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp + src/share/vm/runtime/os_ext.hpp From kumar.x.srinivasan at oracle.com Tue Jan 3 08:29:04 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 03 Jan 2012 16:29:04 +0000 Subject: hg: jdk8/tl/jdk: 7123582: (launcher) display the -version and -XshowSettings Message-ID: <20120103162914.97A394785E@hg.openjdk.java.net> Changeset: 8952a5f494f9 Author: ksrini Date: 2012-01-03 08:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8952a5f494f9 7123582: (launcher) display the -version and -XshowSettings Reviewed-by: alanb ! src/share/bin/java.c ! test/tools/launcher/Settings.java From kumar.x.srinivasan at oracle.com Tue Jan 3 08:36:05 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 03 Jan 2012 16:36:05 +0000 Subject: hg: jdk8/tl/jdk: 7124443: (launcher) test DefaultsLocaleTest fails with Windows shells. Message-ID: <20120103163615.67A264785F@hg.openjdk.java.net> Changeset: 5e34726cb4bb Author: ksrini Date: 2012-01-03 08:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e34726cb4bb 7124443: (launcher) test DefaultsLocaleTest fails with Windows shells. Reviewed-by: darcy ! test/tools/launcher/DefaultLocaleTest.java - test/tools/launcher/DefaultLocaleTest.sh + test/tools/launcher/DefaultLocaleTestRun.java ! test/tools/launcher/TestHelper.java From jonathan.gibbons at oracle.com Tue Jan 3 11:37:41 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 03 Jan 2012 19:37:41 +0000 Subject: hg: jdk8/tl/langtools: 4881269: improve diagnostic for ill-formed tokens Message-ID: <20120103193744.D72C447860@hg.openjdk.java.net> Changeset: 7a836147b266 Author: jjg Date: 2012-01-03 11:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7a836147b266 4881269: improve diagnostic for ill-formed tokens Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/IllegalDot.java + test/tools/javac/parser/T4881269.java + test/tools/javac/parser/T4881269.out From john.coomes at oracle.com Tue Jan 3 13:07:43 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Tue, 03 Jan 2012 21:07:43 +0000 Subject: hg: hsx/hotspot-rt/langtools: 12 new changesets Message-ID: <20120103210813.1544947866@hg.openjdk.java.net> Changeset: 4822dfe0922b Author: ohair Date: 2011-12-12 08:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/4822dfe0922b 7119829: Adjust default jprt testing configuration Reviewed-by: alanb ! make/jprt.properties Changeset: 3809292620c9 Author: jjg Date: 2011-12-13 11:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/3809292620c9 7120736: refactor javac option handling Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/code/Source.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/file/Locations.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/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! 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/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/Options.java ! test/tools/javac/diags/examples/UnsupportedEncoding.java Changeset: 4e4fed1d02f9 Author: jjg Date: 2011-12-13 14:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/4e4fed1d02f9 7121164: renamed files not committed Reviewed-by: ksrini - src/share/classes/com/sun/tools/javac/main/JavacOption.java + src/share/classes/com/sun/tools/javac/main/Option.java + src/share/classes/com/sun/tools/javac/main/OptionHelper.java - src/share/classes/com/sun/tools/javac/main/OptionName.java - src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java Changeset: 4261dc8af622 Author: jjg Date: 2011-12-14 16:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/4261dc8af622 7111022: javac no long prints last round of processing 7121323: Sqe tests using -Xstdout option fail with an invalid flag error message Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! test/tools/javac/4846262/Test.sh + test/tools/javac/processing/options/testPrintProcessorInfo/TestWithXstdout.java ! test/tools/javac/util/T6597678.java Changeset: 281eeedf9755 Author: jjg Date: 2011-12-14 17:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/281eeedf9755 7121681: compiler message file broken for javac -fullversion Reviewed-by: jjh ! src/share/classes/com/sun/tools/javac/main/Option.java Changeset: 42ffceeceeca Author: jjg Date: 2011-12-14 21:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/42ffceeceeca 7121682: remove obsolete import Reviewed-by: jjh ! test/tools/javac/api/T6838467.java Changeset: ab2a880cc23b Author: lana Date: 2011-12-15 19:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/ab2a880cc23b Merge Changeset: 6b773fdeb633 Author: jjg Date: 2011-12-16 13:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/6b773fdeb633 7121961: javadoc is missing a resource property Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties Changeset: a7a2720c7897 Author: jjh Date: 2011-12-16 16:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/a7a2720c7897 7122342: testPrintProcessorInfo/TestWithXstdout.java failed for JDK8 nightly build at 12/16/2011 Summary: Do not pass empty args to javac Reviewed-by: jjg ! test/tools/javac/processing/options/testPrintProcessorInfo/TestWithXstdout.java Changeset: 1ae5988e201b Author: mcimadamore Date: 2011-12-19 12:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/1ae5988e201b 7120463: Fix method reference parser support in order to avoid ambiguities Summary: Add lookahead routine to disambiguate between method reference in method context and binary expression Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/tools/javac/lambda/MethodReferenceParserTest.java Changeset: 77b2c066084c Author: lana Date: 2011-12-23 16:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/77b2c066084c Merge - src/share/classes/com/sun/tools/javac/main/JavacOption.java - src/share/classes/com/sun/tools/javac/main/OptionName.java - src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java Changeset: ffd294128a48 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/ffd294128a48 Added tag jdk8-b19 for changeset 77b2c066084c ! .hgtags From jim.holmlund at sun.com Tue Jan 3 17:19:06 2012 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Wed, 04 Jan 2012 01:19:06 +0000 Subject: hg: jdk8/tl/langtools: 7046929: tools/javac/api/T6397104.java fails Message-ID: <20120104011908.8E5474786C@hg.openjdk.java.net> Changeset: a07eef109532 Author: jjh Date: 2012-01-03 17:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a07eef109532 7046929: tools/javac/api/T6397104.java fails Reviewed-by: jjg ! test/tools/javac/api/T6397104.java From frederic.parain at oracle.com Wed Jan 4 05:26:27 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Wed, 04 Jan 2012 13:26:27 +0000 Subject: hg: jdk8/tl/jdk: 7104647: Adding a diagnostic command framework Message-ID: <20120104132648.F151947874@hg.openjdk.java.net> Changeset: 0194fe5ca404 Author: fparain Date: 2012-01-04 03:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0194fe5ca404 7104647: Adding a diagnostic command framework Reviewed-by: mchung, dholmes ! make/common/Release.gmk ! make/java/management/mapfile-vers ! make/launchers/Makefile ! make/sun/tools/Makefile + src/linux/doc/man/jcmd.1 + src/share/classes/com/sun/management/DiagnosticCommandArgumentInfo.java + src/share/classes/com/sun/management/DiagnosticCommandInfo.java ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java + src/share/classes/sun/tools/jcmd/Arguments.java + src/share/classes/sun/tools/jcmd/JCmd.java ! src/share/javavm/export/jmm.h ! src/share/native/sun/management/HotSpotDiagnostic.c + src/solaris/doc/sun/man/man1/jcmd.1 + test/com/sun/management/HotSpotDiagnosticMXBean/ExecuteDiagnosticCommand.java + test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommandInfo.java + test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommands.java ! test/sun/tools/common/CommonSetup.sh + test/sun/tools/jcmd/dcmd-script.txt + test/sun/tools/jcmd/help_help.out + test/sun/tools/jcmd/jcmd-Defaults.sh + test/sun/tools/jcmd/jcmd-f.sh + test/sun/tools/jcmd/jcmd-help-help.sh + test/sun/tools/jcmd/jcmd-help.sh + test/sun/tools/jcmd/jcmd-pid.sh + test/sun/tools/jcmd/jcmd_Output1.awk + test/sun/tools/jcmd/jcmd_pid_Output1.awk + test/sun/tools/jcmd/jcmd_pid_Output2.awk + test/sun/tools/jcmd/usage.out From paul.hohensee at oracle.com Wed Jan 4 14:09:42 2012 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Wed, 04 Jan 2012 22:09:42 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7126185: Clean up lasterror handling, add os::get_last_error() Message-ID: <20120104220945.25D4B47881@hg.openjdk.java.net> Changeset: b16494a69d3d Author: phh Date: 2012-01-03 15:11 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b16494a69d3d 7126185: Clean up lasterror handling, add os::get_last_error() Summary: Add os::get_last_error(), replace getLastErrorString() by os::lasterror() in os_windows.cpp. Reviewed-by: kamg, dholmes Contributed-by: erik.gahlin at oracle.com ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp From frederic.parain at oracle.com Thu Jan 5 02:22:39 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 05 Jan 2012 11:22:39 +0100 Subject: RFR (XXS) : 7125594 C-heap growth issue in ThreadService::find_deadlocks_at_safepoint Message-ID: <4F0579EF.1050101@oracle.com> This is a very simple fix for a memory leak. The ThreadService::find_deadlocks_at_safepoint method leaks on DeadlockCycle object every time it is called. A DeadlockCycle object, referenced by the 'cycle' local variable, is pre-allocated and used to store blocked threads. If a deadlock is found, 'cycle' is added to the deadlock list (referenced by the 'deadlocks' local variable) and a new DeadlockCycle object is created and re-assign to the 'cycle' variable. Once all the threads have been processed, the deadlock list is returned, or NULL if no deadlock has been found. In both case, the last DeadlockCycle object that has been allocated, still referenced by 'cycle', is not returned to caller method nor deallocated, causing the memory leak. The fix is to call delete on the object pointed by 'cycle' before returning the result: http://cr.openjdk.java.net/~fparain/7125594/webrev.00/ I've already received positive reviews from Serguei Spitsyn, Dan Daugherty, Mandy Chung and David Holmes. Unless someone objects quickly, I'll proceed and push the fix. Thanks, Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Email: Frederic.Parain at Oracle.com From daniel.daugherty at oracle.com Thu Jan 5 07:08:08 2012 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Thu, 05 Jan 2012 15:08:08 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7127032: fix for 7122253 adds a JvmtiThreadState earlier than necessary Message-ID: <20120105150812.8E6C24789D@hg.openjdk.java.net> Changeset: 5b58979183f9 Author: dcubed Date: 2012-01-05 06:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5b58979183f9 7127032: fix for 7122253 adds a JvmtiThreadState earlier than necessary Summary: Use JavaThread::jvmti_thread_state() instead of JvmtiThreadState::state_for(). Reviewed-by: coleenp, poonam, acorn ! src/share/vm/classfile/classFileParser.cpp From frederic.parain at oracle.com Thu Jan 5 07:19:40 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 05 Jan 2012 16:19:40 +0100 Subject: Request for Review: 7120511: Add diagnostic commands Message-ID: <4F05BF8C.10602@oracle.com> This changeset aims to add a first set of diagnostic commands to the HotSpot JVM. It also includes minor modifications to the diagnostic command framework implementation to ease development of new diagnostic commands. The webrev is here: http://cr.openjdk.java.net/~fparain/7120511/webrev.00/ Here's the list of new diagnostic commands: Thread.print Print all threads with stacktraces. GC.class_histogram Provides statistics about the Java heap usage GC.heap_dump Generate a HPROF format dump of the Java heap GC.run_finalization Call java.lang.System.runFinalization(). GC.run Call java.lang.System.gc(). VM.uptime Print VM uptime. VM.flags Print VM flag options and their current values. VM.system_properties Print system properties VM.command_line Print the command line used to start this VM instance. Thanks, Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From karen.kinnear at oracle.com Thu Jan 5 08:19:28 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 5 Jan 2012 11:19:28 -0500 Subject: Request for Review: 7120511: Add diagnostic commands In-Reply-To: <4F05BF8C.10602@oracle.com> References: <4F05BF8C.10602@oracle.com> Message-ID: <24027BD1-A647-40FD-A806-4642298B7B53@oracle.com> Frederic, Code looks good. A couple of minor comments/questions: 1) diagnosticCommand.cpp HeapDumpDCmd::execute - There is a comment in attachListener under dump_heap that would be helpful to have here as well: // Request a full GC before heap dump if live_objects ... 2) I wonder if it would be helpful for the new jcmds that share functionality with existing mechanisms if it is worth a comment in the code noting where else this logic is called - might help future bug fixers do thorough testing. 3) attachListener jcmd You've added an out->cr() after throwing the exception here, but I wonder if you actually want it whether or not there was an exception thrown here - e.g. inside execute I see a number of places where there are print calls for exceptions and raw_print called - do those want the as well? Or are there cases where there is nothing printed so you would not want that? e.g. runFinalization? thanks, Karen On Jan 5, 2012, at 10:19 AM, Frederic Parain wrote: > This changeset aims to add a first set of diagnostic commands > to the HotSpot JVM. It also includes minor modifications to > the diagnostic command framework implementation to ease > development of new diagnostic commands. > > The webrev is here: > > http://cr.openjdk.java.net/~fparain/7120511/webrev.00/ > > > Here's the list of new diagnostic commands: > > Thread.print > Print all threads with stacktraces. > > GC.class_histogram > Provides statistics about the Java heap usage > > GC.heap_dump > Generate a HPROF format dump of the Java heap > > GC.run_finalization > Call java.lang.System.runFinalization(). > > GC.run > Call java.lang.System.gc(). > > VM.uptime > Print VM uptime. > > VM.flags > Print VM flag options and their current values. > > VM.system_properties > Print system properties > > VM.command_line > Print the command line used to start this VM instance. > > > Thanks, > > Fred > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > Email: Frederic.Parain at Oracle.com > From frederic.parain at oracle.com Thu Jan 5 09:47:27 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Thu, 05 Jan 2012 17:47:27 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7125594: C-heap growth issue in ThreadService::find_deadlocks_at_safepoint Message-ID: <20120105174731.2239F478A1@hg.openjdk.java.net> Changeset: 8a63c6323842 Author: fparain Date: 2012-01-05 07:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8a63c6323842 7125594: C-heap growth issue in ThreadService::find_deadlocks_at_safepoint Reviewed-by: sspitsyn, dcubed, mchung, dholmes ! src/share/vm/services/threadService.cpp From paul.hohensee at oracle.com Thu Jan 5 10:32:24 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 05 Jan 2012 13:32:24 -0500 Subject: Request for Review: 7120511: Add diagnostic commands In-Reply-To: <4F05BF8C.10602@oracle.com> References: <4F05BF8C.10602@oracle.com> Message-ID: <4F05ECB8.8020700@oracle.com> Looks good. Tiny things: In globals.hpp, you might take this opportunity to get rid of the default value for the withComments argument to printFlags. In diagnosticCommand.hpp, there's a few places with blanks between parens where the blanks should go away, vis. static const char* name( ) { ... } In diagnosticCommand.cpp, in PrintSystemProperties::execute(), the arguments to call_static don't seem to line up. Possibly a webrev artifact. Paul On 1/5/12 10:19 AM, Frederic Parain wrote: > This changeset aims to add a first set of diagnostic commands > to the HotSpot JVM. It also includes minor modifications to > the diagnostic command framework implementation to ease > development of new diagnostic commands. > > The webrev is here: > > http://cr.openjdk.java.net/~fparain/7120511/webrev.00/ > > > Here's the list of new diagnostic commands: > > Thread.print > Print all threads with stacktraces. > > GC.class_histogram > Provides statistics about the Java heap usage > > GC.heap_dump > Generate a HPROF format dump of the Java heap > > GC.run_finalization > Call java.lang.System.runFinalization(). > > GC.run > Call java.lang.System.gc(). > > VM.uptime > Print VM uptime. > > VM.flags > Print VM flag options and their current values. > > VM.system_properties > Print system properties > > VM.command_line > Print the command line used to start this VM instance. > > > Thanks, > > Fred > From daniel.daugherty at oracle.com Thu Jan 5 10:33:18 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 05 Jan 2012 11:33:18 -0700 Subject: Request for Review: 7120511: Add diagnostic commands In-Reply-To: <4F05BF8C.10602@oracle.com> References: <4F05BF8C.10602@oracle.com> Message-ID: <4F05ECEE.9060202@oracle.com> On 1/5/12 8:19 AM, Frederic Parain wrote: > This changeset aims to add a first set of diagnostic commands > to the HotSpot JVM. It also includes minor modifications to > the diagnostic command framework implementation to ease > development of new diagnostic commands. > > The webrev is here: > > http://cr.openjdk.java.net/~fparain/7120511/webrev.00/ Thumbs up! src/share/vm/classfile/vmSymbols.hpp No comments. src/share/vm/runtime/arguments.cpp No comments. src/share/vm/runtime/globals.cpp No comments. src/share/vm/runtime/globals.hpp No comments other than thanks for adding an explicit outputStream. src/share/vm/runtime/init.cpp No comments. src/share/vm/services/attachListener.cpp The "out->cr()" on line 162 should follow line 160 (I think). src/share/vm/services/diagnosticCommand.cpp No comments. src/share/vm/services/diagnosticCommand.hpp No comments. src/share/vm/services/diagnosticFramework.cpp No comments. src/share/vm/services/diagnosticFramework.hpp No comments. src/share/vm/services/management.cpp A comment above line 120 describing what the two boolean parameters to DCmdFactoryImp() mean would be helpful to the casual reader... Dan > > > Here's the list of new diagnostic commands: > > Thread.print > Print all threads with stacktraces. > > GC.class_histogram > Provides statistics about the Java heap usage > > GC.heap_dump > Generate a HPROF format dump of the Java heap > > GC.run_finalization > Call java.lang.System.runFinalization(). > > GC.run > Call java.lang.System.gc(). > > VM.uptime > Print VM uptime. > > VM.flags > Print VM flag options and their current values. > > VM.system_properties > Print system properties > > VM.command_line > Print the command line used to start this VM instance. > > > Thanks, > > Fred > From serguei.spitsyn at oracle.com Thu Jan 5 12:05:07 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 05 Jan 2012 12:05:07 -0800 Subject: Request for Review: 7120511: Add diagnostic commands In-Reply-To: <4F05BF8C.10602@oracle.com> References: <4F05BF8C.10602@oracle.com> Message-ID: <4F060273.8090503@oracle.com> Looks good. Some minor comments. share/vm/services/diagnosticCommand.hpp Format of description() return is not consistent: - Some have dot at the end, some - not. - Some has an extra space. 72 return "Print the command line used to start this VM instance."; 86 return "Print system properties"; 102 return "Print VM flag options and their current values. "; 166 return "Generate a HPROF format dump of the Java heap"; 185 return "Provide statistics about the Java heap usage"; Should the impact() function result be formatted the same way as description() - to have or not have dot at the end ? The following lines are incorrectly indented: 85 static const char* description() { 86 return "Print system properties"; 87 } 88 static const char* impact() { 89 return "Low:"; 90 } 131 static const char* description() { 132 return "Call java.lang.System.gc()."; 133 } 134 static const char* impact() { 135 return "Medium: Depends on Java heap size and content"; 136 } 145 static const char* description() { 146 return "Call java.lang.System.runFinalization()."; 147 } 148 static const char* impact() { 149 return "Medium: Depends on Java content"; 150 } Thanks, Serguei On 1/5/12 7:19 AM, Frederic Parain wrote: > This changeset aims to add a first set of diagnostic commands > to the HotSpot JVM. It also includes minor modifications to > the diagnostic command framework implementation to ease > development of new diagnostic commands. > > The webrev is here: > > http://cr.openjdk.java.net/~fparain/7120511/webrev.00/ > > > Here's the list of new diagnostic commands: > > Thread.print > Print all threads with stacktraces. > > GC.class_histogram > Provides statistics about the Java heap usage > > GC.heap_dump > Generate a HPROF format dump of the Java heap > > GC.run_finalization > Call java.lang.System.runFinalization(). > > GC.run > Call java.lang.System.gc(). > > VM.uptime > Print VM uptime. > > VM.flags > Print VM flag options and their current values. > > VM.system_properties > Print system properties > > VM.command_line > Print the command line used to start this VM instance. > > > Thanks, > > Fred > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120105/3c2106d2/attachment.html From paul.hohensee at oracle.com Thu Jan 5 17:12:50 2012 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Fri, 06 Jan 2012 01:12:50 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20120106011256.2B6AE478AC@hg.openjdk.java.net> Changeset: 2e0ef19fc891 Author: phh Date: 2012-01-05 17:14 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2e0ef19fc891 7126480: Make JVM start time in milliseconds since the Java epoch available Summary: Expose existing Management::_begin_vm_creation_time via new accessor Management::begin_vm_creation_time(). Reviewed-by: acorn, dcubed ! src/share/vm/services/management.hpp Changeset: 66259eca2bf7 Author: phh Date: 2012-01-05 17:16 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/66259eca2bf7 Merge From david.holmes at oracle.com Thu Jan 5 18:19:38 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 06 Jan 2012 12:19:38 +1000 Subject: Request for Review: 7120511: Add diagnostic commands In-Reply-To: <4F05BF8C.10602@oracle.com> References: <4F05BF8C.10602@oracle.com> Message-ID: <4F065A3A.2080207@oracle.com> Hi Fred, Curious about one thing. For the uptime, how does this: + void VMUptimeDCmd::execute(TRAPS) { + if (_date.value()) { + output()->date_stamp(true, "", ": "); + } + output()->time_stamp().update_to(tty->time_stamp().ticks()); + output()->stamp(); + output()->print_cr(" s"); + } compare to simply doing "current time - VM start time" ? I guess the difference will be the difference between when os::elapsed_counter() was initialized and the VM start time is initialized. But the above seems a very non-obvious way of getting the uptime. David ----- On 6/01/2012 1:19 AM, Frederic Parain wrote: > This changeset aims to add a first set of diagnostic commands > to the HotSpot JVM. It also includes minor modifications to > the diagnostic command framework implementation to ease > development of new diagnostic commands. > > The webrev is here: > > http://cr.openjdk.java.net/~fparain/7120511/webrev.00/ > > > Here's the list of new diagnostic commands: > > Thread.print > Print all threads with stacktraces. > > GC.class_histogram > Provides statistics about the Java heap usage > > GC.heap_dump > Generate a HPROF format dump of the Java heap > > GC.run_finalization > Call java.lang.System.runFinalization(). > > GC.run > Call java.lang.System.gc(). > > VM.uptime > Print VM uptime. > > VM.flags > Print VM flag options and their current values. > > VM.system_properties > Print system properties > > VM.command_line > Print the command line used to start this VM instance. > > > Thanks, > > Fred > From john.coomes at oracle.com Thu Jan 5 21:04:16 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 06 Jan 2012 05:04:16 +0000 Subject: hg: hsx/hotspot-rt: Added tag jdk8-b20 for changeset 5a5eaf6374bc Message-ID: <20120106050416.DDFC8478C5@hg.openjdk.java.net> Changeset: cc771d92284f Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/cc771d92284f Added tag jdk8-b20 for changeset 5a5eaf6374bc ! .hgtags From john.coomes at oracle.com Thu Jan 5 21:04:23 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 06 Jan 2012 05:04:23 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b20 for changeset 51d8b6cb18c0 Message-ID: <20120106050425.E038E478C6@hg.openjdk.java.net> Changeset: f157fc2a71a3 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/f157fc2a71a3 Added tag jdk8-b20 for changeset 51d8b6cb18c0 ! .hgtags From john.coomes at oracle.com Thu Jan 5 21:04:32 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 06 Jan 2012 05:04:32 +0000 Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b20 for changeset f052abb8f374 Message-ID: <20120106050433.128E9478C7@hg.openjdk.java.net> Changeset: d41eeadf5c13 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/d41eeadf5c13 Added tag jdk8-b20 for changeset f052abb8f374 ! .hgtags From john.coomes at oracle.com Thu Jan 5 21:04:39 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 06 Jan 2012 05:04:39 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b20 for changeset 2b2818e3386f Message-ID: <20120106050439.C5124478C8@hg.openjdk.java.net> Changeset: dc2ee8b87884 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/dc2ee8b87884 Added tag jdk8-b20 for changeset 2b2818e3386f ! .hgtags From john.coomes at oracle.com Thu Jan 5 21:05:26 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 06 Jan 2012 05:05:26 +0000 Subject: hg: hsx/hotspot-rt/jdk: 9 new changesets Message-ID: <20120106050815.CF997478C9@hg.openjdk.java.net> Changeset: 172d70c50c65 Author: cgruszka Date: 2011-09-15 13:59 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/172d70c50c65 7066713: Separate demos from the bundles on Solaris and Linux Summary: add new license files to demos and samples, new directory for bundling Reviewed-by: katleman, ohair, billyh ! make/common/Release.gmk ! make/common/shared/Defs-control.gmk Changeset: eaf967fd25c5 Author: cgruszka Date: 2011-10-18 14:21 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/eaf967fd25c5 7099017: jdk7u2-dev does not build Summary: changes to skip demo/DEMOS_LICENSE and sample/SAMPLES_LICENSE when building OPENJDK Reviewed-by: ohair, billyh ! make/common/Release.gmk Changeset: 39b7f01203c9 Author: cgruszka Date: 2011-11-17 16:57 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/39b7f01203c9 Merge Changeset: b64e7263b4fd Author: cgruszka Date: 2011-11-18 01:03 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b64e7263b4fd Merge Changeset: e98869ff9f1e Author: cgruszka Date: 2011-12-05 12:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e98869ff9f1e Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: ffa36a6a46f5 Author: cgruszka Date: 2011-12-16 15:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ffa36a6a46f5 Merge - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h - src/solaris/classes/sun/awt/motif/AWTLockAccess.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h - src/solaris/native/sun/awt/awt_Cursor.h - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh Changeset: 5fe1525e6e2c Author: cgruszka Date: 2011-12-23 10:43 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5fe1525e6e2c Merge Changeset: 39e938cd1b82 Author: cgruszka Date: 2012-01-03 14:34 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/39e938cd1b82 Merge Changeset: fc050750f8a0 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/fc050750f8a0 Added tag jdk8-b20 for changeset 39e938cd1b82 ! .hgtags From frederic.parain at oracle.com Fri Jan 6 01:28:21 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 06 Jan 2012 10:28:21 +0100 Subject: Request for Review: 7120511: Add diagnostic commands In-Reply-To: <4F065A3A.2080207@oracle.com> References: <4F05BF8C.10602@oracle.com> <4F065A3A.2080207@oracle.com> Message-ID: <4F06BEB5.7060802@oracle.com> Hi David, I've considered that the uptime value should be consistent with other logging mechanisms in the VM tagging their output with uptime timestamp (namely, the gc log), so I used the same code to produce the uptime value. If the timestamp support in the outputStream class is modified, the gc log timestamps and the VMUptime timestamps will remain consistent. Fred On 01/ 6/12 03:19 AM, David Holmes wrote: > Hi Fred, > > Curious about one thing. For the uptime, how does this: > > + void VMUptimeDCmd::execute(TRAPS) { > + if (_date.value()) { > + output()->date_stamp(true, "", ": "); > + } > + output()->time_stamp().update_to(tty->time_stamp().ticks()); > + output()->stamp(); > + output()->print_cr(" s"); > + } > > compare to simply doing "current time - VM start time" ? I guess the > difference will be the difference between when os::elapsed_counter() was > initialized and the VM start time is initialized. But the above seems a > very non-obvious way of getting the uptime. > > David > ----- > > On 6/01/2012 1:19 AM, Frederic Parain wrote: >> This changeset aims to add a first set of diagnostic commands >> to the HotSpot JVM. It also includes minor modifications to >> the diagnostic command framework implementation to ease >> development of new diagnostic commands. >> >> The webrev is here: >> >> http://cr.openjdk.java.net/~fparain/7120511/webrev.00/ >> >> >> Here's the list of new diagnostic commands: >> >> Thread.print >> Print all threads with stacktraces. >> >> GC.class_histogram >> Provides statistics about the Java heap usage >> >> GC.heap_dump >> Generate a HPROF format dump of the Java heap >> >> GC.run_finalization >> Call java.lang.System.runFinalization(). >> >> GC.run >> Call java.lang.System.gc(). >> >> VM.uptime >> Print VM uptime. >> >> VM.flags >> Print VM flag options and their current values. >> >> VM.system_properties >> Print system properties >> >> VM.command_line >> Print the command line used to start this VM instance. >> >> >> Thanks, >> >> Fred >> -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From frederic.parain at oracle.com Fri Jan 6 04:15:29 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 06 Jan 2012 13:15:29 +0100 Subject: Request for Review: 7120511: Add diagnostic commands In-Reply-To: <24027BD1-A647-40FD-A806-4642298B7B53@oracle.com> References: <4F05BF8C.10602@oracle.com> <24027BD1-A647-40FD-A806-4642298B7B53@oracle.com> Message-ID: <4F06E5E1.7030705@oracle.com> Thanks for the review, my comments are inlined below. On 01/ 5/12 05:19 PM, Karen Kinnear wrote: > Frederic, > > Code looks good. > > A couple of minor comments/questions: > 1) diagnosticCommand.cpp HeapDumpDCmd::execute > - There is a comment in attachListener under dump_heap that would > be helpful to have here as well: // Request a full GC before heap dump if live_objects ... A comment has been added in diagnosticCommand.cpp and the help message of the HeapDumpDCmd has been updated too. > 2) I wonder if it would be helpful for the new jcmds that share functionality with existing mechanisms > if it is worth a comment in the code noting where else this logic is called - might > help future bug fixers do thorough testing. I've added cross-references in comments between the attachListener file and the diagnosticCommand file. > 3) attachListener jcmd > You've added an out->cr() after throwing the exception here, but I wonder if > you actually want it whether or not there was an exception thrown here - > e.g. inside execute I see a number of places where there are print calls for > exceptions and raw_print called - do those want the as well? > Or are there cases where there is nothing printed so you would not want that? e.g. runFinalization? The out->cr() in attachListener was correct, but other locations were an exception was printed were lacking an out->cr() call. It's fixed now. New webrev: http://cr.openjdk.java.net/~fparain/7120511/webrev.01/ Thank you, Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From frederic.parain at oracle.com Fri Jan 6 04:17:09 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 06 Jan 2012 13:17:09 +0100 Subject: Request for Review: 7120511: Add diagnostic commands In-Reply-To: <4F05ECB8.8020700@oracle.com> References: <4F05BF8C.10602@oracle.com> <4F05ECB8.8020700@oracle.com> Message-ID: <4F06E645.2000206@oracle.com> Thanks for the review, On 01/ 5/12 07:32 PM, Paul Hohensee wrote: > In globals.hpp, you might take this opportunity to get rid of the > default value for the withComments argument to printFlags. Done. > In diagnosticCommand.hpp, there's a few places with blanks > between parens where the blanks should go away, vis. > static const char* name( ) { ... } Fixed. > In diagnosticCommand.cpp, in PrintSystemProperties::execute(), > the arguments to call_static don't seem to line up. Possibly a > webrev artifact. It wasn't a webrev artifact, it's fixed now. New webrev: http://cr.openjdk.java.net/~fparain/7120511/webrev.01/ Thank you, Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From frederic.parain at oracle.com Fri Jan 6 04:19:04 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 06 Jan 2012 13:19:04 +0100 Subject: Request for Review: 7120511: Add diagnostic commands In-Reply-To: <4F05ECEE.9060202@oracle.com> References: <4F05BF8C.10602@oracle.com> <4F05ECEE.9060202@oracle.com> Message-ID: <4F06E6B8.6010602@oracle.com> Thanks for the review, I've addressed the following points: On 01/ 5/12 07:33 PM, Daniel D. Daugherty wrote: > src/share/vm/services/attachListener.cpp > The "out->cr()" on line 162 should follow line 160 (I think). Makes sense, fixed. > src/share/vm/services/management.cpp > A comment above line 120 describing what the two boolean parameters > to DCmdFactoryImp() mean would be helpful to the casual reader... Comment added. Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From frederic.parain at oracle.com Fri Jan 6 04:21:00 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 06 Jan 2012 13:21:00 +0100 Subject: Request for Review: 7120511: Add diagnostic commands In-Reply-To: <4F060273.8090503@oracle.com> References: <4F05BF8C.10602@oracle.com> <4F060273.8090503@oracle.com> Message-ID: <4F06E72C.60902@oracle.com> Thanks for the review, I've made consistent both the description strings and the impact strings. I've also fixed the indentation issue. New webrev: http://cr.openjdk.java.net/~fparain/7120511/webrev.01/ Regards, Fred On 01/ 5/12 09:05 PM, serguei.spitsyn at oracle.com wrote: > Looks good. > Some minor comments. > > share/vm/services/diagnosticCommand.hpp > > Format of description() return is not consistent: > - Some have dot at the end, some - not. > - Some has an extra space. > > 72 return "Print the command line used to start this VM instance."; > > 86 return "Print system properties"; > > 102 return "Print VM flag options and their current values. "; > > 166 return "Generate a HPROF format dump of the Java heap"; > > 185 return "Provide statistics about the Java heap usage"; > > > Should the impact() function result be formatted the same way as > description() > - to have or not have dot at the end ? > > The following lines are incorrectly indented: > > 85 static const char* description() { > 86 return "Print system properties"; > 87 } > 88 static const char* impact() { > 89 return "Low:"; > 90 } > > 131 static const char* description() { > 132 return "Call java.lang.System.gc()."; > 133 } > 134 static const char* impact() { > 135 return "Medium: Depends on Java heap size and content"; > 136 } > > 145 static const char* description() { > 146 return "Call java.lang.System.runFinalization()."; > 147 } > 148 static const char* impact() { > 149 return "Medium: Depends on Java content"; > 150 } > > > Thanks, > Serguei > > On 1/5/12 7:19 AM, Frederic Parain wrote: >> This changeset aims to add a first set of diagnostic commands >> to the HotSpot JVM. It also includes minor modifications to >> the diagnostic command framework implementation to ease >> development of new diagnostic commands. >> >> The webrev is here: >> >> http://cr.openjdk.java.net/~fparain/7120511/webrev.00/ >> >> >> Here's the list of new diagnostic commands: >> >> Thread.print >> Print all threads with stacktraces. >> >> GC.class_histogram >> Provides statistics about the Java heap usage >> >> GC.heap_dump >> Generate a HPROF format dump of the Java heap >> >> GC.run_finalization >> Call java.lang.System.runFinalization(). >> >> GC.run >> Call java.lang.System.gc(). >> >> VM.uptime >> Print VM uptime. >> >> VM.flags >> Print VM flag options and their current values. >> >> VM.system_properties >> Print system properties >> >> VM.command_line >> Print the command line used to start this VM instance. >> >> >> Thanks, >> >> Fred >> > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From paul.hohensee at oracle.com Fri Jan 6 04:33:01 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Fri, 06 Jan 2012 07:33:01 -0500 Subject: Request for Review: 7120511: Add diagnostic commands In-Reply-To: <4F06E645.2000206@oracle.com> References: <4F05BF8C.10602@oracle.com> <4F05ECB8.8020700@oracle.com> <4F06E645.2000206@oracle.com> Message-ID: <4F06E9FD.8000804@oracle.com> Looks good. Paul On 1/6/12 7:17 AM, Frederic Parain wrote: > Thanks for the review, > > On 01/ 5/12 07:32 PM, Paul Hohensee wrote: >> In globals.hpp, you might take this opportunity to get rid of the >> default value for the withComments argument to printFlags. > > Done. > >> In diagnosticCommand.hpp, there's a few places with blanks >> between parens where the blanks should go away, vis. >> static const char* name( ) { ... } > > Fixed. > >> In diagnosticCommand.cpp, in PrintSystemProperties::execute(), >> the arguments to call_static don't seem to line up. Possibly a >> webrev artifact. > > It wasn't a webrev artifact, it's fixed now. > > New webrev: http://cr.openjdk.java.net/~fparain/7120511/webrev.01/ > > Thank you, > > Fred > From alan.bateman at oracle.com Fri Jan 6 07:01:57 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 06 Jan 2012 15:01:57 +0000 Subject: hg: jdk8/tl/jdk: 7127235: (fs) NPE in Files.walkFileTree if cached attributes are GC'ed Message-ID: <20120106150224.844CE478CF@hg.openjdk.java.net> Changeset: 400cc379adb5 Author: alanb Date: 2012-01-06 15:00 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/400cc379adb5 7127235: (fs) NPE in Files.walkFileTree if cached attributes are GC'ed Reviewed-by: forax, chegar ! src/share/classes/java/nio/file/FileTreeWalker.java From daniel.daugherty at oracle.com Fri Jan 6 09:57:17 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 06 Jan 2012 10:57:17 -0700 Subject: Request for Review: 7120511: Add diagnostic commands In-Reply-To: <4F06E72C.60902@oracle.com> References: <4F05BF8C.10602@oracle.com> <4F060273.8090503@oracle.com> <4F06E72C.60902@oracle.com> Message-ID: <4F0735FD.1080807@oracle.com> On 1/6/12 5:21 AM, Frederic Parain wrote: > New webrev: http://cr.openjdk.java.net/~fparain/7120511/webrev.01/ Thumbs up. Dan From valerie.peng at oracle.com Fri Jan 6 11:05:01 2012 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Fri, 06 Jan 2012 19:05:01 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120106190520.A8FB5478D2@hg.openjdk.java.net> Changeset: cdc128128044 Author: valeriep Date: 2012-01-05 18:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cdc128128044 6414899: P11Digest should support cloning Summary: Enhanced the PKCS11 Digest implementation to support cloning Reviewed-by: vinnie ! make/sun/security/pkcs11/mapfile-vers ! src/share/classes/sun/security/pkcs11/P11Digest.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java ! src/share/lib/security/sunpkcs11-solaris.cfg ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h + test/sun/security/pkcs11/MessageDigest/TestCloning.java Changeset: e6ef778c1df4 Author: valeriep Date: 2012-01-06 11:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e6ef778c1df4 Merge From serguei.spitsyn at oracle.com Fri Jan 6 14:29:47 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 06 Jan 2012 14:29:47 -0800 Subject: Request for Review: 7120511: Add diagnostic commands In-Reply-To: <4F06E72C.60902@oracle.com> References: <4F05BF8C.10602@oracle.com> <4F060273.8090503@oracle.com> <4F06E72C.60902@oracle.com> Message-ID: <4F0775DB.5040004@oracle.com> Thumbs up. Thanks, Serguei On 1/6/12 4:21 AM, Frederic Parain wrote: > Thanks for the review, > > I've made consistent both the description strings > and the impact strings. I've also fixed the indentation > issue. > > New webrev: http://cr.openjdk.java.net/~fparain/7120511/webrev.01/ > > Regards, > > Fred > > On 01/ 5/12 09:05 PM, serguei.spitsyn at oracle.com wrote: >> Looks good. >> Some minor comments. >> >> share/vm/services/diagnosticCommand.hpp >> >> Format of description() return is not consistent: >> - Some have dot at the end, some - not. >> - Some has an extra space. >> >> 72 return "Print the command line used to start this VM >> instance."; >> >> 86 return "Print system properties"; >> >> 102 return "Print VM flag options and their current values. "; >> >> 166 return "Generate a HPROF format dump of the Java heap"; >> >> 185 return "Provide statistics about the Java heap usage"; >> >> >> Should the impact() function result be formatted the same way as >> description() >> - to have or not have dot at the end ? >> >> The following lines are incorrectly indented: >> >> 85 static const char* description() { >> 86 return "Print system properties"; >> 87 } >> 88 static const char* impact() { >> 89 return "Low:"; >> 90 } >> >> 131 static const char* description() { >> 132 return "Call java.lang.System.gc()."; >> 133 } >> 134 static const char* impact() { >> 135 return "Medium: Depends on Java heap size and content"; >> 136 } >> >> 145 static const char* description() { >> 146 return "Call java.lang.System.runFinalization()."; >> 147 } >> 148 static const char* impact() { >> 149 return "Medium: Depends on Java content"; >> 150 } >> >> >> Thanks, >> Serguei >> >> On 1/5/12 7:19 AM, Frederic Parain wrote: >>> This changeset aims to add a first set of diagnostic commands >>> to the HotSpot JVM. It also includes minor modifications to >>> the diagnostic command framework implementation to ease >>> development of new diagnostic commands. >>> >>> The webrev is here: >>> >>> http://cr.openjdk.java.net/~fparain/7120511/webrev.00/ >>> >>> >>> Here's the list of new diagnostic commands: >>> >>> Thread.print >>> Print all threads with stacktraces. >>> >>> GC.class_histogram >>> Provides statistics about the Java heap usage >>> >>> GC.heap_dump >>> Generate a HPROF format dump of the Java heap >>> >>> GC.run_finalization >>> Call java.lang.System.runFinalization(). >>> >>> GC.run >>> Call java.lang.System.gc(). >>> >>> VM.uptime >>> Print VM uptime. >>> >>> VM.flags >>> Print VM flag options and their current values. >>> >>> VM.system_properties >>> Print system properties >>> >>> VM.command_line >>> Print the command line used to start this VM instance. >>> >>> >>> Thanks, >>> >>> Fred >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120106/4fa85889/attachment.html From valerie.peng at oracle.com Fri Jan 6 16:12:58 2012 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Sat, 07 Jan 2012 00:12:58 +0000 Subject: hg: jdk8/tl/jdk: 7033170: Cipher.getMaxAllowedKeyLength(String) throws NoSuchAlgorithmException Message-ID: <20120107001308.B7DB7478D8@hg.openjdk.java.net> Changeset: 6720ae7b1448 Author: valeriep Date: 2012-01-06 16:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6720ae7b1448 7033170: Cipher.getMaxAllowedKeyLength(String) throws NoSuchAlgorithmException Summary: Changed to always use full transformation as provider properties. Reviewed-by: mullan ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! test/javax/crypto/Cipher/GetMaxAllowed.java From joe.darcy at oracle.com Fri Jan 6 19:13:07 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Sat, 07 Jan 2012 03:13:07 +0000 Subject: hg: jdk8/tl/jdk: 7123649: Remove public modifier from Math.powerOfTwoF. Message-ID: <20120107031317.03BA7478DB@hg.openjdk.java.net> Changeset: 2050ff9dfc92 Author: darcy Date: 2012-01-06 18:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2050ff9dfc92 7123649: Remove public modifier from Math.powerOfTwoF. Reviewed-by: smarks, alanb ! src/share/classes/java/lang/Math.java From frederic.parain at oracle.com Mon Jan 9 10:16:25 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Mon, 09 Jan 2012 18:16:25 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7120511: Add diagnostic commands Message-ID: <20120109181628.11A12478F1@hg.openjdk.java.net> Changeset: 4f25538b54c9 Author: fparain Date: 2012-01-09 10:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4f25538b54c9 7120511: Add diagnostic commands Reviewed-by: acorn, phh, dcubed, sspitsyn ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/services/diagnosticFramework.cpp ! src/share/vm/services/diagnosticFramework.hpp ! src/share/vm/services/management.cpp From alan.bateman at oracle.com Mon Jan 9 11:33:51 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 09 Jan 2012 19:33:51 +0000 Subject: hg: jdk8/tl/jdk: 7030573: test/java/io/FileInputStream/LargeFileAvailable.java fails when there is insufficient disk space Message-ID: <20120109193414.B83CB478F2@hg.openjdk.java.net> Changeset: 74c92c3e66ad Author: gadams Date: 2012-01-09 19:33 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74c92c3e66ad 7030573: test/java/io/FileInputStream/LargeFileAvailable.java fails when there is insufficient disk space Reviewed-by: alanb ! test/java/io/FileInputStream/LargeFileAvailable.java From kurchi.subhra.hazra at oracle.com Mon Jan 9 12:02:27 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Mon, 09 Jan 2012 12:02:27 -0800 Subject: Code Review Request: 7117570: Warnings in sun.mangement.* and its subpackages Message-ID: <4F0B47D3.5080102@oracle.com> Hi, As an effort to cleanup build warnings, this webrev involves small changes in sun.management.* and its subpackages: Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7117570 Webrev: http://cr.openjdk.java.net/~khazra/7117570/webrev.03/ Thanks, Kurchi From joe.darcy at oracle.com Mon Jan 9 15:55:51 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 09 Jan 2012 23:55:51 +0000 Subject: hg: jdk8/tl/jdk: 7128441: StrictMath performance improvement note shared with Math Message-ID: <20120109235609.65D34478F6@hg.openjdk.java.net> Changeset: 858038d89fd5 Author: darcy Date: 2012-01-09 15:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/858038d89fd5 7128441: StrictMath performance improvement note shared with Math Reviewed-by: darcy Contributed-by: Martin Desruisseaux ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java From mandy.chung at oracle.com Mon Jan 9 19:30:15 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 09 Jan 2012 19:30:15 -0800 Subject: Code Review Request: 7117570: Warnings in sun.mangement.* and its subpackages In-Reply-To: <4F0B47D3.5080102@oracle.com> References: <4F0B47D3.5080102@oracle.com> Message-ID: <4F0BB0C7.2090603@oracle.com> Kurchi, Thanks for following up this cleanup build warnings work. I went through all files including the snmp ones. You mentioned in your initial review request that you used the serialver tool to generate all the serial version UIDs and that's good. This change looks okay. Some minor comments: Agent.java L221: it should keep passing "x" as the argument to the UnsupportedOperationException constructor (rather than x.getCause()). I actually misread this line in your previous webrev.00 that I missed that "x" is already passed as the argument. GarbageCollectorImpl.java L76, 78: indentation not aligned properly - one extra space. HotspotCompilation.java L123,126,129: looks like there are two spaces after "c =" LazyCompositeData.java L162: space before ")" can be removed. SnmpNamedListTableCache.java L216,221,225: should it be List rather than List? Will that help get rid of the unchecked suppressed warning? You mentioned in your previous email that sun.management and its subpackages are warning free with your changeset but I suspect there are still warnings e.g. JvmMemoryImpl.java L160 - this casts the key to MemoryUsage. Did you get a chance to check the incremental build and see if there are warnings or not? e.g. cd sun/management; make clean all I suspect the snmp code still has compiler warnings but that's fine since it's very old code that requires more cleanup work for the future. Mandy On 1/9/2012 12:02 PM, Kurchi Hazra wrote: > Hi, > > As an effort to cleanup build warnings, this webrev involves small > changes in > sun.management.* and its subpackages: > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7117570 > Webrev: http://cr.openjdk.java.net/~khazra/7117570/webrev.03/ > > > Thanks, > Kurchi From joe.darcy at oracle.com Mon Jan 9 20:14:46 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 10 Jan 2012 04:14:46 +0000 Subject: hg: jdk8/tl/jdk: 7128512: Javadoc typo in java.lang.invoke.MethodHandle Message-ID: <20120110041508.719D4478FB@hg.openjdk.java.net> Changeset: dd69d3695cee Author: darcy Date: 2012-01-09 20:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd69d3695cee 7128512: Javadoc typo in java.lang.invoke.MethodHandle Reviewed-by: mduigou ! src/share/classes/java/lang/invoke/MethodHandle.java From chris.hegarty at oracle.com Tue Jan 10 04:46:12 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 10 Jan 2012 12:46:12 +0000 Subject: hg: jdk8/tl/jdk: 7123415: Some cases of network interface indexes being read incorrectly Message-ID: <20120110124633.CD6EE47901@hg.openjdk.java.net> Changeset: d72de8b3fe36 Author: chegar Date: 2012-01-10 10:57 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d72de8b3fe36 7123415: Some cases of network interface indexes being read incorrectly Reviewed-by: chegar Contributed-by: brandon.passanisi at oracle.com ! src/solaris/native/java/net/net_util_md.c From chris.hegarty at oracle.com Tue Jan 10 04:49:14 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 10 Jan 2012 12:49:14 +0000 Subject: hg: jdk8/tl/jdk: 7128584: Typo in sun.misc.VM's private directMemory field comment Message-ID: <20120110124923.C329247902@hg.openjdk.java.net> Changeset: bba276a6aa0d Author: chegar Date: 2012-01-10 12:48 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bba276a6aa0d 7128584: Typo in sun.misc.VM's private directMemory field comment Reviewed-by: forax, chegar Contributed-by: Krystal Mok ! src/share/classes/sun/misc/VM.java From keith.mcguigan at oracle.com Tue Jan 10 16:28:33 2012 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Wed, 11 Jan 2012 00:28:33 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 40 new changesets Message-ID: <20120111002957.1C5D34790E@hg.openjdk.java.net> Changeset: 3b2b58fb1425 Author: tonyp Date: 2011-12-20 12:59 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3b2b58fb1425 7123165: G1: output during parallel verification can get messed up Summary: Serialize the worker threads that are generating output during parallel heap verification to make sure the output is consistent. Reviewed-by: brutisso, johnc, jmasa ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: d15b458c4225 Author: jmasa Date: 2011-12-20 20:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d15b458c4225 Merge Changeset: 67fdcb391461 Author: tonyp Date: 2011-12-21 07:53 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/67fdcb391461 7119027: G1: use atomics to update RS length / predict time of inc CSet Summary: Make sure that the updates to the RS length and inc CSet predicted time are updated in an MT-safe way. Reviewed-by: brutisso, iveresov ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: 441e946dc1af Author: jmasa Date: 2011-12-14 13:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/441e946dc1af 7121618: Change type of number of GC workers to unsigned int. Summary: Change variables representing the number of GC workers to uint from int and size_t. Change the parameter in work(int i) to work(uint worker_id). Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 1cbe7978b021 Author: brutisso Date: 2011-12-21 22:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1cbe7978b021 7113021: G1: automatically enable young gen size auto-tuning when -Xms==-Xmx Summary: Use a percentage of -Xms as min and another percentage of -Xmx as max for the young gen size Reviewed-by: tonyp, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 7faca6dfa2ed Author: jmasa Date: 2011-12-27 12:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7faca6dfa2ed Merge ! src/share/vm/runtime/globals.hpp Changeset: 3db6ea5ce021 Author: vladidan Date: 2011-12-29 20:09 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3db6ea5ce021 Merge Changeset: 20bfb6d15a94 Author: iveresov Date: 2011-12-27 16:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/20bfb6d15a94 7124829: NUMA: memory leak on Linux with large pages Summary: In os::free_memory() use mmap with the same attributes as for the heap space Reviewed-by: kvn Contributed-by: Aleksey Ignatenko ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/runtime/os.hpp Changeset: 776173fc2df9 Author: stefank Date: 2011-12-29 07:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/776173fc2df9 7125516: G1: ~ConcurrentMark() frees incorrectly Summary: Replaced the code with a ShouldNotReachHere Reviewed-by: tonyp, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 5ee33ff9b1c4 Author: jmasa Date: 2012-01-03 10:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5ee33ff9b1c4 Merge Changeset: 75c0a73eee98 Author: coleenp Date: 2011-11-17 12:53 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/75c0a73eee98 7102776: Pack instanceKlass boolean fields into single u1 field Summary: Reduce class runtime memory usage by packing 4 instanceKlass boolean fields into single u1 field. Save 4-byte for each loaded class. Reviewed-by: dholmes, bobv, phh, twisti, never, coleenp Contributed-by: Jiangli Zhou ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: da4dd142ea01 Author: bobv Date: 2011-11-29 14:44 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/da4dd142ea01 Merge ! src/share/vm/code/dependencies.cpp Changeset: 52b5d32fbfaf Author: coleenp Date: 2011-12-06 18:28 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/52b5d32fbfaf 7117052: instanceKlass::_init_state can be u1 type Summary: Change instanceKlass::_init_state field to u1 type. Reviewed-by: bdelsart, coleenp, dholmes, phh, never Contributed-by: Jiangli Zhou ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: eccc4b1f8945 Author: vladidan Date: 2011-12-07 16:47 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/eccc4b1f8945 7050298: ARM: SIGSEGV in JNIHandleBlock::allocate_handle Summary: missing release barrier in Monitor::IUnlock Reviewed-by: dholmes, dice ! src/share/vm/runtime/mutex.cpp Changeset: 2685ea97b89f Author: jiangli Date: 2011-12-09 11:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2685ea97b89f Merge ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp Changeset: 8fdf463085e1 Author: jiangli Date: 2011-12-16 17:33 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8fdf463085e1 Merge Changeset: dca455dea3a7 Author: bdelsart Date: 2011-12-20 12:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/dca455dea3a7 7116216: StackOverflow GC crash Summary: GC crash for explicit stack overflow checks after a C2I transition. Reviewed-by: coleenp, never Contributed-by: yang02.wang at sap.com, bertrand.delsart at oracle.com ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp + test/compiler/7116216/LargeFrame.java + test/compiler/7116216/StackOverflow.java Changeset: cd5d8cafcc84 Author: jiangli Date: 2011-12-28 12:15 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cd5d8cafcc84 7123315: instanceKlass::_static_oop_field_count and instanceKlass::_java_fields_count should be u2 type. Summary: Change instanceKlass::_static_oop_field_count and instanceKlass::_java_fields_count to u2 type. Reviewed-by: never, bdelsart, dholmes Contributed-by: Jiangli Zhou ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 05de27e852c4 Author: jiangli Date: 2012-01-04 12:36 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/05de27e852c4 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: b6a04c79ccbc Author: stefank Date: 2012-01-02 10:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b6a04c79ccbc 7125503: Compiling collectedHeap.cpp fails with -Werror=int-to-pointer-cast with g++ 4.6.1 Summary: Used uintptr_t and void* for all the casts and checks in test_is_in. Reviewed-by: tonyp, jmasa ! src/share/vm/gc_interface/collectedHeap.cpp Changeset: 4753e3dda3c8 Author: jmasa Date: 2012-01-04 07:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4753e3dda3c8 Merge Changeset: 2ee4167627a3 Author: jmasa Date: 2012-01-05 21:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2ee4167627a3 Merge Changeset: 2b3acb34791f Author: dcubed Date: 2012-01-06 16:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2b3acb34791f Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/runtime/os.hpp Changeset: abcceac2f7cd Author: iveresov Date: 2011-12-12 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/abcceac2f7cd 7119730: Tiered: SIGSEGV in AdvancedThresholdPolicy::is_method_profiled(methodOop) Summary: Added handles for references to methods in select_task() Reviewed-by: twisti, kvn ! src/share/vm/runtime/advancedThresholdPolicy.cpp Changeset: 7bca37d28f32 Author: roland Date: 2011-12-13 10:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7bca37d28f32 7114106: C1: assert(goto_state->is_same(sux_state)) failed: states must match now Summary: fix C1's CEE to take inlining into account when the stacks in states are compared. Reviewed-by: iveresov, never ! src/share/vm/c1/c1_Optimizer.cpp Changeset: d725f0affb1a Author: iveresov Date: 2011-12-13 17:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d725f0affb1a 7121111: -server -Xcomp -XX:+TieredCompilation does not invoke C2 compiler Summary: Exercise C2 more in tiered mode with Xcomp Reviewed-by: kvn, never ! src/share/vm/runtime/arguments.cpp Changeset: 127b3692c168 Author: kvn Date: 2011-12-14 14:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/127b3692c168 7116452: Add support for AVX instructions Summary: Added support for AVX extension to the x86 instruction set. Reviewed-by: never ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/assembler_x86.inline.hpp ! src/cpu/x86/vm/nativeInst_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.hpp ! src/cpu/x86/vm/register_definitions_x86.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/runtime/globals.hpp Changeset: 669f6a7d5b70 Author: never Date: 2011-12-19 14:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/669f6a7d5b70 7121073: secondary_super_cache memory slice has incorrect bounds in flatten_alias_type Reviewed-by: kvn ! src/share/vm/opto/compile.cpp Changeset: 65149e74c706 Author: kvn Date: 2011-12-20 00:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/65149e74c706 7121648: Use 3-operands SIMD instructions on x86 with AVX Summary: Use 3-operands SIMD instructions in C2 generated code for machines with AVX. Reviewed-by: never ! make/bsd/makefiles/adlc.make ! make/linux/makefiles/adlc.make ! make/solaris/makefiles/adlc.make ! make/windows/makefiles/adlc.make ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp + src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/matcher.cpp Changeset: 069ab3f976d3 Author: stefank Date: 2011-12-07 11:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/069ab3f976d3 7118863: Move sizeof(klassOopDesc) into the *Klass::*_offset_in_bytes() functions Summary: Moved sizeof(klassOopDesc), changed the return type to ByteSize and removed the _in_bytes suffix. Reviewed-by: never, bdelsart, coleenp, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassOop.hpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/shark/sharkIntrinsics.cpp ! src/share/vm/shark/sharkTopLevelBlock.cpp Changeset: 1dc233a8c7fe Author: roland Date: 2011-12-20 16:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1dc233a8c7fe 7121140: Allocation paths require explicit memory synchronization operations for RMO systems Summary: adds store store barrier after initialization of header and body of objects. Reviewed-by: never, kvn ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.hpp Changeset: e5ac210043cd Author: roland Date: 2011-12-22 10:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e5ac210043cd 7123108: C1: assert(if_state != NULL) failed: states do not match up Summary: In CEE, ensure if and common successor state are at the same inline level Reviewed-by: never ! src/share/vm/c1/c1_Optimizer.cpp + test/compiler/7123108/Test7123108.java Changeset: b642b49f9738 Author: roland Date: 2011-12-23 09:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b642b49f9738 7123253: C1: in store check code, usage of registers may be incorrect Summary: fix usage of input register in assembly code for store check. Reviewed-by: never ! src/share/vm/c1/c1_LIR.cpp Changeset: 40c2484c09e1 Author: kvn Date: 2011-12-23 15:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/40c2484c09e1 7110832: ctw/.../org_apache_avalon_composition_util_StringHelper crashes the VM Summary: Distance is too large for one short branch in string_indexofC8(). Reviewed-by: iveresov ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp Changeset: d12a66fa3820 Author: kvn Date: 2011-12-27 15:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d12a66fa3820 7123954: Some CTW test crash with SIGSEGV Summary: Correct Allocate expansion code to preserve i_o when only slow call is generated. Reviewed-by: iveresov ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/macro.cpp Changeset: 8940fd98d540 Author: kvn Date: 2011-12-29 11:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8940fd98d540 Merge ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/runtime/globals.hpp Changeset: 9c87bcb3b4dd Author: kvn Date: 2011-12-30 11:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9c87bcb3b4dd 7125879: assert(proj != NULL) failed: must be found Summary: Leave i_o attached to slow allocation call when there are no i_o users after the call. Reviewed-by: iveresov, twisti ! src/share/vm/opto/macro.cpp + test/compiler/7125879/Test7125879.java Changeset: 1cb50d7a9d95 Author: iveresov Date: 2012-01-05 17:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1cb50d7a9d95 7119294: Two command line options cause JVM to crash Summary: Setup thread register in MacroAssembler::incr_allocated_bytes() on x64 Reviewed-by: kvn ! src/cpu/x86/vm/assembler_x86.cpp Changeset: 22cee0ee8927 Author: kvn Date: 2012-01-06 20:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/22cee0ee8927 Merge ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parseHelper.cpp Changeset: 865e0817f32b Author: kamg Date: 2012-01-10 15:47 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/865e0817f32b Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp From kurchi.subhra.hazra at oracle.com Tue Jan 10 16:35:37 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 10 Jan 2012 16:35:37 -0800 Subject: Code Review Request: 7117570: Warnings in sun.mangement.* and its subpackages In-Reply-To: <4F0BB0C7.2090603@oracle.com> References: <4F0B47D3.5080102@oracle.com> <4F0BB0C7.2090603@oracle.com> Message-ID: <4F0CD959.1020103@oracle.com> Hi Mandy, > Agent.java > L221: it should keep passing "x" as the argument to the > UnsupportedOperationException constructor (rather than x.getCause()). > I actually misread this line in your previous webrev.00 that I > missed that "x" is already passed as the argument. > > GarbageCollectorImpl.java > L76, 78: indentation not aligned properly - one extra space. > > HotspotCompilation.java > L123,126,129: looks like there are two spaces after "c =" > > LazyCompositeData.java > L162: space before ")" can be removed. Updated webrev with all the above changes incorporated: http://cr.openjdk.java.net/~khazra/7117570/webrev.04/ > > SnmpNamedListTableCache.java > L216,221,225: should it be List rather than List? > Will that help get rid of the unchecked suppressed warning? - It does remove the suppressed warning added to this function, but will give rise to added suppress warnings in other places. For example: src/share/classes/sun/management/snmp/util/SnmpListTableCache.java:109 (since now the argument passed to be has to be List, else the compiler complains) Do you still want me to change it to List and not List? > > You mentioned in your previous email that sun.management and its > subpackages are warning free with your changeset but I suspect > there are still warnings e.g. > JvmMemoryImpl.java L160 - this casts the key to MemoryUsage. This and I also see some other casts that are somehow not being reported even if I turn on -Werror in make/sun/management/snmp. I will let this be for the time being and first get this changeset pushed. Probably in a new CR I will try adding -Werror to make/java/management and make/sun/management. Thanks, Kurchi > > Did you get a chance to check the incremental build and see if > there are warnings or not? e.g. cd sun/management; make clean all > I suspect the snmp code still has compiler warnings but that's fine > since it's very old code that requires more cleanup work for the > future. > > Mandy > > On 1/9/2012 12:02 PM, Kurchi Hazra wrote: >> Hi, >> >> As an effort to cleanup build warnings, this webrev involves >> small changes in >> sun.management.* and its subpackages: >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7117570 >> Webrev: http://cr.openjdk.java.net/~khazra/7117570/webrev.03/ >> >> >> Thanks, >> Kurchi -- -Kurchi From stuart.marks at oracle.com Tue Jan 10 16:58:13 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 10 Jan 2012 16:58:13 -0800 Subject: Code Review Request: 7117570: Warnings in sun.mangement.* and its subpackages In-Reply-To: <4F0CD959.1020103@oracle.com> References: <4F0B47D3.5080102@oracle.com> <4F0BB0C7.2090603@oracle.com> <4F0CD959.1020103@oracle.com> Message-ID: <4F0CDEA5.9000407@oracle.com> On 1/10/12 4:35 PM, Kurchi Hazra wrote: > Updated webrev with all the above changes incorporated: > http://cr.openjdk.java.net/~khazra/7117570/webrev.04/ > >> SnmpNamedListTableCache.java >> L216,221,225: should it be List rather than List? >> Will that help get rid of the unchecked suppressed warning? > - It does remove the suppressed warning added to this function, but will > give rise to added suppress warnings in other places. For example: > > src/share/classes/sun/management/snmp/util/SnmpListTableCache.java:109 > (since now the argument passed to be has to be List, else the compiler > complains) > > Do you still want me to change it to List and not List? I was looking at this too. Arguably the best conversion of a raw type List to generics is List but as you noted this causes a ripple effect, where other things have to be converted to wildcards as well. It looks like you have to change updateCachedDatas() and SnmpListTableCache.updateCachedDatas(), but then that's it. That doesn't look too bad. It could be that I've missed something and that you'll have to change more and more, in which case I'd reconsider making the change to use wildcards. >> You mentioned in your previous email that sun.management and its >> subpackages are warning free with your changeset but I suspect >> there are still warnings e.g. >> JvmMemoryImpl.java L160 - this casts the key to MemoryUsage. > This and I also see some other casts that are somehow not being > reported even if I turn on -Werror in make/sun/management/snmp. I will > let this be for the time being and first get this changeset pushed. Probably > in a new CR I will try adding -Werror to make/java/management and > make/sun/management. This cast doesn't generate an unchecked warning, because it *is* checked -- the VM checks the downcast from Object to MemoryUsage and throws ClassCastException if there's a mismatch. The compiler only emits unchecked warnings when the cast can't be checked at compile time *and* it can't be checked at runtime. Offhand I don't know whether this code is correct in making this cast. (The cast is *checked* but it might not be *safe*.) The code does catch RuntimeException and it does something reasonable, so maybe it's OK. This effort is about cleaning up warnings, though, and since there's no warning here I don't think we need to worry about it. s'marks > > > Thanks, > Kurchi > > >> >> Did you get a chance to check the incremental build and see if >> there are warnings or not? e.g. cd sun/management; make clean all >> I suspect the snmp code still has compiler warnings but that's fine >> since it's very old code that requires more cleanup work for the >> future. >> >> Mandy >> >> On 1/9/2012 12:02 PM, Kurchi Hazra wrote: >>> Hi, >>> >>> As an effort to cleanup build warnings, this webrev involves small changes in >>> sun.management.* and its subpackages: >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7117570 >>> Webrev: http://cr.openjdk.java.net/~khazra/7117570/webrev.03/ >>> >>> >>> Thanks, >>> Kurchi > From joe.darcy at oracle.com Tue Jan 10 17:13:02 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 11 Jan 2012 01:13:02 +0000 Subject: hg: jdk8/tl/jdk: 7112008: Javadoc for j.l.Object.finalize() vs JLS 12.6 Finalization of Class Instances Message-ID: <20120111011327.5669247913@hg.openjdk.java.net> Changeset: 49e64a8fc18f Author: darcy Date: 2012-01-10 17:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/49e64a8fc18f 7112008: Javadoc for j.l.Object.finalize() vs JLS 12.6 Finalization of Class Instances Reviewed-by: mduigou ! src/share/classes/java/lang/Object.java From kurchi.subhra.hazra at oracle.com Tue Jan 10 17:45:09 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 10 Jan 2012 17:45:09 -0800 Subject: Code Review Request: 7117570: Warnings in sun.mangement.* and its subpackages In-Reply-To: <4F0CDEA5.9000407@oracle.com> References: <4F0B47D3.5080102@oracle.com> <4F0BB0C7.2090603@oracle.com> <4F0CD959.1020103@oracle.com> <4F0CDEA5.9000407@oracle.com> Message-ID: <4F0CE9A5.70803@oracle.com> On 1/10/2012 4:58 PM, Stuart Marks wrote: > On 1/10/12 4:35 PM, Kurchi Hazra wrote: >> Updated webrev with all the above changes incorporated: >> http://cr.openjdk.java.net/~khazra/7117570/webrev.04/ >> >>> SnmpNamedListTableCache.java >>> L216,221,225: should it be List rather than List? >>> Will that help get rid of the unchecked suppressed warning? >> - It does remove the suppressed warning added to this function, but will >> give rise to added suppress warnings in other places. For example: >> >> src/share/classes/sun/management/snmp/util/SnmpListTableCache.java:109 >> (since now the argument passed to be has to be List, else the >> compiler >> complains) >> >> Do you still want me to change it to List and not List? > > I was looking at this too. Arguably the best conversion of a raw type > List to generics is List but as you noted this causes a ripple > effect, where other things have to be converted to wildcards as well. > It looks like you have to change updateCachedDatas() and > SnmpListTableCache.updateCachedDatas(), but then that's it. That > doesn't look too bad. It could be that I've missed something and that > you'll have to change more and more, in which case I'd reconsider > making the change to use wildcards. This webrev includes the above changes List to List http://cr.openjdk.java.net/~khazra/7117570/webrev.05/ -Kurchi > >>> You mentioned in your previous email that sun.management and its >>> subpackages are warning free with your changeset but I suspect >>> there are still warnings e.g. >>> JvmMemoryImpl.java L160 - this casts the key to MemoryUsage. >> This and I also see some other casts that are somehow not being >> reported even if I turn on -Werror in make/sun/management/snmp. I will >> let this be for the time being and first get this changeset pushed. >> Probably >> in a new CR I will try adding -Werror to make/java/management and >> make/sun/management. > > This cast doesn't generate an unchecked warning, because it *is* > checked -- the VM checks the downcast from Object to MemoryUsage and > throws ClassCastException if there's a mismatch. The compiler only > emits unchecked warnings when the cast can't be checked at compile > time *and* it can't be checked at runtime. > > Offhand I don't know whether this code is correct in making this cast. > (The cast is *checked* but it might not be *safe*.) The code does > catch RuntimeException and it does something reasonable, so maybe it's > OK. This effort is about cleaning up warnings, though, and since > there's no warning here I don't think we need to worry about it. > > s'marks > > >> >> >> Thanks, >> Kurchi >> >> >>> >>> Did you get a chance to check the incremental build and see if >>> there are warnings or not? e.g. cd sun/management; make clean all >>> I suspect the snmp code still has compiler warnings but that's fine >>> since it's very old code that requires more cleanup work for the >>> future. >>> >>> Mandy >>> >>> On 1/9/2012 12:02 PM, Kurchi Hazra wrote: >>>> Hi, >>>> >>>> As an effort to cleanup build warnings, this webrev involves small >>>> changes in >>>> sun.management.* and its subpackages: >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7117570 >>>> Webrev: http://cr.openjdk.java.net/~khazra/7117570/webrev.03/ >>>> >>>> >>>> Thanks, >>>> Kurchi >> -- -Kurchi From joe.darcy at oracle.com Tue Jan 10 17:47:02 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 11 Jan 2012 01:47:02 +0000 Subject: hg: jdk8/tl/jdk: 7128931: Bad HTML escaping in java.lang.Throwable javadoc Message-ID: <20120111014712.8637A47914@hg.openjdk.java.net> Changeset: 62dbcbe4c446 Author: darcy Date: 2012-01-10 17:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/62dbcbe4c446 7128931: Bad HTML escaping in java.lang.Throwable javadoc Reviewed-by: mduigou ! src/share/classes/java/lang/Throwable.java From mandy.chung at oracle.com Tue Jan 10 18:04:47 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 10 Jan 2012 18:04:47 -0800 Subject: Code Review Request: 7117570: Warnings in sun.mangement.* and its subpackages In-Reply-To: <4F0CD959.1020103@oracle.com> References: <4F0B47D3.5080102@oracle.com> <4F0BB0C7.2090603@oracle.com> <4F0CD959.1020103@oracle.com> Message-ID: <4F0CEE3F.3060000@oracle.com> On 1/10/2012 4:35 PM, Kurchi Hazra wrote: > > Updated webrev with all the above changes incorporated: > http://cr.openjdk.java.net/~khazra/7117570/webrev.04/ > GarbageCollectorImpl.java L76: nit - needs a space between "for" and "(" SnmpNamedListTableCache.java L215: I assume the unchecked suppressed warning is gone and this annotation can be removed, right? L225: the cast "(List)" isn't needed. SnmpListTableCache.java L107: this cast "(Object)" shouldn't be needed. Mandy From chris.hegarty at oracle.com Wed Jan 11 05:04:07 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 11 Jan 2012 13:04:07 +0000 Subject: hg: jdk8/tl/jdk: 7128648: HttpURLConnection.getHeaderFields should return an unmodifiable Map Message-ID: <20120111130426.417554791A@hg.openjdk.java.net> Changeset: 31a1fc60a895 Author: chegar Date: 2012-01-11 10:52 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/31a1fc60a895 7128648: HttpURLConnection.getHeaderFields should return an unmodifiable Map Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/java/net/HttpURLConnection/UnmodifiableMaps.java From alan.bateman at oracle.com Wed Jan 11 05:07:57 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 11 Jan 2012 13:07:57 +0000 Subject: hg: jdk8/tl/jdk: 7068856: (fs) Typo in Files.isSameFile() javadoc; ... Message-ID: <20120111130807.33E614791B@hg.openjdk.java.net> Changeset: 82144054d2d8 Author: alanb Date: 2012-01-11 13:07 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/82144054d2d8 7068856: (fs) Typo in Files.isSameFile() javadoc 7099208: (fs) Files.newBufferedReader has typo in javadoc Reviewed-by: forax ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/Path.java From Dmitry.Samersoff at oracle.com Wed Jan 11 06:34:38 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 11 Jan 2012 18:34:38 +0400 Subject: Code Review Request: 7117570: Warnings in sun.mangement.* and its subpackages In-Reply-To: <4F0CE9A5.70803@oracle.com> References: <4F0B47D3.5080102@oracle.com> <4F0BB0C7.2090603@oracle.com> <4F0CD959.1020103@oracle.com> <4F0CDEA5.9000407@oracle.com> <4F0CE9A5.70803@oracle.com> Message-ID: <4F0D9DFE.2010904@oracle.com> Kurchi, Sorry for stepping into it at later stage, my few cents. 1. Agent.java 220 comments is not relevant any more. 248 check of existence of configFile is not necessary. 255-258 a) Exceptions could be collapsed b) finally is gone - is it expected? CONFIG_FILE_CLOSE_FAILED is never happens anymore. I would prefer to keep original code 2. ConnectorAddressLink.java 176 Not sure implicit toString() necessary here. -Dmitry On 01/11/2012 05:45 AM, Kurchi Hazra wrote: > > > On 1/10/2012 4:58 PM, Stuart Marks wrote: >> On 1/10/12 4:35 PM, Kurchi Hazra wrote: >>> Updated webrev with all the above changes incorporated: >>> http://cr.openjdk.java.net/~khazra/7117570/webrev.04/ >>> >>>> SnmpNamedListTableCache.java >>>> L216,221,225: should it be List rather than List? >>>> Will that help get rid of the unchecked suppressed warning? >>> - It does remove the suppressed warning added to this function, but will >>> give rise to added suppress warnings in other places. For example: >>> >>> src/share/classes/sun/management/snmp/util/SnmpListTableCache.java:109 >>> (since now the argument passed to be has to be List, else the >>> compiler >>> complains) >>> >>> Do you still want me to change it to List and not List? >> >> I was looking at this too. Arguably the best conversion of a raw type >> List to generics is List but as you noted this causes a ripple >> effect, where other things have to be converted to wildcards as well. >> It looks like you have to change updateCachedDatas() and >> SnmpListTableCache.updateCachedDatas(), but then that's it. That >> doesn't look too bad. It could be that I've missed something and that >> you'll have to change more and more, in which case I'd reconsider >> making the change to use wildcards. > > This webrev includes the above changes List to List > > http://cr.openjdk.java.net/~khazra/7117570/webrev.05/ > > -Kurchi > >> >>>> You mentioned in your previous email that sun.management and its >>>> subpackages are warning free with your changeset but I suspect >>>> there are still warnings e.g. >>>> JvmMemoryImpl.java L160 - this casts the key to MemoryUsage. >>> This and I also see some other casts that are somehow not being >>> reported even if I turn on -Werror in make/sun/management/snmp. I will >>> let this be for the time being and first get this changeset pushed. >>> Probably >>> in a new CR I will try adding -Werror to make/java/management and >>> make/sun/management. >> >> This cast doesn't generate an unchecked warning, because it *is* >> checked -- the VM checks the downcast from Object to MemoryUsage and >> throws ClassCastException if there's a mismatch. The compiler only >> emits unchecked warnings when the cast can't be checked at compile >> time *and* it can't be checked at runtime. >> >> Offhand I don't know whether this code is correct in making this cast. >> (The cast is *checked* but it might not be *safe*.) The code does >> catch RuntimeException and it does something reasonable, so maybe it's >> OK. This effort is about cleaning up warnings, though, and since >> there's no warning here I don't think we need to worry about it. >> >> s'marks >> >> >>> >>> >>> Thanks, >>> Kurchi >>> >>> >>>> >>>> Did you get a chance to check the incremental build and see if >>>> there are warnings or not? e.g. cd sun/management; make clean all >>>> I suspect the snmp code still has compiler warnings but that's fine >>>> since it's very old code that requires more cleanup work for the >>>> future. >>>> >>>> Mandy >>>> >>>> On 1/9/2012 12:02 PM, Kurchi Hazra wrote: >>>>> Hi, >>>>> >>>>> As an effort to cleanup build warnings, this webrev involves small >>>>> changes in >>>>> sun.management.* and its subpackages: >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7117570 >>>>> Webrev: http://cr.openjdk.java.net/~khazra/7117570/webrev.03/ >>>>> >>>>> >>>>> Thanks, >>>>> Kurchi >>> > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From kumar.x.srinivasan at oracle.com Wed Jan 11 09:07:53 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Wed, 11 Jan 2012 17:07:53 +0000 Subject: hg: jdk8/tl/jdk: 7125442: jar application located in two bytes character named folder cannot be run with JRE 7 u1/u2 Message-ID: <20120111170810.E146B47923@hg.openjdk.java.net> Changeset: 96fe796fd242 Author: ksrini Date: 2012-01-11 08:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/96fe796fd242 7125442: jar application located in two bytes character named folder cannot be run with JRE 7 u1/u2 Reviewed-by: sherman, mchung, darcy ! src/share/bin/java.c + test/tools/launcher/I18NJarTest.java ! test/tools/launcher/TestHelper.java From maurizio.cimadamore at oracle.com Wed Jan 11 10:25:45 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 11 Jan 2012 18:25:45 +0000 Subject: hg: jdk8/tl/langtools: 7126754: Generics compilation failure casting List to List Message-ID: <20120111182549.7716F47925@hg.openjdk.java.net> Changeset: 70d92518063e Author: mcimadamore Date: 2012-01-11 18:23 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/70d92518063e 7126754: Generics compilation failure casting List to List Summary: Problems with Types.rewriteQuantifiers not preserving variance Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/cast/7126754/T7126754.java + test/tools/javac/cast/7126754/T7126754.out From paul.hohensee at oracle.com Wed Jan 11 23:19:01 2012 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Thu, 12 Jan 2012 07:19:01 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20120112071909.60DBA47933@hg.openjdk.java.net> Changeset: 94ec88ca68e2 Author: phh Date: 2012-01-11 17:34 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/94ec88ca68e2 7115199: Add event tracing hooks and Java Flight Recorder infrastructure Summary: Added a nop tracing infrastructure, JFR makefile changes and other infrastructure used only by JFR. Reviewed-by: acorn, sspitsyn Contributed-by: markus.gronlund at oracle.com ! make/Makefile ! make/bsd/makefiles/vm.make ! make/defs.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! make/windows/build.bat ! make/windows/create_obj_files.sh ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jni.cpp + src/share/vm/prims/jniExport.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vm_operations.hpp + src/share/vm/trace/traceEventTypes.hpp + src/share/vm/trace/traceMacros.hpp + src/share/vm/trace/tracing.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 4f3ce9284781 Author: phh Date: 2012-01-11 17:58 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4f3ce9284781 Merge ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp From david.holmes at oracle.com Wed Jan 11 23:54:58 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Jan 2012 17:54:58 +1000 Subject: Webrev for 6972759 In-Reply-To: <4F0CBE5E.2060203@oracle.com> References: <4F0CBE5E.2060203@oracle.com> Message-ID: <4F0E91D2.5060801@oracle.com> Hi Bill, I believe this should have gone out to the Serviceability list (cc'ed) instead of, or perhaps as well as, the runtime list. The change looks okay to me in that is does what you described it would. With JVMTI the proof-of-the-pudding is always in the testing and I assume the various JVMTI test suites have been thoroughly exercised ? Thanks, David On 11/01/2012 8:40 AM, Bill Pittore wrote: > Webrev for fix for 6972759 is at > http://cr.openjdk.java.net/~bpittore/6972759/webrev.00/ > > This bug has to do with single stepping after hitting an exception > breakpoint. The short story is that JVMTI maintains some thread state > information that was not updated correctly if a frame was popped off the > stack. When you pop a frame the exception state should go back to > _exception_detected=false. Otherwise when MethodExit event is sent at > some time in the future the 'was_popped_by_exception' flag will be set > and the agent receiving the event may not re-enable single stepping > properly. This problem will also affect ForceEarlyReturn code. Hacked up > a couple of existing nsk/jvmti tests to issue the necessary sequence of > JVMTI calls/events in order to test original bug and this fix. > > bill > > From xuelei.fan at oracle.com Thu Jan 12 03:40:18 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Thu, 12 Jan 2012 11:40:18 +0000 Subject: hg: jdk8/tl/jdk: 7106773: 512 bits RSA key cannot work with SHA384 and SHA512 Message-ID: <20120112114046.B5E6A47939@hg.openjdk.java.net> Changeset: 11e52d5ba64e Author: xuelei Date: 2012-01-12 03:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11e52d5ba64e 7106773: 512 bits RSA key cannot work with SHA384 and SHA512 Reviewed-by: weijun ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java + src/share/classes/sun/security/util/KeyLength.java + src/share/classes/sun/security/util/Length.java ! src/windows/classes/sun/security/mscapi/Key.java ! src/windows/classes/sun/security/mscapi/RSACipher.java ! src/windows/classes/sun/security/mscapi/RSASignature.java + test/sun/security/mscapi/ShortRSAKey1024.sh + test/sun/security/mscapi/ShortRSAKey512.sh + test/sun/security/mscapi/ShortRSAKey768.sh + test/sun/security/mscapi/ShortRSAKeyWithinTLS.java ! test/sun/security/pkcs11/KeyStore/ClientAuth.java ! test/sun/security/pkcs11/KeyStore/ClientAuth.sh ! test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java + test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java From maurizio.cimadamore at oracle.com Thu Jan 12 07:29:13 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 12 Jan 2012 15:29:13 +0000 Subject: hg: jdk8/tl/langtools: 7123100: javac fails with java.lang.StackOverflowError Message-ID: <20120112152917.CB5DB4793E@hg.openjdk.java.net> Changeset: 133744729455 Author: mcimadamore Date: 2012-01-12 15:28 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/133744729455 7123100: javac fails with java.lang.StackOverflowError Summary: Inference of under-constrained type-variables creates erroneous recursive wildcard types Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/cast/7123100/T7123100a.java + test/tools/javac/cast/7123100/T7123100a.out + test/tools/javac/cast/7123100/T7123100b.java + test/tools/javac/cast/7123100/T7123100b.out + test/tools/javac/cast/7123100/T7123100c.java + test/tools/javac/cast/7123100/T7123100c.out + test/tools/javac/cast/7123100/T7123100d.java + test/tools/javac/cast/7123100/T7123100d.out From john.coomes at oracle.com Thu Jan 12 10:28:33 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 12 Jan 2012 18:28:33 +0000 Subject: hg: hsx/hotspot-rt/langtools: Added tag jdk8-b20 for changeset ffd294128a48 Message-ID: <20120112182838.CEBA847943@hg.openjdk.java.net> Changeset: 020819eb56d2 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/020819eb56d2 Added tag jdk8-b20 for changeset ffd294128a48 ! .hgtags From kurchi.subhra.hazra at oracle.com Thu Jan 12 14:30:45 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Thu, 12 Jan 2012 14:30:45 -0800 Subject: Code Review Request: 7117570: Warnings in sun.mangement.* and its subpackages In-Reply-To: <4F0D9DFE.2010904@oracle.com> References: <4F0B47D3.5080102@oracle.com> <4F0BB0C7.2090603@oracle.com> <4F0CD959.1020103@oracle.com> <4F0CDEA5.9000407@oracle.com> <4F0CE9A5.70803@oracle.com> <4F0D9DFE.2010904@oracle.com> Message-ID: <4F0F5F15.1020909@oracle.com> Hi Dmitry, Thanks for your comments. Please see my doubts/comments inline : On 1/11/2012 6:34 AM, Dmitry Samersoff wrote: > Kurchi, > > Sorry for stepping into it at later stage, my few cents. > > 1. Agent.java > > 220 comments is not relevant any more. > > 248 check of existence of configFile is not necessary. Thanks, I removed these. > 255-258 a) Exceptions could be collapsed This cannot be collapsed since FileNotFoundException is a subclass of IOException. > b) finally is gone - is it expected? > CONFIG_FILE_CLOSE_FAILED is never happens anymore. > > I would prefer to keep original code - We were trying to use try-with-resources (new JDK7 feature), where closing of resources is automatically taken care of. But I will revert back to original code if that is preferred. > > 2. ConnectorAddressLink.java > 176 Not sure implicit toString() necessary here. I am not sure too. getValue() returns an Object. Thanks, Kurchi > > -Dmitry > > On 01/11/2012 05:45 AM, Kurchi Hazra wrote: >> >> On 1/10/2012 4:58 PM, Stuart Marks wrote: >>> On 1/10/12 4:35 PM, Kurchi Hazra wrote: >>>> Updated webrev with all the above changes incorporated: >>>> http://cr.openjdk.java.net/~khazra/7117570/webrev.04/ >>>> >>>>> SnmpNamedListTableCache.java >>>>> L216,221,225: should it be List rather than List? >>>>> Will that help get rid of the unchecked suppressed warning? >>>> - It does remove the suppressed warning added to this function, but will >>>> give rise to added suppress warnings in other places. For example: >>>> >>>> src/share/classes/sun/management/snmp/util/SnmpListTableCache.java:109 >>>> (since now the argument passed to be has to be List, else the >>>> compiler >>>> complains) >>>> >>>> Do you still want me to change it to List and not List? >>> I was looking at this too. Arguably the best conversion of a raw type >>> List to generics is List but as you noted this causes a ripple >>> effect, where other things have to be converted to wildcards as well. >>> It looks like you have to change updateCachedDatas() and >>> SnmpListTableCache.updateCachedDatas(), but then that's it. That >>> doesn't look too bad. It could be that I've missed something and that >>> you'll have to change more and more, in which case I'd reconsider >>> making the change to use wildcards. >> This webrev includes the above changes List to List >> >> http://cr.openjdk.java.net/~khazra/7117570/webrev.05/ >> >> -Kurchi >> >>>>> You mentioned in your previous email that sun.management and its >>>>> subpackages are warning free with your changeset but I suspect >>>>> there are still warnings e.g. >>>>> JvmMemoryImpl.java L160 - this casts the key to MemoryUsage. >>>> This and I also see some other casts that are somehow not being >>>> reported even if I turn on -Werror in make/sun/management/snmp. I will >>>> let this be for the time being and first get this changeset pushed. >>>> Probably >>>> in a new CR I will try adding -Werror to make/java/management and >>>> make/sun/management. >>> This cast doesn't generate an unchecked warning, because it *is* >>> checked -- the VM checks the downcast from Object to MemoryUsage and >>> throws ClassCastException if there's a mismatch. The compiler only >>> emits unchecked warnings when the cast can't be checked at compile >>> time *and* it can't be checked at runtime. >>> >>> Offhand I don't know whether this code is correct in making this cast. >>> (The cast is *checked* but it might not be *safe*.) The code does >>> catch RuntimeException and it does something reasonable, so maybe it's >>> OK. This effort is about cleaning up warnings, though, and since >>> there's no warning here I don't think we need to worry about it. >>> >>> s'marks >>> >>> >>>> >>>> Thanks, >>>> Kurchi >>>> >>>> >>>>> Did you get a chance to check the incremental build and see if >>>>> there are warnings or not? e.g. cd sun/management; make clean all >>>>> I suspect the snmp code still has compiler warnings but that's fine >>>>> since it's very old code that requires more cleanup work for the >>>>> future. >>>>> >>>>> Mandy >>>>> >>>>> On 1/9/2012 12:02 PM, Kurchi Hazra wrote: >>>>>> Hi, >>>>>> >>>>>> As an effort to cleanup build warnings, this webrev involves small >>>>>> changes in >>>>>> sun.management.* and its subpackages: >>>>>> >>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7117570 >>>>>> Webrev: http://cr.openjdk.java.net/~khazra/7117570/webrev.03/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Kurchi > -- -Kurchi From Dmitry.Samersoff at oracle.com Thu Jan 12 14:50:16 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 13 Jan 2012 02:50:16 +0400 Subject: Code Review Request: 7117570: Warnings in sun.mangement.* and its subpackages In-Reply-To: <4F0F5F15.1020909@oracle.com> References: <4F0B47D3.5080102@oracle.com> <4F0BB0C7.2090603@oracle.com> <4F0CD959.1020103@oracle.com> <4F0CDEA5.9000407@oracle.com> <4F0CE9A5.70803@oracle.com> <4F0D9DFE.2010904@oracle.com> <4F0F5F15.1020909@oracle.com> Message-ID: <4F0F63A8.3030903@oracle.com> On 2012-01-13 02:30, Kurchi Hazra wrote: >> 1. Agent.java >> >> 220 comments is not relevant any more. >> >> 248 check of existence of configFile is not necessary. > > Thanks, I removed these. > >> 255-258 a) Exceptions could be collapsed > > This cannot be collapsed since FileNotFoundException is a subclass of > IOException. Does it mean that we can simple remove catch of FileNotFoundException, replacing it with a comments that FileNotFound case covered by IOException ? 263 } catch (FileNotFoundException e) { 264 error(CONFIG_FILE_OPEN_FAILED, e.getMessage()); 265 } catch (IOException e) { 266 error(CONFIG_FILE_OPEN_FAILED, e.getMessage()); This code looks really weird for me, could you at least add a comment? > >> b) finally is gone - is it expected? >> CONFIG_FILE_CLOSE_FAILED is never happens anymore. >> >> I would prefer to keep original code > > - We were trying to use try-with-resources (new JDK7 feature), where > closing of resources is automatically taken care of. But I will > revert back to original code if that is preferred. We going to an area of changing public symbols. I'm in doubt that someone rely on CONFIG_FILE_CLOSE_FAILED message, but we need to check it, remove it from all translations etc. IMHO, It's out of the scope of your amazing work. >> >> 2. ConnectorAddressLink.java >> 176 Not sure implicit toString() necessary here. > I am not sure too. getValue() returns an Object. OK. Thank you! -Dmitry -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From david.holmes at oracle.com Thu Jan 12 15:03:21 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Jan 2012 09:03:21 +1000 Subject: Webrev for 6972759 In-Reply-To: <4F0F5323.1020805@oracle.com> References: <4F0CBE5E.2060203@oracle.com> <4F0E91D2.5060801@oracle.com> <4F0F4186.9040409@oracle.com> <4F0F43C0.6030606@oracle.com> <4F0F5323.1020805@oracle.com> Message-ID: <4F0F66B9.90907@oracle.com> On 13/01/2012 7:39 AM, Bill Pittore wrote: > Thanks for the comment. I dug up a slightly dated (refers to SCCS ) > coding convention document that recommends not to put bug IDs in the > comments. I'll delete it. There are numerous places in the hotspot code where comments refer to a specific CR so I wouldn't be too concerned. Normally they serve as an external link for where to find out more info about why particular code was changed/used. David > thanks, > bill > > > > On 1/12/2012 3:34 PM, yumin.qi at oracle.com wrote: >> Looks OK. One comment, should we include the CR in comment? I >> remember it should not be there. >> >> --Yumin >> >> On 1/12/2012 12:24 PM, Bill Pittore wrote: >>> Hi David, >>> Thanks for forwarding this to the SA list. I did run the nsk/jvmti >>> tests from the UTE area on sqenfs-1.us.oracle.com. There were no new >>> failures with this change. >>> >>> bill >>> >>> >>> >>> On 1/12/2012 2:54 AM, David Holmes wrote: >>>> Hi Bill, >>>> >>>> I believe this should have gone out to the Serviceability list >>>> (cc'ed) instead of, or perhaps as well as, the runtime list. >>>> >>>> The change looks okay to me in that is does what you described it >>>> would. With JVMTI the proof-of-the-pudding is always in the testing >>>> and I assume the various JVMTI test suites have been thoroughly >>>> exercised ? >>>> >>>> Thanks, >>>> David >>>> >>>> On 11/01/2012 8:40 AM, Bill Pittore wrote: >>>>> Webrev for fix for 6972759 is at >>>>> http://cr.openjdk.java.net/~bpittore/6972759/webrev.00/ >>>>> >>>>> This bug has to do with single stepping after hitting an exception >>>>> breakpoint. The short story is that JVMTI maintains some thread state >>>>> information that was not updated correctly if a frame was popped >>>>> off the >>>>> stack. When you pop a frame the exception state should go back to >>>>> _exception_detected=false. Otherwise when MethodExit event is sent at >>>>> some time in the future the 'was_popped_by_exception' flag will be set >>>>> and the agent receiving the event may not re-enable single stepping >>>>> properly. This problem will also affect ForceEarlyReturn code. >>>>> Hacked up >>>>> a couple of existing nsk/jvmti tests to issue the necessary >>>>> sequence of >>>>> JVMTI calls/events in order to test original bug and this fix. >>>>> >>>>> bill >>>>> >>>>> >>> >>> > > From david.holmes at oracle.com Thu Jan 12 15:24:37 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Jan 2012 09:24:37 +1000 Subject: Code Review Request: 7117570: Warnings in sun.mangement.* and its subpackages In-Reply-To: <4F0F63A8.3030903@oracle.com> References: <4F0B47D3.5080102@oracle.com> <4F0BB0C7.2090603@oracle.com> <4F0CD959.1020103@oracle.com> <4F0CDEA5.9000407@oracle.com> <4F0CE9A5.70803@oracle.com> <4F0D9DFE.2010904@oracle.com> <4F0F5F15.1020909@oracle.com> <4F0F63A8.3030903@oracle.com> Message-ID: <4F0F6BB5.3020304@oracle.com> On 13/01/2012 8:50 AM, Dmitry Samersoff wrote: > On 2012-01-13 02:30, Kurchi Hazra wrote: >>> 255-258 a) Exceptions could be collapsed >> >> This cannot be collapsed since FileNotFoundException is a subclass of >> IOException. > > Does it mean that we can simple remove catch of FileNotFoundException, > replacing it with a comments that FileNotFound case covered by IOException ? > > 263 } catch (FileNotFoundException e) { > 264 error(CONFIG_FILE_OPEN_FAILED, e.getMessage()); > 265 } catch (IOException e) { > 266 error(CONFIG_FILE_OPEN_FAILED, e.getMessage()); > > This code looks really weird for me, could you at least add a comment? It is redundant to catch FileNotFoundException and IOException and perform the same action in each case. This can simply reduce to catching IOException. >>> b) finally is gone - is it expected? >>> CONFIG_FILE_CLOSE_FAILED is never happens anymore. >>> >>> I would prefer to keep original code >> >> - We were trying to use try-with-resources (new JDK7 feature), where >> closing of resources is automatically taken care of. But I will >> revert back to original code if that is preferred. > > We going to an area of changing public symbols. I'm in doubt that > someone rely on CONFIG_FILE_CLOSE_FAILED message, but we need to check > it, remove it from all translations etc. > > IMHO, It's out of the scope of your amazing work. I agree. Changing to try-with-resources will change the failure mode. I'm not 100% sure how the try-with-resources works in this case but it seems to me that an IOException on the close() would result in a call to error() with the CONFIG_FILE_OPEN_FAILED message. David ----- From mandy.chung at oracle.com Thu Jan 12 16:01:44 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 12 Jan 2012 16:01:44 -0800 Subject: Code Review Request: 7117570: Warnings in sun.mangement.* and its subpackages In-Reply-To: <4F0D9DFE.2010904@oracle.com> References: <4F0B47D3.5080102@oracle.com> <4F0BB0C7.2090603@oracle.com> <4F0CD959.1020103@oracle.com> <4F0CDEA5.9000407@oracle.com> <4F0CE9A5.70803@oracle.com> <4F0D9DFE.2010904@oracle.com> Message-ID: <4F0F7468.7050405@oracle.com> Dmitry, On 1/11/2012 6:34 AM, Dmitry Samersoff wrote: > Kurchi, > > Sorry for stepping into it at later stage, my few cents. > > 1. Agent.java > > 220 comments is not relevant any more. > Why is it not relevant any more? Hmm.... this code is a bit confusing. The sun.management.snmp.AdaptorBootstrap class exists but the snmp runtime classes may not since they are in the closed source. The CNFE is from other snmp class but not sun.management.snmp.AdaptorBootstrap. Anyway, unless I miss any recent change, I think the comment is still valid. > 248 check of existence of configFile is not necessary. > Why? The user can set com.sun.management.config.file to a non-existence file. It should catch it. In any case, this is out of the scope of Kurchi's warning cleanup work. > 255-258 a) Exceptions could be collapsed > > b) finally is gone - is it expected? > CONFIG_FILE_CLOSE_FAILED is never happens anymore. > > I would prefer to keep original code > Good catch. Let's keep the original code and leave this for future cleanup. Mandy > 2. ConnectorAddressLink.java > 176 Not sure implicit toString() necessary here. > > > -Dmitry > > On 01/11/2012 05:45 AM, Kurchi Hazra wrote: >> >> On 1/10/2012 4:58 PM, Stuart Marks wrote: >>> On 1/10/12 4:35 PM, Kurchi Hazra wrote: >>>> Updated webrev with all the above changes incorporated: >>>> http://cr.openjdk.java.net/~khazra/7117570/webrev.04/ >>>> >>>>> SnmpNamedListTableCache.java >>>>> L216,221,225: should it be List rather than List? >>>>> Will that help get rid of the unchecked suppressed warning? >>>> - It does remove the suppressed warning added to this function, but will >>>> give rise to added suppress warnings in other places. For example: >>>> >>>> src/share/classes/sun/management/snmp/util/SnmpListTableCache.java:109 >>>> (since now the argument passed to be has to be List, else the >>>> compiler >>>> complains) >>>> >>>> Do you still want me to change it to List and not List? >>> I was looking at this too. Arguably the best conversion of a raw type >>> List to generics is List but as you noted this causes a ripple >>> effect, where other things have to be converted to wildcards as well. >>> It looks like you have to change updateCachedDatas() and >>> SnmpListTableCache.updateCachedDatas(), but then that's it. That >>> doesn't look too bad. It could be that I've missed something and that >>> you'll have to change more and more, in which case I'd reconsider >>> making the change to use wildcards. >> This webrev includes the above changes List to List >> >> http://cr.openjdk.java.net/~khazra/7117570/webrev.05/ >> >> -Kurchi >> >>>>> You mentioned in your previous email that sun.management and its >>>>> subpackages are warning free with your changeset but I suspect >>>>> there are still warnings e.g. >>>>> JvmMemoryImpl.java L160 - this casts the key to MemoryUsage. >>>> This and I also see some other casts that are somehow not being >>>> reported even if I turn on -Werror in make/sun/management/snmp. I will >>>> let this be for the time being and first get this changeset pushed. >>>> Probably >>>> in a new CR I will try adding -Werror to make/java/management and >>>> make/sun/management. >>> This cast doesn't generate an unchecked warning, because it *is* >>> checked -- the VM checks the downcast from Object to MemoryUsage and >>> throws ClassCastException if there's a mismatch. The compiler only >>> emits unchecked warnings when the cast can't be checked at compile >>> time *and* it can't be checked at runtime. >>> >>> Offhand I don't know whether this code is correct in making this cast. >>> (The cast is *checked* but it might not be *safe*.) The code does >>> catch RuntimeException and it does something reasonable, so maybe it's >>> OK. This effort is about cleaning up warnings, though, and since >>> there's no warning here I don't think we need to worry about it. >>> >>> s'marks >>> >>> >>>> >>>> Thanks, >>>> Kurchi >>>> >>>> >>>>> Did you get a chance to check the incremental build and see if >>>>> there are warnings or not? e.g. cd sun/management; make clean all >>>>> I suspect the snmp code still has compiler warnings but that's fine >>>>> since it's very old code that requires more cleanup work for the >>>>> future. >>>>> >>>>> Mandy >>>>> >>>>> On 1/9/2012 12:02 PM, Kurchi Hazra wrote: >>>>>> Hi, >>>>>> >>>>>> As an effort to cleanup build warnings, this webrev involves small >>>>>> changes in >>>>>> sun.management.* and its subpackages: >>>>>> >>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7117570 >>>>>> Webrev: http://cr.openjdk.java.net/~khazra/7117570/webrev.03/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Kurchi > From weijun.wang at oracle.com Thu Jan 12 17:51:25 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 13 Jan 2012 01:51:25 +0000 Subject: hg: jdk8/tl/jdk: 7090565: Move test/closed/javax/security/auth/x500/X500Principal/Parse.java to open tests Message-ID: <20120113015144.632D54794D@hg.openjdk.java.net> Changeset: 38bf1e9b6979 Author: weijun Date: 2012-01-13 09:50 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/38bf1e9b6979 7090565: Move test/closed/javax/security/auth/x500/X500Principal/Parse.java to open tests Reviewed-by: mullan + test/javax/security/auth/x500/X500Principal/NameFormat.java From valerie.peng at oracle.com Thu Jan 12 18:56:39 2012 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Fri, 13 Jan 2012 02:56:39 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120113025658.EB51B4794F@hg.openjdk.java.net> Changeset: ef3b6736c074 Author: valeriep Date: 2012-01-12 16:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ef3b6736c074 7088989: Improve the performance for T4 by utilizing the newly provided crypto APIs Summary: Added the OracleUcrypto provider for utilizing the Solaris ucrypto API. Reviewed-by: weijun ! make/com/oracle/Makefile + make/com/oracle/net/Makefile + make/com/oracle/nio/Makefile + make/com/oracle/security/ucrypto/FILES_c.gmk + make/com/oracle/security/ucrypto/Makefile + make/com/oracle/security/ucrypto/mapfile-vers + make/com/oracle/util/Makefile ! src/share/lib/security/java.security-solaris ! test/Makefile + test/com/oracle/security/ucrypto/TestAES.java + test/com/oracle/security/ucrypto/TestDigest.java + test/com/oracle/security/ucrypto/TestRSA.java + test/com/oracle/security/ucrypto/UcryptoTest.java ! test/java/security/Provider/DefaultPKCS11.java Changeset: a7ad2fcd7291 Author: valeriep Date: 2012-01-12 18:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7ad2fcd7291 Merge From bill.pittore at oracle.com Thu Jan 12 12:24:38 2012 From: bill.pittore at oracle.com (Bill Pittore) Date: Thu, 12 Jan 2012 15:24:38 -0500 Subject: Webrev for 6972759 In-Reply-To: <4F0E91D2.5060801@oracle.com> References: <4F0CBE5E.2060203@oracle.com> <4F0E91D2.5060801@oracle.com> Message-ID: <4F0F4186.9040409@oracle.com> Hi David, Thanks for forwarding this to the SA list. I did run the nsk/jvmti tests from the UTE area on sqenfs-1.us.oracle.com. There were no new failures with this change. bill On 1/12/2012 2:54 AM, David Holmes wrote: > Hi Bill, > > I believe this should have gone out to the Serviceability list (cc'ed) > instead of, or perhaps as well as, the runtime list. > > The change looks okay to me in that is does what you described it > would. With JVMTI the proof-of-the-pudding is always in the testing > and I assume the various JVMTI test suites have been thoroughly > exercised ? > > Thanks, > David > > On 11/01/2012 8:40 AM, Bill Pittore wrote: >> Webrev for fix for 6972759 is at >> http://cr.openjdk.java.net/~bpittore/6972759/webrev.00/ >> >> This bug has to do with single stepping after hitting an exception >> breakpoint. The short story is that JVMTI maintains some thread state >> information that was not updated correctly if a frame was popped off the >> stack. When you pop a frame the exception state should go back to >> _exception_detected=false. Otherwise when MethodExit event is sent at >> some time in the future the 'was_popped_by_exception' flag will be set >> and the agent receiving the event may not re-enable single stepping >> properly. This problem will also affect ForceEarlyReturn code. Hacked up >> a couple of existing nsk/jvmti tests to issue the necessary sequence of >> JVMTI calls/events in order to test original bug and this fix. >> >> bill >> >> From yumin.qi at oracle.com Thu Jan 12 12:34:08 2012 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Thu, 12 Jan 2012 12:34:08 -0800 Subject: Webrev for 6972759 In-Reply-To: <4F0F4186.9040409@oracle.com> References: <4F0CBE5E.2060203@oracle.com> <4F0E91D2.5060801@oracle.com> <4F0F4186.9040409@oracle.com> Message-ID: <4F0F43C0.6030606@oracle.com> Looks OK. One comment, should we include the CR in comment? I remember it should not be there. --Yumin On 1/12/2012 12:24 PM, Bill Pittore wrote: > Hi David, > Thanks for forwarding this to the SA list. I did run the nsk/jvmti > tests from the UTE area on sqenfs-1.us.oracle.com. There were no new > failures with this change. > > bill > > > > On 1/12/2012 2:54 AM, David Holmes wrote: >> Hi Bill, >> >> I believe this should have gone out to the Serviceability list >> (cc'ed) instead of, or perhaps as well as, the runtime list. >> >> The change looks okay to me in that is does what you described it >> would. With JVMTI the proof-of-the-pudding is always in the testing >> and I assume the various JVMTI test suites have been thoroughly >> exercised ? >> >> Thanks, >> David >> >> On 11/01/2012 8:40 AM, Bill Pittore wrote: >>> Webrev for fix for 6972759 is at >>> http://cr.openjdk.java.net/~bpittore/6972759/webrev.00/ >>> >>> This bug has to do with single stepping after hitting an exception >>> breakpoint. The short story is that JVMTI maintains some thread state >>> information that was not updated correctly if a frame was popped off >>> the >>> stack. When you pop a frame the exception state should go back to >>> _exception_detected=false. Otherwise when MethodExit event is sent at >>> some time in the future the 'was_popped_by_exception' flag will be set >>> and the agent receiving the event may not re-enable single stepping >>> properly. This problem will also affect ForceEarlyReturn code. >>> Hacked up >>> a couple of existing nsk/jvmti tests to issue the necessary sequence of >>> JVMTI calls/events in order to test original bug and this fix. >>> >>> bill >>> >>> > > From bill.pittore at oracle.com Thu Jan 12 13:39:47 2012 From: bill.pittore at oracle.com (Bill Pittore) Date: Thu, 12 Jan 2012 16:39:47 -0500 Subject: Webrev for 6972759 In-Reply-To: <4F0F43C0.6030606@oracle.com> References: <4F0CBE5E.2060203@oracle.com> <4F0E91D2.5060801@oracle.com> <4F0F4186.9040409@oracle.com> <4F0F43C0.6030606@oracle.com> Message-ID: <4F0F5323.1020805@oracle.com> Thanks for the comment. I dug up a slightly dated (refers to SCCS ) coding convention document that recommends not to put bug IDs in the comments. I'll delete it. thanks, bill On 1/12/2012 3:34 PM, yumin.qi at oracle.com wrote: > Looks OK. One comment, should we include the CR in comment? I > remember it should not be there. > > --Yumin > > On 1/12/2012 12:24 PM, Bill Pittore wrote: >> Hi David, >> Thanks for forwarding this to the SA list. I did run the nsk/jvmti >> tests from the UTE area on sqenfs-1.us.oracle.com. There were no new >> failures with this change. >> >> bill >> >> >> >> On 1/12/2012 2:54 AM, David Holmes wrote: >>> Hi Bill, >>> >>> I believe this should have gone out to the Serviceability list >>> (cc'ed) instead of, or perhaps as well as, the runtime list. >>> >>> The change looks okay to me in that is does what you described it >>> would. With JVMTI the proof-of-the-pudding is always in the testing >>> and I assume the various JVMTI test suites have been thoroughly >>> exercised ? >>> >>> Thanks, >>> David >>> >>> On 11/01/2012 8:40 AM, Bill Pittore wrote: >>>> Webrev for fix for 6972759 is at >>>> http://cr.openjdk.java.net/~bpittore/6972759/webrev.00/ >>>> >>>> This bug has to do with single stepping after hitting an exception >>>> breakpoint. The short story is that JVMTI maintains some thread state >>>> information that was not updated correctly if a frame was popped >>>> off the >>>> stack. When you pop a frame the exception state should go back to >>>> _exception_detected=false. Otherwise when MethodExit event is sent at >>>> some time in the future the 'was_popped_by_exception' flag will be set >>>> and the agent receiving the event may not re-enable single stepping >>>> properly. This problem will also affect ForceEarlyReturn code. >>>> Hacked up >>>> a couple of existing nsk/jvmti tests to issue the necessary >>>> sequence of >>>> JVMTI calls/events in order to test original bug and this fix. >>>> >>>> bill >>>> >>>> >> >> From Dmitry.Samersoff at oracle.com Fri Jan 13 03:26:46 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 13 Jan 2012 15:26:46 +0400 Subject: Code Review Request: 7117570: Warnings in sun.mangement.* and its subpackages In-Reply-To: <4F0F7468.7050405@oracle.com> References: <4F0B47D3.5080102@oracle.com> <4F0BB0C7.2090603@oracle.com> <4F0CD959.1020103@oracle.com> <4F0CDEA5.9000407@oracle.com> <4F0CE9A5.70803@oracle.com> <4F0D9DFE.2010904@oracle.com> <4F0F7468.7050405@oracle.com> Message-ID: <4F1014F6.6030000@oracle.com> On 2012-01-13 04:01, Mandy Chung wrote: > Dmitry, > > On 1/11/2012 6:34 AM, Dmitry Samersoff wrote: >> Kurchi, >> >> Sorry for stepping into it at later stage, my few cents. >> >> 1. Agent.java >> >> 220 comments is not relevant any more. >> > > Why is it not relevant any more? Hmm.... this code is > a bit confusing. The sun.management.snmp.AdaptorBootstrap class > exists but the snmp runtime classes may not since they are > in the closed source. The CNFE is from other snmp class but > not sun.management.snmp.AdaptorBootstrap. Anyway, unless I > miss any recent change, I think the comment is still valid. Comment says // The SNMP packages are not present: throws an exception. but with the new code the same exception thrown if package is present but doesn't have initialize() method or initialize() method has wrong protection. i.e. it means that SNMP package is present but invalid. I'm OK with code changes but would prefer to have comments changed as well. >> 248 check of existence of configFile is not necessary. >> > > Why? The user can set com.sun.management.config.file to a > non-existence file. It should catch it. We are trying to open this file later at ll.260 and would get FileNotFoundException if the file doesn't exist. So check on ll.253 is not necessary, moreover it could lead to confusing results if we are opening file resided on network-mounted media. It's possible that the file doesn't exist at ll.253 but exists to ll.260 and vice versa. So I would prefer to remove this check ever if it's a little bit out of scope of warning cleanup. IMHO, exception code 263 } catch (FileNotFoundException e) { 264 error(CONFIG_FILE_OPEN_FAILED, e.getMessage()); 265 } catch (IOException e) { 266 error(CONFIG_FILE_OPEN_FAILED, e.getMessage()); should look like: } catch (IOException e) { if ( e instanceof FileNotFoundException) error(CONFIG_FILE_NOT_FOUND, fname); else error(CONFIG_FILE_OPEN_FAILED, e.getMessage()); } -Dmitry > In any case, this is out of the scope of Kurchi's warning > cleanup work. > > >> 255-258 a) Exceptions could be collapsed >> >> b) finally is gone - is it expected? >> CONFIG_FILE_CLOSE_FAILED is never happens anymore. >> >> I would prefer to keep original code >> > > Good catch. Let's keep the original code and leave > this for future cleanup. > > Mandy > > >> 2. ConnectorAddressLink.java >> 176 Not sure implicit toString() necessary here. >> >> >> -Dmitry >> >> On 01/11/2012 05:45 AM, Kurchi Hazra wrote: >>> >>> On 1/10/2012 4:58 PM, Stuart Marks wrote: >>>> On 1/10/12 4:35 PM, Kurchi Hazra wrote: >>>>> Updated webrev with all the above changes incorporated: >>>>> http://cr.openjdk.java.net/~khazra/7117570/webrev.04/ >>>>> >>>>>> SnmpNamedListTableCache.java >>>>>> L216,221,225: should it be List rather than List? >>>>>> Will that help get rid of the unchecked suppressed warning? >>>>> - It does remove the suppressed warning added to this function, but >>>>> will >>>>> give rise to added suppress warnings in other places. For example: >>>>> >>>>> src/share/classes/sun/management/snmp/util/SnmpListTableCache.java:109 >>>>> (since now the argument passed to be has to be List, else the >>>>> compiler >>>>> complains) >>>>> >>>>> Do you still want me to change it to List and not List? >>>> I was looking at this too. Arguably the best conversion of a raw type >>>> List to generics is List but as you noted this causes a ripple >>>> effect, where other things have to be converted to wildcards as well. >>>> It looks like you have to change updateCachedDatas() and >>>> SnmpListTableCache.updateCachedDatas(), but then that's it. That >>>> doesn't look too bad. It could be that I've missed something and that >>>> you'll have to change more and more, in which case I'd reconsider >>>> making the change to use wildcards. >>> This webrev includes the above changes List to List >>> >>> http://cr.openjdk.java.net/~khazra/7117570/webrev.05/ >>> >>> -Kurchi >>> >>>>>> You mentioned in your previous email that sun.management and its >>>>>> subpackages are warning free with your changeset but I suspect >>>>>> there are still warnings e.g. >>>>>> JvmMemoryImpl.java L160 - this casts the key to MemoryUsage. >>>>> This and I also see some other casts that are somehow not being >>>>> reported even if I turn on -Werror in make/sun/management/snmp. I will >>>>> let this be for the time being and first get this changeset pushed. >>>>> Probably >>>>> in a new CR I will try adding -Werror to make/java/management and >>>>> make/sun/management. >>>> This cast doesn't generate an unchecked warning, because it *is* >>>> checked -- the VM checks the downcast from Object to MemoryUsage and >>>> throws ClassCastException if there's a mismatch. The compiler only >>>> emits unchecked warnings when the cast can't be checked at compile >>>> time *and* it can't be checked at runtime. >>>> >>>> Offhand I don't know whether this code is correct in making this cast. >>>> (The cast is *checked* but it might not be *safe*.) The code does >>>> catch RuntimeException and it does something reasonable, so maybe it's >>>> OK. This effort is about cleaning up warnings, though, and since >>>> there's no warning here I don't think we need to worry about it. >>>> >>>> s'marks >>>> >>>> >>>>> >>>>> Thanks, >>>>> Kurchi >>>>> >>>>> >>>>>> Did you get a chance to check the incremental build and see if >>>>>> there are warnings or not? e.g. cd sun/management; make clean all >>>>>> I suspect the snmp code still has compiler warnings but that's fine >>>>>> since it's very old code that requires more cleanup work for the >>>>>> future. >>>>>> >>>>>> Mandy >>>>>> >>>>>> On 1/9/2012 12:02 PM, Kurchi Hazra wrote: >>>>>>> Hi, >>>>>>> >>>>>>> As an effort to cleanup build warnings, this webrev involves small >>>>>>> changes in >>>>>>> sun.management.* and its subpackages: >>>>>>> >>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7117570 >>>>>>> Webrev: http://cr.openjdk.java.net/~khazra/7117570/webrev.03/ >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Kurchi >> -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From david.holmes at oracle.com Fri Jan 13 04:00:49 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Jan 2012 22:00:49 +1000 Subject: Code Review Request: 7117570: Warnings in sun.mangement.* and its subpackages In-Reply-To: <4F1014F6.6030000@oracle.com> References: <4F0B47D3.5080102@oracle.com> <4F0BB0C7.2090603@oracle.com> <4F0CD959.1020103@oracle.com> <4F0CDEA5.9000407@oracle.com> <4F0CE9A5.70803@oracle.com> <4F0D9DFE.2010904@oracle.com> <4F0F7468.7050405@oracle.com> <4F1014F6.6030000@oracle.com> Message-ID: <4F101CF1.6080305@oracle.com> On 13/01/2012 9:26 PM, Dmitry Samersoff wrote: > IMHO, exception code > > 263 } catch (FileNotFoundException e) { > 264 error(CONFIG_FILE_OPEN_FAILED, e.getMessage()); > 265 } catch (IOException e) { > 266 error(CONFIG_FILE_OPEN_FAILED, e.getMessage()); > > should look like: > > } catch (IOException e) { > if ( e instanceof FileNotFoundException) > error(CONFIG_FILE_NOT_FOUND, fname); > else > error(CONFIG_FILE_OPEN_FAILED, e.getMessage()); > } Totally disagree - that's not the way to write the exception code. If you have different actions then you use different catch clauses not instanceof: catch (FileNotFoundException fnfe) { error(CONFIG_FILE_NOT_FOUND, fname); } catch (IOException ioe) { error(CONFIG_FILE_OPEN_FAILED, e.getMessage()); } David ----- > > > > -Dmitry > > > >> In any case, this is out of the scope of Kurchi's warning >> cleanup work. >> >> >>> 255-258 a) Exceptions could be collapsed >>> >>> b) finally is gone - is it expected? >>> CONFIG_FILE_CLOSE_FAILED is never happens anymore. >>> >>> I would prefer to keep original code >>> >> >> Good catch. Let's keep the original code and leave >> this for future cleanup. >> >> Mandy >> >> >>> 2. ConnectorAddressLink.java >>> 176 Not sure implicit toString() necessary here. >>> >>> >>> -Dmitry >>> >>> On 01/11/2012 05:45 AM, Kurchi Hazra wrote: >>>> >>>> On 1/10/2012 4:58 PM, Stuart Marks wrote: >>>>> On 1/10/12 4:35 PM, Kurchi Hazra wrote: >>>>>> Updated webrev with all the above changes incorporated: >>>>>> http://cr.openjdk.java.net/~khazra/7117570/webrev.04/ >>>>>> >>>>>>> SnmpNamedListTableCache.java >>>>>>> L216,221,225: should it be List rather than List? >>>>>>> Will that help get rid of the unchecked suppressed warning? >>>>>> - It does remove the suppressed warning added to this function, but >>>>>> will >>>>>> give rise to added suppress warnings in other places. For example: >>>>>> >>>>>> src/share/classes/sun/management/snmp/util/SnmpListTableCache.java:109 >>>>>> (since now the argument passed to be has to be List, else the >>>>>> compiler >>>>>> complains) >>>>>> >>>>>> Do you still want me to change it to List and not List? >>>>> I was looking at this too. Arguably the best conversion of a raw type >>>>> List to generics is List but as you noted this causes a ripple >>>>> effect, where other things have to be converted to wildcards as well. >>>>> It looks like you have to change updateCachedDatas() and >>>>> SnmpListTableCache.updateCachedDatas(), but then that's it. That >>>>> doesn't look too bad. It could be that I've missed something and that >>>>> you'll have to change more and more, in which case I'd reconsider >>>>> making the change to use wildcards. >>>> This webrev includes the above changes List to List >>>> >>>> http://cr.openjdk.java.net/~khazra/7117570/webrev.05/ >>>> >>>> -Kurchi >>>> >>>>>>> You mentioned in your previous email that sun.management and its >>>>>>> subpackages are warning free with your changeset but I suspect >>>>>>> there are still warnings e.g. >>>>>>> JvmMemoryImpl.java L160 - this casts the key to MemoryUsage. >>>>>> This and I also see some other casts that are somehow not being >>>>>> reported even if I turn on -Werror in make/sun/management/snmp. I will >>>>>> let this be for the time being and first get this changeset pushed. >>>>>> Probably >>>>>> in a new CR I will try adding -Werror to make/java/management and >>>>>> make/sun/management. >>>>> This cast doesn't generate an unchecked warning, because it *is* >>>>> checked -- the VM checks the downcast from Object to MemoryUsage and >>>>> throws ClassCastException if there's a mismatch. The compiler only >>>>> emits unchecked warnings when the cast can't be checked at compile >>>>> time *and* it can't be checked at runtime. >>>>> >>>>> Offhand I don't know whether this code is correct in making this cast. >>>>> (The cast is *checked* but it might not be *safe*.) The code does >>>>> catch RuntimeException and it does something reasonable, so maybe it's >>>>> OK. This effort is about cleaning up warnings, though, and since >>>>> there's no warning here I don't think we need to worry about it. >>>>> >>>>> s'marks >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Kurchi >>>>>> >>>>>> >>>>>>> Did you get a chance to check the incremental build and see if >>>>>>> there are warnings or not? e.g. cd sun/management; make clean all >>>>>>> I suspect the snmp code still has compiler warnings but that's fine >>>>>>> since it's very old code that requires more cleanup work for the >>>>>>> future. >>>>>>> >>>>>>> Mandy >>>>>>> >>>>>>> On 1/9/2012 12:02 PM, Kurchi Hazra wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> As an effort to cleanup build warnings, this webrev involves small >>>>>>>> changes in >>>>>>>> sun.management.* and its subpackages: >>>>>>>> >>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7117570 >>>>>>>> Webrev: http://cr.openjdk.java.net/~khazra/7117570/webrev.03/ >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Kurchi >>> > > From Dmitry.Samersoff at oracle.com Fri Jan 13 04:43:42 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 13 Jan 2012 16:43:42 +0400 Subject: Code Review Request: 7117570: Warnings in sun.mangement.* and its subpackages In-Reply-To: <4F101CF1.6080305@oracle.com> References: <4F0B47D3.5080102@oracle.com> <4F0BB0C7.2090603@oracle.com> <4F0CD959.1020103@oracle.com> <4F0CDEA5.9000407@oracle.com> <4F0CE9A5.70803@oracle.com> <4F0D9DFE.2010904@oracle.com> <4F0F7468.7050405@oracle.com> <4F1014F6.6030000@oracle.com> <4F101CF1.6080305@oracle.com> Message-ID: <4F1026FE.8080104@oracle.com> David, On 2012-01-13 16:00, David Holmes wrote: > Totally disagree - that's not the way to write the exception code. If > you have different actions then you use different catch clauses not > instanceof: > > catch (FileNotFoundException fnfe) { > error(CONFIG_FILE_NOT_FOUND, fname); > } > catch (IOException ioe) { > error(CONFIG_FILE_OPEN_FAILED, e.getMessage()); > } OK. Lets it be two different catch statements ... -Dmitry -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From alan.bateman at oracle.com Fri Jan 13 05:32:13 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 13 Jan 2012 13:32:13 +0000 Subject: hg: jdk8/tl/jdk: 7129029: (fs) Unix file system provider should be buildable on platforms that don't support O_NOFOLLOW Message-ID: <20120113133235.A9F634795E@hg.openjdk.java.net> Changeset: 7e593aa6ad41 Author: littlee Date: 2012-01-13 13:20 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7e593aa6ad41 7129029: (fs) Unix file system provider should be buildable on platforms that don't support O_NOFOLLOW Reviewed-by: alanb ! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/native/sun/nio/fs/genUnixConstants.c From mandy.chung at oracle.com Fri Jan 13 07:52:54 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 13 Jan 2012 07:52:54 -0800 Subject: Code Review Request: 7117570: Warnings in sun.mangement.* and its subpackages In-Reply-To: <4F1014F6.6030000@oracle.com> References: <4F0B47D3.5080102@oracle.com> <4F0BB0C7.2090603@oracle.com> <4F0CD959.1020103@oracle.com> <4F0CDEA5.9000407@oracle.com> <4F0CE9A5.70803@oracle.com> <4F0D9DFE.2010904@oracle.com> <4F0F7468.7050405@oracle.com> <4F1014F6.6030000@oracle.com> Message-ID: <4F105356.4050603@oracle.com> On 1/13/2012 3:26 AM, Dmitry Samersoff wrote: >> Why is it not relevant any more? Hmm.... this code is >> a bit confusing. The sun.management.snmp.AdaptorBootstrap class >> exists but the snmp runtime classes may not since they are >> in the closed source. The CNFE is from other snmp class but >> not sun.management.snmp.AdaptorBootstrap. Anyway, unless I >> miss any recent change, I think the comment is still valid. > Comment says > // The SNMP packages are not present: throws an exception. > > but with the new code the same exception thrown if package is present > but doesn't have initialize() method or initialize() method has wrong > protection. > > i.e. it means that SNMP package is present but invalid. > I'm OK with code changes but would prefer to have comments changed as well. > I see what you mean. Perhaps the comment can be: // snmp runtime doesn't exist - initialization fails >>> 248 check of existence of configFile is not necessary. >>> >> Why? The user can set com.sun.management.config.file to a >> non-existence file. It should catch it. > We are trying to open this file later at ll.260 and would get > FileNotFoundException if the file doesn't exist. > > So check on ll.253 is not necessary, moreover it could lead to confusing > results if we are opening file resided on network-mounted media. > It's possible that the file doesn't exist at ll.253 but exists to > ll.260 and vice versa. > > So I would prefer to remove this check ever if it's a little bit out of > scope of warning cleanup. > > IMHO, exception code > > 263 } catch (FileNotFoundException e) { > 264 error(CONFIG_FILE_OPEN_FAILED, e.getMessage()); > 265 } catch (IOException e) { > 266 error(CONFIG_FILE_OPEN_FAILED, e.getMessage()); > > should look like: > > } catch (IOException e) { > if ( e instanceof FileNotFoundException) > error(CONFIG_FILE_NOT_FOUND, fname); > else > error(CONFIG_FILE_OPEN_FAILED, e.getMessage()); > } > > I agree with David that the above should use different catch clauses rather than instanceof within one single catch clause. Since this is out of the scope of the warning cleanup, I suggest to file a bug on this issue and Kurchi will keep the existing code unmodified. Mandy > > -Dmitry > > > >> In any case, this is out of the scope of Kurchi's warning >> cleanup work. >> >> >>> 255-258 a) Exceptions could be collapsed >>> >>> b) finally is gone - is it expected? >>> CONFIG_FILE_CLOSE_FAILED is never happens anymore. >>> >>> I would prefer to keep original code >>> >> Good catch. Let's keep the original code and leave >> this for future cleanup. >> >> Mandy >> >> >>> 2. ConnectorAddressLink.java >>> 176 Not sure implicit toString() necessary here. >>> >>> >>> -Dmitry >>> >>> On 01/11/2012 05:45 AM, Kurchi Hazra wrote: >>>> On 1/10/2012 4:58 PM, Stuart Marks wrote: >>>>> On 1/10/12 4:35 PM, Kurchi Hazra wrote: >>>>>> Updated webrev with all the above changes incorporated: >>>>>> http://cr.openjdk.java.net/~khazra/7117570/webrev.04/ >>>>>> >>>>>>> SnmpNamedListTableCache.java >>>>>>> L216,221,225: should it be List rather than List? >>>>>>> Will that help get rid of the unchecked suppressed warning? >>>>>> - It does remove the suppressed warning added to this function, but >>>>>> will >>>>>> give rise to added suppress warnings in other places. For example: >>>>>> >>>>>> src/share/classes/sun/management/snmp/util/SnmpListTableCache.java:109 >>>>>> (since now the argument passed to be has to be List, else the >>>>>> compiler >>>>>> complains) >>>>>> >>>>>> Do you still want me to change it to List and not List? >>>>> I was looking at this too. Arguably the best conversion of a raw type >>>>> List to generics is List but as you noted this causes a ripple >>>>> effect, where other things have to be converted to wildcards as well. >>>>> It looks like you have to change updateCachedDatas() and >>>>> SnmpListTableCache.updateCachedDatas(), but then that's it. That >>>>> doesn't look too bad. It could be that I've missed something and that >>>>> you'll have to change more and more, in which case I'd reconsider >>>>> making the change to use wildcards. >>>> This webrev includes the above changes List to List >>>> >>>> http://cr.openjdk.java.net/~khazra/7117570/webrev.05/ >>>> >>>> -Kurchi >>>> >>>>>>> You mentioned in your previous email that sun.management and its >>>>>>> subpackages are warning free with your changeset but I suspect >>>>>>> there are still warnings e.g. >>>>>>> JvmMemoryImpl.java L160 - this casts the key to MemoryUsage. >>>>>> This and I also see some other casts that are somehow not being >>>>>> reported even if I turn on -Werror in make/sun/management/snmp. I will >>>>>> let this be for the time being and first get this changeset pushed. >>>>>> Probably >>>>>> in a new CR I will try adding -Werror to make/java/management and >>>>>> make/sun/management. >>>>> This cast doesn't generate an unchecked warning, because it *is* >>>>> checked -- the VM checks the downcast from Object to MemoryUsage and >>>>> throws ClassCastException if there's a mismatch. The compiler only >>>>> emits unchecked warnings when the cast can't be checked at compile >>>>> time *and* it can't be checked at runtime. >>>>> >>>>> Offhand I don't know whether this code is correct in making this cast. >>>>> (The cast is *checked* but it might not be *safe*.) The code does >>>>> catch RuntimeException and it does something reasonable, so maybe it's >>>>> OK. This effort is about cleaning up warnings, though, and since >>>>> there's no warning here I don't think we need to worry about it. >>>>> >>>>> s'marks >>>>> >>>>> >>>>>> Thanks, >>>>>> Kurchi >>>>>> >>>>>> >>>>>>> Did you get a chance to check the incremental build and see if >>>>>>> there are warnings or not? e.g. cd sun/management; make clean all >>>>>>> I suspect the snmp code still has compiler warnings but that's fine >>>>>>> since it's very old code that requires more cleanup work for the >>>>>>> future. >>>>>>> >>>>>>> Mandy >>>>>>> >>>>>>> On 1/9/2012 12:02 PM, Kurchi Hazra wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> As an effort to cleanup build warnings, this webrev involves small >>>>>>>> changes in >>>>>>>> sun.management.* and its subpackages: >>>>>>>> >>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7117570 >>>>>>>> Webrev: http://cr.openjdk.java.net/~khazra/7117570/webrev.03/ >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Kurchi > From kurchi.subhra.hazra at oracle.com Fri Jan 13 12:03:23 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Fri, 13 Jan 2012 12:03:23 -0800 Subject: Code Review Request: 7117570: Warnings in sun.mangement.* and its subpackages In-Reply-To: <4F105356.4050603@oracle.com> References: <4F0B47D3.5080102@oracle.com> <4F0BB0C7.2090603@oracle.com> <4F0CD959.1020103@oracle.com> <4F0CDEA5.9000407@oracle.com> <4F0CE9A5.70803@oracle.com> <4F0D9DFE.2010904@oracle.com> <4F0F7468.7050405@oracle.com> <4F1014F6.6030000@oracle.com> <4F105356.4050603@oracle.com> Message-ID: <4F108E0B.5000402@oracle.com> Updated webrev: http://cr.openjdk.java.net/~khazra/7117570/webrev.07/ Thanks, Kurchi On 1/13/2012 7:52 AM, Mandy Chung wrote: > > > On 1/13/2012 3:26 AM, Dmitry Samersoff wrote: >>> Why is it not relevant any more? Hmm.... this code is >>> a bit confusing. The sun.management.snmp.AdaptorBootstrap class >>> exists but the snmp runtime classes may not since they are >>> in the closed source. The CNFE is from other snmp class but >>> not sun.management.snmp.AdaptorBootstrap. Anyway, unless I >>> miss any recent change, I think the comment is still valid. >> Comment says >> // The SNMP packages are not present: throws an exception. >> >> but with the new code the same exception thrown if package is present >> but doesn't have initialize() method or initialize() method has wrong >> protection. >> >> i.e. it means that SNMP package is present but invalid. >> I'm OK with code changes but would prefer to have comments changed as >> well. >> > > I see what you mean. Perhaps the comment can be: > // snmp runtime doesn't exist - initialization fails > >>>> 248 check of existence of configFile is not necessary. >>>> >>> Why? The user can set com.sun.management.config.file to a >>> non-existence file. It should catch it. >> We are trying to open this file later at ll.260 and would get >> FileNotFoundException if the file doesn't exist. >> >> So check on ll.253 is not necessary, moreover it could lead to confusing >> results if we are opening file resided on network-mounted media. >> It's possible that the file doesn't exist at ll.253 but exists to >> ll.260 and vice versa. >> >> So I would prefer to remove this check ever if it's a little bit out of >> scope of warning cleanup. >> >> IMHO, exception code >> >> 263 } catch (FileNotFoundException e) { >> 264 error(CONFIG_FILE_OPEN_FAILED, e.getMessage()); >> 265 } catch (IOException e) { >> 266 error(CONFIG_FILE_OPEN_FAILED, e.getMessage()); >> >> should look like: >> >> } catch (IOException e) { >> if ( e instanceof FileNotFoundException) >> error(CONFIG_FILE_NOT_FOUND, fname); >> else >> error(CONFIG_FILE_OPEN_FAILED, e.getMessage()); >> } >> >> > > I agree with David that the above should use different catch clauses > rather than instanceof within one single catch clause. > > Since this is out of the scope of the warning cleanup, I suggest to > file a bug on this issue and Kurchi will keep the existing code > unmodified. > > Mandy > >> >> -Dmitry >> >> >> >>> In any case, this is out of the scope of Kurchi's warning >>> cleanup work. >>> >>> >>>> 255-258 a) Exceptions could be collapsed >>>> >>>> b) finally is gone - is it expected? >>>> CONFIG_FILE_CLOSE_FAILED is never happens anymore. >>>> >>>> I would prefer to keep original code >>>> >>> Good catch. Let's keep the original code and leave >>> this for future cleanup. >>> >>> Mandy >>> >>> >>>> 2. ConnectorAddressLink.java >>>> 176 Not sure implicit toString() necessary here. >>>> >>>> >>>> -Dmitry >>>> >>>> On 01/11/2012 05:45 AM, Kurchi Hazra wrote: >>>>> On 1/10/2012 4:58 PM, Stuart Marks wrote: >>>>>> On 1/10/12 4:35 PM, Kurchi Hazra wrote: >>>>>>> Updated webrev with all the above changes incorporated: >>>>>>> http://cr.openjdk.java.net/~khazra/7117570/webrev.04/ >>>>>>> >>>>>>>> SnmpNamedListTableCache.java >>>>>>>> L216,221,225: should it be List rather than List? >>>>>>>> Will that help get rid of the unchecked suppressed warning? >>>>>>> - It does remove the suppressed warning added to this function, but >>>>>>> will >>>>>>> give rise to added suppress warnings in other places. For example: >>>>>>> >>>>>>> src/share/classes/sun/management/snmp/util/SnmpListTableCache.java:109 >>>>>>> >>>>>>> (since now the argument passed to be has to be List, else the >>>>>>> compiler >>>>>>> complains) >>>>>>> >>>>>>> Do you still want me to change it to List and not >>>>>>> List? >>>>>> I was looking at this too. Arguably the best conversion of a raw >>>>>> type >>>>>> List to generics is List but as you noted this causes a ripple >>>>>> effect, where other things have to be converted to wildcards as >>>>>> well. >>>>>> It looks like you have to change updateCachedDatas() and >>>>>> SnmpListTableCache.updateCachedDatas(), but then that's it. That >>>>>> doesn't look too bad. It could be that I've missed something and >>>>>> that >>>>>> you'll have to change more and more, in which case I'd reconsider >>>>>> making the change to use wildcards. >>>>> This webrev includes the above changes List to List >>>>> >>>>> http://cr.openjdk.java.net/~khazra/7117570/webrev.05/ >>>>> >>>>> -Kurchi >>>>> >>>>>>>> You mentioned in your previous email that sun.management and its >>>>>>>> subpackages are warning free with your changeset but I suspect >>>>>>>> there are still warnings e.g. >>>>>>>> JvmMemoryImpl.java L160 - this casts the key to MemoryUsage. >>>>>>> This and I also see some other casts that are somehow not being >>>>>>> reported even if I turn on -Werror in make/sun/management/snmp. >>>>>>> I will >>>>>>> let this be for the time being and first get this changeset pushed. >>>>>>> Probably >>>>>>> in a new CR I will try adding -Werror to make/java/management and >>>>>>> make/sun/management. >>>>>> This cast doesn't generate an unchecked warning, because it *is* >>>>>> checked -- the VM checks the downcast from Object to MemoryUsage and >>>>>> throws ClassCastException if there's a mismatch. The compiler only >>>>>> emits unchecked warnings when the cast can't be checked at compile >>>>>> time *and* it can't be checked at runtime. >>>>>> >>>>>> Offhand I don't know whether this code is correct in making this >>>>>> cast. >>>>>> (The cast is *checked* but it might not be *safe*.) The code does >>>>>> catch RuntimeException and it does something reasonable, so maybe >>>>>> it's >>>>>> OK. This effort is about cleaning up warnings, though, and since >>>>>> there's no warning here I don't think we need to worry about it. >>>>>> >>>>>> s'marks >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Kurchi >>>>>>> >>>>>>> >>>>>>>> Did you get a chance to check the incremental build and see if >>>>>>>> there are warnings or not? e.g. cd sun/management; make clean all >>>>>>>> I suspect the snmp code still has compiler warnings but that's >>>>>>>> fine >>>>>>>> since it's very old code that requires more cleanup work for the >>>>>>>> future. >>>>>>>> >>>>>>>> Mandy >>>>>>>> >>>>>>>> On 1/9/2012 12:02 PM, Kurchi Hazra wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> As an effort to cleanup build warnings, this webrev involves >>>>>>>>> small >>>>>>>>> changes in >>>>>>>>> sun.management.* and its subpackages: >>>>>>>>> >>>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7117570 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~khazra/7117570/webrev.03/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Kurchi >> -- -Kurchi From mandy.chung at oracle.com Fri Jan 13 15:37:26 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 13 Jan 2012 15:37:26 -0800 Subject: Code Review Request: 7117570: Warnings in sun.mangement.* and its subpackages In-Reply-To: <4F108E0B.5000402@oracle.com> References: <4F0B47D3.5080102@oracle.com> <4F0BB0C7.2090603@oracle.com> <4F0CD959.1020103@oracle.com> <4F0CDEA5.9000407@oracle.com> <4F0CE9A5.70803@oracle.com> <4F0D9DFE.2010904@oracle.com> <4F0F7468.7050405@oracle.com> <4F1014F6.6030000@oracle.com> <4F105356.4050603@oracle.com> <4F108E0B.5000402@oracle.com> Message-ID: <4F10C036.80706@oracle.com> On 1/13/2012 12:03 PM, Kurchi Hazra wrote: > Updated webrev: http://cr.openjdk.java.net/~khazra/7117570/webrev.07/ > I re-reviewed Agent.java and the files I had comments with. > > GarbageCollectorImpl.java > L76: nit - needs a space between "for" and "(" > > SnmpNamedListTableCache.java > L215: I assume the unchecked suppressed warning is gone > and this annotation can be removed, right? > L225: the cast "(List)" isn't needed. > > SnmpListTableCache.java > L107: this cast "(Object)" shouldn't be needed. Looks good. When Dmitry agrees with the change, I can sponsor this changeset and push it for you. Thank you for doing the warning cleanup in this area. Mandy From weijun.wang at oracle.com Sun Jan 15 18:14:45 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 16 Jan 2012 02:14:45 +0000 Subject: hg: jdk8/tl/jdk: 7118809: rcache deadlock Message-ID: <20120116021517.899F94797D@hg.openjdk.java.net> Changeset: e8e08d46cc37 Author: weijun Date: 2012-01-16 10:10 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8e08d46cc37 7118809: rcache deadlock Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java ! src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java ! test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/ReplayCache.java From Dmitry.Samersoff at oracle.com Mon Jan 16 03:39:56 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 16 Jan 2012 15:39:56 +0400 Subject: Code Review Request: 7117570: Warnings in sun.mangement.* and its subpackages In-Reply-To: <4F10C036.80706@oracle.com> References: <4F0B47D3.5080102@oracle.com> <4F0BB0C7.2090603@oracle.com> <4F0CD959.1020103@oracle.com> <4F0CDEA5.9000407@oracle.com> <4F0CE9A5.70803@oracle.com> <4F0D9DFE.2010904@oracle.com> <4F0F7468.7050405@oracle.com> <4F1014F6.6030000@oracle.com> <4F105356.4050603@oracle.com> <4F108E0B.5000402@oracle.com> <4F10C036.80706@oracle.com> Message-ID: <4F140C8C.6040000@oracle.com> Kurchi, Looks good for me! -Dmitry On 2012-01-14 03:37, Mandy Chung wrote: > On 1/13/2012 12:03 PM, Kurchi Hazra wrote: >> Updated webrev: http://cr.openjdk.java.net/~khazra/7117570/webrev.07/ >> > > I re-reviewed Agent.java and the files I had comments with. >> >> GarbageCollectorImpl.java >> L76: nit - needs a space between "for" and "(" >> >> SnmpNamedListTableCache.java >> L215: I assume the unchecked suppressed warning is gone >> and this annotation can be removed, right? >> L225: the cast "(List)" isn't needed. >> >> SnmpListTableCache.java >> L107: this cast "(Object)" shouldn't be needed. > > Looks good. When Dmitry agrees with the change, I can sponsor this > changeset and push it for you. > > Thank you for doing the warning cleanup in this area. > Mandy -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From alan.bateman at oracle.com Mon Jan 16 08:31:26 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 16 Jan 2012 16:31:26 +0000 Subject: hg: jdk8/tl/jdk: 7130398: ProblemList.txt updates (1/2012) Message-ID: <20120116163149.C44094798C@hg.openjdk.java.net> Changeset: d1b0bda3a3c7 Author: alanb Date: 2012-01-16 16:30 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d1b0bda3a3c7 7130398: ProblemList.txt updates (1/2012) Reviewed-by: chegar ! test/ProblemList.txt From chris.hegarty at oracle.com Mon Jan 16 13:28:04 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 16 Jan 2012 21:28:04 +0000 Subject: hg: jdk8/tl/jdk: 7129083: CookieManager does not store cookies if url is read before setting cookie manager Message-ID: <20120116212828.15AF54798E@hg.openjdk.java.net> Changeset: e8a143213c65 Author: chegar Date: 2012-01-16 18:05 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8a143213c65 7129083: CookieManager does not store cookies if url is read before setting cookie manager Reviewed-by: michaelm ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java + test/sun/net/www/http/HttpClient/CookieHttpClientTest.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java From david.holmes at oracle.com Mon Jan 16 19:09:21 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Jan 2012 13:09:21 +1000 Subject: RFR (S): 7130391: Add a framework for vendor-specific validation control of setting command-line switches in Hotspot In-Reply-To: <5a181ad1-ef64-4b00-88ce-69829f2ce80b@default> References: <5a181ad1-ef64-4b00-88ce-69829f2ce80b@default> Message-ID: <4F14E661.5080405@oracle.com> Hi Robert, I've added serviceability to the cc list. On 17/01/2012 12:04 PM, Robert Ottenhag wrote: > Webrev: http://cr.openjdk.java.net/~rottenha/7130391/webrev.00 > > This fix adds optional validation control to the setting of command-line switches in Hotspot, and allows it to have vendor-specific extensions if necessary. Does this imply that the Java management APIs (eg com.sun.management.VMOption) need to be changed to reflect these restrictions? Presently VMOptions are either writeable or not, but this makes them conditionally-writeable. > The design follows the previously added framework for vendor-specific command-line switch extensions in CR7117389. > > The validation control is handled by new boolean methods Flag::is_valid_(value,origin) that are called at the beginning of each call to CommandLineFlags[Ex]::AtPut() to verify that the new value and origin are valid replacements for the current value and origin for this flag. > > When parsing the command line options, a failed validation will typically result in an error message and exit with "Unrecognized VM option ''". When used dynamically using the attach API or management API the resulting operation will fail, leaving it up to the caller to handle it as appropriate. The error message doesn't really seem appropriate - it may well be a recognized option, you just can't set it to that value in that way. Ideally there would be a way for the validation logic to supply a meaningful error message. In its absence the top-level message should reflect the new type of error. Also some of the failures lead to crashes - which seems wrong to me - see below. ---- src/share/vm/services/management.cpp: 1821 if (!succeed) { 1822 THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), 1823 "This flag is not writeable with this value or origin."); That's a rather cryptic error message. How about: "Flag can not be set to the requested value using this API" ? ---- src/share/vm/runtime/globals_ext.hpp With all the inline bool Flag::is_valid_ext_T(T value, FlagValueOrigin origin) functions, is it necessary to include the type T in the function name? ----- src/share/vm/runtime/globals.cpp The use of the guarantees seems wrong as it means an invalid option will trigger a VM crash rather than a clean exit during initialization. It seems to me that none of the code in arguments.cpp that uses the FLAG_SET_* macros (which in turn use the CommandLineFlagsEx functions you added the guarantees to) anticipates any possibility for failure. I think if you are going this path then you have no choice but to change the CommandLineFlagsEx methods to return bool and update the FLAG_SET macros to try and perform appropriate error handling. David ----- > A simple use case for validation is a manageable flag whose current value can not be less than the previous value, while a more complex example may base the validation on multiple other flags, etc. > > Thanks, > > /Robert > From robert.ottenhag at oracle.com Tue Jan 17 04:07:50 2012 From: robert.ottenhag at oracle.com (Robert Ottenhag) Date: Tue, 17 Jan 2012 13:07:50 +0100 Subject: RFR (S): 7130391: Add a framework for vendor-specific validation control of setting command-line switches in Hotspot In-Reply-To: <4F14E661.5080405@oracle.com> References: <5a181ad1-ef64-4b00-88ce-69829f2ce80b@default> <4F14E661.5080405@oracle.com> Message-ID: <4F156496.3060206@oracle.com> David, Thanks for the review. On 01/17/2012 04:09 AM, David Holmes wrote: > Hi Robert, > > I've added serviceability to the cc list. Good, will try to remember that ;-) > > On 17/01/2012 12:04 PM, Robert Ottenhag wrote: >> Webrev: http://cr.openjdk.java.net/~rottenha/7130391/webrev.00 >> >> This fix adds optional validation control to the setting of >> command-line switches in Hotspot, and allows it to have >> vendor-specific extensions if necessary. > > Does this imply that the Java management APIs (eg > com.sun.management.VMOption) need to be changed to reflect these > restrictions? Presently VMOptions are either writeable or not, but > this makes them conditionally-writeable. No, since the Java management APIs already cares for conditional writes. According to com.sun.management.HotSpotDiagnosticMXBean.setVMOption() it will throw IllegalArgumentException if the new value is invalid. > >> The design follows the previously added framework for vendor-specific >> command-line switch extensions in CR7117389. >> >> The validation control is handled by new boolean methods >> Flag::is_valid_(value,origin) that are called at the beginning >> of each call to CommandLineFlags[Ex]::AtPut() to verify that >> the new value and origin are valid replacements for the current value >> and origin for this flag. >> >> When parsing the command line options, a failed validation will >> typically result in an error message and exit with "Unrecognized VM >> option ''". When used dynamically using the attach API or >> management API the resulting operation will fail, leaving it up to >> the caller to handle it as appropriate. > > The error message doesn't really seem appropriate - it may well be a > recognized option, you just can't set it to that value in that way. > Ideally there would be a way for the validation logic to supply a > meaningful error message. In its absence the top-level message should > reflect the new type of error. You are absolutely right, but the current fix is in line with the existing bad error messages where any kind of malformatted command line flags results in Unrecognized VM option, whether the reason is an unknown name, bad type semantics (using +- for bool semantics on an integer flag), or if the flag is locked. I will target meaningful error messages for command line parsing in a direct follow up bug to this fix. > > Also some of the failures lead to crashes - which seems wrong to me - > see below. > > ---- > > src/share/vm/services/management.cpp: > > 1821 if (!succeed) { > 1822 THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), > 1823 "This flag is not writeable with this value or > origin."); > > That's a rather cryptic error message. How about: > > "Flag can not be set to the requested value using this API" > > ? Yes, "origin" does not make sense to the upper Java layer. I will use your suggestion. > > ---- > > src/share/vm/runtime/globals_ext.hpp > > With all the > > inline bool Flag::is_valid_ext_T(T value, FlagValueOrigin origin) > > functions, is it necessary to include the type T in the function name? It is necessary if using type safe variants with T value as argument since overloading does not differ between different typedef names that resolves to the same native types, e.g. uintx and uint64_t are both unsigned long int. I am considering a condensed variant that replaces T by void* instead, and do the type casting based on the targeted flag, reducing the number of functions. > > > ----- > > src/share/vm/runtime/globals.cpp > > The use of the guarantees seems wrong as it means an invalid option > will trigger a VM crash rather than a clean exit during > initialization. It seems to me that none of the code in arguments.cpp > that uses the FLAG_SET_* macros (which in turn use the > CommandLineFlagsEx functions you added the guarantees to) anticipates > any possibility for failure. I think if you are going this path then > you have no choice but to change the CommandLineFlagsEx methods to > return bool and update the FLAG_SET macros to try and perform > appropriate error handling. I see your point, and in theory such as VM crash could occur anytime later in a JVM session if rarely running code would make use of FLAG_SET_* to change the value of a VM flag to an invalid value or origin. Seems as if the options are either to a) ignore validation tests for the FLAG_SET_* macros, and trust that they always set valid values. This can be partly verified by static code inspection by looking for any variables that actually have validation logic associated to them (since the variable name is defined at compile time), assuming one has access to all code, but it is not perfect in case code for changing a variable with validation logic exists. b) contain the error handling within the FLAG_SET_* macros, like using guarantee(), but maybe exception logic can help? c) require usage of the FLAG_SET_* macros to handle result codes and pass it up the call chain. Also, the current macro FLAG_SET_DEFAULT does a direct write to the flag value without going through AtPut(). This macro must be rewritten to have validation control to close the holes. The current call format will require all call sites to include type name as with FLAG_SET_{CMDLINE,ERGO} has, or to use slower lookup by variable name. /Robert > > David > ----- > > >> A simple use case for validation is a manageable flag whose current >> value can not be less than the previous value, while a more complex >> example may base the validation on multiple other flags, etc. >> >> Thanks, >> >> /Robert >> -- Oracle Robert Ottenhag | Senior Member of Technical Staff Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161 Oracle Java HotSpot Virtual Machine ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254-6746 Green Oracle Oracle is committed to developing practices and products that help protect the environment -- From robert.ottenhag at oracle.com Tue Jan 17 05:41:37 2012 From: robert.ottenhag at oracle.com (Robert Ottenhag) Date: Tue, 17 Jan 2012 14:41:37 +0100 Subject: RFR (S): 7130391: Add a framework for vendor-specific validation control of setting command-line switches in Hotspot In-Reply-To: <4F156496.3060206@oracle.com> References: <5a181ad1-ef64-4b00-88ce-69829f2ce80b@default> <4F14E661.5080405@oracle.com> <4F156496.3060206@oracle.com> Message-ID: <4F157A91.8080907@oracle.com> David, Regarding the FLAG_SET_* macros, I am thinking that we can leave them to a follow up bug instead. The reason is that it can be verified by code inspection (of preprocessed sources) if any FLAG_SET_* macro writes to a variable known to have validation control. Also, fixing that hole would require any access to the variables to occur through interface get/set functions, preventing direct read and write access (wrapping the variable in a class to prevent direct writes), a change too intrusive for now. Will come back with an updated and cleaned up patch. /Robert On 01/17/2012 01:07 PM, Robert Ottenhag wrote: > David, > > Thanks for the review. > > On 01/17/2012 04:09 AM, David Holmes wrote: >> Hi Robert, >> >> I've added serviceability to the cc list. > > Good, will try to remember that ;-) > >> >> On 17/01/2012 12:04 PM, Robert Ottenhag wrote: >>> Webrev: http://cr.openjdk.java.net/~rottenha/7130391/webrev.00 >>> >>> This fix adds optional validation control to the setting of >>> command-line switches in Hotspot, and allows it to have >>> vendor-specific extensions if necessary. >> >> Does this imply that the Java management APIs (eg >> com.sun.management.VMOption) need to be changed to reflect these >> restrictions? Presently VMOptions are either writeable or not, but >> this makes them conditionally-writeable. > > No, since the Java management APIs already cares for conditional > writes. According to > com.sun.management.HotSpotDiagnosticMXBean.setVMOption() it will throw > IllegalArgumentException if the new value is invalid. > >> >>> The design follows the previously added framework for >>> vendor-specific command-line switch extensions in CR7117389. >>> >>> The validation control is handled by new boolean methods >>> Flag::is_valid_(value,origin) that are called at the beginning >>> of each call to CommandLineFlags[Ex]::AtPut() to verify that >>> the new value and origin are valid replacements for the current >>> value and origin for this flag. >>> >>> When parsing the command line options, a failed validation will >>> typically result in an error message and exit with "Unrecognized VM >>> option ''". When used dynamically using the attach API >>> or management API the resulting operation will fail, leaving it up >>> to the caller to handle it as appropriate. >> >> The error message doesn't really seem appropriate - it may well be a >> recognized option, you just can't set it to that value in that way. >> Ideally there would be a way for the validation logic to supply a >> meaningful error message. In its absence the top-level message should >> reflect the new type of error. > > You are absolutely right, but the current fix is in line with the > existing bad error messages where any kind of malformatted command > line flags results in Unrecognized VM option, whether the reason is an > unknown name, bad type semantics (using +- for bool semantics on an > integer flag), or if the flag is locked. > > I will target meaningful error messages for command line parsing in a > direct follow up bug to this fix. > >> >> Also some of the failures lead to crashes - which seems wrong to me - >> see below. >> >> ---- >> >> src/share/vm/services/management.cpp: >> >> 1821 if (!succeed) { >> 1822 THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), >> 1823 "This flag is not writeable with this value or >> origin."); >> >> That's a rather cryptic error message. How about: >> >> "Flag can not be set to the requested value using this API" >> >> ? > > Yes, "origin" does not make sense to the upper Java layer. I will use > your suggestion. > >> >> ---- >> >> src/share/vm/runtime/globals_ext.hpp >> >> With all the >> >> inline bool Flag::is_valid_ext_T(T value, FlagValueOrigin origin) >> >> functions, is it necessary to include the type T in the function name? > > It is necessary if using type safe variants with T value as argument > since overloading does not differ between different typedef names that > resolves to the same native types, e.g. uintx and uint64_t are both > unsigned long int. > > I am considering a condensed variant that replaces T by void* instead, > and do the type casting based on the targeted flag, reducing the > number of functions. > >> >> >> ----- >> >> src/share/vm/runtime/globals.cpp >> >> The use of the guarantees seems wrong as it means an invalid option >> will trigger a VM crash rather than a clean exit during >> initialization. It seems to me that none of the code in arguments.cpp >> that uses the FLAG_SET_* macros (which in turn use the >> CommandLineFlagsEx functions you added the guarantees to) anticipates >> any possibility for failure. I think if you are going this path then >> you have no choice but to change the CommandLineFlagsEx methods to >> return bool and update the FLAG_SET macros to try and perform >> appropriate error handling. > > I see your point, and in theory such as VM crash could occur anytime > later in a JVM session if rarely running code would make use of > FLAG_SET_* to change the value of a VM flag to an invalid value or > origin. > > Seems as if the options are either to > a) ignore validation tests for the FLAG_SET_* macros, and trust that > they always set valid values. This can be partly verified by static > code inspection by looking for any variables that actually have > validation logic associated to them (since the variable name is > defined at compile time), assuming one has access to all code, but it > is not perfect in case code for changing a variable with validation > logic exists. > b) contain the error handling within the FLAG_SET_* macros, like using > guarantee(), but maybe exception logic can help? > c) require usage of the FLAG_SET_* macros to handle result codes and > pass it up the call chain. > > Also, the current macro FLAG_SET_DEFAULT does a direct write to the > flag value without going through AtPut(). This macro must be > rewritten to have validation control to close the holes. The current > call format will require all call sites to include type name as with > FLAG_SET_{CMDLINE,ERGO} has, or to use slower lookup by variable name. > > /Robert > >> >> David >> ----- >> >> >>> A simple use case for validation is a manageable flag whose current >>> value can not be less than the previous value, while a more complex >>> example may base the validation on multiple other flags, etc. >>> >>> Thanks, >>> >>> /Robert >>> > > -- Oracle Robert Ottenhag | Senior Member of Technical Staff Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161 Oracle Java HotSpot Virtual Machine ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254-6746 Green Oracle Oracle is committed to developing practices and products that help protect the environment -- From chris.hegarty at oracle.com Tue Jan 17 08:51:18 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 17 Jan 2012 16:51:18 +0000 Subject: hg: jdk8/tl/jdk: 6671616: TEST_BUG: java/io/File/BlockIsDirectory.java fails when /dev/dsk empty (sol) Message-ID: <20120117165139.0ECB64799E@hg.openjdk.java.net> Changeset: 40d699d7f6a1 Author: chegar Date: 2012-01-17 14:10 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40d699d7f6a1 6671616: TEST_BUG: java/io/File/BlockIsDirectory.java fails when /dev/dsk empty (sol) Reviewed-by: alanb ! test/ProblemList.txt - test/java/io/File/BlockIsDirectory.java From jim.holmlund at sun.com Tue Jan 17 17:19:44 2012 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Wed, 18 Jan 2012 01:19:44 +0000 Subject: hg: jdk8/tl/langtools: 7127924: langtools regression tests sometimes fail en-masse on windows Message-ID: <20120118011947.69437479AC@hg.openjdk.java.net> Changeset: 1e2f4f4fb9f7 Author: jjh Date: 2012-01-17 17:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1e2f4f4fb9f7 7127924: langtools regression tests sometimes fail en-masse on windows Reviewed-by: jjg ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/RunExamples.java From mandy.chung at oracle.com Tue Jan 17 18:03:55 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 18 Jan 2012 02:03:55 +0000 Subject: hg: jdk8/tl/jdk: 7117570: Warnings in sun.mangement.* and its subpackages Message-ID: <20120118020408.796D4479AE@hg.openjdk.java.net> Changeset: 2f096eb72520 Author: mchung Date: 2012-01-17 15:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2f096eb72520 7117570: Warnings in sun.mangement.* and its subpackages Reviewed-by: mchung, dsamersoff Contributed-by: kurchi.subhra.hazra at oracle.com ! src/share/classes/sun/management/Agent.java ! src/share/classes/sun/management/ConnectorAddressLink.java ! src/share/classes/sun/management/Flag.java ! src/share/classes/sun/management/GarbageCollectionNotifInfoCompositeData.java ! src/share/classes/sun/management/GarbageCollectorImpl.java ! src/share/classes/sun/management/GcInfoBuilder.java ! src/share/classes/sun/management/GcInfoCompositeData.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/classes/sun/management/HotspotCompilation.java ! src/share/classes/sun/management/HotspotThread.java ! src/share/classes/sun/management/LazyCompositeData.java ! src/share/classes/sun/management/ManagementFactoryHelper.java ! src/share/classes/sun/management/MappedMXBeanType.java ! src/share/classes/sun/management/MonitorInfoCompositeData.java ! src/share/classes/sun/management/NotificationEmitterSupport.java ! src/share/classes/sun/management/RuntimeImpl.java ! src/share/classes/sun/management/ThreadInfoCompositeData.java ! src/share/classes/sun/management/counter/perf/PerfInstrumentation.java ! src/share/classes/sun/management/jmxremote/ConnectorBootstrap.java ! src/share/classes/sun/management/snmp/AdaptorBootstrap.java ! src/share/classes/sun/management/snmp/jvminstr/JVM_MANAGEMENT_MIB_IMPL.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemGCTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemManagerTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemMgrPoolRelTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemPoolTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmOSImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRuntimeMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadingMetaImpl.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmClassesVerboseLevel.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmJITCompilerTimeMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemManagerState.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolCollectThreshdSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolState.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolThreshdSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolType.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCCall.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCVerboseLevel.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmRTBootClassPathSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadContentionMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadCpuTimeMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIB.java ! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIBOidTable.java ! src/share/classes/sun/management/snmp/jvmmib/JvmClassLoadingMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmCompilationMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmOSMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRuntimeMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadingMeta.java ! src/share/classes/sun/management/snmp/util/MibLogger.java ! src/share/classes/sun/management/snmp/util/SnmpListTableCache.java ! src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java ! src/share/classes/sun/management/snmp/util/SnmpTableCache.java From zhengyu.gu at oracle.com Tue Jan 17 18:21:04 2012 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Wed, 18 Jan 2012 02:21:04 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7071311: Decoder enhancement Message-ID: <20120118022110.3E448479AF@hg.openjdk.java.net> Changeset: d7e3846464d0 Author: zgu Date: 2012-01-17 13:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d7e3846464d0 7071311: Decoder enhancement Summary: Made decoder thread-safe Reviewed-by: coleenp, kamg - src/os/bsd/vm/decoder_bsd.cpp + src/os/bsd/vm/decoder_machO.cpp + src/os/bsd/vm/decoder_machO.hpp ! src/os/linux/vm/decoder_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/decoder_solaris.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/decoder_windows.cpp + src/os/windows/vm/decoder_windows.hpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp + src/share/vm/utilities/decoder_elf.cpp + src/share/vm/utilities/decoder_elf.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp ! src/share/vm/utilities/elfStringTable.cpp ! src/share/vm/utilities/elfStringTable.hpp ! src/share/vm/utilities/elfSymbolTable.cpp ! src/share/vm/utilities/elfSymbolTable.hpp ! src/share/vm/utilities/vmError.cpp From david.holmes at oracle.com Tue Jan 17 19:36:55 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Jan 2012 13:36:55 +1000 Subject: RFR (S): 7130391: Add a framework for vendor-specific validation control of setting command-line switches in Hotspot In-Reply-To: <4F156496.3060206@oracle.com> References: <5a181ad1-ef64-4b00-88ce-69829f2ce80b@default> <4F14E661.5080405@oracle.com> <4F156496.3060206@oracle.com> Message-ID: <4F163E57.5010401@oracle.com> Hi Robert, Comments inline ... On 17/01/2012 10:07 PM, Robert Ottenhag wrote: >> On 17/01/2012 12:04 PM, Robert Ottenhag wrote: >>> Webrev: http://cr.openjdk.java.net/~rottenha/7130391/webrev.00 >>> >>> This fix adds optional validation control to the setting of >>> command-line switches in Hotspot, and allows it to have >>> vendor-specific extensions if necessary. >> >> Does this imply that the Java management APIs (eg >> com.sun.management.VMOption) need to be changed to reflect these >> restrictions? Presently VMOptions are either writeable or not, but >> this makes them conditionally-writeable. > > No, since the Java management APIs already cares for conditional writes. > According to com.sun.management.HotSpotDiagnosticMXBean.setVMOption() it > will throw IllegalArgumentException if the new value is invalid. I think there is a significant difference between trying to set an invalid value and setting to a valid value at a time that it is not permitted. >> src/share/vm/runtime/globals_ext.hpp >> >> With all the >> >> inline bool Flag::is_valid_ext_T(T value, FlagValueOrigin origin) >> >> functions, is it necessary to include the type T in the function name? > > It is necessary if using type safe variants with T value as argument > since overloading does not differ between different typedef names that > resolves to the same native types, e.g. uintx and uint64_t are both > unsigned long int. > > I am considering a condensed variant that replaces T by void* instead, > and do the type casting based on the targeted flag, reducing the number > of functions. Ok. I thought there might be some conflict with the integral types. >> src/share/vm/runtime/globals.cpp >> >> The use of the guarantees seems wrong as it means an invalid option >> will trigger a VM crash rather than a clean exit during >> initialization. It seems to me that none of the code in arguments.cpp >> that uses the FLAG_SET_* macros (which in turn use the >> CommandLineFlagsEx functions you added the guarantees to) anticipates >> any possibility for failure. I think if you are going this path then >> you have no choice but to change the CommandLineFlagsEx methods to >> return bool and update the FLAG_SET macros to try and perform >> appropriate error handling. > > I see your point, and in theory such as VM crash could occur anytime > later in a JVM session if rarely running code would make use of > FLAG_SET_* to change the value of a VM flag to an invalid value or origin. > > Seems as if the options are either to > a) ignore validation tests for the FLAG_SET_* macros, and trust that > they always set valid values. This can be partly verified by static code > inspection by looking for any variables that actually have validation > logic associated to them (since the variable name is defined at compile > time), assuming one has access to all code, but it is not perfect in > case code for changing a variable with validation logic exists. > b) contain the error handling within the FLAG_SET_* macros, like using > guarantee(), but maybe exception logic can help? > c) require usage of the FLAG_SET_* macros to handle result codes and > pass it up the call chain. > > Also, the current macro FLAG_SET_DEFAULT does a direct write to the flag > value without going through AtPut(). This macro must be rewritten > to have validation control to close the holes. The current call format > will require all call sites to include type name as with > FLAG_SET_{CMDLINE,ERGO} has, or to use slower lookup by variable name. I think you touched on the real problem in your later email - really these flags/options and the ways you can interact with them should be encapsulated in objects. Each different flag can then define its valid values, whether it is "locked", "writeable" etc. But that means every use of those flags in the VM would need changing - which is indeed a very intrusive change. But I can't help but feel that we are going to far in what we are trying to do with these flags when they are in fact simple variables. Also I think we may be overcomplicating this. I don't see why we can't consider the uses of the flags at initialization time and runtime to be distinct use-cases and use different APIs to interact with them. For initialization we have the FLAGS_SET_* macros, and the end result is that we have a set of flags that are either at their default values or have been set to a valid value. I don't think we need to consider (as I believe the current proposal does) multiple settings of a given flag at initialization time ie: java -XX:+UseFoo ... -XX:-UseFoo ... -XX:+UseFoo should simply result in UseFoo==true. Even if we have stated that once UseFoo is turned on it can't be turned off again. To me that should only relate to true "dynamic" runtime setting of the flags. In which case only the management APIs need to be augmented to support this and we may be able to create "shadow" objects for flags we need to handle specially at runtime. David ----- > /Robert > >> >> David >> ----- >> >> >>> A simple use case for validation is a manageable flag whose current >>> value can not be less than the previous value, while a more complex >>> example may base the validation on multiple other flags, etc. >>> >>> Thanks, >>> >>> /Robert >>> > > From keith.mcguigan at oracle.com Tue Jan 17 21:08:55 2012 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Wed, 18 Jan 2012 05:08:55 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 28 new changesets Message-ID: <20120118050949.D0361479B0@hg.openjdk.java.net> Changeset: 8f8b94305aff Author: dcubed Date: 2012-01-11 19:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8f8b94305aff 7129240: backout fix for 7102776 until 7128770 is resolved Reviewed-by: phh, bobv, coleenp, dcubed Contributed-by: Jiangli Zhou ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: efdf6985a3a2 Author: kamg Date: 2012-01-12 09:59 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/efdf6985a3a2 Merge Changeset: 5da7201222d5 Author: kvn Date: 2012-01-07 10:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5da7201222d5 7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM Summary: Change yank_if_dead() to recursive method to remove all dead inputs. Reviewed-by: never ! src/cpu/sparc/vm/sparc.ad ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/postaloc.cpp Changeset: e9a5e0a812c8 Author: kvn Date: 2012-01-07 13:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e9a5e0a812c8 7125896: Eliminate nested locks Summary: Nested locks elimination done before lock nodes expansion by looking for outer locks of the same object. Reviewed-by: never, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/ci/ciTypeFlow.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp Changeset: 35acf8f0a2e4 Author: kvn Date: 2012-01-10 18:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/35acf8f0a2e4 7128352: assert(obj_node == obj) failed Summary: Compare uncasted object nodes. Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/subnode.cpp ! test/compiler/7116216/StackOverflow.java Changeset: c8d8e124380c Author: kvn Date: 2012-01-12 12:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c8d8e124380c 7064302: JDK7 build 147 crashed after testing my java 6-compiled web app Summary: Don't split CMove node if it's control edge is different from split region. Reviewed-by: never ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp Changeset: 31a5b9aad4bc Author: jrose Date: 2012-01-13 00:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/31a5b9aad4bc Merge ! src/share/vm/runtime/arguments.cpp Changeset: bacb651cf5bf Author: tonyp Date: 2012-01-05 05:54 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/bacb651cf5bf 7113006: G1: excessive ergo output when an evac failure happens Summary: Introduce a flag that is set when a heap expansion attempt during a GC fails so that we do not consantly attempt to expand the heap when it's going to fail anyway. This not only prevents the excessive ergo output (which is generated when a region allocation fails) but also avoids excessive and ultimately unsuccessful expansion attempts. Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 5fd354a959c5 Author: jmasa Date: 2012-01-05 21:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5fd354a959c5 Merge Changeset: 023652e49ac0 Author: johnc Date: 2011-12-23 11:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/023652e49ac0 7121496: G1: do the per-region evacuation failure handling work in parallel Summary: Parallelize the removal of self forwarding pointers etc. by wrapping in a HeapRegion closure, which is then wrapped inside an AbstractGangTask. Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp + src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 02838862dec8 Author: tonyp Date: 2012-01-07 00:43 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/02838862dec8 7121623: G1: always be able to reliably calculate the length of a forwarded chunked array Summary: Store the "next chunk start index" in the length field of the to-space object, instead of the from-space object, so that we can always reliably read the size of all from-space objects. Reviewed-by: johnc, ysr, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 97c00e21fecb Author: tonyp Date: 2012-01-09 23:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/97c00e21fecb 7125281: G1: heap expansion code is replicated Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 1d6185f732aa Author: brutisso Date: 2012-01-10 20:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1d6185f732aa 7128532: G1: Change default value of G1DefaultMaxNewGenPercent to 80 Reviewed-by: tonyp, jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 2ace1c4ee8da Author: tonyp Date: 2012-01-10 18:58 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2ace1c4ee8da 6888336: G1: avoid explicitly marking and pushing objects in survivor spaces Summary: This change simplifies the interaction between GC and concurrent marking. By disabling survivor spaces during the initial-mark pause we don't need to propagate marks of objects we copy during each GC (since we never need to copy an explicitly marked object). Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegion.inline.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp Changeset: 9d4f4a1825e4 Author: brutisso Date: 2012-01-13 01:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9d4f4a1825e4 Merge Changeset: 5acd82522540 Author: brutisso Date: 2012-01-13 06:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5acd82522540 Merge Changeset: b0ff910edfc9 Author: kvn Date: 2012-01-12 14:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b0ff910edfc9 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed Summary: Do not common BoxLock nodes and avoid creating phis of boxes. Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/parse1.cpp Changeset: f4d8930a45b9 Author: jrose Date: 2012-01-13 00:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f4d8930a45b9 Merge Changeset: 89d0a5d40008 Author: kvn Date: 2012-01-13 12:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/89d0a5d40008 7129618: assert(obj_node->eqv_uncast(obj),""); Summary: Relax verification and locks elimination checks for new implementation (EliminateNestedLocks). Reviewed-by: iveresov ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/macro.cpp Changeset: e504fd26c073 Author: kvn Date: 2012-01-13 14:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e504fd26c073 Merge Changeset: fe2c87649981 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/fe2c87649981 Added tag jdk8-b19 for changeset 9232e0ecbc2c ! .hgtags Changeset: 9952d1c439d6 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9952d1c439d6 Added tag jdk8-b20 for changeset fe2c87649981 ! .hgtags Changeset: ed621d125d02 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ed621d125d02 Added tag jdk8-b21 for changeset 9952d1c439d6 ! .hgtags Changeset: 513351373923 Author: amurillo Date: 2012-01-14 00:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/513351373923 Merge Changeset: 24727fb37561 Author: amurillo Date: 2012-01-14 00:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/24727fb37561 Added tag hs23-b10 for changeset 513351373923 ! .hgtags Changeset: 4e80db53c323 Author: amurillo Date: 2012-01-14 00:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4e80db53c323 7129512: new hotspot build - hs23-b11 Reviewed-by: jcoomes ! make/hotspot_version Changeset: f1cd52d6ce02 Author: kamg Date: 2012-01-17 10:16 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f1cd52d6ce02 Merge Changeset: 6520f9861937 Author: kamg Date: 2012-01-17 21:25 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6520f9861937 Merge From robert.ottenhag at oracle.com Wed Jan 18 06:33:13 2012 From: robert.ottenhag at oracle.com (Robert Ottenhag) Date: Wed, 18 Jan 2012 15:33:13 +0100 Subject: RFR (S): 7130391: Add a framework for vendor-specific validation control of setting command-line switches in Hotspot In-Reply-To: <4F163E57.5010401@oracle.com> References: <5a181ad1-ef64-4b00-88ce-69829f2ce80b@default> <4F14E661.5080405@oracle.com> <4F156496.3060206@oracle.com> <4F163E57.5010401@oracle.com> Message-ID: <4F16D829.7090201@oracle.com> Hi David, More comments inline... On 01/18/2012 04:36 AM, David Holmes wrote: > Hi Robert, > > Comments inline ... > > On 17/01/2012 10:07 PM, Robert Ottenhag wrote: >>> On 17/01/2012 12:04 PM, Robert Ottenhag wrote: >>>> Webrev: http://cr.openjdk.java.net/~rottenha/7130391/webrev.00 >>>> >>>> This fix adds optional validation control to the setting of >>>> command-line switches in Hotspot, and allows it to have >>>> vendor-specific extensions if necessary. >>> >>> Does this imply that the Java management APIs (eg >>> com.sun.management.VMOption) need to be changed to reflect these >>> restrictions? Presently VMOptions are either writeable or not, but >>> this makes them conditionally-writeable. >> >> No, since the Java management APIs already cares for conditional writes. >> According to com.sun.management.HotSpotDiagnosticMXBean.setVMOption() it >> will throw IllegalArgumentException if the new value is invalid. > > I think there is a significant difference between trying to set an > invalid value and setting to a valid value at a time that it is not > permitted. Agreed. There is a semantic difference here that can be confusing. > >>> src/share/vm/runtime/globals.cpp >>> >>> The use of the guarantees seems wrong as it means an invalid option >>> will trigger a VM crash rather than a clean exit during >>> initialization. It seems to me that none of the code in arguments.cpp >>> that uses the FLAG_SET_* macros (which in turn use the >>> CommandLineFlagsEx functions you added the guarantees to) anticipates >>> any possibility for failure. I think if you are going this path then >>> you have no choice but to change the CommandLineFlagsEx methods to >>> return bool and update the FLAG_SET macros to try and perform >>> appropriate error handling. >> >> I see your point, and in theory such as VM crash could occur anytime >> later in a JVM session if rarely running code would make use of >> FLAG_SET_* to change the value of a VM flag to an invalid value or >> origin. >> >> Seems as if the options are either to >> a) ignore validation tests for the FLAG_SET_* macros, and trust that >> they always set valid values. This can be partly verified by static code >> inspection by looking for any variables that actually have validation >> logic associated to them (since the variable name is defined at compile >> time), assuming one has access to all code, but it is not perfect in >> case code for changing a variable with validation logic exists. >> b) contain the error handling within the FLAG_SET_* macros, like using >> guarantee(), but maybe exception logic can help? >> c) require usage of the FLAG_SET_* macros to handle result codes and >> pass it up the call chain. >> >> Also, the current macro FLAG_SET_DEFAULT does a direct write to the flag >> value without going through AtPut(). This macro must be rewritten >> to have validation control to close the holes. The current call format >> will require all call sites to include type name as with >> FLAG_SET_{CMDLINE,ERGO} has, or to use slower lookup by variable name. > > I think you touched on the real problem in your later email - really > these flags/options and the ways you can interact with them should be > encapsulated in objects. Each different flag can then define its valid > values, whether it is "locked", "writeable" etc. But that means every > use of those flags in the VM would need changing - which is indeed a > very intrusive change. We might be able to keep existing usage by encapsulating it within a class that overrides the assignment and type conversion operators, but as you say it is a little more work than expected right now. > > But I can't help but feel that we are going to far in what we are > trying to do with these flags when they are in fact simple variables. > > Also I think we may be overcomplicating this. I don't see why we can't > consider the uses of the flags at initialization time and runtime to > be distinct use-cases and use different APIs to interact with them. > For initialization we have the FLAGS_SET_* macros, and the end result > is that we have a set of flags that are either at their default values > or have been set to a valid value. I don't think we need to consider > (as I believe the current proposal does) multiple settings of a given > flag at initialization time ie: > > java -XX:+UseFoo ... -XX:-UseFoo ... -XX:+UseFoo > > should simply result in UseFoo==true. Even if we have stated that once > UseFoo is turned on it can't be turned off again. To me that should > only relate to true "dynamic" runtime setting of the flags. In which > case only the management APIs need to be augmented to support this and > we may be able to create "shadow" objects for flags we need to handle > specially at runtime. The problem with the FLAG_SET_* macros is that they can also be used after initialization, or for that matter direct variable assignment can be also done, to bypass any validation logic that is observed by the dynamic interfaces. However, at this point I am also leaning towards a design that only focuses on the dynamic setting, which will not change existing behavior of command line flags parsing, i.e. any variable is writable with any value during the initialization phase. > > David > ----- > >> /Robert >> >>> >>> David >>> ----- >>> >>> >>>> A simple use case for validation is a manageable flag whose current >>>> value can not be less than the previous value, while a more complex >>>> example may base the validation on multiple other flags, etc. >>>> >>>> Thanks, >>>> >>>> /Robert >>>> >> >> -- Oracle Robert Ottenhag | Senior Member of Technical Staff Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161 Oracle Java HotSpot Virtual Machine ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254-6746 Green Oracle Oracle is committed to developing practices and products that help protect the environment -- From robert.ottenhag at oracle.com Wed Jan 18 07:00:30 2012 From: robert.ottenhag at oracle.com (Robert Ottenhag) Date: Wed, 18 Jan 2012 16:00:30 +0100 Subject: RFR (S): 7130391: Add a framework for vendor-specific validation control of setting command-line switches in Hotspot In-Reply-To: <4F157A91.8080907@oracle.com> References: <5a181ad1-ef64-4b00-88ce-69829f2ce80b@default> <4F14E661.5080405@oracle.com> <4F156496.3060206@oracle.com> <4F157A91.8080907@oracle.com> Message-ID: <4F16DE8E.1090609@oracle.com> Updated webrev: http://cr.openjdk.java.net/~rottenha/7130391/webrev.01 Changes to the previous version are: * src/share/vm/runtime/globals.cpp: Remove validation control from AtPut(CommandLineFlagsWithType, ...), that is only used by FLAG_SET_* macros in globals_extension.hpp. * src/share/vm/runtime/{globals.hpp, globals.cpp, globals_ext.hpp}: Replace multiple public type safe functions Flag::is_valid[_ext]_( value, ...) by single protected type generic functions CommandLineFlags::is_valid[_ext (const Flag*, const void*, ...), then do internal type casts on the values based on the type of the targeted flag (and assert on type correctness). * src/share/vm/services/management.cpp: Use a better error message (David Holmes). /Robert On 01/17/2012 02:41 PM, Robert Ottenhag wrote: > David, > > Regarding the FLAG_SET_* macros, I am thinking that we can leave them > to a follow up bug instead. > > The reason is that it can be verified by code inspection (of > preprocessed sources) if any FLAG_SET_* macro writes to a variable > known to have validation control. > > Also, fixing that hole would require any access to the variables to > occur through interface get/set functions, preventing direct read and > write access (wrapping the variable in a class to prevent direct > writes), a change too intrusive for now. > > Will come back with an updated and cleaned up patch. > > /Robert > > On 01/17/2012 01:07 PM, Robert Ottenhag wrote: >> David, >> >> Thanks for the review. >> >> On 01/17/2012 04:09 AM, David Holmes wrote: >>> Hi Robert, >>> >>> I've added serviceability to the cc list. >> >> Good, will try to remember that ;-) >> >>> >>> On 17/01/2012 12:04 PM, Robert Ottenhag wrote: >>>> Webrev: http://cr.openjdk.java.net/~rottenha/7130391/webrev.00 >>>> >>>> This fix adds optional validation control to the setting of >>>> command-line switches in Hotspot, and allows it to have >>>> vendor-specific extensions if necessary. >>> >>> Does this imply that the Java management APIs (eg >>> com.sun.management.VMOption) need to be changed to reflect these >>> restrictions? Presently VMOptions are either writeable or not, but >>> this makes them conditionally-writeable. >> >> No, since the Java management APIs already cares for conditional >> writes. According to >> com.sun.management.HotSpotDiagnosticMXBean.setVMOption() it will >> throw IllegalArgumentException if the new value is invalid. >> >>> >>>> The design follows the previously added framework for >>>> vendor-specific command-line switch extensions in CR7117389. >>>> >>>> The validation control is handled by new boolean methods >>>> Flag::is_valid_(value,origin) that are called at the >>>> beginning of each call to CommandLineFlags[Ex]::AtPut() to >>>> verify that the new value and origin are valid replacements for the >>>> current value and origin for this flag. >>>> >>>> When parsing the command line options, a failed validation will >>>> typically result in an error message and exit with "Unrecognized VM >>>> option ''". When used dynamically using the attach API >>>> or management API the resulting operation will fail, leaving it up >>>> to the caller to handle it as appropriate. >>> >>> The error message doesn't really seem appropriate - it may well be a >>> recognized option, you just can't set it to that value in that way. >>> Ideally there would be a way for the validation logic to supply a >>> meaningful error message. In its absence the top-level message >>> should reflect the new type of error. >> >> You are absolutely right, but the current fix is in line with the >> existing bad error messages where any kind of malformatted command >> line flags results in Unrecognized VM option, whether the reason is >> an unknown name, bad type semantics (using +- for bool semantics on >> an integer flag), or if the flag is locked. >> >> I will target meaningful error messages for command line parsing in a >> direct follow up bug to this fix. >> >>> >>> Also some of the failures lead to crashes - which seems wrong to me >>> - see below. >>> >>> ---- >>> >>> src/share/vm/services/management.cpp: >>> >>> 1821 if (!succeed) { >>> 1822 THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), >>> 1823 "This flag is not writeable with this value or >>> origin."); >>> >>> That's a rather cryptic error message. How about: >>> >>> "Flag can not be set to the requested value using this API" >>> >>> ? >> >> Yes, "origin" does not make sense to the upper Java layer. I will use >> your suggestion. >> >>> >>> ---- >>> >>> src/share/vm/runtime/globals_ext.hpp >>> >>> With all the >>> >>> inline bool Flag::is_valid_ext_T(T value, FlagValueOrigin origin) >>> >>> functions, is it necessary to include the type T in the function name? >> >> It is necessary if using type safe variants with T value as argument >> since overloading does not differ between different typedef names >> that resolves to the same native types, e.g. uintx and uint64_t are >> both unsigned long int. >> >> I am considering a condensed variant that replaces T by void* >> instead, and do the type casting based on the targeted flag, reducing >> the number of functions. >> >>> >>> >>> ----- >>> >>> src/share/vm/runtime/globals.cpp >>> >>> The use of the guarantees seems wrong as it means an invalid option >>> will trigger a VM crash rather than a clean exit during >>> initialization. It seems to me that none of the code in >>> arguments.cpp that uses the FLAG_SET_* macros (which in turn use the >>> CommandLineFlagsEx functions you added the guarantees to) >>> anticipates any possibility for failure. I think if you are going >>> this path then you have no choice but to change the >>> CommandLineFlagsEx methods to return bool and update the FLAG_SET >>> macros to try and perform appropriate error handling. >> >> I see your point, and in theory such as VM crash could occur anytime >> later in a JVM session if rarely running code would make use of >> FLAG_SET_* to change the value of a VM flag to an invalid value or >> origin. >> >> Seems as if the options are either to >> a) ignore validation tests for the FLAG_SET_* macros, and trust that >> they always set valid values. This can be partly verified by static >> code inspection by looking for any variables that actually have >> validation logic associated to them (since the variable name is >> defined at compile time), assuming one has access to all code, but it >> is not perfect in case code for changing a variable with validation >> logic exists. >> b) contain the error handling within the FLAG_SET_* macros, like >> using guarantee(), but maybe exception logic can help? >> c) require usage of the FLAG_SET_* macros to handle result codes and >> pass it up the call chain. >> >> Also, the current macro FLAG_SET_DEFAULT does a direct write to the >> flag value without going through AtPut(). This macro must be >> rewritten to have validation control to close the holes. The current >> call format will require all call sites to include type name as with >> FLAG_SET_{CMDLINE,ERGO} has, or to use slower lookup by variable name. >> >> /Robert >> >>> >>> David >>> ----- >>> >>> >>>> A simple use case for validation is a manageable flag whose current >>>> value can not be less than the previous value, while a more complex >>>> example may base the validation on multiple other flags, etc. >>>> >>>> Thanks, >>>> >>>> /Robert >>>> >> >> > > -- Oracle Robert Ottenhag | Senior Member of Technical Staff Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161 Oracle Java HotSpot Virtual Machine ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254-6746 Green Oracle Oracle is committed to developing practices and products that help protect the environment -- From lana.steuck at oracle.com Wed Jan 18 12:17:07 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 18 Jan 2012 20:17:07 +0000 Subject: hg: jdk8/tl: 3 new changesets Message-ID: <20120118201708.06880479C2@hg.openjdk.java.net> Changeset: 5a5eaf6374bc Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/5a5eaf6374bc Added tag jdk8-b19 for changeset 237bc29afbfc ! .hgtags Changeset: cc771d92284f Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/cc771d92284f Added tag jdk8-b20 for changeset 5a5eaf6374bc ! .hgtags Changeset: 7ad075c80995 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7ad075c80995 Added tag jdk8-b21 for changeset cc771d92284f ! .hgtags From lana.steuck at oracle.com Wed Jan 18 12:17:06 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 18 Jan 2012 20:17:06 +0000 Subject: hg: jdk8/tl/corba: 3 new changesets Message-ID: <20120118201711.0B5BA479C3@hg.openjdk.java.net> Changeset: 51d8b6cb18c0 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/51d8b6cb18c0 Added tag jdk8-b19 for changeset e1366c5d84ef ! .hgtags Changeset: f157fc2a71a3 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/f157fc2a71a3 Added tag jdk8-b20 for changeset 51d8b6cb18c0 ! .hgtags Changeset: a11d0062c445 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/a11d0062c445 Added tag jdk8-b21 for changeset f157fc2a71a3 ! .hgtags From lana.steuck at oracle.com Wed Jan 18 12:17:12 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 18 Jan 2012 20:17:12 +0000 Subject: hg: jdk8/tl/jaxws: 5 new changesets Message-ID: <20120118201712.59F05479C4@hg.openjdk.java.net> Changeset: 2b2818e3386f Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/2b2818e3386f Added tag jdk8-b19 for changeset b73b733214aa ! .hgtags Changeset: dc2ee8b87884 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/dc2ee8b87884 Added tag jdk8-b20 for changeset 2b2818e3386f ! .hgtags Changeset: e67d51254533 Author: ohair Date: 2012-01-09 09:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/e67d51254533 7096063: /META-INF/mimetypes.default missing in jre\lib\resources.jar Reviewed-by: dholmes ! build-defs.xml Changeset: c266cab0e3ff Author: katleman Date: 2012-01-11 16:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c266cab0e3ff Merge Changeset: 8d3df89b0f2d Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/8d3df89b0f2d Added tag jdk8-b21 for changeset c266cab0e3ff ! .hgtags From lana.steuck at oracle.com Wed Jan 18 12:17:13 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 18 Jan 2012 20:17:13 +0000 Subject: hg: jdk8/tl/jaxp: 3 new changesets Message-ID: <20120118201713.20293479C5@hg.openjdk.java.net> Changeset: f052abb8f374 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f052abb8f374 Added tag jdk8-b19 for changeset dffeb62b1a7f ! .hgtags Changeset: d41eeadf5c13 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d41eeadf5c13 Added tag jdk8-b20 for changeset f052abb8f374 ! .hgtags Changeset: cf9d6ec44f89 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/cf9d6ec44f89 Added tag jdk8-b21 for changeset d41eeadf5c13 ! .hgtags From lana.steuck at oracle.com Wed Jan 18 12:17:07 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 18 Jan 2012 20:17:07 +0000 Subject: hg: jdk8/tl/hotspot: 3 new changesets Message-ID: <20120118201718.53D4F479C6@hg.openjdk.java.net> Changeset: fe2c87649981 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fe2c87649981 Added tag jdk8-b19 for changeset 9232e0ecbc2c ! .hgtags Changeset: 9952d1c439d6 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9952d1c439d6 Added tag jdk8-b20 for changeset fe2c87649981 ! .hgtags Changeset: ed621d125d02 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ed621d125d02 Added tag jdk8-b21 for changeset 9952d1c439d6 ! .hgtags From lana.steuck at oracle.com Wed Jan 18 12:17:19 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 18 Jan 2012 20:17:19 +0000 Subject: hg: jdk8/tl/langtools: 6 new changesets Message-ID: <20120118201731.998B6479C7@hg.openjdk.java.net> Changeset: ffd294128a48 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ffd294128a48 Added tag jdk8-b19 for changeset 77b2c066084c ! .hgtags Changeset: 020819eb56d2 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/020819eb56d2 Added tag jdk8-b20 for changeset ffd294128a48 ! .hgtags Changeset: 4e8aa6eca726 Author: lana Date: 2012-01-04 10:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4e8aa6eca726 Merge Changeset: bcb21abf1c41 Author: lana Date: 2012-01-09 19:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bcb21abf1c41 Merge Changeset: 390a7828ae18 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/390a7828ae18 Added tag jdk8-b21 for changeset bcb21abf1c41 ! .hgtags Changeset: f00afa80f1f0 Author: lana Date: 2012-01-18 11:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f00afa80f1f0 Merge From lana.steuck at oracle.com Wed Jan 18 12:18:17 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 18 Jan 2012 20:18:17 +0000 Subject: hg: jdk8/tl/jdk: 20 new changesets Message-ID: <20120118202131.6962A479C8@hg.openjdk.java.net> Changeset: 60dd940eb58e Author: yhuang Date: 2011-12-12 18:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60dd940eb58e 7003124: In Bulgarian Locale DateFormat is wrong Reviewed-by: naoto, peytoia ! src/share/classes/sun/text/resources/FormatData_bg.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: cd03cd0e0965 Author: mfang Date: 2011-12-15 11:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd03cd0e0965 Merge Changeset: 3778f8577305 Author: katleman Date: 2011-12-28 15:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3778f8577305 Merge Changeset: 80350ee39fa8 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80350ee39fa8 Added tag jdk8-b19 for changeset 3778f8577305 ! .hgtags Changeset: 172d70c50c65 Author: cgruszka Date: 2011-09-15 13:59 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/172d70c50c65 7066713: Separate demos from the bundles on Solaris and Linux Summary: add new license files to demos and samples, new directory for bundling Reviewed-by: katleman, ohair, billyh ! make/common/Release.gmk ! make/common/shared/Defs-control.gmk Changeset: eaf967fd25c5 Author: cgruszka Date: 2011-10-18 14:21 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eaf967fd25c5 7099017: jdk7u2-dev does not build Summary: changes to skip demo/DEMOS_LICENSE and sample/SAMPLES_LICENSE when building OPENJDK Reviewed-by: ohair, billyh ! make/common/Release.gmk Changeset: 39b7f01203c9 Author: cgruszka Date: 2011-11-17 16:57 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39b7f01203c9 Merge Changeset: b64e7263b4fd Author: cgruszka Date: 2011-11-18 01:03 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b64e7263b4fd Merge Changeset: e98869ff9f1e Author: cgruszka Date: 2011-12-05 12:41 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e98869ff9f1e Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: ffa36a6a46f5 Author: cgruszka Date: 2011-12-16 15:01 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ffa36a6a46f5 Merge - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h - src/solaris/classes/sun/awt/motif/AWTLockAccess.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h - src/solaris/native/sun/awt/awt_Cursor.h - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh Changeset: 5fe1525e6e2c Author: cgruszka Date: 2011-12-23 10:43 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5fe1525e6e2c Merge Changeset: 39e938cd1b82 Author: cgruszka Date: 2012-01-03 14:34 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39e938cd1b82 Merge Changeset: fc050750f8a0 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc050750f8a0 Added tag jdk8-b20 for changeset 39e938cd1b82 ! .hgtags Changeset: 38a318502e19 Author: lana Date: 2012-01-04 10:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/38a318502e19 Merge ! make/common/Release.gmk - test/tools/launcher/DefaultLocaleTest.sh Changeset: 93ab1df09d11 Author: lana Date: 2012-01-09 19:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93ab1df09d11 Merge - test/tools/launcher/DefaultLocaleTest.sh Changeset: ddb97d4fa83d Author: ohair Date: 2012-01-04 17:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ddb97d4fa83d 7127104: Build issue with prtconf and zones, also using := to avoid extra execs Reviewed-by: katleman ! make/common/shared/Platform.gmk Changeset: 7c8c16f2c05e Author: ohair Date: 2012-01-09 09:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7c8c16f2c05e 7128320: Fix freetype sanity check to make it more generic Reviewed-by: luchsh, katleman Contributed-by: Jonathan Lu ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk ! make/common/Demo.gmk ! make/tools/freetypecheck/Makefile Changeset: 664fa4fb0ee4 Author: katleman Date: 2012-01-11 16:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/664fa4fb0ee4 Merge Changeset: dda27c73d8db Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dda27c73d8db Added tag jdk8-b21 for changeset 664fa4fb0ee4 ! .hgtags Changeset: b14e13237498 Author: lana Date: 2012-01-18 11:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b14e13237498 Merge From zhengyu.gu at oracle.com Wed Jan 18 15:25:04 2012 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Wed, 18 Jan 2012 23:25:04 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7131050: fix for "7071311 Decoder enhancement" does not build on MacOS X Message-ID: <20120118232508.72AE8479E2@hg.openjdk.java.net> Changeset: db18ca98d237 Author: zgu Date: 2012-01-18 11:45 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/db18ca98d237 7131050: fix for "7071311 Decoder enhancement" does not build on MacOS X Summary: Decoder API changes did not reflect in os_bsd Reviewed-by: kamg, dcubed ! src/os/bsd/vm/os_bsd.cpp From joe.darcy at oracle.com Wed Jan 18 16:44:40 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 19 Jan 2012 00:44:40 +0000 Subject: hg: jdk8/tl/langtools: 7130768: Clarify behavior of Element.getEnclosingElements in subtypes Message-ID: <20120119004442.815EC479E3@hg.openjdk.java.net> Changeset: cf2496340fef Author: darcy Date: 2012-01-18 16:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cf2496340fef 7130768: Clarify behavior of Element.getEnclosingElements in subtypes Reviewed-by: mcimadamore, jjg ! src/share/classes/javax/lang/model/element/Element.java ! src/share/classes/javax/lang/model/element/PackageElement.java ! src/share/classes/javax/lang/model/element/TypeElement.java From jim.holmlund at sun.com Wed Jan 18 18:27:52 2012 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Thu, 19 Jan 2012 02:27:52 +0000 Subject: hg: jdk8/tl/langtools: 7131308: Three regression tests fail due to bad fix for 7127924 Message-ID: <20120119022754.7DDE5479E4@hg.openjdk.java.net> Changeset: 99261fc7d95d Author: jjh Date: 2012-01-18 18:26 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/99261fc7d95d 7131308: Three regression tests fail due to bad fix for 7127924 Reviewed-by: jjg ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/RunExamples.java From frederic.parain at oracle.com Thu Jan 19 01:59:57 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 19 Jan 2012 10:59:57 +0100 Subject: RFR (XS) : 7131346 Parsing of boolean arguments to diagnostic commands is broken Message-ID: <4F17E99D.10908@oracle.com> This is a small fix (2 lines) to fix an issue with the parsing of boolean arguments by diagnostic commands CR is not available on bugs.sun.com yet, but the description says that the string comparisons to identify "true" or "false" values doesn't take into account the length of the argument being parse. The suggested fix is: --- old/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 10:36:10 2012 +++ new/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 10:36:10 2012 @@ -62,9 +62,9 @@ if (len == 0) { set_value(true); } else { - if (strcasecmp(str, "true") == 0) { + if (len == strlen("true") && strncasecmp(str, "true", len) == 0) { set_value(true); - } else if (strcasecmp(str, "false") == 0) { + } else if (len == strlen("false") && strncasecmp(str, "false", len) == 0) { set_value(false); } else { THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), Webrev: http://cr.openjdk.java.net/~fparain/7131346/webrev.00/ Thanks, Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From Dmitry.Samersoff at oracle.com Thu Jan 19 02:22:53 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 19 Jan 2012 14:22:53 +0400 Subject: RFR (XS) : 7131346 Parsing of boolean arguments to diagnostic commands is broken In-Reply-To: <4F17E99D.10908@oracle.com> References: <4F17E99D.10908@oracle.com> Message-ID: <4F17EEFD.5040803@oracle.com> Frederic, I think explicit check for len is not necessary, strncasecmp(str, "true", 4) == 0 is enough. -Dmitry On 2012-01-19 13:59, Frederic Parain wrote: > This is a small fix (2 lines) to fix an issue with the > parsing of boolean arguments by diagnostic commands > > CR is not available on bugs.sun.com yet, but the description > says that the string comparisons to identify "true" or "false" > values doesn't take into account the length of the argument > being parse. > > The suggested fix is: > > --- old/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 > 10:36:10 2012 > +++ new/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 > 10:36:10 2012 > @@ -62,9 +62,9 @@ > if (len == 0) { > set_value(true); > } else { > - if (strcasecmp(str, "true") == 0) { > + if (len == strlen("true") && strncasecmp(str, "true", len) == 0) { > set_value(true); > - } else if (strcasecmp(str, "false") == 0) { > + } else if (len == strlen("false") && strncasecmp(str, "false", len) > == 0) { > set_value(false); > } else { > THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), > > > Webrev: > http://cr.openjdk.java.net/~fparain/7131346/webrev.00/ > > Thanks, > > Fred > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From frederic.parain at oracle.com Thu Jan 19 02:26:13 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 19 Jan 2012 11:26:13 +0100 Subject: RFR (XS) : 7131346 Parsing of boolean arguments to diagnostic commands is broken In-Reply-To: <4F17EEFD.5040803@oracle.com> References: <4F17E99D.10908@oracle.com> <4F17EEFD.5040803@oracle.com> Message-ID: <4F17EFC5.7080909@oracle.com> strncasecmp(str, "true", 4) == 0 would accept arguments like this: -all=truefalse which are not valid. Fred On 01/19/12 11:22 AM, Dmitry Samersoff wrote: > Frederic, > > I think explicit check for len is not necessary, > > strncasecmp(str, "true", 4) == 0 > > is enough. > > -Dmitry > > > On 2012-01-19 13:59, Frederic Parain wrote: >> This is a small fix (2 lines) to fix an issue with the >> parsing of boolean arguments by diagnostic commands >> >> CR is not available on bugs.sun.com yet, but the description >> says that the string comparisons to identify "true" or "false" >> values doesn't take into account the length of the argument >> being parse. >> >> The suggested fix is: >> >> --- old/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 >> 10:36:10 2012 >> +++ new/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 >> 10:36:10 2012 >> @@ -62,9 +62,9 @@ >> if (len == 0) { >> set_value(true); >> } else { >> - if (strcasecmp(str, "true") == 0) { >> + if (len == strlen("true")&& strncasecmp(str, "true", len) == 0) { >> set_value(true); >> - } else if (strcasecmp(str, "false") == 0) { >> + } else if (len == strlen("false")&& strncasecmp(str, "false", len) >> == 0) { >> set_value(false); >> } else { >> THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), >> >> >> Webrev: >> http://cr.openjdk.java.net/~fparain/7131346/webrev.00/ >> >> Thanks, >> >> Fred >> > > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From Dmitry.Samersoff at oracle.com Thu Jan 19 02:48:49 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 19 Jan 2012 14:48:49 +0400 Subject: RFR (XS) : 7131346 Parsing of boolean arguments to diagnostic commands is broken In-Reply-To: <4F17EFC5.7080909@oracle.com> References: <4F17E99D.10908@oracle.com> <4F17EEFD.5040803@oracle.com> <4F17EFC5.7080909@oracle.com> Message-ID: <4F17F511.20803@oracle.com> Frederic, Sorry, of course strncasecmp(str, "true", 4) == 0 && str[4] == 0 -Dmitry On 2012-01-19 14:26, Frederic Parain wrote: > strncasecmp(str, "true", 4) == 0 would accept > arguments like this: > > -all=truefalse > > which are not valid. > > Fred > > On 01/19/12 11:22 AM, Dmitry Samersoff wrote: >> Frederic, >> >> I think explicit check for len is not necessary, >> >> strncasecmp(str, "true", 4) == 0 >> >> is enough. >> >> -Dmitry >> >> >> On 2012-01-19 13:59, Frederic Parain wrote: >>> This is a small fix (2 lines) to fix an issue with the >>> parsing of boolean arguments by diagnostic commands >>> >>> CR is not available on bugs.sun.com yet, but the description >>> says that the string comparisons to identify "true" or "false" >>> values doesn't take into account the length of the argument >>> being parse. >>> >>> The suggested fix is: >>> >>> --- old/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 >>> 10:36:10 2012 >>> +++ new/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 >>> 10:36:10 2012 >>> @@ -62,9 +62,9 @@ >>> if (len == 0) { >>> set_value(true); >>> } else { >>> - if (strcasecmp(str, "true") == 0) { >>> + if (len == strlen("true")&& strncasecmp(str, "true", len) == 0) { >>> set_value(true); >>> - } else if (strcasecmp(str, "false") == 0) { >>> + } else if (len == strlen("false")&& strncasecmp(str, "false", len) >>> == 0) { >>> set_value(false); >>> } else { >>> THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), >>> >>> >>> Webrev: >>> http://cr.openjdk.java.net/~fparain/7131346/webrev.00/ >>> >>> Thanks, >>> >>> Fred >>> >> >> > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From serguei.spitsyn at oracle.com Thu Jan 19 02:54:10 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 19 Jan 2012 02:54:10 -0800 Subject: Initial triage of JFR nighly regressions + bugster bugs In-Reply-To: <372c4f2e-3b60-4b1f-ba88-1d60fb80ea1c@default> References: <57010038-70cf-47b5-9eb4-c8593a1d4786@default> <4F17238F.6050501@oracle.com> <372c4f2e-3b60-4b1f-ba88-1d60fb80ea1c@default> Message-ID: <4F17F652.1090807@oracle.com> Vladimir and Nicolay, Just wanted to let you know about several new bugs opened in the hotspot/test category. They are behalf of the JFR_Baseline nightly and need to be resolved quicker than usually, so the priority is P3. It is because the JFR needs better test coverage. Please, let us know if you disagree. I've just moved to the hotspot/test subcat the bug: 7130996 nsk/jvmti/RedefineClasses/redefclass031 fails with JFR Also, I've opened another one (covers 3 nsk/jvmti tests: popframe001, popframe003, popframe005): 7131317 JVMTI: nsk/jvmti/PopFrame/popframe003 fails intermittently with JFR The bug 7130996 does not have a suggested fix but the approach can be the same - to filter out the NativeMethodBind events coming from unexpected threads (JFR thread in our case). Thanks, Serguei On 1/18/12 12:21 PM, Markus Gr?nlund wrote: > > Hi Serguei, > > I think Nils has setup a new system for JFR binaries (and included > them into JRPT install) although I have not tried it yet. I will try > to find the mail from Nils, otherwise he will see this tomorrow > Swedish time for clarification. > > Your list looks accurate from what we filed today! > > Thanks a lot! > > Markus > > *From:*Serguei Spitsyn > *Sent:* den 18 januari 2012 20:55 > *To:* Markus Gr?nlund > *Cc:* jfr_dev_ww > *Subject:* Re: Initial triage of JFR nighly regressions + bugster bugs > > Hi Markus, > > This is the list I've got: > 7130983 Test failures in nsk/sajdi/ > 7130988 nsk/hprof/options/depth/depth002 fails in JFR_Baseline > 7130989 nsk/hprof/options/format/format002 fails with JFR > 7130990 nsk/jdi/ReferenceType/allFields/allfields005 fails with JFR: > assertion JNI handle should not be null > 7130992 Test failures in nsk/jdb (esp on Win-i586) > 7130993 nsk/jdi/ReferenceType/instances/instances004 fails with JFR: > assert(ServiceUtil::visible_oop(obj)) > 7130995 tests in nsk/regression/ fail on win-i586 > 7130996 nsk/jvmti/RedefineClasses/redefclass031 fails with JFR > 7131001 Test failure in nsk/regression/b6186200 > 7131006 java/lang/management/ThreadMXBean/ThreadLists.java > > > These are current test-fail-jfr bugs that was already routed to SQE: > 7122951 JVMTI: nsk/jvmti/scenarios/multienv/MA10/ma10t001 fails when > JFR is enabled > 7122954 JVMTI: nsk/jvmti/ClassPrepare/classprep001 fails when JFR is > enabled > 7131002 com/sun/jdi/InstanceFilter.java fails with JFR: Does not > expect MethodEntryEvent from JFR > 7131005 com/sun/jdi/MethodExitReturnValuesTest.jav fails with JFR: > Does not expect events from JFR Thread > 7131007 demo/jvmti/mtrace/TraceJFrame.java fails in JFR_Baseline: > Can't connect to X11 server > > > How are we supposed to find the latest JFR jdk binaries that was used > in nightly? > > Thanks, > Serguei > > > > On 1/18/12 9:02 AM, Markus Gr?nlund wrote: > > Hi all, > > Myself and Rickard spent the day trying to understand the reporting of > nightly failures for JFR_Baseline with an ambition to bring in some > descriptions for the failures into Bugster, as well as starting to > learn on how to use UTE to address test failures. > > We have made a first stab at this with a few bugster bugs outlining > what we found -- I still don't know how to post a query to bugster, > but if you search for manager tuva.palm at oracle.com > you can get to see them (they are also > tagged with keyword test-fail-jfr. > > We need to address the failures here; a lot of them seems to be > related to environmental setups but a few seems to be related to tests > that needs to be updated (and bugs re-routed to SQE?). > > We have asked SQE to turn JFR defaultrecording back ON as of tonight, > so hopefully we will have some additional information/failures to > triage tomorrow. > > Please take a look at the bugs if you can -- I am in the process of > trying to rule out a lot of the failures for Windows fiddling around > in UTE... > > Thanks a lot > > Markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120119/8e9c53f8/attachment-0001.html From david.holmes at oracle.com Thu Jan 19 03:25:20 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Jan 2012 21:25:20 +1000 Subject: RFR (XS) : 7131346 Parsing of boolean arguments to diagnostic commands is broken In-Reply-To: <4F17E99D.10908@oracle.com> References: <4F17E99D.10908@oracle.com> Message-ID: <4F17FDA0.6060708@oracle.com> Hi Fred, On 19/01/2012 7:59 PM, Frederic Parain wrote: > This is a small fix (2 lines) to fix an issue with the > parsing of boolean arguments by diagnostic commands > > CR is not available on bugs.sun.com yet, but the description > says that the string comparisons to identify "true" or "false" > values doesn't take into account the length of the argument > being parse. > > The suggested fix is: > > --- old/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 10:36:10 > 2012 > +++ new/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 10:36:10 > 2012 > @@ -62,9 +62,9 @@ > if (len == 0) { > set_value(true); > } else { > - if (strcasecmp(str, "true") == 0) { > + if (len == strlen("true") && strncasecmp(str, "true", len) == 0) { Given you've established that str has the right length isn't the use strncasecmp unnecessary? David ----- > set_value(true); > - } else if (strcasecmp(str, "false") == 0) { > + } else if (len == strlen("false") && strncasecmp(str, "false", len) == > 0) { > set_value(false); > } else { > THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), > > > Webrev: > http://cr.openjdk.java.net/~fparain/7131346/webrev.00/ > > Thanks, > > Fred > From robert.ottenhag at oracle.com Thu Jan 19 03:39:05 2012 From: robert.ottenhag at oracle.com (Robert Ottenhag) Date: Thu, 19 Jan 2012 12:39:05 +0100 Subject: RFR (XS) : 7131346 Parsing of boolean arguments to diagnostic commands is broken In-Reply-To: <4F17F511.20803@oracle.com> References: <4F17E99D.10908@oracle.com> <4F17EEFD.5040803@oracle.com> <4F17EFC5.7080909@oracle.com> <4F17F511.20803@oracle.com> Message-ID: <4F1800D9.6000708@oracle.com> Dmitry, No, that expects str to have length 4 or longer, which might be false. The argument 'len' provides the length. Frederic, However, I do not get it, why cannot ordinary strcasecmp(str, "true") be used here, is it problem with an input string that is not null terminated, or is it some other problem? Reading the bug, the failing input is "-all=true", but how is that a problem, assuming the upper layer code has separated "-all=" from "true" before parsing the value? /Robert On 01/19/2012 11:48 AM, Dmitry Samersoff wrote: > Frederic, > > Sorry, of course > > strncasecmp(str, "true", 4) == 0&& str[4] == 0 > > -Dmitry > > On 2012-01-19 14:26, Frederic Parain wrote: >> strncasecmp(str, "true", 4) == 0 would accept >> arguments like this: >> >> -all=truefalse >> >> which are not valid. >> >> Fred >> >> On 01/19/12 11:22 AM, Dmitry Samersoff wrote: >>> Frederic, >>> >>> I think explicit check for len is not necessary, >>> >>> strncasecmp(str, "true", 4) == 0 >>> >>> is enough. >>> >>> -Dmitry >>> >>> >>> On 2012-01-19 13:59, Frederic Parain wrote: >>>> This is a small fix (2 lines) to fix an issue with the >>>> parsing of boolean arguments by diagnostic commands >>>> >>>> CR is not available on bugs.sun.com yet, but the description >>>> says that the string comparisons to identify "true" or "false" >>>> values doesn't take into account the length of the argument >>>> being parse. >>>> >>>> The suggested fix is: >>>> >>>> --- old/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 >>>> 10:36:10 2012 >>>> +++ new/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 >>>> 10:36:10 2012 >>>> @@ -62,9 +62,9 @@ >>>> if (len == 0) { >>>> set_value(true); >>>> } else { >>>> - if (strcasecmp(str, "true") == 0) { >>>> + if (len == strlen("true")&& strncasecmp(str, "true", len) == 0) { >>>> set_value(true); >>>> - } else if (strcasecmp(str, "false") == 0) { >>>> + } else if (len == strlen("false")&& strncasecmp(str, "false", len) >>>> == 0) { >>>> set_value(false); >>>> } else { >>>> THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), >>>> >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~fparain/7131346/webrev.00/ >>>> >>>> Thanks, >>>> >>>> Fred >>>> >>> > -- Oracle Robert Ottenhag | Senior Member of Technical Staff Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161 Oracle Java HotSpot Virtual Machine ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254-6746 Green Oracle Oracle is committed to developing practices and products that help protect the environment -- From frederic.parain at oracle.com Thu Jan 19 03:41:06 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 19 Jan 2012 12:41:06 +0100 Subject: RFR (XS) : 7131346 Parsing of boolean arguments to diagnostic commands is broken In-Reply-To: <4F17FDA0.6060708@oracle.com> References: <4F17E99D.10908@oracle.com> <4F17FDA0.6060708@oracle.com> Message-ID: <4F180152.6030606@oracle.com> On 01/19/12 12:25 PM, David Holmes wrote: + if (len == strlen("true") && strncasecmp(str, "true", len) == 0) { > > Given you've established that str has the right length isn't the use > strncasecmp unnecessary? str has the right length, but this length has been computed by the parser which knows what is the delimiter between two arguments. The section of str which must be considered is not necessarily NULL-terminated, so using strcasecmp (without len argument) is not an option. Example: str = "-all=true filename.hprof" len = 4 The comparison must be restricted to the first 4 characters, even if strlen(str) > 4. Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From frederic.parain at oracle.com Thu Jan 19 03:49:23 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 19 Jan 2012 12:49:23 +0100 Subject: RFR (XS) : 7131346 Parsing of boolean arguments to diagnostic commands is broken In-Reply-To: <4F1800D9.6000708@oracle.com> References: <4F17E99D.10908@oracle.com> <4F17EEFD.5040803@oracle.com> <4F17EFC5.7080909@oracle.com> <4F17F511.20803@oracle.com> <4F1800D9.6000708@oracle.com> Message-ID: <4F180343.2020301@oracle.com> On 01/19/12 12:39 PM, Robert Ottenhag wrote: > However, I do not get it, why cannot ordinary strcasecmp(str, "true") be > used here, is it problem with an input string that is not null > terminated, or is it some other problem? Correct. The parsing must be applied only to a section of str which is not null terminated. > Reading the bug, the failing input is "-all=true", but how is that a > problem, assuming the upper layer code has separated "-all=" from "true" > before parsing the value? > The CR is missing some information (I've received a more detailed description of the failure by e-mail). The failing input is in fact "-all=true filename.hprof" Where the value of the boolean argument is followed by a delimiter (a space in this case) and another argument. When the parsing method is invoked, str points to the 't' of "true" and len is 4: Using strcasecmp: strcasecmp("true filename.hprof","true") returns a positive number Using strncasecmp: strncasecmp("true filename.hprof","true",len) returns zero Fred > On 01/19/2012 11:48 AM, Dmitry Samersoff wrote: >> Frederic, >> >> Sorry, of course >> >> strncasecmp(str, "true", 4) == 0&& str[4] == 0 >> >> -Dmitry >> >> On 2012-01-19 14:26, Frederic Parain wrote: >>> strncasecmp(str, "true", 4) == 0 would accept >>> arguments like this: >>> >>> -all=truefalse >>> >>> which are not valid. >>> >>> Fred >>> >>> On 01/19/12 11:22 AM, Dmitry Samersoff wrote: >>>> Frederic, >>>> >>>> I think explicit check for len is not necessary, >>>> >>>> strncasecmp(str, "true", 4) == 0 >>>> >>>> is enough. >>>> >>>> -Dmitry >>>> >>>> >>>> On 2012-01-19 13:59, Frederic Parain wrote: >>>>> This is a small fix (2 lines) to fix an issue with the >>>>> parsing of boolean arguments by diagnostic commands >>>>> >>>>> CR is not available on bugs.sun.com yet, but the description >>>>> says that the string comparisons to identify "true" or "false" >>>>> values doesn't take into account the length of the argument >>>>> being parse. >>>>> >>>>> The suggested fix is: >>>>> >>>>> --- old/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 >>>>> 10:36:10 2012 >>>>> +++ new/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 >>>>> 10:36:10 2012 >>>>> @@ -62,9 +62,9 @@ >>>>> if (len == 0) { >>>>> set_value(true); >>>>> } else { >>>>> - if (strcasecmp(str, "true") == 0) { >>>>> + if (len == strlen("true")&& strncasecmp(str, "true", len) == 0) { >>>>> set_value(true); >>>>> - } else if (strcasecmp(str, "false") == 0) { >>>>> + } else if (len == strlen("false")&& strncasecmp(str, "false", len) >>>>> == 0) { >>>>> set_value(false); >>>>> } else { >>>>> THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), >>>>> >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~fparain/7131346/webrev.00/ >>>>> >>>>> Thanks, >>>>> >>>>> Fred >>>>> >>>> >> > > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From david.holmes at oracle.com Thu Jan 19 04:08:04 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Jan 2012 22:08:04 +1000 Subject: RFR (XS) : 7131346 Parsing of boolean arguments to diagnostic commands is broken In-Reply-To: <4F180343.2020301@oracle.com> References: <4F17E99D.10908@oracle.com> <4F17EEFD.5040803@oracle.com> <4F17EFC5.7080909@oracle.com> <4F17F511.20803@oracle.com> <4F1800D9.6000708@oracle.com> <4F180343.2020301@oracle.com> Message-ID: <4F1807A4.9020706@oracle.com> On 19/01/2012 9:49 PM, Frederic Parain wrote: > On 01/19/12 12:39 PM, Robert Ottenhag wrote: >> However, I do not get it, why cannot ordinary strcasecmp(str, "true") be >> used here, is it problem with an input string that is not null >> terminated, or is it some other problem? > > Correct. The parsing must be applied only to a section of str which > is not null terminated. > >> Reading the bug, the failing input is "-all=true", but how is that a >> problem, assuming the upper layer code has separated "-all=" from "true" >> before parsing the value? >> > > The CR is missing some information (I've received a more detailed > description of the failure by e-mail). > > The failing input is in fact "-all=true filename.hprof" > > Where the value of the boolean argument is followed by > a delimiter (a space in this case) and another argument. > > When the parsing method is invoked, str points to the 't' of > "true" and len is 4: > > Using strcasecmp: > strcasecmp("true filename.hprof","true") returns a positive number > > Using strncasecmp: > strncasecmp("true filename.hprof","true",len) returns zero Okay that all makes sense now. But does that mean other parse routines have a similar issue eg: 39 template <> void DCmdArgument::parse_value(const char* str, 40 size_t len, TRAPS) { 41 if (sscanf(str, INT64_FORMAT, &_value) != 1) { 42 THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), 43 "Integer parsing error in diagnostic command arguments"); 44 } 45 } this doesn't limit itself to checking only len characters in str. David ----- > Fred > >> On 01/19/2012 11:48 AM, Dmitry Samersoff wrote: >>> Frederic, >>> >>> Sorry, of course >>> >>> strncasecmp(str, "true", 4) == 0&& str[4] == 0 >>> >>> -Dmitry >>> >>> On 2012-01-19 14:26, Frederic Parain wrote: >>>> strncasecmp(str, "true", 4) == 0 would accept >>>> arguments like this: >>>> >>>> -all=truefalse >>>> >>>> which are not valid. >>>> >>>> Fred >>>> >>>> On 01/19/12 11:22 AM, Dmitry Samersoff wrote: >>>>> Frederic, >>>>> >>>>> I think explicit check for len is not necessary, >>>>> >>>>> strncasecmp(str, "true", 4) == 0 >>>>> >>>>> is enough. >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2012-01-19 13:59, Frederic Parain wrote: >>>>>> This is a small fix (2 lines) to fix an issue with the >>>>>> parsing of boolean arguments by diagnostic commands >>>>>> >>>>>> CR is not available on bugs.sun.com yet, but the description >>>>>> says that the string comparisons to identify "true" or "false" >>>>>> values doesn't take into account the length of the argument >>>>>> being parse. >>>>>> >>>>>> The suggested fix is: >>>>>> >>>>>> --- old/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 >>>>>> 10:36:10 2012 >>>>>> +++ new/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 >>>>>> 10:36:10 2012 >>>>>> @@ -62,9 +62,9 @@ >>>>>> if (len == 0) { >>>>>> set_value(true); >>>>>> } else { >>>>>> - if (strcasecmp(str, "true") == 0) { >>>>>> + if (len == strlen("true")&& strncasecmp(str, "true", len) == 0) { >>>>>> set_value(true); >>>>>> - } else if (strcasecmp(str, "false") == 0) { >>>>>> + } else if (len == strlen("false")&& strncasecmp(str, "false", len) >>>>>> == 0) { >>>>>> set_value(false); >>>>>> } else { >>>>>> THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), >>>>>> >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~fparain/7131346/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Fred >>>>>> >>>>> >>> >> >> > From frederic.parain at oracle.com Thu Jan 19 04:18:50 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 19 Jan 2012 13:18:50 +0100 Subject: RFR (XS) : 7131346 Parsing of boolean arguments to diagnostic commands is broken In-Reply-To: <4F1807A4.9020706@oracle.com> References: <4F17E99D.10908@oracle.com> <4F17EEFD.5040803@oracle.com> <4F17EFC5.7080909@oracle.com> <4F17F511.20803@oracle.com> <4F1800D9.6000708@oracle.com> <4F180343.2020301@oracle.com> <4F1807A4.9020706@oracle.com> Message-ID: <4F180A2A.40602@oracle.com> On 01/19/12 01:08 PM, David Holmes wrote: > Okay that all makes sense now. > > But does that mean other parse routines have a similar issue eg: > > 39 template <> void DCmdArgument::parse_value(const char* str, > 40 size_t len, TRAPS) { > 41 if (sscanf(str, INT64_FORMAT, &_value) != 1) { > 42 THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), > 43 "Integer parsing error in diagnostic command arguments"); > 44 } > 45 } sscanf will stop parsing as soon as it finds a character which cannot be used to create an integer. Unless someone as the bad idea to use a digit character as delimiter, it should be safe. However, I'm not sure that trailing characters are properly detected. Do you consider that as a show stopper? Fred >> Fred >> >>> On 01/19/2012 11:48 AM, Dmitry Samersoff wrote: >>>> Frederic, >>>> >>>> Sorry, of course >>>> >>>> strncasecmp(str, "true", 4) == 0&& str[4] == 0 >>>> >>>> -Dmitry >>>> >>>> On 2012-01-19 14:26, Frederic Parain wrote: >>>>> strncasecmp(str, "true", 4) == 0 would accept >>>>> arguments like this: >>>>> >>>>> -all=truefalse >>>>> >>>>> which are not valid. >>>>> >>>>> Fred >>>>> >>>>> On 01/19/12 11:22 AM, Dmitry Samersoff wrote: >>>>>> Frederic, >>>>>> >>>>>> I think explicit check for len is not necessary, >>>>>> >>>>>> strncasecmp(str, "true", 4) == 0 >>>>>> >>>>>> is enough. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2012-01-19 13:59, Frederic Parain wrote: >>>>>>> This is a small fix (2 lines) to fix an issue with the >>>>>>> parsing of boolean arguments by diagnostic commands >>>>>>> >>>>>>> CR is not available on bugs.sun.com yet, but the description >>>>>>> says that the string comparisons to identify "true" or "false" >>>>>>> values doesn't take into account the length of the argument >>>>>>> being parse. >>>>>>> >>>>>>> The suggested fix is: >>>>>>> >>>>>>> --- old/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 >>>>>>> 10:36:10 2012 >>>>>>> +++ new/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 >>>>>>> 10:36:10 2012 >>>>>>> @@ -62,9 +62,9 @@ >>>>>>> if (len == 0) { >>>>>>> set_value(true); >>>>>>> } else { >>>>>>> - if (strcasecmp(str, "true") == 0) { >>>>>>> + if (len == strlen("true")&& strncasecmp(str, "true", len) == 0) { >>>>>>> set_value(true); >>>>>>> - } else if (strcasecmp(str, "false") == 0) { >>>>>>> + } else if (len == strlen("false")&& strncasecmp(str, "false", len) >>>>>>> == 0) { >>>>>>> set_value(false); >>>>>>> } else { >>>>>>> THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), >>>>>>> >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~fparain/7131346/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Fred >>>>>>> >>>>>> >>>> >>> >>> >> -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From david.holmes at oracle.com Thu Jan 19 04:28:00 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Jan 2012 22:28:00 +1000 Subject: RFR (XS) : 7131346 Parsing of boolean arguments to diagnostic commands is broken In-Reply-To: <4F180A2A.40602@oracle.com> References: <4F17E99D.10908@oracle.com> <4F17EEFD.5040803@oracle.com> <4F17EFC5.7080909@oracle.com> <4F17F511.20803@oracle.com> <4F1800D9.6000708@oracle.com> <4F180343.2020301@oracle.com> <4F1807A4.9020706@oracle.com> <4F180A2A.40602@oracle.com> Message-ID: <4F180C50.20208@oracle.com> On 19/01/2012 10:18 PM, Frederic Parain wrote: > On 01/19/12 01:08 PM, David Holmes wrote: >> Okay that all makes sense now. >> >> But does that mean other parse routines have a similar issue eg: >> >> 39 template <> void DCmdArgument::parse_value(const char* str, >> 40 size_t len, TRAPS) { >> 41 if (sscanf(str, INT64_FORMAT, &_value) != 1) { >> 42 THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), >> 43 "Integer parsing error in diagnostic command arguments"); >> 44 } >> 45 } > > sscanf will stop parsing as soon as it finds a character > which cannot be used to create an integer. Ah - right! > Unless someone as the bad idea to use a digit character > as delimiter, it should be safe. Yeah that would be a bad idea :) > However, I'm not sure that trailing characters are properly > detected. Do you consider that as a show stopper? Depends on exactly what you mean by that. If extra junk characters are ignored rather than causing an error that's okay to me. David ----- > Fred > >>> Fred >>> >>>> On 01/19/2012 11:48 AM, Dmitry Samersoff wrote: >>>>> Frederic, >>>>> >>>>> Sorry, of course >>>>> >>>>> strncasecmp(str, "true", 4) == 0&& str[4] == 0 >>>>> >>>>> -Dmitry >>>>> >>>>> On 2012-01-19 14:26, Frederic Parain wrote: >>>>>> strncasecmp(str, "true", 4) == 0 would accept >>>>>> arguments like this: >>>>>> >>>>>> -all=truefalse >>>>>> >>>>>> which are not valid. >>>>>> >>>>>> Fred >>>>>> >>>>>> On 01/19/12 11:22 AM, Dmitry Samersoff wrote: >>>>>>> Frederic, >>>>>>> >>>>>>> I think explicit check for len is not necessary, >>>>>>> >>>>>>> strncasecmp(str, "true", 4) == 0 >>>>>>> >>>>>>> is enough. >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>>>> On 2012-01-19 13:59, Frederic Parain wrote: >>>>>>>> This is a small fix (2 lines) to fix an issue with the >>>>>>>> parsing of boolean arguments by diagnostic commands >>>>>>>> >>>>>>>> CR is not available on bugs.sun.com yet, but the description >>>>>>>> says that the string comparisons to identify "true" or "false" >>>>>>>> values doesn't take into account the length of the argument >>>>>>>> being parse. >>>>>>>> >>>>>>>> The suggested fix is: >>>>>>>> >>>>>>>> --- old/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 >>>>>>>> 10:36:10 2012 >>>>>>>> +++ new/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 >>>>>>>> 10:36:10 2012 >>>>>>>> @@ -62,9 +62,9 @@ >>>>>>>> if (len == 0) { >>>>>>>> set_value(true); >>>>>>>> } else { >>>>>>>> - if (strcasecmp(str, "true") == 0) { >>>>>>>> + if (len == strlen("true")&& strncasecmp(str, "true", len) == 0) { >>>>>>>> set_value(true); >>>>>>>> - } else if (strcasecmp(str, "false") == 0) { >>>>>>>> + } else if (len == strlen("false")&& strncasecmp(str, "false", >>>>>>>> len) >>>>>>>> == 0) { >>>>>>>> set_value(false); >>>>>>>> } else { >>>>>>>> THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), >>>>>>>> >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~fparain/7131346/webrev.00/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Fred >>>>>>>> >>>>>>> >>>>> >>>> >>>> >>> > From frederic.parain at oracle.com Thu Jan 19 04:33:02 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 19 Jan 2012 13:33:02 +0100 Subject: RFR (XS) : 7131346 Parsing of boolean arguments to diagnostic commands is broken In-Reply-To: <4F180C50.20208@oracle.com> References: <4F17E99D.10908@oracle.com> <4F17EEFD.5040803@oracle.com> <4F17EFC5.7080909@oracle.com> <4F17F511.20803@oracle.com> <4F1800D9.6000708@oracle.com> <4F180343.2020301@oracle.com> <4F1807A4.9020706@oracle.com> <4F180A2A.40602@oracle.com> <4F180C50.20208@oracle.com> Message-ID: <4F180D7E.4030603@oracle.com> On 01/19/12 01:28 PM, David Holmes wrote: >> However, I'm not sure that trailing characters are properly >> detected. Do you consider that as a show stopper? > > Depends on exactly what you mean by that. If extra junk characters are > ignored rather than causing an error that's okay to me. They will be silently ignored. Fred >> Fred >> >>>> Fred >>>> >>>>> On 01/19/2012 11:48 AM, Dmitry Samersoff wrote: >>>>>> Frederic, >>>>>> >>>>>> Sorry, of course >>>>>> >>>>>> strncasecmp(str, "true", 4) == 0&& str[4] == 0 >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2012-01-19 14:26, Frederic Parain wrote: >>>>>>> strncasecmp(str, "true", 4) == 0 would accept >>>>>>> arguments like this: >>>>>>> >>>>>>> -all=truefalse >>>>>>> >>>>>>> which are not valid. >>>>>>> >>>>>>> Fred >>>>>>> >>>>>>> On 01/19/12 11:22 AM, Dmitry Samersoff wrote: >>>>>>>> Frederic, >>>>>>>> >>>>>>>> I think explicit check for len is not necessary, >>>>>>>> >>>>>>>> strncasecmp(str, "true", 4) == 0 >>>>>>>> >>>>>>>> is enough. >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2012-01-19 13:59, Frederic Parain wrote: >>>>>>>>> This is a small fix (2 lines) to fix an issue with the >>>>>>>>> parsing of boolean arguments by diagnostic commands >>>>>>>>> >>>>>>>>> CR is not available on bugs.sun.com yet, but the description >>>>>>>>> says that the string comparisons to identify "true" or "false" >>>>>>>>> values doesn't take into account the length of the argument >>>>>>>>> being parse. >>>>>>>>> >>>>>>>>> The suggested fix is: >>>>>>>>> >>>>>>>>> --- old/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 >>>>>>>>> 10:36:10 2012 >>>>>>>>> +++ new/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 >>>>>>>>> 10:36:10 2012 >>>>>>>>> @@ -62,9 +62,9 @@ >>>>>>>>> if (len == 0) { >>>>>>>>> set_value(true); >>>>>>>>> } else { >>>>>>>>> - if (strcasecmp(str, "true") == 0) { >>>>>>>>> + if (len == strlen("true")&& strncasecmp(str, "true", len) == >>>>>>>>> 0) { >>>>>>>>> set_value(true); >>>>>>>>> - } else if (strcasecmp(str, "false") == 0) { >>>>>>>>> + } else if (len == strlen("false")&& strncasecmp(str, "false", >>>>>>>>> len) >>>>>>>>> == 0) { >>>>>>>>> set_value(false); >>>>>>>>> } else { >>>>>>>>> THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), >>>>>>>>> >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~fparain/7131346/webrev.00/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Fred >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>>> >>>> >> -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From valerie.peng at oracle.com Thu Jan 19 12:06:58 2012 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Thu, 19 Jan 2012 20:06:58 +0000 Subject: hg: jdk8/tl/jdk: 7092825: javax.crypto.Cipher.Transform.patternCache is synchronizedMap and became scalability bottleneck. Message-ID: <20120119200711.C17CC470A0@hg.openjdk.java.net> Changeset: 313da5d059bf Author: valeriep Date: 2012-01-19 12:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/313da5d059bf 7092825: javax.crypto.Cipher.Transform.patternCache is synchronizedMap and became scalability bottleneck. Summary: Changed patternCache from synchronizedMap to ConcurrentHashMap. Reviewed-by: mullan ! src/share/classes/javax/crypto/Cipher.java From david.holmes at oracle.com Fri Jan 20 03:18:20 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 20 Jan 2012 21:18:20 +1000 Subject: RFR (XS) : 7131346 Parsing of boolean arguments to diagnostic commands is broken In-Reply-To: <4F180D7E.4030603@oracle.com> References: <4F17E99D.10908@oracle.com> <4F17EEFD.5040803@oracle.com> <4F17EFC5.7080909@oracle.com> <4F17F511.20803@oracle.com> <4F1800D9.6000708@oracle.com> <4F180343.2020301@oracle.com> <4F1807A4.9020706@oracle.com> <4F180A2A.40602@oracle.com> <4F180C50.20208@oracle.com> <4F180D7E.4030603@oracle.com> Message-ID: <4F194D7C.5080102@oracle.com> On 19/01/2012 10:33 PM, Frederic Parain wrote: > On 01/19/12 01:28 PM, David Holmes wrote: >>> However, I'm not sure that trailing characters are properly >>> detected. Do you consider that as a show stopper? >> >> Depends on exactly what you mean by that. If extra junk characters are >> ignored rather than causing an error that's okay to me. > > They will be silently ignored. Not a showstopper in that case. So this looks good to go. David ----- > Fred > >>> Fred >>> >>>>> Fred >>>>> >>>>>> On 01/19/2012 11:48 AM, Dmitry Samersoff wrote: >>>>>>> Frederic, >>>>>>> >>>>>>> Sorry, of course >>>>>>> >>>>>>> strncasecmp(str, "true", 4) == 0&& str[4] == 0 >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> On 2012-01-19 14:26, Frederic Parain wrote: >>>>>>>> strncasecmp(str, "true", 4) == 0 would accept >>>>>>>> arguments like this: >>>>>>>> >>>>>>>> -all=truefalse >>>>>>>> >>>>>>>> which are not valid. >>>>>>>> >>>>>>>> Fred >>>>>>>> >>>>>>>> On 01/19/12 11:22 AM, Dmitry Samersoff wrote: >>>>>>>>> Frederic, >>>>>>>>> >>>>>>>>> I think explicit check for len is not necessary, >>>>>>>>> >>>>>>>>> strncasecmp(str, "true", 4) == 0 >>>>>>>>> >>>>>>>>> is enough. >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2012-01-19 13:59, Frederic Parain wrote: >>>>>>>>>> This is a small fix (2 lines) to fix an issue with the >>>>>>>>>> parsing of boolean arguments by diagnostic commands >>>>>>>>>> >>>>>>>>>> CR is not available on bugs.sun.com yet, but the description >>>>>>>>>> says that the string comparisons to identify "true" or "false" >>>>>>>>>> values doesn't take into account the length of the argument >>>>>>>>>> being parse. >>>>>>>>>> >>>>>>>>>> The suggested fix is: >>>>>>>>>> >>>>>>>>>> --- old/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 >>>>>>>>>> 10:36:10 2012 >>>>>>>>>> +++ new/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 >>>>>>>>>> 10:36:10 2012 >>>>>>>>>> @@ -62,9 +62,9 @@ >>>>>>>>>> if (len == 0) { >>>>>>>>>> set_value(true); >>>>>>>>>> } else { >>>>>>>>>> - if (strcasecmp(str, "true") == 0) { >>>>>>>>>> + if (len == strlen("true")&& strncasecmp(str, "true", len) == >>>>>>>>>> 0) { >>>>>>>>>> set_value(true); >>>>>>>>>> - } else if (strcasecmp(str, "false") == 0) { >>>>>>>>>> + } else if (len == strlen("false")&& strncasecmp(str, "false", >>>>>>>>>> len) >>>>>>>>>> == 0) { >>>>>>>>>> set_value(false); >>>>>>>>>> } else { >>>>>>>>>> THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~fparain/7131346/webrev.00/ >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Fred >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>> > From frederic.parain at oracle.com Fri Jan 20 06:45:04 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 20 Jan 2012 15:45:04 +0100 Subject: RFR (XS) : 7131346 Parsing of boolean arguments to diagnostic commands is broken In-Reply-To: <4F194D7C.5080102@oracle.com> References: <4F17E99D.10908@oracle.com> <4F17EEFD.5040803@oracle.com> <4F17EFC5.7080909@oracle.com> <4F17F511.20803@oracle.com> <4F1800D9.6000708@oracle.com> <4F180343.2020301@oracle.com> <4F1807A4.9020706@oracle.com> <4F180A2A.40602@oracle.com> <4F180C50.20208@oracle.com> <4F180D7E.4030603@oracle.com> <4F194D7C.5080102@oracle.com> Message-ID: <4F197DF0.9070901@oracle.com> Thanks David, I just need a second reviewer and I'll push the fix. Fred On 1/20/12 12:18 PM, David Holmes wrote: > On 19/01/2012 10:33 PM, Frederic Parain wrote: >> On 01/19/12 01:28 PM, David Holmes wrote: >>>> However, I'm not sure that trailing characters are properly >>>> detected. Do you consider that as a show stopper? >>> >>> Depends on exactly what you mean by that. If extra junk characters are >>> ignored rather than causing an error that's okay to me. >> >> They will be silently ignored. > > Not a showstopper in that case. > > So this looks good to go. > > David > ----- > >> Fred >> >>>> Fred >>>> >>>>>> Fred >>>>>> >>>>>>> On 01/19/2012 11:48 AM, Dmitry Samersoff wrote: >>>>>>>> Frederic, >>>>>>>> >>>>>>>> Sorry, of course >>>>>>>> >>>>>>>> strncasecmp(str, "true", 4) == 0&& str[4] == 0 >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> On 2012-01-19 14:26, Frederic Parain wrote: >>>>>>>>> strncasecmp(str, "true", 4) == 0 would accept >>>>>>>>> arguments like this: >>>>>>>>> >>>>>>>>> -all=truefalse >>>>>>>>> >>>>>>>>> which are not valid. >>>>>>>>> >>>>>>>>> Fred >>>>>>>>> >>>>>>>>> On 01/19/12 11:22 AM, Dmitry Samersoff wrote: >>>>>>>>>> Frederic, >>>>>>>>>> >>>>>>>>>> I think explicit check for len is not necessary, >>>>>>>>>> >>>>>>>>>> strncasecmp(str, "true", 4) == 0 >>>>>>>>>> >>>>>>>>>> is enough. >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2012-01-19 13:59, Frederic Parain wrote: >>>>>>>>>>> This is a small fix (2 lines) to fix an issue with the >>>>>>>>>>> parsing of boolean arguments by diagnostic commands >>>>>>>>>>> >>>>>>>>>>> CR is not available on bugs.sun.com yet, but the description >>>>>>>>>>> says that the string comparisons to identify "true" or "false" >>>>>>>>>>> values doesn't take into account the length of the argument >>>>>>>>>>> being parse. >>>>>>>>>>> >>>>>>>>>>> The suggested fix is: >>>>>>>>>>> >>>>>>>>>>> --- old/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 >>>>>>>>>>> 10:36:10 2012 >>>>>>>>>>> +++ new/src/share/vm/services/diagnosticArgument.cpp Thu Jan 19 >>>>>>>>>>> 10:36:10 2012 >>>>>>>>>>> @@ -62,9 +62,9 @@ >>>>>>>>>>> if (len == 0) { >>>>>>>>>>> set_value(true); >>>>>>>>>>> } else { >>>>>>>>>>> - if (strcasecmp(str, "true") == 0) { >>>>>>>>>>> + if (len == strlen("true")&& strncasecmp(str, "true", len) == >>>>>>>>>>> 0) { >>>>>>>>>>> set_value(true); >>>>>>>>>>> - } else if (strcasecmp(str, "false") == 0) { >>>>>>>>>>> + } else if (len == strlen("false")&& strncasecmp(str, "false", >>>>>>>>>>> len) >>>>>>>>>>> == 0) { >>>>>>>>>>> set_value(false); >>>>>>>>>>> } else { >>>>>>>>>>> THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~fparain/7131346/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Fred >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >> -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From mark.reinhold at oracle.com Fri Jan 20 09:10:48 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 20 Jan 2012 09:10:48 -0800 (PST) Subject: JEP 137: Diagnostic-Command Framework Message-ID: <20120120171048.CA35EDD3@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/137 - Mark From joe.darcy at oracle.com Fri Jan 20 17:56:53 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Sat, 21 Jan 2012 01:56:53 +0000 Subject: hg: jdk8/tl/jdk: 4504839: Java libraries should provide support for unsigned integer arithmetic; ... Message-ID: <20120121015731.6C9D7470EE@hg.openjdk.java.net> Changeset: 71200c517524 Author: darcy Date: 2012-01-20 17:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71200c517524 4504839: Java libraries should provide support for unsigned integer arithmetic 4215269: Some Integer.toHexString(int) results cannot be decoded back to an int 6322074: Converting integers to string as if unsigned Reviewed-by: mduigou, emcmanus, flar ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java + test/java/lang/Integer/Unsigned.java + test/java/lang/Long/Unsigned.java From john.coomes at oracle.com Sat Jan 21 15:34:50 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 21 Jan 2012 23:34:50 +0000 Subject: hg: hsx/hotspot-rt: 2 new changesets Message-ID: <20120121233450.F40854710C@hg.openjdk.java.net> Changeset: 7ad075c80995 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/7ad075c80995 Added tag jdk8-b21 for changeset cc771d92284f ! .hgtags Changeset: 60d6f64a86b1 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/60d6f64a86b1 Added tag jdk8-b22 for changeset 7ad075c80995 ! .hgtags From john.coomes at oracle.com Sat Jan 21 15:34:56 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 21 Jan 2012 23:34:56 +0000 Subject: hg: hsx/hotspot-rt/corba: 2 new changesets Message-ID: <20120121233459.24FAC4710D@hg.openjdk.java.net> Changeset: a11d0062c445 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/a11d0062c445 Added tag jdk8-b21 for changeset f157fc2a71a3 ! .hgtags Changeset: 5218eb256658 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/5218eb256658 Added tag jdk8-b22 for changeset a11d0062c445 ! .hgtags From john.coomes at oracle.com Sat Jan 21 15:35:04 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 21 Jan 2012 23:35:04 +0000 Subject: hg: hsx/hotspot-rt/jaxp: 2 new changesets Message-ID: <20120121233504.CAE9B4710E@hg.openjdk.java.net> Changeset: cf9d6ec44f89 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/cf9d6ec44f89 Added tag jdk8-b21 for changeset d41eeadf5c13 ! .hgtags Changeset: 95102fd33418 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/95102fd33418 Added tag jdk8-b22 for changeset cf9d6ec44f89 ! .hgtags From john.coomes at oracle.com Sat Jan 21 15:35:10 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 21 Jan 2012 23:35:10 +0000 Subject: hg: hsx/hotspot-rt/jaxws: 4 new changesets Message-ID: <20120121233510.589E34710F@hg.openjdk.java.net> Changeset: e67d51254533 Author: ohair Date: 2012-01-09 09:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/e67d51254533 7096063: /META-INF/mimetypes.default missing in jre\lib\resources.jar Reviewed-by: dholmes ! build-defs.xml Changeset: c266cab0e3ff Author: katleman Date: 2012-01-11 16:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/c266cab0e3ff Merge Changeset: 8d3df89b0f2d Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/8d3df89b0f2d Added tag jdk8-b21 for changeset c266cab0e3ff ! .hgtags Changeset: 25ce7a000487 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/25ce7a000487 Added tag jdk8-b22 for changeset 8d3df89b0f2d ! .hgtags From john.coomes at oracle.com Sat Jan 21 15:35:40 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 21 Jan 2012 23:35:40 +0000 Subject: hg: hsx/hotspot-rt/jdk: 23 new changesets Message-ID: <20120121233953.CCB6D47111@hg.openjdk.java.net> Changeset: 1c4fffa22930 Author: okutsu Date: 2011-12-21 17:09 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1c4fffa22930 7122054: (tz) Windows-only: tzmappings needs update for KB2633952 Reviewed-by: peytoia ! src/windows/lib/tzmappings Changeset: b1814b3ea6d3 Author: michaelm Date: 2011-12-21 10:06 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b1814b3ea6d3 7078386: NetworkInterface.getNetworkInterfaces() may return corrupted results on linux Reviewed-by: michaelm, alanb, chegar Contributed-by: brandon.passanisi at oracle.com ! src/solaris/native/java/net/NetworkInterface.c Changeset: a9dfdc523c2c Author: valeriep Date: 2011-12-21 14:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a9dfdc523c2c 6839886: Array overrun in pkcs11 Summary: Fix the wrong value when dealing w/ month and day. Reviewed-by: mullan ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c Changeset: 11698dedbe79 Author: weijun Date: 2011-12-22 15:35 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/11698dedbe79 7122169: TcpTimeout fail for various reasons Reviewed-by: alanb ! test/sun/security/krb5/auto/TcpTimeout.java Changeset: 559e07ed1f56 Author: alanb Date: 2011-12-22 10:52 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/559e07ed1f56 7076310: (file) AclEntry.Builder setFlags throws IllegalArgumentException if set argument is empty Reviewed-by: alanb Contributed-by: stephen.flores at oracle.com ! src/share/classes/java/nio/file/attribute/AclEntry.java + test/java/nio/file/attribute/AclEntry/EmptySet.java Changeset: 3c1ab134db71 Author: dcubed Date: 2011-12-22 18:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3c1ab134db71 7121600: Instrumentation.redefineClasses() leaks class bytes Summary: Call JNI ReleaseByteArrayElements() on memory returned by JNI GetByteArrayElements(). Also push test for 7122253. Reviewed-by: acorn, poonam ! src/share/instrument/JPLISAgent.c + test/java/lang/instrument/BigClass.java + test/java/lang/instrument/MakeJAR4.sh + test/java/lang/instrument/RedefineBigClass.sh + test/java/lang/instrument/RedefineBigClassAgent.java + test/java/lang/instrument/RedefineBigClassApp.java + test/java/lang/instrument/RetransformBigClass.sh + test/java/lang/instrument/RetransformBigClassAgent.java + test/java/lang/instrument/RetransformBigClassApp.java Changeset: 437255d15e76 Author: lana Date: 2011-12-28 10:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/437255d15e76 Merge - src/share/classes/sun/awt/FocusingTextField.java - src/share/classes/sun/awt/HorizBagLayout.java - src/share/classes/sun/awt/OrientableFlowLayout.java - src/share/classes/sun/awt/VariableGridLayout.java - src/share/classes/sun/awt/VerticalBagLayout.java Changeset: 3a7ea63302f8 Author: smarks Date: 2011-12-29 16:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3a7ea63302f8 7122061: add -Xlint:all -Werror to warning-free build steps Reviewed-by: chegar, alanb, dholmes, ohair ! make/com/sun/demo/jvmti/hprof/Makefile ! make/com/sun/java/browser/net/Makefile ! make/com/sun/tools/Makefile ! make/com/sun/tools/attach/Makefile ! make/com/sun/tracing/Makefile ! make/com/sun/tracing/dtrace/Makefile ! make/java/instrument/Makefile ! make/java/rmi/Makefile ! make/java/text/base/Makefile ! make/java/text/bidi/Makefile ! make/java/util/Makefile ! make/javax/accessibility/Makefile ! make/javax/others/Makefile ! make/javax/security/Makefile ! make/jpda/tty/Makefile ! make/sun/launcher/Makefile ! make/sun/serialver/Makefile ! make/sun/text/Makefile ! make/sun/util/Makefile Changeset: 5aeefe0e5d8c Author: chegar Date: 2012-01-01 09:24 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5aeefe0e5d8c 7125055: ContentHandler.getContent API changed in error Reviewed-by: alanb ! src/share/classes/java/net/ContentHandler.java ! src/share/classes/sun/net/www/content/image/gif.java ! src/share/classes/sun/net/www/content/image/jpeg.java ! src/share/classes/sun/net/www/content/image/png.java ! src/share/classes/sun/net/www/content/image/x_xbitmap.java ! src/share/classes/sun/net/www/content/image/x_xpixmap.java Changeset: 8952a5f494f9 Author: ksrini Date: 2012-01-03 08:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8952a5f494f9 7123582: (launcher) display the -version and -XshowSettings Reviewed-by: alanb ! src/share/bin/java.c ! test/tools/launcher/Settings.java Changeset: 5e34726cb4bb Author: ksrini Date: 2012-01-03 08:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5e34726cb4bb 7124443: (launcher) test DefaultsLocaleTest fails with Windows shells. Reviewed-by: darcy ! test/tools/launcher/DefaultLocaleTest.java - test/tools/launcher/DefaultLocaleTest.sh + test/tools/launcher/DefaultLocaleTestRun.java ! test/tools/launcher/TestHelper.java Changeset: 0194fe5ca404 Author: fparain Date: 2012-01-04 03:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0194fe5ca404 7104647: Adding a diagnostic command framework Reviewed-by: mchung, dholmes ! make/common/Release.gmk ! make/java/management/mapfile-vers ! make/launchers/Makefile ! make/sun/tools/Makefile + src/linux/doc/man/jcmd.1 + src/share/classes/com/sun/management/DiagnosticCommandArgumentInfo.java + src/share/classes/com/sun/management/DiagnosticCommandInfo.java ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java + src/share/classes/sun/tools/jcmd/Arguments.java + src/share/classes/sun/tools/jcmd/JCmd.java ! src/share/javavm/export/jmm.h ! src/share/native/sun/management/HotSpotDiagnostic.c + src/solaris/doc/sun/man/man1/jcmd.1 + test/com/sun/management/HotSpotDiagnosticMXBean/ExecuteDiagnosticCommand.java + test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommandInfo.java + test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommands.java ! test/sun/tools/common/CommonSetup.sh + test/sun/tools/jcmd/dcmd-script.txt + test/sun/tools/jcmd/help_help.out + test/sun/tools/jcmd/jcmd-Defaults.sh + test/sun/tools/jcmd/jcmd-f.sh + test/sun/tools/jcmd/jcmd-help-help.sh + test/sun/tools/jcmd/jcmd-help.sh + test/sun/tools/jcmd/jcmd-pid.sh + test/sun/tools/jcmd/jcmd_Output1.awk + test/sun/tools/jcmd/jcmd_pid_Output1.awk + test/sun/tools/jcmd/jcmd_pid_Output2.awk + test/sun/tools/jcmd/usage.out Changeset: 38a318502e19 Author: lana Date: 2012-01-04 10:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/38a318502e19 Merge ! make/common/Release.gmk - test/tools/launcher/DefaultLocaleTest.sh Changeset: 93ab1df09d11 Author: lana Date: 2012-01-09 19:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/93ab1df09d11 Merge - test/tools/launcher/DefaultLocaleTest.sh Changeset: ddb97d4fa83d Author: ohair Date: 2012-01-04 17:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ddb97d4fa83d 7127104: Build issue with prtconf and zones, also using := to avoid extra execs Reviewed-by: katleman ! make/common/shared/Platform.gmk Changeset: 7c8c16f2c05e Author: ohair Date: 2012-01-09 09:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7c8c16f2c05e 7128320: Fix freetype sanity check to make it more generic Reviewed-by: luchsh, katleman Contributed-by: Jonathan Lu ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk ! make/common/Demo.gmk ! make/tools/freetypecheck/Makefile Changeset: 664fa4fb0ee4 Author: katleman Date: 2012-01-11 16:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/664fa4fb0ee4 Merge Changeset: dda27c73d8db Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/dda27c73d8db Added tag jdk8-b21 for changeset 664fa4fb0ee4 ! .hgtags Changeset: 76bfd08d8cc5 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/76bfd08d8cc5 Added tag jdk8-b22 for changeset dda27c73d8db ! .hgtags Changeset: db189e2f3cdb Author: jrose Date: 2012-01-18 17:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/db189e2f3cdb 7117167: Misc warnings in java.lang.invoke and sun.invoke.* Reviewed-by: smarks ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/invoke/util/Wrapper.java ! test/java/lang/invoke/CallSiteTest.java ! test/java/lang/invoke/ClassValueTest.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/lang/invoke/PermuteArgsTest.java ! test/java/lang/invoke/RicochetTest.java ! test/java/lang/invoke/ThrowExceptionsTest.java ! test/sun/invoke/util/ValueConversionsTest.java Changeset: 01014596ada1 Author: jrose Date: 2012-01-18 17:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/01014596ada1 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init Summary: Use correct access token for unreflecting MHs where setAccessible(true) Reviewed-by: never, twisti ! src/share/classes/java/lang/invoke/MethodHandles.java Changeset: 92d2cba30f08 Author: jrose Date: 2012-01-18 17:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/92d2cba30f08 7030453: JSR 292 ClassValue.get method is too slow Summary: Implement ClassValue cooperatively with Class like ThreadLocal with Thread. Reviewed-by: twisti, mduigou ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassValue.java ! test/java/lang/invoke/ClassValueTest.java Changeset: 81a2629aa2a2 Author: amurillo Date: 2012-01-20 14:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/81a2629aa2a2 Merge From Xuelei.Fan at Oracle.COM Mon Jan 23 04:21:31 2012 From: Xuelei.Fan at Oracle.COM (Xuelei Fan) Date: Mon, 23 Jan 2012 20:21:31 +0800 Subject: Code review request [JDK 8]: 7132248, sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java failing Message-ID: <4F1D50CB.2000908@Oracle.COM> Webrev: http://cr.openjdk.java.net/~xuelei/7132248/webrev.00/ In JDK 8, the regression tests of JSSE (HTTP/TLS) run in agentvm mode. In agentvm mode, multiple threads may share the thread pool. SunJSSE implementation initialize the SSL/TLS context at the first time the context get loaded, and will not dynamically change the context anymore after the initialization. If a test case has initialized the context, another test case share the same thread will use the same context. New settings in the later will have no impact on the context. The cause of the bug is that some other test case updated the context, and CookieHttpsClientTest cannot setup the context as expected. Need to make the test case run in othervm mode. Thanks, Xuelei From Alan.Bateman at oracle.com Mon Jan 23 04:25:37 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Jan 2012 12:25:37 +0000 Subject: Code review request [JDK 8]: 7132248, sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java failing In-Reply-To: <4F1D50CB.2000908@Oracle.COM> References: <4F1D50CB.2000908@Oracle.COM> Message-ID: <4F1D51C1.9020304@oracle.com> On 23/01/2012 12:21, Xuelei Fan wrote: > Webrev: http://cr.openjdk.java.net/~xuelei/7132248/webrev.00/ > > In JDK 8, the regression tests of JSSE (HTTP/TLS) run in agentvm > mode. In agentvm mode, multiple threads may share the thread pool. > SunJSSE implementation initialize the SSL/TLS context at the first > time the context get loaded, and will not dynamically change the > context anymore after the initialization. If a test case has > initialized the context, another test case share the same thread will > use the same context. New settings in the later will have no impact on > the context. > > The cause of the bug is that some other test case updated the context, > and CookieHttpsClientTest cannot setup the context as expected. Need > to make the test case run in othervm mode. > > Thanks, > Xuelei This looks fine to me, thanks for jumping on this annoying test failure. -Alan. PS: cc'ing security-dev as I'm guessing you cc'ed serviceabilty-dev in error. From xuelei.fan at oracle.com Mon Jan 23 04:45:29 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Mon, 23 Jan 2012 12:45:29 +0000 Subject: hg: jdk8/tl/jdk: 7132248: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java failing Message-ID: <20120123124542.588494712C@hg.openjdk.java.net> Changeset: d383b5d128e3 Author: xuelei Date: 2012-01-23 04:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d383b5d128e3 7132248: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java failing Reviewed-by: alanb ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java From daniel.daugherty at oracle.com Mon Jan 23 07:11:37 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 23 Jan 2012 08:11:37 -0700 Subject: RFR (XS) : 7131346 Parsing of boolean arguments to diagnostic commands is broken In-Reply-To: <4F197DF0.9070901@oracle.com> References: <4F17E99D.10908@oracle.com> <4F17EEFD.5040803@oracle.com> <4F17EFC5.7080909@oracle.com> <4F17F511.20803@oracle.com> <4F1800D9.6000708@oracle.com> <4F180343.2020301@oracle.com> <4F1807A4.9020706@oracle.com> <4F180A2A.40602@oracle.com> <4F180C50.20208@oracle.com> <4F180D7E.4030603@oracle.com> <4F194D7C.5080102@oracle.com> <4F197DF0.9070901@oracle.com> Message-ID: <4F1D78A9.1050208@oracle.com> src/share/vm/services/diagnosticArgument.cpp Maybe the following comment before line 65: // len is the length of the current token starting at str However, that's just a suggestion. Thumbs up. Dan On 1/20/12 7:45 AM, Frederic Parain wrote: > Thanks David, > > I just need a second reviewer and I'll push the fix. > > Fred > > On 1/20/12 12:18 PM, David Holmes wrote: >> On 19/01/2012 10:33 PM, Frederic Parain wrote: >>> On 01/19/12 01:28 PM, David Holmes wrote: >>>>> However, I'm not sure that trailing characters are properly >>>>> detected. Do you consider that as a show stopper? >>>> >>>> Depends on exactly what you mean by that. If extra junk characters are >>>> ignored rather than causing an error that's okay to me. >>> >>> They will be silently ignored. >> >> Not a showstopper in that case. >> >> So this looks good to go. >> >> David >> ----- >> >>> Fred >>> >>>>> Fred >>>>> >>>>>>> Fred >>>>>>> >>>>>>>> On 01/19/2012 11:48 AM, Dmitry Samersoff wrote: >>>>>>>>> Frederic, >>>>>>>>> >>>>>>>>> Sorry, of course >>>>>>>>> >>>>>>>>> strncasecmp(str, "true", 4) == 0&& str[4] == 0 >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> On 2012-01-19 14:26, Frederic Parain wrote: >>>>>>>>>> strncasecmp(str, "true", 4) == 0 would accept >>>>>>>>>> arguments like this: >>>>>>>>>> >>>>>>>>>> -all=truefalse >>>>>>>>>> >>>>>>>>>> which are not valid. >>>>>>>>>> >>>>>>>>>> Fred >>>>>>>>>> >>>>>>>>>> On 01/19/12 11:22 AM, Dmitry Samersoff wrote: >>>>>>>>>>> Frederic, >>>>>>>>>>> >>>>>>>>>>> I think explicit check for len is not necessary, >>>>>>>>>>> >>>>>>>>>>> strncasecmp(str, "true", 4) == 0 >>>>>>>>>>> >>>>>>>>>>> is enough. >>>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2012-01-19 13:59, Frederic Parain wrote: >>>>>>>>>>>> This is a small fix (2 lines) to fix an issue with the >>>>>>>>>>>> parsing of boolean arguments by diagnostic commands >>>>>>>>>>>> >>>>>>>>>>>> CR is not available on bugs.sun.com yet, but the description >>>>>>>>>>>> says that the string comparisons to identify "true" or "false" >>>>>>>>>>>> values doesn't take into account the length of the argument >>>>>>>>>>>> being parse. >>>>>>>>>>>> >>>>>>>>>>>> The suggested fix is: >>>>>>>>>>>> >>>>>>>>>>>> --- old/src/share/vm/services/diagnosticArgument.cpp Thu >>>>>>>>>>>> Jan 19 >>>>>>>>>>>> 10:36:10 2012 >>>>>>>>>>>> +++ new/src/share/vm/services/diagnosticArgument.cpp Thu >>>>>>>>>>>> Jan 19 >>>>>>>>>>>> 10:36:10 2012 >>>>>>>>>>>> @@ -62,9 +62,9 @@ >>>>>>>>>>>> if (len == 0) { >>>>>>>>>>>> set_value(true); >>>>>>>>>>>> } else { >>>>>>>>>>>> - if (strcasecmp(str, "true") == 0) { >>>>>>>>>>>> + if (len == strlen("true")&& strncasecmp(str, "true", len) == >>>>>>>>>>>> 0) { >>>>>>>>>>>> set_value(true); >>>>>>>>>>>> - } else if (strcasecmp(str, "false") == 0) { >>>>>>>>>>>> + } else if (len == strlen("false")&& strncasecmp(str, >>>>>>>>>>>> "false", >>>>>>>>>>>> len) >>>>>>>>>>>> == 0) { >>>>>>>>>>>> set_value(false); >>>>>>>>>>>> } else { >>>>>>>>>>>> THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~fparain/7131346/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Fred >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> > From sean.mullan at oracle.com Mon Jan 23 10:40:27 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Mon, 23 Jan 2012 18:40:27 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120123184046.6976E4713A@hg.openjdk.java.net> Changeset: 3df0bd3ed880 Author: mullan Date: 2012-01-23 12:17 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3df0bd3ed880 7131084: XMLDSig XPathFilter2Transform regression involving intersect filter Reviewed-by: xuelei ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPath2Filter.java ! test/javax/xml/crypto/dsig/KeySelectors.java ! test/javax/xml/crypto/dsig/ValidationTests.java ! test/javax/xml/crypto/dsig/X509KeySelector.java + test/javax/xml/crypto/dsig/data/xmldsig-xfilter2.xml Changeset: 5e1ad6ad41b7 Author: mullan Date: 2012-01-23 13:23 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e1ad6ad41b7 Merge From joe.darcy at oracle.com Mon Jan 23 12:17:44 2012 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 23 Jan 2012 20:17:44 +0000 Subject: hg: jdk8/tl/jdk: 7132338: Use @code friendly idiom for '\' in javadoc Message-ID: <20120123201754.053A04713D@hg.openjdk.java.net> Changeset: 914711cccc60 Author: darcy Date: 2012-01-23 12:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/914711cccc60 7132338: Use @code friendly idiom for '\' in javadoc Reviewed-by: alanb ! src/share/classes/java/io/DataInput.java ! src/share/classes/java/io/LineNumberInputStream.java ! src/share/classes/java/io/RandomAccessFile.java ! src/share/classes/java/io/StreamTokenizer.java ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/util/Properties.java From john.coomes at oracle.com Mon Jan 23 15:05:07 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Mon, 23 Jan 2012 23:05:07 +0000 Subject: hg: hsx/hotspot-rt/langtools: 8 new changesets Message-ID: <20120123230526.6EA2A47146@hg.openjdk.java.net> Changeset: 116f68a5e677 Author: jjg Date: 2011-12-23 22:30 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/116f68a5e677 7124605: typos in javac comments Reviewed-by: ksrini ! test/tools/javac/generics/diamond/7046778/DiamondAndInnerClassTest.java ! test/tools/javac/generics/inference/7086601/T7086601b.java ! test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java ! test/tools/javac/lambda/LambdaParserTest.java Changeset: 67512b631961 Author: lana Date: 2011-12-28 10:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/67512b631961 Merge Changeset: 7a836147b266 Author: jjg Date: 2012-01-03 11:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/7a836147b266 4881269: improve diagnostic for ill-formed tokens Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/IllegalDot.java + test/tools/javac/parser/T4881269.java + test/tools/javac/parser/T4881269.out Changeset: a07eef109532 Author: jjh Date: 2012-01-03 17:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/a07eef109532 7046929: tools/javac/api/T6397104.java fails Reviewed-by: jjg ! test/tools/javac/api/T6397104.java Changeset: 4e8aa6eca726 Author: lana Date: 2012-01-04 10:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/4e8aa6eca726 Merge Changeset: bcb21abf1c41 Author: lana Date: 2012-01-09 19:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/bcb21abf1c41 Merge Changeset: 390a7828ae18 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/390a7828ae18 Added tag jdk8-b21 for changeset bcb21abf1c41 ! .hgtags Changeset: f6191bad139a Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/f6191bad139a Added tag jdk8-b22 for changeset 390a7828ae18 ! .hgtags From coleen.phillimore at oracle.com Mon Jan 23 23:55:38 2012 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 24 Jan 2012 07:55:38 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20120124075544.82F584714D@hg.openjdk.java.net> Changeset: af739d5ab23c Author: bpittore Date: 2012-01-21 23:02 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/af739d5ab23c 6972759: Step over not working after thrown exception and Pop Summary: reset jvmtithreadstate exception state after frame pop and forceearlyreturn processed Reviewed-by: minqi, dholmes, dlong Contributed-by: bill.pittore at oracle.com ! src/share/vm/prims/jvmtiThreadState.cpp ! src/share/vm/prims/jvmtiThreadState.hpp Changeset: 583b428aa858 Author: coleenp Date: 2012-01-23 17:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/583b428aa858 Merge - src/os/bsd/vm/decoder_bsd.cpp From alan.bateman at oracle.com Tue Jan 24 01:23:06 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 24 Jan 2012 09:23:06 +0000 Subject: hg: jdk8/tl: 7132204: Default testset in JPRT should not run all tests Message-ID: <20120124092307.001B84715A@hg.openjdk.java.net> Changeset: 0f653ee93477 Author: alanb Date: 2012-01-24 09:08 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0f653ee93477 7132204: Default testset in JPRT should not run all tests Reviewed-by: ohair ! make/jprt.properties From alan.bateman at oracle.com Tue Jan 24 01:24:05 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 24 Jan 2012 09:24:05 +0000 Subject: hg: jdk8/tl/jdk: 7132204: Default testset in JPRT should not run all tests Message-ID: <20120124092421.4ABED4715B@hg.openjdk.java.net> Changeset: 237319a01a9a Author: alanb Date: 2012-01-24 09:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/237319a01a9a 7132204: Default testset in JPRT should not run all tests Reviewed-by: ohair ! make/jprt.properties ! test/ProblemList.txt From rickard.backman at oracle.com Tue Jan 24 05:00:42 2012 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Tue, 24 Jan 2012 13:00:42 +0000 Subject: hg: jdk8/tl/jdk: 7132386: makefile support for tracing/Java Flight Recorder framework phase I Message-ID: <20120124130105.1320547160@hg.openjdk.java.net> Changeset: 718bca4e685f Author: rbackman Date: 2012-01-17 16:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/718bca4e685f 7132386: makefile support for tracing/Java Flight Recorder framework phase I Reviewed-by: ohair, dholmes, rottenha Contributed-by: Markus Gronlund , Erik Gahlin , Nils Loodin , Rickard Backman , Staffan Larsen ! make/com/oracle/Makefile + make/com/oracle/jfr/Makefile ! make/common/Defs.gmk ! make/common/Release.gmk From maurizio.cimadamore at oracle.com Tue Jan 24 09:54:26 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 24 Jan 2012 17:54:26 +0000 Subject: hg: jdk8/tl/langtools: 7129801: Merge the two method applicability routines Message-ID: <20120124175432.C36B84716E@hg.openjdk.java.net> Changeset: 51fb17abfc32 Author: mcimadamore Date: 2012-01-24 17:52 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/51fb17abfc32 7129801: Merge the two method applicability routines Summary: Resolve.java and Infer.java should reuse the same method applicability check routine Reviewed-by: dlsmith, jjg ! 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/InferVarargsArgumentMismatch.java From kumar.x.srinivasan at oracle.com Tue Jan 24 10:02:10 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 24 Jan 2012 18:02:10 +0000 Subject: hg: jdk8/tl/jdk: 7132270: tools/launcher/DefaultLocaleTestRun.java failing (win) Message-ID: <20120124180231.8A5A04716F@hg.openjdk.java.net> Changeset: f64ea40293db Author: ksrini Date: 2012-01-24 09:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f64ea40293db 7132270: tools/launcher/DefaultLocaleTestRun.java failing (win) Reviewed-by: alanb, chegar ! test/tools/launcher/DefaultLocaleTestRun.java ! test/tools/launcher/TestHelper.java From lance.andersen at oracle.com Tue Jan 24 12:13:54 2012 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Tue, 24 Jan 2012 20:13:54 +0000 Subject: hg: jdk8/tl/jdk: 7132879: address Findbugs issue in WebRowSetXmlWriter Message-ID: <20120124201403.CD26347173@hg.openjdk.java.net> Changeset: 303b67074666 Author: lancea Date: 2012-01-24 15:13 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/303b67074666 7132879: address Findbugs issue in WebRowSetXmlWriter Reviewed-by: forax ! src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java From paul.hohensee at oracle.com Tue Jan 24 15:20:42 2012 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Tue, 24 Jan 2012 23:20:42 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7126732: MAC: Require Mac OS X builds/tests for JPRT integrate jobs for HotSpot Message-ID: <20120124232044.7364247177@hg.openjdk.java.net> Changeset: d6660fedbab5 Author: phh Date: 2012-01-24 14:07 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d6660fedbab5 7126732: MAC: Require Mac OS X builds/tests for JPRT integrate jobs for HotSpot Summary: Modify jprt.properties to run OSX builds and tests. Reviewed-by: dcubed, kamg, ohair, dholmes Contributed-by: james.melvin at oracle.com ! make/jprt.properties From jim.holmlund at sun.com Tue Jan 24 15:52:32 2012 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Tue, 24 Jan 2012 23:52:32 +0000 Subject: hg: jdk8/tl/langtools: 7126832: com.sun.tools.javac.api.ClientCodeWrapper$WrappedJavaFileManager cannot be cast Message-ID: <20120124235237.28C944717A@hg.openjdk.java.net> Changeset: ac36176b7de0 Author: jjh Date: 2012-01-24 15:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ac36176b7de0 7126832: com.sun.tools.javac.api.ClientCodeWrapper$WrappedJavaFileManager cannot be cast Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/main/Main.java + test/tools/javah/T7126832/T7126832.java + test/tools/javah/T7126832/java.java From jim.holmlund at sun.com Tue Jan 24 16:31:39 2012 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Wed, 25 Jan 2012 00:31:39 +0000 Subject: hg: jdk8/tl/langtools: 7129225: javac fails to run annotation processors when star import of package of gensrc Message-ID: <20120125003141.674D94717B@hg.openjdk.java.net> Changeset: d16b464e742c Author: jjh Date: 2012-01-24 16:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d16b464e742c 7129225: javac fails to run annotation processors when star import of package of gensrc Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/7129225/Anno.java + test/tools/javac/7129225/AnnoProcessor.java + test/tools/javac/7129225/NegTest.ref + test/tools/javac/7129225/TestImportStar.java + test/tools/javac/7129225/TestImportStar.ref From dmitriy.samersoff at oracle.com Tue Jan 24 22:23:08 2012 From: dmitriy.samersoff at oracle.com (dmitriy.samersoff at oracle.com) Date: Wed, 25 Jan 2012 06:23:08 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20120125062314.2422047187@hg.openjdk.java.net> Changeset: bf864f701a4a Author: dsamersoff Date: 2012-01-25 02:29 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/bf864f701a4a 7066129: GarbageCollectorMXBean#getLastGcInfo leaks native memory Summary: Make GCStatInfo a resource object Reviewed-by: phh, coleenp ! src/share/vm/services/gcNotifier.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp Changeset: df88f58f3b61 Author: dsamersoff Date: 2012-01-24 20:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/df88f58f3b61 Merge From paul.hohensee at oracle.com Wed Jan 25 03:38:15 2012 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Wed, 25 Jan 2012 11:38:15 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20120125113821.382CC4718E@hg.openjdk.java.net> Changeset: e8a4934564b2 Author: phh Date: 2012-01-24 19:33 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e8a4934564b2 7125793: MAC: test_gamma should always work Summary: Fix gamma launcher on Mac OS X and reconcile test_gamma script on Unix platforms Reviewed-by: dcubed, ohair, jcoomes, dholmes, ksrini Contributed-by: james.melvin at oracle.com ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/launcher.make ! make/bsd/makefiles/vm.make ! make/linux/makefiles/buildtree.make ! make/solaris/makefiles/buildtree.make ! src/os/bsd/vm/os_bsd.cpp ! src/os/posix/launcher/java_md.c Changeset: 78dadb7b16ab Author: phh Date: 2012-01-25 01:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/78dadb7b16ab Merge From keith.mcguigan at oracle.com Wed Jan 25 11:48:16 2012 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Wed, 25 Jan 2012 19:48:16 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 10 new changesets Message-ID: <20120125194835.C83EA4719B@hg.openjdk.java.net> Changeset: eaa9557116a2 Author: bdelsart Date: 2012-01-18 16:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/eaa9557116a2 7120448: Fix FP values for compiled frames in frame::describe Summary: fix for debug method frame::describe Reviewed-by: never, kvn ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.hpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp Changeset: 15d394228cfa Author: jrose Date: 2012-01-19 13:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/15d394228cfa 7111138: delete the obsolete flag -XX:+UseRicochetFrames Reviewed-by: dholmes, bdelsart, kvn, twisti ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/zero/vm/methodHandles_zero.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 898522ae3c32 Author: iveresov Date: 2012-01-19 10:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/898522ae3c32 7131288: COMPILE SKIPPED: deopt handler overflow (retry at different tier) Summary: Fix exception handler stub size, enable guarantees to check for the correct deopt and exception stub sizes in the future Reviewed-by: kvn, never, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 469e0a46f2fe Author: jrose Date: 2012-01-19 17:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/469e0a46f2fe Merge Changeset: 50d9b7a0072c Author: jrose Date: 2012-01-19 18:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/50d9b7a0072c Merge Changeset: 338d438ee229 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/338d438ee229 Added tag jdk8-b22 for changeset 24727fb37561 ! .hgtags Changeset: dcc292399a39 Author: amurillo Date: 2012-01-20 16:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/dcc292399a39 Merge - src/os/bsd/vm/decoder_bsd.cpp Changeset: e850d8e7ea54 Author: amurillo Date: 2012-01-20 16:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e850d8e7ea54 Added tag hs23-b11 for changeset dcc292399a39 ! .hgtags Changeset: 5f3fcd591768 Author: amurillo Date: 2012-01-20 17:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5f3fcd591768 7131979: new hotspot build - hs23-b12 Reviewed-by: jcoomes ! make/hotspot_version Changeset: d708a8cdd022 Author: kamg Date: 2012-01-25 10:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d708a8cdd022 Merge From jim.holmlund at sun.com Wed Jan 25 12:20:33 2012 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Wed, 25 Jan 2012 20:20:33 +0000 Subject: hg: jdk8/tl/langtools: 7133314: The regression test for 7129225 fails when run with jtreg -samevm or jtreg -agentvm Message-ID: <20120125202036.616FC4719D@hg.openjdk.java.net> Changeset: 332dfa0f91df Author: jjh Date: 2012-01-25 12:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/332dfa0f91df 7133314: The regression test for 7129225 fails when run with jtreg -samevm or jtreg -agentvm Reviewed-by: jjg ! test/tools/javac/7129225/AnnoProcessor.java ! test/tools/javac/7129225/NegTest.ref ! test/tools/javac/7129225/TestImportStar.java ! test/tools/javac/7129225/TestImportStar.ref From frederic.parain at oracle.com Wed Jan 25 18:55:35 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Thu, 26 Jan 2012 02:55:35 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20120126025539.9D18F471BB@hg.openjdk.java.net> Changeset: 520830f632e7 Author: fparain Date: 2012-01-25 10:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/520830f632e7 7131346: Parsing of boolean arguments to diagnostic commands is broken Reviewed-by: dholmes, dcubed ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp Changeset: 24ec1a6d6ef3 Author: fparain Date: 2012-01-25 16:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/24ec1a6d6ef3 Merge From dmitriy.samersoff at oracle.com Wed Jan 25 21:19:48 2012 From: dmitriy.samersoff at oracle.com (dmitriy.samersoff at oracle.com) Date: Thu, 26 Jan 2012 05:19:48 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets Message-ID: <20120126051954.66E6B471BD@hg.openjdk.java.net> Changeset: a42c07c38c47 Author: dsamersoff Date: 2012-01-25 21:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a42c07c38c47 7132515: Add dcmd to manage UnlockingCommercialFeature flag Summary: Added dcmd to unlock or check status of UnlockingCommercialFeature flag Reviewed-by: fparain, rottenha ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp + src/share/vm/services/diagnosticCommand_ext.hpp ! src/share/vm/services/diagnosticFramework.hpp ! src/share/vm/services/management.cpp Changeset: 6d00795f99a1 Author: dsamersoff Date: 2012-01-25 15:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6d00795f99a1 Merge Changeset: 6db63e782d3d Author: dsamersoff Date: 2012-01-25 18:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6db63e782d3d Merge From yuka.kamiya at oracle.com Thu Jan 26 00:08:38 2012 From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com) Date: Thu, 26 Jan 2012 08:08:38 +0000 Subject: hg: jdk8/tl/jdk: 7017458: (cal) Multithreaded deserialization of Calendar leads to ClassCastException Message-ID: <20120126080847.A0FEA471C1@hg.openjdk.java.net> Changeset: ceab7e149581 Author: peytoia Date: 2012-01-26 17:06 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ceab7e149581 7017458: (cal) Multithreaded deserialization of Calendar leads to ClassCastException Reviewed-by: okutsu ! src/share/classes/java/util/Calendar.java + test/java/util/Calendar/Bug7017458.java From rickard.backman at oracle.com Thu Jan 26 01:44:10 2012 From: rickard.backman at oracle.com (=?UTF-8?B?Umlja2FyZCBCw6Rja21hbg==?=) Date: Thu, 26 Jan 2012 10:44:10 +0100 Subject: RFR: 7133124 Remove redundant packages from JAR command line Message-ID: <4F21206A.1040907@oracle.com> Hi, We have a problem with some versions of jar reporting errors when trying to run jar cf com/test com/test/foo This fix removes the redundant subdirectories from the command. Webrev is here: http://cr.openjdk.java.net/~rbackman/7133124/webrev/ Thanks /Rickard From Alan.Bateman at oracle.com Thu Jan 26 01:51:43 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 26 Jan 2012 09:51:43 +0000 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <4F21206A.1040907@oracle.com> References: <4F21206A.1040907@oracle.com> Message-ID: <4F21222F.5070605@oracle.com> On 26/01/2012 09:44, Rickard B?ckman wrote: > Hi, > > We have a problem with some versions of jar reporting errors when > trying to run jar cf com/test com/test/foo > > This fix removes the redundant subdirectories from the command. > > Webrev is here: > http://cr.openjdk.java.net/~rbackman/7133124/webrev/ > > Thanks > /Rickard Looks okay to me. -Alan. From markus.gronlund at oracle.com Thu Jan 26 01:57:47 2012 From: markus.gronlund at oracle.com (=?utf-8?B?TWFya3VzIEdyw7ZubHVuZA==?=) Date: Thu, 26 Jan 2012 01:57:47 -0800 (PST) Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <4F21222F.5070605@oracle.com> References: <4F21206A.1040907@oracle.com> <4F21222F.5070605@oracle.com> Message-ID: Thanks Alan for quick response, much appreciated. Markus > -----Original Message----- > From: Alan Bateman > Sent: den 26 januari 2012 10:52 > To: Rickard B?ckman > Cc: serviceability-dev at openjdk.java.net; build-dev at openjdk.java.net > Subject: Re: RFR: 7133124 Remove redundant packages from JAR command > line > > On 26/01/2012 09:44, Rickard B?ckman wrote: > > Hi, > > > > We have a problem with some versions of jar reporting errors when > > trying to run jar cf com/test com/test/foo > > > > This fix removes the redundant subdirectories from the command. > > > > Webrev is here: > > http://cr.openjdk.java.net/~rbackman/7133124/webrev/ > > > > Thanks > > /Rickard > Looks okay to me. > > -Alan. From rickard.backman at oracle.com Thu Jan 26 01:58:55 2012 From: rickard.backman at oracle.com (=?UTF-8?B?Umlja2FyZCBCw6Rja21hbg==?=) Date: Thu, 26 Jan 2012 10:58:55 +0100 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <4F21222F.5070605@oracle.com> References: <4F21206A.1040907@oracle.com> <4F21222F.5070605@oracle.com> Message-ID: <4F2123DF.7060206@oracle.com> On 01/26/2012 10:51 AM, Alan Bateman wrote: > On 26/01/2012 09:44, Rickard B?ckman wrote: >> Hi, >> >> We have a problem with some versions of jar reporting errors when >> trying to run jar cf com/test com/test/foo >> >> This fix removes the redundant subdirectories from the command. >> >> Webrev is here: >> http://cr.openjdk.java.net/~rbackman/7133124/webrev/ >> >> Thanks >> /Rickard > Looks okay to me. > > -Alan. Thank you for your quick review & response Alan! /R From david.holmes at oracle.com Thu Jan 26 03:50:49 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Jan 2012 21:50:49 +1000 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <4F21206A.1040907@oracle.com> References: <4F21206A.1040907@oracle.com> Message-ID: <4F213E19.90508@oracle.com> On 26/01/2012 7:44 PM, Rickard B?ckman wrote: > We have a problem with some versions of jar reporting errors when trying > to run jar cf com/test com/test/foo > > This fix removes the redundant subdirectories from the command. > > Webrev is here: > http://cr.openjdk.java.net/~rbackman/7133124/webrev/ Change looks fine, but then so did the original! Will this be handled correctly by all versions of the jar command? David > Thanks > /Rickard From karen.kinnear at oracle.com Thu Jan 26 03:53:58 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 26 Jan 2012 06:53:58 -0500 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <4F21206A.1040907@oracle.com> References: <4F21206A.1040907@oracle.com> Message-ID: <6976A397-BFE9-48A4-B63D-5AC4BA633609@oracle.com> Code change looks good. I assume you want to put this fix back to JDK8 as well. thank you for the quick fix! Karen On Jan 26, 2012, at 4:44 AM, Rickard B?ckman wrote: > Hi, > > We have a problem with some versions of jar reporting errors when trying to run jar cf com/test com/test/foo > > This fix removes the redundant subdirectories from the command. > > Webrev is here: > http://cr.openjdk.java.net/~rbackman/7133124/webrev/ > > Thanks > /Rickard From rickard.backman at oracle.com Thu Jan 26 04:02:40 2012 From: rickard.backman at oracle.com (=?UTF-8?B?Umlja2FyZCBCw6Rja21hbg==?=) Date: Thu, 26 Jan 2012 13:02:40 +0100 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <4F213E19.90508@oracle.com> References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com> Message-ID: <4F2140E0.5040802@oracle.com> On 01/26/2012 12:50 PM, David Holmes wrote: > On 26/01/2012 7:44 PM, Rickard B?ckman wrote: >> We have a problem with some versions of jar reporting errors when trying >> to run jar cf com/test com/test/foo >> >> This fix removes the redundant subdirectories from the command. >> >> Webrev is here: >> http://cr.openjdk.java.net/~rbackman/7133124/webrev/ > > Change looks fine, but then so did the original! Will this be handled > correctly by all versions of the jar command? > > David David, thanks for the review. We, have checked the contents of the version that RE is using (1.6.0_1 or something like that) and the one JPRT is using (1.6.0_18) and locally on my machine (1.7.0) I don't think I'll be able to verify _all_ versions of jar. It seems the "faulty" behavior of "jar" was fixed in 1.6.0_18 which is the first version I could find that didn't cause the error on the previous code. I would rather hope that we could try to use one and the same version across all kind of builds of the same jdk version. It would help to catch this kind of errors earlier... Thanks /R > >> Thanks >> /Rickard From rickard.backman at oracle.com Thu Jan 26 04:03:49 2012 From: rickard.backman at oracle.com (=?ISO-8859-1?Q?Rickard_B=E4ckman?=) Date: Thu, 26 Jan 2012 13:03:49 +0100 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <6976A397-BFE9-48A4-B63D-5AC4BA633609@oracle.com> References: <4F21206A.1040907@oracle.com> <6976A397-BFE9-48A4-B63D-5AC4BA633609@oracle.com> Message-ID: <4F214125.7080803@oracle.com> On 01/26/2012 12:53 PM, Karen Kinnear wrote: > Code change looks good. > I assume you want to put this fix back to JDK8 as well. > > thank you for the quick fix! > Karen Thanks for the review Karen, I'm not sure about JDK8, I think it build with JDK1.7.0? Which has a fixed version of jar. I'll try to find out if we need to fix it in 8 as well. /R > > On Jan 26, 2012, at 4:44 AM, Rickard B?ckman wrote: > >> Hi, >> >> We have a problem with some versions of jar reporting errors when trying to run jar cf com/test com/test/foo >> >> This fix removes the redundant subdirectories from the command. >> >> Webrev is here: >> http://cr.openjdk.java.net/~rbackman/7133124/webrev/ >> >> Thanks >> /Rickard > From karen.kinnear at oracle.com Thu Jan 26 04:20:39 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 26 Jan 2012 07:20:39 -0500 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <4F214125.7080803@oracle.com> References: <4F21206A.1040907@oracle.com> <6976A397-BFE9-48A4-B63D-5AC4BA633609@oracle.com> <4F214125.7080803@oracle.com> Message-ID: <1C14E4C5-6A22-4482-A18B-F6768113AF4E@oracle.com> Thanks Rickard. My guess is that if it works with all version of jar which you've tested, then it will be easier going forward to maintain the file consistently, and it causes no harm. thanks, Karen On Jan 26, 2012, at 7:03 AM, Rickard B?ckman wrote: > On 01/26/2012 12:53 PM, Karen Kinnear wrote: >> Code change looks good. >> I assume you want to put this fix back to JDK8 as well. >> >> thank you for the quick fix! >> Karen > > Thanks for the review Karen, > > I'm not sure about JDK8, I think it build with JDK1.7.0? Which has a fixed version of jar. > > I'll try to find out if we need to fix it in 8 as well. > > /R > >> >> On Jan 26, 2012, at 4:44 AM, Rickard B?ckman wrote: >> >>> Hi, >>> >>> We have a problem with some versions of jar reporting errors when trying to run jar cf com/test com/test/foo >>> >>> This fix removes the redundant subdirectories from the command. >>> >>> Webrev is here: >>> http://cr.openjdk.java.net/~rbackman/7133124/webrev/ >>> >>> Thanks >>> /Rickard >> > From rickard.backman at oracle.com Thu Jan 26 04:37:51 2012 From: rickard.backman at oracle.com (=?ISO-8859-1?Q?Rickard_B=E4ckman?=) Date: Thu, 26 Jan 2012 13:37:51 +0100 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <1C14E4C5-6A22-4482-A18B-F6768113AF4E@oracle.com> References: <4F21206A.1040907@oracle.com> <6976A397-BFE9-48A4-B63D-5AC4BA633609@oracle.com> <4F214125.7080803@oracle.com> <1C14E4C5-6A22-4482-A18B-F6768113AF4E@oracle.com> Message-ID: <4F21491F.8020608@oracle.com> Karen, that makes sense, I'll push to 8 as well. Thanks /R On 01/26/2012 01:20 PM, Karen Kinnear wrote: > Thanks Rickard. > > My guess is that if it works with all version of jar which you've tested, then it will > be easier going forward to maintain the file consistently, and it causes no harm. > > thanks, > Karen > > On Jan 26, 2012, at 7:03 AM, Rickard B?ckman wrote: > >> On 01/26/2012 12:53 PM, Karen Kinnear wrote: >>> Code change looks good. >>> I assume you want to put this fix back to JDK8 as well. >>> >>> thank you for the quick fix! >>> Karen >> >> Thanks for the review Karen, >> >> I'm not sure about JDK8, I think it build with JDK1.7.0? Which has a fixed version of jar. >> >> I'll try to find out if we need to fix it in 8 as well. >> >> /R >> >>> >>> On Jan 26, 2012, at 4:44 AM, Rickard B?ckman wrote: >>> >>>> Hi, >>>> >>>> We have a problem with some versions of jar reporting errors when trying to run jar cf com/test com/test/foo >>>> >>>> This fix removes the redundant subdirectories from the command. >>>> >>>> Webrev is here: >>>> http://cr.openjdk.java.net/~rbackman/7133124/webrev/ >>>> >>>> Thanks >>>> /Rickard >>> >> > From rickard.backman at oracle.com Thu Jan 26 05:08:59 2012 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Thu, 26 Jan 2012 13:08:59 +0000 Subject: hg: jdk8/tl/jdk: 7133124: Remove redundant packages from JAR command line Message-ID: <20120126130920.71D86471CB@hg.openjdk.java.net> Changeset: 350971f50949 Author: rbackman Date: 2012-01-26 09:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/350971f50949 7133124: Remove redundant packages from JAR command line Reviewed-by: acorn, alanb, dholmes, rottenha ! make/common/Release.gmk From rickard.backman at oracle.com Thu Jan 26 05:17:00 2012 From: rickard.backman at oracle.com (=?UTF-8?B?Umlja2FyZCBCw6Rja21hbg==?=) Date: Thu, 26 Jan 2012 14:17:00 +0100 Subject: RFR: 7130476 - Remove use of #ifdef TRACE_DEFINE_KLASS_TRACE_ID from klass.hpp Message-ID: <4F21524C.8030506@oracle.com> Hi, can I have some reviews for this change? I decided to go with unused typedefs (thanks Keith) for the usages in the class definition and a do { } while (0) in the method definition. The webrev: http://cr.openjdk.java.net/~rbackman/7130476/webrev/ Thanks /R From keith.mcguigan at oracle.com Thu Jan 26 05:20:58 2012 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Thu, 26 Jan 2012 08:20:58 -0500 Subject: RFR: 7130476 - Remove use of #ifdef TRACE_DEFINE_KLASS_TRACE_ID from klass.hpp In-Reply-To: <4F21524C.8030506@oracle.com> References: <4F21524C.8030506@oracle.com> Message-ID: <4F21533A.4060206@oracle.com> Looks great, thanks! -- - Keith On 1/26/2012 8:17 AM, Rickard B?ckman wrote: > Hi, > > can I have some reviews for this change? > I decided to go with unused typedefs (thanks Keith) for the usages in > the class definition and a do { } while (0) in the method definition. > > The webrev: > http://cr.openjdk.java.net/~rbackman/7130476/webrev/ > > Thanks > /R From Dmitry.Samersoff at oracle.com Thu Jan 26 05:29:46 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 26 Jan 2012 17:29:46 +0400 Subject: RFR: 7130476 - Remove use of #ifdef TRACE_DEFINE_KLASS_TRACE_ID from klass.hpp In-Reply-To: <4F21524C.8030506@oracle.com> References: <4F21524C.8030506@oracle.com> Message-ID: <4F21554A.9090202@oracle.com> Looks good for me. On 2012-01-26 17:17, Rickard B?ckman wrote: > Hi, > > can I have some reviews for this change? > I decided to go with unused typedefs (thanks Keith) for the usages in > the class definition and a do { } while (0) in the method definition. > > The webrev: > http://cr.openjdk.java.net/~rbackman/7130476/webrev/ > > Thanks > /R -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From rickard.backman at oracle.com Thu Jan 26 05:45:14 2012 From: rickard.backman at oracle.com (=?UTF-8?B?Umlja2FyZCBCw6Rja21hbg==?=) Date: Thu, 26 Jan 2012 14:45:14 +0100 Subject: RFR: 7130476 - Remove use of #ifdef TRACE_DEFINE_KLASS_TRACE_ID from klass.hpp In-Reply-To: <4F21554A.9090202@oracle.com> References: <4F21524C.8030506@oracle.com> <4F21554A.9090202@oracle.com> Message-ID: <4F2158EA.6000808@oracle.com> Thank you, Dmitry! /R On 01/26/2012 02:29 PM, Dmitry Samersoff wrote: > Looks good for me. > > On 2012-01-26 17:17, Rickard B?ckman wrote: >> Hi, >> >> can I have some reviews for this change? >> I decided to go with unused typedefs (thanks Keith) for the usages in >> the class definition and a do { } while (0) in the method definition. >> >> The webrev: >> http://cr.openjdk.java.net/~rbackman/7130476/webrev/ >> >> Thanks >> /R > > From paul.hohensee at oracle.com Thu Jan 26 06:14:51 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 26 Jan 2012 09:14:51 -0500 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <4F21206A.1040907@oracle.com> References: <4F21206A.1040907@oracle.com> Message-ID: <4F215FDB.8090209@oracle.com> Will this fix the jdk7u-dev build problem? Thanks, paul On 1/26/12 4:44 AM, Rickard B?ckman wrote: > Hi, > > We have a problem with some versions of jar reporting errors when > trying to run jar cf com/test com/test/foo > > This fix removes the redundant subdirectories from the command. > > Webrev is here: > http://cr.openjdk.java.net/~rbackman/7133124/webrev/ > > Thanks > /Rickard From paul.hohensee at oracle.com Thu Jan 26 06:18:50 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 26 Jan 2012 09:18:50 -0500 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <4F215FDB.8090209@oracle.com> References: <4F21206A.1040907@oracle.com> <4F215FDB.8090209@oracle.com> Message-ID: <4F2160CA.4090702@oracle.com> Apparently yes. Thanks, paul On 1/26/12 9:14 AM, Paul Hohensee wrote: > Will this fix the jdk7u-dev build problem? > > Thanks, > > paul > > On 1/26/12 4:44 AM, Rickard B?ckman wrote: >> Hi, >> >> We have a problem with some versions of jar reporting errors when >> trying to run jar cf com/test com/test/foo >> >> This fix removes the redundant subdirectories from the command. >> >> Webrev is here: >> http://cr.openjdk.java.net/~rbackman/7133124/webrev/ >> >> Thanks >> /Rickard From paul.hohensee at oracle.com Thu Jan 26 06:27:19 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 26 Jan 2012 09:27:19 -0500 Subject: RFR: 7130476 - Remove use of #ifdef TRACE_DEFINE_KLASS_TRACE_ID from klass.hpp In-Reply-To: <4F21524C.8030506@oracle.com> References: <4F21524C.8030506@oracle.com> Message-ID: <4F2162C7.5010209@oracle.com> Looks good. Paul On 1/26/12 8:17 AM, Rickard B?ckman wrote: > Hi, > > can I have some reviews for this change? > I decided to go with unused typedefs (thanks Keith) for the usages in > the class definition and a do { } while (0) in the method definition. > > The webrev: > http://cr.openjdk.java.net/~rbackman/7130476/webrev/ > > Thanks > /R From david.holmes at oracle.com Thu Jan 26 13:43:53 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Jan 2012 07:43:53 +1000 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <4F21491F.8020608@oracle.com> References: <4F21206A.1040907@oracle.com> <6976A397-BFE9-48A4-B63D-5AC4BA633609@oracle.com> <4F214125.7080803@oracle.com> <1C14E4C5-6A22-4482-A18B-F6768113AF4E@oracle.com> <4F21491F.8020608@oracle.com> Message-ID: <4F21C919.8030802@oracle.com> On 26/01/2012 10:37 PM, Rickard B?ckman wrote: > Karen, > > that makes sense, I'll push to 8 as well. Recall that I plan to change all this by moving it into make/closed for 8 (and then 7u). So this could be cleaned up then. David ----- > Thanks > /R > > On 01/26/2012 01:20 PM, Karen Kinnear wrote: >> Thanks Rickard. >> >> My guess is that if it works with all version of jar which you've >> tested, then it will >> be easier going forward to maintain the file consistently, and it >> causes no harm. >> >> thanks, >> Karen >> >> On Jan 26, 2012, at 7:03 AM, Rickard B?ckman wrote: >> >>> On 01/26/2012 12:53 PM, Karen Kinnear wrote: >>>> Code change looks good. >>>> I assume you want to put this fix back to JDK8 as well. >>>> >>>> thank you for the quick fix! >>>> Karen >>> >>> Thanks for the review Karen, >>> >>> I'm not sure about JDK8, I think it build with JDK1.7.0? Which has a >>> fixed version of jar. >>> >>> I'll try to find out if we need to fix it in 8 as well. >>> >>> /R >>> >>>> >>>> On Jan 26, 2012, at 4:44 AM, Rickard B?ckman wrote: >>>> >>>>> Hi, >>>>> >>>>> We have a problem with some versions of jar reporting errors when >>>>> trying to run jar cf com/test com/test/foo >>>>> >>>>> This fix removes the redundant subdirectories from the command. >>>>> >>>>> Webrev is here: >>>>> http://cr.openjdk.java.net/~rbackman/7133124/webrev/ >>>>> >>>>> Thanks >>>>> /Rickard >>>> >>> >> > From david.holmes at oracle.com Thu Jan 26 13:56:02 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Jan 2012 07:56:02 +1000 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <4F2140E0.5040802@oracle.com> References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com> <4F2140E0.5040802@oracle.com> Message-ID: <4F21CBF2.1040407@oracle.com> On 26/01/2012 10:02 PM, Rickard B?ckman wrote: > On 01/26/2012 12:50 PM, David Holmes wrote: >> Change looks fine, but then so did the original! Will this be handled >> correctly by all versions of the jar command? > > We, have checked the contents of the version that RE is using (1.6.0_1 > or something like that) and the one JPRT is using (1.6.0_18) and locally > on my machine (1.7.0) I don't think I'll be able to verify _all_ > versions of jar. It seems the "faulty" behavior of "jar" was fixed in > 1.6.0_18 which is the first version I could find that didn't cause the > error on the previous code. I would rather hope that we could try to use > one and the same version across all kind of builds of the same jdk > version. It would help to catch this kind of errors earlier... Sorry I meant "all versions of jar that we might build with" :) I think the normal RE process is to build JDK N with the FCS version of JDK N-1, which would explain why the old JDK 6 jar is being used. JPRT has changes to the bootjdks made "on demand". As long as we target both 7u and 8 we will be using two different toolsets. But I agree that JPRT and RE should be using the same tools. That needs to be taken up with RE and Kelly. Thanks, David > Thanks > /R > >> >>> Thanks >>> /Rickard > From lance.andersen at oracle.com Thu Jan 26 16:42:05 2012 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Fri, 27 Jan 2012 00:42:05 +0000 Subject: hg: jdk8/tl/jdk: 7133815: address the findbug errors in CachedRowSetImpl, SerialStruct, BaseRow, SerialInputImpl, SerialOutputImpl Message-ID: <20120127004215.C6803471E7@hg.openjdk.java.net> Changeset: b518b160607f Author: lancea Date: 2012-01-26 19:41 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b518b160607f 7133815: address the findbug errors in CachedRowSetImpl, SerialStruct, BaseRow, SerialInputImpl, SerialOutputImpl Reviewed-by: forax ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/BaseRow.java ! src/share/classes/javax/sql/rowset/serial/SQLInputImpl.java ! src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java ! src/share/classes/javax/sql/rowset/serial/SerialStruct.java From bradford.wetmore at oracle.com Thu Jan 26 17:16:54 2012 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Fri, 27 Jan 2012 01:16:54 +0000 Subject: hg: jdk8/tl/jdk: 7126889: Incorrect SSLEngine debug output Message-ID: <20120127011704.23275471EA@hg.openjdk.java.net> Changeset: 5ee30ab905db Author: wetmore Date: 2012-01-26 17:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ee30ab905db 7126889: Incorrect SSLEngine debug output Reviewed-by: xuelei ! src/share/classes/sun/security/ssl/EngineArgs.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh From john.coomes at oracle.com Thu Jan 26 20:53:07 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 27 Jan 2012 04:53:07 +0000 Subject: hg: hsx/hotspot-rt: Added tag jdk8-b23 for changeset 60d6f64a86b1 Message-ID: <20120127045307.BE6DC47213@hg.openjdk.java.net> Changeset: 1a5f1d6b98d6 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/1a5f1d6b98d6 Added tag jdk8-b23 for changeset 60d6f64a86b1 ! .hgtags From john.coomes at oracle.com Thu Jan 26 20:53:15 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 27 Jan 2012 04:53:15 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b23 for changeset 5218eb256658 Message-ID: <20120127045317.8CAA747214@hg.openjdk.java.net> Changeset: b98f0e6dddf9 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/b98f0e6dddf9 Added tag jdk8-b23 for changeset 5218eb256658 ! .hgtags From john.coomes at oracle.com Thu Jan 26 20:53:26 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 27 Jan 2012 04:53:26 +0000 Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b23 for changeset 95102fd33418 Message-ID: <20120127045326.BA11A47215@hg.openjdk.java.net> Changeset: 7836655e2495 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/7836655e2495 Added tag jdk8-b23 for changeset 95102fd33418 ! .hgtags From john.coomes at oracle.com Thu Jan 26 20:53:42 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 27 Jan 2012 04:53:42 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b23 for changeset 25ce7a000487 Message-ID: <20120127045342.ACEF947216@hg.openjdk.java.net> Changeset: e0d90803439b Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/e0d90803439b Added tag jdk8-b23 for changeset 25ce7a000487 ! .hgtags From john.coomes at oracle.com Thu Jan 26 20:54:38 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 27 Jan 2012 04:54:38 +0000 Subject: hg: hsx/hotspot-rt/jdk: 43 new changesets Message-ID: <20120127050209.DB24147218@hg.openjdk.java.net> Changeset: 44bd765c22f4 Author: prr Date: 2012-01-13 13:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/44bd765c22f4 7127827: JRE8: javaws fails to launch on oracle linux due to XRender Reviewed-by: bae, jgodinez ! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java Changeset: b566004bcb1a Author: dbuck Date: 2012-01-16 11:52 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b566004bcb1a 7083621: Add fontconfig file for OEL6 and rename RH/O EL 5 file so that it is picked up for all 5.x updates Reviewed-by: bae, prr ! make/sun/awt/Makefile Changeset: 397667460892 Author: lana Date: 2012-01-18 11:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/397667460892 Merge - test/tools/launcher/DefaultLocaleTest.sh Changeset: e0f94b9c53a8 Author: alexsch Date: 2012-01-10 15:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e0f94b9c53a8 7110815: closed/javax/swing/JSplitPane/4885629/bug4885629.java unstable on MacOS Reviewed-by: kizune + test/javax/swing/JSplitPane/4885629/bug4885629.java Changeset: 79d14e328670 Author: alexsch Date: 2012-01-10 17:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/79d14e328670 6505523: NullPointerException in BasicTreeUI when a node is removed by expansion listener Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java + test/javax/swing/JTree/6505523/bug6505523.java Changeset: ce32a4e1be1d Author: alexsch Date: 2012-01-13 12:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ce32a4e1be1d 7121765: closed/javax/swing/JTextArea/4697612/bug4697612.java fails on MacOS on Aqua L&F Reviewed-by: rupashka + test/javax/swing/JTextArea/4697612/bug4697612.java + test/javax/swing/JTextArea/4697612/bug4697612.txt Changeset: 59b8875949e1 Author: malenkov Date: 2012-01-16 18:28 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/59b8875949e1 7122740: PropertyDescriptor Performance Slow Reviewed-by: rupashka ! src/share/classes/com/sun/beans/TypeResolver.java Changeset: 3e9d35e6ee4f Author: denis Date: 2012-01-17 19:09 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3e9d35e6ee4f 7110590: DnDMerlinQLTestsuite_DnDJTextArea test fails with an java.awt.dnd.InvalidDnDOperationException Reviewed-by: art ! src/share/classes/java/awt/AWTKeyStroke.java Changeset: 89bc9d08fe82 Author: anthony Date: 2012-01-18 19:09 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/89bc9d08fe82 7130662: GTK file dialog crashes with a NPE Summary: Guard adding a back slash to the directory name with an if (!= null) check Reviewed-by: anthony, art Contributed-by: Matt ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java Changeset: fe1278123fbb Author: lana Date: 2012-01-18 11:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/fe1278123fbb Merge - test/tools/launcher/DefaultLocaleTest.sh Changeset: 4d8b49a45cff Author: lana Date: 2012-01-18 20:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4d8b49a45cff Merge Changeset: 400cc379adb5 Author: alanb Date: 2012-01-06 15:00 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/400cc379adb5 7127235: (fs) NPE in Files.walkFileTree if cached attributes are GC'ed Reviewed-by: forax, chegar ! src/share/classes/java/nio/file/FileTreeWalker.java Changeset: cdc128128044 Author: valeriep Date: 2012-01-05 18:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cdc128128044 6414899: P11Digest should support cloning Summary: Enhanced the PKCS11 Digest implementation to support cloning Reviewed-by: vinnie ! make/sun/security/pkcs11/mapfile-vers ! src/share/classes/sun/security/pkcs11/P11Digest.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java ! src/share/lib/security/sunpkcs11-solaris.cfg ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h + test/sun/security/pkcs11/MessageDigest/TestCloning.java Changeset: e6ef778c1df4 Author: valeriep Date: 2012-01-06 11:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e6ef778c1df4 Merge Changeset: 6720ae7b1448 Author: valeriep Date: 2012-01-06 16:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6720ae7b1448 7033170: Cipher.getMaxAllowedKeyLength(String) throws NoSuchAlgorithmException Summary: Changed to always use full transformation as provider properties. Reviewed-by: mullan ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! test/javax/crypto/Cipher/GetMaxAllowed.java Changeset: 2050ff9dfc92 Author: darcy Date: 2012-01-06 18:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2050ff9dfc92 7123649: Remove public modifier from Math.powerOfTwoF. Reviewed-by: smarks, alanb ! src/share/classes/java/lang/Math.java Changeset: 74c92c3e66ad Author: gadams Date: 2012-01-09 19:33 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/74c92c3e66ad 7030573: test/java/io/FileInputStream/LargeFileAvailable.java fails when there is insufficient disk space Reviewed-by: alanb ! test/java/io/FileInputStream/LargeFileAvailable.java Changeset: 858038d89fd5 Author: darcy Date: 2012-01-09 15:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/858038d89fd5 7128441: StrictMath performance improvement note shared with Math Reviewed-by: darcy Contributed-by: Martin Desruisseaux ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java Changeset: dd69d3695cee Author: darcy Date: 2012-01-09 20:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/dd69d3695cee 7128512: Javadoc typo in java.lang.invoke.MethodHandle Reviewed-by: mduigou ! src/share/classes/java/lang/invoke/MethodHandle.java Changeset: d72de8b3fe36 Author: chegar Date: 2012-01-10 10:57 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d72de8b3fe36 7123415: Some cases of network interface indexes being read incorrectly Reviewed-by: chegar Contributed-by: brandon.passanisi at oracle.com ! src/solaris/native/java/net/net_util_md.c Changeset: bba276a6aa0d Author: chegar Date: 2012-01-10 12:48 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bba276a6aa0d 7128584: Typo in sun.misc.VM's private directMemory field comment Reviewed-by: forax, chegar Contributed-by: Krystal Mok ! src/share/classes/sun/misc/VM.java Changeset: 49e64a8fc18f Author: darcy Date: 2012-01-10 17:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/49e64a8fc18f 7112008: Javadoc for j.l.Object.finalize() vs JLS 12.6 Finalization of Class Instances Reviewed-by: mduigou ! src/share/classes/java/lang/Object.java Changeset: 62dbcbe4c446 Author: darcy Date: 2012-01-10 17:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/62dbcbe4c446 7128931: Bad HTML escaping in java.lang.Throwable javadoc Reviewed-by: mduigou ! src/share/classes/java/lang/Throwable.java Changeset: 31a1fc60a895 Author: chegar Date: 2012-01-11 10:52 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/31a1fc60a895 7128648: HttpURLConnection.getHeaderFields should return an unmodifiable Map Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/java/net/HttpURLConnection/UnmodifiableMaps.java Changeset: 82144054d2d8 Author: alanb Date: 2012-01-11 13:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/82144054d2d8 7068856: (fs) Typo in Files.isSameFile() javadoc 7099208: (fs) Files.newBufferedReader has typo in javadoc Reviewed-by: forax ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/Path.java Changeset: 96fe796fd242 Author: ksrini Date: 2012-01-11 08:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/96fe796fd242 7125442: jar application located in two bytes character named folder cannot be run with JRE 7 u1/u2 Reviewed-by: sherman, mchung, darcy ! src/share/bin/java.c + test/tools/launcher/I18NJarTest.java ! test/tools/launcher/TestHelper.java Changeset: 11e52d5ba64e Author: xuelei Date: 2012-01-12 03:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/11e52d5ba64e 7106773: 512 bits RSA key cannot work with SHA384 and SHA512 Reviewed-by: weijun ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java + src/share/classes/sun/security/util/KeyLength.java + src/share/classes/sun/security/util/Length.java ! src/windows/classes/sun/security/mscapi/Key.java ! src/windows/classes/sun/security/mscapi/RSACipher.java ! src/windows/classes/sun/security/mscapi/RSASignature.java + test/sun/security/mscapi/ShortRSAKey1024.sh + test/sun/security/mscapi/ShortRSAKey512.sh + test/sun/security/mscapi/ShortRSAKey768.sh + test/sun/security/mscapi/ShortRSAKeyWithinTLS.java ! test/sun/security/pkcs11/KeyStore/ClientAuth.java ! test/sun/security/pkcs11/KeyStore/ClientAuth.sh ! test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java + test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java Changeset: 38bf1e9b6979 Author: weijun Date: 2012-01-13 09:50 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/38bf1e9b6979 7090565: Move test/closed/javax/security/auth/x500/X500Principal/Parse.java to open tests Reviewed-by: mullan + test/javax/security/auth/x500/X500Principal/NameFormat.java Changeset: ef3b6736c074 Author: valeriep Date: 2012-01-12 16:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ef3b6736c074 7088989: Improve the performance for T4 by utilizing the newly provided crypto APIs Summary: Added the OracleUcrypto provider for utilizing the Solaris ucrypto API. Reviewed-by: weijun ! make/com/oracle/Makefile + make/com/oracle/net/Makefile + make/com/oracle/nio/Makefile + make/com/oracle/security/ucrypto/FILES_c.gmk + make/com/oracle/security/ucrypto/Makefile + make/com/oracle/security/ucrypto/mapfile-vers + make/com/oracle/util/Makefile ! src/share/lib/security/java.security-solaris ! test/Makefile + test/com/oracle/security/ucrypto/TestAES.java + test/com/oracle/security/ucrypto/TestDigest.java + test/com/oracle/security/ucrypto/TestRSA.java + test/com/oracle/security/ucrypto/UcryptoTest.java ! test/java/security/Provider/DefaultPKCS11.java Changeset: a7ad2fcd7291 Author: valeriep Date: 2012-01-12 18:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a7ad2fcd7291 Merge Changeset: 7e593aa6ad41 Author: littlee Date: 2012-01-13 13:20 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7e593aa6ad41 7129029: (fs) Unix file system provider should be buildable on platforms that don't support O_NOFOLLOW Reviewed-by: alanb ! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/native/sun/nio/fs/genUnixConstants.c Changeset: e8e08d46cc37 Author: weijun Date: 2012-01-16 10:10 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e8e08d46cc37 7118809: rcache deadlock Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java ! src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java ! test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/ReplayCache.java Changeset: d1b0bda3a3c7 Author: alanb Date: 2012-01-16 16:30 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d1b0bda3a3c7 7130398: ProblemList.txt updates (1/2012) Reviewed-by: chegar ! test/ProblemList.txt Changeset: e8a143213c65 Author: chegar Date: 2012-01-16 18:05 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e8a143213c65 7129083: CookieManager does not store cookies if url is read before setting cookie manager Reviewed-by: michaelm ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java + test/sun/net/www/http/HttpClient/CookieHttpClientTest.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java Changeset: 40d699d7f6a1 Author: chegar Date: 2012-01-17 14:10 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/40d699d7f6a1 6671616: TEST_BUG: java/io/File/BlockIsDirectory.java fails when /dev/dsk empty (sol) Reviewed-by: alanb ! test/ProblemList.txt - test/java/io/File/BlockIsDirectory.java Changeset: 2f096eb72520 Author: mchung Date: 2012-01-17 15:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2f096eb72520 7117570: Warnings in sun.mangement.* and its subpackages Reviewed-by: mchung, dsamersoff Contributed-by: kurchi.subhra.hazra at oracle.com ! src/share/classes/sun/management/Agent.java ! src/share/classes/sun/management/ConnectorAddressLink.java ! src/share/classes/sun/management/Flag.java ! src/share/classes/sun/management/GarbageCollectionNotifInfoCompositeData.java ! src/share/classes/sun/management/GarbageCollectorImpl.java ! src/share/classes/sun/management/GcInfoBuilder.java ! src/share/classes/sun/management/GcInfoCompositeData.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/classes/sun/management/HotspotCompilation.java ! src/share/classes/sun/management/HotspotThread.java ! src/share/classes/sun/management/LazyCompositeData.java ! src/share/classes/sun/management/ManagementFactoryHelper.java ! src/share/classes/sun/management/MappedMXBeanType.java ! src/share/classes/sun/management/MonitorInfoCompositeData.java ! src/share/classes/sun/management/NotificationEmitterSupport.java ! src/share/classes/sun/management/RuntimeImpl.java ! src/share/classes/sun/management/ThreadInfoCompositeData.java ! src/share/classes/sun/management/counter/perf/PerfInstrumentation.java ! src/share/classes/sun/management/jmxremote/ConnectorBootstrap.java ! src/share/classes/sun/management/snmp/AdaptorBootstrap.java ! src/share/classes/sun/management/snmp/jvminstr/JVM_MANAGEMENT_MIB_IMPL.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemGCTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemManagerTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemMgrPoolRelTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemPoolTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmOSImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRuntimeMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadingMetaImpl.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmClassesVerboseLevel.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmJITCompilerTimeMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemManagerState.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolCollectThreshdSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolState.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolThreshdSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolType.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCCall.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCVerboseLevel.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmRTBootClassPathSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadContentionMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadCpuTimeMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIB.java ! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIBOidTable.java ! src/share/classes/sun/management/snmp/jvmmib/JvmClassLoadingMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmCompilationMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmOSMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRuntimeMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadingMeta.java ! src/share/classes/sun/management/snmp/util/MibLogger.java ! src/share/classes/sun/management/snmp/util/SnmpListTableCache.java ! src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java ! src/share/classes/sun/management/snmp/util/SnmpTableCache.java Changeset: b14e13237498 Author: lana Date: 2012-01-18 11:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b14e13237498 Merge Changeset: e6614f361127 Author: lana Date: 2012-01-18 20:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e6614f361127 Merge - test/java/io/File/BlockIsDirectory.java Changeset: 227fcf5d0bec Author: lana Date: 2012-01-24 13:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/227fcf5d0bec Merge - test/java/io/File/BlockIsDirectory.java Changeset: 954a1c535730 Author: amurillo Date: 2012-01-25 12:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/954a1c535730 Merge - test/java/io/File/BlockIsDirectory.java Changeset: d3b334e376d3 Author: mr Date: 2012-01-23 12:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d3b334e376d3 7110396: Sound code fails to build with gcc 4.6 on multiarch Linux systems Reviewed-by: ohair ! make/javax/sound/jsoundalsa/Makefile Changeset: 54202e0148ec Author: katleman Date: 2012-01-25 13:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/54202e0148ec Merge Changeset: 34029a0c69bb Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/34029a0c69bb Added tag jdk8-b23 for changeset 54202e0148ec ! .hgtags From paul.hohensee at oracle.com Thu Jan 26 21:15:21 2012 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Fri, 27 Jan 2012 05:15:21 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7082553: Interpret Thread.setPriority(Thread.MAX_PRIORITY) to mean FX60 on Solaris 10 and 11 Message-ID: <20120127051525.40A4C47219@hg.openjdk.java.net> Changeset: de268c8a8075 Author: phh Date: 2012-01-26 20:06 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/de268c8a8075 7082553: Interpret Thread.setPriority(Thread.MAX_PRIORITY) to mean FX60 on Solaris 10 and 11 Summary: Add CriticalPriority == MaxPriority+1 and enable scheduling class as well as thread priority to change on Solaris. Reviewed-by: dholmes, dcubed ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/osThread_solaris.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp From masayoshi.okutsu at oracle.com Thu Jan 26 22:50:16 2012 From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com) Date: Fri, 27 Jan 2012 06:50:16 +0000 Subject: hg: jdk8/tl/jdk: 7130335: Problem with timezone in a SimpleDateFormat Message-ID: <20120127065039.955054721C@hg.openjdk.java.net> Changeset: 7aa5ddfa3c9d Author: okutsu Date: 2012-01-27 14:58 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7aa5ddfa3c9d 7130335: Problem with timezone in a SimpleDateFormat Reviewed-by: peytoia ! src/share/classes/java/text/SimpleDateFormat.java + test/java/text/Format/DateFormat/Bug7130335.java From stefan.karlsson at oracle.com Fri Jan 27 05:12:47 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 27 Jan 2012 14:12:47 +0100 Subject: Review request (XS): 7022100: Method annotations are incorrectly set when redefining classes Message-ID: <4F22A2CF.9080708@oracle.com> Here's a fix for a simple copy-n-past bug in the handling of annotations, affecting only class redefinition. http://cr.openjdk.java.net/~stefank/7022100/webrev.00/ 7022100: Method annotations are incorrectly set when redefining classes Summary: Changed to the correct annotation arrays Reviewed-by: TBD1, TBD2 From keith.mcguigan at oracle.com Fri Jan 27 05:18:06 2012 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Fri, 27 Jan 2012 08:18:06 -0500 Subject: Review request (XS): 7022100: Method annotations are incorrectly set when redefining classes In-Reply-To: <4F22A2CF.9080708@oracle.com> References: <4F22A2CF.9080708@oracle.com> Message-ID: Looks good. On Jan 27, 2012, at 8:12 AM, Stefan Karlsson wrote: > Here's a fix for a simple copy-n-past bug in the handling of > annotations, affecting only class redefinition. > > http://cr.openjdk.java.net/~stefank/7022100/webrev.00/ > > 7022100: Method annotations are incorrectly set when redefining > classes > Summary: Changed to the correct annotation arrays > Reviewed-by: TBD1, TBD2 From david.holmes at oracle.com Fri Jan 27 05:30:18 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Jan 2012 23:30:18 +1000 Subject: Review request (XS): 7022100: Method annotations are incorrectly set when redefining classes In-Reply-To: <4F22A2CF.9080708@oracle.com> References: <4F22A2CF.9080708@oracle.com> Message-ID: <4F22A6EA.6090004@oracle.com> On 27/01/2012 11:12 PM, Stefan Karlsson wrote: > Here's a fix for a simple copy-n-past bug in the handling of > annotations, affecting only class redefinition. > > http://cr.openjdk.java.net/~stefank/7022100/webrev.00/ > > 7022100: Method annotations are incorrectly set when redefining classes > Summary: Changed to the correct annotation arrays > Reviewed-by: TBD1, TBD2 Looks perfectly logical, but begs the question as to how this has not been discovered. Are there no tests in this area? David From staffan.larsen at oracle.com Fri Jan 27 05:31:13 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 27 Jan 2012 14:31:13 +0100 Subject: Review request (XS): 7022100: Method annotations are incorrectly set when redefining classes In-Reply-To: References: <4F22A2CF.9080708@oracle.com> Message-ID: <29A78047-D031-4E19-9499-F905DD7CF401@oracle.com> Looks good. On 27 jan 2012, at 14:18, Keith McGuigan wrote: > > Looks good. > > On Jan 27, 2012, at 8:12 AM, Stefan Karlsson wrote: > >> Here's a fix for a simple copy-n-past bug in the handling of annotations, affecting only class redefinition. >> >> http://cr.openjdk.java.net/~stefank/7022100/webrev.00/ >> >> 7022100: Method annotations are incorrectly set when redefining classes >> Summary: Changed to the correct annotation arrays >> Reviewed-by: TBD1, TBD2 > From kelly.ohair at oracle.com Fri Jan 27 12:40:49 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 27 Jan 2012 12:40:49 -0800 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com> <4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com> Message-ID: On Jan 26, 2012, at 2:47 PM, Georges Saab wrote: >> As long as we target both 7u and 8 we will be using two different toolsets. But I agree that JPRT and RE should be using the same tools. That needs to be taken up with RE and Kelly. > > Ideally not just using the same tools, but they should _be_ the same systems. But I digress... I have tried very hard to have JPRT match RE, this 6u14 vs. 6u18 difference was a mistake we will correct. However, it is literally impossible to keep any two systems identical all the time, and many products used by RE (like PocketSoft RTPATCH) are simply not available to all JPRT systems. So this is always a best match situation. I do what I can to match RE because that's a primary goal of JPRT to insure that RE builds will be successful. We also have little control on when PDIT/GIT system maintenance could change the system by installing patches or updates on systems. So there is always some randomness to the systems. -kto -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120127/b0d13cef/attachment.html From john.coomes at oracle.com Fri Jan 27 12:50:36 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 27 Jan 2012 20:50:36 +0000 Subject: hg: hsx/hotspot-rt/langtools: 8 new changesets Message-ID: <20120127205055.45F914723D@hg.openjdk.java.net> Changeset: 70d92518063e Author: mcimadamore Date: 2012-01-11 18:23 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/70d92518063e 7126754: Generics compilation failure casting List to List Summary: Problems with Types.rewriteQuantifiers not preserving variance Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/cast/7126754/T7126754.java + test/tools/javac/cast/7126754/T7126754.out Changeset: 133744729455 Author: mcimadamore Date: 2012-01-12 15:28 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/133744729455 7123100: javac fails with java.lang.StackOverflowError Summary: Inference of under-constrained type-variables creates erroneous recursive wildcard types Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/cast/7123100/T7123100a.java + test/tools/javac/cast/7123100/T7123100a.out + test/tools/javac/cast/7123100/T7123100b.java + test/tools/javac/cast/7123100/T7123100b.out + test/tools/javac/cast/7123100/T7123100c.java + test/tools/javac/cast/7123100/T7123100c.out + test/tools/javac/cast/7123100/T7123100d.java + test/tools/javac/cast/7123100/T7123100d.out Changeset: 1e2f4f4fb9f7 Author: jjh Date: 2012-01-17 17:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/1e2f4f4fb9f7 7127924: langtools regression tests sometimes fail en-masse on windows Reviewed-by: jjg ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/RunExamples.java Changeset: f00afa80f1f0 Author: lana Date: 2012-01-18 11:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/f00afa80f1f0 Merge Changeset: cf2496340fef Author: darcy Date: 2012-01-18 16:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/cf2496340fef 7130768: Clarify behavior of Element.getEnclosingElements in subtypes Reviewed-by: mcimadamore, jjg ! src/share/classes/javax/lang/model/element/Element.java ! src/share/classes/javax/lang/model/element/PackageElement.java ! src/share/classes/javax/lang/model/element/TypeElement.java Changeset: 99261fc7d95d Author: jjh Date: 2012-01-18 18:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/99261fc7d95d 7131308: Three regression tests fail due to bad fix for 7127924 Reviewed-by: jjg ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/RunExamples.java Changeset: 601ffcc6551d Author: lana Date: 2012-01-24 13:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/601ffcc6551d Merge Changeset: 6c9d21ca92c4 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/6c9d21ca92c4 Added tag jdk8-b23 for changeset 601ffcc6551d ! .hgtags From stefan.karlsson at oracle.com Fri Jan 27 15:21:00 2012 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Fri, 27 Jan 2012 23:21:00 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7130476: Remove use of #ifdef TRACE_DEFINE_KLASS_TRACE_ID from klass.hpp Message-ID: <20120127232104.EF5FA47240@hg.openjdk.java.net> Changeset: 34e2e90e7182 Author: rbackman Date: 2012-01-24 14:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/34e2e90e7182 7130476: Remove use of #ifdef TRACE_DEFINE_KLASS_TRACE_ID from klass.hpp Reviewed-by: kamg, phh, dsamersoff Contributed-by: Rickard Backman ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/trace/traceMacros.hpp From valerie.peng at oracle.com Fri Jan 27 15:26:40 2012 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Fri, 27 Jan 2012 23:26:40 +0000 Subject: hg: jdk8/tl/jdk: 7136538: typo in test/Makefile under the jdk_security3 target Message-ID: <20120127232657.9BF1547241@hg.openjdk.java.net> Changeset: ff24779c147f Author: valeriep Date: 2012-01-27 15:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff24779c147f 7136538: typo in test/Makefile under the jdk_security3 target Summary: Fixed the typo of "secrity". Reviewed-by: wetmore ! test/Makefile From georges.saab at oracle.com Thu Jan 26 14:47:24 2012 From: georges.saab at oracle.com (Georges Saab) Date: Thu, 26 Jan 2012 14:47:24 -0800 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <4F21CBF2.1040407@oracle.com> References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com> <4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com> Message-ID: On 26 jan 2012, at 13:56, David Holmes wrote: > On 26/01/2012 10:02 PM, Rickard B?ckman wrote: >> On 01/26/2012 12:50 PM, David Holmes wrote: >>> Change looks fine, but then so did the original! Will this be handled >>> correctly by all versions of the jar command? >> >> We, have checked the contents of the version that RE is using (1.6.0_1 >> or something like that) and the one JPRT is using (1.6.0_18) and locally >> on my machine (1.7.0) I don't think I'll be able to verify _all_ >> versions of jar. It seems the "faulty" behavior of "jar" was fixed in >> 1.6.0_18 which is the first version I could find that didn't cause the >> error on the previous code. I would rather hope that we could try to use >> one and the same version across all kind of builds of the same jdk >> version. It would help to catch this kind of errors earlier... > > Sorry I meant "all versions of jar that we might build with" :) > > I think the normal RE process is to build JDK N with the FCS version of JDK N-1, which would explain why the old JDK 6 jar is being used. JPRT has changes to the bootjdks made "on demand". > > As long as we target both 7u and 8 we will be using two different toolsets. But I agree that JPRT and RE should be using the same tools. That needs to be taken up with RE and Kelly. Ideally not just using the same tools, but they should _be_ the same systems. But I digress... > > Thanks, > David > >> Thanks >> /R >> >>> >>>> Thanks >>>> /Rickard >> From georges.saab at oracle.com Fri Jan 27 21:52:57 2012 From: georges.saab at oracle.com (Georges Saab) Date: Fri, 27 Jan 2012 21:52:57 -0800 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com> <4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com> Message-ID: <4E51D843-A417-422C-9207-DF130D605DCC@oracle.com> On 27 jan 2012, at 12:40, Kelly O'Hair wrote: > > On Jan 26, 2012, at 2:47 PM, Georges Saab wrote: > >>> As long as we target both 7u and 8 we will be using two different toolsets. But I agree that JPRT and RE should be using the same tools. That needs to be taken up with RE and Kelly. >> >> Ideally not just using the same tools, but they should _be_ the same systems. But I digress... > > > I have tried very hard to have JPRT match RE, this 6u14 vs. 6u18 difference was a mistake we will correct. > > However, it is literally impossible to keep any two systems identical all the time, Exactly. If the same system is used for checkin-test builds and production builds then you no longer have two systems that need to be 'kept in sync'. > and many products used by RE > (like PocketSoft RTPATCH) are simply not available to all JPRT systems. > So this is always a best match situation. I do what I can to match RE because that's a primary goal of JPRT to insure > that RE builds will be successful. > > We also have little control on when PDIT/GIT system maintenance could change the system > by installing patches or updates on systems. So there is always some randomness to the systems. > > -kto > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120127/e8ded2cd/attachment.html From kelly.ohair at oracle.com Sat Jan 28 09:46:35 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Sat, 28 Jan 2012 09:46:35 -0800 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <4E51D843-A417-422C-9207-DF130D605DCC@oracle.com> References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com> <4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com> <4E51D843-A417-422C-9207-DF130D605DCC@oracle.com> Message-ID: <7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com> On Jan 27, 2012, at 9:52 PM, Georges Saab wrote: > > On 27 jan 2012, at 12:40, Kelly O'Hair wrote: > >> >> On Jan 26, 2012, at 2:47 PM, Georges Saab wrote: >> >>>> As long as we target both 7u and 8 we will be using two different toolsets. But I agree that JPRT and RE should be using the same tools. That needs to be taken up with RE and Kelly. >>> >>> Ideally not just using the same tools, but they should _be_ the same systems. But I digress... >> >> >> I have tried very hard to have JPRT match RE, this 6u14 vs. 6u18 difference was a mistake we will correct. >> >> However, it is literally impossible to keep any two systems identical all the time, > > Exactly. If the same system is used for checkin-test builds and production builds then you no > longer have two systems that need to be 'kept in sync'. I'm missing something. How can everybody using the exact same system scale to 100's of developers? And that one system will naturally change over time too, so unless you are able to prevent all change to a system (impossible with security updates etc) every use of that 'same system' will be different. -kto > > >> and many products used by RE >> (like PocketSoft RTPATCH) are simply not available to all JPRT systems. >> So this is always a best match situation. I do what I can to match RE because that's a primary goal of JPRT to insure >> that RE builds will be successful. >> >> We also have little control on when PDIT/GIT system maintenance could change the system >> by installing patches or updates on systems. So there is always some randomness to the systems. >> >> -kto >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120128/04598258/attachment-0001.html From kumar.x.srinivasan at oracle.com Sat Jan 28 10:48:05 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sat, 28 Jan 2012 18:48:05 +0000 Subject: hg: jdk8/tl/jdk: 7127906: (launcher) convert the launcher regression tests to java Message-ID: <20120128184824.5522D4724E@hg.openjdk.java.net> Changeset: 7dbc129d8e5c Author: ksrini Date: 2012-01-28 10:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7dbc129d8e5c 7127906: (launcher) convert the launcher regression tests to java Reviewed-by: darcy, naoto ! test/tools/launcher/Arrrghs.java + test/tools/launcher/ChangeDataModel.java - test/tools/launcher/ChangeDataModel.sh - test/tools/launcher/CreatePlatformFile.java ! test/tools/launcher/DefaultLocaleTestRun.java ! test/tools/launcher/ExecutionEnvironment.java ! test/tools/launcher/I18NJarTest.java + test/tools/launcher/I18NTest.java ! test/tools/launcher/MiscTests.java ! test/tools/launcher/Settings.java - test/tools/launcher/SomeException.java ! test/tools/launcher/Test7029048.java ! test/tools/launcher/TestHelper.java - test/tools/launcher/UnicodeCleanup.java ! test/tools/launcher/UnicodeTest.java - test/tools/launcher/UnicodeTest.sh ! test/tools/launcher/UnresolvedExceptions.java - test/tools/launcher/deleteI18n.sh - test/tools/launcher/i18nTest.sh - test/tools/launcher/unresolvedExceptions.sh From lana.steuck at oracle.com Sat Jan 28 21:58:30 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 29 Jan 2012 05:58:30 +0000 Subject: hg: jdk8/tl: 3 new changesets Message-ID: <20120129055830.D7EDA47257@hg.openjdk.java.net> Changeset: 60d6f64a86b1 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/60d6f64a86b1 Added tag jdk8-b22 for changeset 7ad075c80995 ! .hgtags Changeset: 1a5f1d6b98d6 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1a5f1d6b98d6 Added tag jdk8-b23 for changeset 60d6f64a86b1 ! .hgtags Changeset: bd3fcc98c5d2 Author: lana Date: 2012-01-28 20:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/bd3fcc98c5d2 Merge From lana.steuck at oracle.com Sat Jan 28 21:58:30 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 29 Jan 2012 05:58:30 +0000 Subject: hg: jdk8/tl/jaxp: 2 new changesets Message-ID: <20120129055830.D4B4347256@hg.openjdk.java.net> Changeset: 95102fd33418 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/95102fd33418 Added tag jdk8-b22 for changeset cf9d6ec44f89 ! .hgtags Changeset: 7836655e2495 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/7836655e2495 Added tag jdk8-b23 for changeset 95102fd33418 ! .hgtags From lana.steuck at oracle.com Sat Jan 28 21:58:30 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 29 Jan 2012 05:58:30 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20120129055830.D1F4847255@hg.openjdk.java.net> Changeset: 25ce7a000487 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/25ce7a000487 Added tag jdk8-b22 for changeset 8d3df89b0f2d ! .hgtags Changeset: e0d90803439b Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/e0d90803439b Added tag jdk8-b23 for changeset 25ce7a000487 ! .hgtags From lana.steuck at oracle.com Sat Jan 28 21:58:30 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 29 Jan 2012 05:58:30 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20120129055832.93E6047258@hg.openjdk.java.net> Changeset: 5218eb256658 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/5218eb256658 Added tag jdk8-b22 for changeset a11d0062c445 ! .hgtags Changeset: b98f0e6dddf9 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/b98f0e6dddf9 Added tag jdk8-b23 for changeset 5218eb256658 ! .hgtags From lana.steuck at oracle.com Sat Jan 28 21:58:30 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 29 Jan 2012 05:58:30 +0000 Subject: hg: jdk8/tl/langtools: 4 new changesets Message-ID: <20120129055841.74AD347259@hg.openjdk.java.net> Changeset: f6191bad139a Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f6191bad139a Added tag jdk8-b22 for changeset 390a7828ae18 ! .hgtags Changeset: 601ffcc6551d Author: lana Date: 2012-01-24 13:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/601ffcc6551d Merge Changeset: 6c9d21ca92c4 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6c9d21ca92c4 Added tag jdk8-b23 for changeset 601ffcc6551d ! .hgtags Changeset: 7d412606d641 Author: lana Date: 2012-01-28 20:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7d412606d641 Merge From lana.steuck at oracle.com Sat Jan 28 21:58:48 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 29 Jan 2012 05:58:48 +0000 Subject: hg: jdk8/tl/hotspot: 88 new changesets Message-ID: <20120129060149.DB6E24725A@hg.openjdk.java.net> Changeset: 0841c0ec2ed6 Author: amurillo Date: 2011-12-23 15:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0841c0ec2ed6 7123810: new hotspot build - hs23-b10 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3b2b58fb1425 Author: tonyp Date: 2011-12-20 12:59 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3b2b58fb1425 7123165: G1: output during parallel verification can get messed up Summary: Serialize the worker threads that are generating output during parallel heap verification to make sure the output is consistent. Reviewed-by: brutisso, johnc, jmasa ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: d15b458c4225 Author: jmasa Date: 2011-12-20 20:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d15b458c4225 Merge Changeset: 67fdcb391461 Author: tonyp Date: 2011-12-21 07:53 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/67fdcb391461 7119027: G1: use atomics to update RS length / predict time of inc CSet Summary: Make sure that the updates to the RS length and inc CSet predicted time are updated in an MT-safe way. Reviewed-by: brutisso, iveresov ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: 441e946dc1af Author: jmasa Date: 2011-12-14 13:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/441e946dc1af 7121618: Change type of number of GC workers to unsigned int. Summary: Change variables representing the number of GC workers to uint from int and size_t. Change the parameter in work(int i) to work(uint worker_id). Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 1cbe7978b021 Author: brutisso Date: 2011-12-21 22:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1cbe7978b021 7113021: G1: automatically enable young gen size auto-tuning when -Xms==-Xmx Summary: Use a percentage of -Xms as min and another percentage of -Xmx as max for the young gen size Reviewed-by: tonyp, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 7faca6dfa2ed Author: jmasa Date: 2011-12-27 12:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7faca6dfa2ed Merge ! src/share/vm/runtime/globals.hpp Changeset: 4ceaf61479fc Author: dcubed Date: 2011-12-22 12:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4ceaf61479fc 7122253: Instrumentation.retransformClasses() leaks class bytes Summary: Change ClassFileParser::parseClassFile() to use the instanceKlass:_cached_class_file_bytes field to avoid leaking the cache. Reviewed-by: coleenp, acorn, poonam ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 4ec93d767458 Author: vladidan Date: 2011-12-26 20:36 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4ec93d767458 Merge Changeset: 3db6ea5ce021 Author: vladidan Date: 2011-12-29 20:09 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3db6ea5ce021 Merge Changeset: 20bfb6d15a94 Author: iveresov Date: 2011-12-27 16:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/20bfb6d15a94 7124829: NUMA: memory leak on Linux with large pages Summary: In os::free_memory() use mmap with the same attributes as for the heap space Reviewed-by: kvn Contributed-by: Aleksey Ignatenko ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/runtime/os.hpp Changeset: 776173fc2df9 Author: stefank Date: 2011-12-29 07:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/776173fc2df9 7125516: G1: ~ConcurrentMark() frees incorrectly Summary: Replaced the code with a ShouldNotReachHere Reviewed-by: tonyp, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 5ee33ff9b1c4 Author: jmasa Date: 2012-01-03 10:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5ee33ff9b1c4 Merge Changeset: 75c0a73eee98 Author: coleenp Date: 2011-11-17 12:53 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/75c0a73eee98 7102776: Pack instanceKlass boolean fields into single u1 field Summary: Reduce class runtime memory usage by packing 4 instanceKlass boolean fields into single u1 field. Save 4-byte for each loaded class. Reviewed-by: dholmes, bobv, phh, twisti, never, coleenp Contributed-by: Jiangli Zhou ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: da4dd142ea01 Author: bobv Date: 2011-11-29 14:44 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/da4dd142ea01 Merge ! src/share/vm/code/dependencies.cpp Changeset: 52b5d32fbfaf Author: coleenp Date: 2011-12-06 18:28 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/52b5d32fbfaf 7117052: instanceKlass::_init_state can be u1 type Summary: Change instanceKlass::_init_state field to u1 type. Reviewed-by: bdelsart, coleenp, dholmes, phh, never Contributed-by: Jiangli Zhou ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: eccc4b1f8945 Author: vladidan Date: 2011-12-07 16:47 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eccc4b1f8945 7050298: ARM: SIGSEGV in JNIHandleBlock::allocate_handle Summary: missing release barrier in Monitor::IUnlock Reviewed-by: dholmes, dice ! src/share/vm/runtime/mutex.cpp Changeset: 2685ea97b89f Author: jiangli Date: 2011-12-09 11:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2685ea97b89f Merge ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp Changeset: 8fdf463085e1 Author: jiangli Date: 2011-12-16 17:33 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8fdf463085e1 Merge Changeset: dca455dea3a7 Author: bdelsart Date: 2011-12-20 12:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dca455dea3a7 7116216: StackOverflow GC crash Summary: GC crash for explicit stack overflow checks after a C2I transition. Reviewed-by: coleenp, never Contributed-by: yang02.wang at sap.com, bertrand.delsart at oracle.com ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp + test/compiler/7116216/LargeFrame.java + test/compiler/7116216/StackOverflow.java Changeset: cd5d8cafcc84 Author: jiangli Date: 2011-12-28 12:15 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cd5d8cafcc84 7123315: instanceKlass::_static_oop_field_count and instanceKlass::_java_fields_count should be u2 type. Summary: Change instanceKlass::_static_oop_field_count and instanceKlass::_java_fields_count to u2 type. Reviewed-by: never, bdelsart, dholmes Contributed-by: Jiangli Zhou ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 05de27e852c4 Author: jiangli Date: 2012-01-04 12:36 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/05de27e852c4 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: b6a04c79ccbc Author: stefank Date: 2012-01-02 10:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b6a04c79ccbc 7125503: Compiling collectedHeap.cpp fails with -Werror=int-to-pointer-cast with g++ 4.6.1 Summary: Used uintptr_t and void* for all the casts and checks in test_is_in. Reviewed-by: tonyp, jmasa ! src/share/vm/gc_interface/collectedHeap.cpp Changeset: 4753e3dda3c8 Author: jmasa Date: 2012-01-04 07:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4753e3dda3c8 Merge Changeset: 2ee4167627a3 Author: jmasa Date: 2012-01-05 21:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2ee4167627a3 Merge Changeset: 7ab5f6318694 Author: phh Date: 2012-01-01 11:17 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7ab5f6318694 7125934: Add a fast unordered timestamp capability to Hotspot on x86/x64 Summary: Add rdtsc detection and inline generation. Reviewed-by: kamg, dholmes Contributed-by: karen.kinnear at oracle.com ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/os_bsd_x86.inline.hpp ! src/os_cpu/linux_x86/vm/os_linux_x86.hpp + src/os_cpu/linux_x86/vm/os_linux_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.hpp + src/os_cpu/solaris_x86/vm/os_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/os_cpu/solaris_x86/vm/solaris_x86_64.il ! src/os_cpu/windows_x86/vm/os_windows_x86.hpp + src/os_cpu/windows_x86/vm/os_windows_x86.inline.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp + src/share/vm/runtime/os_ext.hpp Changeset: b16494a69d3d Author: phh Date: 2012-01-03 15:11 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b16494a69d3d 7126185: Clean up lasterror handling, add os::get_last_error() Summary: Add os::get_last_error(), replace getLastErrorString() by os::lasterror() in os_windows.cpp. Reviewed-by: kamg, dholmes Contributed-by: erik.gahlin at oracle.com ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp Changeset: 5b58979183f9 Author: dcubed Date: 2012-01-05 06:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5b58979183f9 7127032: fix for 7122253 adds a JvmtiThreadState earlier than necessary Summary: Use JavaThread::jvmti_thread_state() instead of JvmtiThreadState::state_for(). Reviewed-by: coleenp, poonam, acorn ! src/share/vm/classfile/classFileParser.cpp Changeset: 8a63c6323842 Author: fparain Date: 2012-01-05 07:26 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8a63c6323842 7125594: C-heap growth issue in ThreadService::find_deadlocks_at_safepoint Reviewed-by: sspitsyn, dcubed, mchung, dholmes ! src/share/vm/services/threadService.cpp Changeset: 2e0ef19fc891 Author: phh Date: 2012-01-05 17:14 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2e0ef19fc891 7126480: Make JVM start time in milliseconds since the Java epoch available Summary: Expose existing Management::_begin_vm_creation_time via new accessor Management::begin_vm_creation_time(). Reviewed-by: acorn, dcubed ! src/share/vm/services/management.hpp Changeset: 66259eca2bf7 Author: phh Date: 2012-01-05 17:16 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/66259eca2bf7 Merge Changeset: 2b3acb34791f Author: dcubed Date: 2012-01-06 16:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2b3acb34791f Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/runtime/os.hpp Changeset: abcceac2f7cd Author: iveresov Date: 2011-12-12 12:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/abcceac2f7cd 7119730: Tiered: SIGSEGV in AdvancedThresholdPolicy::is_method_profiled(methodOop) Summary: Added handles for references to methods in select_task() Reviewed-by: twisti, kvn ! src/share/vm/runtime/advancedThresholdPolicy.cpp Changeset: 7bca37d28f32 Author: roland Date: 2011-12-13 10:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7bca37d28f32 7114106: C1: assert(goto_state->is_same(sux_state)) failed: states must match now Summary: fix C1's CEE to take inlining into account when the stacks in states are compared. Reviewed-by: iveresov, never ! src/share/vm/c1/c1_Optimizer.cpp Changeset: d725f0affb1a Author: iveresov Date: 2011-12-13 17:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d725f0affb1a 7121111: -server -Xcomp -XX:+TieredCompilation does not invoke C2 compiler Summary: Exercise C2 more in tiered mode with Xcomp Reviewed-by: kvn, never ! src/share/vm/runtime/arguments.cpp Changeset: 127b3692c168 Author: kvn Date: 2011-12-14 14:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/127b3692c168 7116452: Add support for AVX instructions Summary: Added support for AVX extension to the x86 instruction set. Reviewed-by: never ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/assembler_x86.inline.hpp ! src/cpu/x86/vm/nativeInst_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.hpp ! src/cpu/x86/vm/register_definitions_x86.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/runtime/globals.hpp Changeset: 669f6a7d5b70 Author: never Date: 2011-12-19 14:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/669f6a7d5b70 7121073: secondary_super_cache memory slice has incorrect bounds in flatten_alias_type Reviewed-by: kvn ! src/share/vm/opto/compile.cpp Changeset: 65149e74c706 Author: kvn Date: 2011-12-20 00:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/65149e74c706 7121648: Use 3-operands SIMD instructions on x86 with AVX Summary: Use 3-operands SIMD instructions in C2 generated code for machines with AVX. Reviewed-by: never ! make/bsd/makefiles/adlc.make ! make/linux/makefiles/adlc.make ! make/solaris/makefiles/adlc.make ! make/windows/makefiles/adlc.make ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp + src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/matcher.cpp Changeset: 069ab3f976d3 Author: stefank Date: 2011-12-07 11:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/069ab3f976d3 7118863: Move sizeof(klassOopDesc) into the *Klass::*_offset_in_bytes() functions Summary: Moved sizeof(klassOopDesc), changed the return type to ByteSize and removed the _in_bytes suffix. Reviewed-by: never, bdelsart, coleenp, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassOop.hpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/shark/sharkIntrinsics.cpp ! src/share/vm/shark/sharkTopLevelBlock.cpp Changeset: 1dc233a8c7fe Author: roland Date: 2011-12-20 16:56 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1dc233a8c7fe 7121140: Allocation paths require explicit memory synchronization operations for RMO systems Summary: adds store store barrier after initialization of header and body of objects. Reviewed-by: never, kvn ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.hpp Changeset: e5ac210043cd Author: roland Date: 2011-12-22 10:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e5ac210043cd 7123108: C1: assert(if_state != NULL) failed: states do not match up Summary: In CEE, ensure if and common successor state are at the same inline level Reviewed-by: never ! src/share/vm/c1/c1_Optimizer.cpp + test/compiler/7123108/Test7123108.java Changeset: b642b49f9738 Author: roland Date: 2011-12-23 09:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b642b49f9738 7123253: C1: in store check code, usage of registers may be incorrect Summary: fix usage of input register in assembly code for store check. Reviewed-by: never ! src/share/vm/c1/c1_LIR.cpp Changeset: 40c2484c09e1 Author: kvn Date: 2011-12-23 15:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/40c2484c09e1 7110832: ctw/.../org_apache_avalon_composition_util_StringHelper crashes the VM Summary: Distance is too large for one short branch in string_indexofC8(). Reviewed-by: iveresov ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp Changeset: d12a66fa3820 Author: kvn Date: 2011-12-27 15:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d12a66fa3820 7123954: Some CTW test crash with SIGSEGV Summary: Correct Allocate expansion code to preserve i_o when only slow call is generated. Reviewed-by: iveresov ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/macro.cpp Changeset: 8940fd98d540 Author: kvn Date: 2011-12-29 11:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8940fd98d540 Merge ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/runtime/globals.hpp Changeset: 9c87bcb3b4dd Author: kvn Date: 2011-12-30 11:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9c87bcb3b4dd 7125879: assert(proj != NULL) failed: must be found Summary: Leave i_o attached to slow allocation call when there are no i_o users after the call. Reviewed-by: iveresov, twisti ! src/share/vm/opto/macro.cpp + test/compiler/7125879/Test7125879.java Changeset: 1cb50d7a9d95 Author: iveresov Date: 2012-01-05 17:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1cb50d7a9d95 7119294: Two command line options cause JVM to crash Summary: Setup thread register in MacroAssembler::incr_allocated_bytes() on x64 Reviewed-by: kvn ! src/cpu/x86/vm/assembler_x86.cpp Changeset: 22cee0ee8927 Author: kvn Date: 2012-01-06 20:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/22cee0ee8927 Merge ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parseHelper.cpp Changeset: 8f8b94305aff Author: dcubed Date: 2012-01-11 19:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8f8b94305aff 7129240: backout fix for 7102776 until 7128770 is resolved Reviewed-by: phh, bobv, coleenp, dcubed Contributed-by: Jiangli Zhou ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 4f25538b54c9 Author: fparain Date: 2012-01-09 10:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4f25538b54c9 7120511: Add diagnostic commands Reviewed-by: acorn, phh, dcubed, sspitsyn ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/services/diagnosticFramework.cpp ! src/share/vm/services/diagnosticFramework.hpp ! src/share/vm/services/management.cpp Changeset: 865e0817f32b Author: kamg Date: 2012-01-10 15:47 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/865e0817f32b Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: efdf6985a3a2 Author: kamg Date: 2012-01-12 09:59 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/efdf6985a3a2 Merge Changeset: 5da7201222d5 Author: kvn Date: 2012-01-07 10:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5da7201222d5 7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM Summary: Change yank_if_dead() to recursive method to remove all dead inputs. Reviewed-by: never ! src/cpu/sparc/vm/sparc.ad ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/postaloc.cpp Changeset: e9a5e0a812c8 Author: kvn Date: 2012-01-07 13:26 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e9a5e0a812c8 7125896: Eliminate nested locks Summary: Nested locks elimination done before lock nodes expansion by looking for outer locks of the same object. Reviewed-by: never, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/ci/ciTypeFlow.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp Changeset: 35acf8f0a2e4 Author: kvn Date: 2012-01-10 18:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/35acf8f0a2e4 7128352: assert(obj_node == obj) failed Summary: Compare uncasted object nodes. Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/subnode.cpp ! test/compiler/7116216/StackOverflow.java Changeset: c8d8e124380c Author: kvn Date: 2012-01-12 12:28 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c8d8e124380c 7064302: JDK7 build 147 crashed after testing my java 6-compiled web app Summary: Don't split CMove node if it's control edge is different from split region. Reviewed-by: never ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp Changeset: 31a5b9aad4bc Author: jrose Date: 2012-01-13 00:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/31a5b9aad4bc Merge ! src/share/vm/runtime/arguments.cpp Changeset: bacb651cf5bf Author: tonyp Date: 2012-01-05 05:54 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bacb651cf5bf 7113006: G1: excessive ergo output when an evac failure happens Summary: Introduce a flag that is set when a heap expansion attempt during a GC fails so that we do not consantly attempt to expand the heap when it's going to fail anyway. This not only prevents the excessive ergo output (which is generated when a region allocation fails) but also avoids excessive and ultimately unsuccessful expansion attempts. Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 5fd354a959c5 Author: jmasa Date: 2012-01-05 21:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5fd354a959c5 Merge Changeset: 023652e49ac0 Author: johnc Date: 2011-12-23 11:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/023652e49ac0 7121496: G1: do the per-region evacuation failure handling work in parallel Summary: Parallelize the removal of self forwarding pointers etc. by wrapping in a HeapRegion closure, which is then wrapped inside an AbstractGangTask. Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp + src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 02838862dec8 Author: tonyp Date: 2012-01-07 00:43 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/02838862dec8 7121623: G1: always be able to reliably calculate the length of a forwarded chunked array Summary: Store the "next chunk start index" in the length field of the to-space object, instead of the from-space object, so that we can always reliably read the size of all from-space objects. Reviewed-by: johnc, ysr, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 97c00e21fecb Author: tonyp Date: 2012-01-09 23:50 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/97c00e21fecb 7125281: G1: heap expansion code is replicated Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 1d6185f732aa Author: brutisso Date: 2012-01-10 20:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1d6185f732aa 7128532: G1: Change default value of G1DefaultMaxNewGenPercent to 80 Reviewed-by: tonyp, jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 2ace1c4ee8da Author: tonyp Date: 2012-01-10 18:58 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2ace1c4ee8da 6888336: G1: avoid explicitly marking and pushing objects in survivor spaces Summary: This change simplifies the interaction between GC and concurrent marking. By disabling survivor spaces during the initial-mark pause we don't need to propagate marks of objects we copy during each GC (since we never need to copy an explicitly marked object). Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegion.inline.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp Changeset: 9d4f4a1825e4 Author: brutisso Date: 2012-01-13 01:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9d4f4a1825e4 Merge Changeset: 5acd82522540 Author: brutisso Date: 2012-01-13 06:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5acd82522540 Merge Changeset: b0ff910edfc9 Author: kvn Date: 2012-01-12 14:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b0ff910edfc9 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed Summary: Do not common BoxLock nodes and avoid creating phis of boxes. Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/parse1.cpp Changeset: f4d8930a45b9 Author: jrose Date: 2012-01-13 00:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f4d8930a45b9 Merge Changeset: 89d0a5d40008 Author: kvn Date: 2012-01-13 12:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/89d0a5d40008 7129618: assert(obj_node->eqv_uncast(obj),""); Summary: Relax verification and locks elimination checks for new implementation (EliminateNestedLocks). Reviewed-by: iveresov ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/macro.cpp Changeset: e504fd26c073 Author: kvn Date: 2012-01-13 14:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e504fd26c073 Merge Changeset: 513351373923 Author: amurillo Date: 2012-01-14 00:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/513351373923 Merge Changeset: 24727fb37561 Author: amurillo Date: 2012-01-14 00:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/24727fb37561 Added tag hs23-b10 for changeset 513351373923 ! .hgtags Changeset: 338d438ee229 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/338d438ee229 Added tag jdk8-b22 for changeset 24727fb37561 ! .hgtags Changeset: 4e80db53c323 Author: amurillo Date: 2012-01-14 00:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4e80db53c323 7129512: new hotspot build - hs23-b11 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 94ec88ca68e2 Author: phh Date: 2012-01-11 17:34 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/94ec88ca68e2 7115199: Add event tracing hooks and Java Flight Recorder infrastructure Summary: Added a nop tracing infrastructure, JFR makefile changes and other infrastructure used only by JFR. Reviewed-by: acorn, sspitsyn Contributed-by: markus.gronlund at oracle.com ! make/Makefile ! make/bsd/makefiles/vm.make ! make/defs.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! make/windows/build.bat ! make/windows/create_obj_files.sh ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jni.cpp + src/share/vm/prims/jniExport.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vm_operations.hpp + src/share/vm/trace/traceEventTypes.hpp + src/share/vm/trace/traceMacros.hpp + src/share/vm/trace/tracing.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 4f3ce9284781 Author: phh Date: 2012-01-11 17:58 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4f3ce9284781 Merge ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp Changeset: f1cd52d6ce02 Author: kamg Date: 2012-01-17 10:16 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f1cd52d6ce02 Merge Changeset: d7e3846464d0 Author: zgu Date: 2012-01-17 13:08 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d7e3846464d0 7071311: Decoder enhancement Summary: Made decoder thread-safe Reviewed-by: coleenp, kamg - src/os/bsd/vm/decoder_bsd.cpp + src/os/bsd/vm/decoder_machO.cpp + src/os/bsd/vm/decoder_machO.hpp ! src/os/linux/vm/decoder_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/decoder_solaris.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/decoder_windows.cpp + src/os/windows/vm/decoder_windows.hpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp + src/share/vm/utilities/decoder_elf.cpp + src/share/vm/utilities/decoder_elf.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp ! src/share/vm/utilities/elfStringTable.cpp ! src/share/vm/utilities/elfStringTable.hpp ! src/share/vm/utilities/elfSymbolTable.cpp ! src/share/vm/utilities/elfSymbolTable.hpp ! src/share/vm/utilities/vmError.cpp Changeset: 6520f9861937 Author: kamg Date: 2012-01-17 21:25 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6520f9861937 Merge Changeset: db18ca98d237 Author: zgu Date: 2012-01-18 11:45 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/db18ca98d237 7131050: fix for "7071311 Decoder enhancement" does not build on MacOS X Summary: Decoder API changes did not reflect in os_bsd Reviewed-by: kamg, dcubed ! src/os/bsd/vm/os_bsd.cpp Changeset: eaa9557116a2 Author: bdelsart Date: 2012-01-18 16:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eaa9557116a2 7120448: Fix FP values for compiled frames in frame::describe Summary: fix for debug method frame::describe Reviewed-by: never, kvn ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.hpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp Changeset: 15d394228cfa Author: jrose Date: 2012-01-19 13:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/15d394228cfa 7111138: delete the obsolete flag -XX:+UseRicochetFrames Reviewed-by: dholmes, bdelsart, kvn, twisti ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/zero/vm/methodHandles_zero.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 898522ae3c32 Author: iveresov Date: 2012-01-19 10:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/898522ae3c32 7131288: COMPILE SKIPPED: deopt handler overflow (retry at different tier) Summary: Fix exception handler stub size, enable guarantees to check for the correct deopt and exception stub sizes in the future Reviewed-by: kvn, never, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 469e0a46f2fe Author: jrose Date: 2012-01-19 17:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/469e0a46f2fe Merge Changeset: 50d9b7a0072c Author: jrose Date: 2012-01-19 18:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/50d9b7a0072c Merge Changeset: dcc292399a39 Author: amurillo Date: 2012-01-20 16:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dcc292399a39 Merge - src/os/bsd/vm/decoder_bsd.cpp Changeset: e850d8e7ea54 Author: amurillo Date: 2012-01-20 16:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e850d8e7ea54 Added tag hs23-b11 for changeset dcc292399a39 ! .hgtags Changeset: 6edfe6e42a68 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6edfe6e42a68 Added tag jdk8-b23 for changeset e850d8e7ea54 ! .hgtags From lana.steuck at oracle.com Sat Jan 28 21:59:07 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 29 Jan 2012 05:59:07 +0000 Subject: hg: jdk8/tl/jdk: 23 new changesets Message-ID: <20120129060256.0A9F54725B@hg.openjdk.java.net> Changeset: 76bfd08d8cc5 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76bfd08d8cc5 Added tag jdk8-b22 for changeset dda27c73d8db ! .hgtags Changeset: 44bd765c22f4 Author: prr Date: 2012-01-13 13:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44bd765c22f4 7127827: JRE8: javaws fails to launch on oracle linux due to XRender Reviewed-by: bae, jgodinez ! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java Changeset: b566004bcb1a Author: dbuck Date: 2012-01-16 11:52 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b566004bcb1a 7083621: Add fontconfig file for OEL6 and rename RH/O EL 5 file so that it is picked up for all 5.x updates Reviewed-by: bae, prr ! make/sun/awt/Makefile Changeset: 397667460892 Author: lana Date: 2012-01-18 11:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/397667460892 Merge - test/tools/launcher/DefaultLocaleTest.sh Changeset: e0f94b9c53a8 Author: alexsch Date: 2012-01-10 15:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e0f94b9c53a8 7110815: closed/javax/swing/JSplitPane/4885629/bug4885629.java unstable on MacOS Reviewed-by: kizune + test/javax/swing/JSplitPane/4885629/bug4885629.java Changeset: 79d14e328670 Author: alexsch Date: 2012-01-10 17:11 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79d14e328670 6505523: NullPointerException in BasicTreeUI when a node is removed by expansion listener Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java + test/javax/swing/JTree/6505523/bug6505523.java Changeset: ce32a4e1be1d Author: alexsch Date: 2012-01-13 12:39 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ce32a4e1be1d 7121765: closed/javax/swing/JTextArea/4697612/bug4697612.java fails on MacOS on Aqua L&F Reviewed-by: rupashka + test/javax/swing/JTextArea/4697612/bug4697612.java + test/javax/swing/JTextArea/4697612/bug4697612.txt Changeset: 59b8875949e1 Author: malenkov Date: 2012-01-16 18:28 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59b8875949e1 7122740: PropertyDescriptor Performance Slow Reviewed-by: rupashka ! src/share/classes/com/sun/beans/TypeResolver.java Changeset: 3e9d35e6ee4f Author: denis Date: 2012-01-17 19:09 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e9d35e6ee4f 7110590: DnDMerlinQLTestsuite_DnDJTextArea test fails with an java.awt.dnd.InvalidDnDOperationException Reviewed-by: art ! src/share/classes/java/awt/AWTKeyStroke.java Changeset: 89bc9d08fe82 Author: anthony Date: 2012-01-18 19:09 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89bc9d08fe82 7130662: GTK file dialog crashes with a NPE Summary: Guard adding a back slash to the directory name with an if (!= null) check Reviewed-by: anthony, art Contributed-by: Matt ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java Changeset: fe1278123fbb Author: lana Date: 2012-01-18 11:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe1278123fbb Merge - test/tools/launcher/DefaultLocaleTest.sh Changeset: 4d8b49a45cff Author: lana Date: 2012-01-18 20:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d8b49a45cff Merge Changeset: e6614f361127 Author: lana Date: 2012-01-18 20:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e6614f361127 Merge - test/java/io/File/BlockIsDirectory.java Changeset: 227fcf5d0bec Author: lana Date: 2012-01-24 13:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/227fcf5d0bec Merge - test/java/io/File/BlockIsDirectory.java Changeset: db189e2f3cdb Author: jrose Date: 2012-01-18 17:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/db189e2f3cdb 7117167: Misc warnings in java.lang.invoke and sun.invoke.* Reviewed-by: smarks ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/invoke/util/Wrapper.java ! test/java/lang/invoke/CallSiteTest.java ! test/java/lang/invoke/ClassValueTest.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/lang/invoke/PermuteArgsTest.java ! test/java/lang/invoke/RicochetTest.java ! test/java/lang/invoke/ThrowExceptionsTest.java ! test/sun/invoke/util/ValueConversionsTest.java Changeset: 01014596ada1 Author: jrose Date: 2012-01-18 17:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01014596ada1 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init Summary: Use correct access token for unreflecting MHs where setAccessible(true) Reviewed-by: never, twisti ! src/share/classes/java/lang/invoke/MethodHandles.java Changeset: 92d2cba30f08 Author: jrose Date: 2012-01-18 17:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92d2cba30f08 7030453: JSR 292 ClassValue.get method is too slow Summary: Implement ClassValue cooperatively with Class like ThreadLocal with Thread. Reviewed-by: twisti, mduigou ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassValue.java ! test/java/lang/invoke/ClassValueTest.java Changeset: 81a2629aa2a2 Author: amurillo Date: 2012-01-20 14:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/81a2629aa2a2 Merge Changeset: 954a1c535730 Author: amurillo Date: 2012-01-25 12:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/954a1c535730 Merge - test/java/io/File/BlockIsDirectory.java Changeset: d3b334e376d3 Author: mr Date: 2012-01-23 12:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d3b334e376d3 7110396: Sound code fails to build with gcc 4.6 on multiarch Linux systems Reviewed-by: ohair ! make/javax/sound/jsoundalsa/Makefile Changeset: 54202e0148ec Author: katleman Date: 2012-01-25 13:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/54202e0148ec Merge Changeset: 34029a0c69bb Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/34029a0c69bb Added tag jdk8-b23 for changeset 54202e0148ec ! .hgtags Changeset: 7a25b72b3644 Author: lana Date: 2012-01-28 20:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a25b72b3644 Merge From georges.saab at oracle.com Sun Jan 29 10:23:18 2012 From: georges.saab at oracle.com (Georges Saab) Date: Sun, 29 Jan 2012 10:23:18 -0800 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com> References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com> <4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com> <4E51D843-A417-422C-9207-DF130D605DCC@oracle.com> <7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com> Message-ID: <63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com> On 28 jan 2012, at 09:46, Kelly O'Hair wrote: > > On Jan 27, 2012, at 9:52 PM, Georges Saab wrote: > >> >> On 27 jan 2012, at 12:40, Kelly O'Hair wrote: >> >>> >>> On Jan 26, 2012, at 2:47 PM, Georges Saab wrote: >>> >>>>> As long as we target both 7u and 8 we will be using two different toolsets. But I agree that JPRT and RE should be using the same tools. That needs to be taken up with RE and Kelly. >>>> >>>> Ideally not just using the same tools, but they should _be_ the same systems. But I digress... >>> >>> >>> I have tried very hard to have JPRT match RE, this 6u14 vs. 6u18 difference was a mistake we will correct. >>> >>> However, it is literally impossible to keep any two systems identical all the time, >> >> Exactly. If the same system is used for checkin-test builds and production builds then you no >> longer have two systems that need to be 'kept in sync'. > > I'm missing something. How can everybody using the exact same system scale to 100's of developers? System = distributed build and test of OpenJDK Developers send in jobs Jobs are distribute across a pool of (HW/OS) resources The resources may be divided into pools dedicated to different tasks (RE/checkin/perf/stress) The pools are populated initially according to predictions of load and then increased/rebalanced according to data on actual usage No assumptions made about what exists on the machine other than HW/OS The build and test tasks are self sufficient, i.e. bootstrap themselves The bootstrapping is done in the same way for different build and test tasks The only scaling aspect that seems at all challenging is that the current checkin system is designed to serialize checkins in a way that apparently does not scale -- here there are some decisions to be made and tradeoffs but this is nothing new in the world of Open community development (or any large team development for that matter) > > And that one system will naturally change over time too, so unless you are able to prevent all change > to a system (impossible with security updates etc) every use of that 'same system' will be different. Yes, but it is possible to control this update and have a staging environment so you know that a HW/OS update will not break the existing successful build when rolled out to the build/test farm. > > -kto > >> >> >>> and many products used by RE >>> (like PocketSoft RTPATCH) are simply not available to all JPRT systems. >>> So this is always a best match situation. I do what I can to match RE because that's a primary goal of JPRT to insure >>> that RE builds will be successful. >>> >>> We also have little control on when PDIT/GIT system maintenance could change the system >>> by installing patches or updates on systems. So there is always some randomness to the systems. >>> >>> -kto >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120129/0cb9beb1/attachment.html From kelly.ohair at oracle.com Sun Jan 29 11:52:17 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Sun, 29 Jan 2012 11:52:17 -0800 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com> References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com> <4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com> <4E51D843-A417-422C-9207-DF130D605DCC@oracle.com> <7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com> <63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com> Message-ID: <13F503FD-0B04-4383-BD98-7F2A4C518820@oracle.com> On Jan 29, 2012, at 10:23 AM, Georges Saab wrote: >> >> I'm missing something. How can everybody using the exact same system scale to 100's of developers? > > System = distributed build and test of OpenJDK Ah ha... I'm down in the trenches dealing with dozens of different OS's arch's variation machines. You are speaking to a higher level, I need to crawl out of the basement. > > Developers send in jobs > Jobs are distribute across a pool of (HW/OS) resources > The resources may be divided into pools dedicated to different tasks (RE/checkin/perf/stress) > The pools are populated initially according to predictions of load and then increased/rebalanced according to data on actual usage > No assumptions made about what exists on the machine other than HW/OS > The build and test tasks are self sufficient, i.e. bootstrap themselves > The bootstrapping is done in the same way for different build and test tasks Understood. We have talked about this before. I have also been on the search for the Holy Grail. ;^) This is why I keep working on JPRT. > > The only scaling aspect that seems at all challenging is that the current checkin system is designed to serialize checkins in a way that apparently does not scale -- here there are some decisions to be made and tradeoffs but this is nothing new in the world of Open community development (or any large team development for that matter) The serialize checkins issue can be minimized some by using distributed SCMs (Mercurial, Git, etc) and using separate forests (fewer developers per source repository means fewer merge/sync issues) and having an integrator merge into a master. This has proven to work in many situations but it also creates delivery to master delays, especially if the integration process is too heavyweight. The JDK projects has been doing this for a long time, I'm sure many people have opinions as to how successful it is or isn't. It is my opinion that merges/syncs are some of the most dangerous things you can do to a source base, and anything we can do to avoid them is usually goodness, I don't think you should scale this without some very great care. > >> >> And that one system will naturally change over time too, so unless you are able to prevent all change >> to a system (impossible with security updates etc) every use of that 'same system' will be different. > > Yes, but it is possible to control this update and have a staging environment so you know that a HW/OS update will not break the existing successful build when rolled out to the build/test farm. Possible but not always easy. The auto updating of everything has increased significantly over the years, making it harder to control completely. I've been doing this build&test stuff long enough to never expect anything to be 100% reliable. Hardware fails, software updates regress functionality, networks become unreliable, humans trip over power cords, virus scanners break things, etc. It just happens, and often, it's not very predictable or reproducible. You can do lots of things to minimize issues, but at some point you just have to accept a few risks because the alternative just isn't feasible or just can't happen with the resources we have. -kto -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120129/f61468c7/attachment-0001.html From Dmitry.Samersoff at oracle.com Sun Jan 29 13:51:32 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 30 Jan 2012 01:51:32 +0400 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <13F503FD-0B04-4383-BD98-7F2A4C518820@oracle.com> References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com> <4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com> <4E51D843-A417-422C-9207-DF130D605DCC@oracle.com> <7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com> <63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com> <13F503FD-0B04-4383-BD98-7F2A4C518820@oracle.com> Message-ID: <4F25BF64.6070802@oracle.com> Kelly, > The serialize checkins issue can be minimized some by using > distributed SCMs (Mercurial, Git, etc) We have chosen a model: build->test->integrate but we may consider different approach: integrate->build->test->[backout if necessary] i.e. Developer (A) integrate his changeset to an integration workspace Bot takes snapshot and start building/testing Developer (B) integrate his changeset to an integration workspace Bot takes snapshot and start building/testing if Job A failed, bot lock integration ws, restore it to pre-A state, apply B-patch. unlock ws. -Dmitry On 2012-01-29 23:52, Kelly O'Hair wrote: > > On Jan 29, 2012, at 10:23 AM, Georges Saab wrote: > >>> >>> I'm missing something. How can everybody using the exact same system >>> scale to 100's of developers? >> >> System = distributed build and test of OpenJDK > > Ah ha... I'm down in the trenches dealing with dozens of different > OS's arch's variation machines. > You are speaking to a higher level, I need to crawl out of the basement. > >> >> Developers send in jobs >> Jobs are distribute across a pool of (HW/OS) resources >> The resources may be divided into pools dedicated to different tasks >> (RE/checkin/perf/stress) >> The pools are populated initially according to predictions of load and >> then increased/rebalanced according to data on actual usage >> No assumptions made about what exists on the machine other than HW/OS >> The build and test tasks are self sufficient, i.e. bootstrap themselves >> The bootstrapping is done in the same way for different build and test >> tasks > > Understood. We have talked about this before. I have also been on the > search for the Holy Grail. ;^) > This is why I keep working on JPRT. > >> >> The only scaling aspect that seems at all challenging is that the >> current checkin system is designed to serialize checkins in a way that >> apparently does not scale -- here there are some decisions to be made >> and tradeoffs but this is nothing new in the world of Open community >> development (or any large team development for that matter) > > The serialize checkins issue can be minimized some by using distributed > SCMs (Mercurial, Git, etc) > and using separate forests (fewer developers per source repository means > fewer merge/sync issues) > and having an integrator merge into a master. This has proven to work in > many situations but it > also creates delivery to master delays, especially if the integration > process is too heavyweight. > > The JDK projects has been doing this for a long time, I'm sure many > people have opinions as to how > successful it is or isn't. > > It is my opinion that merges/syncs are some of the most dangerous things > you can do to a source base, > and anything we can do to avoid them is usually goodness, I don't think > you should scale this without some > very great care. > >> >>> >>> And that one system will naturally change over time too, so unless >>> you are able to prevent all change >>> to a system (impossible with security updates etc) every use of that >>> 'same system' will be different. >> >> Yes, but it is possible to control this update and have a staging >> environment so you know that a HW/OS update will not break the >> existing successful build when rolled out to the build/test farm. > > Possible but not always easy. The auto updating of everything has > increased significantly over the years, > making it harder to control completely. > > I've been doing this build&test stuff long enough to never expect > anything to be 100% reliable. > Hardware fails, software updates regress functionality, networks become > unreliable, humans trip over > power cords, virus scanners break things, etc. It just happens, and > often, it's not very predictable or reproducible. > You can do lots of things to minimize issues, but at some point you just > have to accept a few risks because > the alternative just isn't feasible or just can't happen with the > resources we have. > > -kto > > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From stefan.karlsson at oracle.com Sun Jan 29 15:42:11 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 30 Jan 2012 00:42:11 +0100 Subject: Review request (XS): 7022100: Method annotations are incorrectly set when redefining classes In-Reply-To: <4F22A6EA.6090004@oracle.com> References: <4F22A2CF.9080708@oracle.com> <4F22A6EA.6090004@oracle.com> Message-ID: <4F25D953.70406@oracle.com> On 2012-01-27 14:30, David Holmes wrote: > On 27/01/2012 11:12 PM, Stefan Karlsson wrote: >> Here's a fix for a simple copy-n-past bug in the handling of >> annotations, affecting only class redefinition. >> >> http://cr.openjdk.java.net/~stefank/7022100/webrev.00/ >> >> 7022100: Method annotations are incorrectly set when redefining classes >> Summary: Changed to the correct annotation arrays >> Reviewed-by: TBD1, TBD2 > > Looks perfectly logical, but begs the question as to how this has not > been discovered. Are there no tests in this area? I don't think so. This code is only exercised if you redefine a class under the following conditions: 1) The class has overloaded functions, 2) these functions have parameter annotations, 3) the redefined class has swapped the order of these functions (or added another overloaded function). I've managed to write a test for the set_method_parameter_annotations, I just need to figure out how to push it to a suitable test suite. I couldn't come up with a test case fore the set_method_default_annotations case. These annotations are only used together with methods in an Annotation class. Since annotation methods are not allowed to have parameters, I can't induce condition (3) above. thanks, StefanK > > David From John.Coomes at oracle.com Sun Jan 29 18:35:52 2012 From: John.Coomes at oracle.com (John Coomes) Date: Sun, 29 Jan 2012 18:35:52 -0800 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <4F25BF64.6070802@oracle.com> References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com> <4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com> <4E51D843-A417-422C-9207-DF130D605DCC@oracle.com> <7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com> <63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com> <13F503FD-0B04-4383-BD98-7F2A4C518820@oracle.com> <4F25BF64.6070802@oracle.com> Message-ID: <20262.520.379715.707949@oracle.com> Dmitry Samersoff (Dmitry.Samersoff at oracle.com) wrote: > Kelly, > > > The serialize checkins issue can be minimized some by using > > distributed SCMs (Mercurial, Git, etc) > > We have chosen a model: > > build->test->integrate > > but we may consider different approach: > > integrate->build->test->[backout if necessary] In that model, you can never rely on the repository having any degree of stability. It may not even build at a given moment. > Developer (A) integrate his changeset to an integration workspace > Bot takes snapshot and start building/testing > Developer (B) integrate his changeset to an integration workspace > Bot takes snapshot and start building/testing > > if Job A failed, bot lock integration ws, restore it to pre-A state, > apply B-patch. unlock ws. Don't forget the trusting souls that pulled from the integration repo after A inflicted the breakage: they each waste time cleaning up a copy of A's mess. -John > On 2012-01-29 23:52, Kelly O'Hair wrote: > > > > On Jan 29, 2012, at 10:23 AM, Georges Saab wrote: > > > >>> > >>> I'm missing something. How can everybody using the exact same system > >>> scale to 100's of developers? > >> > >> System = distributed build and test of OpenJDK > > > > Ah ha... I'm down in the trenches dealing with dozens of different > > OS's arch's variation machines. > > You are speaking to a higher level, I need to crawl out of the basement. > > > >> > >> Developers send in jobs > >> Jobs are distribute across a pool of (HW/OS) resources > >> The resources may be divided into pools dedicated to different tasks > >> (RE/checkin/perf/stress) > >> The pools are populated initially according to predictions of load and > >> then increased/rebalanced according to data on actual usage > >> No assumptions made about what exists on the machine other than HW/OS > >> The build and test tasks are self sufficient, i.e. bootstrap themselves > >> The bootstrapping is done in the same way for different build and test > >> tasks > > > > Understood. We have talked about this before. I have also been on the > > search for the Holy Grail. ;^) > > This is why I keep working on JPRT. > > > >> > >> The only scaling aspect that seems at all challenging is that the > >> current checkin system is designed to serialize checkins in a way that > >> apparently does not scale -- here there are some decisions to be made > >> and tradeoffs but this is nothing new in the world of Open community > >> development (or any large team development for that matter) > > > > The serialize checkins issue can be minimized some by using distributed > > SCMs (Mercurial, Git, etc) > > and using separate forests (fewer developers per source repository means > > fewer merge/sync issues) > > and having an integrator merge into a master. This has proven to work in > > many situations but it > > also creates delivery to master delays, especially if the integration > > process is too heavyweight. > > > > The JDK projects has been doing this for a long time, I'm sure many > > people have opinions as to how > > successful it is or isn't. > > > > It is my opinion that merges/syncs are some of the most dangerous things > > you can do to a source base, > > and anything we can do to avoid them is usually goodness, I don't think > > you should scale this without some > > very great care. > > > >> > >>> > >>> And that one system will naturally change over time too, so unless > >>> you are able to prevent all change > >>> to a system (impossible with security updates etc) every use of that > >>> 'same system' will be different. > >> > >> Yes, but it is possible to control this update and have a staging > >> environment so you know that a HW/OS update will not break the > >> existing successful build when rolled out to the build/test farm. > > > > Possible but not always easy. The auto updating of everything has > > increased significantly over the years, > > making it harder to control completely. > > > > I've been doing this build&test stuff long enough to never expect > > anything to be 100% reliable. > > Hardware fails, software updates regress functionality, networks become > > unreliable, humans trip over > > power cords, virus scanners break things, etc. It just happens, and > > often, it's not very predictable or reproducible. > > You can do lots of things to minimize issues, but at some point you just > > have to accept a few risks because > > the alternative just isn't feasible or just can't happen with the > > resources we have. > > > > -kto > > > > > > > -- > Dmitry Samersoff > Java Hotspot development team, SPB04 > * There will come soft rains ... From Dmitry.Samersoff at oracle.com Mon Jan 30 01:09:50 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 30 Jan 2012 13:09:50 +0400 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <20262.520.379715.707949@oracle.com> References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com> <4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com> <4E51D843-A417-422C-9207-DF130D605DCC@oracle.com> <7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com> <63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com> <13F503FD-0B04-4383-BD98-7F2A4C518820@oracle.com> <4F25BF64.6070802@oracle.com> <20262.520.379715.707949@oracle.com> Message-ID: <4F265E5E.3010308@oracle.com> John, Actually the goal of my letter is not to promote new integration scheme. Just to remind that we need to put some efforts to internal process review and optimization. But, see answers below (inline): Integration method I mentioned often used in open source projects, because it doesn't require any special infrastructure for external commiters. The only necessary thing to do safe commit is a write access to integration (-gate) workspace. On 2012-01-30 06:35, John Coomes wrote: >> We have chosen a model: >> >> build->test->integrate >> >> but we may consider different approach: >> >> integrate->build->test->[backout if necessary] > > In that model, you can never rely on the repository having any degree > of stability. It may not even build at a given moment. What happens today if Developer A and Developer B changes the same line of a source? What happens today if Developer A changes some_func() but Developer B rely on some_func() ? We would get a fault *after* all integration tests and SQE file one more nightly bug. To the time someone investigate it and give the fix, bad code will be distributed to all dev workspaces. >> Developer (A) integrate his changeset to an integration workspace >> Bot takes snapshot and start building/testing >> Developer (B) integrate his changeset to an integration workspace >> Bot takes snapshot and start building/testing >> >> if Job A failed, bot lock integration ws, restore it to pre-A state, >> apply B-patch. unlock ws. > > Don't forget the trusting souls that pulled from the integration repo > after A inflicted the breakage: they each waste time cleaning up a > copy of A's mess. Nobody pulls from -gate repository today and nobody expected to do it. -gate to ws merge continues as usual. To remove faulty changeset we need about fifteen minutes for whole jdk at worst. -Dmitry > > -John > >> On 2012-01-29 23:52, Kelly O'Hair wrote: >>> >>> On Jan 29, 2012, at 10:23 AM, Georges Saab wrote: >>> >>>>> >>>>> I'm missing something. How can everybody using the exact same system >>>>> scale to 100's of developers? >>>> >>>> System = distributed build and test of OpenJDK >>> >>> Ah ha... I'm down in the trenches dealing with dozens of different >>> OS's arch's variation machines. >>> You are speaking to a higher level, I need to crawl out of the basement. >>> >>>> >>>> Developers send in jobs >>>> Jobs are distribute across a pool of (HW/OS) resources >>>> The resources may be divided into pools dedicated to different tasks >>>> (RE/checkin/perf/stress) >>>> The pools are populated initially according to predictions of load and >>>> then increased/rebalanced according to data on actual usage >>>> No assumptions made about what exists on the machine other than HW/OS >>>> The build and test tasks are self sufficient, i.e. bootstrap themselves >>>> The bootstrapping is done in the same way for different build and test >>>> tasks >>> >>> Understood. We have talked about this before. I have also been on the >>> search for the Holy Grail. ;^) >>> This is why I keep working on JPRT. >>> >>>> >>>> The only scaling aspect that seems at all challenging is that the >>>> current checkin system is designed to serialize checkins in a way that >>>> apparently does not scale -- here there are some decisions to be made >>>> and tradeoffs but this is nothing new in the world of Open community >>>> development (or any large team development for that matter) >>> >>> The serialize checkins issue can be minimized some by using distributed >>> SCMs (Mercurial, Git, etc) >>> and using separate forests (fewer developers per source repository means >>> fewer merge/sync issues) >>> and having an integrator merge into a master. This has proven to work in >>> many situations but it >>> also creates delivery to master delays, especially if the integration >>> process is too heavyweight. >>> >>> The JDK projects has been doing this for a long time, I'm sure many >>> people have opinions as to how >>> successful it is or isn't. >>> >>> It is my opinion that merges/syncs are some of the most dangerous things >>> you can do to a source base, >>> and anything we can do to avoid them is usually goodness, I don't think >>> you should scale this without some >>> very great care. >>> >>>> >>>>> >>>>> And that one system will naturally change over time too, so unless >>>>> you are able to prevent all change >>>>> to a system (impossible with security updates etc) every use of that >>>>> 'same system' will be different. >>>> >>>> Yes, but it is possible to control this update and have a staging >>>> environment so you know that a HW/OS update will not break the >>>> existing successful build when rolled out to the build/test farm. >>> >>> Possible but not always easy. The auto updating of everything has >>> increased significantly over the years, >>> making it harder to control completely. >>> >>> I've been doing this build&test stuff long enough to never expect >>> anything to be 100% reliable. >>> Hardware fails, software updates regress functionality, networks become >>> unreliable, humans trip over >>> power cords, virus scanners break things, etc. It just happens, and >>> often, it's not very predictable or reproducible. >>> You can do lots of things to minimize issues, but at some point you just >>> have to accept a few risks because >>> the alternative just isn't feasible or just can't happen with the >>> resources we have. >>> >>> -kto >>> >>> >> >> >> -- >> Dmitry Samersoff >> Java Hotspot development team, SPB04 >> * There will come soft rains ... -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From robert.ottenhag at oracle.com Mon Jan 30 02:00:46 2012 From: robert.ottenhag at oracle.com (Robert Ottenhag) Date: Mon, 30 Jan 2012 11:00:46 +0100 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <4F265E5E.3010308@oracle.com> References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com> <4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com> <4E51D843-A417-422C-9207-DF130D605DCC@oracle.com> <7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com> <63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com> <13F503FD-0B04-4383-BD98-7F2A4C518820@oracle.com> <4F25BF64.6070802@oracle.com> <20262.520.379715.707949@oracle.com> <4F265E5E.3010308@oracle.com> Message-ID: <4F266A4E.9030902@oracle.com> Dmitry, I think this discussion diverged somewhat from the original topic, but I do agree with you that we must also attack the problem on a process level. With the model you propose (and also the existing model) I would also like to stress the need for continuous and automatic builds triggered by incoming new changes compared to the last working change. Having that, it is possible to update labels (tags) for "last_clean_build", "last_nightly_build", etc. That way any build breakage would only be visible at the tip. However, when submitting a new change care should be taken to do it against a working tip, that it builds and tests correctly (personal check-in testing). Actually, this is close to the model we had for the JRockit source base. WLS also uses the model of sliding labels for "last_clean_build" where developers most often only do partial builds themselves. Regarding external committers, I think they need both the option of building and testing locally, as well as access to an Open JDK specific queue for build and test submissions. By making use of cross compilation and open tools it is possible to at least verify that the product builds locally. Even better is to also supply preconfigured VMs with the necessary standard build and test environment (e.g. obsolete Solaris or Linux distros that we require). In general, having a build and test setup that is automatically configurable (including Windows) will help both internal and external developers (see also the build-infra project). /Robert On 01/30/2012 10:09 AM, Dmitry Samersoff wrote: > John, > > Actually the goal of my letter is not to promote new integration > scheme. Just to remind that we need to put some efforts to internal > process review and optimization. > > But, see answers below (inline): > > Integration method I mentioned often used in open source projects, > because it doesn't require any special infrastructure for external > commiters. The only necessary thing to do safe commit is a write > access to integration (-gate) workspace. > > On 2012-01-30 06:35, John Coomes wrote: >>> We have chosen a model: >>> >>> build->test->integrate >>> >>> but we may consider different approach: >>> >>> integrate->build->test->[backout if necessary] >> >> In that model, you can never rely on the repository having any degree >> of stability. It may not even build at a given moment. > > What happens today if Developer A and Developer B changes the same > line of a source? > > What happens today if Developer A changes some_func() but Developer B > rely on some_func() ? > > We would get a fault *after* all integration tests and SQE file one > more nightly bug. To the time someone investigate it and give the fix, > bad code will be distributed to all dev workspaces. > > >>> Developer (A) integrate his changeset to an integration workspace >>> Bot takes snapshot and start building/testing >>> Developer (B) integrate his changeset to an integration workspace >>> Bot takes snapshot and start building/testing >>> >>> if Job A failed, bot lock integration ws, restore it to pre-A state, >>> apply B-patch. unlock ws. >> >> Don't forget the trusting souls that pulled from the integration repo >> after A inflicted the breakage: they each waste time cleaning up a >> copy of A's mess. > > Nobody pulls from -gate repository today and nobody expected to do it. > -gate to ws merge continues as usual. > > To remove faulty changeset we need about fifteen minutes for whole jdk > at worst. > > -Dmitry > >> >> -John >> >>> On 2012-01-29 23:52, Kelly O'Hair wrote: >>>> >>>> On Jan 29, 2012, at 10:23 AM, Georges Saab wrote: >>>> >>>>>> >>>>>> I'm missing something. How can everybody using the exact same system >>>>>> scale to 100's of developers? >>>>> >>>>> System = distributed build and test of OpenJDK >>>> >>>> Ah ha... I'm down in the trenches dealing with dozens of different >>>> OS's arch's variation machines. >>>> You are speaking to a higher level, I need to crawl out of the >>>> basement. >>>> >>>>> >>>>> Developers send in jobs >>>>> Jobs are distribute across a pool of (HW/OS) resources >>>>> The resources may be divided into pools dedicated to different tasks >>>>> (RE/checkin/perf/stress) >>>>> The pools are populated initially according to predictions of load >>>>> and >>>>> then increased/rebalanced according to data on actual usage >>>>> No assumptions made about what exists on the machine other than HW/OS >>>>> The build and test tasks are self sufficient, i.e. bootstrap >>>>> themselves >>>>> The bootstrapping is done in the same way for different build and >>>>> test >>>>> tasks >>>> >>>> Understood. We have talked about this before. I have also been on the >>>> search for the Holy Grail. ;^) >>>> This is why I keep working on JPRT. >>>> >>>>> >>>>> The only scaling aspect that seems at all challenging is that the >>>>> current checkin system is designed to serialize checkins in a way >>>>> that >>>>> apparently does not scale -- here there are some decisions to be made >>>>> and tradeoffs but this is nothing new in the world of Open community >>>>> development (or any large team development for that matter) >>>> >>>> The serialize checkins issue can be minimized some by using >>>> distributed >>>> SCMs (Mercurial, Git, etc) >>>> and using separate forests (fewer developers per source repository >>>> means >>>> fewer merge/sync issues) >>>> and having an integrator merge into a master. This has proven to >>>> work in >>>> many situations but it >>>> also creates delivery to master delays, especially if the integration >>>> process is too heavyweight. >>>> >>>> The JDK projects has been doing this for a long time, I'm sure many >>>> people have opinions as to how >>>> successful it is or isn't. >>>> >>>> It is my opinion that merges/syncs are some of the most dangerous >>>> things >>>> you can do to a source base, >>>> and anything we can do to avoid them is usually goodness, I don't >>>> think >>>> you should scale this without some >>>> very great care. >>>> >>>>> >>>>>> >>>>>> And that one system will naturally change over time too, so unless >>>>>> you are able to prevent all change >>>>>> to a system (impossible with security updates etc) every use of that >>>>>> 'same system' will be different. >>>>> >>>>> Yes, but it is possible to control this update and have a staging >>>>> environment so you know that a HW/OS update will not break the >>>>> existing successful build when rolled out to the build/test farm. >>>> >>>> Possible but not always easy. The auto updating of everything has >>>> increased significantly over the years, >>>> making it harder to control completely. >>>> >>>> I've been doing this build&test stuff long enough to never expect >>>> anything to be 100% reliable. >>>> Hardware fails, software updates regress functionality, networks >>>> become >>>> unreliable, humans trip over >>>> power cords, virus scanners break things, etc. It just happens, and >>>> often, it's not very predictable or reproducible. >>>> You can do lots of things to minimize issues, but at some point you >>>> just >>>> have to accept a few risks because >>>> the alternative just isn't feasible or just can't happen with the >>>> resources we have. >>>> >>>> -kto >>>> >>>> >>> >>> >>> -- >>> Dmitry Samersoff >>> Java Hotspot development team, SPB04 >>> * There will come soft rains ... > > -- Oracle Robert Ottenhag | Senior Member of Technical Staff Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161 Oracle Java HotSpot Virtual Machine ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254-6746 Green Oracle Oracle is committed to developing practices and products that help protect the environment -- From staffan.larsen at oracle.com Mon Jan 30 02:05:59 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 30 Jan 2012 11:05:59 +0100 Subject: Request for Review: 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms Message-ID: <83B4C4D0-3005-442A-9D5D-274AA97AF1E0@oracle.com> Please review the following fix. Webrev: http://cr.openjdk.java.net/~sla/7132199/webrev.00/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132199 The problem is that HotSpot will always create the .java_pid1234 socket/door file in /tmp (see CR 7009828). The JDK will currently look first in the current directory then in java.io.tmpdir. If java.io.tmpdir has the default value of /tmp this works, but if the user has set it to something else it doesn't. My fix hardcodes /tmp in LinuxVirtualMachine.java and SolarisVirtualMachine.java. The same fix will be needed in BsdVirtualMachine.java eventually. Thanks, /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120130/4943ad83/attachment.html From Dmitry.Samersoff at oracle.com Mon Jan 30 03:23:56 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 30 Jan 2012 15:23:56 +0400 Subject: Request for Review: 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms In-Reply-To: <83B4C4D0-3005-442A-9D5D-274AA97AF1E0@oracle.com> References: <83B4C4D0-3005-442A-9D5D-274AA97AF1E0@oracle.com> Message-ID: <4F267DCC.2090002@oracle.com> Staffan, 1. Why we can't use System.getProperty("java.io.tmpdir") ? 2. If you decide to hardcode "/tmp" please, create a global constant for it. -Dmitry On 2012-01-30 14:05, Staffan Larsen wrote: > Please review the following fix. > > Webrev: http://cr.openjdk.java.net/~sla/7132199/webrev.00/ > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132199 > > The problem is that HotSpot will always create the .java_pid1234 > socket/door file in /tmp (see CR 7009828). > > The JDK will currently look first in the current directory then in > java.io.tmpdir. If java.io.tmpdir has the default value of /tmp this > works, but if the user has set it to something else it doesn't. > > My fix hardcodes /tmp in LinuxVirtualMachine.java and > SolarisVirtualMachine.java. > > The same fix will be needed in BsdVirtualMachine.java eventually. > > Thanks, > /Staffan -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From david.holmes at oracle.com Mon Jan 30 03:49:00 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 30 Jan 2012 21:49:00 +1000 Subject: Request for Review: 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms In-Reply-To: <83B4C4D0-3005-442A-9D5D-274AA97AF1E0@oracle.com> References: <83B4C4D0-3005-442A-9D5D-274AA97AF1E0@oracle.com> Message-ID: <4F2683AC.4080806@oracle.com> Hi Staffan, I'm somewhat confused by this problem. 6938627 is the CR that changed from /tmp to use the java.io.tmpdir property, but that CR did not modify the files that you have modified - so what broke these files? Looking at your fix, wouldn't it be simpler to just set the static tmpdir to /tmp and leave the rest of the code as-is? Why do you stop looking in the cwd in addition to changing the tmp location? Is it because hotspot will never write it there? Thanks, David On 30/01/2012 8:05 PM, Staffan Larsen wrote: > Please review the following fix. > > Webrev: http://cr.openjdk.java.net/~sla/7132199/webrev.00/ > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132199 > > The problem is that HotSpot will always create the .java_pid1234 > socket/door file in /tmp (see CR 7009828). > > The JDK will currently look first in the current directory then in > java.io.tmpdir. If java.io.tmpdir has the default value of /tmp this > works, but if the user has set it to something else it doesn't. > > My fix hardcodes /tmp in LinuxVirtualMachine.java and > SolarisVirtualMachine.java. > > The same fix will be needed in BsdVirtualMachine.java eventually. > > Thanks, > /Staffan From staffan.larsen at oracle.com Mon Jan 30 04:28:22 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 30 Jan 2012 13:28:22 +0100 Subject: Request for Review: 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms In-Reply-To: <4F267DCC.2090002@oracle.com> References: <83B4C4D0-3005-442A-9D5D-274AA97AF1E0@oracle.com> <4F267DCC.2090002@oracle.com> Message-ID: On 30 jan 2012, at 12:23, Dmitry Samersoff wrote: > 1. Why we can't use System.getProperty("java.io.tmpdir") ? Since HotSpot and the tools run in separate processes it is important that the file is in a well-known global location. It cannot be in different locations for different processes. Since java.io.tmpdir can be set on the command line (which JPRT does), it can be different in the tools and in HotSpot. HotSpot will always write the file to /tmp/.java_pidXXX regardless of the value of java.io.tmpdir (see 7009828). Thus, the tools need to always look there. > 2. If you decide to hardcode "/tmp" please, create a global constant for it. I don't agree that this would make the code easier to read or maintain. I should, however, include a comment saying that the file is always in /tmp regardless of the value of java.io.tmpdir. On 30 jan 2012, at 12:49, David Holmes wrote: > I'm somewhat confused by this problem. 6938627 is the CR that changed from /tmp to use the java.io.tmpdir property, but that CR did not modify the files that you have modified - so what broke these files? 7009828 then changed HotSpot back to use /tmp always. I seems like this has been going back and forth for a while? I don't really know the whole history. > Looking at your fix, wouldn't it be simpler to just set the static tmpdir to /tmp and leave the rest of the code as-is? Why do you stop looking in the cwd in addition to changing the tmp location? Is it because hotspot will never write it there? Changing the tmpdir static would be a smaller fix, but all the cwd code would then remain. Yes, HotSpot never writes to cwd. Thanks, /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120130/555d8fcd/attachment.html From stefan.karlsson at oracle.com Mon Jan 30 05:03:54 2012 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Mon, 30 Jan 2012 13:03:54 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7022100: Method annotations are incorrectly set when redefining classes Message-ID: <20120130130356.9BFEF47284@hg.openjdk.java.net> Changeset: 26a08cbbf042 Author: stefank Date: 2012-01-27 13:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/26a08cbbf042 7022100: Method annotations are incorrectly set when redefining classes Summary: Changed to the correct annotation arrays Reviewed-by: kamg, dholmes, sla ! src/share/vm/oops/instanceKlass.hpp From chris.hegarty at oracle.com Mon Jan 30 06:07:39 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 30 Jan 2012 14:07:39 +0000 Subject: hg: jdk8/tl/jdk: 7132378: Race in FutureTask if used with explicit set ( not Runnable ) Message-ID: <20120130140758.691934728A@hg.openjdk.java.net> Changeset: f9fb8c4b4550 Author: dl Date: 2012-01-30 11:44 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f9fb8c4b4550 7132378: Race in FutureTask if used with explicit set ( not Runnable ) Reviewed-by: chegar, dholmes ! src/share/classes/java/util/concurrent/FutureTask.java + test/java/util/concurrent/FutureTask/DoneTimedGetLoops.java + test/java/util/concurrent/FutureTask/ExplicitSet.java From bengt.rutisson at oracle.com Mon Jan 30 07:50:51 2012 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Mon, 30 Jan 2012 15:50:51 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20120130155055.64F7A4728B@hg.openjdk.java.net> Changeset: f457154eee8b Author: brutisso Date: 2012-01-30 12:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f457154eee8b 7140882: Don't return booleans from methods returning pointers Summary: Changed "return false" to "return NULL" Reviewed-by: dholmes, rottenha Contributed-by: dbhole at redhat.com ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/opto/loopnode.cpp Changeset: d96c130c9399 Author: brutisso Date: 2012-01-30 05:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d96c130c9399 Merge From daniel.daugherty at oracle.com Mon Jan 30 09:05:40 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 30 Jan 2012 10:05:40 -0700 Subject: Request for Review: 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms In-Reply-To: <83B4C4D0-3005-442A-9D5D-274AA97AF1E0@oracle.com> References: <83B4C4D0-3005-442A-9D5D-274AA97AF1E0@oracle.com> Message-ID: <4F26CDE4.9010409@oracle.com> On 1/30/12 3:05 AM, Staffan Larsen wrote: > Please review the following fix. > > Webrev: http://cr.openjdk.java.net/~sla/7132199/webrev.00/ > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132199 > > The problem is that HotSpot will always create the .java_pid1234 > socket/door file in /tmp (see CR 7009828). > > The JDK will currently look first in the current directory then in > java.io.tmpdir. If java.io.tmpdir has the default value of /tmp this > works, but if the user has set it to something else it doesn't. > > My fix hardcodes /tmp in LinuxVirtualMachine.java and > SolarisVirtualMachine.java. > > The same fix will be needed in BsdVirtualMachine.java eventually. Please fix BsdVirtualMachine.java at the same time. Dan > > Thanks, > /Staffan From kelly.ohair at oracle.com Mon Jan 30 09:26:49 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 30 Jan 2012 09:26:49 -0800 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <4F266A4E.9030902@oracle.com> References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com> <4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com> <4E51D843-A417-422C-9207-DF130D605DCC@oracle.com> <7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com> <63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com> <13F503FD-0B04-4383-BD98-7F2A4C518820@oracle.com> <4F25BF64.6070802@oracle.com> <20262.520.379715.707949@oracle.com> <4F265E5E.3010308@oracle.com> <4F266A4E.9030902@oracle.com> Message-ID: <59349013-5AC8-42F9-AE37-FEE60F6DC12C@oracle.com> Diverged and in transit to another planet. :^( A push to a shared repo without verifying it builds on all supported platforms is risky behavior, and one that can consume needless resources finding out it doesn't build, and more importantly waste your co-worker's time undoing it. We have the ability to prevent that, and we should. And the JDK is not just a VM, and cross compilation does not address Windows or Solaris. This is a much more difficult situation than most people think it is. Yes we can change things to simplify it, make it better, but don't kid yourself, this is more complex than most people think. Anyone that hasn't built the entire JDK on Windows, successfully, should try it. -kto On Jan 30, 2012, at 2:00 AM, Robert Ottenhag wrote: > Dmitry, > > I think this discussion diverged somewhat from the original topic, but I do agree with you that we must also attack the problem on a process level. > > With the model you propose (and also the existing model) I would also like to stress the need for continuous and automatic builds triggered by incoming new changes compared to the last working change. Having that, it is possible to update labels (tags) for "last_clean_build", "last_nightly_build", etc. That way any build breakage would only be visible at the tip. > > However, when submitting a new change care should be taken to do it against a working tip, that it builds and tests correctly (personal check-in testing). Actually, this is close to the model we had for the JRockit source base. WLS also uses the model of sliding labels for "last_clean_build" where developers most often only do partial builds themselves. > > Regarding external committers, I think they need both the option of building and testing locally, as well as access to an Open JDK specific queue for build and test submissions. > > By making use of cross compilation and open tools it is possible to at least verify that the product builds locally. Even better is to also supply preconfigured VMs with the necessary standard build and test environment (e.g. obsolete Solaris or Linux distros that we require). In general, having a build and test setup that is automatically configurable (including Windows) will help both internal and external developers (see also the build-infra project). > > /Robert > > On 01/30/2012 10:09 AM, Dmitry Samersoff wrote: >> John, >> >> Actually the goal of my letter is not to promote new integration scheme. Just to remind that we need to put some efforts to internal process review and optimization. >> >> But, see answers below (inline): >> >> Integration method I mentioned often used in open source projects, >> because it doesn't require any special infrastructure for external commiters. The only necessary thing to do safe commit is a write access to integration (-gate) workspace. >> >> On 2012-01-30 06:35, John Coomes wrote: >>>> We have chosen a model: >>>> >>>> build->test->integrate >>>> >>>> but we may consider different approach: >>>> >>>> integrate->build->test->[backout if necessary] >>> >>> In that model, you can never rely on the repository having any degree >>> of stability. It may not even build at a given moment. >> >> What happens today if Developer A and Developer B changes the same line of a source? >> >> What happens today if Developer A changes some_func() but Developer B >> rely on some_func() ? >> >> We would get a fault *after* all integration tests and SQE file one more nightly bug. To the time someone investigate it and give the fix, bad code will be distributed to all dev workspaces. >> >> >>>> Developer (A) integrate his changeset to an integration workspace >>>> Bot takes snapshot and start building/testing >>>> Developer (B) integrate his changeset to an integration workspace >>>> Bot takes snapshot and start building/testing >>>> >>>> if Job A failed, bot lock integration ws, restore it to pre-A state, >>>> apply B-patch. unlock ws. >>> >>> Don't forget the trusting souls that pulled from the integration repo >>> after A inflicted the breakage: they each waste time cleaning up a >>> copy of A's mess. >> >> Nobody pulls from -gate repository today and nobody expected to do it. >> -gate to ws merge continues as usual. >> >> To remove faulty changeset we need about fifteen minutes for whole jdk at worst. >> >> -Dmitry >> >>> >>> -John >>> >>>> On 2012-01-29 23:52, Kelly O'Hair wrote: >>>>> >>>>> On Jan 29, 2012, at 10:23 AM, Georges Saab wrote: >>>>> >>>>>>> >>>>>>> I'm missing something. How can everybody using the exact same system >>>>>>> scale to 100's of developers? >>>>>> >>>>>> System = distributed build and test of OpenJDK >>>>> >>>>> Ah ha... I'm down in the trenches dealing with dozens of different >>>>> OS's arch's variation machines. >>>>> You are speaking to a higher level, I need to crawl out of the basement. >>>>> >>>>>> >>>>>> Developers send in jobs >>>>>> Jobs are distribute across a pool of (HW/OS) resources >>>>>> The resources may be divided into pools dedicated to different tasks >>>>>> (RE/checkin/perf/stress) >>>>>> The pools are populated initially according to predictions of load and >>>>>> then increased/rebalanced according to data on actual usage >>>>>> No assumptions made about what exists on the machine other than HW/OS >>>>>> The build and test tasks are self sufficient, i.e. bootstrap themselves >>>>>> The bootstrapping is done in the same way for different build and test >>>>>> tasks >>>>> >>>>> Understood. We have talked about this before. I have also been on the >>>>> search for the Holy Grail. ;^) >>>>> This is why I keep working on JPRT. >>>>> >>>>>> >>>>>> The only scaling aspect that seems at all challenging is that the >>>>>> current checkin system is designed to serialize checkins in a way that >>>>>> apparently does not scale -- here there are some decisions to be made >>>>>> and tradeoffs but this is nothing new in the world of Open community >>>>>> development (or any large team development for that matter) >>>>> >>>>> The serialize checkins issue can be minimized some by using distributed >>>>> SCMs (Mercurial, Git, etc) >>>>> and using separate forests (fewer developers per source repository means >>>>> fewer merge/sync issues) >>>>> and having an integrator merge into a master. This has proven to work in >>>>> many situations but it >>>>> also creates delivery to master delays, especially if the integration >>>>> process is too heavyweight. >>>>> >>>>> The JDK projects has been doing this for a long time, I'm sure many >>>>> people have opinions as to how >>>>> successful it is or isn't. >>>>> >>>>> It is my opinion that merges/syncs are some of the most dangerous things >>>>> you can do to a source base, >>>>> and anything we can do to avoid them is usually goodness, I don't think >>>>> you should scale this without some >>>>> very great care. >>>>> >>>>>> >>>>>>> >>>>>>> And that one system will naturally change over time too, so unless >>>>>>> you are able to prevent all change >>>>>>> to a system (impossible with security updates etc) every use of that >>>>>>> 'same system' will be different. >>>>>> >>>>>> Yes, but it is possible to control this update and have a staging >>>>>> environment so you know that a HW/OS update will not break the >>>>>> existing successful build when rolled out to the build/test farm. >>>>> >>>>> Possible but not always easy. The auto updating of everything has >>>>> increased significantly over the years, >>>>> making it harder to control completely. >>>>> >>>>> I've been doing this build&test stuff long enough to never expect >>>>> anything to be 100% reliable. >>>>> Hardware fails, software updates regress functionality, networks become >>>>> unreliable, humans trip over >>>>> power cords, virus scanners break things, etc. It just happens, and >>>>> often, it's not very predictable or reproducible. >>>>> You can do lots of things to minimize issues, but at some point you just >>>>> have to accept a few risks because >>>>> the alternative just isn't feasible or just can't happen with the >>>>> resources we have. >>>>> >>>>> -kto >>>>> >>>>> >>>> >>>> >>>> -- >>>> Dmitry Samersoff >>>> Java Hotspot development team, SPB04 >>>> * There will come soft rains ... >> >> > > > -- > Oracle > Robert Ottenhag | Senior Member of Technical Staff > Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161 > Oracle Java HotSpot Virtual Machine > ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm > > Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254-6746 > > Green Oracle > > Oracle is committed to developing practices and products that help protect the environment > -- > From Dmitry.Samersoff at oracle.com Mon Jan 30 09:28:05 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 30 Jan 2012 21:28:05 +0400 Subject: Request for Review: 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms In-Reply-To: References: <83B4C4D0-3005-442A-9D5D-274AA97AF1E0@oracle.com> <4F267DCC.2090002@oracle.com> Message-ID: <4F26D325.1000404@oracle.com> On 2012-01-30 16:28, Staffan Larsen wrote: >> 2. If you decide to hardcode "/tmp" please, create a global constant >> for it. > > I don't agree that this would make the code easier to read or maintain. > I should, however, include a comment saying that the file is always in > /tmp regardless of the value of java.io.tmpdir. /tmp is common but not mandatory, especially if we speak about embedded systems. Native code should use P_tmpdir constant from stdio.h rather than hardcode "/tmp". As we can't access it from java I recommend to create a global constant somewhere to reduce possible future porting efforts. > Changing the tmpdir static would be a smaller fix, but all the cwd code > would then remain. Yes, HotSpot never writes to cwd. I agree with Staffan, that looks for socket/door in cwd should be removed. -Dmitry -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From robert.ottenhag at oracle.com Mon Jan 30 09:41:27 2012 From: robert.ottenhag at oracle.com (Robert Ottenhag) Date: Mon, 30 Jan 2012 09:41:27 -0800 (PST) Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <59349013-5AC8-42F9-AE37-FEE60F6DC12C@oracle.com> References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com> <4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com> <4E51D843-A417-422C-9207-DF130D605DCC@oracle.com> <7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com> <63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com> <13F503FD-0B04-4383-BD98-7F2A4C518820@oracle.com> <4F25BF64.6070802@oracle.com> <20262.520.379715.707949@oracle.com> <4F265E5E.3010308@oracle.com> <4F266A4E.9030902@oracle.com> <59349013-5AC8-42F9-AE37-FEE60F6DC12C@oracle.com> Message-ID: <4ebe6472-1fe9-4196-8b63-a7096eacd3f7@default> Inline, > -----Original Message----- > From: Kelly O'Hair > Sent: Monday, January 30, 2012 6:27 PM > To: Robert Ottenhag > Cc: Dmitry Samersoff; serviceability-dev at openjdk.java.net; John Coomes; > build-dev at openjdk.java.net > Subject: Re: RFR: 7133124 Remove redundant packages from JAR command line > > Diverged and in transit to another planet. :^( > > A push to a shared repo without verifying it builds on all supported > platforms is risky behavior, and one that can > consume needless resources finding out it doesn't build, and more > importantly waste your co-worker's time undoing it. > We have the ability to prevent that, and we should. I totally agree. Passing suitable build and test requirements (check-in testing) is crucial (having 100+ developers waiting for a build fix is a _bad_ thing). > And the JDK is not just a VM, and cross compilation does not address > Windows or Solaris. It does not, but it can limit the number of build platforms that need to be maintained. See also my suggestion on an open JRPT queue and preconfigured virtual machines for build and test. Windows and Linux should cross build 32_to_64bit and 64_to_32bit, and Solaris can be helped by a virtual box installation of Solaris/{i586,x64}. > This is a much more difficult situation than most people think it is. > Yes we can change things to simplify it, make it better, but don't kid > yourself, this is more complex than most people think. True, but aiming for simpler and better is always beneficial. > > Anyone that hasn't built the entire JDK on Windows, successfully, should > try it. I have ;-) /Robert > > -kto > > On Jan 30, 2012, at 2:00 AM, Robert Ottenhag wrote: > > > Dmitry, > > > > I think this discussion diverged somewhat from the original topic, but I > do agree with you that we must also attack the problem on a process level. > > > > With the model you propose (and also the existing model) I would also > like to stress the need for continuous and automatic builds triggered by > incoming new changes compared to the last working change. Having that, it > is possible to update labels (tags) for "last_clean_build", > "last_nightly_build", etc. That way any build breakage would only be > visible at the tip. > > > > However, when submitting a new change care should be taken to do it > against a working tip, that it builds and tests correctly (personal check- > in testing). Actually, this is close to the model we had for the JRockit > source base. WLS also uses the model of sliding labels for > "last_clean_build" where developers most often only do partial builds > themselves. > > > > Regarding external committers, I think they need both the option of > building and testing locally, as well as access to an Open JDK specific > queue for build and test submissions. > > > > By making use of cross compilation and open tools it is possible to at > least verify that the product builds locally. Even better is to also > supply preconfigured VMs with the necessary standard build and test > environment (e.g. obsolete Solaris or Linux distros that we require). In > general, having a build and test setup that is automatically configurable > (including Windows) will help both internal and external developers (see > also the build-infra project). > > > > /Robert > > > > On 01/30/2012 10:09 AM, Dmitry Samersoff wrote: > >> John, > >> > >> Actually the goal of my letter is not to promote new integration > scheme. Just to remind that we need to put some efforts to internal > process review and optimization. > >> > >> But, see answers below (inline): > >> > >> Integration method I mentioned often used in open source projects, > >> because it doesn't require any special infrastructure for external > commiters. The only necessary thing to do safe commit is a write access to > integration (-gate) workspace. > >> > >> On 2012-01-30 06:35, John Coomes wrote: > >>>> We have chosen a model: > >>>> > >>>> build->test->integrate > >>>> > >>>> but we may consider different approach: > >>>> > >>>> integrate->build->test->[backout if necessary] > >>> > >>> In that model, you can never rely on the repository having any degree > >>> of stability. It may not even build at a given moment. > >> > >> What happens today if Developer A and Developer B changes the same line > of a source? > >> > >> What happens today if Developer A changes some_func() but Developer B > >> rely on some_func() ? > >> > >> We would get a fault *after* all integration tests and SQE file one > more nightly bug. To the time someone investigate it and give the fix, bad > code will be distributed to all dev workspaces. > >> > >> > >>>> Developer (A) integrate his changeset to an integration workspace > >>>> Bot takes snapshot and start building/testing > >>>> Developer (B) integrate his changeset to an integration workspace > >>>> Bot takes snapshot and start building/testing > >>>> > >>>> if Job A failed, bot lock integration ws, restore it to pre-A > state, > >>>> apply B-patch. unlock ws. > >>> > >>> Don't forget the trusting souls that pulled from the integration repo > >>> after A inflicted the breakage: they each waste time cleaning up a > >>> copy of A's mess. > >> > >> Nobody pulls from -gate repository today and nobody expected to do it. > >> -gate to ws merge continues as usual. > >> > >> To remove faulty changeset we need about fifteen minutes for whole jdk > at worst. > >> > >> -Dmitry > >> > >>> > >>> -John > >>> > >>>> On 2012-01-29 23:52, Kelly O'Hair wrote: > >>>>> > >>>>> On Jan 29, 2012, at 10:23 AM, Georges Saab wrote: > >>>>> > >>>>>>> > >>>>>>> I'm missing something. How can everybody using the exact same > system > >>>>>>> scale to 100's of developers? > >>>>>> > >>>>>> System = distributed build and test of OpenJDK > >>>>> > >>>>> Ah ha... I'm down in the trenches dealing with dozens of different > >>>>> OS's arch's variation machines. > >>>>> You are speaking to a higher level, I need to crawl out of the > basement. > >>>>> > >>>>>> > >>>>>> Developers send in jobs > >>>>>> Jobs are distribute across a pool of (HW/OS) resources > >>>>>> The resources may be divided into pools dedicated to different > tasks > >>>>>> (RE/checkin/perf/stress) > >>>>>> The pools are populated initially according to predictions of load > and > >>>>>> then increased/rebalanced according to data on actual usage > >>>>>> No assumptions made about what exists on the machine other than > HW/OS > >>>>>> The build and test tasks are self sufficient, i.e. bootstrap > themselves > >>>>>> The bootstrapping is done in the same way for different build and > test > >>>>>> tasks > >>>>> > >>>>> Understood. We have talked about this before. I have also been on > the > >>>>> search for the Holy Grail. ;^) > >>>>> This is why I keep working on JPRT. > >>>>> > >>>>>> > >>>>>> The only scaling aspect that seems at all challenging is that the > >>>>>> current checkin system is designed to serialize checkins in a way > that > >>>>>> apparently does not scale -- here there are some decisions to be > made > >>>>>> and tradeoffs but this is nothing new in the world of Open > community > >>>>>> development (or any large team development for that matter) > >>>>> > >>>>> The serialize checkins issue can be minimized some by using > distributed > >>>>> SCMs (Mercurial, Git, etc) > >>>>> and using separate forests (fewer developers per source repository > means > >>>>> fewer merge/sync issues) > >>>>> and having an integrator merge into a master. This has proven to > work in > >>>>> many situations but it > >>>>> also creates delivery to master delays, especially if the > integration > >>>>> process is too heavyweight. > >>>>> > >>>>> The JDK projects has been doing this for a long time, I'm sure many > >>>>> people have opinions as to how > >>>>> successful it is or isn't. > >>>>> > >>>>> It is my opinion that merges/syncs are some of the most dangerous > things > >>>>> you can do to a source base, > >>>>> and anything we can do to avoid them is usually goodness, I don't > think > >>>>> you should scale this without some > >>>>> very great care. > >>>>> > >>>>>> > >>>>>>> > >>>>>>> And that one system will naturally change over time too, so unless > >>>>>>> you are able to prevent all change > >>>>>>> to a system (impossible with security updates etc) every use of > that > >>>>>>> 'same system' will be different. > >>>>>> > >>>>>> Yes, but it is possible to control this update and have a staging > >>>>>> environment so you know that a HW/OS update will not break the > >>>>>> existing successful build when rolled out to the build/test farm. > >>>>> > >>>>> Possible but not always easy. The auto updating of everything has > >>>>> increased significantly over the years, > >>>>> making it harder to control completely. > >>>>> > >>>>> I've been doing this build&test stuff long enough to never expect > >>>>> anything to be 100% reliable. > >>>>> Hardware fails, software updates regress functionality, networks > become > >>>>> unreliable, humans trip over > >>>>> power cords, virus scanners break things, etc. It just happens, and > >>>>> often, it's not very predictable or reproducible. > >>>>> You can do lots of things to minimize issues, but at some point you > just > >>>>> have to accept a few risks because > >>>>> the alternative just isn't feasible or just can't happen with the > >>>>> resources we have. > >>>>> > >>>>> -kto > >>>>> > >>>>> > >>>> > >>>> > >>>> -- > >>>> Dmitry Samersoff > >>>> Java Hotspot development team, SPB04 > >>>> * There will come soft rains ... > >> > >> > > > > > > -- > > Oracle > > Robert Ottenhag | Senior Member of Technical Staff > > Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161 > > Oracle Java HotSpot Virtual Machine > > ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm > > > > Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254- > 6746 > > > > Green Oracle > > > > Oracle is committed to developing practices and products that help > protect the environment > > -- > > > From jonathan.gibbons at oracle.com Mon Jan 30 10:02:40 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 30 Jan 2012 10:02:40 -0800 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <4ebe6472-1fe9-4196-8b63-a7096eacd3f7@default> References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com> <4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com> <4E51D843-A417-422C-9207-DF130D605DCC@oracle.com> <7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com> <63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com> <13F503FD-0B04-4383-BD98-7F2A4C518820@oracle.com> <4F25BF64.6070802@oracle.com> <20262.520.379715.707949@oracle.com> <4F265E5E.3010308@oracle.com> <4F266A4E.9030902@oracle.com> <59349013-5AC8-42F9-AE37-FEE60F6DC12C@oracle.com> <4ebe6472-1fe9-4196-8b63-a7096eacd3f7@default> Message-ID: <4F26DB40.9090300@oracle.com> On 01/30/2012 09:41 AM, Robert Ottenhag wrote: >> > A push to a shared repo without verifying it builds on all supported >> > platforms is risky behavior, and one that can >> > consume needless resources finding out it doesn't build, and more >> > importantly waste your co-worker's time undoing it. >> > We have the ability to prevent that, and we should. > I totally agree. Passing suitable build and test requirements (check-in testing) is crucial (having 100+ developers waiting for a build fix is a_bad_ thing). > We need to be careful here. We have the ability to totally overload any reasonable build system, and going through a full build and test for what are sometimes small changes may be impractical (having 100+ developers waiting for the build queue is also a _bad_ thing.) As Joe Darcy often points out, we need to be careful that we are not so afraid of doing anything bad that we prevent anything good from happening. Note, I am /not/ saying we don't need a good build and test system. We do. We just need to be careful how we mandate its use. -- Jon From staffan.larsen at oracle.com Mon Jan 30 10:40:18 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 30 Jan 2012 19:40:18 +0100 Subject: Request for Review: 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms In-Reply-To: <4F26CDE4.9010409@oracle.com> References: <83B4C4D0-3005-442A-9D5D-274AA97AF1E0@oracle.com> <4F26CDE4.9010409@oracle.com> Message-ID: <4EA1D833-9895-4B4F-8897-CAF7E186BC43@oracle.com> On 30 jan 2012, at 18:05, Daniel D. Daugherty wrote: >> The same fix will be needed in BsdVirtualMachine.java eventually. > > Please fix BsdVirtualMachine.java at the same time. Yeah, I'd love to, but it's still in the osx-port repo and this fixes for jdk8 (and then back port to jdk7). I'll file a separate bug for BsdVirtualMachine.java and fix that, too. /Staffan From daniel.daugherty at oracle.com Mon Jan 30 10:46:04 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 30 Jan 2012 11:46:04 -0700 Subject: Request for Review: 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms In-Reply-To: <4EA1D833-9895-4B4F-8897-CAF7E186BC43@oracle.com> References: <83B4C4D0-3005-442A-9D5D-274AA97AF1E0@oracle.com> <4F26CDE4.9010409@oracle.com> <4EA1D833-9895-4B4F-8897-CAF7E186BC43@oracle.com> Message-ID: <4F26E56C.5010107@oracle.com> On 1/30/12 11:40 AM, Staffan Larsen wrote: > On 30 jan 2012, at 18:05, Daniel D. Daugherty wrote: > >>> The same fix will be needed in BsdVirtualMachine.java eventually. >> Please fix BsdVirtualMachine.java at the same time. > Yeah, I'd love to, but it's still in the osx-port repo I keep forgetting that the JDK-side is still separate and that HSX is merged... one day we'll all be in the same place... > and this fixes for jdk8 (and then back port to jdk7). I'll file a separate bug for BsdVirtualMachine.java and fix that, too. Sounds like a good plan. Dan From kelly.ohair at oracle.com Mon Jan 30 15:41:23 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 30 Jan 2012 15:41:23 -0800 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <4F26DB40.9090300@oracle.com> References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com> <4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com> <4E51D843-A417-422C-9207-DF130D605DCC@oracle.com> <7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com> <63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com> <13F503FD-0B04-4383-BD98-7F2A4C518820@oracle.com> <4F25BF64.6070802@oracle.com> <20262.520.379715.707949@oracle.com> <4F265E5E.3010308@oracle.com> <4F266A4E.9030902@oracle.com> <59349013-5AC8-42F9-AE37-FEE60F6DC12C@oracle.com> <4ebe6472-1fe9-4196-8b63-a7096eacd3f7@default> <4F26DB40.9090300@oracle.com> Message-ID: On Jan 30, 2012, at 10:02 AM, Jonathan Gibbons wrote: > On 01/30/2012 09:41 AM, Robert Ottenhag wrote: >>> > A push to a shared repo without verifying it builds on all supported >>> > platforms is risky behavior, and one that can >>> > consume needless resources finding out it doesn't build, and more >>> > importantly waste your co-worker's time undoing it. >>> > We have the ability to prevent that, and we should. >> I totally agree. Passing suitable build and test requirements (check-in testing) is crucial (having 100+ developers waiting for a build fix is a_bad_ thing). >> > > We need to be careful here. We have the ability to totally overload any reasonable build system, and going through a full build and test for what are sometimes small changes may be impractical (having 100+ developers waiting for the build queue is also a _bad_ thing.) > > As Joe Darcy often points out, we need to be careful that we are not so afraid of doing anything bad that we prevent anything good from happening. > > Note, I am /not/ saying we don't need a good build and test system. We do. We just need to be careful how we mandate its use. > > -- Jon Totally agree Jon, it's a balancing act, we do what makes sense and what gives us the best chance of keeping poison or broken changesets from getting into circulation. We cannot run all the tests all the time. I also think that extremely low or no risk changes need not follow this rule, but the problem is getting people to agree with 'no risk changes' are. I've seen enough 'low risk' changes bring the house down that I'm on the paranoid side. :^( -kto From jonathan.gibbons at oracle.com Mon Jan 30 15:43:27 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 30 Jan 2012 15:43:27 -0800 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com> <4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com> <4E51D843-A417-422C-9207-DF130D605DCC@oracle.com> <7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com> <63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com> <13F503FD-0B04-4383-BD98-7F2A4C518820@oracle.com> <4F25BF64.6070802@oracle.com> <20262.520.379715.707949@oracle.com> <4F265E5E.3010308@oracle.com> <4F266A4E.9030902@oracle.com> <59349013-5AC8-42F9-AE37-FEE60F6DC12C@oracle.com> <4ebe6472-1fe9-4196-8b63-a7096eacd3f7@default> <4F26DB40.9090300@oracle.com> Message-ID: <4F272B1F.3090904@oracle.com> On 01/30/2012 03:41 PM, Kelly O'Hair wrote: > I also think that extremely low or no risk changes need not follow this rule, but the problem is getting people > to agree with 'no risk changes' are. I've seen enough 'low risk' changes bring the house down that I'm on the > paranoid side. :^( How does the saying go: Just because you're paranoid doesn't mean that folk won't break the build? ;-) -- Jon From david.holmes at oracle.com Mon Jan 30 16:23:06 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 31 Jan 2012 10:23:06 +1000 Subject: Request for Review: 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms In-Reply-To: <4F26D325.1000404@oracle.com> References: <83B4C4D0-3005-442A-9D5D-274AA97AF1E0@oracle.com> <4F267DCC.2090002@oracle.com> <4F26D325.1000404@oracle.com> Message-ID: <4F27346A.1080302@oracle.com> On 31/01/2012 3:28 AM, Dmitry Samersoff wrote: > On 2012-01-30 16:28, Staffan Larsen wrote: >>> 2. If you decide to hardcode "/tmp" please, create a global constant >>> for it. >> >> I don't agree that this would make the code easier to read or maintain. >> I should, however, include a comment saying that the file is always in >> /tmp regardless of the value of java.io.tmpdir. Staffan: I still think changing the static field tmpdir to refer to "/tmp" is cleaner then putting "/tmp" in all the use-sites. > /tmp is common but not mandatory, especially if we speak about embedded > systems. Dmitry: The point is that the VM will always put the file in /tmp. That's wrong but the issue here is making the management Java code match the hotspot code. > Native code should use P_tmpdir constant from stdio.h rather than > hardcode "/tmp". > > As we can't access it from java I recommend to create a global constant > somewhere to reduce possible future porting efforts. > > >> Changing the tmpdir static would be a smaller fix, but all the cwd code >> would then remain. Yes, HotSpot never writes to cwd. > > I agree with Staffan, that looks for socket/door in cwd should be removed. Ok, if it is never needed then remove it. David > -Dmitry > From david.holmes at oracle.com Mon Jan 30 16:57:18 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 31 Jan 2012 10:57:18 +1000 Subject: Patch to fix build breakage with GCC 4.7 In-Reply-To: <20120130152052.GE3179@redhat.com> References: <20120130152052.GE3179@redhat.com> Message-ID: <4F273C6E.30801@oracle.com> Hi Deepak, The primary change here is a build change so I've cc'ed build-dev. The majority of the changes are to JVMTI demo files hence I've cc'd serviceability-dev. I think JDK8-dev doesn't need to be included now so I've bcc'd it. While gcc compilation on sparc is rare I'm not sure that simply deleting the sparc-only option unconditionally is the right thing to do. David On 31/01/2012 1:20 AM, Deepak Bhole wrote: > Hi, > > JDK builds currently fail with GCC 4.7 due to its stricter option > checking. > > GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not. Certain > files in JDK supply the -mimpure-text option to GCC. This option is only > valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during build > on Linux (I suppose . > > This patch removes the option: > http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00 > > 1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html > 2: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html > > If OK for push, please feel free to do so (I don't have commit access). > > Cheers, > Deepak From kelly.ohair at oracle.com Mon Jan 30 17:23:06 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 30 Jan 2012 17:23:06 -0800 Subject: RFR: 7133124 Remove redundant packages from JAR command line In-Reply-To: <4ebe6472-1fe9-4196-8b63-a7096eacd3f7@default> References: <4F21206A.1040907@oracle.com> <4F213E19.90508@oracle.com> <4F2140E0.5040802@oracle.com> <4F21CBF2.1040407@oracle.com> <4E51D843-A417-422C-9207-DF130D605DCC@oracle.com> <7CFD9D69-4823-4CEF-AB34-CC20321951FB@oracle.com> <63282503-E530-4B4C-B0DF-B2B7A64C5F7D@oracle.com> <13F503FD-0B04-4383-BD98-7F2A4C518820@oracle.com> <4F25BF64.6070802@oracle.com> <20262.520.379715.707949@oracle.com> <4F265E5E.3010308@oracle.com> <4F266A4E.9030902@oracle.com> <59349013-5AC8-42F9-AE37-FEE60F6DC12C@oracle.com> <4ebe6472-1fe9-4196-8b63-a7096eacd3f7@default> Message-ID: On Jan 30, 2012, at 9:41 AM, Robert Ottenhag wrote: > Inline, > >> -----Original Message----- >> From: Kelly O'Hair >> Sent: Monday, January 30, 2012 6:27 PM >> To: Robert Ottenhag >> Cc: Dmitry Samersoff; serviceability-dev at openjdk.java.net; John Coomes; >> build-dev at openjdk.java.net >> Subject: Re: RFR: 7133124 Remove redundant packages from JAR command line >> >> Diverged and in transit to another planet. :^( >> >> A push to a shared repo without verifying it builds on all supported >> platforms is risky behavior, and one that can >> consume needless resources finding out it doesn't build, and more >> importantly waste your co-worker's time undoing it. >> We have the ability to prevent that, and we should. > > I totally agree. Passing suitable build and test requirements (check-in testing) is crucial (having 100+ developers waiting for a build fix is a _bad_ thing). > >> And the JDK is not just a VM, and cross compilation does not address >> Windows or Solaris. > > It does not, but it can limit the number of build platforms that need to be maintained. See also my suggestion on an open JRPT queue and preconfigured virtual machines for build and test. Windows and Linux should cross build 32_to_64bit and 64_to_32bit, and Solaris can be helped by a virtual box installation of Solaris/{i586,x64}. 32 to 64 may be a problem. As much as I have tried to keep the build just a build, we continue to run what we build in order to create the build. This will happen more going forward unfortunately, impacting our ability to cross compile on platforms that can't run what you are building. The current thinking is that an initial build for the host would be done first, and then that would be used to create the cross compiled build. But that's all up in the air, depends on when the jigsaw and jdk modularization work starts showing up in jdk8. In general Solaris has always been an x64 system where you build both. There really is no Solaris 32bit systems used anymore. I'd like to change it so that there is just one pass, and both 32bit and 64bit native pieces are created at the same time. Dito for Linux and Windows, e.g. you just build Windows, or Linux, or Solaris. But if you are limited, i.e. running on a 32bit system, you only build 32bit. I'm of the opinion that most desktop systems will be 64bit, or should be. > >> This is a much more difficult situation than most people think it is. >> Yes we can change things to simplify it, make it better, but don't kid >> yourself, this is more complex than most people think. > > True, but aiming for simpler and better is always beneficial. Simpler is better, I agree. > >> >> Anyone that hasn't built the entire JDK on Windows, successfully, should >> try it. > > I have ;-) I did not know you had the jdk windows merit badge, congrads, or is it 'my sympathies'. ;^) -kto > > /Robert > >> >> -kto >> >> On Jan 30, 2012, at 2:00 AM, Robert Ottenhag wrote: >> >>> Dmitry, >>> >>> I think this discussion diverged somewhat from the original topic, but I >> do agree with you that we must also attack the problem on a process level. >>> >>> With the model you propose (and also the existing model) I would also >> like to stress the need for continuous and automatic builds triggered by >> incoming new changes compared to the last working change. Having that, it >> is possible to update labels (tags) for "last_clean_build", >> "last_nightly_build", etc. That way any build breakage would only be >> visible at the tip. >>> >>> However, when submitting a new change care should be taken to do it >> against a working tip, that it builds and tests correctly (personal check- >> in testing). Actually, this is close to the model we had for the JRockit >> source base. WLS also uses the model of sliding labels for >> "last_clean_build" where developers most often only do partial builds >> themselves. >>> >>> Regarding external committers, I think they need both the option of >> building and testing locally, as well as access to an Open JDK specific >> queue for build and test submissions. >>> >>> By making use of cross compilation and open tools it is possible to at >> least verify that the product builds locally. Even better is to also >> supply preconfigured VMs with the necessary standard build and test >> environment (e.g. obsolete Solaris or Linux distros that we require). In >> general, having a build and test setup that is automatically configurable >> (including Windows) will help both internal and external developers (see >> also the build-infra project). >>> >>> /Robert >>> >>> On 01/30/2012 10:09 AM, Dmitry Samersoff wrote: >>>> John, >>>> >>>> Actually the goal of my letter is not to promote new integration >> scheme. Just to remind that we need to put some efforts to internal >> process review and optimization. >>>> >>>> But, see answers below (inline): >>>> >>>> Integration method I mentioned often used in open source projects, >>>> because it doesn't require any special infrastructure for external >> commiters. The only necessary thing to do safe commit is a write access to >> integration (-gate) workspace. >>>> >>>> On 2012-01-30 06:35, John Coomes wrote: >>>>>> We have chosen a model: >>>>>> >>>>>> build->test->integrate >>>>>> >>>>>> but we may consider different approach: >>>>>> >>>>>> integrate->build->test->[backout if necessary] >>>>> >>>>> In that model, you can never rely on the repository having any degree >>>>> of stability. It may not even build at a given moment. >>>> >>>> What happens today if Developer A and Developer B changes the same line >> of a source? >>>> >>>> What happens today if Developer A changes some_func() but Developer B >>>> rely on some_func() ? >>>> >>>> We would get a fault *after* all integration tests and SQE file one >> more nightly bug. To the time someone investigate it and give the fix, bad >> code will be distributed to all dev workspaces. >>>> >>>> >>>>>> Developer (A) integrate his changeset to an integration workspace >>>>>> Bot takes snapshot and start building/testing >>>>>> Developer (B) integrate his changeset to an integration workspace >>>>>> Bot takes snapshot and start building/testing >>>>>> >>>>>> if Job A failed, bot lock integration ws, restore it to pre-A >> state, >>>>>> apply B-patch. unlock ws. >>>>> >>>>> Don't forget the trusting souls that pulled from the integration repo >>>>> after A inflicted the breakage: they each waste time cleaning up a >>>>> copy of A's mess. >>>> >>>> Nobody pulls from -gate repository today and nobody expected to do it. >>>> -gate to ws merge continues as usual. >>>> >>>> To remove faulty changeset we need about fifteen minutes for whole jdk >> at worst. >>>> >>>> -Dmitry >>>> >>>>> >>>>> -John >>>>> >>>>>> On 2012-01-29 23:52, Kelly O'Hair wrote: >>>>>>> >>>>>>> On Jan 29, 2012, at 10:23 AM, Georges Saab wrote: >>>>>>> >>>>>>>>> >>>>>>>>> I'm missing something. How can everybody using the exact same >> system >>>>>>>>> scale to 100's of developers? >>>>>>>> >>>>>>>> System = distributed build and test of OpenJDK >>>>>>> >>>>>>> Ah ha... I'm down in the trenches dealing with dozens of different >>>>>>> OS's arch's variation machines. >>>>>>> You are speaking to a higher level, I need to crawl out of the >> basement. >>>>>>> >>>>>>>> >>>>>>>> Developers send in jobs >>>>>>>> Jobs are distribute across a pool of (HW/OS) resources >>>>>>>> The resources may be divided into pools dedicated to different >> tasks >>>>>>>> (RE/checkin/perf/stress) >>>>>>>> The pools are populated initially according to predictions of load >> and >>>>>>>> then increased/rebalanced according to data on actual usage >>>>>>>> No assumptions made about what exists on the machine other than >> HW/OS >>>>>>>> The build and test tasks are self sufficient, i.e. bootstrap >> themselves >>>>>>>> The bootstrapping is done in the same way for different build and >> test >>>>>>>> tasks >>>>>>> >>>>>>> Understood. We have talked about this before. I have also been on >> the >>>>>>> search for the Holy Grail. ;^) >>>>>>> This is why I keep working on JPRT. >>>>>>> >>>>>>>> >>>>>>>> The only scaling aspect that seems at all challenging is that the >>>>>>>> current checkin system is designed to serialize checkins in a way >> that >>>>>>>> apparently does not scale -- here there are some decisions to be >> made >>>>>>>> and tradeoffs but this is nothing new in the world of Open >> community >>>>>>>> development (or any large team development for that matter) >>>>>>> >>>>>>> The serialize checkins issue can be minimized some by using >> distributed >>>>>>> SCMs (Mercurial, Git, etc) >>>>>>> and using separate forests (fewer developers per source repository >> means >>>>>>> fewer merge/sync issues) >>>>>>> and having an integrator merge into a master. This has proven to >> work in >>>>>>> many situations but it >>>>>>> also creates delivery to master delays, especially if the >> integration >>>>>>> process is too heavyweight. >>>>>>> >>>>>>> The JDK projects has been doing this for a long time, I'm sure many >>>>>>> people have opinions as to how >>>>>>> successful it is or isn't. >>>>>>> >>>>>>> It is my opinion that merges/syncs are some of the most dangerous >> things >>>>>>> you can do to a source base, >>>>>>> and anything we can do to avoid them is usually goodness, I don't >> think >>>>>>> you should scale this without some >>>>>>> very great care. >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> And that one system will naturally change over time too, so unless >>>>>>>>> you are able to prevent all change >>>>>>>>> to a system (impossible with security updates etc) every use of >> that >>>>>>>>> 'same system' will be different. >>>>>>>> >>>>>>>> Yes, but it is possible to control this update and have a staging >>>>>>>> environment so you know that a HW/OS update will not break the >>>>>>>> existing successful build when rolled out to the build/test farm. >>>>>>> >>>>>>> Possible but not always easy. The auto updating of everything has >>>>>>> increased significantly over the years, >>>>>>> making it harder to control completely. >>>>>>> >>>>>>> I've been doing this build&test stuff long enough to never expect >>>>>>> anything to be 100% reliable. >>>>>>> Hardware fails, software updates regress functionality, networks >> become >>>>>>> unreliable, humans trip over >>>>>>> power cords, virus scanners break things, etc. It just happens, and >>>>>>> often, it's not very predictable or reproducible. >>>>>>> You can do lots of things to minimize issues, but at some point you >> just >>>>>>> have to accept a few risks because >>>>>>> the alternative just isn't feasible or just can't happen with the >>>>>>> resources we have. >>>>>>> >>>>>>> -kto >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Dmitry Samersoff >>>>>> Java Hotspot development team, SPB04 >>>>>> * There will come soft rains ... >>>> >>>> >>> >>> >>> -- >>> Oracle >>> Robert Ottenhag | Senior Member of Technical Staff >>> Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161 >>> Oracle Java HotSpot Virtual Machine >>> ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm >>> >>> Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254- >> 6746 >>> >>> Green Oracle >>> >>> Oracle is committed to developing practices and products that help >> protect the environment >>> -- >>> >> From kelly.ohair at oracle.com Mon Jan 30 17:29:28 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 30 Jan 2012 17:29:28 -0800 Subject: Patch to fix build breakage with GCC 4.7 In-Reply-To: <4F273C6E.30801@oracle.com> References: <20120130152052.GE3179@redhat.com> <4F273C6E.30801@oracle.com> Message-ID: <52B55BCB-C670-4F08-8D12-DE6FC4A69E95@oracle.com> This change looks fine to me. It would be ok with me for this change to be pushed into the jdk8/build forest. Once there, I can do a JPRT run to verify it, but I really don't seen any issue here. -kto On Jan 30, 2012, at 4:57 PM, David Holmes wrote: > Hi Deepak, > > The primary change here is a build change so I've cc'ed build-dev. > > The majority of the changes are to JVMTI demo files hence I've cc'd serviceability-dev. > > I think JDK8-dev doesn't need to be included now so I've bcc'd it. > > While gcc compilation on sparc is rare I'm not sure that simply deleting the sparc-only option unconditionally is the right thing to do. > > David > > On 31/01/2012 1:20 AM, Deepak Bhole wrote: >> Hi, >> >> JDK builds currently fail with GCC 4.7 due to its stricter option >> checking. >> >> GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not. Certain >> files in JDK supply the -mimpure-text option to GCC. This option is only >> valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during build >> on Linux (I suppose . >> >> This patch removes the option: >> http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00 >> >> 1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html >> 2: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html >> >> If OK for push, please feel free to do so (I don't have commit access). >> >> Cheers, >> Deepak From david.holmes at oracle.com Mon Jan 30 18:49:45 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 31 Jan 2012 12:49:45 +1000 Subject: Patch to fix build breakage with GCC 4.7 In-Reply-To: <20120131023642.GO16474@redhat.com> References: <20120130152052.GE3179@redhat.com> <4F273C6E.30801@oracle.com> <20120131023642.GO16474@redhat.com> Message-ID: <4F2756C9.4000304@oracle.com> On 31/01/2012 12:36 PM, Deepak Bhole wrote: > * David Holmes [2012-01-30 19:57]: >> While gcc compilation on sparc is rare I'm not sure that simply >> deleting the sparc-only option unconditionally is the right thing to >> do. >> > > I thought about that too. But I was unable to find info on OpenJDK + > SPARC + Linux. Is that combination even supported? The README doesn't > list it: > http://hg.openjdk.java.net/jdk6/jdk6/raw-file/tip/README-builds.html#MBE Linux-sparc is not one of Oracle's supported OpenJDK platforms. However AFAIK there are people in the community building OpenJDK on Linux-sparc using the Zero interpreter. I don't know if this would affect them but it still seems to me that we should be careful not to break other people's builds. David ----- > The option seemed more like a relic from Solaris + SPARC config rather > than a requirement for Linux + SPARC. > Cheers, > Deepak > >> David >> >> On 31/01/2012 1:20 AM, Deepak Bhole wrote: >>> Hi, >>> >>> JDK builds currently fail with GCC 4.7 due to its stricter option >>> checking. >>> >>> GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not. Certain >>> files in JDK supply the -mimpure-text option to GCC. This option is only >>> valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during build >>> on Linux (I suppose . >>> >>> This patch removes the option: >>> http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00 >>> >>> 1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html >>> 2: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html >>> >>> If OK for push, please feel free to do so (I don't have commit access). >>> >>> Cheers, >>> Deepak From staffan.larsen at oracle.com Tue Jan 31 00:10:31 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 31 Jan 2012 09:10:31 +0100 Subject: Request for Review: 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms In-Reply-To: <4F27346A.1080302@oracle.com> References: <83B4C4D0-3005-442A-9D5D-274AA97AF1E0@oracle.com> <4F267DCC.2090002@oracle.com> <4F26D325.1000404@oracle.com> <4F27346A.1080302@oracle.com> Message-ID: <71878A35-A098-4A0E-A34D-803606FFF10A@oracle.com> Moving "/tmp" to a static field, made it easier to write a comment explaining the rationale as well. Updated webrev: http://cr.openjdk.java.net/~sla/7132199/webrev.02/ Thanks, /Staffan On 31 jan 2012, at 01:23, David Holmes wrote: > On 31/01/2012 3:28 AM, Dmitry Samersoff wrote: >> On 2012-01-30 16:28, Staffan Larsen wrote: >>>> 2. If you decide to hardcode "/tmp" please, create a global constant >>>> for it. >>> >>> I don't agree that this would make the code easier to read or maintain. >>> I should, however, include a comment saying that the file is always in >>> /tmp regardless of the value of java.io.tmpdir. > > Staffan: I still think changing the static field tmpdir to refer to "/tmp" is cleaner then putting "/tmp" in all the use-sites. > >> /tmp is common but not mandatory, especially if we speak about embedded >> systems. > > Dmitry: The point is that the VM will always put the file in /tmp. That's wrong but the issue here is making the management Java code match the hotspot code. > >> Native code should use P_tmpdir constant from stdio.h rather than >> hardcode "/tmp". >> >> As we can't access it from java I recommend to create a global constant >> somewhere to reduce possible future porting efforts. >> >> >>> Changing the tmpdir static would be a smaller fix, but all the cwd code >>> would then remain. Yes, HotSpot never writes to cwd. >> >> I agree with Staffan, that looks for socket/door in cwd should be removed. > > Ok, if it is never needed then remove it. > > David > >> -Dmitry >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120131/cf86cca0/attachment.html From Dmitry.Samersoff at oracle.com Tue Jan 31 00:12:42 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 31 Jan 2012 12:12:42 +0400 Subject: Request for Review: 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms In-Reply-To: <4F27346A.1080302@oracle.com> References: <83B4C4D0-3005-442A-9D5D-274AA97AF1E0@oracle.com> <4F267DCC.2090002@oracle.com> <4F26D325.1000404@oracle.com> <4F27346A.1080302@oracle.com> Message-ID: <4F27A27A.5070207@oracle.com> David, On 2012-01-31 04:23, David Holmes wrote: > Dmitry: The point is that the VM will always put the file in /tmp. > That's wrong but the issue here is making the management Java code match > the hotspot code. Yes I get it. I'm asking about final String hotpsotTmpDir="/tmp"; instead of copy-pasting string constant across a code (at least in two places) -Dmitry -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From Dmitry.Samersoff at oracle.com Tue Jan 31 00:17:01 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 31 Jan 2012 12:17:01 +0400 Subject: Request for Review: 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms In-Reply-To: <71878A35-A098-4A0E-A34D-803606FFF10A@oracle.com> References: <83B4C4D0-3005-442A-9D5D-274AA97AF1E0@oracle.com> <4F267DCC.2090002@oracle.com> <4F26D325.1000404@oracle.com> <4F27346A.1080302@oracle.com> <71878A35-A098-4A0E-A34D-803606FFF10A@oracle.com> Message-ID: <4F27A37D.8020808@oracle.com> Staffan, Excellent, thank you! Looks good to me. -Dmitry On 2012-01-31 12:10, Staffan Larsen wrote: > Moving "/tmp" to a static field, made it easier to write a comment > explaining the rationale as well. > > Updated webrev: http://cr.openjdk.java.net/~sla/7132199/webrev.02/ > > Thanks, > /Staffan > > On 31 jan 2012, at 01:23, David Holmes wrote: > >> On 31/01/2012 3:28 AM, Dmitry Samersoff wrote: >>> On 2012-01-30 16:28, Staffan Larsen wrote: >>>>> 2. If you decide to hardcode "/tmp" please, create a global constant >>>>> for it. >>>> >>>> I don't agree that this would make the code easier to read or maintain. >>>> I should, however, include a comment saying that the file is always in >>>> /tmp regardless of the value of java.io.tmpdir. >> >> Staffan: I still think changing the static field tmpdir to refer to >> "/tmp" is cleaner then putting "/tmp" in all the use-sites. >> >>> /tmp is common but not mandatory, especially if we speak about embedded >>> systems. >> >> Dmitry: The point is that the VM will always put the file in /tmp. >> That's wrong but the issue here is making the management Java code >> match the hotspot code. >> >>> Native code should use P_tmpdir constant from stdio.h rather than >>> hardcode "/tmp". >>> >>> As we can't access it from java I recommend to create a global constant >>> somewhere to reduce possible future porting efforts. >>> >>> >>>> Changing the tmpdir static would be a smaller fix, but all the cwd code >>>> would then remain. Yes, HotSpot never writes to cwd. >>> >>> I agree with Staffan, that looks for socket/door in cwd should be >>> removed. >> >> Ok, if it is never needed then remove it. >> >> David >> >>> -Dmitry >>> > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From david.holmes at oracle.com Tue Jan 31 00:32:28 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 31 Jan 2012 18:32:28 +1000 Subject: Request for Review: 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms In-Reply-To: <4F27A37D.8020808@oracle.com> References: <83B4C4D0-3005-442A-9D5D-274AA97AF1E0@oracle.com> <4F267DCC.2090002@oracle.com> <4F26D325.1000404@oracle.com> <4F27346A.1080302@oracle.com> <71878A35-A098-4A0E-A34D-803606FFF10A@oracle.com> <4F27A37D.8020808@oracle.com> Message-ID: <4F27A71C.5050700@oracle.com> +1 Thanks, David On 31/01/2012 6:17 PM, Dmitry Samersoff wrote: > Staffan, > > Excellent, thank you! > > Looks good to me. > > -Dmitry > > On 2012-01-31 12:10, Staffan Larsen wrote: >> Moving "/tmp" to a static field, made it easier to write a comment >> explaining the rationale as well. >> >> Updated webrev: http://cr.openjdk.java.net/~sla/7132199/webrev.02/ >> >> Thanks, >> /Staffan >> >> On 31 jan 2012, at 01:23, David Holmes wrote: >> >>> On 31/01/2012 3:28 AM, Dmitry Samersoff wrote: >>>> On 2012-01-30 16:28, Staffan Larsen wrote: >>>>>> 2. If you decide to hardcode "/tmp" please, create a global constant >>>>>> for it. >>>>> >>>>> I don't agree that this would make the code easier to read or maintain. >>>>> I should, however, include a comment saying that the file is always in >>>>> /tmp regardless of the value of java.io.tmpdir. >>> >>> Staffan: I still think changing the static field tmpdir to refer to >>> "/tmp" is cleaner then putting "/tmp" in all the use-sites. >>> >>>> /tmp is common but not mandatory, especially if we speak about embedded >>>> systems. >>> >>> Dmitry: The point is that the VM will always put the file in /tmp. >>> That's wrong but the issue here is making the management Java code >>> match the hotspot code. >>> >>>> Native code should use P_tmpdir constant from stdio.h rather than >>>> hardcode "/tmp". >>>> >>>> As we can't access it from java I recommend to create a global constant >>>> somewhere to reduce possible future porting efforts. >>>> >>>> >>>>> Changing the tmpdir static would be a smaller fix, but all the cwd code >>>>> would then remain. Yes, HotSpot never writes to cwd. >>>> >>>> I agree with Staffan, that looks for socket/door in cwd should be >>>> removed. >>> >>> Ok, if it is never needed then remove it. >>> >>> David >>> >>>> -Dmitry >>>> >> > > From neil.richards at ngmr.net Tue Jan 31 01:51:24 2012 From: neil.richards at ngmr.net (neil.richards at ngmr.net) Date: Tue, 31 Jan 2012 09:51:24 +0000 Subject: hg: jdk8/tl/jdk: 7123229: (coll) EnumMap.containsValue(null) returns true Message-ID: <20120131095153.AD178472A8@hg.openjdk.java.net> Changeset: 863a20b0bf08 Author: ngmr Date: 2012-01-10 00:07 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/863a20b0bf08 7123229: (coll) EnumMap.containsValue(null) returns true Summary: java.util.EnumMap.NULL equals() must only be true for itself Reviewed-by: alanb, mduigou Contributed-by: Neil Richards ! src/share/classes/java/util/EnumMap.java + test/java/util/EnumMap/UniqueNullValue.java From suenaga.yasumasa at oss.ntt.co.jp Tue Jan 31 02:32:05 2012 From: suenaga.yasumasa at oss.ntt.co.jp (Yasumasa Suenaga) Date: Tue, 31 Jan 2012 19:32:05 +0900 Subject: Can't attach core image through SA tools Message-ID: <4F27C325.8040501@oss.ntt.co.jp> Hi, I've tried attach a corefile with jstack. However, I couldn't. I guess that this problem is caused by incorrect address mapping of libsaproc.so . I've made a patch which is attached this email. And I've been able to get correct thread stack with jstack. So, I'd like to contribute this patch, and I'd like to backport to JDK6/7 . Could you help me? ------ details ------ I got these messages then I ran jstack with LIBSAPROC_DEBUG environment variable: /*************************/ : libsaproc DEBUG: reading library /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.1.x86_64/jre/lib/amd64/server/libjvm.so @ 0x7f53b455a000 [ 0x7f53b455a000 ] libsaproc DEBUG: ---- sorted virtual address map ---- : libsaproc DEBUG: base = 0x7f53b455a000 size = 9993772 libsaproc DEBUG: base = 0x7f53b455a000 size = 4096 : libsaproc DEBUG: can't locate map_info at 0x7f53b4dbe000 libsaproc DEBUG: core read failed for 4096 byte(s) @ 0x7f53b4dbe000 (4096 more bytes) : /*************************/ libsaproc.so tries to read libjvm.so library address, and it is duplicated. I read Linux kernel source code of function of core dump, and I found these comment: source code: kernel-3.2.1-3.fc16.src.rpm (Fedora16 x86_64) in fs/binfmt_elf.c: static unsigned long vma_dump_size(struct vm_area_struct *vma, unsigned long mm_flags) ---------------------- /* * If this looks like the beginning of a DSO or executable mapping, * check for an ELF header. If we find one, dump the first page to * aid in determining what was mapped here. */ ---------------------- In fact, core image has executable load section which size is 1 page(0x1000) ---------------------- LOAD 0x0000000005173000 0x00007f53b455a000 0x0000000000000000 0x0000000000001000 0x0000000000988000 R E 1000 ---------------------- So, we must think these case when we attach core image. I modified "read_lib_segments()" in hotspot/agent/src/os/linux/ps_core.c to overwrite correct address in shared library . Please check it. Thanks, Yasumasa -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: address_mapping.patch Url: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120131/aad38568/address_mapping.patch From david.holmes at oracle.com Tue Jan 31 02:58:57 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 31 Jan 2012 20:58:57 +1000 Subject: Can't attach core image through SA tools In-Reply-To: <4F27C325.8040501@oss.ntt.co.jp> References: <4F27C325.8040501@oss.ntt.co.jp> Message-ID: <4F27C971.6050709@oracle.com> Hi, A bug was opened for this just a few days ago - 7133122. I'll add your patch to the CR. David Holmes ------------ On 31/01/2012 8:32 PM, Yasumasa Suenaga wrote: > Hi, > > I've tried attach a corefile with jstack. However, I couldn't. > > I guess that this problem is caused by incorrect address mapping of libsaproc.so . > I've made a patch which is attached this email. And I've been able to get correct thread stack with jstack. > > So, I'd like to contribute this patch, and I'd like to backport to JDK6/7 . > Could you help me? > > > ------ details ------ > > I got these messages then I ran jstack with LIBSAPROC_DEBUG environment variable: > > /*************************/ > > : > > libsaproc DEBUG: reading library /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.1.x86_64/jre/lib/amd64/server/libjvm.so @ 0x7f53b455a000 [ 0x7f53b455a000 ] > libsaproc DEBUG: ---- sorted virtual address map ---- > > : > > libsaproc DEBUG: base = 0x7f53b455a000 size = 9993772 > libsaproc DEBUG: base = 0x7f53b455a000 size = 4096 > > : > > libsaproc DEBUG: can't locate map_info at 0x7f53b4dbe000 > libsaproc DEBUG: core read failed for 4096 byte(s) @ 0x7f53b4dbe000 (4096 more bytes) > > : > > /*************************/ > > libsaproc.so tries to read libjvm.so library address, and it is duplicated. > I read Linux kernel source code of function of core dump, and I found these comment: > > source code: kernel-3.2.1-3.fc16.src.rpm (Fedora16 x86_64) > in fs/binfmt_elf.c: static unsigned long vma_dump_size(struct vm_area_struct *vma, unsigned long mm_flags) > ---------------------- > /* > * If this looks like the beginning of a DSO or executable mapping, > * check for an ELF header. If we find one, dump the first page to > * aid in determining what was mapped here. > */ > ---------------------- > > In fact, core image has executable load section which size is 1 page(0x1000) > ---------------------- > LOAD 0x0000000005173000 0x00007f53b455a000 0x0000000000000000 > 0x0000000000001000 0x0000000000988000 R E 1000 > ---------------------- > > So, we must think these case when we attach core image. > I modified "read_lib_segments()" in hotspot/agent/src/os/linux/ps_core.c to overwrite > correct address in shared library . > > > Please check it. > > Thanks, > Yasumasa > From neil.richards at ngmr.net Tue Jan 31 02:33:45 2012 From: neil.richards at ngmr.net (neil.richards at ngmr.net) Date: Tue, 31 Jan 2012 10:33:45 +0000 Subject: hg: jdk8/tl/jdk: 7133301: (process) UNIXProcess_md.c should include sys/wait.h rather than wait.h Message-ID: <20120131103407.6E9E0472AC@hg.openjdk.java.net> Changeset: 13978750cb87 Author: ngmr Date: 2012-01-31 10:31 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13978750cb87 7133301: (process) UNIXProcess_md.c should include sys/wait.h rather than wait.h Reviewed-by: alanb Contributed-by: Jonathan Lu ! src/solaris/native/java/lang/UNIXProcess_md.c From suenaga.yasumasa at oss.ntt.co.jp Tue Jan 31 05:16:55 2012 From: suenaga.yasumasa at oss.ntt.co.jp (Yasumasa Suenaga) Date: Tue, 31 Jan 2012 22:16:55 +0900 Subject: Can't attach core image through SA tools In-Reply-To: <4F27C971.6050709@oracle.com> References: <4F27C325.8040501@oss.ntt.co.jp> <4F27C971.6050709@oracle.com> Message-ID: <4F27E9C7.9090301@oss.ntt.co.jp> Hi David, Thank you for your cooperation. I couldn't find this CR. I will vote it. Thanks, Yasumasa On 2012/01/31 19:58, David Holmes wrote: > Hi, > > A bug was opened for this just a few days ago - 7133122. > > I'll add your patch to the CR. > > David Holmes > ------------ > > On 31/01/2012 8:32 PM, Yasumasa Suenaga wrote: >> Hi, >> >> I've tried attach a corefile with jstack. However, I couldn't. >> >> I guess that this problem is caused by incorrect address mapping of libsaproc.so . >> I've made a patch which is attached this email. And I've been able to get correct thread stack with jstack. >> >> So, I'd like to contribute this patch, and I'd like to backport to JDK6/7 . >> Could you help me? >> >> >> ------ details ------ >> >> I got these messages then I ran jstack with LIBSAPROC_DEBUG environment variable: >> >> /*************************/ >> >> : >> >> libsaproc DEBUG: reading library /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.1.x86_64/jre/lib/amd64/server/libjvm.so @ 0x7f53b455a000 [ 0x7f53b455a000 ] >> libsaproc DEBUG: ---- sorted virtual address map ---- >> >> : >> >> libsaproc DEBUG: base = 0x7f53b455a000 size = 9993772 >> libsaproc DEBUG: base = 0x7f53b455a000 size = 4096 >> >> : >> >> libsaproc DEBUG: can't locate map_info at 0x7f53b4dbe000 >> libsaproc DEBUG: core read failed for 4096 byte(s) @ 0x7f53b4dbe000 (4096 more bytes) >> >> : >> >> /*************************/ >> >> libsaproc.so tries to read libjvm.so library address, and it is duplicated. >> I read Linux kernel source code of function of core dump, and I found these comment: >> >> source code: kernel-3.2.1-3.fc16.src.rpm (Fedora16 x86_64) >> in fs/binfmt_elf.c: static unsigned long vma_dump_size(struct vm_area_struct *vma, unsigned long mm_flags) >> ---------------------- >> /* >> * If this looks like the beginning of a DSO or executable mapping, >> * check for an ELF header. If we find one, dump the first page to >> * aid in determining what was mapped here. >> */ >> ---------------------- >> >> In fact, core image has executable load section which size is 1 page(0x1000) >> ---------------------- >> LOAD 0x0000000005173000 0x00007f53b455a000 0x0000000000000000 >> 0x0000000000001000 0x0000000000988000 R E 1000 >> ---------------------- >> >> So, we must think these case when we attach core image. >> I modified "read_lib_segments()" in hotspot/agent/src/os/linux/ps_core.c to overwrite >> correct address in shared library . >> >> >> Please check it. >> >> Thanks, >> Yasumasa >> From daniel.daugherty at oracle.com Tue Jan 31 06:30:38 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 31 Jan 2012 07:30:38 -0700 Subject: Request for Review: 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms In-Reply-To: <71878A35-A098-4A0E-A34D-803606FFF10A@oracle.com> References: <83B4C4D0-3005-442A-9D5D-274AA97AF1E0@oracle.com> <4F267DCC.2090002@oracle.com> <4F26D325.1000404@oracle.com> <4F27346A.1080302@oracle.com> <71878A35-A098-4A0E-A34D-803606FFF10A@oracle.com> Message-ID: <4F27FB0E.8050306@oracle.com> I think you need to hold up on this one. I don't think the assumption that .java_pid and .attach_pid files are always in /tmp is a good one. More in a little bit. Dan On 1/31/12 1:10 AM, Staffan Larsen wrote: > Moving "/tmp" to a static field, made it easier to write a comment > explaining the rationale as well. > > Updated webrev: http://cr.openjdk.java.net/~sla/7132199/webrev.02/ > > > Thanks, > /Staffan > > On 31 jan 2012, at 01:23, David Holmes wrote: > >> On 31/01/2012 3:28 AM, Dmitry Samersoff wrote: >>> On 2012-01-30 16:28, Staffan Larsen wrote: >>>>> 2. If you decide to hardcode "/tmp" please, create a global constant >>>>> for it. >>>> >>>> I don't agree that this would make the code easier to read or maintain. >>>> I should, however, include a comment saying that the file is always in >>>> /tmp regardless of the value of java.io.tmpdir. >> >> Staffan: I still think changing the static field tmpdir to refer to >> "/tmp" is cleaner then putting "/tmp" in all the use-sites. >> >>> /tmp is common but not mandatory, especially if we speak about embedded >>> systems. >> >> Dmitry: The point is that the VM will always put the file in /tmp. >> That's wrong but the issue here is making the management Java code >> match the hotspot code. >> >>> Native code should use P_tmpdir constant from stdio.h rather than >>> hardcode "/tmp". >>> >>> As we can't access it from java I recommend to create a global constant >>> somewhere to reduce possible future porting efforts. >>> >>> >>>> Changing the tmpdir static would be a smaller fix, but all the cwd code >>>> would then remain. Yes, HotSpot never writes to cwd. >>> >>> I agree with Staffan, that looks for socket/door in cwd should be >>> removed. >> >> Ok, if it is never needed then remove it. >> >> David >> >>> -Dmitry >>> > From daniel.daugherty at oracle.com Tue Jan 31 06:32:11 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 31 Jan 2012 07:32:11 -0700 Subject: Request for Review: 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms In-Reply-To: <71878A35-A098-4A0E-A34D-803606FFF10A@oracle.com> References: <83B4C4D0-3005-442A-9D5D-274AA97AF1E0@oracle.com> <4F267DCC.2090002@oracle.com> <4F26D325.1000404@oracle.com> <4F27346A.1080302@oracle.com> <71878A35-A098-4A0E-A34D-803606FFF10A@oracle.com> Message-ID: <4F27FB6B.2080406@oracle.com> Sorry, sent that last one as "reply to list" instead of "reply to all"... I think you need to hold up on this one. I don't think the assumption that .java_pid and .attach_pid files are always in /tmp is a good one. More in a little bit. Dan On 1/31/12 1:10 AM, Staffan Larsen wrote: > Moving "/tmp" to a static field, made it easier to write a comment > explaining the rationale as well. > > Updated webrev: http://cr.openjdk.java.net/~sla/7132199/webrev.02/ > > > Thanks, > /Staffan > > On 31 jan 2012, at 01:23, David Holmes wrote: > >> On 31/01/2012 3:28 AM, Dmitry Samersoff wrote: >>> On 2012-01-30 16:28, Staffan Larsen wrote: >>>>> 2. If you decide to hardcode "/tmp" please, create a global constant >>>>> for it. >>>> >>>> I don't agree that this would make the code easier to read or maintain. >>>> I should, however, include a comment saying that the file is always in >>>> /tmp regardless of the value of java.io.tmpdir. >> >> Staffan: I still think changing the static field tmpdir to refer to >> "/tmp" is cleaner then putting "/tmp" in all the use-sites. >> >>> /tmp is common but not mandatory, especially if we speak about embedded >>> systems. >> >> Dmitry: The point is that the VM will always put the file in /tmp. >> That's wrong but the issue here is making the management Java code >> match the hotspot code. >> >>> Native code should use P_tmpdir constant from stdio.h rather than >>> hardcode "/tmp". >>> >>> As we can't access it from java I recommend to create a global constant >>> somewhere to reduce possible future porting efforts. >>> >>> >>>> Changing the tmpdir static would be a smaller fix, but all the cwd code >>>> would then remain. Yes, HotSpot never writes to cwd. >>> >>> I agree with Staffan, that looks for socket/door in cwd should be >>> removed. >> >> Ok, if it is never needed then remove it. >> >> David >> >>> -Dmitry >>> > From ahughes at redhat.com Tue Jan 31 07:18:20 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Tue, 31 Jan 2012 10:18:20 -0500 (EST) Subject: Patch to fix build breakage with GCC 4.7 In-Reply-To: <4F2756C9.4000304@oracle.com> Message-ID: <3f4e79e0-949e-4eaf-8320-1794e294bfc7@zmail16.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > On 31/01/2012 12:36 PM, Deepak Bhole wrote: > > * David Holmes [2012-01-30 19:57]: > >> While gcc compilation on sparc is rare I'm not sure that simply > >> deleting the sparc-only option unconditionally is the right thing > >> to > >> do. > >> > > > > I thought about that too. But I was unable to find info on OpenJDK > > + > > SPARC + Linux. Is that combination even supported? The README > > doesn't > > list it: > > http://hg.openjdk.java.net/jdk6/jdk6/raw-file/tip/README-builds.html#MBE > > Linux-sparc is not one of Oracle's supported OpenJDK platforms. > However > AFAIK there are people in the community building OpenJDK on > Linux-sparc > using the Zero interpreter. I don't know if this would affect them > but > it still seems to me that we should be careful not to break other > people's builds. > Yes. Including people in Fedora and Matthias Klose on Debian. > David > ----- > > > The option seemed more like a relic from Solaris + SPARC config > > rather > > than a requirement for Linux + SPARC. > > > > > Cheers, > > Deepak > > > >> David > >> > >> On 31/01/2012 1:20 AM, Deepak Bhole wrote: > >>> Hi, > >>> > >>> JDK builds currently fail with GCC 4.7 due to its stricter option > >>> checking. > >>> > >>> GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not. > >>> Certain > >>> files in JDK supply the -mimpure-text option to GCC. This option > >>> is only > >>> valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during > >>> build > >>> on Linux (I suppose . > >>> > >>> This patch removes the option: > >>> http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00 > >>> > >>> 1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html > >>> 2: > >>> http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html > >>> > >>> If OK for push, please feel free to do so (I don't have commit > >>> access). > >>> > >>> Cheers, > >>> Deepak > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From daniel.daugherty at oracle.com Tue Jan 31 07:21:46 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 31 Jan 2012 08:21:46 -0700 Subject: Request for Review: 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms In-Reply-To: <4F27FB6B.2080406@oracle.com> References: <83B4C4D0-3005-442A-9D5D-274AA97AF1E0@oracle.com> <4F267DCC.2090002@oracle.com> <4F26D325.1000404@oracle.com> <4F27346A.1080302@oracle.com> <71878A35-A098-4A0E-A34D-803606FFF10A@oracle.com> <4F27FB6B.2080406@oracle.com> Message-ID: <4F28070A.9070007@oracle.com> Summary: The .java_pid socket/door is always created in the os::get_temp_directory() which is "/tmp" on BSD, Linux and Solaris. On MacOS X, it can be either the "secure per-user temporary directory" or "/tmp". The .attach_pid file is created by the Java side createAttachFile(). That code first tries to create the file in the process' working directory and if that fails, then it attempts to create the file in tmpdir. src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java lines 40-44: The new comment is right for .java_pid, but not quite right for .attach_pid. See createAttachFile() method on line 280; .attach_pid creation is first attempted in the Java process' current working dir and then in tmpdir. src/solaris/classes/sun/tools/attach/SolarisVirtualMachine.java lines 41-45: The new comment is right for .java_pid, but not quite right for .attach_pid. See createAttachFile() method on line 215; .attach_pid creation is first attempted in the Java process' current working dir and then in tmpdir. test/ProblemList.txt No comments. Linux HSX gory details: The following block of code only creates the .java_pid socket in the directory named by os::get_temp_directory(). On Linux, that function is hardcoded to return "/tmp". src/os/linux/vm/attachListener_linux.cpp: 170 // Initialization - create a listener socket and bind it to a file 171 172 int LinuxAttachListener::init() { 173 char path[UNIX_PATH_MAX]; // socket file 174 char initial_path[UNIX_PATH_MAX]; // socket file during setup 175 int listener; // listener socket (file descriptor ) 176 177 // register function to cleanup 178 ::atexit(listener_cleanup); 179 180 int n = snprintf(path, UNIX_PATH_MAX, "%s/.java_pid%d", 181 os::get_temp_directory(), os::current_process_id()); 182 if (n < (int)UNIX_PATH_MAX) { 183 n = snprintf(initial_path, UNIX_PATH_MAX, "%s.tmp", path); 184 } 185 if (n >= (int)UNIX_PATH_MAX) { 186 return -1; 187 } This block of code checks the process' current directory for an .attach_pid file before it checks os::get_temp_directory(). However, that check is just to see if the attach mechanism should be started. If it does get spoofed, there is little harm. 464 // If the file .attach_pid exists in the working directory 465 // or /tmp then this is the trigger to start the attach mechanism 466 bool AttachListener::is_init_trigger() { 467 if (init_at_startup() || is_initialized()) { 468 return false; // initialized at startup or already ini tialized 469 } 470 char fn[PATH_MAX+1]; 471 sprintf(fn, ".attach_pid%d", os::current_process_id()); 472 int ret; 473 struct stat64 st; 474 RESTARTABLE(::stat64(fn, &st), ret); 475 if (ret == -1) { 476 snprintf(fn, sizeof(fn), "%s/.attach_pid%d", 477 os::get_temp_directory(), os::current_process_id()); 478 RESTARTABLE(::stat64(fn, &st), ret); 479 } 480 if (ret == 0) { 481 // simple check to avoid starting the attach mechanism when 482 // a bogus user creates the file 483 if (st.st_uid == geteuid()) { 484 init(); 485 return true; 486 } 487 } 488 return false; 489 } Solaris HSX gory details: This code assumes both files are always in /tmp/...: src/os/solaris/dtrace/jvm_dtrace.c 170 #define ATTACH_FILE_PATTERN "/tmp/.attach_pid%d" 171 172 /* fill-in the name of attach file name in given buffer */ 173 static void fill_attach_file_name(char* path, int len, pid_t pid) { 174 memset(path, 0, len); 175 sprintf(path, ATTACH_FILE_PATTERN, pid); 176 } 177 178 #define DOOR_FILE_PATTERN "/tmp/.java_pid%d" 179 180 /* open door file for the given JVM */ 181 static int open_door(pid_t pid) { 182 char path[PATH_MAX + 1]; 183 int fd; 184 185 sprintf(path, DOOR_FILE_PATTERN, pid); 186 fd = file_open(path, O_RDONLY); 187 if (fd < 0) { 188 set_jvm_error(JVM_ERR_CANT_OPEN_DOOR); 189 print_debug("cannot open door file %s\n", path); 190 return -1; 191 } 192 print_debug("opened door file %s\n", path); 193 if (check_permission(path) != 0) { 194 set_jvm_error(JVM_ERR_DOOR_FILE_PERMISSION); 195 print_debug("check permission failed for %s\n", path); 196 file_close(fd); 197 fd = -1; 198 } 199 return fd; 200 } 201 202 /* create attach file for given process */ 203 static int create_attach_file(pid_t pid) { 204 char path[PATH_MAX + 1]; 205 int fd; 206 fill_attach_file_name(path, sizeof(path), pid); 207 fd = file_open(path, O_CREAT | O_RDWR); 208 if (fd < 0) { 209 set_jvm_error(JVM_ERR_CANT_CREATE_ATTACH_FILE); 210 print_debug("cannot create file %s\n", path); 211 } else { 212 print_debug("created attach file %s\n", path); 213 } 214 return fd; 215 } The following block of code only creates the .java_pid door in the directory named by os::get_temp_directory(). On Solaris, that function is hardcoded to return "/tmp". src/os/solaris/vm/attachListener_solaris.cpp 367 // Create the door 368 int SolarisAttachListener::create_door() { 369 char door_path[PATH_MAX+1]; 370 char initial_path[PATH_MAX+1]; 371 int fd, res; 372 373 // register exit function 374 ::atexit(listener_cleanup); 375 376 // create the door descriptor 377 int dd = ::door_create(enqueue_proc, NULL, 0); 378 if (dd < 0) { 379 return -1; 380 } 381 382 // create initial file to attach door descriptor 383 snprintf(door_path, sizeof(door_path), "%s/.java_pid%d", 384 os::get_temp_directory(), os::current_process_id()); 385 snprintf(initial_path, sizeof(initial_path), "%s.tmp", door_path); 386 RESTARTABLE(::creat(initial_path, S_IRUSR | S_IWUSR), fd); 387 if (fd == -1) { 388 debug_only(warning("attempt to create %s failed", initial_path)); 389 ::door_revoke(dd); 390 return -1; 391 } 392 assert(fd >= 0, "bad file descriptor"); 393 RESTARTABLE(::close(fd), res); This block of code checks the process' current directory for an .attach_pid file before it checks os::get_temp_directory(). However, that check is just to see if the attach mechanism should be started. If it does get spoofed, there is little harm. 603 // If the file .attach_pid exists in the working directory 604 // or /tmp then this is the trigger to start the attach mechanism 605 bool AttachListener::is_init_trigger() { 606 if (init_at_startup() || is_initialized()) { 607 return false; // initialized at startup or already ini tialized 608 } 609 char fn[PATH_MAX+1]; 610 sprintf(fn, ".attach_pid%d", os::current_process_id()); 611 int ret; 612 struct stat64 st; 613 RESTARTABLE(::stat64(fn, &st), ret); 614 if (ret == -1) { 615 snprintf(fn, sizeof(fn), "%s/.attach_pid%d", 616 os::get_temp_directory(), os::current_process_id()); 617 RESTARTABLE(::stat64(fn, &st), ret); 618 } 619 if (ret == 0) { 620 // simple check to avoid starting the attach mechanism when 621 // a bogus user creates the file 622 if (st.st_uid == geteuid()) { 623 init(); 624 return true; 625 } 626 } 627 return false; 628 } BSD/MacOS X HSX gory details: This code assumes both files are always in /tmp/...: src/os/bsd/dtrace/jvm_dtrace.c 170 #define ATTACH_FILE_PATTERN "/tmp/.attach_pid%d" 171 172 /* fill-in the name of attach file name in given buffer */ 173 static void fill_attach_file_name(char* path, int len, pid_t pid) { 174 memset(path, 0, len); 175 sprintf(path, ATTACH_FILE_PATTERN, pid); 176 } 177 178 #define DOOR_FILE_PATTERN "/tmp/.java_pid%d" 179 180 /* open door file for the given JVM */ 181 static int open_door(pid_t pid) { 182 char path[PATH_MAX + 1]; 183 int fd; 184 185 sprintf(path, DOOR_FILE_PATTERN, pid); 186 fd = file_open(path, O_RDONLY); 187 if (fd < 0) { 188 set_jvm_error(JVM_ERR_CANT_OPEN_DOOR); 189 print_debug("cannot open door file %s\n", path); 190 return -1; 191 } 192 print_debug("opened door file %s\n", path); 193 if (check_permission(path) != 0) { 194 set_jvm_error(JVM_ERR_DOOR_FILE_PERMISSION); 195 print_debug("check permission failed for %s\n", path); 196 file_close(fd); 197 fd = -1; 198 } 199 return fd; 200 } 201 202 /* create attach file for given process */ 203 static int create_attach_file(pid_t pid) { 204 char path[PATH_MAX + 1]; 205 int fd; 206 fill_attach_file_name(path, sizeof(path), pid); 207 fd = file_open(path, O_CREAT | O_RDWR); 208 if (fd < 0) { 209 set_jvm_error(JVM_ERR_CANT_CREATE_ATTACH_FILE); 210 print_debug("cannot create file %s\n", path); 211 } else { 212 print_debug("created attach file %s\n", path); 213 } 214 return fd; 215 } The following block of code only creates the .java_pid socket in the directory named by os::get_temp_directory(). On BSD, that function is hardcoded to return "/tmp". On MacOS X, that function returns the path of the "secure per-user temporary directory" if one is configured or "/tmp" if one is not. src/os/bsd/vm/attachListener_bsd.cpp 170 // Initialization - create a listener socket and bind it to a file 171 172 int BsdAttachListener::init() { 173 char path[UNIX_PATH_MAX]; // socket file 174 char initial_path[UNIX_PATH_MAX]; // socket file during setup 175 int listener; // listener socket (file descriptor ) 176 177 // register function to cleanup 178 ::atexit(listener_cleanup); 179 180 int n = snprintf(path, UNIX_PATH_MAX, "%s/.java_pid%d", 181 os::get_temp_directory(), os::current_process_id()); 182 if (n < (int)UNIX_PATH_MAX) { 183 n = snprintf(initial_path, UNIX_PATH_MAX, "%s.tmp", path); 184 } 185 if (n >= (int)UNIX_PATH_MAX) { 186 return -1; 187 } This block of code checks the process' current directory for an .attach_pid file before it checks os::get_temp_directory(). However, that check is just to see if the attach mechanism should be started. If it does get spoofed, there is little harm. 476 // If the file .attach_pid exists in the working directory 477 // or /tmp then this is the trigger to start the attach mechanism 478 bool AttachListener::is_init_trigger() { 479 if (init_at_startup() || is_initialized()) { 480 return false; // initialized at startup or already ini tialized 481 } 482 char path[PATH_MAX + 1]; 483 int ret; 484 struct stat st; 485 486 snprintf(path, PATH_MAX + 1, "%s/.attach_pid%d", 487 os::get_temp_directory(), os::current_process_id()); 488 RESTARTABLE(::stat(path, &st), ret); 489 if (ret == 0) { 490 // simple check to avoid starting the attach mechanism when 491 // a bogus user creates the file 492 if (st.st_uid == geteuid()) { 493 init(); 494 return true; 495 } 496 } 497 return false; 498 } On 1/31/12 7:32 AM, Daniel D. Daugherty wrote: > Sorry, sent that last one as "reply to list" instead of "reply to all"... > > I think you need to hold up on this one. I don't think the > assumption that .java_pid and .attach_pid files are always > in /tmp is a good one. > > More in a little bit. > > Dan > > On 1/31/12 1:10 AM, Staffan Larsen wrote: >> Moving "/tmp" to a static field, made it easier to write a comment >> explaining the rationale as well. >> >> Updated webrev: http://cr.openjdk.java.net/~sla/7132199/webrev.02/ >> >> >> Thanks, >> /Staffan >> >> On 31 jan 2012, at 01:23, David Holmes wrote: >> >>> On 31/01/2012 3:28 AM, Dmitry Samersoff wrote: >>>> On 2012-01-30 16:28, Staffan Larsen wrote: >>>>>> 2. If you decide to hardcode "/tmp" please, create a global constant >>>>>> for it. >>>>> >>>>> I don't agree that this would make the code easier to read or >>>>> maintain. >>>>> I should, however, include a comment saying that the file is >>>>> always in >>>>> /tmp regardless of the value of java.io.tmpdir. >>> >>> Staffan: I still think changing the static field tmpdir to refer to >>> "/tmp" is cleaner then putting "/tmp" in all the use-sites. >>> >>>> /tmp is common but not mandatory, especially if we speak about >>>> embedded >>>> systems. >>> >>> Dmitry: The point is that the VM will always put the file in /tmp. >>> That's wrong but the issue here is making the management Java code >>> match the hotspot code. >>> >>>> Native code should use P_tmpdir constant from stdio.h rather than >>>> hardcode "/tmp". >>>> >>>> As we can't access it from java I recommend to create a global >>>> constant >>>> somewhere to reduce possible future porting efforts. >>>> >>>> >>>>> Changing the tmpdir static would be a smaller fix, but all the cwd >>>>> code >>>>> would then remain. Yes, HotSpot never writes to cwd. >>>> >>>> I agree with Staffan, that looks for socket/door in cwd should be >>>> removed. >>> >>> Ok, if it is never needed then remove it. >>> >>> David >>> >>>> -Dmitry >>>> >> From karen.kinnear at oracle.com Tue Jan 31 07:29:48 2012 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Tue, 31 Jan 2012 15:29:48 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7114376: Make system dictionary hashtable bucket array size configurable Message-ID: <20120131152952.BC56A472B4@hg.openjdk.java.net> Changeset: b2cd0ee8f778 Author: acorn Date: 2012-01-30 23:27 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b2cd0ee8f778 7114376: Make system dictionary hashtable bucket array size configurable Summary: 7u4 new experimental flag -XX:PredictedClassLoadedCount=# Reviewed-by: dholmes, phh, dcubed ! agent/src/share/classes/sun/jvm/hotspot/memory/LoaderConstraintTable.java ! agent/src/share/classes/sun/jvm/hotspot/memory/SystemDictionary.java ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/hashtable.hpp From staffan.larsen at oracle.com Tue Jan 31 07:48:13 2012 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Tue, 31 Jan 2012 15:48:13 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120131154836.61930472B5@hg.openjdk.java.net> Changeset: 431bc327f34a Author: sla Date: 2012-01-31 10:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/431bc327f34a 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms Summary: Make sure HotSpot and JDK looks for well-known files in the same location Reviewed-by: dholmes, dsamersoff ! src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java ! src/solaris/classes/sun/tools/attach/SolarisVirtualMachine.java ! test/ProblemList.txt Changeset: 663a6333105d Author: sla Date: 2012-01-31 04:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/663a6333105d Merge From staffan at larsen.se Mon Jan 30 05:05:26 2012 From: staffan at larsen.se (Staffan Larsen) Date: Mon, 30 Jan 2012 14:05:26 +0100 Subject: Request for Review: 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms In-Reply-To: References: <83B4C4D0-3005-442A-9D5D-274AA97AF1E0@oracle.com> <4F267DCC.2090002@oracle.com> Message-ID: <285E7381-D9FC-4840-B989-9B0DB17FA745@larsen.se> Here is an updated webrev with an additional comment. Let me know if the comment can be improved or clarified. http://cr.openjdk.java.net/~sla/7132199/webrev.01/ Thanks, /Staffan On 30 jan 2012, at 13:28, Staffan Larsen wrote: > On 30 jan 2012, at 12:23, Dmitry Samersoff wrote: > >> 1. Why we can't use System.getProperty("java.io.tmpdir") ? > > Since HotSpot and the tools run in separate processes it is important that the file is in a well-known global location. It cannot be in different locations for different processes. Since java.io.tmpdir can be set on the command line (which JPRT does), it can be different in the tools and in HotSpot. > > HotSpot will always write the file to /tmp/.java_pidXXX regardless of the value of java.io.tmpdir (see 7009828). Thus, the tools need to always look there. > >> 2. If you decide to hardcode "/tmp" please, create a global constant for it. > > I don't agree that this would make the code easier to read or maintain. I should, however, include a comment saying that the file is always in /tmp regardless of the value of java.io.tmpdir. > > > On 30 jan 2012, at 12:49, David Holmes wrote: > >> I'm somewhat confused by this problem. 6938627 is the CR that changed from /tmp to use the java.io.tmpdir property, but that CR did not modify the files that you have modified - so what broke these files? > > 7009828 then changed HotSpot back to use /tmp always. I seems like this has been going back and forth for a while? I don't really know the whole history. > >> Looking at your fix, wouldn't it be simpler to just set the static tmpdir to /tmp and leave the rest of the code as-is? Why do you stop looking in the cwd in addition to changing the tmp location? Is it because hotspot will never write it there? > > Changing the tmpdir static would be a smaller fix, but all the cwd code would then remain. Yes, HotSpot never writes to cwd. > > Thanks, > /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120130/4f79edd1/attachment.html From dbhole at redhat.com Mon Jan 30 18:36:42 2012 From: dbhole at redhat.com (Deepak Bhole) Date: Mon, 30 Jan 2012 21:36:42 -0500 Subject: Patch to fix build breakage with GCC 4.7 In-Reply-To: <4F273C6E.30801@oracle.com> References: <20120130152052.GE3179@redhat.com> <4F273C6E.30801@oracle.com> Message-ID: <20120131023642.GO16474@redhat.com> * David Holmes [2012-01-30 19:57]: > Hi Deepak, > > The primary change here is a build change so I've cc'ed build-dev. > > The majority of the changes are to JVMTI demo files hence I've cc'd > serviceability-dev. > > I think JDK8-dev doesn't need to be included now so I've bcc'd it. > > While gcc compilation on sparc is rare I'm not sure that simply > deleting the sparc-only option unconditionally is the right thing to > do. > Hi David, I thought about that too. But I was unable to find info on OpenJDK + SPARC + Linux. Is that combination even supported? The README doesn't list it: http://hg.openjdk.java.net/jdk6/jdk6/raw-file/tip/README-builds.html#MBE The option seemed more like a relic from Solaris + SPARC config rather than a requirement for Linux + SPARC. Cheers, Deepak > David > > On 31/01/2012 1:20 AM, Deepak Bhole wrote: > >Hi, > > > >JDK builds currently fail with GCC 4.7 due to its stricter option > >checking. > > > >GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not. Certain > >files in JDK supply the -mimpure-text option to GCC. This option is only > >valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during build > >on Linux (I suppose . > > > >This patch removes the option: > >http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00 > > > >1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html > >2: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html > > > >If OK for push, please feel free to do so (I don't have commit access). > > > >Cheers, > >Deepak From dbhole at redhat.com Tue Jan 31 07:23:37 2012 From: dbhole at redhat.com (Deepak Bhole) Date: Tue, 31 Jan 2012 10:23:37 -0500 Subject: Patch to fix build breakage with GCC 4.7 In-Reply-To: <4F2756C9.4000304@oracle.com> References: <20120130152052.GE3179@redhat.com> <4F273C6E.30801@oracle.com> <20120131023642.GO16474@redhat.com> <4F2756C9.4000304@oracle.com> Message-ID: <20120131152335.GA7700@redhat.com> * David Holmes [2012-01-30 21:50]: > On 31/01/2012 12:36 PM, Deepak Bhole wrote: > >* David Holmes [2012-01-30 19:57]: > >>While gcc compilation on sparc is rare I'm not sure that simply > >>deleting the sparc-only option unconditionally is the right thing to > >>do. > >> > > > >I thought about that too. But I was unable to find info on OpenJDK + > >SPARC + Linux. Is that combination even supported? The README doesn't > >list it: > >http://hg.openjdk.java.net/jdk6/jdk6/raw-file/tip/README-builds.html#MBE > > Linux-sparc is not one of Oracle's supported OpenJDK platforms. > However AFAIK there are people in the community building OpenJDK on > Linux-sparc using the Zero interpreter. I don't know if this would > affect them but it still seems to me that we should be careful not > to break other people's builds. > Ah fair enough. If it is supported, the patch definitely needs to be fixed. I will re-post. Thanks for taking a look! Deepak > David > ----- > > >The option seemed more like a relic from Solaris + SPARC config rather > >than a requirement for Linux + SPARC. > > > > >Cheers, > >Deepak > > > >>David > >> > >>On 31/01/2012 1:20 AM, Deepak Bhole wrote: > >>>Hi, > >>> > >>>JDK builds currently fail with GCC 4.7 due to its stricter option > >>>checking. > >>> > >>>GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not. Certain > >>>files in JDK supply the -mimpure-text option to GCC. This option is only > >>>valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during build > >>>on Linux (I suppose . > >>> > >>>This patch removes the option: > >>>http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00 > >>> > >>>1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html > >>>2: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html > >>> > >>>If OK for push, please feel free to do so (I don't have commit access). > >>> > >>>Cheers, > >>>Deepak