From aph at redhat.com Mon Aug 1 09:06:25 2011 From: aph at redhat.com (Andrew Haley) Date: Mon, 01 Aug 2011 17:06:25 +0100 Subject: The fix for 7017193 causes segfaults Message-ID: <4E36CF01.3020808@redhat.com> The fix for 7017193 is broken, and we get segfaults in the test case Test6929067.sh http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/677234770800 There are two bugs in os::get_line_chars. One is that we read a char from a file into an int variable and we then use the value of that int variable. However, we do not do anything to zero the upper part of the int variable, so the test is comparing uninitialized memory. The variable should not be an int, but a char. // line is longer than size of buf, skip to EOL int ch; while (read(fd, &ch, 1) == 1 && ch != '\n') { // Do nothing } The second bug is a buffer overflow. bsize is the size of the buffer, which is the number of characters to be read plus a terminating null character. If bsize is 128, no more than 127 characters may be read. This loop reads the characters until i is (bsize-1), i.e. 127: // read until EOF, EOL or buf is full while ((sz = (int) read(fd, &buf[i], 1)) == 1 && i < (bsize-1) && buf[i] != '\n') { ++i; } Then later we do: buf[i+1] = 0; This is buf[128]: we have written past the end of the array. (Despite the fact that this is a buffer overflow, it's not an exploitable security hole because there is no way for any attacker to control /proc/self/maps.) This is my proposed fix. Comments, please. Andrew. --- os.cpp~ 2011-08-01 16:00:06.000000000 +0200 +++ os.cpp 2011-08-01 17:49:52.000000000 +0200 @@ -1301,7 +1301,7 @@ size_t sz, i = 0; // read until EOF, EOL or buf is full - while ((sz = (int) read(fd, &buf[i], 1)) == 1 && i < (bsize-1) && buf[i] != '\n') { + while ((sz = (int) read(fd, &buf[i], 1)) == 1 && i < (bsize-2) && buf[i] != '\n') { ++i; } @@ -1322,7 +1322,7 @@ } // line is longer than size of buf, skip to EOL - int ch; + char ch; while (read(fd, &ch, 1) == 1 && ch != '\n') { // Do nothing } From Dmitry.Samersoff at oracle.com Mon Aug 1 11:06:14 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 1 Aug 2011 11:06:14 -0700 (PDT) Subject: The fix for 7017193 causes segfaults In-Reply-To: <4E36CF01.3020808@redhat.com> References: <4E36CF01.3020808@redhat.com> Message-ID: <4E36EB16.1010805@oracle.com> Andrew, Looks good for me. Will file a bug shortly. -Dmitry On 2011-08-01 20:06, Andrew Haley wrote: > The fix for 7017193 is broken, and we get segfaults in the test case > Test6929067.sh > > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/677234770800 > > There are two bugs in os::get_line_chars. One is that we read a char > from a file into an int variable and we then use the value of that int > variable. However, we do not do anything to zero the upper part of > the int variable, so the test is comparing uninitialized memory. > The variable should not be an int, but a char. > > // line is longer than size of buf, skip to EOL > int ch; > while (read(fd,&ch, 1) == 1&& ch != '\n') { > // Do nothing > } Agree. > The second bug is a buffer overflow. bsize is the size of the buffer, > which is the number of characters to be read plus a terminating null > character. If bsize is 128, no more than 127 characters may be read. > > This loop reads the characters until i is (bsize-1), i.e. 127: > > // read until EOF, EOL or buf is full > while ((sz = (int) read(fd,&buf[i], 1)) == 1&& i < (bsize-1)&& buf[i] != '\n') { > ++i; > } > > Then later we do: > > buf[i+1] = 0; > > This is buf[128]: we have written past the end of the array. > > (Despite the fact that this is a buffer overflow, it's not an > exploitable security hole because there is no way for any attacker to > control /proc/self/maps.) > > This is my proposed fix. Comments, please. > > Andrew. > > > --- os.cpp~ 2011-08-01 16:00:06.000000000 +0200 > +++ os.cpp 2011-08-01 17:49:52.000000000 +0200 > @@ -1301,7 +1301,7 @@ > size_t sz, i = 0; > > // read until EOF, EOL or buf is full > - while ((sz = (int) read(fd,&buf[i], 1)) == 1&& i< (bsize-1)&& buf[i] != '\n') { > + while ((sz = (int) read(fd,&buf[i], 1)) == 1&& i< (bsize-2)&& buf[i] != '\n') { > ++i; > } > > @@ -1322,7 +1322,7 @@ > } > > // line is longer than size of buf, skip to EOL > - int ch; > + char ch; > while (read(fd,&ch, 1) == 1&& ch != '\n') { > // Do nothing > } -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From David.Holmes at oracle.com Mon Aug 1 16:07:19 2011 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 02 Aug 2011 09:07:19 +1000 Subject: The fix for 7017193 causes segfaults In-Reply-To: <4E36CF01.3020808@redhat.com> References: <4E36CF01.3020808@redhat.com> Message-ID: <4E3731A7.4040908@oracle.com> Looks good to me too. Good catch Andrew. David Holmes On 2/08/2011 2:06 AM, Andrew Haley wrote: > The fix for 7017193 is broken, and we get segfaults in the test case > Test6929067.sh > > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/677234770800 > > There are two bugs in os::get_line_chars. One is that we read a char > from a file into an int variable and we then use the value of that int > variable. However, we do not do anything to zero the upper part of > the int variable, so the test is comparing uninitialized memory. > The variable should not be an int, but a char. > > // line is longer than size of buf, skip to EOL > int ch; > while (read(fd,&ch, 1) == 1&& ch != '\n') { > // Do nothing > } > > The second bug is a buffer overflow. bsize is the size of the buffer, > which is the number of characters to be read plus a terminating null > character. If bsize is 128, no more than 127 characters may be read. > > This loop reads the characters until i is (bsize-1), i.e. 127: > > // read until EOF, EOL or buf is full > while ((sz = (int) read(fd,&buf[i], 1)) == 1&& i< (bsize-1)&& buf[i] != '\n') { > ++i; > } > > Then later we do: > > buf[i+1] = 0; > > This is buf[128]: we have written past the end of the array. > > (Despite the fact that this is a buffer overflow, it's not an > exploitable security hole because there is no way for any attacker to > control /proc/self/maps.) > > This is my proposed fix. Comments, please. > > Andrew. > > > --- os.cpp~ 2011-08-01 16:00:06.000000000 +0200 > +++ os.cpp 2011-08-01 17:49:52.000000000 +0200 > @@ -1301,7 +1301,7 @@ > size_t sz, i = 0; > > // read until EOF, EOL or buf is full > - while ((sz = (int) read(fd,&buf[i], 1)) == 1&& i< (bsize-1)&& buf[i] != '\n') { > + while ((sz = (int) read(fd,&buf[i], 1)) == 1&& i< (bsize-2)&& buf[i] != '\n') { > ++i; > } > > @@ -1322,7 +1322,7 @@ > } > > // line is longer than size of buf, skip to EOL > - int ch; > + char ch; > while (read(fd,&ch, 1) == 1&& ch != '\n') { > // Do nothing > } From Dmitry.Samersoff at oracle.com Tue Aug 2 04:26:42 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 02 Aug 2011 15:26:42 +0400 Subject: The fix for 7017193 causes segfaults In-Reply-To: <4E36CF01.3020808@redhat.com> References: <4E36CF01.3020808@redhat.com> Message-ID: <4E37DEF2.8050207@oracle.com> Andrew, New bug id is 7073913. I take care of fix integration. -Dmitry On 2011-08-01 20:06, Andrew Haley wrote: > The fix for 7017193 is broken, and we get segfaults in the test case > Test6929067.sh > > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/677234770800 > > There are two bugs in os::get_line_chars. One is that we read a char > from a file into an int variable and we then use the value of that int > variable. However, we do not do anything to zero the upper part of > the int variable, so the test is comparing uninitialized memory. > The variable should not be an int, but a char. > > // line is longer than size of buf, skip to EOL > int ch; > while (read(fd,&ch, 1) == 1&& ch != '\n') { > // Do nothing > } > > The second bug is a buffer overflow. bsize is the size of the buffer, > which is the number of characters to be read plus a terminating null > character. If bsize is 128, no more than 127 characters may be read. > > This loop reads the characters until i is (bsize-1), i.e. 127: > > // read until EOF, EOL or buf is full > while ((sz = (int) read(fd,&buf[i], 1)) == 1&& i< (bsize-1)&& buf[i] != '\n') { > ++i; > } > > Then later we do: > > buf[i+1] = 0; > > This is buf[128]: we have written past the end of the array. > > (Despite the fact that this is a buffer overflow, it's not an > exploitable security hole because there is no way for any attacker to > control /proc/self/maps.) > > This is my proposed fix. Comments, please. > > Andrew. > > > --- os.cpp~ 2011-08-01 16:00:06.000000000 +0200 > +++ os.cpp 2011-08-01 17:49:52.000000000 +0200 > @@ -1301,7 +1301,7 @@ > size_t sz, i = 0; > > // read until EOF, EOL or buf is full > - while ((sz = (int) read(fd,&buf[i], 1)) == 1&& i< (bsize-1)&& buf[i] != '\n') { > + while ((sz = (int) read(fd,&buf[i], 1)) == 1&& i< (bsize-2)&& buf[i] != '\n') { > ++i; > } > > @@ -1322,7 +1322,7 @@ > } > > // line is longer than size of buf, skip to EOL > - int ch; > + char ch; > while (read(fd,&ch, 1) == 1&& ch != '\n') { > // Do nothing > } -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From christian.thalinger at oracle.com Tue Aug 2 07:36:46 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 2 Aug 2011 16:36:46 +0200 Subject: Merging BSDPort into HotSpot mainline In-Reply-To: <22A45842-E61A-416E-B8EC-73F29D444D7E@apple.com> References: <22A45842-E61A-416E-B8EC-73F29D444D7E@apple.com> Message-ID: <9354327B-0D82-4AD5-B5FF-6496C3DC1641@oracle.com> Since nobody replied yet... I looked at the changes (well, not all of them) and it seems that most (all?) changes should be reviewed by the Runtime Team (we, the Compiler Team, could review the agent changes). To make reviewing a little easier could you upload webrevs to cr.openjdk.java.net and put the links instead of the huge diff on the wiki pages? Then we could also easily see the comments. I hope we can get this in soon. -- Christian On Jul 28, 2011, at 7:17 PM, roger hoover wrote: > As the first of many steps to integrate the Mac OS X Port into mainline jdk8, we need to merge the BSDPort code (on which the Mac OS X Port is based) into the jdk8 mainline. This message is intended to begin the discussion of that merge for HotSpot. > > To make the process manageable, we've looked through the diff and have attempted to break up the changes into some smaller pieces for better discussion and analysis. In particular, since many of the changes are modifications upon the linux port, we've included diffs between linux and bsd for those files as a way to understand the otherwise huge additions of new stuff. > > I've created wiki pages off the BSDPort page that contains these diffs. Please add your comments and analysis to these pages so that It becomes a record of issues to be addressed in this merge. The root sub-page is: > http://wikis.sun.com/display/OpenJDK/BSDPort%2C+Description+of+jdk7+changes > > We're going to need someone on Oracle's hotspot team to help with this. What is the next step? Do I file a bug or change request? > > roger > From tom.rodriguez at oracle.com Tue Aug 2 08:47:39 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 2 Aug 2011 08:47:39 -0700 Subject: Merging BSDPort into HotSpot mainline In-Reply-To: <22A45842-E61A-416E-B8EC-73F29D444D7E@apple.com> References: <22A45842-E61A-416E-B8EC-73F29D444D7E@apple.com> Message-ID: <61124695-9A1F-482D-8C61-B013B1877598@oracle.com> On Jul 28, 2011, at 10:17 AM, roger hoover wrote: > As the first of many steps to integrate the Mac OS X Port into mainline jdk8, we need to merge the BSDPort code (on which the Mac OS X Port is based) into the jdk8 mainline. This message is intended to begin the discussion of that merge for HotSpot. > > To make the process manageable, we've looked through the diff and have attempted to break up the changes into some smaller pieces for better discussion and analysis. In particular, since many of the changes are modifications upon the linux port, we've included diffs between linux and bsd for those files as a way to understand the otherwise huge additions of new stuff. I took the liberty of splitting your patch into 3 parts. The first is the #ifdef TARGET_ changes which are benign, the second is the rest of the changes to shared files and the third is all the new files. Webrevs for 1 and 2 are at http://cr.openjdk.java.net/~never/bsd_headers and http://cr.openjdk.java.net/~never/bsd_other respectively. I haven't generated a webrev for the 3rd part since it requires some trickery to produce it. The header changes look fine. Here are the issues I see in the shared changes. The agent and makefile changes look fine to me. What are the UseMembar changes about? They are fine, I'm curious why they are needed. I believe !UseMembar is more efficient. src/cpu/x86/vm/c1_LIRAssembler_x86.cpp: src/cpu/x86/vm/interp_masm_x86_32.cpp: Why is the change of the cast needed? That idiom is used in many other places that haven't been modified. It's an odd little idiom that could be eliminated by fixing a limitation in the MacroAssembler where it emits larger assembly than it needs to. Mainly I'm just unclear why it was changed in some places and not others. src/share/vm/interpreter/bytecodeTracer.cpp: Should this just be converted to INTPTR_FORMAT and intptr_t? src/share/vm/runtime/os.cpp: This is an odd little hack. Why is this in the JVM? globalDefinitions.hpp: INTPTR_FORMAT has been changed to a decimal format when it's supposed to be hexadecimal. I think it should be PRIxPTR instead. These changes might cause compilation problems on earlier releases since for instance Solaris 8 doesn't have PRI*PTR. We might want to add something like: #ifndef PRIxPTR #ifdef _LP64 #define PRIxPTR PRIx64 #else #define PRIxPTR PRIx32 #endif I see a full copy of elf.h in there as well which I doubt we can accept. It seems to be apple specfic but doesn't mac use MachO? test/Makefile: What's the point of the JTREG_TESTDIRS change? > > I've created wiki pages off the BSDPort page that contains these diffs. Please add your comments and analysis to these pages so that It becomes a record of issues to be addressed in this merge. The root sub-page is: > http://wikis.sun.com/display/OpenJDK/BSDPort%2C+Description+of+jdk7+changes > > We're going to need someone on Oracle's hotspot team to help with this. What is the next step? Do I file a bug or change request? I don't know whether the runtime team will want to pursue some refactoring of the bsd changes so there isn't as much duplication or whether it will be ok to merge it as is and deal with refactoring later. That might affect how we wan to handle this. tom > > roger > From kurt at intricatesoftware.com Tue Aug 2 14:18:17 2011 From: kurt at intricatesoftware.com (Kurt Miller) Date: Tue, 2 Aug 2011 17:18:17 -0400 Subject: Merging BSDPort into HotSpot mainline In-Reply-To: <201108021234.30179.kurt@intricatesoftware.com> References: <201108021234.30179.kurt@intricatesoftware.com> Message-ID: <201108021718.17957.kurt@intricatesoftware.com> Hello Tom, I am a co-founding member together with Greg Lewis of the bsd-port project. I have been involved with BSD support for the JDKs for about eight years starting with 1.3 support on OpenBSD. At times I have also been heavily involved with FreeBSD support and contracted with the FreeBSD foundation multiple times to do the enginering work on certifying 1.5 and 1.6 on FreeBSD. Thank you for the review. I will try to address some of your questions inline below. Greg, I've cc'ed you for help with answering some questions on changes I was not familiar with. On Tuesday 02 August 2011 08:47:39 am Tom Rodriguez wrote: > What are the UseMembar changes about? They are fine, I'm curious why they are needed. I believe !UseMembar is more efficient. In the 1.5 update time-frame Sun was working on changing UseMembar from default true to false. When I intergrated this change into FreeBSD's port we started hitting intermittant segfaults that I debugged and traced back to the UseMembar setting change. Since releasing stable certified binaries quickly was one of the goals, I reverted the UseMembar default back to true instead of taking time to find the root cause. More details can be found in the freebsd-port thread below. http://markmail.org/message/rigdtb5heiliutec IIRC, when I worked on porting BSD hotspot support to 1.6 I tried setting UseMembar default to off/false and it still caused intermittant segfaults. Although, I don't recall if I checked this again with OpenJDK7 on FreeBSD SMP systems. > src/cpu/x86/vm/c1_LIRAssembler_x86.cpp: > src/cpu/x86/vm/interp_masm_x86_32.cpp: > > Why is the change of the cast needed? That idiom is used in many other places that haven't been modified. It's an odd little idiom that could be eliminated by fixing a limitation in the MacroAssembler where it emits larger assembly than it needs to. Mainly I'm just unclear why it was changed in some places and not others. On OpenBSD/i386 and I believe also OS/X/x86_32 intptr_t is typedef to long not int which leads to the following build errors: g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 -DPRODUCT -I. -I/home/truk/jdk/bsd-port/hotspot/src/share/vm/prims -I/home/truk/jdk/bsd-port/hotspot/src/share/vm -I/home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm -I/home/truk/jdk/bsd-port/hotspot/src/os_cpu/bsd_x86/vm -I/home/truk/jdk/bsd-port/hotspot/src/os/bsd/vm -I/home/truk/jdk/bsd-port/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"21.0-b17\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"truk\"" -DHOTSPOT_LIB_ARCH=\"i386\" -DJRE_RELEASE_VERSION="\"1.7.0-internal-truk_2011_08_02_14_13-b00\"" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DDEFAULT_LIBPATH="\"/usr/lib:/usr/X11R6/lib:/usr/local/lib\"" -DTARGET_OS_FAMILY_bsd -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_32 -DTARGET_OS_ARCH_bsd_x86 -DTARGET_OS_ARCH_MODEL_bsd_x86_32 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -pthread -fcheck-new -m32 -march=i586 -pipe -O3 -fno-strict-aliasing -DVM_LITTLE_ENDIAN -Werror -Wpointer-arith -Wconversion -Wsign-compare -c -MMD -MP -MF ../generated/dependencies/c1_LIRAssembler_x86.o.d -o c1_LIRAssembler_x86.o /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp: In member function 'int LIR_Assembler::emit_unwind_handler()': /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp:483: error: call of overloaded 'movptr(Address, int32_t)' is ambiguous /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2317: note: candidates are: void MacroAssembler::movptr(Address, intptr_t) /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2319: note: void MacroAssembler::movptr(Address, RegisterImpl*) /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp:484: error: call of overloaded 'movptr(Address, int32_t)' is ambiguous /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2317: note: candidates are: void MacroAssembler::movptr(Address, intptr_t) /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2319: note: void MacroAssembler::movptr(Address, RegisterImpl*) Hmm, reverting the src/cpu/x86/vm/interp_masm_x86_32.cpp change didn't cause a build issue on OpenBSD. We need an Apple developer to check if this one is needed on OS/X x86_32 still (note this is for 32bit build on OS/X not the 64bit build). > > src/share/vm/interpreter/bytecodeTracer.cpp: > > Should this just be converted to INTPTR_FORMAT and intptr_t? That would work ok on OpenBSD, FreeBSD and OS/X where pthread_t is defined as a pointer. > src/share/vm/runtime/os.cpp: > > This is an odd little hack. Why is this in the JVM? Which one? +#if defined(_ALLBSD_SOURCE) + const time_t zone = (time_t) time_struct.tm_gmtoff; +#else const time_t zone = timezone; +#endif This one is because timezone is a function on BSD. + +#if defined(__OpenBSD__) + // Work-around OpenBSD's lack of $ORIGIN support by pre-loading libnet.so + // ignore errors + dll_build_name(buffer, sizeof(buffer), Arguments::get_dll_dir(), "net"); + dll_load(buffer, ebuf, sizeof(ebuf)); +#endif This one is due to OpenBSD's lack of $ORIGIN support in our runtime linker. I've been meaning to add support for it, but have been short on time. Clearly it is a hack but it is needed for OpenBSD until $ORIGIN is supported. > globalDefinitions.hpp: > > INTPTR_FORMAT has been changed to a decimal format when it's supposed to be hexadecimal. I think it should be PRIxPTR instead. > > These changes might cause compilation problems on earlier releases since for instance Solaris 8 doesn't have PRI*PTR. We might want to add something like: > > #ifndef PRIxPTR > #ifdef _LP64 > #define PRIxPTR PRIx64 > #else > #define PRIxPTR PRIx32 > #endif Greg added these changes. Greg, can you comment on them? > > I see a full copy of elf.h in there as well which I doubt we can accept. It seems to be apple specfic but doesn't mac use MachO? > This was brought in for Apple support. We need an Apple developer to remove it and find the places where the build is missing defines. I don't have an x86 OS/X box at the moment to do this work. > test/Makefile: > > What's the point of the JTREG_TESTDIRS change? Not sure. Greg can you comment on this one? Thank you for the review. Regards, -Kurt From glewis at eyesbeyond.com Tue Aug 2 22:41:01 2011 From: glewis at eyesbeyond.com (Greg Lewis) Date: Tue, 2 Aug 2011 22:41:01 -0700 Subject: Merging BSDPort into HotSpot mainline In-Reply-To: <201108021718.17957.kurt@intricatesoftware.com> References: <201108021234.30179.kurt@intricatesoftware.com> <201108021718.17957.kurt@intricatesoftware.com> Message-ID: <20110803054101.GA75624@misty.eyesbeyond.com> On Tue, Aug 02, 2011 at 05:18:17PM -0400, Kurt Miller wrote: > I am a co-founding member together with Greg Lewis of the bsd-port project. I have been involved with BSD support for the JDKs for about eight years starting with 1.3 support on OpenBSD. At times I have also been heavily involved with FreeBSD support and contracted with the FreeBSD foundation multiple times to do the enginering work on certifying 1.5 and 1.6 on FreeBSD. > > Thank you for the review. I will try to address some of your questions inline below. > > Greg, I've cc'ed you for help with answering some questions on changes I was not familiar with. Thanks Kurt. Comments inline where appropriate, I've trimmed some of the other sections. > On Tuesday 02 August 2011 08:47:39 am Tom Rodriguez wrote: > > What are the UseMembar changes about? They are fine, I'm curious why they are needed. I believe !UseMembar is more efficient. > > In the 1.5 update time-frame Sun was working on changing UseMembar from default true to false. When I intergrated this change into FreeBSD's port we started hitting intermittant segfaults that I debugged and traced back to the UseMembar setting change. Since releasing stable certified binaries quickly was one of the goals, I reverted the UseMembar default back to true instead of taking time to find the root cause. More details can be found in the freebsd-port thread below. > > http://markmail.org/message/rigdtb5heiliutec > > IIRC, when I worked on porting BSD hotspot support to 1.6 I tried setting UseMembar default to off/false and it still caused intermittant segfaults. Although, I don't recall if I checked this again with OpenJDK7 on FreeBSD SMP systems. Do we have a test case that shows this up? I have a FreeBSD SMP system I can run it on. > > globalDefinitions.hpp: > > > > INTPTR_FORMAT has been changed to a decimal format when it's supposed to be hexadecimal. I think it should be PRIxPTR instead. > > > > These changes might cause compilation problems on earlier releases since for instance Solaris 8 doesn't have PRI*PTR. We might want to add something like: > > > > #ifndef PRIxPTR > > #ifdef _LP64 > > #define PRIxPTR PRIx64 > > #else > > #define PRIxPTR PRIx32 > > #endif > > Greg added these changes. Greg, can you comment on them? Previously there were a real mish mash of #defines on how to detect which format to use for printing what, which seemed to be particularly troublesome for MacOS X. I brought in the PRI* changes to avoid that, since that is exactly what they are meant to do in a clean way. I'm ok with the above since it uses the define if it exists. IIRC this was in the C99 standard and I see Solaris 8 was released in 2000. So I can understand it not having it yet. I also see Solaris 8 is due to be end of lifed in March 2012. One question that raises for me is whether Java 8 will be out before then or whether this is a moot question? > > I see a full copy of elf.h in there as well which I doubt we can accept. It seems to be apple specfic but doesn't mac use MachO? > > > > This was brought in for Apple support. We need an Apple developer to remove it and find the places where the build is missing defines. I don't have an x86 OS/X box at the moment to do this work. We likely have a similar problem in the agent code then where IIRC we pull in a file from glibc verbatim. > > test/Makefile: > > > > What's the point of the JTREG_TESTDIRS change? > > Not sure. Greg can you comment on this one? To be honest, I don't recall why we did this one. Looks like it's been that way from the start, so I can only suggest that I changed it that way to run the tests in the compiler directory there and didn't change it back before committing. It can likely be reverted. > Thank you for the review. Seconded. -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org From David.Holmes at oracle.com Tue Aug 2 22:57:17 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 03 Aug 2011 15:57:17 +1000 Subject: Merging BSDPort into HotSpot mainline In-Reply-To: <22A45842-E61A-416E-B8EC-73F29D444D7E@apple.com> References: <22A45842-E61A-416E-B8EC-73F29D444D7E@apple.com> Message-ID: <4E38E33D.5050406@oracle.com> I've only given this a cursory glance so far. Is the intent to add BSD as a new supported OS in the src/build tree (which would argue for the long touted factoring out of the POSIX code from Linux and Solaris - assuming BSD is primarily POSIX-like)? Or is the intent to sprinkle "ifdef BSD" through the linux code (or Solaris? which is closer in API support? Thanks, David Holmes roger hoover said the following on 07/29/11 03:17: > As the first of many steps to integrate the Mac OS X Port into mainline jdk8, we need to merge the BSDPort code (on which the Mac OS X Port is based) into the jdk8 mainline. This message is intended to begin the discussion of that merge for HotSpot. > > To make the process manageable, we've looked through the diff and have attempted to break up the changes into some smaller pieces for better discussion and analysis. In particular, since many of the changes are modifications upon the linux port, we've included diffs between linux and bsd for those files as a way to understand the otherwise huge additions of new stuff. > > I've created wiki pages off the BSDPort page that contains these diffs. Please add your comments and analysis to these pages so that It becomes a record of issues to be addressed in this merge. The root sub-page is: > http://wikis.sun.com/display/OpenJDK/BSDPort%2C+Description+of+jdk7+changes > > We're going to need someone on Oracle's hotspot team to help with this. What is the next step? Do I file a bug or change request? > > roger > From David.Holmes at oracle.com Tue Aug 2 23:26:52 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 03 Aug 2011 16:26:52 +1000 Subject: Merging BSDPort into HotSpot mainline In-Reply-To: <201108021718.17957.kurt@intricatesoftware.com> References: <201108021234.30179.kurt@intricatesoftware.com> <201108021718.17957.kurt@intricatesoftware.com> Message-ID: <4E38EA2C.70104@oracle.com> Kurt Miller said the following on 08/03/11 07:18: > On Tuesday 02 August 2011 08:47:39 am Tom Rodriguez wrote: >> What are the UseMembar changes about? They are fine, I'm curious why they are needed. I believe !UseMembar is more efficient. > > In the 1.5 update time-frame Sun was working on changing UseMembar from default true to false. When I intergrated this change into FreeBSD's port we started hitting intermittant segfaults that I debugged and traced back to the UseMembar setting change. Since releasing stable certified binaries quickly was one of the goals, I reverted the UseMembar default back to true instead of taking time to find the root cause. More details can be found in the freebsd-port thread below. > > http://markmail.org/message/rigdtb5heiliutec > > IIRC, when I worked on porting BSD hotspot support to 1.6 I tried setting UseMembar default to off/false and it still caused intermittant segfaults. Although, I don't recall if I checked this again with OpenJDK7 on FreeBSD SMP systems. This likely indicates that BSD page protection operations are not providing the memory serialization affects that hotspot relies upon to perform a "pseudo remote membar". >> src/share/vm/interpreter/bytecodeTracer.cpp: >> >> Should this just be converted to INTPTR_FORMAT and intptr_t? > > That would work ok on OpenBSD, FreeBSD and OS/X where pthread_t is defined as a pointer. We really should not make assumptions about what the underlying type of thread_t and pthread_t are :( Aside: changes of this form @@ -1110,7 +1113,7 @@ } nmethod* nm = method->code(); if (WizardMode && nm != NULL) { - sprintf(buf + (int)strlen(buf), "(nmethod " PTR_FORMAT ")", (intptr_t)nm); + sprintf(buf + (int)strlen(buf), "(nmethod " INTPTR_FORMAT ")", (intptr_t)nm); } } are actually changing the wrong thing. The lack of properly defined portable format-specifiers for pointer types means that our current set of macros are always being subject to various proposals to "fix" them. What we are actually printing is a pointer and PTR_FORMAT is logically the right thing to use, but the actual definition (as an int type) causes compiler warnings which lead to the cast to intptr_t. Which in turn leads to the suggestion that the format specifier should actually be INTPTR_FORMAT. See CR 6990479 - PTR_FORMAT needs to be a pointer format. Cheers, David Holmes From john.pampuch at oracle.com Wed Aug 3 03:39:57 2011 From: john.pampuch at oracle.com (John Pampuch) Date: Wed, 3 Aug 2011 05:39:57 -0500 Subject: Merging BSDPort into HotSpot mainline In-Reply-To: <4E38E33D.5050406@oracle.com> References: <22A45842-E61A-416E-B8EC-73F29D444D7E@apple.com> <4E38E33D.5050406@oracle.com> Message-ID: <1ED49ECC-4B48-495F-8356-D0AFF183E894@oracle.com> Ultimately, this could give us the impetus to refactor into a posix tree with sub-factorings for Linux, BSD and Solaris but expediency might prevent that from happening in short order. -John Sent from my other location On Aug 3, 2011, at 12:57 AM, David Holmes wrote: > I've only given this a cursory glance so far. > > Is the intent to add BSD as a new supported OS in the src/build tree > (which would argue for the long touted factoring out of the POSIX code > from Linux and Solaris - assuming BSD is primarily POSIX-like)? Or is > the intent to sprinkle "ifdef BSD" through the linux code (or Solaris? > which is closer in API support? > > Thanks, > David Holmes > > roger hoover said the following on 07/29/11 03:17: >> As the first of many steps to integrate the Mac OS X Port into mainline jdk8, we need to merge the BSDPort code (on which the Mac OS X Port is based) into the jdk8 mainline. This message is intended to begin the discussion of that merge for HotSpot. >> >> To make the process manageable, we've looked through the diff and have attempted to break up the changes into some smaller pieces for better discussion and analysis. In particular, since many of the changes are modifications upon the linux port, we've included diffs between linux and bsd for those files as a way to understand the otherwise huge additions of new stuff. >> >> I've created wiki pages off the BSDPort page that contains these diffs. Please add your comments and analysis to these pages so that It becomes a record of issues to be addressed in this merge. The root sub-page is: >> http://wikis.sun.com/display/OpenJDK/BSDPort%2C+Description+of+jdk7+changes >> >> We're going to need someone on Oracle's hotspot team to help with this. What is the next step? Do I file a bug or change request? >> >> roger >> From rhoover at apple.com Wed Aug 3 05:19:49 2011 From: rhoover at apple.com (roger hoover) Date: Wed, 03 Aug 2011 06:19:49 -0600 Subject: Merging BSDPort into HotSpot mainline In-Reply-To: <1ED49ECC-4B48-495F-8356-D0AFF183E894@oracle.com> References: <22A45842-E61A-416E-B8EC-73F29D444D7E@apple.com> <4E38E33D.5050406@oracle.com> <1ED49ECC-4B48-495F-8356-D0AFF183E894@oracle.com> Message-ID: <3E7E8084-77C3-44CB-8588-712658B2EED4@apple.com> In answer to David's question, the current framework encourages the addition of BSD as a new OS, and that is what the diff proposes. The additional linux/bsd diffs were created for code understanding and this discussion. The forthcoming Mac OS X changes will be ifdef modifications inside the BSD OS. As someone who has spent the many years porting much of the solaris (and later linux) code into such a parallel os, John's suggested refactoring is something worth looking at. roger On Aug 3, 2011, at 4:39 AM, John Pampuch wrote: > Ultimately, this could give us the impetus to refactor into a posix tree with sub-factorings for Linux, BSD and Solaris but expediency might prevent that from happening in short order. > > -John > > Sent from my other location > > On Aug 3, 2011, at 12:57 AM, David Holmes wrote: > >> I've only given this a cursory glance so far. >> >> Is the intent to add BSD as a new supported OS in the src/build tree >> (which would argue for the long touted factoring out of the POSIX code >> from Linux and Solaris - assuming BSD is primarily POSIX-like)? Or is >> the intent to sprinkle "ifdef BSD" through the linux code (or Solaris? >> which is closer in API support? >> >> Thanks, >> David Holmes >> >> roger hoover said the following on 07/29/11 03:17: >>> As the first of many steps to integrate the Mac OS X Port into mainline jdk8, we need to merge the BSDPort code (on which the Mac OS X Port is based) into the jdk8 mainline. This message is intended to begin the discussion of that merge for HotSpot. >>> >>> To make the process manageable, we've looked through the diff and have attempted to break up the changes into some smaller pieces for better discussion and analysis. In particular, since many of the changes are modifications upon the linux port, we've included diffs between linux and bsd for those files as a way to understand the otherwise huge additions of new stuff. >>> >>> I've created wiki pages off the BSDPort page that contains these diffs. Please add your comments and analysis to these pages so that It becomes a record of issues to be addressed in this merge. The root sub-page is: >>> http://wikis.sun.com/display/OpenJDK/BSDPort%2C+Description+of+jdk7+changes >>> >>> We're going to need someone on Oracle's hotspot team to help with this. What is the next step? Do I file a bug or change request? >>> >>> roger >>> From kurt at intricatesoftware.com Wed Aug 3 08:24:22 2011 From: kurt at intricatesoftware.com (Kurt Miller) Date: Wed, 3 Aug 2011 11:24:22 -0400 Subject: Merging BSDPort into HotSpot mainline In-Reply-To: <20110803054101.GA75624@misty.eyesbeyond.com> References: <201108021234.30179.kurt@intricatesoftware.com> <201108021718.17957.kurt@intricatesoftware.com> <20110803054101.GA75624@misty.eyesbeyond.com> Message-ID: <201108031124.22918.kurt@intricatesoftware.com> On Wednesday 03 August 2011 01:41:01 am Greg Lewis wrote: > On Tue, Aug 02, 2011 at 05:18:17PM -0400, Kurt Miller wrote: > > On Tuesday 02 August 2011 08:47:39 am Tom Rodriguez wrote: > > > What are the UseMembar changes about? They are fine, I'm curious why they are needed. I believe !UseMembar is more efficient. > > > > In the 1.5 update time-frame Sun was working on changing UseMembar from default true to false. When I intergrated this change into FreeBSD's port we started hitting intermittant segfaults that I debugged and traced back to the UseMembar setting change. Since releasing stable certified binaries quickly was one of the goals, I reverted the UseMembar default back to true instead of taking time to find the root cause. More details can be found in the freebsd-port thread below. > > > > http://markmail.org/message/rigdtb5heiliutec > > > > IIRC, when I worked on porting BSD hotspot support to 1.6 I tried setting UseMembar default to off/false and it still caused intermittant segfaults. Although, I don't recall if I checked this again with OpenJDK7 on FreeBSD SMP systems. > > Do we have a test case that shows this up? I have a FreeBSD SMP system I > can run it on. Hi Greg, Refreshing my memory by reading the freebsd-java list for this time-frame and I see that it was rather easy to reproduce on SMP hardware. Reports included using tomcat, netbeans and in one case 'java -version'. Here's the search I used: http://markmail.org/search/list:org%2Efreebsd%2Efreebsd-java+sigbus+diablo+1%2E5%2E0_06 Thanks, -Kurt From kurt at intricatesoftware.com Wed Aug 3 08:57:52 2011 From: kurt at intricatesoftware.com (Kurt Miller) Date: Wed, 3 Aug 2011 11:57:52 -0400 Subject: Merging BSDPort into HotSpot mainline In-Reply-To: <4E38EA2C.70104@oracle.com> References: <201108021234.30179.kurt@intricatesoftware.com> <201108021718.17957.kurt@intricatesoftware.com> <4E38EA2C.70104@oracle.com> Message-ID: <201108031157.52244.kurt@intricatesoftware.com> On Wednesday 03 August 2011 02:26:52 am David Holmes wrote: > Kurt Miller said the following on 08/03/11 07:18: > > On Tuesday 02 August 2011 08:47:39 am Tom Rodriguez wrote: > >> What are the UseMembar changes about? They are fine, I'm curious why they are needed. I believe !UseMembar is more efficient. > > > > In the 1.5 update time-frame Sun was working on changing UseMembar from default true to false. When I intergrated this change into FreeBSD's port we started hitting intermittant segfaults that I debugged and traced back to the UseMembar setting change. Since releasing stable certified binaries quickly was one of the goals, I reverted the UseMembar default back to true instead of taking time to find the root cause. More details can be found in the freebsd-port thread below. > > > > http://markmail.org/message/rigdtb5heiliutec > > > > IIRC, when I worked on porting BSD hotspot support to 1.6 I tried setting UseMembar default to off/false and it still caused intermittant segfaults. Although, I don't recall if I checked this again with OpenJDK7 on FreeBSD SMP systems. > > This likely indicates that BSD page protection operations are not > providing the memory serialization affects that hotspot relies upon to > perform a "pseudo remote membar". Thanks for the pointer. I think I see what your getting at; the calls to os::protect_memory() in ./share/vm/runtime/os.cpp os::serialize_thread_states()? What exactly is the behavior that hotspot is relying on? Can you be more specific about what memory serialization affects that mprotect(2) should be doing? It is more elaborate than adding OrderAccess::fence(); to bsd_mprotect()? Thanks, -Kurt From thomas.wuerthinger at oracle.com Wed Aug 3 10:24:18 2011 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Wed, 03 Aug 2011 10:24:18 -0700 Subject: Enhanced Class Redefinition JEP In-Reply-To: <4E32EDF0.1070601@oracle.com> References: <4E308B49.9070902@oracle.com> <4E32EDF0.1070601@oracle.com> Message-ID: <4E398442.7050200@oracle.com> Jon, The underlying implementation changes from merging the constant pools of the old and the new class version to performing a heap iteration that swaps pointers. However, this change is not visible to users of the class redefinition API. The behavior in terms of effects observable through the JVMTI interface stays the same (for example in the case that a modified method is active on the stack). We do not yet have performance comparison numbers between the old and the new algorithm. However, if the heap iteration turns out to be a bottleneck, we can implement a workaround where the iteration is not necessary when only method bodies are swapped. - thomas On 7/29/2011 10:29 AM, Jon Masamitsu wrote: > Thomas, > > From the JEP Description section > > "The behavior of the current mechanism that swaps method bodies is > unaffected." > > As I recall some of the class redefinition in your implementation > requires > doing a heap iteration (scan and update similar to a full GC) > to update references to redefined classes. > Does the statement above from the description mean that in your > implementation the swapping method bodies does not require the > heap iteration? I think the current implementation in hotspot does > not require such an iteration. > > Jon > > > > > On 7/27/2011 3:03 PM, Thomas Wuerthinger wrote: >> Hi all, >> >> find attached a JDK Enhancement-Proposal (JEP) for enhancing >> HotSpot's class redefinition capabilities. The proposed features >> include adding/removing methods and fields as well as adding >> supertypes. The JEP includes links to a prototype implementation and >> technical publications about the approach. >> >> Regards, >> Thomas Wuerthinger From glewis at eyesbeyond.com Wed Aug 3 11:29:49 2011 From: glewis at eyesbeyond.com (Greg Lewis) Date: Wed, 3 Aug 2011 11:29:49 -0700 Subject: Merging BSDPort into HotSpot mainline In-Reply-To: <4E38E33D.5050406@oracle.com> References: <22A45842-E61A-416E-B8EC-73F29D444D7E@apple.com> <4E38E33D.5050406@oracle.com> Message-ID: <20110803182949.GA50000@misty.eyesbeyond.com> G'day David, On Wed, Aug 03, 2011 at 03:57:17PM +1000, David Holmes wrote: > I've only given this a cursory glance so far. > > Is the intent to add BSD as a new supported OS in the src/build tree > (which would argue for the long touted factoring out of the POSIX code > from Linux and Solaris - assuming BSD is primarily POSIX-like)? Or is > the intent to sprinkle "ifdef BSD" through the linux code (or Solaris? > which is closer in API support? As others have mentioned, it is the former. I agree that a factoring out of the POSIX/SUS code would be a good move. The question is whether adding such a requirement to the bringing in of new platform support or whether working with the HotSpot group post-import is the right way to do that. I'd argue for the latter since I think requiring the refactoring for new platform support is an undue burden to place upon the porting team. > roger hoover said the following on 07/29/11 03:17: > > As the first of many steps to integrate the Mac OS X Port into mainline jdk8, we need to merge the BSDPort code (on which the Mac OS X Port is based) into the jdk8 mainline. This message is intended to begin the discussion of that merge for HotSpot. > > > > To make the process manageable, we've looked through the diff and have attempted to break up the changes into some smaller pieces for better discussion and analysis. In particular, since many of the changes are modifications upon the linux port, we've included diffs between linux and bsd for those files as a way to understand the otherwise huge additions of new stuff. > > > > I've created wiki pages off the BSDPort page that contains these diffs. Please add your comments and analysis to these pages so that It becomes a record of issues to be addressed in this merge. The root sub-page is: > > http://wikis.sun.com/display/OpenJDK/BSDPort%2C+Description+of+jdk7+changes > > > > We're going to need someone on Oracle's hotspot team to help with this. What is the next step? Do I file a bug or change request? > > > > roger > > -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org From yuri.gaevsky at oracle.com Mon Aug 1 02:26:32 2011 From: yuri.gaevsky at oracle.com (Yuri Gaevsky) Date: Mon, 01 Aug 2011 13:26:32 +0400 Subject: Enhanced Class Redefinition JEP In-Reply-To: <4E31C959.6060904@oracle.com> References: <4E308B49.9070902@oracle.com> <4E317429.9090600@oracle.com> <4E31C959.6060904@oracle.com> Message-ID: <4E367148.8040005@oracle.com> Hi Thomas, Please note that the similar changes should also be done for: http://download.oracle.com/javase/7/docs/platform/jpda/jdwp/jdwp-protocol.html#JDWP_VirtualMachine_RedefineClasses Best regards, -Yuri On 29.07.2011 0:40, Thomas Wuerthinger wrote: > On 7/28/2011 7:37 AM, Alan Bateman wrote: >> Thomas - this looks very good work. A minor comment on the description is that you mention that it does not modify any >> Java APIs but I assume there is an opportunity to relax the restrictions specified in Instrumentation's >> redefineClasses and retransformClasses as specify the same restrictions as JVMTI today. > Yes, thanks for pointing that out. In the description of those methods, there are the following sentences: > > "The redefinition must not add, remove or rename fields or methods, change the signatures of methods, or change > inheritance. These restrictions maybe be lifted in future versions." > > Those sentences should be changed to only refer to the remaining restriction of removing supertypes. Also, the > implementation of the method "canUnrestrictedlyRedefineClasses" of the interface "com.sun.jdi.VirtualMachine" should be > changed to return true. There is however no need to add an additional method or change the signature of an existing > method in the JDI, JVMTI, or instrumentation API. > > Regards, > Thomas Wuerthinger From weijun.wang at oracle.com Wed Aug 3 19:24:44 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 04 Aug 2011 10:24:44 +0800 Subject: final inner class not final (was Re: Code review request: 7064075 Security libraries don't build with javac -Xlint:all, -deprecation -Werror) In-Reply-To: <4E39DC1C.9040705@oracle.com> References: <4E1B6366.106@oracle.com> <4E1CA8A1.1050409@oracle.com> <4E1CAB92.8080408@oracle.com> <4E203037.6000605@oracle.com> <4E203E43.1010305@oracle.com> <4E246A9D.4010702@oracle.com> <4E249AFB.6040804@oracle.com> <4E24A730.1000301@oracle.com> <4E24ACF8.30009@oracle.com> <4E24D0CF.5060801@oracle.com> <4E24DC03.3030407@oracle.com> <4E2611A2.2080400@oracle.com> <4E263E4E.7030006@oracle.com> <4E270FA4.4010605@oracle.com> <3F614290-E355-4207-90F1-9AB01378FBF6@Oracle.Com> <4E2EFA05.60806@oracle.com> <4E30574A.8020907@oracle.com> <4E39DC1C.9040705@oracle.com> Message-ID: <4E3A02EC.4030901@oracle.com> > serialVersionUID warnings for classes that have had different > generated serialVersionUID's in the past. >>> sun.security.pkcs11.P11TlsPrfGenerator$1 >>> -currently: -8090049519656411362L; >>> -JDK 6: -3305145912345854189L; I find out the reason: Since 6u11, a final inner class is *not* final anymore. $ cat A4.java import java.lang.reflect.Modifier; public class A4 { public static void main(String[] args) throws Exception { Class c = Class.forName(args[0]); System.out.println(c.getModifiers() & Modifier.FINAL); } } $ java A4 java.lang.String 16 $ java A4 'sun.security.pkcs11.P11TlsPrfGenerator$1' 0 getModifiers() is a native method, and calls JVM_GetClassModifiers. Is this an intended change? FYI, the class is defined as private static final SecretKey NULL_KEY = new SecretKey() { .... in http://hg.openjdk.java.net/jdk8/tl/jdk/file/809e8db0c142/src/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java, line 100. Thanks Max From tom.rodriguez at oracle.com Thu Aug 4 11:29:00 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 4 Aug 2011 11:29:00 -0700 Subject: final inner class not final (was Re: Code review request: 7064075 Security libraries don't build with javac -Xlint:all, -deprecation -Werror) In-Reply-To: <4E3A02EC.4030901@oracle.com> References: <4E1B6366.106@oracle.com> <4E1CA8A1.1050409@oracle.com> <4E1CAB92.8080408@oracle.com> <4E203037.6000605@oracle.com> <4E203E43.1010305@oracle.com> <4E246A9D.4010702@oracle.com> <4E249AFB.6040804@oracle.com> <4E24A730.1000301@oracle.com> <4E24ACF8.30009@oracle.com> <4E24D0CF.5060801@oracle.com> <4E24DC03.3030407@oracle.com> <4E2611A2.2080400@oracle.com> <4E263E4E.7030006@oracle.com> <4E270FA4.4010605@oracle.com> <3F614290-E355-4207-90F1-9AB01378FBF6@Oracle.Com> <4E2EFA05.60806@oracle.com> <4E30574A.8020907@oracle.com> <4E39DC1C.9040705@oracle.com> <4E3A02EC.4030901@oracle.com> Message-ID: I think that's a javac issue. The inner class has an attribute which describes the access flags that the VM should report and that changed in _11. Here it is in _10. Attr(#25) { // InnerClasses [] { // InnerClasses #4 #0 #0 24; } } // end InnerClasses and here's _11: Attr(#25) { // InnerClasses [] { // InnerClasses #4 #0 #0 8; } } // end InnerClasses tom On Aug 3, 2011, at 7:24 PM, Weijun Wang wrote: >> serialVersionUID warnings for classes that have had different >> generated serialVersionUID's in the past. >>>> sun.security.pkcs11.P11TlsPrfGenerator$1 >>>> -currently: -8090049519656411362L; >>>> -JDK 6: -3305145912345854189L; > > I find out the reason: > > Since 6u11, a final inner class is *not* final anymore. > > $ cat A4.java > import java.lang.reflect.Modifier; > public class A4 { > public static void main(String[] args) throws Exception { > Class c = Class.forName(args[0]); > System.out.println(c.getModifiers() & Modifier.FINAL); > } > } > $ java A4 java.lang.String > 16 > $ java A4 'sun.security.pkcs11.P11TlsPrfGenerator$1' > 0 > > getModifiers() is a native method, and calls JVM_GetClassModifiers. Is this an intended change? > > FYI, the class is defined as > > private static final SecretKey NULL_KEY = new SecretKey() { > .... > > in http://hg.openjdk.java.net/jdk8/tl/jdk/file/809e8db0c142/src/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java, line 100. > > > Thanks > Max From David.Holmes at oracle.com Thu Aug 4 18:54:14 2011 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 05 Aug 2011 11:54:14 +1000 Subject: final inner class not final (was Re: Code review request: 7064075 Security libraries don't build with javac -Xlint:all, -deprecation -Werror) In-Reply-To: <4E3A02EC.4030901@oracle.com> References: <4E1B6366.106@oracle.com> <4E1CA8A1.1050409@oracle.com> <4E1CAB92.8080408@oracle.com> <4E203037.6000605@oracle.com> <4E203E43.1010305@oracle.com> <4E246A9D.4010702@oracle.com> <4E249AFB.6040804@oracle.com> <4E24A730.1000301@oracle.com> <4E24ACF8.30009@oracle.com> <4E24D0CF.5060801@oracle.com> <4E24DC03.3030407@oracle.com> <4E2611A2.2080400@oracle.com> <4E263E4E.7030006@oracle.com> <4E270FA4.4010605@oracle.com> <3F614290-E355-4207-90F1-9AB01378FBF6@Oracle.Com> <4E2EFA05.60806@oracle.com> <4E30574A.8020907@oracle.com> <4E39DC1C.9040705@oracle.com> <4E3A02EC.4030901@oracle.com> Message-ID: <4E3B4D46.3000606@oracle.com> Max, See 6520152. For backward compatability anonymous inner classes don't have the ACC_FINAL bit set. David Weijun Wang said the following on 08/04/11 12:24: >> serialVersionUID warnings for classes that have had different >> generated serialVersionUID's in the past. >>>> sun.security.pkcs11.P11TlsPrfGenerator$1 >>>> -currently: -8090049519656411362L; >>>> -JDK 6: -3305145912345854189L; > > I find out the reason: > > Since 6u11, a final inner class is *not* final anymore. > > $ cat A4.java > import java.lang.reflect.Modifier; > public class A4 { > public static void main(String[] args) throws Exception { > Class c = Class.forName(args[0]); > System.out.println(c.getModifiers() & Modifier.FINAL); > } > } > $ java A4 java.lang.String > 16 > $ java A4 'sun.security.pkcs11.P11TlsPrfGenerator$1' > 0 > > getModifiers() is a native method, and calls JVM_GetClassModifiers. Is > this an intended change? > > FYI, the class is defined as > > private static final SecretKey NULL_KEY = new SecretKey() { > .... > > in > http://hg.openjdk.java.net/jdk8/tl/jdk/file/809e8db0c142/src/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java, > line 100. > > > Thanks > Max From David.Holmes at oracle.com Thu Aug 4 19:07:58 2011 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 05 Aug 2011 12:07:58 +1000 Subject: final inner class not final (was Re: Code review request: 7064075 Security libraries don't build with javac -Xlint:all, -deprecation -Werror) In-Reply-To: References: <4E1B6366.106@oracle.com> <4E1CA8A1.1050409@oracle.com> <4E1CAB92.8080408@oracle.com> <4E203037.6000605@oracle.com> <4E203E43.1010305@oracle.com> <4E246A9D.4010702@oracle.com> <4E249AFB.6040804@oracle.com> <4E24A730.1000301@oracle.com> <4E24ACF8.30009@oracle.com> <4E24D0CF.5060801@oracle.com> <4E24DC03.3030407@oracle.com> <4E2611A2.2080400@oracle.com> <4E263E4E.7030006@oracle.com> <4E270FA4.4010605@oracle.com> <3F614290-E355-4207-90F1-9AB01378FBF6@Oracle.Com> <4E2EFA05.60806@oracle.com> <4E30574A.8020907@oracle.com> <4E39DC1C.9040705@oracle.com> <4E3A02EC.4030901@oracle.com> Message-ID: <4E3B507E.5020200@oracle.com> Interesting - 6520152 was fixed in 6u4, so it would appear that this got turned on again at some stage and then off again in 6u11. Though I don't see a bug fix in 6u11 that would cover this. David Tom Rodriguez said the following on 08/05/11 04:29: > I think that's a javac issue. The inner class has an attribute which describes the access flags that the VM should report and that changed in _11. Here it is in _10. > > Attr(#25) { // InnerClasses > [] { // InnerClasses > #4 #0 #0 24; > } > } // end InnerClasses > > and here's _11: > > Attr(#25) { // InnerClasses > [] { // InnerClasses > #4 #0 #0 8; > } > } // end InnerClasses > > tom > > On Aug 3, 2011, at 7:24 PM, Weijun Wang wrote: > >>> serialVersionUID warnings for classes that have had different >>> generated serialVersionUID's in the past. >>>>> sun.security.pkcs11.P11TlsPrfGenerator$1 >>>>> -currently: -8090049519656411362L; >>>>> -JDK 6: -3305145912345854189L; >> I find out the reason: >> >> Since 6u11, a final inner class is *not* final anymore. >> >> $ cat A4.java >> import java.lang.reflect.Modifier; >> public class A4 { >> public static void main(String[] args) throws Exception { >> Class c = Class.forName(args[0]); >> System.out.println(c.getModifiers() & Modifier.FINAL); >> } >> } >> $ java A4 java.lang.String >> 16 >> $ java A4 'sun.security.pkcs11.P11TlsPrfGenerator$1' >> 0 >> >> getModifiers() is a native method, and calls JVM_GetClassModifiers. Is this an intended change? >> >> FYI, the class is defined as >> >> private static final SecretKey NULL_KEY = new SecretKey() { >> .... >> >> in http://hg.openjdk.java.net/jdk8/tl/jdk/file/809e8db0c142/src/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java, line 100. >> >> >> Thanks >> Max > From weijun.wang at oracle.com Thu Aug 4 20:00:53 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 05 Aug 2011 11:00:53 +0800 Subject: final inner class not final (was Re: Code review request: 7064075 Security libraries don't build with javac -Xlint:all, -deprecation -Werror) In-Reply-To: <4E3B507E.5020200@oracle.com> References: <4E1B6366.106@oracle.com> <4E1CA8A1.1050409@oracle.com> <4E1CAB92.8080408@oracle.com> <4E203037.6000605@oracle.com> <4E203E43.1010305@oracle.com> <4E246A9D.4010702@oracle.com> <4E249AFB.6040804@oracle.com> <4E24A730.1000301@oracle.com> <4E24ACF8.30009@oracle.com> <4E24D0CF.5060801@oracle.com> <4E24DC03.3030407@oracle.com> <4E2611A2.2080400@oracle.com> <4E263E4E.7030006@oracle.com> <4E270FA4.4010605@oracle.com> <3F614290-E355-4207-90F1-9AB01378FBF6@Oracle.Com> <4E2EFA05.60806@oracle.com> <4E30574A.8020907@oracle.com> <4E39DC1C.9040705@oracle.com> <4E3A02EC.4030901@oracle.com> <4E3B507E.5020200@oracle.com> Message-ID: <4E3B5CE5.8020604@oracle.com> No, it isn't that complicated. Take another class sun.security.jca.ProviderList$1 for example: 6-b54: 1151354171352296389L 6-b55: -8369942687198303343L (6219964) 6u3-latest: -8369942687198303343L 6u4-latest: 1151354171352296389L (6520152) So the times are connect. sun.security.pkcs11.P11TlsPrfGenerator$1 is a JCE class which is inside the ext/sunpkcs11.jar. Most likely that jar was only compiled using the new javac from 6u11. Thanks Max On 08/05/2011 10:07 AM, David Holmes wrote: > Interesting - 6520152 was fixed in 6u4, so it would appear that this got > turned on again at some stage and then off again in 6u11. Though I don't > see a bug fix in 6u11 that would cover this. > > David > > Tom Rodriguez said the following on 08/05/11 04:29: >> I think that's a javac issue. The inner class has an attribute which >> describes the access flags that the VM should report and that changed >> in _11. Here it is in _10. >> >> Attr(#25) { // InnerClasses >> [] { // InnerClasses >> #4 #0 #0 24; >> } >> } // end InnerClasses >> >> and here's _11: >> >> Attr(#25) { // InnerClasses >> [] { // InnerClasses >> #4 #0 #0 8; >> } >> } // end InnerClasses >> >> tom >> >> On Aug 3, 2011, at 7:24 PM, Weijun Wang wrote: >> >>>> serialVersionUID warnings for classes that have had different >>>> generated serialVersionUID's in the past. >>>>>> sun.security.pkcs11.P11TlsPrfGenerator$1 >>>>>> -currently: -8090049519656411362L; >>>>>> -JDK 6: -3305145912345854189L; >>> I find out the reason: >>> >>> Since 6u11, a final inner class is *not* final anymore. >>> >>> $ cat A4.java >>> import java.lang.reflect.Modifier; >>> public class A4 { >>> public static void main(String[] args) throws Exception { >>> Class c = Class.forName(args[0]); >>> System.out.println(c.getModifiers() & Modifier.FINAL); >>> } >>> } >>> $ java A4 java.lang.String >>> 16 >>> $ java A4 'sun.security.pkcs11.P11TlsPrfGenerator$1' >>> 0 >>> >>> getModifiers() is a native method, and calls JVM_GetClassModifiers. >>> Is this an intended change? >>> >>> FYI, the class is defined as >>> >>> private static final SecretKey NULL_KEY = new SecretKey() { >>> .... >>> >>> in >>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/809e8db0c142/src/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java, >>> line 100. >>> >>> >>> Thanks >>> Max >> From c.m.bockisch at cs.utwente.nl Fri Aug 5 03:08:39 2011 From: c.m.bockisch at cs.utwente.nl (Christoph Bockisch) Date: Fri, 05 Aug 2011 12:08:39 +0200 Subject: extended deadline: workshop on Virtual Machines and Intermediate Languages (VMIL) Message-ID: <4E3BC127.3010708@cs.utwente.nl> Dear Colleagues: as there have been requests to get some more time improving submissions to the VMIL workshop, we have decided to extend the deadline. For the details, see below. But please note that abstract submission is now mandatory. This workshop is a forum for research in virtual machines (VM) and intermediate languages (IL). It is dedicated to identifying programming mechanisms and constructs that are currently realized as code transformations or implemented in libraries but should rather be supported at VM and IL level. ------------------------------------------------------------ **Invited Talks** In the tradition of past VMIL workshops, the 2011 edition will feature high-quality, on-topic invited talks. Speakers and titles will be announced later. ------------------------------------------------------------ **Due Dates** Abstract submission is mandatory until August 8, 2011. Papers for VMIL are due Aug 12, 2011. Notification of acceptance will be on Sep 1, 2011. ------------------------------------------------------------ **Program Committee** We have once again assembled an excellent program committee which consists of: Steve Blackburn (Chair), Cliff Click, David Grove, Kim Hazelwood, Antony Hosking, Doug Lea, Ben Titzer, and Olivier Zendra. ------------------------------------------------------------ For more details please see: http://www.cs.iastate.edu/~design/vmil/ We look forward to your submissions to VMIL 2011. Best regards, Hridesh Rajan, Christoph Bockisch, Michael Haupt and Robert Dyer VMIL 2011 Organizers From zhouyx at linux.vnet.ibm.com Sun Aug 7 20:34:25 2011 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Mon, 8 Aug 2011 11:34:25 +0800 Subject: Enhanced Class Redefinition JEP In-Reply-To: <4E308B49.9070902@oracle.com> References: <4E308B49.9070902@oracle.com> Message-ID: Great feature. I just have one consideration after reading the paper. If A.a calls B.b calls C.c in application, A.a and C.c is going to be redefined. During running, a thread is executing in B.b just before invoking C.c when the class redefine is triggered. Will B.b invoke the new version of C'.c' or the old version C.c? I remember the current implementation is to invoke the new version. 2011/7/28 Thomas Wuerthinger > Hi all, > > find attached a JDK Enhancement-Proposal (JEP) for enhancing HotSpot's > class redefinition capabilities. The proposed features include > adding/removing methods and fields as well as adding supertypes. The JEP > includes links to a prototype implementation and technical publications > about the approach. > > Regards, > Thomas Wuerthinger > -- Best Regards, Sean Chou -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110808/a9150415/attachment.html From gary.collins at sun.com Mon Aug 8 18:09:46 2011 From: gary.collins at sun.com (gary.collins at sun.com) Date: Tue, 09 Aug 2011 01:09:46 +0000 Subject: hg: hsx/hotspot-main/hotspot: 7072341: enable hotspot builds on Linux 3.0 Message-ID: <20110809010952.EB72147A32@hg.openjdk.java.net> Changeset: ca1f1753c866 Author: andrew Date: 2011-07-28 14:10 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ca1f1753c866 7072341: enable hotspot builds on Linux 3.0 Summary: Add "3" to list of allowable versions Reviewed-by: kamg, chrisphi ! make/linux/Makefile From danhicks at fastmail.fm Tue Aug 9 04:24:10 2011 From: danhicks at fastmail.fm (Dan Hicks) Date: Tue, 09 Aug 2011 06:24:10 -0500 Subject: Apparent JITC bug In-Reply-To: References: Message-ID: <4E4118DA.30306@fastmail.fm> This sequence fails on Linux JDK 1.6.0_21, and an unknown Java version on OS X 10.6.8: |public class Prototype { public static void main(String[] args) { final int start= Integer.MAX_VALUE/2; final int end= Integer.MAX_VALUE; { long b= 0; for (int i= start; i< end; i++) { b++; } System.out.println(b); } { long b= 0; for (int i= start; i< end; i++) { b++; } System.out.println(b); } } } | The second loop terminates early, producing a different, random, erroneous result when compared to the first. http://stackoverflow.com/questions/6995225/erroneous-for-loops-in-java I'm guessing the bug has something to do with trying to jump into a just-JITed loop while executing. -- Dan Hicks It is an ironic habit of human beings to run faster when we have lost our way. --Rollo May -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110809/4c951464/attachment.html From vladimir.kozlov at oracle.com Tue Aug 9 08:18:27 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 09 Aug 2011 08:18:27 -0700 Subject: Apparent JITC bug In-Reply-To: <4E4118DA.30306@fastmail.fm> References: <4E4118DA.30306@fastmail.fm> Message-ID: <4E414FC3.7090206@oracle.com> Dan, I was not able to reproduce the problem with your test but this problem looks like 5091921 bug which was fixed in jdk7. Could you, please, show how to reproduce the problem and version of java you are using (-version flag)? Regards, Vladimir Dan Hicks wrote: > This sequence fails on Linux JDK 1.6.0_21, and an unknown Java version > on OS X 10.6.8: > > |public class Prototype { > public static void main(String[] args) { > final int start = Integer.MAX_VALUE/2; > final int end = Integer.MAX_VALUE; > { > long b = 0; > for (int i = start; i < end; i++) { > b++; > } > System.out.println(b); > } > { > long b = 0; > for (int i = start; i < end; i++) { > b++; > } > System.out.println(b); > } > } > } > | > > The second loop terminates early, producing a different, random, > erroneous result when compared to the first. > > http://stackoverflow.com/questions/6995225/erroneous-for-loops-in-java > > I'm guessing the bug has something to do with trying to jump into a > just-JITed loop while executing. > > -- > Dan Hicks > It is an ironic habit of human beings to run faster when we have lost our way. --Rollo May > From David.Holmes at oracle.com Tue Aug 9 17:37:09 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 10 Aug 2011 10:37:09 +1000 Subject: Apparent JITC bug In-Reply-To: <4E414FC3.7090206@oracle.com> References: <4E4118DA.30306@fastmail.fm> <4E414FC3.7090206@oracle.com> Message-ID: <4E41D2B5.9020904@oracle.com> Yes this is 5091921. As Vladimir says fixed in JDK7. But not planned to be fixed in JDK6 David On 10/08/2011 1:18 AM, Vladimir Kozlov wrote: > Dan, > > I was not able to reproduce the problem with your test but this problem > looks like 5091921 bug which was fixed in jdk7. Could you, please, show how > to reproduce the problem and version of java you are using (-version flag)? > > Regards, > Vladimir > > Dan Hicks wrote: >> This sequence fails on Linux JDK 1.6.0_21, and an unknown Java version on >> OS X 10.6.8: >> >> |public class Prototype { >> public static void main(String[] args) { >> final int start = Integer.MAX_VALUE/2; >> final int end = Integer.MAX_VALUE; >> { >> long b = 0; >> for (int i = start; i < end; i++) { >> b++; >> } >> System.out.println(b); >> } >> { >> long b = 0; >> for (int i = start; i < end; i++) { >> b++; >> } >> System.out.println(b); >> } >> } >> } >> | >> >> The second loop terminates early, producing a different, random, erroneous >> result when compared to the first. >> >> http://stackoverflow.com/questions/6995225/erroneous-for-loops-in-java >> >> I'm guessing the bug has something to do with trying to jump into a >> just-JITed loop while executing. >> >> -- >> Dan Hicks >> It is an ironic habit of human beings to run faster when we have lost our >> way. --Rollo May >> From tom.rodriguez at oracle.com Tue Aug 9 19:04:44 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 9 Aug 2011 19:04:44 -0700 Subject: Merging BSDPort into HotSpot mainline In-Reply-To: <201108021718.17957.kurt@intricatesoftware.com> References: <201108021234.30179.kurt@intricatesoftware.com> <201108021718.17957.kurt@intricatesoftware.com> Message-ID: <881CAFF8-5E2E-45F2-8CEB-EA91C4874642@oracle.com> > >> src/cpu/x86/vm/c1_LIRAssembler_x86.cpp: >> src/cpu/x86/vm/interp_masm_x86_32.cpp: >> >> Why is the change of the cast needed? That idiom is used in many other places that haven't been modified. It's an odd little idiom that could be eliminated by fixing a limitation in the MacroAssembler where it emits larger assembly than it needs to. Mainly I'm just unclear why it was changed in some places and not others. > > On OpenBSD/i386 and I believe also OS/X/x86_32 intptr_t is typedef to long not int which leads to the following build errors: > > g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 -DPRODUCT -I. -I/home/truk/jdk/bsd-port/hotspot/src/share/vm/prims -I/home/truk/jdk/bsd-port/hotspot/src/share/vm -I/home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm -I/home/truk/jdk/bsd-port/hotspot/src/os_cpu/bsd_x86/vm -I/home/truk/jdk/bsd-port/hotspot/src/os/bsd/vm -I/home/truk/jdk/bsd-port/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"21.0-b17\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"truk\"" -DHOTSPOT_LIB_ARCH=\"i386\" -DJRE_RELEASE_VERSION="\"1.7.0-internal-truk_2011_08_02_14_13-b00\"" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DDEFAULT_LIBPATH="\"/usr/lib:/usr/X11R6/lib:/usr/local/lib\"" -DTARGET_OS_FAMILY_bsd -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_32 -DTARGET_OS_ARCH_bsd_x86 -DTARGET_OS_ARCH_MODEL_bsd_x86_32 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -pthread -fcheck-new -m32 -march=i586 -pipe -O3 -fno-strict-aliasing -DVM_LITTLE_ENDIAN -Werror -Wpointer-arith -Wconversion -Wsign-compare -c -MMD -MP -MF ../generated/dependencies/c1_LIRAssembler_x86.o.d -o c1_LIRAssembler_x86.o /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp > /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp: In member function 'int LIR_Assembler::emit_unwind_handler()': > /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp:483: error: call of overloaded 'movptr(Address, int32_t)' is ambiguous > /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2317: note: candidates are: void MacroAssembler::movptr(Address, intptr_t) > /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2319: note: void MacroAssembler::movptr(Address, RegisterImpl*) > /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp:484: error: call of overloaded 'movptr(Address, int32_t)' is ambiguous > /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2317: note: candidates are: void MacroAssembler::movptr(Address, intptr_t) > /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2319: note: void MacroAssembler::movptr(Address, RegisterImpl*) I looked at this again and realized that this was the only case of this idiom in 32 bit. All the others are in 64 bit which explains why only this one was needed but not the others. I think the history of it is that the MacroAssembler isn't doing a very good job of selecting shorter instruction formats when the value is declared intptr_t but the actual value fits in 32 or 8 bits. The change itself is ok. > + > +#if defined(__OpenBSD__) > + // Work-around OpenBSD's lack of $ORIGIN support by pre-loading libnet.so > + // ignore errors > + dll_build_name(buffer, sizeof(buffer), Arguments::get_dll_dir(), "net"); > + dll_load(buffer, ebuf, sizeof(ebuf)); > +#endif > > This one is due to OpenBSD's lack of $ORIGIN support in our runtime linker. I've been meaning to add support for it, but have been short on time. Clearly it is a hack but it is needed for OpenBSD until $ORIGIN is supported. Yes, this is the one I meant. Why is this hack in the JVM instead of the JDK? Aren't you likely to hit other problems than just this? > >> >> I see a full copy of elf.h in there as well which I doubt we can accept. It seems to be apple specfic but doesn't mac use MachO? >> > > This was brought in for Apple support. We need an Apple developer to remove it and find the places where the build is missing defines. I don't have an x86 OS/X box at the moment to do this work. I grabbed the patch and tried to build it on my mac. It immediately failed trying to build sa-jdi.jar since the standard Mac jdk doesn't have a separate tools.jar, which I guess is expected. The other problems I see are format mismatches in memprofiler.cpp and os.cpp that I think are fixed in the macosx-port repo with some more format changes. I assume that can be dealt with when those changes come in though. I made a patch that removes the usages of elf.h on Mac. I uploaded it as http://cr.openjdk.java.net/~never/elf. It compiles and builds on my Snow Leopard mac though I had to massage the build a little bit extra to deal with the previously mentioned format issues. tom > >> test/Makefile: >> >> What's the point of the JTREG_TESTDIRS change? > > Not sure. Greg can you comment on this one? > > Thank you for the review. > > Regards, > -Kurt From kurt at intricatesoftware.com Thu Aug 11 15:12:12 2011 From: kurt at intricatesoftware.com (Kurt Miller) Date: Thu, 11 Aug 2011 18:12:12 -0400 Subject: Merging BSDPort into HotSpot mainline In-Reply-To: <881CAFF8-5E2E-45F2-8CEB-EA91C4874642@oracle.com> References: <201108021234.30179.kurt@intricatesoftware.com> <201108021718.17957.kurt@intricatesoftware.com> <881CAFF8-5E2E-45F2-8CEB-EA91C4874642@oracle.com> Message-ID: <201108111812.12537.kurt@intricatesoftware.com> On Tuesday 09 August 2011 10:04:44 pm Tom Rodriguez wrote: > > > > >> src/cpu/x86/vm/c1_LIRAssembler_x86.cpp: > >> src/cpu/x86/vm/interp_masm_x86_32.cpp: > >> > >> Why is the change of the cast needed? That idiom is used in many other places that haven't been modified. It's an odd little idiom that could be eliminated by fixing a limitation in the MacroAssembler where it emits larger assembly than it needs to. Mainly I'm just unclear why it was changed in some places and not others. > > > > On OpenBSD/i386 and I believe also OS/X/x86_32 intptr_t is typedef to long not int which leads to the following build errors: > > > > g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 -DPRODUCT -I. -I/home/truk/jdk/bsd-port/hotspot/src/share/vm/prims -I/home/truk/jdk/bsd-port/hotspot/src/share/vm -I/home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm -I/home/truk/jdk/bsd-port/hotspot/src/os_cpu/bsd_x86/vm -I/home/truk/jdk/bsd-port/hotspot/src/os/bsd/vm -I/home/truk/jdk/bsd-port/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"21.0-b17\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"truk\"" -DHOTSPOT_LIB_ARCH=\"i386\" -DJRE_RELEASE_VERSION="\"1.7.0-internal-truk_2011_08_02_14_13-b00\"" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DDEFAULT_LIBPATH="\"/usr/lib:/usr/X11R6/lib:/usr/local/lib\"" -DTARGET_OS_FAMILY_bsd -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_32 -DTARGET_OS_ARCH_bsd_x86 -DTARGET_OS_ARCH_MODEL_bsd_x86_32 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -pthread -fcheck-new -m32 -march=i586 -pipe -O3 -fno-strict-aliasing -DVM_LITTLE_ENDIAN -Werror -Wpointer-arith -Wconversion -Wsign-compare -c -MMD -MP -MF ../generated/dependencies/c1_LIRAssembler_x86.o.d -o c1_LIRAssembler_x86.o /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp > > /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp: In member function 'int LIR_Assembler::emit_unwind_handler()': > > /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp:483: error: call of overloaded 'movptr(Address, int32_t)' is ambiguous > > /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2317: note: candidates are: void MacroAssembler::movptr(Address, intptr_t) > > /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2319: note: void MacroAssembler::movptr(Address, RegisterImpl*) > > /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp:484: error: call of overloaded 'movptr(Address, int32_t)' is ambiguous > > /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2317: note: candidates are: void MacroAssembler::movptr(Address, intptr_t) > > /home/truk/jdk/bsd-port/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2319: note: void MacroAssembler::movptr(Address, RegisterImpl*) > > I looked at this again and realized that this was the only case of this idiom in 32 bit. All the others are in 64 bit which explains why only this one was needed but not the others. I think the history of it is that the MacroAssembler isn't doing a very good job of selecting shorter instruction formats when the value is declared intptr_t but the actual value fits in 32 or 8 bits. The change itself is ok. Great. > > + > > +#if defined(__OpenBSD__) > > + // Work-around OpenBSD's lack of $ORIGIN support by pre-loading libnet.so > > + // ignore errors > > + dll_build_name(buffer, sizeof(buffer), Arguments::get_dll_dir(), "net"); > > + dll_load(buffer, ebuf, sizeof(ebuf)); > > +#endif > > > > This one is due to OpenBSD's lack of $ORIGIN support in our runtime linker. I've been meaning to add support for it, but have been short on time. Clearly it is a hack but it is needed for OpenBSD until $ORIGIN is supported. > > Yes, this is the one I meant. Why is this hack in the JVM instead of the JDK? Aren't you likely to hit other problems than just this? Indeed it is not a complete work-around. For example using JDWP requires setting LD_LIBRARY_PATH. I'm ok with this hunk not making it into hotspot. It will provide me the incentive to write $ORIGIN support for OpenBSD's runtime linker. :-) > > > >> > >> I see a full copy of elf.h in there as well which I doubt we can accept. It seems to be apple specfic but doesn't mac use MachO? > >> > > > > This was brought in for Apple support. We need an Apple developer to remove it and find the places where the build is missing defines. I don't have an x86 OS/X box at the moment to do this work. > > I grabbed the patch and tried to build it on my mac. It immediately failed trying to build sa-jdi.jar since the standard Mac jdk doesn't have a separate tools.jar, which I guess is expected. The other problems I see are format mismatches in memprofiler.cpp and os.cpp that I think are fixed in the macosx-port repo with some more format changes. I assume that can be dealt with when those changes come in though. > > I made a patch that removes the usages of elf.h on Mac. I uploaded it as http://cr.openjdk.java.net/~never/elf. It compiles and builds on my Snow Leopard mac though I had to massage the build a little bit extra to deal with the previously mentioned format issues. Great. Thank you. What is the next step to move this forward? Regards, -Kurt From y.s.ramakrishna at oracle.com Tue Aug 16 18:36:05 2011 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Wed, 17 Aug 2011 01:36:05 +0000 Subject: hg: hsx/hotspot-main/hotspot: 9 new changesets Message-ID: <20110817013621.5AA4E47C38@hg.openjdk.java.net> Changeset: 14a2fd14c0db Author: johnc Date: 2011-08-01 10:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/14a2fd14c0db 7068240: G1: Long "parallel other time" and "ext root scanning" when running specific benchmark Summary: In root processing, move the scanning of the reference processor's discovered lists to before RSet updating and scanning. When scanning the reference processor's discovered lists, use a buffering closure so that the time spent copying any reference object is correctly attributed. Also removed a couple of unused and irrelevant timers. Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: 6aa4feb8a366 Author: johnc Date: 2011-08-02 12:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6aa4feb8a366 7069863: G1: SIGSEGV running SPECjbb2011 and -UseBiasedLocking Summary: Align the reserved size of the heap and perm to the heap region size to get a preferred heap base that is aligned to the region size, and call the correct heap reservation constructor. Also add a check in the heap reservation code that the reserved space starts at the requested address (if any). Reviewed-by: kvn, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/virtualspace.cpp Changeset: a20e6e447d3d Author: iveresov Date: 2011-08-05 16:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a20e6e447d3d 7060842: UseNUMA crash with UseHugreTLBFS running SPECjvm2008 Summary: Use mmap() instead of madvise(MADV_DONTNEED) to uncommit pages Reviewed-by: ysr ! src/os/linux/vm/os_linux.cpp Changeset: 7c2653aefc46 Author: iveresov Date: 2011-08-05 16:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7c2653aefc46 7060836: RHEL 5.5 and 5.6 should support UseNUMA Summary: Add a wrapper for sched_getcpu() for systems where libc lacks it Reviewed-by: ysr Contributed-by: Andrew John Hughes ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp Changeset: 41e6ee74f879 Author: kevinw Date: 2011-08-02 14:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/41e6ee74f879 7072527: CMS: JMM GC counters overcount in some cases Summary: Avoid overcounting when CMS has concurrent mode failure. Reviewed-by: ysr Contributed-by: rednaxelafx at gmail.com ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp + test/gc/7072527/TestFullGCCount.java Changeset: e9db47a083cc Author: kevinw Date: 2011-08-11 14:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e9db47a083cc Merge Changeset: 87e40b34bc2b Author: johnc Date: 2011-08-11 11:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/87e40b34bc2b 7074579: G1: JVM crash with JDK7 running ATG CRMDemo Fusion App Summary: Handlize MemoryUsage klass oop in createGCInfo routine Reviewed-by: tonyp, fparain, ysr, jcoomes ! src/share/vm/services/gcNotifier.cpp Changeset: f44782f04dd4 Author: tonyp Date: 2011-08-12 11:31 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f44782f04dd4 7039627: G1: avoid BOT updates for survivor allocations and dirty survivor regions incrementally Summary: Refactor the allocation code during GC to use the G1AllocRegion abstraction. Use separate subclasses of G1AllocRegion for survivor and old regions. Avoid BOT updates and dirty survivor cards incrementally for the former. Reviewed-by: brutisso, johnc, ysr ! src/share/vm/gc_implementation/g1/g1AllocRegion.cpp ! src/share/vm/gc_implementation/g1/g1AllocRegion.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp Changeset: 76b1a9420e3d Author: ysr Date: 2011-08-16 08:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/76b1a9420e3d Merge From gary.collins at sun.com Thu Aug 18 09:52:19 2011 From: gary.collins at sun.com (gary.collins at sun.com) Date: Thu, 18 Aug 2011 16:52:19 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20110818165233.DD3AA47D0E@hg.openjdk.java.net> Changeset: 46cb9a7b8b01 Author: dsamersoff Date: 2011-08-10 15:04 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/46cb9a7b8b01 7073913: The fix for 7017193 causes segfaults Summary: Buffer overflow in os::get_line_chars Reviewed-by: coleenp, dholmes, dcubed Contributed-by: aph at redhat.com ! src/share/vm/runtime/os.cpp Changeset: b1cbb0907b36 Author: zgu Date: 2011-04-15 09:34 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b1cbb0907b36 7016797: Hotspot: securely/restrictive load dlls and new API for loading system dlls Summary: Created Windows Dll wrapped to handle jdk6 and jdk7 platform requirements, also provided more restictive Dll search orders for Windows system Dlls. Reviewed-by: acorn, dcubed, ohair, alanb ! make/windows/makefiles/compile.make ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/jvm_windows.h ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp Changeset: 279ef1916773 Author: zgu Date: 2011-07-12 21:13 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/279ef1916773 7065535: Mistyped function name that disabled UseLargePages on Windows Summary: Missing suffix "A" of Windows API LookupPrivilegeValue failed finding function pointer, caused VM to disable UseLargePages option Reviewed-by: coleenp, phh ! src/os/windows/vm/os_windows.cpp Changeset: a68e11dceb83 Author: zgu Date: 2011-08-16 09:18 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a68e11dceb83 Merge Changeset: 00ed4ccfe642 Author: collins Date: 2011-08-17 07:05 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/00ed4ccfe642 Merge From tom.rodriguez at oracle.com Fri Aug 19 09:58:50 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 19 Aug 2011 09:58:50 -0700 Subject: Merging BSDPort into HotSpot mainline In-Reply-To: <201108111812.12537.kurt@intricatesoftware.com> References: <201108021234.30179.kurt@intricatesoftware.com> <201108021718.17957.kurt@intricatesoftware.com> <881CAFF8-5E2E-45F2-8CEB-EA91C4874642@oracle.com> <201108111812.12537.kurt@intricatesoftware.com> Message-ID: >>> + >>> +#if defined(__OpenBSD__) >>> + // Work-around OpenBSD's lack of $ORIGIN support by pre-loading libnet.so >>> + // ignore errors >>> + dll_build_name(buffer, sizeof(buffer), Arguments::get_dll_dir(), "net"); >>> + dll_load(buffer, ebuf, sizeof(ebuf)); >>> +#endif >>> >>> This one is due to OpenBSD's lack of $ORIGIN support in our runtime linker. I've been meaning to add support for it, but have been short on time. Clearly it is a hack but it is needed for OpenBSD until $ORIGIN is supported. >> >> Yes, this is the one I meant. Why is this hack in the JVM instead of the JDK? Aren't you likely to hit other problems than just this? > > Indeed it is not a complete work-around. For example using JDWP requires setting LD_LIBRARY_PATH. I'm ok with this hunk not making it into hotspot. It will provide me the incentive to write $ORIGIN support for OpenBSD's runtime linker. :-) I would prefer that, though we could leave it in for now if that would be easier for you. Just so we have a plan for it's removal. > >>> >>>> >>>> I see a full copy of elf.h in there as well which I doubt we can accept. It seems to be apple specfic but doesn't mac use MachO? >>>> >>> >>> This was brought in for Apple support. We need an Apple developer to remove it and find the places where the build is missing defines. I don't have an x86 OS/X box at the moment to do this work. >> >> I grabbed the patch and tried to build it on my mac. It immediately failed trying to build sa-jdi.jar since the standard Mac jdk doesn't have a separate tools.jar, which I guess is expected. The other problems I see are format mismatches in memprofiler.cpp and os.cpp that I think are fixed in the macosx-port repo with some more format changes. I assume that can be dealt with when those changes come in though. >> >> I made a patch that removes the usages of elf.h on Mac. I uploaded it as http://cr.openjdk.java.net/~never/elf. It compiles and builds on my Snow Leopard mac though I had to massage the build a little bit extra to deal with the previously mentioned format issues. > > Great. Thank you. > > What is the next step to move this forward? Sorry this is taking so long. I'll put together another webrev and test it that it builds and works as expected on our existing patforms and send it out early next week. I may go ahead and incorporate a few formatting things from the Mac OS X repo so those kinds of fixes can all be done at once. Official support for BSD/Mac OS X in the main repos is a bit further out but at least we can get everyone onto the pretty much the same repo. Since many of the JSR 292 users are on Mac this will make me much happier. Thanks for your patience. tom > > Regards, > -Kurt From kurt at intricatesoftware.com Fri Aug 19 13:31:25 2011 From: kurt at intricatesoftware.com (Kurt Miller) Date: Fri, 19 Aug 2011 16:31:25 -0400 Subject: Merging BSDPort into HotSpot mainline In-Reply-To: References: <201108021234.30179.kurt@intricatesoftware.com> <201108111812.12537.kurt@intricatesoftware.com> Message-ID: <201108191631.25828.kurt@intricatesoftware.com> On Friday 19 August 2011 12:58:50 pm Tom Rodriguez wrote: > >>> + > >>> +#if defined(__OpenBSD__) > >>> + // Work-around OpenBSD's lack of $ORIGIN support by pre-loading libnet.so > >>> + // ignore errors > >>> + dll_build_name(buffer, sizeof(buffer), Arguments::get_dll_dir(), "net"); > >>> + dll_load(buffer, ebuf, sizeof(ebuf)); > >>> +#endif > >>> > >>> This one is due to OpenBSD's lack of $ORIGIN support in our runtime linker. I've been meaning to add support for it, but have been short on time. Clearly it is a hack but it is needed for OpenBSD until $ORIGIN is supported. > >> > >> Yes, this is the one I meant. Why is this hack in the JVM instead of the JDK? Aren't you likely to hit other problems than just this? > > > > Indeed it is not a complete work-around. For example using JDWP requires setting LD_LIBRARY_PATH. I'm ok with this hunk not making it into hotspot. It will provide me the incentive to write $ORIGIN support for OpenBSD's runtime linker. :-) > > I would prefer that, though we could leave it in for now if that would be easier for you. Just so we have a plan for it's removal. Either way is fine with me. > > > > >>> > >>>> > >>>> I see a full copy of elf.h in there as well which I doubt we can accept. It seems to be apple specfic but doesn't mac use MachO? > >>>> > >>> > >>> This was brought in for Apple support. We need an Apple developer to remove it and find the places where the build is missing defines. I don't have an x86 OS/X box at the moment to do this work. > >> > >> I grabbed the patch and tried to build it on my mac. It immediately failed trying to build sa-jdi.jar since the standard Mac jdk doesn't have a separate tools.jar, which I guess is expected. The other problems I see are format mismatches in memprofiler.cpp and os.cpp that I think are fixed in the macosx-port repo with some more format changes. I assume that can be dealt with when those changes come in though. > >> > >> I made a patch that removes the usages of elf.h on Mac. I uploaded it as http://cr.openjdk.java.net/~never/elf. It compiles and builds on my Snow Leopard mac though I had to massage the build a little bit extra to deal with the previously mentioned format issues. > > > > Great. Thank you. > > > > What is the next step to move this forward? > > Sorry this is taking so long. I'll put together another webrev and test it that it builds and works as expected on our existing patforms and send it out early next week. I may go ahead and incorporate a few formatting things from the Mac OS X repo so those kinds of fixes can all be done at once. > > Official support for BSD/Mac OS X in the main repos is a bit further out but at least we can get everyone onto the pretty much the same repo. Since many of the JSR 292 users are on Mac this will make me much happier. > > Thanks for your patience. Thank you for moving it forward. Regards, -Kurt From vladimir.kozlov at oracle.com Fri Aug 19 13:39:39 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 19 Aug 2011 20:39:39 +0000 Subject: hg: hsx/hotspot-main/hotspot: 22 new changesets Message-ID: <20110819204021.7CF2147E4E@hg.openjdk.java.net> Changeset: 43f9d800f276 Author: iveresov Date: 2011-07-20 18:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/43f9d800f276 7066339: Tiered: policy should make consistent decisions about osr levels Summary: Added feedback disabling flag to common(), fixed handling of TieredStopAtLevel. Reviewed-by: kvn, never ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.hpp Changeset: 6a991dcb52bb Author: never Date: 2011-07-21 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6a991dcb52bb 7012081: JSR 292: SA-JDI can't read MH/MT/Indy ConstantPool entries Reviewed-by: kvn, twisti, jrose ! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecode.java - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastAAccess0.java - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastIAccess0.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeStream.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWideable.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWithCPIndex.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecodes.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCache.java ! agent/src/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/TypeArray.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java ! src/share/vm/oops/generateOopMap.cpp Changeset: 3d42f82cd811 Author: kvn Date: 2011-07-21 11:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3d42f82cd811 7063628: Use cbcond on T4 Summary: Add new short branch instruction to Hotspot sparc assembler. Reviewed-by: never, twisti, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/runtime/globals.hpp Changeset: 4e761e7e6e12 Author: kvn Date: 2011-07-26 19:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4e761e7e6e12 7070134: Hotspot crashes with sigsegv from PorterStemmer Summary: Do not move data nodes which are attached to a predicate test to a dominating test. Reviewed-by: never ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp + test/compiler/7070134/Stemmer.java + test/compiler/7070134/Test7070134.sh + test/compiler/7070134/words Changeset: 0f34fdee809e Author: never Date: 2011-07-27 15:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0f34fdee809e 7071427: AdapterFingerPrint can hold 8 entries per int Reviewed-by: kvn ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: c7b60b601eb4 Author: kvn Date: 2011-07-27 17:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c7b60b601eb4 7069452: Cleanup NodeFlags Summary: Remove flags which duplicate information in Node::NodeClasses. Reviewed-by: never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/mulnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp Changeset: d17bd0b18663 Author: twisti Date: 2011-07-28 02:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d17bd0b18663 7066143: JSR 292: Zero support after regressions from 7009923 and 7009309 Reviewed-by: jrose, twisti Contributed-by: Xerxes Ranby ! src/cpu/zero/vm/stack_zero.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ce3e1d4dc416 Author: never Date: 2011-07-28 13:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ce3e1d4dc416 7060619: C1 should respect inline and dontinline directives from CompilerOracle Reviewed-by: kvn, iveresov ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: c96c3eb1efae Author: kvn Date: 2011-07-29 09:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c96c3eb1efae 7068051: SIGSEGV in PhaseIdealLoop::build_loop_late_post Summary: Removed predicate cloning from loop peeling optimization and from split fall-in paths. Reviewed-by: never ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/phaseX.hpp Changeset: 4aa5974a06dd Author: kvn Date: 2011-08-06 08:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4aa5974a06dd 7075559: JPRT windows_x64 build failure Summary: use SA_CLASSDIR variable instead of dirsctory saclasses. Reviewed-by: kamg, dcubed ! make/linux/makefiles/defs.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/saproc.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/sa.make Changeset: a3142bdb6707 Author: twisti Date: 2011-08-08 05:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a3142bdb6707 7071823: Zero: zero/shark doesn't build after b147-fcs Reviewed-by: gbenson, twisti Contributed-by: Chris Phillips ! src/cpu/zero/vm/frame_zero.cpp + src/cpu/zero/vm/methodHandles_zero.hpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/share/vm/shark/sharkContext.hpp Changeset: a19c671188cb Author: never Date: 2011-08-08 13:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a19c671188cb 7075623: 6990212 broke raiseException in 64 bit Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp Changeset: f1c12354c3f7 Author: roland Date: 2011-08-02 18:36 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f1c12354c3f7 7074017: Introduce MemBarAcquireLock/MemBarReleaseLock nodes for monitor enter/exit code paths Summary: replace MemBarAcquire/MemBarRelease nodes on the monitor enter/exit code paths with new MemBarAcquireLock/MemBarReleaseLock nodes Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp Changeset: 6987871cfb9b Author: kvn Date: 2011-08-10 14:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6987871cfb9b 7077439: Possible reference through NULL in loopPredicate.cpp:726 Summary: Use cl->is_valid_counted_loop() check. Reviewed-by: never ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/superword.cpp Changeset: 95134e034042 Author: kvn Date: 2011-08-11 12:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/95134e034042 7063629: use cbcond in C2 generated code on T4 Summary: Use new short branch instruction in C2 generated code. Reviewed-by: never ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/linux_x86/vm/linux_x86_32.ad ! src/os_cpu/linux_x86/vm/linux_x86_64.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_32.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp Changeset: fdb992d83a87 Author: twisti Date: 2011-08-16 04:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fdb992d83a87 7071653: JSR 292: call site change notification should be pushed not pulled Reviewed-by: kvn, never, bdelsart ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciCallSite.cpp ! src/share/vm/ci/ciCallSite.hpp ! src/share/vm/ci/ciField.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/dependencies.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse3.cpp Changeset: 11211f7cb5a0 Author: kvn Date: 2011-08-16 11:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/11211f7cb5a0 7079317: Incorrect branch's destination block in PrintoOptoAssembly output Summary: save/restore label and block in scratch_emit_size() Reviewed-by: never ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp Changeset: 1af104d6cf99 Author: kvn Date: 2011-08-16 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1af104d6cf99 7079329: Adjust allocation prefetching for T4 Summary: on T4 2 BIS instructions should be issued to prefetch 64 bytes Reviewed-by: iveresov, phh, twisti ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp Changeset: 381bf869f784 Author: twisti Date: 2011-08-17 05:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/381bf869f784 7079626: x64 emits unnecessary REX prefix Reviewed-by: kvn, iveresov, never ! src/cpu/x86/vm/assembler_x86.cpp Changeset: bd87c0dcaba5 Author: twisti Date: 2011-08-17 11:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bd87c0dcaba5 7079769: JSR 292: incorrect size() for CallStaticJavaHandle on sparc Reviewed-by: never, kvn ! src/cpu/sparc/vm/sparc.ad Changeset: 739a9abbbd4b Author: kvn Date: 2011-08-18 11:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/739a9abbbd4b 7080431: VM asserts if specified size(x) in .ad is larger than emitted size Summary: Move code from finalize_offsets_and_shorten() to fill_buffer() to restore previous behavior. Reviewed-by: never ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/output.cpp Changeset: de147f62e695 Author: kvn Date: 2011-08-19 08:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/de147f62e695 Merge - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastAAccess0.java - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastIAccess0.java From john.coomes at oracle.com Fri Aug 19 16:41:39 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 19 Aug 2011 23:41:39 +0000 Subject: hg: hsx/hotspot-main/hotspot: 8 new changesets Message-ID: <20110819234154.DCE4747E70@hg.openjdk.java.net> Changeset: 24cee90e9453 Author: jcoomes Date: 2011-08-17 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/24cee90e9453 6791672: enable 1G and larger pages on solaris Reviewed-by: ysr, iveresov, johnc ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp Changeset: 3be7439273c5 Author: katleman Date: 2011-05-25 13:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3be7439273c5 7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles Reviewed-by: ohair, trims ! agent/src/share/classes/sun/jvm/hotspot/runtime/ServiceThread.java ! make/linux/README ! make/windows/projectfiles/kernel/Makefile ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.s ! src/share/tools/hsdis/README ! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/utilities/yieldingWorkgroup.cpp Changeset: 8b135e6129d6 Author: jeff Date: 2011-05-27 15:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8b135e6129d6 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 52e4ba46751f Author: kamg Date: 2011-04-12 16:42 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/52e4ba46751f 7020373: JSR rewriting can overflow memory address size variables Summary: Abort if incoming classfile's parameters would cause overflows Reviewed-by: coleenp, dcubed, never ! src/share/vm/oops/generateOopMap.cpp + test/runtime/7020373/Test7020373.sh Changeset: bca686989d4b Author: asaha Date: 2011-06-15 14:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bca686989d4b 7055247: Ignore test of # 7020373 Reviewed-by: dcubed ! test/runtime/7020373/Test7020373.sh Changeset: 337ffef74c37 Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/337ffef74c37 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: 9f12ede5571a Author: jcoomes Date: 2011-08-19 14:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9f12ede5571a Merge ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/runtime/os.cpp Changeset: 7c29742c41b4 Author: jcoomes Date: 2011-08-19 14:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7c29742c41b4 7081251: bump the hs22 build number to 02 Reviewed-by: johnc ! make/hotspot_version From john.coomes at oracle.com Fri Aug 19 17:56:08 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 20 Aug 2011 00:56:08 +0000 Subject: hg: hsx/hsx22/hotspot: 54 new changesets Message-ID: <20110820005747.1DA4547E80@hg.openjdk.java.net> Changeset: 20cac004a4f9 Author: dsamersoff Date: 2011-06-09 01:06 +0400 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/20cac004a4f9 Merge Changeset: 1744e37e032b Author: dsamersoff Date: 2011-06-18 13:32 +0400 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/1744e37e032b Merge Changeset: d425748f2203 Author: dcubed Date: 2011-06-23 20:31 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/d425748f2203 7043987: 3/3 JVMTI FollowReferences is slow Summary: VM_HeapWalkOperation::doit() should only reset mark bits when necessary. Reviewed-by: dsamersoff, ysr, dholmes, dcubed Contributed-by: ashok.srinivasa.murthy at oracle.com ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 88dce6a60ac8 Author: dcubed Date: 2011-06-29 20:28 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/88dce6a60ac8 6951623: 3/3 possible performance problems in FollowReferences() and GetObjectsWithTags() Summary: Call collect_stack_roots() before collect_simple_roots() as an optimization. Reviewed-by: ysr, dsamersoff, dcubed Contributed-by: ashok.srinivasa.murthy at oracle.com ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 109d1d265924 Author: dholmes Date: 2011-07-02 04:17 -0400 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/109d1d265924 7052988: JPRT embedded builds don't set MINIMIZE_RAM_USAGE Reviewed-by: kamg, dsamersoff ! make/jprt.gmk Changeset: 5447b2c582ad Author: coleenp Date: 2011-07-07 22:34 -0400 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/5447b2c582ad Merge Changeset: bcc6475bc68f Author: coleenp Date: 2011-07-16 22:21 -0400 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/bcc6475bc68f Merge Changeset: 0b80db433fcb Author: dholmes Date: 2011-07-22 00:29 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/0b80db433fcb 7046490: Preallocated OOME objects should obey Throwable stack trace protocol Summary: Update the OOME stacktrace to contain Throwable.UNASSIGNED_STACK when the backtrace is filled in Reviewed-by: mchung, phh ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp Changeset: 8107273fd204 Author: coleenp Date: 2011-07-23 10:42 -0400 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/8107273fd204 Merge Changeset: ca1f1753c866 Author: andrew Date: 2011-07-28 14:10 -0400 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/ca1f1753c866 7072341: enable hotspot builds on Linux 3.0 Summary: Add "3" to list of allowable versions Reviewed-by: kamg, chrisphi ! make/linux/Makefile Changeset: 14a2fd14c0db Author: johnc Date: 2011-08-01 10:04 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/14a2fd14c0db 7068240: G1: Long "parallel other time" and "ext root scanning" when running specific benchmark Summary: In root processing, move the scanning of the reference processor's discovered lists to before RSet updating and scanning. When scanning the reference processor's discovered lists, use a buffering closure so that the time spent copying any reference object is correctly attributed. Also removed a couple of unused and irrelevant timers. Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: 6aa4feb8a366 Author: johnc Date: 2011-08-02 12:13 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/6aa4feb8a366 7069863: G1: SIGSEGV running SPECjbb2011 and -UseBiasedLocking Summary: Align the reserved size of the heap and perm to the heap region size to get a preferred heap base that is aligned to the region size, and call the correct heap reservation constructor. Also add a check in the heap reservation code that the reserved space starts at the requested address (if any). Reviewed-by: kvn, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/virtualspace.cpp Changeset: a20e6e447d3d Author: iveresov Date: 2011-08-05 16:44 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/a20e6e447d3d 7060842: UseNUMA crash with UseHugreTLBFS running SPECjvm2008 Summary: Use mmap() instead of madvise(MADV_DONTNEED) to uncommit pages Reviewed-by: ysr ! src/os/linux/vm/os_linux.cpp Changeset: 7c2653aefc46 Author: iveresov Date: 2011-08-05 16:50 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/7c2653aefc46 7060836: RHEL 5.5 and 5.6 should support UseNUMA Summary: Add a wrapper for sched_getcpu() for systems where libc lacks it Reviewed-by: ysr Contributed-by: Andrew John Hughes ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp Changeset: 41e6ee74f879 Author: kevinw Date: 2011-08-02 14:37 +0100 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/41e6ee74f879 7072527: CMS: JMM GC counters overcount in some cases Summary: Avoid overcounting when CMS has concurrent mode failure. Reviewed-by: ysr Contributed-by: rednaxelafx at gmail.com ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp + test/gc/7072527/TestFullGCCount.java Changeset: e9db47a083cc Author: kevinw Date: 2011-08-11 14:58 +0100 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/e9db47a083cc Merge Changeset: 87e40b34bc2b Author: johnc Date: 2011-08-11 11:36 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/87e40b34bc2b 7074579: G1: JVM crash with JDK7 running ATG CRMDemo Fusion App Summary: Handlize MemoryUsage klass oop in createGCInfo routine Reviewed-by: tonyp, fparain, ysr, jcoomes ! src/share/vm/services/gcNotifier.cpp Changeset: f44782f04dd4 Author: tonyp Date: 2011-08-12 11:31 -0400 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/f44782f04dd4 7039627: G1: avoid BOT updates for survivor allocations and dirty survivor regions incrementally Summary: Refactor the allocation code during GC to use the G1AllocRegion abstraction. Use separate subclasses of G1AllocRegion for survivor and old regions. Avoid BOT updates and dirty survivor cards incrementally for the former. Reviewed-by: brutisso, johnc, ysr ! src/share/vm/gc_implementation/g1/g1AllocRegion.cpp ! src/share/vm/gc_implementation/g1/g1AllocRegion.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp Changeset: 76b1a9420e3d Author: ysr Date: 2011-08-16 08:02 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/76b1a9420e3d Merge Changeset: 46cb9a7b8b01 Author: dsamersoff Date: 2011-08-10 15:04 +0400 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/46cb9a7b8b01 7073913: The fix for 7017193 causes segfaults Summary: Buffer overflow in os::get_line_chars Reviewed-by: coleenp, dholmes, dcubed Contributed-by: aph at redhat.com ! src/share/vm/runtime/os.cpp Changeset: b1cbb0907b36 Author: zgu Date: 2011-04-15 09:34 -0400 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/b1cbb0907b36 7016797: Hotspot: securely/restrictive load dlls and new API for loading system dlls Summary: Created Windows Dll wrapped to handle jdk6 and jdk7 platform requirements, also provided more restictive Dll search orders for Windows system Dlls. Reviewed-by: acorn, dcubed, ohair, alanb ! make/windows/makefiles/compile.make ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/jvm_windows.h ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp Changeset: 279ef1916773 Author: zgu Date: 2011-07-12 21:13 -0400 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/279ef1916773 7065535: Mistyped function name that disabled UseLargePages on Windows Summary: Missing suffix "A" of Windows API LookupPrivilegeValue failed finding function pointer, caused VM to disable UseLargePages option Reviewed-by: coleenp, phh ! src/os/windows/vm/os_windows.cpp Changeset: a68e11dceb83 Author: zgu Date: 2011-08-16 09:18 -0400 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/a68e11dceb83 Merge Changeset: 00ed4ccfe642 Author: collins Date: 2011-08-17 07:05 -0400 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/00ed4ccfe642 Merge Changeset: 43f9d800f276 Author: iveresov Date: 2011-07-20 18:04 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/43f9d800f276 7066339: Tiered: policy should make consistent decisions about osr levels Summary: Added feedback disabling flag to common(), fixed handling of TieredStopAtLevel. Reviewed-by: kvn, never ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.hpp Changeset: 6a991dcb52bb Author: never Date: 2011-07-21 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/6a991dcb52bb 7012081: JSR 292: SA-JDI can't read MH/MT/Indy ConstantPool entries Reviewed-by: kvn, twisti, jrose ! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecode.java - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastAAccess0.java - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastIAccess0.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeStream.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWideable.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWithCPIndex.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecodes.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCache.java ! agent/src/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/TypeArray.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java ! src/share/vm/oops/generateOopMap.cpp Changeset: 3d42f82cd811 Author: kvn Date: 2011-07-21 11:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/3d42f82cd811 7063628: Use cbcond on T4 Summary: Add new short branch instruction to Hotspot sparc assembler. Reviewed-by: never, twisti, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/runtime/globals.hpp Changeset: 4e761e7e6e12 Author: kvn Date: 2011-07-26 19:35 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/4e761e7e6e12 7070134: Hotspot crashes with sigsegv from PorterStemmer Summary: Do not move data nodes which are attached to a predicate test to a dominating test. Reviewed-by: never ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp + test/compiler/7070134/Stemmer.java + test/compiler/7070134/Test7070134.sh + test/compiler/7070134/words Changeset: 0f34fdee809e Author: never Date: 2011-07-27 15:06 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/0f34fdee809e 7071427: AdapterFingerPrint can hold 8 entries per int Reviewed-by: kvn ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: c7b60b601eb4 Author: kvn Date: 2011-07-27 17:28 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/c7b60b601eb4 7069452: Cleanup NodeFlags Summary: Remove flags which duplicate information in Node::NodeClasses. Reviewed-by: never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/mulnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp Changeset: d17bd0b18663 Author: twisti Date: 2011-07-28 02:14 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/d17bd0b18663 7066143: JSR 292: Zero support after regressions from 7009923 and 7009309 Reviewed-by: jrose, twisti Contributed-by: Xerxes Ranby ! src/cpu/zero/vm/stack_zero.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ce3e1d4dc416 Author: never Date: 2011-07-28 13:03 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/ce3e1d4dc416 7060619: C1 should respect inline and dontinline directives from CompilerOracle Reviewed-by: kvn, iveresov ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: c96c3eb1efae Author: kvn Date: 2011-07-29 09:16 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/c96c3eb1efae 7068051: SIGSEGV in PhaseIdealLoop::build_loop_late_post Summary: Removed predicate cloning from loop peeling optimization and from split fall-in paths. Reviewed-by: never ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/phaseX.hpp Changeset: 4aa5974a06dd Author: kvn Date: 2011-08-06 08:28 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/4aa5974a06dd 7075559: JPRT windows_x64 build failure Summary: use SA_CLASSDIR variable instead of dirsctory saclasses. Reviewed-by: kamg, dcubed ! make/linux/makefiles/defs.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/saproc.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/sa.make Changeset: a3142bdb6707 Author: twisti Date: 2011-08-08 05:49 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/a3142bdb6707 7071823: Zero: zero/shark doesn't build after b147-fcs Reviewed-by: gbenson, twisti Contributed-by: Chris Phillips ! src/cpu/zero/vm/frame_zero.cpp + src/cpu/zero/vm/methodHandles_zero.hpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/share/vm/shark/sharkContext.hpp Changeset: a19c671188cb Author: never Date: 2011-08-08 13:19 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/a19c671188cb 7075623: 6990212 broke raiseException in 64 bit Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp Changeset: f1c12354c3f7 Author: roland Date: 2011-08-02 18:36 +0200 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/f1c12354c3f7 7074017: Introduce MemBarAcquireLock/MemBarReleaseLock nodes for monitor enter/exit code paths Summary: replace MemBarAcquire/MemBarRelease nodes on the monitor enter/exit code paths with new MemBarAcquireLock/MemBarReleaseLock nodes Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp Changeset: 6987871cfb9b Author: kvn Date: 2011-08-10 14:06 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/6987871cfb9b 7077439: Possible reference through NULL in loopPredicate.cpp:726 Summary: Use cl->is_valid_counted_loop() check. Reviewed-by: never ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/superword.cpp Changeset: 95134e034042 Author: kvn Date: 2011-08-11 12:08 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/95134e034042 7063629: use cbcond in C2 generated code on T4 Summary: Use new short branch instruction in C2 generated code. Reviewed-by: never ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/linux_x86/vm/linux_x86_32.ad ! src/os_cpu/linux_x86/vm/linux_x86_64.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_32.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp Changeset: fdb992d83a87 Author: twisti Date: 2011-08-16 04:14 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/fdb992d83a87 7071653: JSR 292: call site change notification should be pushed not pulled Reviewed-by: kvn, never, bdelsart ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciCallSite.cpp ! src/share/vm/ci/ciCallSite.hpp ! src/share/vm/ci/ciField.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/dependencies.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse3.cpp Changeset: 11211f7cb5a0 Author: kvn Date: 2011-08-16 11:53 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/11211f7cb5a0 7079317: Incorrect branch's destination block in PrintoOptoAssembly output Summary: save/restore label and block in scratch_emit_size() Reviewed-by: never ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp Changeset: 1af104d6cf99 Author: kvn Date: 2011-08-16 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/1af104d6cf99 7079329: Adjust allocation prefetching for T4 Summary: on T4 2 BIS instructions should be issued to prefetch 64 bytes Reviewed-by: iveresov, phh, twisti ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp Changeset: 381bf869f784 Author: twisti Date: 2011-08-17 05:14 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/381bf869f784 7079626: x64 emits unnecessary REX prefix Reviewed-by: kvn, iveresov, never ! src/cpu/x86/vm/assembler_x86.cpp Changeset: bd87c0dcaba5 Author: twisti Date: 2011-08-17 11:52 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/bd87c0dcaba5 7079769: JSR 292: incorrect size() for CallStaticJavaHandle on sparc Reviewed-by: never, kvn ! src/cpu/sparc/vm/sparc.ad Changeset: 739a9abbbd4b Author: kvn Date: 2011-08-18 11:49 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/739a9abbbd4b 7080431: VM asserts if specified size(x) in .ad is larger than emitted size Summary: Move code from finalize_offsets_and_shorten() to fill_buffer() to restore previous behavior. Reviewed-by: never ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/output.cpp Changeset: de147f62e695 Author: kvn Date: 2011-08-19 08:55 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/de147f62e695 Merge - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastAAccess0.java - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastIAccess0.java Changeset: 24cee90e9453 Author: jcoomes Date: 2011-08-17 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/24cee90e9453 6791672: enable 1G and larger pages on solaris Reviewed-by: ysr, iveresov, johnc ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp Changeset: 3be7439273c5 Author: katleman Date: 2011-05-25 13:31 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/3be7439273c5 7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles Reviewed-by: ohair, trims ! agent/src/share/classes/sun/jvm/hotspot/runtime/ServiceThread.java ! make/linux/README ! make/windows/projectfiles/kernel/Makefile ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.s ! src/share/tools/hsdis/README ! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/utilities/yieldingWorkgroup.cpp Changeset: 8b135e6129d6 Author: jeff Date: 2011-05-27 15:01 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/8b135e6129d6 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 52e4ba46751f Author: kamg Date: 2011-04-12 16:42 -0400 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/52e4ba46751f 7020373: JSR rewriting can overflow memory address size variables Summary: Abort if incoming classfile's parameters would cause overflows Reviewed-by: coleenp, dcubed, never ! src/share/vm/oops/generateOopMap.cpp + test/runtime/7020373/Test7020373.sh Changeset: bca686989d4b Author: asaha Date: 2011-06-15 14:59 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/bca686989d4b 7055247: Ignore test of # 7020373 Reviewed-by: dcubed ! test/runtime/7020373/Test7020373.sh Changeset: 337ffef74c37 Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/337ffef74c37 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: 9f12ede5571a Author: jcoomes Date: 2011-08-19 14:08 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/9f12ede5571a Merge ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/runtime/os.cpp Changeset: 7c29742c41b4 Author: jcoomes Date: 2011-08-19 14:22 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/7c29742c41b4 7081251: bump the hs22 build number to 02 Reviewed-by: johnc ! make/hotspot_version From tanguy.lachenal at free.fr Tue Aug 23 10:29:23 2011 From: tanguy.lachenal at free.fr (Lachenal tanguy) Date: Tue, 23 Aug 2011 19:29:23 +0200 Subject: Strange behavior with a "tail rec" optimization Message-ID: <4E53E373.2080207@free.fr> Hello, I've tried to benchmark a quicksort programm writen in Java and Scala and i get some strange result (At least for me). But the problem seems not related to Scala but more to JIT or my benchmark are wrong... Here is the quicksort programm (All in java of course :)) public class QuickSortJava { public static void sort(int[] xs) { sort1(0, xs.length - 1, xs); } private static void swap(int i, int j, int[] xs) { int t = xs[i]; xs[i] = xs[j]; xs[j] = t; } private static void sort1(int l, int r, int[] xs) { int pivot = xs[(l + r) / 2]; int i = l; int j = r; while (i <= j) { while (xs[i] < pivot) i += 1; while (xs[j] > pivot) j -= 1; if (i <= j) { swap(i, j, xs); i += 1; j -= 1; } } if (l < j) sort1(l, j, xs); if (j < r) sort1(i, r, xs); } } Now the quicksort programm that i get with the scala compiler in java version : public class QuickSortScala { public static void sort(int[] xs) { sort1(0, xs.length - 1, xs); } private static void swap(int i, int j, int[] xs) { int t = xs[i]; xs[i] = xs[j]; xs[j] = t; } private static void sort1(int l, int r, int[] xs) { while (true) { int pivot = xs[(l + r) / 2]; int i = l; int j = r; while (i <= j) { while (xs[i] < pivot) i += 1; while (xs[j] > pivot) j -= 1; if (i <= j) { swap(i, j, xs); i += 1; j -= 1; } } if (l < j) sort1(l, j, xs); if (j >= r) break; l = i; } } } Notice that the only difference is that the last 'sort1' call is transformed into a while loop. Now the test programm : public class MQuickSort { public static void main(String[] args) { int arraySize = 1 * 1000 * 1000; int nbLoop = 20; int[] xs = new int[arraySize]; // Warm up for (int l = 0; l < nbLoop; l++) { initArray(xs); QuickSortJava.sort(xs); initArray(xs); QuickSortScala.sort(xs); } double delta2 = 0; for (int l = 0; l < nbLoop; l++) { initArray(xs); double t1 = System.nanoTime(); QuickSortScala.sort(xs); double t2 = System.nanoTime(); delta2 += (t2 - t1) / 1000.0 / 1000.0; } System.err.println("Delta for scala " + (delta2 / nbLoop)); double delta1 = 0; for (int l = 0; l < nbLoop; l++) { initArray(xs); double t1 = System.nanoTime(); QuickSortJava.sort(xs); double t2 = System.nanoTime(); delta1 += (t2 - t1) / 1000.0 / 1000.0; } System.err.println("Delta for java " + (delta1 / nbLoop)); } public static void initArray(int[] xs) { for (int i = 0; i < xs.length; i++) { xs[i] = xs.length - i; } } } And finally the result : Delta for scala 43.98459049999998 Delta for java 32.0383011 So the version with the "tail rec" optimization performs significatively slower than the traditional one. I tried this with JDK 1.6 update 21 and 27 and the JDK 1.7 and i get the same result. I was expecting that the two versions will perform nearly the same. So I don't understand why they are such a difference in performance. So my questions are : + Is my test programm wrong ? + Why the while loop performs so badly in this case ? Thanks for your response and for reading this long post :) From rednaxelafx at gmail.com Tue Aug 23 22:40:33 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 24 Aug 2011 13:40:33 +0800 Subject: documenting PrintCompilation output Message-ID: Hi all, I wrote a note describing the output of PrintCompilation from HotSpot VM: https://gist.github.com/1165804#file_notes.md I thought there might be other people interested, so I'm posting the link here. Please correct me if I've made any mistakes in the note, especially the details. I'm not familiar with the HotSpot VMs before OpenJDK came out, so I'm not too sure if I got it right. P.S. Any chances of integrating notes like this one into the HotSpot Internals wiki ( http://wikis.sun.com/display/HotSpotInternals/PrintCompilation)? Regards, Kris Mok -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110824/328cc539/attachment.html From christian.thalinger at oracle.com Wed Aug 24 04:32:41 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 24 Aug 2011 13:32:41 +0200 Subject: documenting PrintCompilation output In-Reply-To: References: Message-ID: <77B34F8B-0148-4FF2-B327-7E46A9152B85@oracle.com> I quickly looked over the file and noticed that the links for CR 7022998 are wrong. -- Christian On Aug 24, 2011, at 7:40 AM, Krystal Mok wrote: > Hi all, > > I wrote a note describing the output of PrintCompilation from HotSpot VM: https://gist.github.com/1165804#file_notes.md > I thought there might be other people interested, so I'm posting the link here. > > Please correct me if I've made any mistakes in the note, especially the details. I'm not familiar with the HotSpot VMs before OpenJDK came out, so I'm not too sure if I got it right. > > P.S. Any chances of integrating notes like this one into the HotSpot Internals wiki (http://wikis.sun.com/display/HotSpotInternals/PrintCompilation)? > > Regards, > Kris Mok From rednaxelafx at gmail.com Wed Aug 24 08:10:34 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 24 Aug 2011 23:10:34 +0800 Subject: documenting PrintCompilation output In-Reply-To: <77B34F8B-0148-4FF2-B327-7E46A9152B85@oracle.com> References: <77B34F8B-0148-4FF2-B327-7E46A9152B85@oracle.com> Message-ID: Hi Christian, I quickly looked over the file and noticed that the links for CR 7022998 are > wrong. Oops, my bad. Copy-and-paste bug. Fixed it. Thanks for pointing that out! BTW, the compilation level in tiered mode in HS22-b02 is still printed as "0". I'm not sure what's the cleaner way of getting the intended "-"; this one certainly does the trick: diff -r a594deb1d6dc src/share/vm/compiler/compileBroker.cpp --- a/src/share/vm/compiler/compileBroker.cpp Mon Aug 22 11:00:39 2011 -0700 +++ b/src/share/vm/compiler/compileBroker.cpp Wed Aug 24 23:06:21 2011 +0800 @@ -322,8 +322,8 @@ st->print("%c%c%c%c%c ", compile_type, sync_char, exception_char, blocking_char, native_char); if (TieredCompilation) { - if (comp_level != -1) st->print("%d ", comp_level); - else st->print("- "); + if (comp_level != CompLevel_none) st->print("%d ", comp_level); + else st->print("- "); } st->print(" "); // more indent Or maybe it's better to create the nmethod object for the native wrapper with a compilation level of -1, in nmethod::new_native_nmethod Regards, Kris Mok On Wed, Aug 24, 2011 at 7:32 PM, Christian Thalinger < christian.thalinger at oracle.com> wrote: > I quickly looked over the file and noticed that the links for CR 7022998 > are wrong. > > -- Christian > > On Aug 24, 2011, at 7:40 AM, Krystal Mok wrote: > > > Hi all, > > > > I wrote a note describing the output of PrintCompilation from HotSpot VM: > https://gist.github.com/1165804#file_notes.md > > I thought there might be other people interested, so I'm posting the link > here. > > > > Please correct me if I've made any mistakes in the note, especially the > details. I'm not familiar with the HotSpot VMs before OpenJDK came out, so > I'm not too sure if I got it right. > > > > P.S. Any chances of integrating notes like this one into the HotSpot > Internals wiki ( > http://wikis.sun.com/display/HotSpotInternals/PrintCompilation)? > > > > Regards, > > Kris Mok > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110824/731bf1b0/attachment.html From Baiyan.Huang at morganstanley.com Thu Aug 25 02:56:25 2011 From: Baiyan.Huang at morganstanley.com (Huang, Baiyan) Date: Thu, 25 Aug 2011 17:56:25 +0800 Subject: Disable JVM from handling hard errors Message-ID: Hi, everyone, Suppose I have a simple JNI program in Windows: int* p = NULL; *p = 5; When run it from JVM, not like normal C++ application, JVM will nicely catch such hard exception and do some cleanup work. The problem here is it also stops me from generating crash dumps right there, although there is a JVM option: -XX:OnError, but core dumps generated at this point is far from the crime scene thus hard to debug. Do you have any suggestions? Thanks. -Baiyan -------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110825/923a8039/attachment.html From David.Holmes at oracle.com Thu Aug 25 03:32:12 2011 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 25 Aug 2011 20:32:12 +1000 Subject: Disable JVM from handling hard errors In-Reply-To: References: Message-ID: <4E5624AC.40105@oracle.com> On 25/08/2011 7:56 PM, Huang, Baiyan wrote: > Suppose I have a simple JNI program in Windows: > > int* p = NULL; > > *p = 5; > > When run it from JVM, not like normal C++ application, JVM will nicely catch > such hard exception and do some cleanup work. > > The problem here is it also stops me from generating crash dumps right > there, although there is a JVM option: -XX:OnError, but core dumps generated > at this point is far from the crime scene thus hard to debug. > > Do you have any suggestions? I think you'd need to install your own fatal exception handler whilst in the JNI code, and restore the JVM handler when leaving. I'm not sure of the details on Windows in terms of API. But the JVM fatal error handling can create a crash dump - use -XX:CreateMinidumpOnCrash David > Thanks. > > -Baiyan > > ---------------------------------------------------------------------------- > NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions > or views contained herein are not intended to be, and do not constitute, > advice within the meaning of Section 975 of the Dodd-Frank Wall Street > Reform and Consumer Protection Act. If you have received this communication > in error, please destroy all electronic and paper copies and notify the > sender immediately. Mistransmission is not intended to waive confidentiality > or privilege. Morgan Stanley reserves the right, to the extent permitted > under applicable law, to monitor electronic communications. This message is > subject to terms available at the following link: > http://www.morganstanley.com/disclaimers. If you cannot access these links, > please notify us by reply message and we will send the contents to you. By > messaging with Morgan Stanley you consent to the foregoing. From Baiyan.Huang at morganstanley.com Thu Aug 25 07:17:09 2011 From: Baiyan.Huang at morganstanley.com (Huang, Baiyan) Date: Thu, 25 Aug 2011 22:17:09 +0800 Subject: Disable JVM from handling hard errors In-Reply-To: <4E5624AC.40105@oracle.com> References: <4E5624AC.40105@oracle.com> Message-ID: Thanks David, But what if I don't have the permission to change the JNI code? Actually, even I can change the JNI code, and I install my exception handler, it also "handle" the exception, and the execution flow is jump to other place, rather than the "crash" point. -XX:CreateMinidumpOnCrash should be similar as it also requires a exception handler. I am thinking of away to disable the internal handling in JVM of such exception. -Baiyan -----Original Message----- From: David Holmes [mailto:David.Holmes at oracle.com] Sent: Thursday, August 25, 2011 6:32 PM To: Huang, Baiyan (ISGT) Cc: hotspot-dev at openjdk.java.net Subject: Re: Disable JVM from handling hard errors On 25/08/2011 7:56 PM, Huang, Baiyan wrote: > Suppose I have a simple JNI program in Windows: > > int* p = NULL; > > *p = 5; > > When run it from JVM, not like normal C++ application, JVM will nicely catch > such hard exception and do some cleanup work. > > The problem here is it also stops me from generating crash dumps right > there, although there is a JVM option: -XX:OnError, but core dumps generated > at this point is far from the crime scene thus hard to debug. > > Do you have any suggestions? I think you'd need to install your own fatal exception handler whilst in the JNI code, and restore the JVM handler when leaving. I'm not sure of the details on Windows in terms of API. But the JVM fatal error handling can create a crash dump - use -XX:CreateMinidumpOnCrash David > Thanks. > > -Baiyan > > ---------------------------------------------------------------------------- > NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions > or views contained herein are not intended to be, and do not constitute, > advice within the meaning of Section 975 of the Dodd-Frank Wall Street > Reform and Consumer Protection Act. If you have received this communication > in error, please destroy all electronic and paper copies and notify the > sender immediately. Mistransmission is not intended to waive confidentiality > or privilege. Morgan Stanley reserves the right, to the extent permitted > under applicable law, to monitor electronic communications. This message is > subject to terms available at the following link: > http://www.morganstanley.com/disclaimers. If you cannot access these links, > please notify us by reply message and we will send the contents to you. By > messaging with Morgan Stanley you consent to the foregoing. -------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing. From coleen.phillimore at oracle.com Thu Aug 25 07:52:30 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 25 Aug 2011 10:52:30 -0400 Subject: Disable JVM from handling hard errors In-Reply-To: References: <4E5624AC.40105@oracle.com> Message-ID: <4E5661AE.1040602@oracle.com> The option you want is -XX:+UseOSErrorReporting. That will stop and put you in the windows debugger at the point of the crash. Coleen On 8/25/2011 10:17 AM, Huang, Baiyan wrote: > Thanks David, > > But what if I don't have the permission to change the JNI code? > > Actually, even I can change the JNI code, and I install my exception handler, it also "handle" the exception, and the execution flow is jump to other place, rather than the "crash" point. -XX:CreateMinidumpOnCrash should be similar as it also requires a exception handler. > > I am thinking of away to disable the internal handling in JVM of such exception. > > -Baiyan > > > -----Original Message----- > From: David Holmes [mailto:David.Holmes at oracle.com] > Sent: Thursday, August 25, 2011 6:32 PM > To: Huang, Baiyan (ISGT) > Cc: hotspot-dev at openjdk.java.net > Subject: Re: Disable JVM from handling hard errors > > On 25/08/2011 7:56 PM, Huang, Baiyan wrote: >> Suppose I have a simple JNI program in Windows: >> >> int* p = NULL; >> >> *p = 5; >> >> When run it from JVM, not like normal C++ application, JVM will nicely catch >> such hard exception and do some cleanup work. >> >> The problem here is it also stops me from generating crash dumps right >> there, although there is a JVM option: -XX:OnError, but core dumps generated >> at this point is far from the crime scene thus hard to debug. >> >> Do you have any suggestions? > I think you'd need to install your own fatal exception handler whilst in the > JNI code, and restore the JVM handler when leaving. I'm not sure of the > details on Windows in terms of API. > > But the JVM fatal error handling can create a crash dump - use > -XX:CreateMinidumpOnCrash > > David > >> Thanks. >> >> -Baiyan >> >> ---------------------------------------------------------------------------- >> NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions >> or views contained herein are not intended to be, and do not constitute, >> advice within the meaning of Section 975 of the Dodd-Frank Wall Street >> Reform and Consumer Protection Act. If you have received this communication >> in error, please destroy all electronic and paper copies and notify the >> sender immediately. Mistransmission is not intended to waive confidentiality >> or privilege. Morgan Stanley reserves the right, to the extent permitted >> under applicable law, to monitor electronic communications. This message is >> subject to terms available at the following link: >> http://www.morganstanley.com/disclaimers. If you cannot access these links, >> please notify us by reply message and we will send the contents to you. By >> messaging with Morgan Stanley you consent to the foregoing. > -------------------------------------------------------------------------- > NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing. From christian.tornqvist at oracle.com Thu Aug 25 08:09:21 2011 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Thu, 25 Aug 2011 08:09:21 -0700 (PDT) Subject: Disable JVM from handling hard errors In-Reply-To: References: <4E5624AC.40105@oracle.com FCA040E41AF5D748B572D8ECBE2BAF35090F5EC573@HKWEXMBX0050.msad.ms.com> Message-ID: There should be an exception context record stored in the minidump which should put you in the correct context. When loaded in windbg, use the command '.ecxr' to set the context to the exception context record. Regards, Christian -----Original Message----- From: Huang, Baiyan [mailto:Baiyan.Huang at morganstanley.com] Sent: den 25 augusti 2011 16:17 To: David Holmes Cc: hotspot-dev at openjdk.java.net Subject: RE: Disable JVM from handling hard errors Thanks David, But what if I don't have the permission to change the JNI code? Actually, even I can change the JNI code, and I install my exception handler, it also "handle" the exception, and the execution flow is jump to other place, rather than the "crash" point. -XX:CreateMinidumpOnCrash should be similar as it also requires a exception handler. I am thinking of away to disable the internal handling in JVM of such exception. -Baiyan -----Original Message----- From: David Holmes [mailto:David.Holmes at oracle.com] Sent: Thursday, August 25, 2011 6:32 PM To: Huang, Baiyan (ISGT) Cc: hotspot-dev at openjdk.java.net Subject: Re: Disable JVM from handling hard errors On 25/08/2011 7:56 PM, Huang, Baiyan wrote: > Suppose I have a simple JNI program in Windows: > > int* p = NULL; > > *p = 5; > > When run it from JVM, not like normal C++ application, JVM will nicely catch > such hard exception and do some cleanup work. > > The problem here is it also stops me from generating crash dumps right > there, although there is a JVM option: -XX:OnError, but core dumps generated > at this point is far from the crime scene thus hard to debug. > > Do you have any suggestions? I think you'd need to install your own fatal exception handler whilst in the JNI code, and restore the JVM handler when leaving. I'm not sure of the details on Windows in terms of API. But the JVM fatal error handling can create a crash dump - use -XX:CreateMinidumpOnCrash David > Thanks. > > -Baiyan > > ---------------------------------------------------------------------------- > NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions > or views contained herein are not intended to be, and do not constitute, > advice within the meaning of Section 975 of the Dodd-Frank Wall Street > Reform and Consumer Protection Act. If you have received this communication > in error, please destroy all electronic and paper copies and notify the > sender immediately. Mistransmission is not intended to waive confidentiality > or privilege. Morgan Stanley reserves the right, to the extent permitted > under applicable law, to monitor electronic communications. This message is > subject to terms available at the following link: > http://www.morganstanley.com/disclaimers. If you cannot access these links, > please notify us by reply message and we will send the contents to you. By > messaging with Morgan Stanley you consent to the foregoing. -------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing. From y.s.ramakrishna at oracle.com Thu Aug 25 18:06:19 2011 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Fri, 26 Aug 2011 01:06:19 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20110826010632.9C9BC47115@hg.openjdk.java.net> Changeset: ff53346271fe Author: brutisso Date: 2011-08-19 09:30 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ff53346271fe 6814390: G1: remove the concept of non-generational G1 Summary: Removed the possibility to turn off generational mode for G1. Reviewed-by: johnc, ysr, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: ae73da50be4b Author: tonyp Date: 2011-08-22 10:16 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ae73da50be4b 7081064: G1: remove develop params G1FixedSurvivorSpaceSize, G1FixedTenuringThreshold, and G1FixedEdenSize Summary: Remove three develop parameters we don't use. Reviewed-by: brutisso, jwilhelm ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 7f776886a215 Author: ysr Date: 2011-08-22 12:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7f776886a215 6810861: G1: support -XX:+{PrintClassHistogram,HeapDump}{Before,After}FullGC Summary: Call {pre,post}_full_gc_dump() before and after a STW full gc of G1CollectedHeap. Also adjusted the prefix message, including the addition of missing whitespace. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.cpp Changeset: be05e987ba07 Author: ysr Date: 2011-08-22 23:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/be05e987ba07 Merge Changeset: 2f27ed2a98fa Author: brutisso Date: 2011-08-23 11:06 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2f27ed2a98fa 7082220: Visual Studio projects broken after change 7016797: Hotspot: securely/restrictive load dlls and new Summary: Add the psapi.lib library to Visual Studio projects Reviewed-by: jwilhelm, poonam, kamg ! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java From tom.rodriguez at oracle.com Thu Aug 25 20:35:22 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 25 Aug 2011 20:35:22 -0700 Subject: review for 7082263: Reflection::resolve_field/field_get/field_set are broken Message-ID: <4B4D0B81-DDF5-4FE5-BC3A-6193A95BBE26@oracle.com> http://cr.openjdk.java.net/~never/7082263 1023 lines changed: 0 ins; 1017 del; 6 mod; 10236 unchg 7082263: Reflection::resolve_field/field_get/field_set are broken Reviewed-by: The static field mirror changes missed some dead code in reflection. Instead of fixing it I'm deleting it. I've deleted all the reflection code that's dead. I confirmed that none of these JVM_ entry points are referenced by any JDK since 1.5. They also aren't mentioned by the jvm.h in the JDK. Tested with JPRT. From David.Holmes at oracle.com Thu Aug 25 21:26:23 2011 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 26 Aug 2011 14:26:23 +1000 Subject: review for 7082263: Reflection::resolve_field/field_get/field_set are broken In-Reply-To: <4B4D0B81-DDF5-4FE5-BC3A-6193A95BBE26@oracle.com> References: <4B4D0B81-DDF5-4FE5-BC3A-6193A95BBE26@oracle.com> Message-ID: <4E57206F.1010006@oracle.com> Hi Tom, On 26/08/2011 1:35 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7082263 > 1023 lines changed: 0 ins; 1017 del; 6 mod; 10236 unchg > > 7082263: Reflection::resolve_field/field_get/field_set are broken > Reviewed-by: > > The static field mirror changes missed some dead code in reflection. > Instead of fixing it I'm deleting it. I've deleted all the reflection > code that's dead. I confirmed that none of these JVM_ entry points > are referenced by any JDK since 1.5. They also aren't mentioned by > the jvm.h in the JDK. Tested with JPRT. Seems the "old reflection" code is partly still the current reflection code! :) But the deletion looks good. Only thing I'd suggest is to run the jdk reflection tests in addition to JPRT testing. David From vladimir.kozlov at oracle.com Thu Aug 25 21:32:21 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 25 Aug 2011 21:32:21 -0700 Subject: review for 7082263: Reflection::resolve_field/field_get/field_set are broken In-Reply-To: <4B4D0B81-DDF5-4FE5-BC3A-6193A95BBE26@oracle.com> References: <4B4D0B81-DDF5-4FE5-BC3A-6193A95BBE26@oracle.com> Message-ID: <4E5721D5.1020605@oracle.com> Looks good. Why jsr292 methods were under #ifdef SUPPORT_OLD_REFLECTION in these files? Thanks, Vladimir On 8/25/11 8:35 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7082263 > 1023 lines changed: 0 ins; 1017 del; 6 mod; 10236 unchg > > 7082263: Reflection::resolve_field/field_get/field_set are broken > Reviewed-by: > > The static field mirror changes missed some dead code in reflection. > Instead of fixing it I'm deleting it. I've deleted all the reflection > code that's dead. I confirmed that none of these JVM_ entry points > are referenced by any JDK since 1.5. They also aren't mentioned by > the jvm.h in the JDK. Tested with JPRT. > From vladimir.kozlov at oracle.com Fri Aug 26 00:25:02 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 26 Aug 2011 07:25:02 +0000 Subject: hg: hsx/hotspot-main/hotspot: 3 new changesets Message-ID: <20110826072510.63B8547123@hg.openjdk.java.net> Changeset: ff9ab6327924 Author: kvn Date: 2011-08-20 14:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ff9ab6327924 7076831: TEST_BUG: compiler/5091921/Test7005594.java fails on LOW MEM SYSTEMS Summary: Run test only on systems with 2Gbyte or more memory. Don't zap heap to reduce execution time. Reviewed-by: iveresov ! test/compiler/5091921/Test7005594.sh Changeset: a594deb1d6dc Author: kvn Date: 2011-08-22 11:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a594deb1d6dc 7081926: assert(VM_Version::supports_sse2()) failed: must support Summary: fix assert, prefetchnta is supported since SSE not SSE2. Reviewed-by: never ! src/cpu/x86/vm/assembler_x86.cpp Changeset: a70c2acb8f52 Author: kvn Date: 2011-08-25 18:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a70c2acb8f52 Merge From stefan.karlsson at oracle.com Fri Aug 26 00:54:39 2011 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 26 Aug 2011 09:54:39 +0200 Subject: review for 7082263: Reflection::resolve_field/field_get/field_set are broken In-Reply-To: <4B4D0B81-DDF5-4FE5-BC3A-6193A95BBE26@oracle.com> References: <4B4D0B81-DDF5-4FE5-BC3A-6193A95BBE26@oracle.com> Message-ID: <4E57513F.9040303@oracle.com> Looks good. If you want to, you could collapse this ifdef in make/solaris/makefiles/product.make: # Linker mapfiles ifdef USE_GCC MAPFILE = $(GAMMADIR)/make/solaris/makefiles/mapfile-vers else MAPFILE = $(GAMMADIR)/make/solaris/makefiles/mapfile-vers StefanK On 08/26/2011 05:35 AM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7082263 > 1023 lines changed: 0 ins; 1017 del; 6 mod; 10236 unchg > > 7082263: Reflection::resolve_field/field_get/field_set are broken > Reviewed-by: > > The static field mirror changes missed some dead code in reflection. > Instead of fixing it I'm deleting it. I've deleted all the reflection > code that's dead. I confirmed that none of these JVM_ entry points > are referenced by any JDK since 1.5. They also aren't mentioned by > the jvm.h in the JDK. Tested with JPRT. > From tom.rodriguez at oracle.com Fri Aug 26 07:37:29 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 26 Aug 2011 07:37:29 -0700 Subject: review for 7082263: Reflection::resolve_field/field_get/field_set are broken In-Reply-To: <4E5721D5.1020605@oracle.com> References: <4B4D0B81-DDF5-4FE5-BC3A-6193A95BBE26@oracle.com> <4E5721D5.1020605@oracle.com> Message-ID: <0DBD079F-32CE-4F99-A8B1-BDDBD11BF341@oracle.com> On Aug 25, 2011, at 9:32 PM, Vladimir Kozlov wrote: > Looks good. > > Why jsr292 methods were under #ifdef SUPPORT_OLD_REFLECTION in these files? Do you mean JVM_DefineClassWithCP in jvm.h? It wasn't under the ifdef but since it was neither defined nor exported I went ahead and deleted it. Thanks! tom > > Thanks, > Vladimir > > On 8/25/11 8:35 PM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7082263 >> 1023 lines changed: 0 ins; 1017 del; 6 mod; 10236 unchg >> >> 7082263: Reflection::resolve_field/field_get/field_set are broken >> Reviewed-by: >> >> The static field mirror changes missed some dead code in reflection. >> Instead of fixing it I'm deleting it. I've deleted all the reflection >> code that's dead. I confirmed that none of these JVM_ entry points >> are referenced by any JDK since 1.5. They also aren't mentioned by >> the jvm.h in the JDK. Tested with JPRT. >> From tom.rodriguez at oracle.com Fri Aug 26 07:39:58 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 26 Aug 2011 07:39:58 -0700 Subject: review for 7082263: Reflection::resolve_field/field_get/field_set are broken In-Reply-To: <4E57513F.9040303@oracle.com> References: <4B4D0B81-DDF5-4FE5-BC3A-6193A95BBE26@oracle.com> <4E57513F.9040303@oracle.com> Message-ID: <780F49F7-9C85-4D85-BA86-2320EB957B93@oracle.com> On Aug 26, 2011, at 12:54 AM, Stefan Karlsson wrote: > Looks good. > > If you want to, you could collapse this ifdef in make/solaris/makefiles/product.make: > # Linker mapfiles > ifdef USE_GCC > MAPFILE = $(GAMMADIR)/make/solaris/makefiles/mapfile-vers > else > MAPFILE = $(GAMMADIR)/make/solaris/makefiles/mapfile-vers Fixed. Thanks! tom > > StefanK > > On 08/26/2011 05:35 AM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7082263 >> 1023 lines changed: 0 ins; 1017 del; 6 mod; 10236 unchg >> >> 7082263: Reflection::resolve_field/field_get/field_set are broken >> Reviewed-by: >> >> The static field mirror changes missed some dead code in reflection. >> Instead of fixing it I'm deleting it. I've deleted all the reflection >> code that's dead. I confirmed that none of these JVM_ entry points >> are referenced by any JDK since 1.5. They also aren't mentioned by >> the jvm.h in the JDK. Tested with JPRT. >> > From tom.rodriguez at oracle.com Fri Aug 26 07:41:22 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 26 Aug 2011 07:41:22 -0700 Subject: review for 7082263: Reflection::resolve_field/field_get/field_set are broken In-Reply-To: <4E57206F.1010006@oracle.com> References: <4B4D0B81-DDF5-4FE5-BC3A-6193A95BBE26@oracle.com> <4E57206F.1010006@oracle.com> Message-ID: On Aug 25, 2011, at 9:26 PM, David Holmes wrote: > Hi Tom, > > On 26/08/2011 1:35 PM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7082263 >> 1023 lines changed: 0 ins; 1017 del; 6 mod; 10236 unchg >> >> 7082263: Reflection::resolve_field/field_get/field_set are broken >> Reviewed-by: >> >> The static field mirror changes missed some dead code in reflection. >> Instead of fixing it I'm deleting it. I've deleted all the reflection >> code that's dead. I confirmed that none of these JVM_ entry points >> are referenced by any JDK since 1.5. They also aren't mentioned by >> the jvm.h in the JDK. Tested with JPRT. > > Seems the "old reflection" code is partly still the current reflection code! :) Yes. For quite a long time too. > > But the deletion looks good. Only thing I'd suggest is to run the jdk reflection tests in addition to JPRT testing. I'll run them for completeness but these functions are mentioned neither by the sources nor the binaries so I think it's clear they dead. Thanks. tom > > David > From coleen.phillimore at oracle.com Fri Aug 26 07:48:29 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 26 Aug 2011 10:48:29 -0400 Subject: review for 7082263: Reflection::resolve_field/field_get/field_set are broken In-Reply-To: <780F49F7-9C85-4D85-BA86-2320EB957B93@oracle.com> References: <4B4D0B81-DDF5-4FE5-BC3A-6193A95BBE26@oracle.com> <4E57513F.9040303@oracle.com> <780F49F7-9C85-4D85-BA86-2320EB957B93@oracle.com> Message-ID: <4E57B23D.7090106@oracle.com> This is so helpful, thanks! Coleen On 8/26/2011 10:39 AM, Tom Rodriguez wrote: > On Aug 26, 2011, at 12:54 AM, Stefan Karlsson wrote: > >> Looks good. >> >> If you want to, you could collapse this ifdef in make/solaris/makefiles/product.make: >> # Linker mapfiles >> ifdef USE_GCC >> MAPFILE = $(GAMMADIR)/make/solaris/makefiles/mapfile-vers >> else >> MAPFILE = $(GAMMADIR)/make/solaris/makefiles/mapfile-vers > Fixed. Thanks! > > tom > > >> StefanK >> >> On 08/26/2011 05:35 AM, Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7082263 >>> 1023 lines changed: 0 ins; 1017 del; 6 mod; 10236 unchg >>> >>> 7082263: Reflection::resolve_field/field_get/field_set are broken >>> Reviewed-by: >>> >>> The static field mirror changes missed some dead code in reflection. >>> Instead of fixing it I'm deleting it. I've deleted all the reflection >>> code that's dead. I confirmed that none of these JVM_ entry points >>> are referenced by any JDK since 1.5. They also aren't mentioned by >>> the jvm.h in the JDK. Tested with JPRT. >>> From tom.rodriguez at oracle.com Fri Aug 26 09:22:24 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 26 Aug 2011 09:22:24 -0700 Subject: review for 7082263: Reflection::resolve_field/field_get/field_set are broken In-Reply-To: References: <4B4D0B81-DDF5-4FE5-BC3A-6193A95BBE26@oracle.com> <4E57206F.1010006@oracle.com> Message-ID: On Aug 26, 2011, at 7:41 AM, Tom Rodriguez wrote: > > On Aug 25, 2011, at 9:26 PM, David Holmes wrote: > >> Hi Tom, >> >> On 26/08/2011 1:35 PM, Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7082263 >>> 1023 lines changed: 0 ins; 1017 del; 6 mod; 10236 unchg >>> >>> 7082263: Reflection::resolve_field/field_get/field_set are broken >>> Reviewed-by: >>> >>> The static field mirror changes missed some dead code in reflection. >>> Instead of fixing it I'm deleting it. I've deleted all the reflection >>> code that's dead. I confirmed that none of these JVM_ entry points >>> are referenced by any JDK since 1.5. They also aren't mentioned by >>> the jvm.h in the JDK. Tested with JPRT. >> >> Seems the "old reflection" code is partly still the current reflection code! :) > > Yes. For quite a long time too. > >> >> But the deletion looks good. Only thing I'd suggest is to run the jdk reflection tests in addition to JPRT testing. > > I'll run them for completeness but these functions are mentioned neither by the sources nor the binaries so I think it's clear they dead. They all passed. tom > > Thanks. > > tom > >> >> David >> > From vladimir.kozlov at oracle.com Fri Aug 26 20:02:36 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sat, 27 Aug 2011 03:02:36 +0000 Subject: hg: hsx/hsx22/hotspot: 9 new changesets Message-ID: <20110827030256.662A747158@hg.openjdk.java.net> Changeset: ff53346271fe Author: brutisso Date: 2011-08-19 09:30 +0200 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/ff53346271fe 6814390: G1: remove the concept of non-generational G1 Summary: Removed the possibility to turn off generational mode for G1. Reviewed-by: johnc, ysr, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: ae73da50be4b Author: tonyp Date: 2011-08-22 10:16 -0400 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/ae73da50be4b 7081064: G1: remove develop params G1FixedSurvivorSpaceSize, G1FixedTenuringThreshold, and G1FixedEdenSize Summary: Remove three develop parameters we don't use. Reviewed-by: brutisso, jwilhelm ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 7f776886a215 Author: ysr Date: 2011-08-22 12:30 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/7f776886a215 6810861: G1: support -XX:+{PrintClassHistogram,HeapDump}{Before,After}FullGC Summary: Call {pre,post}_full_gc_dump() before and after a STW full gc of G1CollectedHeap. Also adjusted the prefix message, including the addition of missing whitespace. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.cpp Changeset: be05e987ba07 Author: ysr Date: 2011-08-22 23:57 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/be05e987ba07 Merge Changeset: 2f27ed2a98fa Author: brutisso Date: 2011-08-23 11:06 +0200 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/2f27ed2a98fa 7082220: Visual Studio projects broken after change 7016797: Hotspot: securely/restrictive load dlls and new Summary: Add the psapi.lib library to Visual Studio projects Reviewed-by: jwilhelm, poonam, kamg ! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java Changeset: ff9ab6327924 Author: kvn Date: 2011-08-20 14:03 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/ff9ab6327924 7076831: TEST_BUG: compiler/5091921/Test7005594.java fails on LOW MEM SYSTEMS Summary: Run test only on systems with 2Gbyte or more memory. Don't zap heap to reduce execution time. Reviewed-by: iveresov ! test/compiler/5091921/Test7005594.sh Changeset: a594deb1d6dc Author: kvn Date: 2011-08-22 11:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/a594deb1d6dc 7081926: assert(VM_Version::supports_sse2()) failed: must support Summary: fix assert, prefetchnta is supported since SSE not SSE2. Reviewed-by: never ! src/cpu/x86/vm/assembler_x86.cpp Changeset: a70c2acb8f52 Author: kvn Date: 2011-08-25 18:56 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/a70c2acb8f52 Merge Changeset: 1520340a7f35 Author: kvn Date: 2011-08-26 16:11 -0700 URL: http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/1520340a7f35 7083916: Bump the hs22 build number to 03 Reviewed-by: jcoomes Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version From Baiyan.Huang at morganstanley.com Sat Aug 27 20:32:00 2011 From: Baiyan.Huang at morganstanley.com (Huang, Baiyan) Date: Sun, 28 Aug 2011 11:32:00 +0800 Subject: Disable JVM from handling hard errors In-Reply-To: <4E5661AE.1040602@oracle.com> References: <4E5624AC.40105@oracle.com>, <4E5661AE.1040602@oracle.com> Message-ID: Thanks Coleen, But what should be the right way to use this option, I do it this way: (Windows) 1. Config windbg as the default debugger to create dump Registry: Debugger=windbg.exe -p %ld -e %ld -g 2. Run my application which will crash in JNI (access vioration) java.exe -XX:+UseOSErrorReporting Main But it seems only start windbg for me, it doesn't create a dump file for me, nor could I see the exact call stack. According to this post: http://bugs.sun.com/view_bug.do?bug_id=4997835, it should create both hprof and dump file for me. BTW, when I run my application with jre 7, it prints out a message: # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows Is this a new feature in Java 7, how could I do to enable it to write core dump as default? Thanks. ________________________________________ From: hotspot-dev-bounces at openjdk.java.net [hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore [coleen.phillimore at oracle.com] Sent: Thursday, August 25, 2011 10:52 PM To: hotspot-dev at openjdk.java.net Subject: Re: Disable JVM from handling hard errors The option you want is -XX:+UseOSErrorReporting. That will stop and put you in the windows debugger at the point of the crash. Coleen On 8/25/2011 10:17 AM, Huang, Baiyan wrote: > Thanks David, > > But what if I don't have the permission to change the JNI code? > > Actually, even I can change the JNI code, and I install my exception handler, it also "handle" the exception, and the execution flow is jump to other place, rather than the "crash" point. -XX:CreateMinidumpOnCrash should be similar as it also requires a exception handler. > > I am thinking of away to disable the internal handling in JVM of such exception. > > -Baiyan > > > -----Original Message----- > From: David Holmes [mailto:David.Holmes at oracle.com] > Sent: Thursday, August 25, 2011 6:32 PM > To: Huang, Baiyan (ISGT) > Cc: hotspot-dev at openjdk.java.net > Subject: Re: Disable JVM from handling hard errors > > On 25/08/2011 7:56 PM, Huang, Baiyan wrote: >> Suppose I have a simple JNI program in Windows: >> >> int* p = NULL; >> >> *p = 5; >> >> When run it from JVM, not like normal C++ application, JVM will nicely catch >> such hard exception and do some cleanup work. >> >> The problem here is it also stops me from generating crash dumps right >> there, although there is a JVM option: -XX:OnError, but core dumps generated >> at this point is far from the crime scene thus hard to debug. >> >> Do you have any suggestions? > I think you'd need to install your own fatal exception handler whilst in the > JNI code, and restore the JVM handler when leaving. I'm not sure of the > details on Windows in terms of API. > > But the JVM fatal error handling can create a crash dump - use > -XX:CreateMinidumpOnCrash > > David > >> Thanks. >> >> -Baiyan >> >> ---------------------------------------------------------------------------- >> NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions >> or views contained herein are not intended to be, and do not constitute, >> advice within the meaning of Section 975 of the Dodd-Frank Wall Street >> Reform and Consumer Protection Act. If you have received this communication >> in error, please destroy all electronic and paper copies and notify the >> sender immediately. Mistransmission is not intended to waive confidentiality >> or privilege. Morgan Stanley reserves the right, to the extent permitted >> under applicable law, to monitor electronic communications. This message is >> subject to terms available at the following link: >> http://www.morganstanley.com/disclaimers. If you cannot access these links, >> please notify us by reply message and we will send the contents to you. By >> messaging with Morgan Stanley you consent to the foregoing. > -------------------------------------------------------------------------- > NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing. -------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing. From vladimir.kozlov at oracle.com Sat Aug 27 21:45:16 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sun, 28 Aug 2011 04:45:16 +0000 Subject: hg: hsx/hotspot-main/hotspot: 7083916: Bump the hs22 build number to 03 Message-ID: <20110828044522.9B6244718F@hg.openjdk.java.net> Changeset: 1520340a7f35 Author: kvn Date: 2011-08-26 16:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1520340a7f35 7083916: Bump the hs22 build number to 03 Reviewed-by: jcoomes Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version From David.Holmes at oracle.com Sun Aug 28 04:33:04 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sun, 28 Aug 2011 21:33:04 +1000 Subject: Disable JVM from handling hard errors In-Reply-To: References: <4E5624AC.40105@oracle.com>, <4E5661AE.1040602@oracle.com> Message-ID: <4E5A2770.4080102@oracle.com> As mentioned previously with Java 7 use -XX:+CreateMinidumpOnCrash to enable mini-dumps. David On 28/08/2011 1:32 PM, Huang, Baiyan wrote: > Thanks Coleen, > > But what should be the right way to use this option, I do it this way: (Windows) > 1. Config windbg as the default debugger to create dump > Registry: Debugger=windbg.exe -p %ld -e %ld -g > 2. Run my application which will crash in JNI (access vioration) > java.exe -XX:+UseOSErrorReporting Main > > But it seems only start windbg for me, it doesn't create a dump file for me, nor could I see the exact call stack. > > According to this post: http://bugs.sun.com/view_bug.do?bug_id=4997835, it should create both hprof and dump file for me. > > > BTW, when I run my application with jre 7, it prints out a message: > # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows > Is this a new feature in Java 7, how could I do to enable it to write core dump as default? > > Thanks. > > > > ________________________________________ > From: hotspot-dev-bounces at openjdk.java.net [hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore [coleen.phillimore at oracle.com] > Sent: Thursday, August 25, 2011 10:52 PM > To: hotspot-dev at openjdk.java.net > Subject: Re: Disable JVM from handling hard errors > > The option you want is -XX:+UseOSErrorReporting. That will stop and put > you in the windows debugger at the point of the crash. > > Coleen > > On 8/25/2011 10:17 AM, Huang, Baiyan wrote: >> Thanks David, >> >> But what if I don't have the permission to change the JNI code? >> >> Actually, even I can change the JNI code, and I install my exception handler, it also "handle" the exception, and the execution flow is jump to other place, rather than the "crash" point. -XX:CreateMinidumpOnCrash should be similar as it also requires a exception handler. >> >> I am thinking of away to disable the internal handling in JVM of such exception. >> >> -Baiyan >> >> >> -----Original Message----- >> From: David Holmes [mailto:David.Holmes at oracle.com] >> Sent: Thursday, August 25, 2011 6:32 PM >> To: Huang, Baiyan (ISGT) >> Cc: hotspot-dev at openjdk.java.net >> Subject: Re: Disable JVM from handling hard errors >> >> On 25/08/2011 7:56 PM, Huang, Baiyan wrote: >>> Suppose I have a simple JNI program in Windows: >>> >>> int* p = NULL; >>> >>> *p = 5; >>> >>> When run it from JVM, not like normal C++ application, JVM will nicely catch >>> such hard exception and do some cleanup work. >>> >>> The problem here is it also stops me from generating crash dumps right >>> there, although there is a JVM option: -XX:OnError, but core dumps generated >>> at this point is far from the crime scene thus hard to debug. >>> >>> Do you have any suggestions? >> I think you'd need to install your own fatal exception handler whilst in the >> JNI code, and restore the JVM handler when leaving. I'm not sure of the >> details on Windows in terms of API. >> >> But the JVM fatal error handling can create a crash dump - use >> -XX:CreateMinidumpOnCrash >> >> David >> >>> Thanks. >>> >>> -Baiyan >>> >>> ---------------------------------------------------------------------------- >>> NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions >>> or views contained herein are not intended to be, and do not constitute, >>> advice within the meaning of Section 975 of the Dodd-Frank Wall Street >>> Reform and Consumer Protection Act. If you have received this communication >>> in error, please destroy all electronic and paper copies and notify the >>> sender immediately. Mistransmission is not intended to waive confidentiality >>> or privilege. Morgan Stanley reserves the right, to the extent permitted >>> under applicable law, to monitor electronic communications. This message is >>> subject to terms available at the following link: >>> http://www.morganstanley.com/disclaimers. If you cannot access these links, >>> please notify us by reply message and we will send the contents to you. By >>> messaging with Morgan Stanley you consent to the foregoing. >> -------------------------------------------------------------------------- >> NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing. > -------------------------------------------------------------------------- > NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.