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: <c3289a9a-e020-431a-a5b3-ee75a72a05b3@default>
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>
<c3289a9a-e020-431a-a5b3-ee75a72a05b3@default>
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/ <http://cr.openjdk.java.net/%7Esla/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 <mailto: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/ <http://cr.openjdk.java.net/%7Esla/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: <AANLkTi==+cUEqcqWi9RZg2gQtAMtOertZxuXsOGQ20MU@mail.gmail.com>
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: <AANLkTi==+cUEqcqWi9RZg2gQtAMtOertZxuXsOGQ20MU@mail.gmail.com>
References: <AANLkTi==+cUEqcqWi9RZg2gQtAMtOertZxuXsOGQ20MU@mail.gmail.com>
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: <AANLkTi==+cUEqcqWi9RZg2gQtAMtOertZxuXsOGQ20MU@mail.gmail.com>
References: <AANLkTi==+cUEqcqWi9RZg2gQtAMtOertZxuXsOGQ20MU@mail.gmail.com>
Message-ID: <AANLkTimrHwLM4Lr5j4FjXgHjMhXXXPjrR9d3_bMjSWRd@mail.gmail.com>
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, ??? <joannechiou at gmail.com> 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: <AANLkTimrHwLM4Lr5j4FjXgHjMhXXXPjrR9d3_bMjSWRd@mail.gmail.com>
References: <AANLkTi==+cUEqcqWi9RZg2gQtAMtOertZxuXsOGQ20MU@mail.gmail.com>
<AANLkTimrHwLM4Lr5j4FjXgHjMhXXXPjrR9d3_bMjSWRd@mail.gmail.com>
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 <cwimmer at uci.edu>
! 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: <C383F0D6-0785-4C40-91EE-BACEFE3544D4@oracle.com>
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: <C383F0D6-0785-4C40-91EE-BACEFE3544D4@oracle.com>
References: <C383F0D6-0785-4C40-91EE-BACEFE3544D4@oracle.com>
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: <C383F0D6-0785-4C40-91EE-BACEFE3544D4@oracle.com>
References: <C383F0D6-0785-4C40-91EE-BACEFE3544D4@oracle.com>
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: <D1101B09-8F47-43B5-BA1B-C29937070643@oracle.com>
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: <C383F0D6-0785-4C40-91EE-BACEFE3544D4@oracle.com>
<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: <D1101B09-8F47-43B5-BA1B-C29937070643@oracle.com>
References: <D1101B09-8F47-43B5-BA1B-C29937070643@oracle.com>
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: <D1101B09-8F47-43B5-BA1B-C29937070643@oracle.com>
<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: <D1101B09-8F47-43B5-BA1B-C29937070643@oracle.com>
<4CAFA115.4040204@oracle.com> <4CAFA3F6.4090500@oracle.com>
Message-ID: <DFF4A326-67BF-4C89-ACAE-1FFF12A09035@oracle.com>
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: <DFF4A326-67BF-4C89-ACAE-1FFF12A09035@oracle.com>
References: <D1101B09-8F47-43B5-BA1B-C29937070643@oracle.com>
<4CAFA115.4040204@oracle.com> <4CAFA3F6.4090500@oracle.com>
<DFF4A326-67BF-4C89-ACAE-1FFF12A09035@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: <D1101B09-8F47-43B5-BA1B-C29937070643@oracle.com>
<4CAFA115.4040204@oracle.com> <4CAFA3F6.4090500@oracle.com>
<DFF4A326-67BF-4C89-ACAE-1FFF12A09035@oracle.com>
<7E92D93A-F96A-4088-AF43-435409F95C25@oracle.com>
Message-ID: <E17F76EC-2576-41A2-9FD2-734E856D13DC@oracle.com>
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: <E17F76EC-2576-41A2-9FD2-734E856D13DC@oracle.com>
References: <D1101B09-8F47-43B5-BA1B-C29937070643@oracle.com> <4CAFA115.4040204@oracle.com>
<4CAFA3F6.4090500@oracle.com> <DFF4A326-67BF-4C89-ACAE-1FFF12A09035@oracle.com> <7E92D93A-F96A-4088-AF43-435409F95C25@oracle.com>
<E17F76EC-2576-41A2-9FD2-734E856D13DC@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: <D1101B09-8F47-43B5-BA1B-C29937070643@oracle.com> <4CAFA115.4040204@oracle.com> <4CAFA3F6.4090500@oracle.com> <DFF4A326-67BF-4C89-ACAE-1FFF12A09035@oracle.com> <7E92D93A-F96A-4088-AF43-435409F95C25@oracle.com> <E17F76EC-2576-41A2-9FD2-734E856D13DC@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: <C383F0D6-0785-4C40-91EE-BACEFE3544D4@oracle.com>
<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: <C383F0D6-0785-4C40-91EE-BACEFE3544D4@oracle.com>
<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: <C383F0D6-0785-4C40-91EE-BACEFE3544D4@oracle.com>
<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: <C383F0D6-0785-4C40-91EE-BACEFE3544D4@oracle.com>
<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: <C383F0D6-0785-4C40-91EE-BACEFE3544D4@oracle.com>
<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: <C383F0D6-0785-4C40-91EE-BACEFE3544D4@oracle.com>
<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 <gbenson at redhat.com>
! 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<oopDesc*>(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<oopDesc*>(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<oopDesc*>(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<oopDesc*>(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: <C383F0D6-0785-4C40-91EE-BACEFE3544D4@oracle.com>
<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: <BD08EF4B-2771-4246-B683-56DFB7649D4A@oracle.com>
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: <E4342E66-3441-4F21-979C-F86064B22A3F@oracle.com>
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: <E4342E66-3441-4F21-979C-F86064B22A3F@oracle.com>
References: <201010272209.o9RM9Peb029052@prt-web.sfbay.sun.com>
<E4342E66-3441-4F21-979C-F86064B22A3F@oracle.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>
<E4342E66-3441-4F21-979C-F86064B22A3F@oracle.com>
<4F475BD1-2F75-4850-86CA-B55F458E8E1F@oracle.com>
Message-ID: <D3382FBD-6496-4D6B-8DC4-A42E9C9EA843@oracle.com>
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: <D3382FBD-6496-4D6B-8DC4-A42E9C9EA843@oracle.com>
References: <201010272209.o9RM9Peb029052@prt-web.sfbay.sun.com>
<E4342E66-3441-4F21-979C-F86064B22A3F@oracle.com>
<4F475BD1-2F75-4850-86CA-B55F458E8E1F@oracle.com>
<D3382FBD-6496-4D6B-8DC4-A42E9C9EA843@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