From karen.kinnear at oracle.com Fri Oct 1 07:57:57 2010 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 1 Oct 2010 10:57:57 -0400 Subject: S code review please: 6763959 LockSupport.parkUntil(0) Message-ID: <6ACF5A98-FA1B-4599-950D-133BBC1E2814@oracle.com> Please review: http://cr.openjdk.java.net/~acorn/6763959/webrev/ bug link at http://monaco.sfbay.sun.com/detail.jsf?cr=6763959 6763959: java.util.concurrent.locks.LockSupport.parkUntil(0) blocks forever instead of returning immediately. Thanks to David Holmes for the suggested fixes. tests: new test attached to bug on Solaris, Linux and Windows thanks, Karen From coleen.phillimore at oracle.com Fri Oct 1 09:21:38 2010 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 01 Oct 2010 12:21:38 -0400 Subject: Review request 6981484: Update development launcher In-Reply-To: References: <41c46841-693e-4bed-ac89-29cff7867a50@default> <1284985103.14822.2285.camel@macbook> <50ee9673-7a05-48ce-954a-3541eca08e2a@default> <1285087758.14822.3018.camel@macbook> <629026fb-5d9f-4760-a2c4-fb945998f0c1@default 1285159093.14822.3636.camel@macbook> <3b7d727a-e930-4721-b064-1b539e7c9193@default 4C9A109F.6040909@oracle.com> Message-ID: <4CA60A92.7090501@oracle.com> I reviewed this, and I think it looks great. A couple of comments: http://cr.openjdk.java.net/~sla/6981484/webrev.04/make/windows/makefiles/launcher.make.html Did the lines about VS2005 come from the jdk version? I don't think we ever supported VS2005 but maybe open source community does, so it's probably okay and safe to leave it there. I was going to suggest testing it on the "control" build which is the top jdk build but I don't think this would affect the control build. I can send you an easy way to do this. Lastly, thank you for the extra work and investigation so that we only have one version in the VM. Thanks, Coleen Staffan Larsen wrote: > > Hi All, > > > > So, another shot: http://cr.openjdk.java.net/~sla/6981484/webrev.04/ > > > > This time I have based the launcher code on JDK 6u22. I am using the > same code for all platforms. Shared code are in > src/share/tools/launcher. To minimize code duplication I have placed > the shared solaris/linux code in src/os/posix/launcher. The windows > code is in src/os/windows/launcher. > > > > The launcher is now called hotspot(.exe). It will choose the JDK to > use based on the values of JAVA_HOME or ALT_JAVA_HOME (the latter > takes precedence). > > > > The windows launcher is a normal executable with dynamic linking of > jvm.dll. It has no special arguments. > > > > The posix launcher is really a shell script that sets up > LD_LIBRARY_PATH and some other things before calling the executable. > The executable is still called gamma and is dynamically linked to > libjvm.so. The posix launcher accepts the following arguments: > > -gdb: launches gdb and runs the launcher until libjvm.so is loaded > (to make it easier to set breakpoints) > > -gud: same as -gdb, but launches emacs in gud-mode. > > -dbx: launches dbx > > -valgrind: launches in the valgrind environment (if available) > > > > Thanks, > > /Staffan > > > > > > *From:* Coleen Phillimore > *Sent:* den 22 september 2010 4:20 > *To:* Staffan Larsen > *Cc:* Christian Thalinger; hotspot-dev at openjdk.java.net > *Subject:* Re: Review request 6981484: Update development launcher > > > > > Hi Staffan, > Is this file *src/os/windows/launcher/java.c** > *the same as ./os/linux/launcher/java.c and ./os/solaris/launcher/java.c > In fact, the sources in os/linux/launcher are almost exactly the same > as os/solaris/launcher. > Can we have just one set? Perhaps put it in directory > src/share/tools/launcher and make the makefiles use these sources > instead? Sorry to make more work but having the same 2000 lines of > code somewhere else, guarantees one copy will always be wrong. > > Thanks, > Coleen > > On 09/22/10 08:38, Staffan Larsen wrote: > > Here we go again: http://cr.openjdk.java.net/~sla/6981484/webrev.03/ > > Eventually, I'll get there... > > Thanks, > /Staffan > > -----Original Message----- > From: Christian Thalinger > Sent: den 22 september 2010 2:38 > To: Staffan Larsen > Cc: hotspot-dev at openjdk.java.net > Subject: RE: Review request 6981484: Update development launcher > > On Wed, 2010-09-22 at 05:23 -0700, Staffan Larsen wrote: > > > Thanks Christian - I obviously have some things to learn as a new > > committer - didn't think about the copyrights :-) > > > > > Sure. I was going the same route :-) > > > > > > http://cr.openjdk.java.net/~sla/6981484/webrev.02/ > > > > Now with updated copyrights. > > > > > As David already said. > > -- Christian > > > > > From David.Holmes at oracle.com Fri Oct 1 15:57:27 2010 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 02 Oct 2010 08:57:27 +1000 Subject: S code review please: 6763959 LockSupport.parkUntil(0) In-Reply-To: <6ACF5A98-FA1B-4599-950D-133BBC1E2814@oracle.com> References: <6ACF5A98-FA1B-4599-950D-133BBC1E2814@oracle.com> Message-ID: <4CA66757.1050603@oracle.com> Looks good to me. :) David Karen Kinnear said the following on 10/02/10 00:57: > > Please review: > > http://cr.openjdk.java.net/~acorn/6763959/webrev/ > bug link at http://monaco.sfbay.sun.com/detail.jsf?cr=6763959 > > 6763959: java.util.concurrent.locks.LockSupport.parkUntil(0) blocks > forever instead of returning immediately. > Thanks to David Holmes for the suggested fixes. > > tests: new test attached to bug > on Solaris, Linux and Windows > > thanks, > Karen From daniel.daugherty at oracle.com Fri Oct 1 16:21:02 2010 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 01 Oct 2010 17:21:02 -0600 Subject: S code review please: 6763959 LockSupport.parkUntil(0) In-Reply-To: <6ACF5A98-FA1B-4599-950D-133BBC1E2814@oracle.com> References: <6ACF5A98-FA1B-4599-950D-133BBC1E2814@oracle.com> Message-ID: <4CA66CDE.7040304@oracle.com> Thumbs up. Linux and Solaris files need the copyright updated. Dan On 10/1/2010 8:57 AM, Karen Kinnear wrote: > > Please review: > > http://cr.openjdk.java.net/~acorn/6763959/webrev/ > bug link at http://monaco.sfbay.sun.com/detail.jsf?cr=6763959 > > 6763959: java.util.concurrent.locks.LockSupport.parkUntil(0) blocks > forever instead of returning immediately. > Thanks to David Holmes for the suggested fixes. > > tests: new test attached to bug > on Solaris, Linux and Windows > > thanks, > Karen From erik.trimble at oracle.com Fri Oct 1 18:05:51 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Sat, 02 Oct 2010 01:05:51 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20101002010601.905B447E44@hg.openjdk.java.net> Changeset: beef35b96b81 Author: cl Date: 2010-10-01 15:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/beef35b96b81 Added tag jdk7-b112 for changeset 5511edd5d719 ! .hgtags Changeset: 1c52033222eb Author: trims Date: 2010-10-01 18:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1c52033222eb Added tag hs20-b01 for changeset 5511edd5d719 ! .hgtags From joannechiou at gmail.com Sun Oct 3 04:33:05 2010 From: joannechiou at gmail.com (=?Big5?B?qvTfTrRm?=) Date: Sun, 3 Oct 2010 19:33:05 +0800 Subject: [hotspot-dev] JIT compiler generate x86 and x86_64 binary Message-ID: hi, all i built openjdk6 on x86_64 machine, and actually JIT compiler generated codes for x86_64, now i try to make JIT compiler can generate x86 32 bits codes. because x86_32 binary could run on x86_64 machine. Is this idea feasible? and any other hint to do this? thanks. Chiou -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101003/abde0ca6/attachment.html From erik.trimble at oracle.com Sun Oct 3 13:51:14 2010 From: erik.trimble at oracle.com (Erik Trimble) Date: Sun, 03 Oct 2010 13:51:14 -0700 Subject: [hotspot-dev] JIT compiler generate x86 and x86_64 binary In-Reply-To: References: Message-ID: <4CA8ECC2.4000207@oracle.com> On 10/3/2010 4:33 AM, ??? wrote: > hi, all > > i built openjdk6 on x86_64 machine, and actually JIT compiler > generated codes for x86_64, > now i try to make JIT compiler can generate x86 32 bits codes. because > x86_32 binary could run > on x86_64 machine. > > Is this idea feasible? and any other hint to do this? > thanks. > > > > Chiou I _believe_ that what you want it to install the x86 version of the server JRE on your x64 machine - its JIT will generate x86 instructions. Naturally, you'll have to live with the memory (and other) restrictions of x86, even through the OS/hardware may be x64. Having a x64 systems generate "x86" codes isn't the right questions. x64 is an ISA (environment), and it's a general superset of the x86 ISA. So, technically, you *are* generating x86 opcodes, they're just being run in a x64 context. You *can't* switch the context a process runs in - no program is able to do that. If all you are looking to be able to do is build a 32-bit JDK on a x64 machine, that's entirely possible (indeed really simple on Solaris, a bit more - but not much - difficult on Linux). The README instructions should have the option you need to set in the build/make process to produce a 32-bit JDK on a 64-bit machine/OS. Note you can't use a 32-bit Hotspot with a 64-bit JDK, or vice versa. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA From vladimir.kozlov at oracle.com Mon Oct 4 13:03:28 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 04 Oct 2010 13:03:28 -0700 Subject: Nightly failured java/util tests Message-ID: <4CAA3310.1080404@oracle.com> Sorry if it is known issue. A lot of new java/util tests failed like this during compilation (javac): /export/local/common/testbase/jtreg/7/JT_JDK/test/java/util/Calendar/WeekDateTest.java:88: cannot find symbol cal.setWeekDate(weekDate[0], weekDate[1], dayOfWeek); ^ symbol: method setWeekDate(int,int,int) location: class GregorianCalendar The test used new methods from jdk7b112 which are not defined in jdk7b107 we used for testing. Can we exclude these tests until we switch to newest JDK? % /java/re/jdk/7/promoted/all/b111/binaries/solaris-i586/bin/javac WeekDateTest.java WeekDateTest.java:88: cannot find symbol cal.setWeekDate(weekDate[0], weekDate[1], dayOfWeek); ^ symbol: method setWeekDate(int,int,int) location: class GregorianCalendar ... % /java/re/jdk/7/promoted/all/b112/binaries/solaris-i586/bin/javac WeekDateTest.java % Thanks, Vladimir From erik.trimble at oracle.com Tue Oct 5 18:20:51 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Wed, 06 Oct 2010 01:20:51 +0000 Subject: hg: hsx/hsx17/baseline: Added tag hs17-b17 for changeset 1771222afd14 Message-ID: <20101006012053.6FA6047F29@hg.openjdk.java.net> Changeset: 704f3487eaa2 Author: trims Date: 2010-10-05 18:20 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/704f3487eaa2 Added tag hs17-b17 for changeset 1771222afd14 ! .hgtags From erik.trimble at oracle.com Tue Oct 5 18:22:08 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Wed, 06 Oct 2010 01:22:08 +0000 Subject: hg: hsx/hsx17/master: 2 new changesets Message-ID: <20101006012216.B415247F2A@hg.openjdk.java.net> Changeset: 1771222afd14 Author: ohair Date: 2010-07-16 22:26 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/master/rev/1771222afd14 6969236: Regression: JVM identification fails due to Oracle rebranding in java.exe Reviewed-by: asaha ! make/hotspot_distro ! make/hotspot_version Changeset: 704f3487eaa2 Author: trims Date: 2010-10-05 18:20 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/master/rev/704f3487eaa2 Added tag hs17-b17 for changeset 1771222afd14 ! .hgtags From volker.simonis at gmail.com Wed Oct 6 08:01:34 2010 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 6 Oct 2010 17:01:34 +0200 Subject: [hotspot-dev] JIT compiler generate x86 and x86_64 binary In-Reply-To: References: Message-ID: Building a 32-bit HotSpot on a 64-bit Linux System can be done as follows (just copied and pasted from an internal memo): If you are working on a 64-bit system and want to build a 32-bit VM, you have to use a 32-bit boot JVM, i.e. one that supports the -d32 option (see ALT_BOOTDIR option above). The 32-bit JVM is not strictly needed for the build, but for the concluding smoke test. Depending on your system, you may also have to install the 32-bit development libraries and headers (e.g. g++-multilib on Ubuntu). Additionally you have to set the environment variable ARCH_DATA_MODEL=32 and you probably want to use DEBUG_CFLAGS/i486=-g to instruct the make to generate the default and most expressive debugging format. Otherwise, -gstabs will be used on 32-bit systems which is not the preferred debugging format anymore. So building a 32-bit HotSpot VM on a 64-bit Linux system where warnings wont be treated as errors can be done with the following command line: > ALT_BOOTDIR=/share/software/Java/jdk1.6.0_21 \ ALT_OUTPUTDIR=../output_x86_dbg \ ARCH_DATA_MODEL=32 \ make jvmg WARNINGS_ARE_ERRORS= DEBUG_CFLAGS/i486=-g 2>&1 | tee ../output_x86_dbg.log You can then use the newly created libjvm.so with an existing 32-bit JDK/JRE by replacing the original library with the new one. Regards, Volker On Sun, Oct 3, 2010 at 1:33 PM, ??? wrote: > hi, all > i built openjdk6 on x86_64 machine, and actually JIT compiler generated > codes for x86_64, > now i try to make JIT compiler can generate x86 32 bits codes. because > x86_32 binary could run > on x86_64 machine. > Is this idea feasible? and any other hint to do this? > thanks. > > > Chiou From christian.thalinger at oracle.com Wed Oct 6 11:37:32 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 06 Oct 2010 20:37:32 +0200 Subject: [hotspot-dev] JIT compiler generate x86 and x86_64 binary In-Reply-To: References: Message-ID: <1286390252.9946.2031.camel@macbook> On Wed, 2010-10-06 at 17:01 +0200, Volker Simonis wrote: > probably want to use DEBUG_CFLAGS/i486=-g to instruct the make to > generate the default and most expressive debugging format. Otherwise, > -gstabs will be used on 32-bit systems which is not the preferred > debugging format anymore. Just a FYI: using DEBUG_BINARIES=true uses -g for all platforms, which is a little more generic. -- Christian From vladimir.kozlov at oracle.com Wed Oct 6 17:27:26 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 07 Oct 2010 00:27:26 +0000 Subject: hg: jdk7/hotspot/hotspot: 20 new changesets Message-ID: <20101007002801.6F81A47F5F@hg.openjdk.java.net> Changeset: c77e8f982901 Author: never Date: 2010-09-15 20:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c77e8f982901 6984979: OptimizeFill misses some cases with an odd memory graph Reviewed-by: kvn ! src/share/vm/opto/loopTransform.cpp Changeset: fd5d4527cdf5 Author: iveresov Date: 2010-09-21 13:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fd5d4527cdf5 6986270: guarantee(*bcp != Bytecodes::_monitorenter || exec_mode != Deoptimization::Unpack_exception) fails Summary: Propagate the compiler type of the deopting method to vframeArrayElement::unpack_on_stack() Reviewed-by: jrose, never ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vframeArray.cpp Changeset: 5867d89c129b Author: never Date: 2010-09-22 13:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5867d89c129b 6982537: Crash in Node*step_through_mergemem Reviewed-by: kvn ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/memnode.cpp Changeset: 87b64980e2f1 Author: never Date: 2010-09-22 21:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/87b64980e2f1 6972540: sun/nio/ch/SocketChannelImpl compilation crashed when executing CompileTheWorld Reviewed-by: kvn ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp Changeset: c40600e85311 Author: never Date: 2010-09-22 23:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c40600e85311 6986028: assert(_base == Int) failed: Not an Int in CmpINode::sub Reviewed-by: kvn, twisti ! src/share/vm/opto/stringopts.cpp Changeset: c93c652551b5 Author: twisti Date: 2010-09-24 03:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c93c652551b5 6986944: JSR 292 assert(caller_nm->is_method_handle_return(caller_frame.pc())) failed: must be MH call site Reviewed-by: never, kvn ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/ci/ciMethod.cpp Changeset: f02a8bbe6ed4 Author: roland Date: 2009-12-29 19:08 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f02a8bbe6ed4 6986046: C1 valuestack cleanup Summary: fixes an historical oddity in C1 with inlining where all of the expression stacks are kept in the topmost ValueStack instead of being in their respective ValueStacks. Reviewed-by: never Contributed-by: Christian Wimmer ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_CFGPrinter.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_ValueStack.cpp ! src/share/vm/c1/c1_ValueStack.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/includeDB_compiler1 Changeset: 861f533d12b0 Author: roland Date: 2010-09-24 13:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/861f533d12b0 Merge Changeset: df015ec64052 Author: iveresov Date: 2010-09-27 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/df015ec64052 6987115: Non-tiered compilation policy creates unnecessary C1 threads Summary: Fixed NonTieredCompPolicy::compiler_count() to return correct thread count. Reviewed-by: twisti, kvn ! src/share/vm/runtime/compilationPolicy.cpp Changeset: 1375bc8922e4 Author: never Date: 2010-09-27 20:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1375bc8922e4 6987763: assert(kind() == EmptyExceptionState) failed: only EmptyExceptionStates can be modified Reviewed-by: roland, kvn, iveresov ! src/share/vm/c1/c1_ValueStack.hpp Changeset: 8aa5fd5d2046 Author: twisti Date: 2010-09-29 00:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8aa5fd5d2046 6987634: JSR 292 assert(start_bci() >= 0 && start_bci() < code_size()) failed: correct osr_bci argument Reviewed-by: never, kvn ! src/share/vm/opto/doCall.cpp Changeset: ad0638ff8ea4 Author: roland Date: 2010-09-29 18:53 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ad0638ff8ea4 6988303: 6986046 breaks build with recent gcc Summary: fixes build break Reviewed-by: never, kvn ! src/share/vm/c1/c1_Instruction.hpp Changeset: 80c9354976b0 Author: iveresov Date: 2010-09-29 16:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/80c9354976b0 6988346: 6986046 breaks tiered Summary: adjusted profiling code generation to use the new ValueStack implementation; lowered optimization level for c1_LinearScan.cpp on solaris x64. Reviewed-by: kvn, never ! make/solaris/makefiles/amd64.make ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 56601ef83436 Author: kvn Date: 2010-09-30 18:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/56601ef83436 6916062: assert(_inserts <= _insert_limit,"hash table overflow") in NodeHash::hash_insert Summary: Missing check for not empty worklist when puting memory node back on worklist and expecting address type update. Reviewed-by: never ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/phaseX.cpp Changeset: 52e82a6bedaf Author: never Date: 2010-10-04 17:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/52e82a6bedaf 6968348: Byteswapped memory access can point to wrong location after JIT Reviewed-by: twisti, kvn, iveresov ! src/cpu/x86/vm/x86_64.ad + test/compiler/6968348/Test6968348.java Changeset: 3f9a70eb8b1f Author: iveresov Date: 2010-10-05 00:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3f9a70eb8b1f 6989368: Regression in scimark2.MonteCarlo in jdk7_b112 on Linux Summary: Fix ciMethod::instructions_size() to return correct value Reviewed-by: kvn, twisti ! src/share/vm/ci/ciMethod.cpp Changeset: fe08403130db Author: kvn Date: 2010-10-05 08:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fe08403130db 6979458: VM crashes when -XX:ObjectAlignmentInBytes is too big Summary: Set upper limit 256 for ObjectAlignmentInBytes value. Reviewed-by: never, iveresov ! src/share/vm/runtime/arguments.cpp Changeset: a3f7f95b0165 Author: never Date: 2010-10-05 11:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a3f7f95b0165 6988018: dtrace/hotspot/MethodInvocation/MethodInvocation002 crashes with client compiler Reviewed-by: iveresov, kvn, kamg ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: a50abfc67f31 Author: never Date: 2010-10-05 17:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a50abfc67f31 6989736: fix mapfile warnings on solaris Reviewed-by: kvn, iveresov, jcoomes ! make/linux/adlc_updater ! make/solaris/adlc_updater ! make/solaris/makefiles/reorder_COMPILER1_i486 ! make/solaris/makefiles/reorder_COMPILER1_sparc ! make/solaris/makefiles/reorder_TIERED_amd64 ! make/solaris/makefiles/reorder_TIERED_i486 ! make/solaris/makefiles/reorder_TIERED_sparc ! make/solaris/makefiles/reorder_TIERED_sparcv9 Changeset: 22e4420d19f7 Author: kvn Date: 2010-10-06 14:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/22e4420d19f7 Merge ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/runtime/arguments.cpp From tom.rodriguez at oracle.com Thu Oct 7 13:12:51 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 7 Oct 2010 13:12:51 -0700 Subject: review (S) for 6970683: improvements to hs_err output Message-ID: http://cr.openjdk.java.net/~never/6970683 6970683: improvements to hs_err output Reviewed-by: There are a few things missing from the hs_err dump that would be useful. First we don't dump the sparc L and I registers. Second some information about the size and contents of the code cache would be useful. Third we should dump a larger region around the faulting instruction. Additionally the new register to memory mapping output can crash which stops us from getting the stack and instructions at the faulting pc, so I moved it into it's own section. block_start would assert in some cases so I augmented existing logic to just return null. I also changed the formatting to remove all the extra whitespace and made some of the output more compact and eliminated most of the useless whitespace. From vladimir.kozlov at oracle.com Thu Oct 7 14:03:45 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 07 Oct 2010 14:03:45 -0700 Subject: review (S) for 6970683: improvements to hs_err output In-Reply-To: References: Message-ID: <4CAE35B1.4040501@oracle.com> src/share/vm/utilities/vmError.cpp change comment: + STEP(105, "(printing register info)") + + // registers, top of stack, instructions near pc src/share/vm/runtime/os.cpp next values are the same why print twice? + st->print_cr(INTPTR_FORMAT " is the thread: " + INTPTR_FORMAT, addr, thread); src/share/vm/code/codeCache.cpp closed ")" should be "]" (or it is indication that address in not included?): + st->print_cr("Code Cache [" INTPTR_FORMAT ", " INTPTR_FORMAT ", " INTPTR_FORMAT ")", also why you need to put ' ' around numbers for codecache values? Can you separate them using comma? src/os_cpu/windows_x86/vm/os_windows_x86.cpp missing #ifdef AMD64 in os::print_register_info() and end of method: st->cr(); } Also why you left Register to memory dump the same? On solaris platforms you print only register name before call to print_location() (I prefer this). src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp missing "=" after register name in print_register_info(). src/os_cpu/linux_x86/vm/os_linux_x86.cpp print_register_info() should be as in os_solaris_x86.cpp src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp missing print_register_info() method. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6970683 > > 6970683: improvements to hs_err output > Reviewed-by: > > There are a few things missing from the hs_err dump that would be > useful. First we don't dump the sparc L and I registers. Second some > information about the size and contents of the code cache would be > useful. Third we should dump a larger region around the faulting > instruction. Additionally the new register to memory mapping output > can crash which stops us from getting the stack and instructions at > the faulting pc, so I moved it into it's own section. block_start > would assert in some cases so I augmented existing logic to just > return null. I also changed the formatting to remove all the extra > whitespace and made some of the output more compact and eliminated > most of the useless whitespace. From coleen.phillimore at oracle.com Fri Oct 8 09:03:50 2010 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 08 Oct 2010 12:03:50 -0400 Subject: review (S) for 6970683: improvements to hs_err output In-Reply-To: References: Message-ID: <4CAF40E6.8070803@oracle.com> This change looks good to me. I missed when print_location() was added for the registers, but it does a lot of things that we used to consider unsafe from the error handler. And I didn't like all the white space. I wonder if you should check for Universe::is_initialized() in vmError before calling this? Can you attach an "after" version of hs_err? I guess I can get one of my own pretty easily after you check this in, but I'd like to see one first. Lastly, what sort of problems can you diagnose from the code cache bounds? Thanks, Coleen Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6970683 > > 6970683: improvements to hs_err output > Reviewed-by: > > There are a few things missing from the hs_err dump that would be > useful. First we don't dump the sparc L and I registers. Second some > information about the size and contents of the code cache would be > useful. Third we should dump a larger region around the faulting > instruction. Additionally the new register to memory mapping output > can crash which stops us from getting the stack and instructions at > the faulting pc, so I moved it into it's own section. block_start > would assert in some cases so I augmented existing logic to just > return null. I also changed the formatting to remove all the extra > whitespace and made some of the output more compact and eliminated > most of the useless whitespace. > From kelly.ohair at oracle.com Fri Oct 8 12:21:13 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 8 Oct 2010 12:21:13 -0700 Subject: hotspot messages about the future? Message-ID: When did the hotspot -XX options start spitting out messages like this? svc6<1263> java -XX:+CMSClassUnloadingEnabled -XX: +CMSPermGenSweepingEnabled -version Please use CMSClassUnloadingEnabled in place of CMSPermGenSweepingEnabled in the future java version "1.6.0_10" Java(TM) SE Runtime Environment (build 1.6.0_10-b33) Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode) I always thought silence was golden? -kto From paul.hohensee at oracle.com Fri Oct 8 14:45:39 2010 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Fri, 08 Oct 2010 21:45:39 +0000 Subject: hg: hsx/hsx19/baseline: 32 new changesets Message-ID: <20101008214636.168D247FEA@hg.openjdk.java.net> Changeset: d64a8c7aa9d5 Author: never Date: 2010-08-27 17:33 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/d64a8c7aa9d5 4809552: Optimize Arrays.fill(...) Reviewed-by: kvn ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/share/vm/includeDB_compiler2 ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 51a669dbaa6a Author: kvn Date: 2010-08-26 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/51a669dbaa6a 6976400: "Meet Not Symmetric" Summary: Use NULL as klass for TypeAryPtr::RANGE. Add klass verification into TypeAryPtr ctor. Reviewed-by: never ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: 22339bb3b2fd Author: kvn Date: 2010-08-30 11:02 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/22339bb3b2fd 6980978: assert(mt == t->xmeet(this)) failed: meet not commutative Summary: Fix code in TypeAryPtr::xmeet() for constant array. Reviewed-by: never ! src/share/vm/opto/type.cpp Changeset: be2b508a60cb Author: phh Date: 2010-10-08 11:07 -0400 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/be2b508a60cb 6981431: IdealKit should support I_O projections Summary: add I_O projections support into IdealKit Reviewed-by: never ! src/share/vm/includeDB_compiler2 ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/library_call.cpp Changeset: 0652d205acda Author: never Date: 2010-08-30 17:27 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/0652d205acda 6969586: OptimizeStringConcat: SIGSEGV in LoadNode::Value() Reviewed-by: kvn ! src/share/vm/opto/memnode.cpp Changeset: 04323991c395 Author: kamg Date: 2010-08-27 15:05 -0400 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/04323991c395 6980262: Memory leak when exception is thrown in static initializer Summary: Use resource memory instead of c-heap for the exception message Reviewed-by: phh, jmasa ! src/share/vm/oops/instanceKlass.cpp Changeset: 5b0eb275c3d0 Author: never Date: 2010-09-02 11:40 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/5b0eb275c3d0 6981773: incorrect fill value with OptimizeFill Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/stubGenerator_sparc.cpp Changeset: 95a51e316d1c Author: kvn Date: 2010-08-23 09:09 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/95a51e316d1c 6896381: CTW fails share/vm/ci/bcEscapeAnalyzer.cpp:99, assert(_stack_height < _max_stack,"stack overflow") Summary: Check constant Tag type instead of calling get_constant(). Reviewed-by: never ! src/share/vm/ci/bcEscapeAnalyzer.cpp Changeset: 9b2e416eda7f Author: dholmes Date: 2010-09-03 01:28 -0400 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/9b2e416eda7f 6978641: Fix for 6929067 introduces additional overhead in thread creation/termination paths Summary: Disable stack bounds checks in product mode other than for the initial thread Reviewed-by: coleenp, jcoomes, aph ! src/os/linux/vm/os_linux.cpp Changeset: a8effb842215 Author: never Date: 2010-09-03 13:31 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/a8effb842215 6982370: SIGBUS in jbyte_fill Reviewed-by: kvn ! src/cpu/sparc/vm/stubGenerator_sparc.cpp + test/compiler/6982370/Test6982370.java Changeset: fa7695e418a1 Author: trims Date: 2010-09-03 18:43 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/fa7695e418a1 6982488: Bump the HS19 build number to 07 for 6Updates Summary: Update the HS19 build number to 07 Reviewed-by: jcoomes ! make/hotspot_version Changeset: b65b341bd9fa Author: never Date: 2010-09-07 11:31 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/b65b341bd9fa 6982533: Crash in ~StubRoutines::jbyte_fill with AggressiveOpts enabled Reviewed-by: kvn ! src/share/vm/opto/loopTransform.cpp Changeset: 17143f9aa19a Author: phh Date: 2010-10-08 11:13 -0400 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/17143f9aa19a Added tag hs19-b07 for changeset b65b341bd9fa ! .hgtags Changeset: 620cfdea5a3f Author: trims Date: 2010-09-07 18:27 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/620cfdea5a3f 6983013: Change the HS_MINOR version to 6 for the 6Update train Summary: Update the HS_MINOR_VER to 6 Reviewed-by: jcoomes ! make/hotspot_version Changeset: cff4ddf257b4 Author: kvn Date: 2010-09-13 16:45 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/cff4ddf257b4 6984346: Remove development code in type.hpp Summary: Remove code which use UseNewCode in type.hpp Reviewed-by: never ! src/share/vm/opto/type.hpp Changeset: 4cf84525dc4d Author: kvn Date: 2010-09-14 17:19 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/4cf84525dc4d 6984368: Large default heap size does not allow to use zero based compressed oops Summary: take into account HeapBaseMinAddress and round down MaxPermSize Reviewed-by: never ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/runtime/arguments.cpp Changeset: f6b107f3629a Author: acorn Date: 2010-09-10 13:40 -0400 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/f6b107f3629a 6942092: Loader-constraint test is failing Summary: Fix test string compare to match source update Reviewed-by: dcubed, phh ! test/runtime/6626217/Test6626217.sh Changeset: bdd14610f204 Author: never Date: 2010-09-15 20:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/bdd14610f204 6984979: OptimizeFill misses some cases with an odd memory graph Reviewed-by: kvn ! src/share/vm/opto/loopTransform.cpp Changeset: a367fee99714 Author: phh Date: 2010-10-08 11:26 -0400 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/a367fee99714 Added tag hs19-b07 for changeset bdd14610f204 ! .hgtags Changeset: 59244c77684a Author: kamg Date: 2010-09-21 14:41 -0400 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/59244c77684a 6975210: java.lang.VerifyError in some of JCK tests Summary: Naked oop in verificationType::is_reference_assignable_from() Reviewed-by: never, kvn, coleenp ! src/share/vm/classfile/verificationType.cpp Changeset: c437eeffbd7e Author: trims Date: 2010-09-22 13:37 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/c437eeffbd7e 6985396: Bump the HS19 build number to 08 Summary: Update the HS19 build number to 08 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 23f1a60e5e43 Author: trims Date: 2010-09-22 13:40 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/23f1a60e5e43 6982489: Update Hotspot 19 to use jdk6u21p as the default JPRT release target Summary: Change the HS19 default JPRT target to be jdk6perf Reviewed-by: ohair ! make/jprt.properties Changeset: 0c5c902506a0 Author: jcoomes Date: 2010-09-27 22:36 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/0c5c902506a0 6423256: GC stacks should use a better data structure 6942771: SEGV in ParScanThreadState::take_from_overflow_stack Reviewed-by: apetrusenko, ysr, pbk ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/includeDB_gc_serial ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/includeDB_core ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp + src/share/vm/utilities/stack.hpp + src/share/vm/utilities/stack.inline.hpp ! src/share/vm/utilities/taskqueue.hpp Changeset: e076c91fb9b6 Author: never Date: 2010-09-22 13:01 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/e076c91fb9b6 6982537: Crash in Node*step_through_mergemem Reviewed-by: kvn ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/memnode.cpp Changeset: bda2024ae52b Author: phh Date: 2010-10-08 11:40 -0400 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/bda2024ae52b 6986028: assert(_base == Int) failed: Not an Int in CmpINode::sub Reviewed-by: kvn, twisti ! src/share/vm/opto/stringopts.cpp Changeset: 9a19ee0490e0 Author: kvn Date: 2010-09-30 18:31 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/9a19ee0490e0 6916062: assert(_inserts <= _insert_limit,"hash table overflow") in NodeHash::hash_insert Summary: Missing check for not empty worklist when puting memory node back on worklist and expecting address type update. Reviewed-by: never ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/phaseX.cpp Changeset: 53adfc40121e Author: jcoomes Date: 2010-10-01 09:19 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/53adfc40121e 6988678: fatal error deadlock handling was unintentionally disabled Reviewed-by: ysr ! src/share/vm/runtime/thread.cpp Changeset: 243e95e6a37d Author: never Date: 2010-09-08 20:28 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/243e95e6a37d 6965815: OptimizeStringConcat: assert(!q->is_MergeMem()) failed with specjbb2000 Reviewed-by: kvn ! src/share/vm/opto/graphKit.cpp Changeset: c53baab9d988 Author: never Date: 2010-10-05 11:16 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/c53baab9d988 6988018: dtrace/hotspot/MethodInvocation/MethodInvocation002 crashes with client compiler Reviewed-by: iveresov, kvn, kamg ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 61e2d45faa7f Author: minqi Date: 2010-10-07 13:49 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/61e2d45faa7f 6966589: hs16-b08 causes java.lang.StackOverflowError Reviewed-by: mchung, dholmes, chrisphi ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp Changeset: 2b2e90b406ca Author: minqi Date: 2010-10-07 13:51 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/2b2e90b406ca 6990124: supplemental fix for 6361589 Reviewed-by: coleenp, chrisphi ! src/share/vm/utilities/vmError.cpp Changeset: 3ea92ddc62ff Author: never Date: 2010-10-07 13:11 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/3ea92ddc62ff 6980792: Crash "exception happened outside interpreter, nmethods and vtable stubs (1)" Reviewed-by: kvn ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/runtime.cpp From erik.trimble at oracle.com Fri Oct 8 15:24:18 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Fri, 08 Oct 2010 22:24:18 +0000 Subject: hg: hsx/hsx19/baseline: 2 new changesets Message-ID: <20101008222422.1B16647FEC@hg.openjdk.java.net> Changeset: 8da8d443833d Author: trims Date: 2010-10-08 15:20 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/8da8d443833d Added tag hs19-b08 for changeset 23f1a60e5e43 ! .hgtags Changeset: 13edc857b967 Author: trims Date: 2010-10-08 13:29 -0700 URL: http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/13edc857b967 6990756: Bump the HS19 build number to 09 Summary: Update the HS19 build number to 09 Reviewed-by: jcoomes ! make/hotspot_version From David.Holmes at oracle.com Fri Oct 8 15:43:09 2010 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 09 Oct 2010 08:43:09 +1000 Subject: review (S) for 6970683: improvements to hs_err output In-Reply-To: <4CAF40E6.8070803@oracle.com> References: <4CAF40E6.8070803@oracle.com> Message-ID: <4CAF9E7D.8080002@oracle.com> Hi Coleen, Coleen Phillimore said the following on 10/09/10 02:03: > This change looks good to me. I missed when print_location() was added > for the registers, but it does a lot of things that we used to consider > unsafe from the error handler. And I didn't like all the white space. It was added (by me) as part of the SE-Embedded integration but was only enabled for ARM and PPC at the time. Note that it is the hs_find functionality from debug.cpp transferred into the error handler. And yes, sometime those checks will induce secondary crashes. What whitespace are you referring to? > wonder if you should check for Universe::is_initialized() in vmError > before calling this? No idea. As I said the code came from the debug.cpp code - no better, no worse. David > > Can you attach an "after" version of hs_err? I guess I can get one of > my own pretty easily after you check this in, but I'd like to see one > first. > > Lastly, what sort of problems can you diagnose from the code cache bounds? > > Thanks, > Coleen > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6970683 >> >> 6970683: improvements to hs_err output >> Reviewed-by: >> >> There are a few things missing from the hs_err dump that would be >> useful. First we don't dump the sparc L and I registers. Second some >> information about the size and contents of the code cache would be >> useful. Third we should dump a larger region around the faulting >> instruction. Additionally the new register to memory mapping output >> can crash which stops us from getting the stack and instructions at >> the faulting pc, so I moved it into it's own section. block_start >> would assert in some cases so I augmented existing logic to just >> return null. I also changed the formatting to remove all the extra >> whitespace and made some of the output more compact and eliminated >> most of the useless whitespace. >> From David.Holmes at oracle.com Fri Oct 8 15:54:13 2010 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 09 Oct 2010 08:54:13 +1000 Subject: hotspot messages about the future? In-Reply-To: References: Message-ID: <4CAFA115.4040204@oracle.com> Kelly O'Hair said the following on 10/09/10 05:21: > > When did the hotspot -XX options start spitting out messages like this? I can't tell exactly, but this was there when HS moved to Mercurial. I think it is done whenever an option has become obsolete, or is not applicable/appropriate for the given usage. David > > svc6<1263> java -XX:+CMSClassUnloadingEnabled > -XX:+CMSPermGenSweepingEnabled -version > Please use CMSClassUnloadingEnabled in place of > CMSPermGenSweepingEnabled in the future > java version "1.6.0_10" > Java(TM) SE Runtime Environment (build 1.6.0_10-b33) > Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode) > > > I always thought silence was golden? > > -kto > From john.pampuch at oracle.com Fri Oct 8 16:06:30 2010 From: john.pampuch at oracle.com (John Pampuch) Date: Fri, 08 Oct 2010 16:06:30 -0700 Subject: hotspot messages about the future? In-Reply-To: <4CAFA115.4040204@oracle.com> References: <4CAFA115.4040204@oracle.com> Message-ID: <4CAFA3F6.4090500@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101008/287552ad/attachment-0001.html From kelly.ohair at oracle.com Fri Oct 8 17:21:43 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 8 Oct 2010 17:21:43 -0700 Subject: hotspot messages about the future? In-Reply-To: <4CAFA3F6.4090500@oracle.com> References: <4CAFA115.4040204@oracle.com> <4CAFA3F6.4090500@oracle.com> Message-ID: There is a long list of CRs related to hotspot stdout and stderr (start with 4837953). The issue I remember is that if I write a java app that uses stdout and stderr in it's logic, and hotspot or the jdk also dumps text to stdout and stderr, it makes the java app's stdout/stderr pretty worthless. The java app needs to own stdout and stderr, in my opinion, or at a minimum it needs to own stdout. I always thought the VM was supposed to be somewhat invisible, the OZ guy behind the curtain, unseen unless something REALLY serious happens. -kto On Oct 8, 2010, at 4:06 PM, John Pampuch wrote: > My recollection is that we choose not to insert messages like this. > From my perspective, the output could get really noisy, and spurious > output in a release like that *could* affect a shell script, so it > could get annoying. > > Not sure if I'm completely right on the policy, and even if I am, it > probably isn't written down anywhere. At very least, I don't recall > us doing it before (not that I'm in a habit of checking.) > > -John > > On 10/8/10 3:54 PM, David Holmes wrote: >> >> Kelly O'Hair said the following on 10/09/10 05:21: >>> >>> When did the hotspot -XX options start spitting out messages like >>> this? >> >> I can't tell exactly, but this was there when HS moved to Mercurial. >> >> I think it is done whenever an option has become obsolete, or is >> not applicable/appropriate for the given usage. >> >> David >> >>> >>> svc6<1263> java -XX:+CMSClassUnloadingEnabled -XX: >>> +CMSPermGenSweepingEnabled -version >>> Please use CMSClassUnloadingEnabled in place of >>> CMSPermGenSweepingEnabled in the future >>> java version "1.6.0_10" >>> Java(TM) SE Runtime Environment (build 1.6.0_10-b33) >>> Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode) >>> >>> >>> I always thought silence was golden? >>> >>> -kto >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101008/6a4868aa/attachment.html From john.r.rose at oracle.com Fri Oct 8 18:04:12 2010 From: john.r.rose at oracle.com (John Rose) Date: Fri, 8 Oct 2010 18:04:12 -0700 Subject: hotspot messages about the future? In-Reply-To: References: <4CAFA115.4040204@oracle.com> <4CAFA3F6.4090500@oracle.com> Message-ID: <7E92D93A-F96A-4088-AF43-435409F95C25@oracle.com> Absolute silence is a fine ideal. As long as we are less than ideal, there's also this: -XX:+UnlockDiagnosticVMOptions -XX:-DisplayVMOutput (Seems a bit odd to have to unlock diagnostics to turn them off, but there's where it stands today.) And conversely: -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -- John On Oct 8, 2010, at 5:21 PM, Kelly O'Hair wrote: > There is a long list of CRs related to hotspot stdout and stderr (start with 4837953). > > The issue I remember is that if I write a java app that uses stdout and stderr in it's logic, > and hotspot or the jdk also dumps text to stdout and stderr, it makes the java app's stdout/stderr > pretty worthless. > > The java app needs to own stdout and stderr, in my opinion, or at a minimum it needs to own stdout. > > I always thought the VM was supposed to be somewhat invisible, the OZ guy behind the curtain, unseen > unless something REALLY serious happens. > > -kto > > On Oct 8, 2010, at 4:06 PM, John Pampuch wrote: > >> My recollection is that we choose not to insert messages like this. From my perspective, the output could get really noisy, and spurious output in a release like that *could* affect a shell script, so it could get annoying. >> >> Not sure if I'm completely right on the policy, and even if I am, it probably isn't written down anywhere. At very least, I don't recall us doing it before (not that I'm in a habit of checking.) >> >> -John >> >> On 10/8/10 3:54 PM, David Holmes wrote: >>> Kelly O'Hair said the following on 10/09/10 05:21: >>>> >>>> When did the hotspot -XX options start spitting out messages like this? >>> >>> I can't tell exactly, but this was there when HS moved to Mercurial. >>> >>> I think it is done whenever an option has become obsolete, or is not applicable/appropriate for the given usage. >>> >>> David >>> >>>> >>>> svc6<1263> java -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -version >>>> Please use CMSClassUnloadingEnabled in place of CMSPermGenSweepingEnabled in the future >>>> java version "1.6.0_10" >>>> Java(TM) SE Runtime Environment (build 1.6.0_10-b33) >>>> Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode) >>>> >>>> >>>> I always thought silence was golden? >>>> >>>> -kto >>>> > From karen.kinnear at oracle.com Fri Oct 8 18:24:07 2010 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 8 Oct 2010 21:24:07 -0400 Subject: hotspot messages about the future? In-Reply-To: <7E92D93A-F96A-4088-AF43-435409F95C25@oracle.com> References: <4CAFA115.4040204@oracle.com> <4CAFA3F6.4090500@oracle.com> <7E92D93A-F96A-4088-AF43-435409F95C25@oracle.com> Message-ID: Yes, the VM is supposed to be invisible, we spent years trying to clean this up. Looks like we have a bug? thanks, Karen On Oct 8, 2010, at 9:04 PM, John Rose wrote: > Absolute silence is a fine ideal. As long as we are less than > ideal, there's also this: > -XX:+UnlockDiagnosticVMOptions -XX:-DisplayVMOutput > > (Seems a bit odd to have to unlock diagnostics to turn them off, but > there's where it stands today.) > > And conversely: > -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput > > -- John > > On Oct 8, 2010, at 5:21 PM, Kelly O'Hair wrote: > >> There is a long list of CRs related to hotspot stdout and stderr >> (start with 4837953). >> >> The issue I remember is that if I write a java app that uses stdout >> and stderr in it's logic, >> and hotspot or the jdk also dumps text to stdout and stderr, it >> makes the java app's stdout/stderr >> pretty worthless. >> >> The java app needs to own stdout and stderr, in my opinion, or at a >> minimum it needs to own stdout. >> >> I always thought the VM was supposed to be somewhat invisible, the >> OZ guy behind the curtain, unseen >> unless something REALLY serious happens. >> >> -kto >> >> On Oct 8, 2010, at 4:06 PM, John Pampuch wrote: >> >>> My recollection is that we choose not to insert messages like >>> this. From my perspective, the output could get really noisy, and >>> spurious output in a release like that *could* affect a shell >>> script, so it could get annoying. >>> >>> Not sure if I'm completely right on the policy, and even if I am, >>> it probably isn't written down anywhere. At very least, I don't >>> recall us doing it before (not that I'm in a habit of checking.) >>> >>> -John >>> >>> On 10/8/10 3:54 PM, David Holmes wrote: >>>> Kelly O'Hair said the following on 10/09/10 05:21: >>>>> >>>>> When did the hotspot -XX options start spitting out messages >>>>> like this? >>>> >>>> I can't tell exactly, but this was there when HS moved to >>>> Mercurial. >>>> >>>> I think it is done whenever an option has become obsolete, or is >>>> not applicable/appropriate for the given usage. >>>> >>>> David >>>> >>>>> >>>>> svc6<1263> java -XX:+CMSClassUnloadingEnabled -XX: >>>>> +CMSPermGenSweepingEnabled -version >>>>> Please use CMSClassUnloadingEnabled in place of >>>>> CMSPermGenSweepingEnabled in the future >>>>> java version "1.6.0_10" >>>>> Java(TM) SE Runtime Environment (build 1.6.0_10-b33) >>>>> Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode) >>>>> >>>>> >>>>> I always thought silence was golden? >>>>> >>>>> -kto >>>>> >> > From David.Holmes at oracle.com Fri Oct 8 19:00:07 2010 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 09 Oct 2010 12:00:07 +1000 Subject: hotspot messages about the future? In-Reply-To: References: <4CAFA115.4040204@oracle.com> <4CAFA3F6.4090500@oracle.com> <7E92D93A-F96A-4088-AF43-435409F95C25@oracle.com> Message-ID: <4CAFCCA7.9040902@oracle.com> Karen Kinnear said the following on 10/09/10 11:24: > Yes, the VM is supposed to be invisible, we spent years trying to clean > this up. > > Looks like we have a bug? I assume it is okay to print messages if the selected option causes initialization of the VM to fail? And also okay if such messages only occur when "logging" and/or "verbose" flags are enabled. Looking in arguments.cpp we currently have a mix of non-fatal messages, some as warning()s and others (like these) just as printfs. Seems to me we need a consistent policy here on what mechanism to use for these kinds of "warnings" and how to control them. That would seem to be the warning() function now that Keith is doing a fix to allow warnings to be turned on and off. David > thanks, > Karen > > On Oct 8, 2010, at 9:04 PM, John Rose wrote: > >> Absolute silence is a fine ideal. As long as we are less than ideal, >> there's also this: >> -XX:+UnlockDiagnosticVMOptions -XX:-DisplayVMOutput >> >> (Seems a bit odd to have to unlock diagnostics to turn them off, but >> there's where it stands today.) >> >> And conversely: >> -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput >> >> -- John >> >> On Oct 8, 2010, at 5:21 PM, Kelly O'Hair wrote: >> >>> There is a long list of CRs related to hotspot stdout and stderr >>> (start with 4837953). >>> >>> The issue I remember is that if I write a java app that uses stdout >>> and stderr in it's logic, >>> and hotspot or the jdk also dumps text to stdout and stderr, it makes >>> the java app's stdout/stderr >>> pretty worthless. >>> >>> The java app needs to own stdout and stderr, in my opinion, or at a >>> minimum it needs to own stdout. >>> >>> I always thought the VM was supposed to be somewhat invisible, the OZ >>> guy behind the curtain, unseen >>> unless something REALLY serious happens. >>> >>> -kto >>> >>> On Oct 8, 2010, at 4:06 PM, John Pampuch wrote: >>> >>>> My recollection is that we choose not to insert messages like this. >>>> From my perspective, the output could get really noisy, and spurious >>>> output in a release like that *could* affect a shell script, so it >>>> could get annoying. >>>> >>>> Not sure if I'm completely right on the policy, and even if I am, it >>>> probably isn't written down anywhere. At very least, I don't recall >>>> us doing it before (not that I'm in a habit of checking.) >>>> >>>> -John >>>> >>>> On 10/8/10 3:54 PM, David Holmes wrote: >>>>> Kelly O'Hair said the following on 10/09/10 05:21: >>>>>> >>>>>> When did the hotspot -XX options start spitting out messages like >>>>>> this? >>>>> >>>>> I can't tell exactly, but this was there when HS moved to Mercurial. >>>>> >>>>> I think it is done whenever an option has become obsolete, or is >>>>> not applicable/appropriate for the given usage. >>>>> >>>>> David >>>>> >>>>>> >>>>>> svc6<1263> java -XX:+CMSClassUnloadingEnabled >>>>>> -XX:+CMSPermGenSweepingEnabled -version >>>>>> Please use CMSClassUnloadingEnabled in place of >>>>>> CMSPermGenSweepingEnabled in the future >>>>>> java version "1.6.0_10" >>>>>> Java(TM) SE Runtime Environment (build 1.6.0_10-b33) >>>>>> Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode) >>>>>> >>>>>> >>>>>> I always thought silence was golden? >>>>>> >>>>>> -kto >>>>>> >>> >> > From john.coomes at oracle.com Fri Oct 8 21:08:24 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 09 Oct 2010 04:08:24 +0000 Subject: hg: jdk7/hotspot/hotspot: 11 new changesets Message-ID: <20101009040844.6E52847FF9@hg.openjdk.java.net> Changeset: 8b10f48633dc Author: jmasa Date: 2010-09-20 14:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8b10f48633dc 6984287: Regularize how GC parallel workers are specified. Summary: Associate number of GC workers with the workgang as opposed to the task. Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! 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_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/includeDB_core ! 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/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.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: 22cace5e30b5 Author: jcoomes Date: 2010-09-08 16:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/22cace5e30b5 6983296: build sanity checks for jdk7 should require SS12u1 Reviewed-by: ohair ! make/solaris/makefiles/sparcWorks.make Changeset: 4805b9f4779e Author: johnc Date: 2010-09-28 09:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4805b9f4779e 6941395: G1: Use only lock-free versions of region stack push() and pop() Summary: Re-enable use of the lock-free versions of region stack push() and pop() by recording aborted regions in a thread-local structure, which are then processed when scanning of the region stack restarts. The previous locking versions of these routines are retained for diagnostic purposes. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: 894b1d7c7e01 Author: jcoomes Date: 2010-09-28 15:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/894b1d7c7e01 6423256: GC stacks should use a better data structure 6942771: SEGV in ParScanThreadState::take_from_overflow_stack Reviewed-by: apetrusenko, ysr, pbk ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/includeDB_gc_serial ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/includeDB_core ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp + src/share/vm/utilities/stack.hpp + src/share/vm/utilities/stack.inline.hpp ! src/share/vm/utilities/taskqueue.hpp Changeset: c99c53f07c14 Author: ysr Date: 2010-09-29 16:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c99c53f07c14 6692906: CMS: parallel concurrent marking may be prone to hanging or stalling mutators for periods of time Summary: Inserted missing yield(check)s in closures used during the work-stealing phase of parallel concurrent marking, a missing synchronous yield-request in the cms perm gen allocation path, and a terminator-terminator for the offer_termination invocation that monitors the yield status of the concurrent marking task. Elaborated some documentation comments and made some task queue termination loop flags configurable at start-up to aid debugging in the field. Reviewed-by: jmasa, johnc, poonam ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 8f6f7587d292 Author: jcoomes Date: 2010-09-30 12:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8f6f7587d292 6988678: fatal error deadlock handling was unintentionally disabled Reviewed-by: ysr ! src/share/vm/runtime/thread.cpp Changeset: e41cd7fd68a6 Author: ysr Date: 2010-10-01 16:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e41cd7fd68a6 6794422: Perm gen expansion policy for concurrent collectors Summary: Concurrent collectors should expand the perm gen without a full STW GC, but possibly by triggering a concurrent collection. Temporary band-aid for G1 where no concurrent collection is kicked off since the perm gen is not collected concurrently. Reviewed-by: johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp ! src/share/vm/includeDB_core ! src/share/vm/memory/permGen.cpp ! src/share/vm/memory/permGen.hpp Changeset: 4e0094bc41fa Author: johnc Date: 2010-10-01 18:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4e0094bc41fa 6983311: G1: LoopTest hangs when run with -XX:+ExplicitInvokesConcurrent Summary: Clear the concurrent marking "in progress" flag while the FullGCCount_lock is held. This avoids a race that can cause back to back System.gc() calls, when ExplicitGCInvokesConcurrent is enabled, to fail to initiate a marking cycle causing the requesting thread to hang. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 32a1f7bf0c21 Author: johnc Date: 2010-10-01 21:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/32a1f7bf0c21 Merge Changeset: 6e0aac35bfa9 Author: tonyp Date: 2010-10-01 16:43 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6e0aac35bfa9 6980838: G1: guarantee(false) failed: thread has an unexpected active value in its SATB queue Summary: Under certain circumstances a safepoint could happen between a JavaThread object being created and that object being added to the Java threads list. This could cause the active field of that thread's SATB queue to get out-of-sync with respect to the other Java threads. The solution is to activate the SATB queue, when necessary, before adding the thread to the Java threads list, not when the JavaThread object is created. The changeset also includes a small fix to rename the surrogate locker thread from "Surrogate Locker Thread (CMS)" to "Surrogate Locker Thread (Concurrent GC)" since it's also used in G1. Reviewed-by: iveresov, ysr, johnc, jcoomes ! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 0715f0cf171d Author: jcoomes Date: 2010-10-08 09:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0715f0cf171d Merge ! src/share/vm/includeDB_core ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp From y.s.ramakrishna at oracle.com Mon Oct 11 10:29:48 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Mon, 11 Oct 2010 10:29:48 -0700 Subject: hotspot messages about the future? In-Reply-To: <4CAFCCA7.9040902@oracle.com> References: <4CAFA115.4040204@oracle.com> <4CAFA3F6.4090500@oracle.com> <7E92D93A-F96A-4088-AF43-435409F95C25@oracle.com> <4CAFCCA7.9040902@oracle.com> Message-ID: <4CB3498C.9030205@oracle.com> Sorry to be late on the discussion. Yes, I see GC's fingerprints on some of these messages, some rather recent, although I am not sure we did this first or were just following earlier precedent. I agree with David. Has a bug been filed? thanks. -- ramki On 10/8/2010 7:00 PM, David Holmes wrote: > Karen Kinnear said the following on 10/09/10 11:24: >> Yes, the VM is supposed to be invisible, we spent years trying to clean this up. >> >> Looks like we have a bug? > > I assume it is okay to print messages if the selected option causes initialization of the VM to > fail? And also okay if such messages only occur when "logging" and/or "verbose" flags are enabled. > > Looking in arguments.cpp we currently have a mix of non-fatal messages, some as warning()s and > others (like these) just as printfs. > > Seems to me we need a consistent policy here on what mechanism to use for these kinds of "warnings" > and how to control them. That would seem to be the warning() function now that Keith is doing a fix > to allow warnings to be turned on and off. > > David > >> thanks, >> Karen >> >> On Oct 8, 2010, at 9:04 PM, John Rose wrote: >> >>> Absolute silence is a fine ideal. As long as we are less than ideal, there's also this: >>> -XX:+UnlockDiagnosticVMOptions -XX:-DisplayVMOutput >>> >>> (Seems a bit odd to have to unlock diagnostics to turn them off, but there's where it stands today.) >>> >>> And conversely: >>> -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput >>> >>> -- John >>> >>> On Oct 8, 2010, at 5:21 PM, Kelly O'Hair wrote: >>> >>>> There is a long list of CRs related to hotspot stdout and stderr (start with 4837953). >>>> >>>> The issue I remember is that if I write a java app that uses stdout and stderr in it's logic, >>>> and hotspot or the jdk also dumps text to stdout and stderr, it makes the java app's stdout/stderr >>>> pretty worthless. >>>> >>>> The java app needs to own stdout and stderr, in my opinion, or at a minimum it needs to own stdout. >>>> >>>> I always thought the VM was supposed to be somewhat invisible, the OZ guy behind the curtain, >>>> unseen >>>> unless something REALLY serious happens. >>>> >>>> -kto >>>> >>>> On Oct 8, 2010, at 4:06 PM, John Pampuch wrote: >>>> >>>>> My recollection is that we choose not to insert messages like this. From my perspective, the >>>>> output could get really noisy, and spurious output in a release like that *could* affect a >>>>> shell script, so it could get annoying. >>>>> >>>>> Not sure if I'm completely right on the policy, and even if I am, it probably isn't written >>>>> down anywhere. At very least, I don't recall us doing it before (not that I'm in a habit of >>>>> checking.) >>>>> >>>>> -John >>>>> >>>>> On 10/8/10 3:54 PM, David Holmes wrote: >>>>>> Kelly O'Hair said the following on 10/09/10 05:21: >>>>>>> >>>>>>> When did the hotspot -XX options start spitting out messages like this? >>>>>> >>>>>> I can't tell exactly, but this was there when HS moved to Mercurial. >>>>>> >>>>>> I think it is done whenever an option has become obsolete, or is not applicable/appropriate >>>>>> for the given usage. >>>>>> >>>>>> David >>>>>> >>>>>>> >>>>>>> svc6<1263> java -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -version >>>>>>> Please use CMSClassUnloadingEnabled in place of CMSPermGenSweepingEnabled in the future >>>>>>> java version "1.6.0_10" >>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_10-b33) >>>>>>> Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode) >>>>>>> >>>>>>> >>>>>>> I always thought silence was golden? >>>>>>> >>>>>>> -kto >>>>>>> >>>> >>> >> From tom.rodriguez at oracle.COM Tue Oct 12 10:02:20 2010 From: tom.rodriguez at oracle.COM (Tom Rodriguez) Date: Tue, 12 Oct 2010 10:02:20 -0700 Subject: review (S) for 6970683: improvements to hs_err output In-Reply-To: <4CAE35B1.4040501@oracle.com> References: <4CAE35B1.4040501@oracle.com> Message-ID: <4EEF5B56-CAE5-47C7-BA78-B10E34856079@oracle.com> On Oct 7, 2010, at 2:03 PM, Vladimir Kozlov wrote: > src/share/vm/utilities/vmError.cpp change comment: > > + STEP(105, "(printing register info)") > + > + // registers, top of stack, instructions near pc fixed. > > src/share/vm/runtime/os.cpp next values are the same why print twice? > > + st->print_cr(INTPTR_FORMAT " is the thread: " > + INTPTR_FORMAT, addr, thread); I wanted to print something shorter since we dump all the threads later but I didn't closely enough about what would come out. How about this: - thread->print_on(st); + if (verbose) { + thread->print_on(st); + } else { + static char buf[256]; + thread->print_on_error(buf, sizeof(buf)); + st->print_cr(INTPTR_FORMAT " is %s", addr, buf); + } This will print out in the same one line format that the rest of VMError uses. > > src/share/vm/code/codeCache.cpp closed ")" should be "]" (or it is indication that address in not included?): > > + st->print_cr("Code Cache [" INTPTR_FORMAT ", " INTPTR_FORMAT ", " INTPTR_FORMAT ")", It's the same format we use for the other sections and yes the final address isn't included. It's the half open interval. > > also why you need to put ' ' around numbers for codecache values? Can you separate them using comma? It was a copy paste from the log sweeper printing which was xml. I've removed them. Why do you want commas? Code Cache [0xfa800000, 0xfaa40000, 0xfd800000) total_blobs=398 nmethods=299 adapters=60 free_code_cache=49158848 vs. Code Cache [0xfa800000, 0xfaa40000, 0xfd800000) total_blobs=398, nmethods=299, adapters=60, free_code_cache=49158848 > > src/os_cpu/windows_x86/vm/os_windows_x86.cpp missing #ifdef AMD64 in os::print_register_info() and end of method: > st->cr(); > } > > Also why you left Register to memory dump the same? On solaris platforms you print only register name before call to print_location() (I prefer this). Oops. I thought I'd finished the windows side. It's done now, though it hasn't been through jprt yet. > > src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp missing "=" after register name in print_register_info(). fixed. > > src/os_cpu/linux_x86/vm/os_linux_x86.cpp print_register_info() should be as in os_solaris_x86.cpp fixed. > > src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp missing print_register_info() method. Added, though not tested. tom > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6970683 >> 6970683: improvements to hs_err output >> Reviewed-by: >> There are a few things missing from the hs_err dump that would be >> useful. First we don't dump the sparc L and I registers. Second some >> information about the size and contents of the code cache would be >> useful. Third we should dump a larger region around the faulting >> instruction. Additionally the new register to memory mapping output >> can crash which stops us from getting the stack and instructions at >> the faulting pc, so I moved it into it's own section. block_start >> would assert in some cases so I augmented existing logic to just >> return null. I also changed the formatting to remove all the extra >> whitespace and made some of the output more compact and eliminated >> most of the useless whitespace. From tom.rodriguez at oracle.com Tue Oct 12 10:02:18 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 12 Oct 2010 10:02:18 -0700 Subject: review (S) for 6970683: improvements to hs_err output In-Reply-To: <4CAF40E6.8070803@oracle.com> References: <4CAF40E6.8070803@oracle.com> Message-ID: <4BB3BBA5-99B8-4AE3-87FC-6669E4F0B61F@oracle.com> On Oct 8, 2010, at 9:03 AM, Coleen Phillimore wrote: > This change looks good to me. I missed when print_location() was added for the registers, but it does a lot of things that we used to consider unsafe from the error handler. It does, though it seems like it's handled properly by the existing logic for restarting failures during dumping. Many of the routines do fairly trivial printing. If we find an oop then much more complicated printing occurs though mostly more interesting than resource allocation is really going to occur. Stack overflow conditions are likely the most dangerous possibility. > And I didn't like all the white space. I wonder if you should check for Universe::is_initialized() in vmError before calling this? Ok. > > Can you attach an "after" version of hs_err? I guess I can get one of my own pretty easily after you check this in, but I'd like to see one first. I'll generate a couple after fixing the review comments and send them out. > Lastly, what sort of problems can you diagnose from the code cache bounds? I've wanted it several times to make sure that values that appeared to be code cache values actually were. Also the counts of how full the code cache is can be useful. tom > > Thanks, > Coleen > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6970683 >> >> 6970683: improvements to hs_err output >> Reviewed-by: >> >> There are a few things missing from the hs_err dump that would be >> useful. First we don't dump the sparc L and I registers. Second some >> information about the size and contents of the code cache would be >> useful. Third we should dump a larger region around the faulting >> instruction. Additionally the new register to memory mapping output >> can crash which stops us from getting the stack and instructions at >> the faulting pc, so I moved it into it's own section. block_start >> would assert in some cases so I augmented existing logic to just >> return null. I also changed the formatting to remove all the extra >> whitespace and made some of the output more compact and eliminated >> most of the useless whitespace. >> From vladimir.kozlov at oracle.com Tue Oct 12 11:04:57 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Oct 2010 11:04:57 -0700 Subject: review (S) for 6970683: improvements to hs_err output In-Reply-To: <4EEF5B56-CAE5-47C7-BA78-B10E34856079@oracle.com> References: <4CAE35B1.4040501@oracle.com> <4EEF5B56-CAE5-47C7-BA78-B10E34856079@oracle.com> Message-ID: <4CB4A349.3090302@oracle.com> Tom Rodriguez wrote: >> src/share/vm/runtime/os.cpp next values are the same why print twice? >> >> + st->print_cr(INTPTR_FORMAT " is the thread: " >> + INTPTR_FORMAT, addr, thread); > > I wanted to print something shorter since we dump all the threads later but I didn't closely enough about what would come out. How about this: > > - thread->print_on(st); > + if (verbose) { > + thread->print_on(st); > + } else { > + static char buf[256]; > + thread->print_on_error(buf, sizeof(buf)); > + st->print_cr(INTPTR_FORMAT " is %s", addr, buf); > + } > > This will print out in the same one line format that the rest of VMError uses. It is too many lines (two :) ). I would just say it is thread, we can look it down in hs_err for more info. - thread->print_on(st); + if (verbose) { + thread->print_on(st); + } else { + st->print_cr(INTPTR_FORMAT " is the thread", addr); + } > >> src/share/vm/code/codeCache.cpp closed ")" should be "]" (or it is indication that address in not included?): >> >> + st->print_cr("Code Cache [" INTPTR_FORMAT ", " INTPTR_FORMAT ", " INTPTR_FORMAT ")", > > It's the same format we use for the other sections and yes the final address isn't included. It's the half open interval. Then it is fine. > >> also why you need to put ' ' around numbers for codecache values? Can you separate them using comma? > > It was a copy paste from the log sweeper printing which was xml. I've removed them. Why do you want commas? > > Code Cache [0xfa800000, 0xfaa40000, 0xfd800000) > total_blobs=398 nmethods=299 adapters=60 free_code_cache=49158848 > > vs. > > Code Cache [0xfa800000, 0xfaa40000, 0xfd800000) > total_blobs=398, nmethods=299, adapters=60, free_code_cache=49158848 > I am fine without commas (less file size). > >> src/os_cpu/windows_x86/vm/os_windows_x86.cpp missing #ifdef AMD64 in os::print_register_info() and end of method: >> st->cr(); >> } >> >> Also why you left Register to memory dump the same? On solaris platforms you print only register name before call to print_location() (I prefer this). > > Oops. I thought I'd finished the windows side. It's done now, though it hasn't been through jprt yet. I don't see that you updated print_register_info(), it is still original (several lines per reg). Thanks, Vladimir > > > tom > >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/6970683 >>> 6970683: improvements to hs_err output >>> Reviewed-by: >>> There are a few things missing from the hs_err dump that would be >>> useful. First we don't dump the sparc L and I registers. Second some >>> information about the size and contents of the code cache would be >>> useful. Third we should dump a larger region around the faulting >>> instruction. Additionally the new register to memory mapping output >>> can crash which stops us from getting the stack and instructions at >>> the faulting pc, so I moved it into it's own section. block_start >>> would assert in some cases so I augmented existing logic to just >>> return null. I also changed the formatting to remove all the extra >>> whitespace and made some of the output more compact and eliminated >>> most of the useless whitespace. > From tom.rodriguez at oracle.com Tue Oct 12 12:07:08 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 12 Oct 2010 12:07:08 -0700 Subject: review (S) for 6970683: improvements to hs_err output In-Reply-To: <4CB4A349.3090302@oracle.com> References: <4CAE35B1.4040501@oracle.com> <4EEF5B56-CAE5-47C7-BA78-B10E34856079@oracle.com> <4CB4A349.3090302@oracle.com> Message-ID: <6389ADFB-3044-41A0-B3C2-F50D6C170F70@oracle.com> On Oct 12, 2010, at 11:04 AM, Vladimir Kozlov wrote: > Tom Rodriguez wrote: >>> src/share/vm/runtime/os.cpp next values are the same why print twice? >>> >>> + st->print_cr(INTPTR_FORMAT " is the thread: " >>> + INTPTR_FORMAT, addr, thread); >> I wanted to print something shorter since we dump all the threads later but I didn't closely enough about what would come out. How about this: >> - thread->print_on(st); + if (verbose) { + thread->print_on(st); + } else { + static char buf[256]; + thread->print_on_error(buf, sizeof(buf)); + st->print_cr(INTPTR_FORMAT " is %s", addr, buf); + } This will print out in the same one line format that the rest of VMError uses. > > It is too many lines (two :) ). I would just say it is thread, we can look it down in hs_err for more info. > > - thread->print_on(st); > + if (verbose) { > + thread->print_on(st); > + } else { > + st->print_cr(INTPTR_FORMAT " is the thread", addr); > + } st->print_cr(INTPTR_FORMAT " is a thread", addr); > >>> src/share/vm/code/codeCache.cpp closed ")" should be "]" (or it is indication that address in not included?): >>> >>> + st->print_cr("Code Cache [" INTPTR_FORMAT ", " INTPTR_FORMAT ", " INTPTR_FORMAT ")", >> It's the same format we use for the other sections and yes the final address isn't included. It's the half open interval. > > Then it is fine. > >>> also why you need to put ' ' around numbers for codecache values? Can you separate them using comma? >> It was a copy paste from the log sweeper printing which was xml. I've removed them. Why do you want commas? >> Code Cache [0xfa800000, 0xfaa40000, 0xfd800000) >> total_blobs=398 nmethods=299 adapters=60 free_code_cache=49158848 >> vs. >> Code Cache [0xfa800000, 0xfaa40000, 0xfd800000) >> total_blobs=398, nmethods=299, adapters=60, free_code_cache=49158848 > > I am fine without commas (less file size). Ok. > >>> src/os_cpu/windows_x86/vm/os_windows_x86.cpp missing #ifdef AMD64 in os::print_register_info() and end of method: >>> st->cr(); >>> } >>> >>> Also why you left Register to memory dump the same? On solaris platforms you print only register name before call to print_location() (I prefer this). >> Oops. I thought I'd finished the windows side. It's done now, though it hasn't been through jprt yet. > > I don't see that you updated print_register_info(), it is still original (several lines per reg). I've updated the webrev. There were also extra _cr's in the os_linux_x86 code that I removed. tom > > Thanks, > Vladimir > >> tom >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/6970683 >>>> 6970683: improvements to hs_err output >>>> Reviewed-by: >>>> There are a few things missing from the hs_err dump that would be >>>> useful. First we don't dump the sparc L and I registers. Second some >>>> information about the size and contents of the code cache would be >>>> useful. Third we should dump a larger region around the faulting >>>> instruction. Additionally the new register to memory mapping output >>>> can crash which stops us from getting the stack and instructions at >>>> the faulting pc, so I moved it into it's own section. block_start >>>> would assert in some cases so I augmented existing logic to just >>>> return null. I also changed the formatting to remove all the extra >>>> whitespace and made some of the output more compact and eliminated >>>> most of the useless whitespace. From vladimir.kozlov at oracle.com Tue Oct 12 12:27:29 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Oct 2010 12:27:29 -0700 Subject: review (S) for 6970683: improvements to hs_err output In-Reply-To: <6389ADFB-3044-41A0-B3C2-F50D6C170F70@oracle.com> References: <4CAE35B1.4040501@oracle.com> <4EEF5B56-CAE5-47C7-BA78-B10E34856079@oracle.com> <4CB4A349.3090302@oracle.com> <6389ADFB-3044-41A0-B3C2-F50D6C170F70@oracle.com> Message-ID: <4CB4B6A1.80206@oracle.com> Looks good. One thing I notice is os_solaris_x86.cpp doesn't have' REG_' in reg names in 32-bit case but os_linux_x86.cpp has it. Why such difference? Thanks, Vladimir Tom Rodriguez wrote: > On Oct 12, 2010, at 11:04 AM, Vladimir Kozlov wrote: > >> Tom Rodriguez wrote: >>>> src/share/vm/runtime/os.cpp next values are the same why print twice? >>>> >>>> + st->print_cr(INTPTR_FORMAT " is the thread: " >>>> + INTPTR_FORMAT, addr, thread); >>> I wanted to print something shorter since we dump all the threads later but I didn't closely enough about what would come out. How about this: >>> - thread->print_on(st); + if (verbose) { + thread->print_on(st); + } else { + static char buf[256]; + thread->print_on_error(buf, sizeof(buf)); + st->print_cr(INTPTR_FORMAT " is %s", addr, buf); + } This will print out in the same one line format that the rest of VMError uses. >> It is too many lines (two :) ). I would just say it is thread, we can look it down in hs_err for more info. >> >> - thread->print_on(st); >> + if (verbose) { >> + thread->print_on(st); >> + } else { >> + st->print_cr(INTPTR_FORMAT " is the thread", addr); >> + } > > st->print_cr(INTPTR_FORMAT " is a thread", addr); > >>>> src/share/vm/code/codeCache.cpp closed ")" should be "]" (or it is indication that address in not included?): >>>> >>>> + st->print_cr("Code Cache [" INTPTR_FORMAT ", " INTPTR_FORMAT ", " INTPTR_FORMAT ")", >>> It's the same format we use for the other sections and yes the final address isn't included. It's the half open interval. >> Then it is fine. >> >>>> also why you need to put ' ' around numbers for codecache values? Can you separate them using comma? >>> It was a copy paste from the log sweeper printing which was xml. I've removed them. Why do you want commas? >>> Code Cache [0xfa800000, 0xfaa40000, 0xfd800000) >>> total_blobs=398 nmethods=299 adapters=60 free_code_cache=49158848 >>> vs. >>> Code Cache [0xfa800000, 0xfaa40000, 0xfd800000) >>> total_blobs=398, nmethods=299, adapters=60, free_code_cache=49158848 >> I am fine without commas (less file size). > > Ok. > >>>> src/os_cpu/windows_x86/vm/os_windows_x86.cpp missing #ifdef AMD64 in os::print_register_info() and end of method: >>>> st->cr(); >>>> } >>>> >>>> Also why you left Register to memory dump the same? On solaris platforms you print only register name before call to print_location() (I prefer this). >>> Oops. I thought I'd finished the windows side. It's done now, though it hasn't been through jprt yet. >> I don't see that you updated print_register_info(), it is still original (several lines per reg). > > I've updated the webrev. There were also extra _cr's in the os_linux_x86 code that I removed. > > tom > >> Thanks, >> Vladimir >> >>> tom >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> http://cr.openjdk.java.net/~never/6970683 >>>>> 6970683: improvements to hs_err output >>>>> Reviewed-by: >>>>> There are a few things missing from the hs_err dump that would be >>>>> useful. First we don't dump the sparc L and I registers. Second some >>>>> information about the size and contents of the code cache would be >>>>> useful. Third we should dump a larger region around the faulting >>>>> instruction. Additionally the new register to memory mapping output >>>>> can crash which stops us from getting the stack and instructions at >>>>> the faulting pc, so I moved it into it's own section. block_start >>>>> would assert in some cases so I augmented existing logic to just >>>>> return null. I also changed the formatting to remove all the extra >>>>> whitespace and made some of the output more compact and eliminated >>>>> most of the useless whitespace. > From tom.rodriguez at oracle.com Tue Oct 12 12:44:46 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 12 Oct 2010 12:44:46 -0700 Subject: review (S) for 6970683: improvements to hs_err output In-Reply-To: <4CB4B6A1.80206@oracle.com> References: <4CAE35B1.4040501@oracle.com> <4EEF5B56-CAE5-47C7-BA78-B10E34856079@oracle.com> <4CB4A349.3090302@oracle.com> <6389ADFB-3044-41A0-B3C2-F50D6C170F70@oracle.com> <4CB4B6A1.80206@oracle.com> Message-ID: <5D6468B5-D2F6-4069-B7CF-0BAED50CE823@oracle.com> On Oct 12, 2010, at 12:27 PM, Vladimir Kozlov wrote: > Looks good. > > One thing I notice is os_solaris_x86.cpp doesn't have' REG_' in reg names in 32-bit case but os_linux_x86.cpp has it. Why such difference? As far as I know it's just a platform include difference. Thanks! tom > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> On Oct 12, 2010, at 11:04 AM, Vladimir Kozlov wrote: >>> Tom Rodriguez wrote: >>>>> src/share/vm/runtime/os.cpp next values are the same why print twice? >>>>> >>>>> + st->print_cr(INTPTR_FORMAT " is the thread: " >>>>> + INTPTR_FORMAT, addr, thread); >>>> I wanted to print something shorter since we dump all the threads later but I didn't closely enough about what would come out. How about this: >>>> - thread->print_on(st); + if (verbose) { + thread->print_on(st); + } else { + static char buf[256]; + thread->print_on_error(buf, sizeof(buf)); + st->print_cr(INTPTR_FORMAT " is %s", addr, buf); > + } This will print out in the same one line format that the rest of VMError uses. >>> It is too many lines (two :) ). I would just say it is thread, we can look it down in hs_err for more info. >>> >>> - thread->print_on(st); >>> + if (verbose) { >>> + thread->print_on(st); >>> + } else { >>> + st->print_cr(INTPTR_FORMAT " is the thread", addr); >>> + } >> st->print_cr(INTPTR_FORMAT " is a thread", addr); >>>>> src/share/vm/code/codeCache.cpp closed ")" should be "]" (or it is indication that address in not included?): >>>>> >>>>> + st->print_cr("Code Cache [" INTPTR_FORMAT ", " INTPTR_FORMAT ", " INTPTR_FORMAT ")", >>>> It's the same format we use for the other sections and yes the final address isn't included. It's the half open interval. >>> Then it is fine. >>> >>>>> also why you need to put ' ' around numbers for codecache values? Can you separate them using comma? >>>> It was a copy paste from the log sweeper printing which was xml. I've removed them. Why do you want commas? >>>> Code Cache [0xfa800000, 0xfaa40000, 0xfd800000) >>>> total_blobs=398 nmethods=299 adapters=60 free_code_cache=49158848 >>>> vs. >>>> Code Cache [0xfa800000, 0xfaa40000, 0xfd800000) >>>> total_blobs=398, nmethods=299, adapters=60, free_code_cache=49158848 >>> I am fine without commas (less file size). >> Ok. >>>>> src/os_cpu/windows_x86/vm/os_windows_x86.cpp missing #ifdef AMD64 in os::print_register_info() and end of method: >>>>> st->cr(); >>>>> } >>>>> >>>>> Also why you left Register to memory dump the same? On solaris platforms you print only register name before call to print_location() (I prefer this). >>>> Oops. I thought I'd finished the windows side. It's done now, though it hasn't been through jprt yet. >>> I don't see that you updated print_register_info(), it is still original (several lines per reg). >> I've updated the webrev. There were also extra _cr's in the os_linux_x86 code that I removed. >> tom >>> Thanks, >>> Vladimir >>> >>>> tom >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> http://cr.openjdk.java.net/~never/6970683 >>>>>> 6970683: improvements to hs_err output >>>>>> Reviewed-by: >>>>>> There are a few things missing from the hs_err dump that would be >>>>>> useful. First we don't dump the sparc L and I registers. Second some >>>>>> information about the size and contents of the code cache would be >>>>>> useful. Third we should dump a larger region around the faulting >>>>>> instruction. Additionally the new register to memory mapping output >>>>>> can crash which stops us from getting the stack and instructions at >>>>>> the faulting pc, so I moved it into it's own section. block_start >>>>>> would assert in some cases so I augmented existing logic to just >>>>>> return null. I also changed the formatting to remove all the extra >>>>>> whitespace and made some of the output more compact and eliminated >>>>>> most of the useless whitespace. From vladimir.kozlov at oracle.com Thu Oct 14 13:31:07 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 14 Oct 2010 20:31:07 +0000 Subject: hg: jdk7/hotspot/hotspot: 10 new changesets Message-ID: <20101014203124.A9AB847150@hg.openjdk.java.net> Changeset: 75588558f1bf Author: never Date: 2010-10-07 21:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/75588558f1bf 6980792: Crash "exception happened outside interpreter, nmethods and vtable stubs (1)" Reviewed-by: kvn ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/runtime.cpp Changeset: a222fcfba398 Author: twisti Date: 2010-10-08 02:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a222fcfba398 6990549: Zero and Shark fixes after 6978355 and 6953144 Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/interpreterRT_zero.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/shark/sharkCompiler.hpp Changeset: d55217dc206f Author: twisti Date: 2010-10-11 04:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d55217dc206f 6829194: JSR 292 needs to support compressed oops Reviewed-by: kvn, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/oop.inline.hpp Changeset: a932f331ef90 Author: twisti Date: 2010-10-12 02:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a932f331ef90 6991065: missed a review comment in 6829194 Reviewed-by: kvn ! src/share/vm/classfile/classFileParser.cpp Changeset: c393f046f4c5 Author: iveresov Date: 2010-10-12 23:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c393f046f4c5 6991512: G1 barriers fail with 64bit C1 Summary: Fix compare-and-swap intrinsic problem with G1 post-barriers and issue with branch ranges in G1 stubs on sparc Reviewed-by: never, kvn ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 5beba6174298 Author: twisti Date: 2010-10-13 01:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5beba6174298 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC Reviewed-by: never, jrose ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp + test/compiler/6987555/Test6987555.java Changeset: ecca2e3e2767 Author: twisti Date: 2010-10-13 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ecca2e3e2767 Merge Changeset: 357451a9ae6a Author: roland Date: 2010-10-13 10:29 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/357451a9ae6a 6991211: assert failure on sparc: "can not have caller-save register operands at calls" Summary: fixes sparc only assert failure following 6972540 Reviewed-by: never ! src/cpu/sparc/vm/c1_LinearScan_sparc.hpp Changeset: 94d77a279225 Author: roland Date: 2010-10-13 15:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/94d77a279225 Merge Changeset: b98784e85f71 Author: kvn Date: 2010-10-14 10:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b98784e85f71 Merge From john.coomes at oracle.com Thu Oct 14 15:37:57 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 14 Oct 2010 22:37:57 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20101014223802.C51DB47156@hg.openjdk.java.net> Changeset: c32059ef4dc0 Author: johnc Date: 2010-10-12 09:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c32059ef4dc0 6971296: G1: simplify G1RemSet class hierarchy Summary: Remove G1RemSet base class and StupidG1RemSet class; rename HRInto_G1RemSet to just G1RemSet. Reviewed-by: ysr, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! 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/g1/g1_globals.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: b14ec34b1e07 Author: jcoomes Date: 2010-10-12 11:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b14ec34b1e07 6989448: G1: refactor and simplify G1ParScanThreadState Reviewed-by: iveresov, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: ee813f7b46e4 Author: jcoomes Date: 2010-10-14 11:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ee813f7b46e4 Merge From Feng.Da at zxelec.com Thu Oct 14 18:08:04 2010 From: Feng.Da at zxelec.com (Feng.Da at zxelec.com) Date: Fri, 15 Oct 2010 09:08:04 +0800 Subject: valgrind reveal bug of openjdk during pressure test Message-ID: <6B947C8AC4195040A8C6876A496C644A0464224D@BJ-MAIL-04.vimicro.com> Hi: I'm doing a pressure test and find openjdk thrashed suse10 and crashed. The following is the valgrind report and hs_error file. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101015/20b4c8b8/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: openJdkProblems.rar Type: application/octet-stream Size: 20380 bytes Desc: openJdkProblems.rar Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101015/20b4c8b8/attachment-0001.obj From David.Holmes at oracle.com Thu Oct 14 19:08:01 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 15 Oct 2010 12:08:01 +1000 Subject: valgrind reveal bug of openjdk during pressure test In-Reply-To: <6B947C8AC4195040A8C6876A496C644A0464224D@BJ-MAIL-04.vimicro.com> References: <6B947C8AC4195040A8C6876A496C644A0464224D@BJ-MAIL-04.vimicro.com> Message-ID: <4CB7B781.20002@oracle.com> Feng.Da at zxelec.com said the following on 10/15/10 11:08: > I?m doing a pressure test and find openjdk thrashed suse10 and crashed. > The following is the valgrind report and hs_error file. Can you supply that attachment as something other than rar? I can't open it on Solaris. Thanks, David Holmes From Feng.Da at zxelec.com Thu Oct 14 19:18:54 2010 From: Feng.Da at zxelec.com (Feng.Da at zxelec.com) Date: Fri, 15 Oct 2010 10:18:54 +0800 Subject: =?gb2312?B?tPC4tDogdmFsZ3JpbmQgcmV2ZWFsIGJ1ZyBvZiBvcGVuamRrIGR1cg==?= =?gb2312?B?aW5nIHByZXNzdXJlIHRlc3Q=?= In-Reply-To: <4CB7B781.20002@oracle.com> Message-ID: <6B947C8AC4195040A8C6876A496C644A046422D4@BJ-MAIL-04.vimicro.com> Hi: OK.I used tar. A tar.gz file. -----????????----- ??????: David Holmes [mailto:David.Holmes at oracle.com] ????????: 2010??10??15?? 10:08 ??????: Feng.Da at zxelec.com ????: hotspot-dev at openjdk.java.net ????: Re: valgrind reveal bug of openjdk during pressure test Feng.Da at zxelec.com said the following on 10/15/10 11:08: > I??m doing a pressure test and find openjdk thrashed suse10 and crashed. > The following is the valgrind report and hs_error file. Can you supply that attachment as something other than rar? I can't open it on Solaris. Thanks, David Holmes -------------- next part -------------- A non-text attachment was scrubbed... Name: opeJdkProblems.tar.gz Type: application/x-gzip Size: 25930 bytes Desc: opeJdkProblems.tar.gz Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101015/ec726968/attachment-0001.bin From David.Holmes at oracle.com Thu Oct 14 19:35:05 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 15 Oct 2010 12:35:05 +1000 Subject: valgrind reveal bug of openjdk during pressure test In-Reply-To: <6B947C8AC4195040A8C6876A496C644A0464224D@BJ-MAIL-04.vimicro.com> References: <6B947C8AC4195040A8C6876A496C644A0464224D@BJ-MAIL-04.vimicro.com> Message-ID: <4CB7BDD9.3020509@oracle.com> Feng.Da at zxelec.com said the following on 10/15/10 11:08: > I?m doing a pressure test and find openjdk thrashed suse10 and crashed. > The following is the valgrind report and hs_error file. Ok I belatedly found the 7z command to access the original rar archive. The hs_err log shows: --------------- T H R E A D --------------- Current thread (0x06ea4000): GCTaskThread [stack: 0x0bf9b000,0x0c01c000] [id=31719] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0xfffff032;; Registers: EAX=0x06f5c1e8, EBX=0x16840fc0, ECX=0x06f5c1e8, EDX=0xfffff032 ESP=0x00000000, EBP=0x0c01b088, ESI=0x0c01b0b0, EDI=0x00000001 EIP=0x077febc1, CR2=0xfffff032, EFLAGS=0x00200000 Top of Stack: (sp=0x00000000) 0x00000000: [error occurred during error reporting (printing registers, top of stack, instructions near pc), id 0xb] Stack: [0x0bf9b000,0x0c01c000] Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x576bc1];; _ZN10PSScavenge26copy_and_push_safe_barrierIP7oopDescEEvP18PSPromotionManagerPT_+0x11 V [libjvm.so+0x526bfb];; _ZN9OopMapSet6all_doEPK5framePK11RegisterMapP10OopClosurePFvPP7oopDescSA_ES7_+0x17b V [libjvm.so+0x526a72];; _ZN9OopMapSet7oops_doEPK5framePK11RegisterMapP10OopClosure+0x32 V [libjvm.so+0x2ea3e1];; _ZN5frame17oops_code_blob_doEP10OopClosurePK11RegisterMap+0x31 V [libjvm.so+0x2eab1f];; _ZN5frame16oops_do_internalEP10OopClosureP11RegisterMapb+0x7f V [libjvm.so+0x6131aa];; _ZN10JavaThread7oops_doEP10OopClosure+0xea V [libjvm.so+0x578d0d];; _ZN15ThreadRootsTask5do_itEP13GCTaskManagerj+0x8d V [libjvm.so+0x30e0eb];; _ZN12GCTaskThread3runEv+0x12b V [libjvm.so+0x531cce];; _Z10java_startP6Thread+0x14e C [libpthread.so.0+0x52ab] The valgrind log shows the original error as: ==31714== Thread 6: ==31714== Invalid read of size 4 ==31714== at 0x77FEBC1: void PSScavenge::copy_and_push_safe_barrier(PSPromotionManager*, oopDesc**) (in /opt/java/jdk1.6.0_17/jre/lib/i386/server/libjvm.so) and the secondary error during error reporting as: ==31714== Invalid read of size 4 ==31714== at 0x77B1D06: os::print_hex_dump(outputStream*, unsigned char*, unsigned char*, int) (in /opt/java/jdk1.6.0_17/jre/lib/i386/server/libjvm.so) ==31714== by 0x77BBE35: os::print_context(outputStream*, void*) (in /opt/java/jdk1.6.0_17/jre/lib/i386/server/libjvm.so) ==31714== by 0x78D72ED: VMError::report(outputStream*) (in /opt/java/jdk1.6.0_17/jre/lib/i386/server/libjvm.so) which I suspect is caused by the fact the sp = 0 (which is obviously not be!) What program were you running? can you reproduce the crash outside of valgrind? David Holmes From Feng.Da at zxelec.com Thu Oct 14 19:39:58 2010 From: Feng.Da at zxelec.com (Feng.Da at zxelec.com) Date: Fri, 15 Oct 2010 10:39:58 +0800 Subject: =?gb2312?B?tPC4tDogdmFsZ3JpbmQgcmV2ZWFsIGJ1ZyBvZiBvcGVuamRrIGR1cg==?= =?gb2312?B?aW5nIHByZXNzdXJlIHRlc3Q=?= In-Reply-To: <4CB7BDD9.3020509@oracle.com> Message-ID: <6B947C8AC4195040A8C6876A496C644A04642300@BJ-MAIL-04.vimicro.com> Program is mainly apache mina with native jni. I find jdk5.0 under the same condition is running OK. So it should not be the problem of my program. I should be able to reproduce the problem, it just takes longer time to crash. By the way, Mina can produce lots of leaked socket under heavy GC, which shows invalid file handle when lsof -p displays them. -----????????----- ??????: David Holmes [mailto:David.Holmes at oracle.com] ????????: 2010??10??15?? 10:35 ??????: Feng.Da at zxelec.com ????: hotspot-dev at openjdk.java.net ????: Re: valgrind reveal bug of openjdk during pressure test Feng.Da at zxelec.com said the following on 10/15/10 11:08: > I??m doing a pressure test and find openjdk thrashed suse10 and crashed. > The following is the valgrind report and hs_error file. Ok I belatedly found the 7z command to access the original rar archive. The hs_err log shows: --------------- T H R E A D --------------- Current thread (0x06ea4000): GCTaskThread [stack: 0x0bf9b000,0x0c01c000] [id=31719] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0xfffff032;; Registers: EAX=0x06f5c1e8, EBX=0x16840fc0, ECX=0x06f5c1e8, EDX=0xfffff032 ESP=0x00000000, EBP=0x0c01b088, ESI=0x0c01b0b0, EDI=0x00000001 EIP=0x077febc1, CR2=0xfffff032, EFLAGS=0x00200000 Top of Stack: (sp=0x00000000) 0x00000000: [error occurred during error reporting (printing registers, top of stack, instructions near pc), id 0xb] Stack: [0x0bf9b000,0x0c01c000] Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x576bc1];; _ZN10PSScavenge26copy_and_push_safe_barrierIP7oopDescEEvP18PSPromotionManagerPT_+0x11 V [libjvm.so+0x526bfb];; _ZN9OopMapSet6all_doEPK5framePK11RegisterMapP10OopClosurePFvPP7oopDescSA_ES7_+0x17b V [libjvm.so+0x526a72];; _ZN9OopMapSet7oops_doEPK5framePK11RegisterMapP10OopClosure+0x32 V [libjvm.so+0x2ea3e1];; _ZN5frame17oops_code_blob_doEP10OopClosurePK11RegisterMap+0x31 V [libjvm.so+0x2eab1f];; _ZN5frame16oops_do_internalEP10OopClosureP11RegisterMapb+0x7f V [libjvm.so+0x6131aa];; _ZN10JavaThread7oops_doEP10OopClosure+0xea V [libjvm.so+0x578d0d];; _ZN15ThreadRootsTask5do_itEP13GCTaskManagerj+0x8d V [libjvm.so+0x30e0eb];; _ZN12GCTaskThread3runEv+0x12b V [libjvm.so+0x531cce];; _Z10java_startP6Thread+0x14e C [libpthread.so.0+0x52ab] The valgrind log shows the original error as: ==31714== Thread 6: ==31714== Invalid read of size 4 ==31714== at 0x77FEBC1: void PSScavenge::copy_and_push_safe_barrier(PSPromotionManager*, oopDesc**) (in /opt/java/jdk1.6.0_17/jre/lib/i386/server/libjvm.so) and the secondary error during error reporting as: ==31714== Invalid read of size 4 ==31714== at 0x77B1D06: os::print_hex_dump(outputStream*, unsigned char*, unsigned char*, int) (in /opt/java/jdk1.6.0_17/jre/lib/i386/server/libjvm.so) ==31714== by 0x77BBE35: os::print_context(outputStream*, void*) (in /opt/java/jdk1.6.0_17/jre/lib/i386/server/libjvm.so) ==31714== by 0x78D72ED: VMError::report(outputStream*) (in /opt/java/jdk1.6.0_17/jre/lib/i386/server/libjvm.so) which I suspect is caused by the fact the sp = 0 (which is obviously not be!) What program were you running? can you reproduce the crash outside of valgrind? David Holmes From Dmitriy.Samersoff at oracle.com Fri Oct 15 01:10:19 2010 From: Dmitriy.Samersoff at oracle.com (Dmitriy Samersoff) Date: Fri, 15 Oct 2010 12:10:19 +0400 Subject: =?UTF-8?B?562U5aSNOiB2YWxncmluZCByZXZlYWwgYnVnIG9mIG9wZW5qZGs=?= =?UTF-8?B?IGR1cmluZyBwcmVzc3VyZSB0ZXN0?= In-Reply-To: <6B947C8AC4195040A8C6876A496C644A04642300@BJ-MAIL-04.vimicro.com> References: <6B947C8AC4195040A8C6876A496C644A04642300@BJ-MAIL-04.vimicro.com> Message-ID: <4CB80C6B.4060709@oracle.com> Feng, Valgrind can't be used with JVM for many of reasons (e.g. JVM heavy use UNIX signals for it's own purpose, maintain it's own memory, has dynamically generated code etc) If you really whant to use valgrind you have to carefully insert VALGRIND_* macros in the JVM code and re-build hotspot, but it's a huge work. -Dmitry On 2010-10-15 06:39, Feng.Da at zxelec.com wrote: > > Program is mainly apache mina with native jni. I find jdk5.0 under the same condition is running OK. So it should not be the problem of my program. I should be able to reproduce the problem, it just takes longer time to crash. By the way, > Mina can produce lots of leaked socket under heavy GC, which shows invalid file handle when lsof -p displays them. > > -----????----- > ???: David Holmes [mailto:David.Holmes at oracle.com] > ????: 2010?10?15? 10:35 > ???: Feng.Da at zxelec.com > ??: hotspot-dev at openjdk.java.net > ??: Re: valgrind reveal bug of openjdk during pressure test > > Feng.Da at zxelec.com said the following on 10/15/10 11:08: >> I?m doing a pressure test and find openjdk thrashed suse10 and crashed. >> The following is the valgrind report and hs_error file. > > Ok I belatedly found the 7z command to access the original rar archive. > > The hs_err log shows: > > --------------- T H R E A D --------------- > > Current thread (0x06ea4000): GCTaskThread [stack: > 0x0bf9b000,0x0c01c000] [id=31719] > > siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), > si_addr=0xfffff032;; > > Registers: > EAX=0x06f5c1e8, EBX=0x16840fc0, ECX=0x06f5c1e8, EDX=0xfffff032 > ESP=0x00000000, EBP=0x0c01b088, ESI=0x0c01b0b0, EDI=0x00000001 > EIP=0x077febc1, CR2=0xfffff032, EFLAGS=0x00200000 > > Top of Stack: (sp=0x00000000) > 0x00000000: > [error occurred during error reporting (printing registers, top of > stack, instructions near pc), id 0xb] > > Stack: [0x0bf9b000,0x0c01c000] > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > V [libjvm.so+0x576bc1];; > _ZN10PSScavenge26copy_and_push_safe_barrierIP7oopDescEEvP18PSPromotionManagerPT_+0x11 > V [libjvm.so+0x526bfb];; > _ZN9OopMapSet6all_doEPK5framePK11RegisterMapP10OopClosurePFvPP7oopDescSA_ES7_+0x17b > V [libjvm.so+0x526a72];; > _ZN9OopMapSet7oops_doEPK5framePK11RegisterMapP10OopClosure+0x32 > V [libjvm.so+0x2ea3e1];; > _ZN5frame17oops_code_blob_doEP10OopClosurePK11RegisterMap+0x31 > V [libjvm.so+0x2eab1f];; > _ZN5frame16oops_do_internalEP10OopClosureP11RegisterMapb+0x7f > V [libjvm.so+0x6131aa];; _ZN10JavaThread7oops_doEP10OopClosure+0xea > V [libjvm.so+0x578d0d];; _ZN15ThreadRootsTask5do_itEP13GCTaskManagerj+0x8d > V [libjvm.so+0x30e0eb];; _ZN12GCTaskThread3runEv+0x12b > V [libjvm.so+0x531cce];; _Z10java_startP6Thread+0x14e > C [libpthread.so.0+0x52ab] > > > The valgrind log shows the original error as: > > ==31714== Thread 6: > ==31714== Invalid read of size 4 > ==31714== at 0x77FEBC1: void > PSScavenge::copy_and_push_safe_barrier(PSPromotionManager*, > oopDesc**) (in /opt/java/jdk1.6.0_17/jre/lib/i386/server/libjvm.so) > > and the secondary error during error reporting as: > > ==31714== Invalid read of size 4 > ==31714== at 0x77B1D06: os::print_hex_dump(outputStream*, unsigned > char*, unsigned char*, int) (in > /opt/java/jdk1.6.0_17/jre/lib/i386/server/libjvm.so) > ==31714== by 0x77BBE35: os::print_context(outputStream*, void*) (in > /opt/java/jdk1.6.0_17/jre/lib/i386/server/libjvm.so) > ==31714== by 0x78D72ED: VMError::report(outputStream*) (in > /opt/java/jdk1.6.0_17/jre/lib/i386/server/libjvm.so) > > which I suspect is caused by the fact the sp = 0 (which is obviously not > be!) > > What program were you running? can you reproduce the crash outside of > valgrind? > > David Holmes -- Dmitry Samersoff J2SE Sustaining team, SPB04 * Give Rabbit time and he'll always get the answer ... From Feng.Da at zxelec.com Fri Oct 15 01:51:50 2010 From: Feng.Da at zxelec.com (Feng.Da at zxelec.com) Date: Fri, 15 Oct 2010 16:51:50 +0800 Subject: =?gb2312?B?tPC4tDogtPC4tDogdmFsZ3JpbmQgcmV2ZWFsIGJ1ZyBvZiBvcGVuag==?= =?gb2312?B?ZGsgZHVyaW5nIHByZXNzdXJlIHRlc3Q=?= In-Reply-To: <4CB80C6B.4060709@oracle.com> Message-ID: <6B947C8AC4195040A8C6876A496C644A0468B546@BJ-MAIL-04.vimicro.com> Samersoff: I used valgrind to debug my JNI program, and find it useful. I submit the bug just because I find openjdk crashes. Thanks for you advice. -----????????----- ??????: Dmitriy Samersoff [mailto:Dmitriy.Samersoff at oracle.com] ????????: 2010??10??15?? 16:10 ??????: Feng.Da at zxelec.com ????: David Holmes; hotspot-dev at openjdk.java.net ????: Re: ????: valgrind reveal bug of openjdk during pressure test Feng, Valgrind can't be used with JVM for many of reasons (e.g. JVM heavy use UNIX signals for it's own purpose, maintain it's own memory, has dynamically generated code etc) If you really whant to use valgrind you have to carefully insert VALGRIND_* macros in the JVM code and re-build hotspot, but it's a huge work. -Dmitry On 2010-10-15 06:39, Feng.Da at zxelec.com wrote: > > Program is mainly apache mina with native jni. I find jdk5.0 under the same condition is running OK. So it should not be the problem of my program. I should be able to reproduce the problem, it just takes longer time to crash. By the way, > Mina can produce lots of leaked socket under heavy GC, which shows invalid file handle when lsof -p displays them. > > -----????????----- > ??????: David Holmes [mailto:David.Holmes at oracle.com] > ????????: 2010??10??15?? 10:35 > ??????: Feng.Da at zxelec.com > ????: hotspot-dev at openjdk.java.net > ????: Re: valgrind reveal bug of openjdk during pressure test > > Feng.Da at zxelec.com said the following on 10/15/10 11:08: >> I??m doing a pressure test and find openjdk thrashed suse10 and crashed. >> The following is the valgrind report and hs_error file. > > Ok I belatedly found the 7z command to access the original rar archive. > > The hs_err log shows: > > --------------- T H R E A D --------------- > > Current thread (0x06ea4000): GCTaskThread [stack: > 0x0bf9b000,0x0c01c000] [id=31719] > > siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), > si_addr=0xfffff032;; > > Registers: > EAX=0x06f5c1e8, EBX=0x16840fc0, ECX=0x06f5c1e8, EDX=0xfffff032 > ESP=0x00000000, EBP=0x0c01b088, ESI=0x0c01b0b0, EDI=0x00000001 > EIP=0x077febc1, CR2=0xfffff032, EFLAGS=0x00200000 > > Top of Stack: (sp=0x00000000) > 0x00000000: > [error occurred during error reporting (printing registers, top of > stack, instructions near pc), id 0xb] > > Stack: [0x0bf9b000,0x0c01c000] > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > V [libjvm.so+0x576bc1];; > _ZN10PSScavenge26copy_and_push_safe_barrierIP7oopDescEEvP18PSPromotionManagerPT_+0x11 > V [libjvm.so+0x526bfb];; > _ZN9OopMapSet6all_doEPK5framePK11RegisterMapP10OopClosurePFvPP7oopDescSA_ES7_+0x17b > V [libjvm.so+0x526a72];; > _ZN9OopMapSet7oops_doEPK5framePK11RegisterMapP10OopClosure+0x32 > V [libjvm.so+0x2ea3e1];; > _ZN5frame17oops_code_blob_doEP10OopClosurePK11RegisterMap+0x31 > V [libjvm.so+0x2eab1f];; > _ZN5frame16oops_do_internalEP10OopClosureP11RegisterMapb+0x7f > V [libjvm.so+0x6131aa];; _ZN10JavaThread7oops_doEP10OopClosure+0xea > V [libjvm.so+0x578d0d];; _ZN15ThreadRootsTask5do_itEP13GCTaskManagerj+0x8d > V [libjvm.so+0x30e0eb];; _ZN12GCTaskThread3runEv+0x12b > V [libjvm.so+0x531cce];; _Z10java_startP6Thread+0x14e > C [libpthread.so.0+0x52ab] > > > The valgrind log shows the original error as: > > ==31714== Thread 6: > ==31714== Invalid read of size 4 > ==31714== at 0x77FEBC1: void > PSScavenge::copy_and_push_safe_barrier(PSPromotionManager*, > oopDesc**) (in /opt/java/jdk1.6.0_17/jre/lib/i386/server/libjvm.so) > > and the secondary error during error reporting as: > > ==31714== Invalid read of size 4 > ==31714== at 0x77B1D06: os::print_hex_dump(outputStream*, unsigned > char*, unsigned char*, int) (in > /opt/java/jdk1.6.0_17/jre/lib/i386/server/libjvm.so) > ==31714== by 0x77BBE35: os::print_context(outputStream*, void*) (in > /opt/java/jdk1.6.0_17/jre/lib/i386/server/libjvm.so) > ==31714== by 0x78D72ED: VMError::report(outputStream*) (in > /opt/java/jdk1.6.0_17/jre/lib/i386/server/libjvm.so) > > which I suspect is caused by the fact the sp = 0 (which is obviously not > be!) > > What program were you running? can you reproduce the crash outside of > valgrind? > > David Holmes -- Dmitry Samersoff J2SE Sustaining team, SPB04 * Give Rabbit time and he'll always get the answer ... From karen.kinnear at oracle.com Sat Oct 16 01:19:27 2010 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Sat, 16 Oct 2010 08:19:27 +0000 Subject: hg: jdk7/hotspot/hotspot: 9 new changesets Message-ID: <20101016081948.A9B02471BF@hg.openjdk.java.net> Changeset: dfb38ea7da17 Author: zgu Date: 2010-09-30 12:05 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/dfb38ea7da17 6988363: Rebrand vm vendor property settings (jdk7 only) Summary: Vendor properties should be initialized after JDK version is determined. Reviewed-by: kamg, ohair, dcubed, dholmes ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/thread.cpp Changeset: 1c352af0135d Author: acorn Date: 2010-10-04 13:11 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1c352af0135d 6763959: java.util.concurrent.locks.LockSupport.parkUntil(0) blocks forever Summary: Absolute time 0 needs to return immediately. Reviewed-by: phh, dcubed, dholmes ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp Changeset: 644f98c78e33 Author: acorn Date: 2010-10-04 10:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/644f98c78e33 Merge Changeset: b6aedd1acdc0 Author: coleenp Date: 2010-10-07 08:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b6aedd1acdc0 6983240: guarantee((Solaris::min_stack_allowed >= (StackYellowPages+StackRedPages...) wrong Summary: min_stack_allowed is a compile time constant and Stack*Pages are settable Reviewed-by: dholmes, kvn ! src/cpu/x86/vm/methodHandles_x86.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/runtime/arguments.cpp ! src/share/vm/utilities/exceptions.cpp Changeset: 3dc12ef8735e Author: bobv Date: 2010-10-07 15:12 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3dc12ef8735e 6989297: Integrate additional portability improvements Reviewed-by: vladidan, dholmes ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/zero/vm/globals_zero.hpp ! src/os/linux/vm/attachListener_linux.cpp ! src/share/vm/includeDB_core ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 7491c8b96111 Author: bobv Date: 2010-10-07 15:14 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7491c8b96111 Merge Changeset: c77b5c592eab Author: kamg Date: 2010-10-12 10:57 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c77b5c592eab 6392697: Additional flag needed to supress Hotspot warning messages Summary: Apply PrintJvmWarnings flag to all warnings Reviewed-by: coleenp, phh ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/debug.cpp Changeset: 75b0735b4d04 Author: acorn Date: 2010-10-13 11:46 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/75b0735b4d04 Merge ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/includeDB_core ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: beba40b26a79 Author: acorn Date: 2010-10-15 15:12 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/beba40b26a79 Merge ! src/cpu/x86/vm/methodHandles_x86.cpp From tom.rodriguez at oracle.com Mon Oct 18 12:45:22 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 18 Oct 2010 12:45:22 -0700 Subject: review (S) for 6970683: improvements to hs_err output In-Reply-To: <4CAF40E6.8070803@oracle.com> References: <4CAF40E6.8070803@oracle.com> Message-ID: <12ACEC2C-C4AA-4973-AE69-1D6C9F4A5560@oracle.com> On Oct 8, 2010, at 9:03 AM, Coleen Phillimore wrote: > This change looks good to me. I missed when print_location() was added for the registers, but it does a lot of things that we used to consider unsafe from the error handler. And I didn't like all the white space. I wonder if you should check for Universe::is_initialized() in vmError before calling this? > > Can you attach an "after" version of hs_err? I guess I can get one of my own pretty easily after you check this in, but I'd like to see one first. I forgot to send these out last week. I put hs_errs from x86/sparc vs. 32/64 in http://cr.openjdk.java.net/~never/6970683/hse. tom > > Lastly, what sort of problems can you diagnose from the code cache bounds? > > Thanks, > Coleen > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6970683 >> >> 6970683: improvements to hs_err output >> Reviewed-by: >> >> There are a few things missing from the hs_err dump that would be >> useful. First we don't dump the sparc L and I registers. Second some >> information about the size and contents of the code cache would be >> useful. Third we should dump a larger region around the faulting >> instruction. Additionally the new register to memory mapping output >> can crash which stops us from getting the stack and instructions at >> the faulting pc, so I moved it into it's own section. block_start >> would assert in some cases so I augmented existing logic to just >> return null. I also changed the formatting to remove all the extra >> whitespace and made some of the output more compact and eliminated >> most of the useless whitespace. >> From tom.rodriguez at oracle.com Mon Oct 18 15:21:05 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Mon, 18 Oct 2010 22:21:05 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20101018222108.B5C4B47252@hg.openjdk.java.net> Changeset: 07a218de38cb Author: never Date: 2010-10-15 14:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/07a218de38cb 6992477: fix for 6991512 broke sparc barriers Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 75ab0162aa84 Author: never Date: 2010-10-18 09:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/75ab0162aa84 Merge From igor.veresov at oracle.com Tue Oct 19 00:38:19 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 19 Oct 2010 00:38:19 -0700 Subject: Request for review(XS): 6989669: Coops: -Xshare:dump causes crash Message-ID: <4CBD4AEB.9080803@oracle.com> This a temporary fix to disable compressed oops with CDS. I'd like to put this fix directly to hotspot/hotspot since this issue is a major roadblock for testing. Webrev: http://cr.openjdk.java.net/~iveresov/6989669/webrev.00/ Thanks, igor From David.Holmes at oracle.com Tue Oct 19 01:07:55 2010 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 19 Oct 2010 18:07:55 +1000 Subject: Request for review(XS): 6989669: Coops: -Xshare:dump causes crash In-Reply-To: <4CBD4AEB.9080803@oracle.com> References: <4CBD4AEB.9080803@oracle.com> Message-ID: <4CBD51DB.9090402@oracle.com> Hi Igor, This looks okay to me, but why the change to SharedReadWriteSize? Seems unrelated to the CDS issue. David Igor Veresov said the following on 10/19/10 17:38: > This a temporary fix to disable compressed oops with CDS. I'd like to > put this fix directly to hotspot/hotspot since this issue is a major > roadblock for testing. > > Webrev: http://cr.openjdk.java.net/~iveresov/6989669/webrev.00/ > > Thanks, > igor From christian.thalinger at oracle.com Tue Oct 19 01:17:53 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 19 Oct 2010 10:17:53 +0200 Subject: Request for review(XS): 6989669: Coops: -Xshare:dump causes crash In-Reply-To: <4CBD4AEB.9080803@oracle.com> References: <4CBD4AEB.9080803@oracle.com> Message-ID: On Oct 19, 2010, at 9:38 AM, Igor Veresov wrote: > This a temporary fix to disable compressed oops with CDS. I'd like > to put this fix directly to hotspot/hotspot since this issue is a > major roadblock for testing. > > Webrev: http://cr.openjdk.java.net/~iveresov/6989669/webrev.00/ Looks good. -- Christian From igor.veresov at oracle.com Tue Oct 19 02:24:57 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 19 Oct 2010 02:24:57 -0700 Subject: Request for review(XS): 6989669: Coops: -Xshare:dump causes crash In-Reply-To: <4CBD51DB.9090402@oracle.com> References: <4CBD4AEB.9080803@oracle.com> <4CBD51DB.9090402@oracle.com> Message-ID: <4CBD63E9.7050109@oracle.com> On 10/19/10 1:07 AM, David Holmes wrote: > Hi Igor, > > This looks okay to me, but why the change to SharedReadWriteSize? Seems > unrelated to the CDS issue. The space wasn't enough on 64bit (uncompressed) and dumping didn't work. So I had to bump it up a little bit. igor > > David > > > Igor Veresov said the following on 10/19/10 17:38: >> This a temporary fix to disable compressed oops with CDS. I'd like to >> put this fix directly to hotspot/hotspot since this issue is a major >> roadblock for testing. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6989669/webrev.00/ >> >> Thanks, >> igor From David.Holmes at oracle.com Tue Oct 19 02:31:51 2010 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 19 Oct 2010 19:31:51 +1000 Subject: Request for review(XS): 6989669: Coops: -Xshare:dump causes crash In-Reply-To: <4CBD63E9.7050109@oracle.com> References: <4CBD4AEB.9080803@oracle.com> <4CBD51DB.9090402@oracle.com> <4CBD63E9.7050109@oracle.com> Message-ID: <4CBD6587.3070209@oracle.com> Igor Veresov said the following on 10/19/10 19:24: > On 10/19/10 1:07 AM, David Holmes wrote: >> This looks okay to me, but why the change to SharedReadWriteSize? Seems >> unrelated to the CDS issue. > > The space wasn't enough on 64bit (uncompressed) and dumping didn't work. > So I had to bump it up a little bit. Ok. David > igor > >> >> David >> >> >> Igor Veresov said the following on 10/19/10 17:38: >>> This a temporary fix to disable compressed oops with CDS. I'd like to >>> put this fix directly to hotspot/hotspot since this issue is a major >>> roadblock for testing. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/6989669/webrev.00/ >>> >>> Thanks, >>> igor > From vladimir.kozlov at oracle.com Tue Oct 19 07:36:20 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Oct 2010 07:36:20 -0700 Subject: Request for review(XS): 6989669: Coops: -Xshare:dump causes crash In-Reply-To: <4CBD4AEB.9080803@oracle.com> References: <4CBD4AEB.9080803@oracle.com> Message-ID: <4CBDACE4.9040300@oracle.com> Looks good Vladimir On 10/19/10 12:38 AM, Igor Veresov wrote: > This a temporary fix to disable compressed oops with CDS. I'd like to put this fix directly to hotspot/hotspot since > this issue is a major roadblock for testing. > > Webrev: http://cr.openjdk.java.net/~iveresov/6989669/webrev.00/ > > Thanks, > igor From igor.veresov at oracle.com Tue Oct 19 11:01:21 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 19 Oct 2010 11:01:21 -0700 Subject: Request for review(XS): 6989669: Coops: -Xshare:dump causes crash In-Reply-To: <7A77BBD0-0974-4192-9F9D-B9799EEC574B@oracle.com> References: <4CBD4AEB.9080803@oracle.com> <7A77BBD0-0974-4192-9F9D-B9799EEC574B@oracle.com> Message-ID: <4CBDDCF1.90804@oracle.com> Thanks David, Christian, Vladimir and Tom! igor On 10/19/10 8:29 AM, Tom Rodriguez wrote: > Looks good. > > tom > > On Oct 19, 2010, at 12:38 AM, Igor Veresov wrote: > >> This a temporary fix to disable compressed oops with CDS. I'd like to put this fix directly to hotspot/hotspot since this issue is a major roadblock for testing. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6989669/webrev.00/ >> >> Thanks, >> igor > From igor.veresov at oracle.com Tue Oct 19 20:33:21 2010 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Wed, 20 Oct 2010 03:33:21 +0000 Subject: hg: jdk7/hotspot/hotspot: 6989669: Coops: -Xshare:dump causes crash Message-ID: <20101020033325.50805472A9@hg.openjdk.java.net> Changeset: 4e22405d98d6 Author: iveresov Date: 2010-10-19 11:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4e22405d98d6 6989669: Coops: -Xshare:dump causes crash Summary: Temporarily fix to disable compressed oops with CDS Reviewed-by: dholmes, twisti, kvn, never ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp From erik.trimble at oracle.com Wed Oct 20 17:15:42 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Thu, 21 Oct 2010 00:15:42 +0000 Subject: hg: jdk7/hotspot/hotspot: 6 new changesets Message-ID: <20101021001552.E5F17472EB@hg.openjdk.java.net> Changeset: 68d6141ea19d Author: cl Date: 2010-10-07 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/68d6141ea19d Added tag jdk7-b113 for changeset beef35b96b81 ! .hgtags Changeset: 52f19c724d96 Author: trims Date: 2010-10-14 15:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/52f19c724d96 Merge ! .hgtags Changeset: 570870354f86 Author: trims Date: 2010-10-14 16:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/570870354f86 6992267: Bump the HS20 build number to 02 Summary: Update the HS20 build number to 02 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 477faa484f91 Author: cl Date: 2010-10-14 19:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/477faa484f91 Added tag jdk7-b114 for changeset 68d6141ea19d ! .hgtags Changeset: bdbc48857210 Author: trims Date: 2010-10-20 16:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/bdbc48857210 Merge ! .hgtags Changeset: 9eaf8ba53f3d Author: trims Date: 2010-10-20 17:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9eaf8ba53f3d Merge From doko at ubuntu.com Thu Oct 21 04:44:57 2010 From: doko at ubuntu.com (Matthias Klose) Date: Thu, 21 Oct 2010 13:44:57 +0200 Subject: The Road to 1.10 In-Reply-To: <20101021102907.GA5809@bree.redhat.com> References: <20101021102907.GA5809@bree.redhat.com> Message-ID: <4CC027B9.6090200@ubuntu.com> On 21.10.2010 12:29, Dr Andrew John Hughes wrote: > OpenJDK b21 should be available sometime in the next month or so. I'd > like us to release IcedTea6 1.10 about a week after, allowing time for > testing, etc. > > With the change to HotSpot 19 as default (added on Tuesday), current > IcedTea6 HEAD is now pretty much inline with b21, through this and our > other patches. So the b21 bump will be just a matter of switching to > the new tarball. You can track progress on b21 using the hg branch: > http://icedtea.classpath.org/hg/icedtea6-hg. > > Major changes in 1.10: > > * Upgrade to HotSpot 19 (on HEAD) and OpenJDK6 b21 (imminent) which fails to build on powerpc. looks like an upstream issue. see icedtea#579. Matthias From kurt at intricatesoftware.com Tue Oct 26 13:35:18 2010 From: kurt at intricatesoftware.com (Kurt Miller) Date: Tue, 26 Oct 2010 16:35:18 -0400 Subject: Source Bundle Question Message-ID: <201010261635.18096.kurt@intricatesoftware.com> Hi, I noticed some differences beween the source that is released in the bundle vs what is in mecurial for the same build/tag. What mercurial hotspot tree is used to build the source bundles for hotspot? For example in build 105 source bundle downloaded here: http://download.java.net/openjdk/jdk7/promoted/b105/ there exists support for UseCompressedStrings but I can't find that support in mercurial. For example this file: openjdk/hotspot/src/share/vm/runtime/globals.hpp has product values for UseCompressedStrings, SpecialStringCompress, SpecialStringInflate, SpecialStringCompareToCC, SpecialStringIndexOfCC and SpecialStringEqualsCC. Whereas the same file with b105 tag doesn't: http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/6709c14587c2/src/share/vm/runtime/globals.hpp Am I'm using the wrong hotspot repository? Thanks, -Kurt From karen.kinnear at oracle.com Wed Oct 27 11:53:52 2010 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Wed, 27 Oct 2010 18:53:52 +0000 Subject: hg: jdk7/hotspot/hotspot: 6 new changesets Message-ID: <20101027185403.06C5E47485@hg.openjdk.java.net> Changeset: a4c7fe54bf3f Author: kamg Date: 2010-10-21 10:10 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a4c7fe54bf3f 6991315: RedefineClasses fails with java.lang.VerifyError Summary: Repair stackmap table attribute when relocating bytecode Reviewed-by: acorn, never + src/share/vm/classfile/stackMapTableFormat.hpp ! src/share/vm/includeDB_core ! src/share/vm/oops/methodOop.hpp ! src/share/vm/runtime/relocator.cpp ! src/share/vm/runtime/relocator.hpp Changeset: fa83ab460c54 Author: acorn Date: 2010-10-22 15:59 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fa83ab460c54 6988353: refactor contended sync subsystem Summary: reduce complexity by factoring synchronizer.cpp Reviewed-by: dholmes, never, coleenp - src/os/linux/vm/objectMonitor_linux.cpp - src/os/linux/vm/objectMonitor_linux.hpp - src/os/linux/vm/objectMonitor_linux.inline.hpp - src/os/solaris/vm/objectMonitor_solaris.cpp - src/os/solaris/vm/objectMonitor_solaris.hpp - src/os/solaris/vm/objectMonitor_solaris.inline.hpp - src/os/windows/vm/objectMonitor_windows.cpp - src/os/windows/vm/objectMonitor_windows.hpp - src/os/windows/vm/objectMonitor_windows.inline.hpp ! src/share/vm/includeDB_compiler1 ! src/share/vm/includeDB_core ! src/share/vm/includeDB_features ! src/share/vm/includeDB_jvmti ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp + src/share/vm/prims/jvmtiRawMonitor.cpp + src/share/vm/prims/jvmtiRawMonitor.hpp + src/share/vm/runtime/basicLock.cpp + src/share/vm/runtime/basicLock.hpp ! src/share/vm/runtime/mutex.hpp + src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/objectMonitor.hpp ! src/share/vm/runtime/objectMonitor.inline.hpp + src/share/vm/runtime/park.cpp + src/share/vm/runtime/park.hpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/synchronizer.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: a312a67b32ef Author: acorn Date: 2010-10-25 13:31 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a312a67b32ef Merge ! src/share/vm/includeDB_core Changeset: 60ce9dade348 Author: acorn Date: 2010-10-26 14:43 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/60ce9dade348 Merge Changeset: 6412b3805cd6 Author: kamg Date: 2010-10-26 14:08 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6412b3805cd6 6891959: HotSpot should not throw ClassFormatError if a class has a field with '>' and/or '<' in its name Summary: Class file parser needs to look for and disallow '[' in names. Reviewed-by: coleenp, never ! src/share/vm/classfile/classFileParser.cpp Changeset: ee0d26abaad3 Author: kamg Date: 2010-10-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ee0d26abaad3 Merge From john.r.rose at oracle.com Wed Oct 27 16:12:51 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 27 Oct 2010 16:12:51 -0700 Subject: error compiling on windows References: <201010272209.o9RM9Peb029052@prt-web.sfbay.sun.com> Message-ID: I just submitted a simple change (6981788) to jprt and got an error I don't understand from the windows C compiler. Does the error below ring bells with anybody? Thanks, -- John Begin forwarded message: > /Yu"incls/_precompiled.incl" /c ..\generated\jvmtifiles\jvmtiEnter.cpp > ..\generated\jvmtifiles\jvmtiEnterTrace.cpp > jvmtiEnter.cpp > jvmtiEnterTrace.cpp > Generating Code... > sh C:\temp\jprt\P1\B\071529.jrose\source/make/windows/build_vm_def.sh > C:\temp\jprt\P1\B\071529.jrose\source\make\windows\makefiles\product.make(73) > : fatal error U1054: cannot create inline file '' > Stop. > NMAKE : fatal error U1077: 'cd' : return code '0x2' > Stop. > NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~1.NET\Vc7\bin\nmake.exe' : > return code '0x2' > Stop. > C:\jprt\slashjava\devtools\win32\bin\gnumake.exe[1]: *** [generic_build2] > Error 2 http://prt-web.sfbay.sun.com/archive/2010/10/2010-10-27-071529.jrose.hotspot//logs/windows_i586_5.0-product.log -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101027/6dbb5b0f/attachment.html From tom.rodriguez at oracle.com Wed Oct 27 16:49:43 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 27 Oct 2010 16:49:43 -0700 Subject: error compiling on windows In-Reply-To: References: <201010272209.o9RM9Peb029052@prt-web.sfbay.sun.com> Message-ID: <4F475BD1-2F75-4850-86CA-B55F458E8E1F@oracle.com> Google says that's an error where a file already exists or the file system is full. Maybe there was garbage left behind by a previous compile? Didn't Kelly just change the windows boxes to run as jprtadm instead of administrator? Maybe there are permission problems cleaning up from previous runs. tom On Oct 27, 2010, at 4:12 PM, John Rose wrote: > I just submitted a simple change (6981788) to jprt and got an error I don't understand from the windows C compiler. > > Does the error below ring bells with anybody? > > Thanks, > -- John > > Begin forwarded message: > >> /Yu"incls/_precompiled.incl" /c ..\generated\jvmtifiles\jvmtiEnter.cpp >> ..\generated\jvmtifiles\jvmtiEnterTrace.cpp >> jvmtiEnter.cpp >> jvmtiEnterTrace.cpp >> Generating Code... >> sh C:\temp\jprt\P1\B\071529.jrose\source/make/windows/build_vm_def.sh >> C:\temp\jprt\P1\B\071529.jrose\source\make\windows\makefiles\product.make(73) >> : fatal error U1054: cannot create inline file '' >> Stop. >> NMAKE : fatal error U1077: 'cd' : return code '0x2' >> Stop. >> NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~1.NET\Vc7\bin\nmake.exe' : >> return code '0x2' >> Stop. >> C:\jprt\slashjava\devtools\win32\bin\gnumake.exe[1]: *** [generic_build2] >> Error 2 > > http://prt-web.sfbay.sun.com/archive/2010/10/2010-10-27-071529.jrose.hotspot//logs/windows_i586_5.0-product.log From john.r.rose at oracle.com Wed Oct 27 17:17:53 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 27 Oct 2010 17:17:53 -0700 Subject: error compiling on windows In-Reply-To: <4F475BD1-2F75-4850-86CA-B55F458E8E1F@oracle.com> References: <201010272209.o9RM9Peb029052@prt-web.sfbay.sun.com> <4F475BD1-2F75-4850-86CA-B55F458E8E1F@oracle.com> Message-ID: On Oct 27, 2010, at 4:49 PM, Tom Rodriguez wrote: > Google says that's an error where a file already exists or the file system is full. Maybe there was garbage left behind by a previous compile? Didn't Kelly just change the windows boxes to run as jprtadm instead of administrator? Maybe there are permission problems cleaning up from previous runs. Thanks. Yes, it feels like a permissions problem. Ramki just ran into it also. (Misery loves company.) We'll see what the JPRT gurus come up with. -- John From kelly.ohair at oracle.com Thu Oct 28 06:28:07 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 28 Oct 2010 09:28:07 -0400 Subject: error compiling on windows In-Reply-To: References: <201010272209.o9RM9Peb029052@prt-web.sfbay.sun.com> <4F475BD1-2F75-4850-86CA-B55F458E8E1F@oracle.com> Message-ID: <4CD9FE6E-CF1A-4C27-A522-CA6746FCA37D@oracle.com> What is the relationship between Ramki's hotspot sources and yours? I'm not finding anything wrong on the JPRT side, and I'm suspecting some kind of VS2010 change that both of you guys got somehow. But I cannot rule out some bizarre permission issue on windows. This make/windows/build_vm_def.sh is certainly involved, but I don't know exactly how since none of what it does is visible in the logs. I'll submit my own hotspot job and see if I can reproduce it. -kto On Oct 27, 2010, at 8:17 PM, John Rose wrote: > On Oct 27, 2010, at 4:49 PM, Tom Rodriguez wrote: > >> Google says that's an error where a file already exists or the file >> system is full. Maybe there was garbage left behind by a previous >> compile? Didn't Kelly just change the windows boxes to run as >> jprtadm instead of administrator? Maybe there are permission >> problems cleaning up from previous runs. > > Thanks. Yes, it feels like a permissions problem. Ramki just ran > into it also. (Misery loves company.) We'll see what the JPRT > gurus come up with. > > -- John From igor.veresov at oracle.com Fri Oct 29 11:27:15 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 29 Oct 2010 11:27:15 -0700 Subject: Request for review(XS): 6996136: VM crash in src/share/vm/runtime/virtualspace.cpp:424 Message-ID: <4CCB1203.4030504@oracle.com> Turn CDS off if compressed oops are used. Also move the checking code after set_ergonomic_flags(). Webrev: http://cr.openjdk.java.net/~iveresov/6996136/webrev.00/ igor From openjdk-ml at seichter.de Fri Oct 29 12:27:18 2010 From: openjdk-ml at seichter.de (Ralph Seichter) Date: Fri, 29 Oct 2010 21:27:18 +0200 Subject: My OpenJDK 64-Bit Server VM crashes, what am I doing wrong? Message-ID: <4CCB2016.5060402@seichter.de> Hello list, I wrote about a JVM crash in the bsd-port-dev mailing list, and Kurt Miller suggested that I rather post here. Based on http://wikis.sun.com/display/OpenJDK/Darwin10Build I have built OpenJDK on Mac OS X 10.6.4 Snow Leopard with the latest Xcode. $ java -version openjdk version "1.7.0-internal" OpenJDK Runtime Environment (build 1.7.0-internal-ralph_2010_10_22_20_59-b00) OpenJDK 64-Bit Server VM (build 19.0-b05, mixed mode) When I run a vanilla Tomcat 6.0.29 within Eclipse with this JVM, Tomcat seems to be OK. However, when I run Tomcat standalone with JAVA_HOME and JRE_HOME set to my OpenJDK build, Tomcat crashes whenever I try to access the Tomcat manager application (please see attached log). Maybe there is something wrong with my OpenJDK build, but how can I verify this? -Ralph -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid504.log Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20101029/a049a3b2/attachment.ksh From vladimir.kozlov at oracle.com Fri Oct 29 15:17:28 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Oct 2010 15:17:28 -0700 Subject: My OpenJDK 64-Bit Server VM crashes, what am I doing wrong? In-Reply-To: <4CCB2016.5060402@seichter.de> References: <4CCB2016.5060402@seichter.de> Message-ID: <4CCB47F8.30609@oracle.com> Ralf, try to switch off compressed oops: -XX:-UseCompressedOops. For implicit compressed NULL pointer check (as in this case) VM expects to get SIGSEGV when loading from protected page below java heap instead of SIGBUS. Could be the page was not reserved (there was bug 6947341 in VM fixed in 19.0-b04, so you should have the fix). Or OS throws SIGBUS instead of SIGSEGV for some reasons. Note, address is aligned: si_addr=4387303432 (0x10580F008) Build fastdebug JVM and run it to get more information. Vladimir Ralph Seichter wrote: > Hello list, > > I wrote about a JVM crash in the bsd-port-dev mailing list, and Kurt > Miller suggested that I rather post here. > > Based on http://wikis.sun.com/display/OpenJDK/Darwin10Build I have built > OpenJDK on Mac OS X 10.6.4 Snow Leopard with the latest Xcode. > > $ java -version > openjdk version "1.7.0-internal" > OpenJDK Runtime Environment (build 1.7.0-internal-ralph_2010_10_22_20_59-b00) > OpenJDK 64-Bit Server VM (build 19.0-b05, mixed mode) > > When I run a vanilla Tomcat 6.0.29 within Eclipse with this JVM, Tomcat > seems to be OK. However, when I run Tomcat standalone with JAVA_HOME and > JRE_HOME set to my OpenJDK build, Tomcat crashes whenever I try to > access the Tomcat manager application (please see attached log). > > Maybe there is something wrong with my OpenJDK build, but how can I > verify this? > > -Ralph > From vladimir.kozlov at oracle.com Fri Oct 29 15:27:36 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Oct 2010 15:27:36 -0700 Subject: Request for review(XS): 6996136: VM crash in src/share/vm/runtime/virtualspace.cpp:424 In-Reply-To: <4CCB1203.4030504@oracle.com> References: <4CCB1203.4030504@oracle.com> Message-ID: <4CCB4A58.2070607@oracle.com> Igor, Could you consolidate code which set UseCompressedOops in one separate method? Also we should print warning id user specified COOP: if (UseCompressedOops && FLAG_IS_CMDLINE(UseCompressedOops)) { warning("Can not use Compressed Oops with shared spaces"); FLAG_SET_DEFAULT(UseCompressedOops, false); } Thanks, Vladimir Igor Veresov wrote: > Turn CDS off if compressed oops are used. Also move the checking code > after set_ergonomic_flags(). > > Webrev: http://cr.openjdk.java.net/~iveresov/6996136/webrev.00/ > > igor From openjdk-ml at seichter.de Sat Oct 30 03:49:25 2010 From: openjdk-ml at seichter.de (Ralph Seichter) Date: Sat, 30 Oct 2010 12:49:25 +0200 Subject: My OpenJDK 64-Bit Server VM crashes, what am I doing wrong? In-Reply-To: <4CCB47F8.30609@oracle.com> References: <4CCB2016.5060402@seichter.de> <4CCB47F8.30609@oracle.com> Message-ID: <4CCBF835.2000409@seichter.de> On 30.10.10 00:17, Vladimir Kozlov wrote: > try to switch off compressed oops: -XX:-UseCompressedOops. I did as you and Dmitry Samersoff suggested: $ cat setenv.sh CATALINA_OPTS='-XX:-UseCompressedOops' JAVA_HOME=/usr/local/OpenJDK-1.7.0-201010222126 JRE_HOME=$JAVA_HOME Now I can access the Tomcat manager application without the JVM crashing. > Build fastdebug JVM and run it to get more information. Can I do this by specifying both 'SKIP_FASTDEBUG_BUILD=false' and 'DEBUG_NAME=fastdebug'? I am too fresh to OpenJDK and obviously have some catching up to do, so could you hint at what documents I have to read? Thanks. -Ralph