From peter.levart at gmail.com Wed Dec 5 01:06:53 2012 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 05 Dec 2012 10:06:53 +0100 Subject: compilation failure using gcc 4.7.2 In-Reply-To: References: <5096D96E.8050503@gmail.com> <5096EC06.3060506@oracle.com> <50A46BD9.6030908@oracle.com> <50A47203.4010305@oracle.com> <50A50475.2060303@oracle.com> <50B8AB30.4040205@gmail.com> <50B8C689.6090201@oracle.com> Message-ID: <50BF0EAD.9080604@gmail.com> On 11/30/2012 04:42 PM, David Chase wrote: > You might try --with-extra-cxx-flags=-fpermissive, since it is a C++ problem, not a C problem, and maybe the scripts are that picky with their flags. > > HOWEVER, when I tried this using gcc 4.8 (because it is what I had handy, and it showed the same problem when I tried it) I got a different failure with > > Compiling /Users/dr2chase/work/hotspot-comp/hotspot/src/share/vm/memory/blockOffsetTable.cpp > Assembling /Users/dr2chase/work/hotspot-comp/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s > Compiling /Users/dr2chase/work/hotspot-comp/hotspot/src/share/vm/opto/buildOopMap.cpp > /Users/dr2chase/work/hotspot-comp/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:24:Rest of line ignored. 1st junk character valued 40 ((). > /Users/dr2chase/work/hotspot-comp/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:25:Rest of line ignored. 1st junk character valued 40 ((). > /Users/dr2chase/work/hotspot-comp/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:26:Rest of line ignored. 1st junk character valued 40 ((). > > etc. > > Line 24 of that file is: > #ifdef __APPLE__ > which contains no instances of "(" (character 40), so I am somewhat puzzled. > > This was on a Mac running Mountain Lion, everything latest.latest, but also with gcc 4.8 instead of the stock 4.2 > > I tried --with-extra-cflags=-fpermissive instead, and got the same result. > > If you have a few minutes to spend you might try the cxx flag, but with 4.7, and see if you get a happier result. > > David Hi David, I have tried using --with-extra-cxxflags=-fpermissive (not --with-extra-cxx-flags - note the last dash) and the option gets assigned to the following make variables: CXXFLAGS_JDKEXE, CXXFLAGS_JDKLIB, LEGACY_EXTRA_CXXFLAGS but unfortunately this does not fix the compilation errors (see below). It seems that -fpermissive is no good for that. Only the patch below to the binaryTreeDictionary.cpp solves the error. Regards, Peter > > > On 2012-11-30, at 9:45 AM, BILL PITTORE wrote: > >> Not familiar enough with the new build system to comment on that. As to it still failing, I wonder if the gcc doc is incorrect? Have not actually tried this myself. >> >> bill >> >> >> >> On 11/30/2012 7:48 AM, Peter Levart wrote: >>> On 11/15/2012 04:04 PM, BILL PITTORE wrote: >>>> Looks like this behavior is called out in the 4.7.2 manual as a "Known cause of trouble with GCC"; section 11.8.2 in the 4.7.2 manual. Using the -fpermissive flag forces gcc to older more permissive behavior. >>>> >>>> bill >>> Hi Bill, >>> >>> Do you know where to put this option in the new build system? >>> >>> I tried with: >>> >>> ../autoconf/configure --with-extra-cflags=-fpermissive >>> >>> and I noticed it gets put into some makefiles: >>> >>> ./build/linux-x86_64-normal-server-release/hotspot-spec.gmk: >>> >>> EXTRA_CFLAGS=-fpermissive >>> >>> ./build/linux-x86_64-normal-server-release/spec.gmk: >>> >>> # using 'configure --with-extra-cflags=-fpermissive' >>> CFLAGS_JDKLIB:= -W -Wall -Wno-unused -Wno-parentheses -pipe -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer -D_LP64=1 -D_LITTLE_ENDIAN -DLINUX -DNDEBUG -DARCH='"amd64"' -Damd64 -DRELEASE='"1.8.0-internal"' -I/home/peter/work/hg/jdk8-tl/build/linux-x86_64-normal-server-release/jdk/include -I/home/peter/work/hg/jdk8-tl/build/linux-x86_64-normal-server-release/jdk/include/linux -I/home/peter/work/hg/jdk8-tl/jdk/src/share/javavm/export -I/home/peter/work/hg/jdk8-tl/jdk/src/solaris/javavm/export -I/home/peter/work/hg/jdk8-tl/jdk/src/share/native/common -I/home/peter/work/hg/jdk8-tl/jdk/src/solaris/native/common -fpermissive -fno-strict-aliasing -fPIC >>> CFLAGS_JDKEXE:= -W -Wall -Wno-unused -Wno-parentheses -pipe -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer -D_LP64=1 -D_LITTLE_ENDIAN -DLINUX -DNDEBUG -DARCH='"amd64"' -Damd64 -DRELEASE='"1.8.0-internal"' -I/home/peter/work/hg/jdk8-tl/build/linux-x86_64-normal-server-release/jdk/include -I/home/peter/work/hg/jdk8-tl/build/linux-x86_64-normal-server-release/jdk/include/linux -I/home/peter/work/hg/jdk8-tl/jdk/src/share/javavm/export -I/home/peter/work/hg/jdk8-tl/jdk/src/solaris/javavm/export -I/home/peter/work/hg/jdk8-tl/jdk/src/share/native/common -I/home/peter/work/hg/jdk8-tl/jdk/src/solaris/native/common -fpermissive -fno-strict-aliasing >>> >>> >>> ... but I still get this error. >>> >>> Regards, Peter >>> >>>> >>>> >>>> On 11/14/2012 11:39 PM, David Holmes wrote: >>>>> On 15/11/2012 2:13 PM, Coleen Phillimore wrote: >>>>>> David, >>>>>> >>>>>> I think adding this-> to these is the best way to fix these, and we've >>>>>> been fixing similar bugs the same way. I don't think anyone preferred >>>>>> adding "using" directives, at least for this sort of compilation error. >>>>> That should have been debated when 7172226 was fixed. Personally I think adding this-> all over the place is a PITA, particularly as each tweak of gcc seems to add a need for more of them in more places. >>>>> >>>>>> I'm not sure why the compilation error exists. It seems that the >>>>>> compiler should be able to resolve these calls with the same template >>>>>> instantiation as the function, but I guess not. >>>>> I'm not going to even try and guess what a C++ compiler might or might not be able to do :) But yes it seems natural to me that given foo() the first place you look for foo() is in "this" :( But I'm not a compiler writer. ;-) >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> Coleen >>>>>> >>>>>> On 11/4/2012 5:28 PM, David Holmes wrote: >>>>>>> Hi Peter, >>>>>>> >>>>>>> I think we have lost some changes through the NPG integration. This >>>>>>> code was updated by Mikael Gerdin under: >>>>>>> >>>>>>> 7172226: HotSpot fails to build with GCC 4.7 because of stricter c++ >>>>>>> argument dependent lookup >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/diff/a297b0e14605/src/share/vm/memory/binaryTreeDictionary.cpp >>>>>>> >>>>>>> >>>>>>> but the NPG changes by Jon under >>>>>>> >>>>>>> 7045397: NPG: Add freelists to class loader arenas >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/685df3c6f84b >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/diff/685df3c6f84b/src/share/vm/memory/binaryTreeDictionary.cpp >>>>>>> >>>>>>> >>>>>>> seems to have undone those changes in part. >>>>>>> >>>>>>> The preferred fix was to add "using" directives rather than writing >>>>>>> fully-qualified names. >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 5/11/2012 7:09 AM, Peter Levart wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Current head of jdk8/hotspot repository (3790:4d37eb50b9b1) can not be >>>>>>>> built with gcc 4.7.2. >>>>>>>> >>>>>>>> I had to make the following changes to compile with gcc 4.7.2 (on >>>>>>>> linux): >>>>>>>> >>>>>>>> >>>>>>>> diff -r 4d37eb50b9b1 src/share/vm/memory/binaryTreeDictionary.cpp >>>>>>>> --- a/src/share/vm/memory/binaryTreeDictionary.cpp Thu Nov 01 14:11:16 >>>>>>>> 2012 -0700 >>>>>>>> +++ b/src/share/vm/memory/binaryTreeDictionary.cpp Sun Nov 04 22:07:29 >>>>>>>> 2012 +0100 >>>>>>>> @@ -239,7 +239,7 @@ >>>>>>>> } else { >>>>>>>> if (nextTC == NULL) { >>>>>>>> // Removing chunk at tail of list >>>>>>>> - link_tail(prevFC); >>>>>>>> + this->link_tail(prevFC); >>>>>>>> } >>>>>>>> // Chunk is interior to the list >>>>>>>> prevFC->link_after(nextTC); >>>>>>>> @@ -296,7 +296,7 @@ >>>>>>>> >>>>>>>> Chunk_t* fc = tail(); >>>>>>>> fc->link_after(chunk); >>>>>>>> - link_tail(chunk); >>>>>>>> + this->link_tail(chunk); >>>>>>>> >>>>>>>> assert(!tail() || size() == tail()->size(), "Wrong sized chunk in >>>>>>>> list"); >>>>>>>> FreeList_t::increment_count(); >>>>>>>> @@ -323,7 +323,7 @@ >>>>>>>> chunk->link_after(fc); >>>>>>>> } else { >>>>>>>> assert(tail() == NULL, "List is inconsistent"); >>>>>>>> - link_tail(chunk); >>>>>>>> + this->link_tail(chunk); >>>>>>>> } >>>>>>>> head()->link_after(chunk); >>>>>>>> assert(!head() || size() == head()->size(), "Wrong sized chunk in >>>>>>>> list"); >>>>>>>> @@ -940,7 +940,7 @@ >>>>>>>> void do_tree(TreeList* tl) { >>>>>>>> if (tl != NULL) { >>>>>>>> do_tree(tl->left()); >>>>>>>> - do_list(tl); >>>>>>>> + this->do_list(tl); >>>>>>>> do_tree(tl->right()); >>>>>>>> } >>>>>>>> } >>>>>>>> @@ -952,7 +952,7 @@ >>>>>>>> void do_tree(TreeList* tl) { >>>>>>>> if (tl != NULL) { >>>>>>>> do_tree(tl->right()); >>>>>>>> - do_list(tl); >>>>>>>> + this->do_list(tl); >>>>>>>> do_tree(tl->left()); >>>>>>>> } >>>>>>>> } >>>>>>>> @@ -1008,7 +1008,7 @@ >>>>>>>> bool do_tree(TreeList* tl) { >>>>>>>> if (tl != NULL) { >>>>>>>> if (do_tree(tl->left())) return true; >>>>>>>> - if (do_list(tl)) return true; >>>>>>>> + if (this->do_list(tl)) return true; >>>>>>>> if (do_tree(tl->right())) return true; >>>>>>>> } >>>>>>>> return false; >>>>>>>> @@ -1022,7 +1022,7 @@ >>>>>>>> bool do_tree(TreeList* tl) { >>>>>>>> if (tl != NULL) { >>>>>>>> if (do_tree(tl->right())) return true; >>>>>>>> - if (do_list(tl)) return true; >>>>>>>> + if (this->do_list(tl)) return true; >>>>>>>> if (do_tree(tl->left())) return true; >>>>>>>> } >>>>>>>> return false; >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Regards, Peter >>>>>>>> >>>> >> From coleen.phillimore at oracle.com Wed Dec 5 11:23:42 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 05 Dec 2012 14:23:42 -0500 Subject: Request for review: 7174978: NPG: Fix bactrace builder for class redefinition Message-ID: <50BF9F3E.6010906@oracle.com> Summary: Save the set of backtraces to use for on stack method walking for redefine classes. I also moved metadataOnStackMark class to it's own file because it's not only used for redefine classes. Some metadata can be individually deallocated (eg. the Method* created in the relocator). open webrev at http://cr.openjdk.java.net/~coleenp/7174978/ bug link at http://bugs.sun.com/view_bug.do?bug_id=7174978 Ran test that will be added to the jdk/tests in java/lang/instrument/RedefineMethodInBacktrace.sh (to be checked in separately). thanks, Coleen From jiangli.zhou at oracle.com Wed Dec 5 12:38:20 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 05 Dec 2012 12:38:20 -0800 Subject: Request for review: 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing Message-ID: <50BFB0BC.7060809@oracle.com> Hi Coleen and others, Please review the webrev for moving the Method::_max_locals and Method::_size_of_parameters to ConstMethod: http://cr.openjdk.java.net/~jiangli/8004076/webrev.00/ Tested with jprt, runthese and vm.quick.testlist. No noticeable performance impact with the change. ============================================================================== logs.maxlocal_baseline.spec.1: Benchmark Samples Mean Stdev Geomean Weight specjvm98 8 546.91 12.58 ============================================================================== logs.maxlocal.spec.1: Benchmark Samples Mean Stdev %Diff P Significant specjvm98 8 547.44 12.13 0.10 0.933 * ============================================================================== ============================================================================== logs.maxlocal_baseline.jbb: Benchmark Samples Mean Stdev Geomean Weight specjbb2005 3 56898.90 481.78 ============================================================================== logs.maxlocal.jbb: Benchmark Samples Mean Stdev %Diff P Significant specjbb2005 3 56901.46 613.98 0.00 0.996 * ============================================================================== Thanks, Jiangli From coleen.phillimore at oracle.com Wed Dec 5 14:01:20 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 05 Dec 2012 17:01:20 -0500 Subject: Request for review: 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing In-Reply-To: <50BFB0BC.7060809@oracle.com> References: <50BFB0BC.7060809@oracle.com> Message-ID: <50BFC430.6030201@oracle.com> Hi Jiangli, This looks great! It's also bug 6329051. I had two questions. Can you run -Xshare:dump on 64 bits to see if the SharedReadOnly size is still big enough? JPRT will run -Xshare:dump for you on 32 bit platforms. The other is there is strange indentation in vmStructs around the lines you changed in the webrev, which may or may not be an unintended change. Thanks! Coleen On 12/5/2012 3:38 PM, Jiangli Zhou wrote: > Hi Coleen and others, > > Please review the webrev for moving the Method::_max_locals and > Method::_size_of_parameters to ConstMethod: > > http://cr.openjdk.java.net/~jiangli/8004076/webrev.00/ > > Tested with jprt, runthese and vm.quick.testlist. No noticeable > performance impact with the change. > > ============================================================================== > > logs.maxlocal_baseline.spec.1: > Benchmark Samples Mean Stdev Geomean Weight > specjvm98 8 546.91 12.58 > ============================================================================== > > logs.maxlocal.spec.1: > Benchmark Samples Mean Stdev %Diff P > Significant > specjvm98 8 547.44 12.13 0.10 > 0.933 * > ============================================================================== > > > ============================================================================== > > logs.maxlocal_baseline.jbb: > Benchmark Samples Mean Stdev Geomean Weight > specjbb2005 3 56898.90 481.78 > ============================================================================== > > logs.maxlocal.jbb: > Benchmark Samples Mean Stdev %Diff P > Significant > specjbb2005 3 56901.46 613.98 0.00 > 0.996 * > ============================================================================== > > > Thanks, > Jiangli From jiangli.zhou at oracle.com Wed Dec 5 14:13:19 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 05 Dec 2012 14:13:19 -0800 Subject: Request for review: 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing In-Reply-To: <50BFC430.6030201@oracle.com> References: <50BFB0BC.7060809@oracle.com> <50BFC430.6030201@oracle.com> Message-ID: <50BFC6FF.5020400@oracle.com> Hi Coleen, Thanks for the review and bug id. Will try -Xshare:dump on 64 bits. For the indentation change in vmStructs.cpp, were you referring to line 379 & 380? They follows the other defines for ConstMethod. Or maybe you were referring to different lines? Thanks, Jiangli On 12/05/2012 02:01 PM, Coleen Phillimore wrote: > > Hi Jiangli, > This looks great! It's also bug 6329051. I had two questions. > Can you run -Xshare:dump on 64 bits to see if the SharedReadOnly size > is still big enough? JPRT will run -Xshare:dump for you on 32 bit > platforms. The other is there is strange indentation in vmStructs > around the lines you changed in the webrev, which may or may not be an > unintended change. > > Thanks! > Coleen > > On 12/5/2012 3:38 PM, Jiangli Zhou wrote: >> Hi Coleen and others, >> >> Please review the webrev for moving the Method::_max_locals and >> Method::_size_of_parameters to ConstMethod: >> >> http://cr.openjdk.java.net/~jiangli/8004076/webrev.00/ >> >> Tested with jprt, runthese and vm.quick.testlist. No noticeable >> performance impact with the change. >> >> ============================================================================== >> >> logs.maxlocal_baseline.spec.1: >> Benchmark Samples Mean Stdev Geomean Weight >> specjvm98 8 546.91 12.58 >> ============================================================================== >> >> logs.maxlocal.spec.1: >> Benchmark Samples Mean Stdev %Diff P >> Significant >> specjvm98 8 547.44 12.13 0.10 >> 0.933 * >> ============================================================================== >> >> >> ============================================================================== >> >> logs.maxlocal_baseline.jbb: >> Benchmark Samples Mean Stdev Geomean Weight >> specjbb2005 3 56898.90 481.78 >> ============================================================================== >> >> logs.maxlocal.jbb: >> Benchmark Samples Mean Stdev %Diff P >> Significant >> specjbb2005 3 56901.46 613.98 0.00 >> 0.996 * >> ============================================================================== >> >> >> Thanks, >> Jiangli > From coleen.phillimore at oracle.com Thu Dec 6 08:15:18 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 06 Dec 2012 11:15:18 -0500 Subject: Request for review: 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing In-Reply-To: <50BFC6FF.5020400@oracle.com> References: <50BFB0BC.7060809@oracle.com> <50BFC430.6030201@oracle.com> <50BFC6FF.5020400@oracle.com> Message-ID: <50C0C496.8070404@oracle.com> On 12/05/2012 05:13 PM, Jiangli Zhou wrote: > Hi Coleen, > > Thanks for the review and bug id. Will try -Xshare:dump on 64 bits. > For the indentation change in vmStructs.cpp, were you referring to > line 379 & 380? They follows the other defines for ConstMethod. Or > maybe you were referring to different lines? The indentation is fine. Sorry for the noise. Coleen > > Thanks, > Jiangli > > On 12/05/2012 02:01 PM, Coleen Phillimore wrote: >> >> Hi Jiangli, >> This looks great! It's also bug 6329051. I had two questions. >> Can you run -Xshare:dump on 64 bits to see if the SharedReadOnly size >> is still big enough? JPRT will run -Xshare:dump for you on 32 bit >> platforms. The other is there is strange indentation in vmStructs >> around the lines you changed in the webrev, which may or may not be >> an unintended change. >> >> Thanks! >> Coleen >> >> On 12/5/2012 3:38 PM, Jiangli Zhou wrote: >>> Hi Coleen and others, >>> >>> Please review the webrev for moving the Method::_max_locals and >>> Method::_size_of_parameters to ConstMethod: >>> >>> http://cr.openjdk.java.net/~jiangli/8004076/webrev.00/ >>> >>> Tested with jprt, runthese and vm.quick.testlist. No noticeable >>> performance impact with the change. >>> >>> ============================================================================== >>> >>> logs.maxlocal_baseline.spec.1: >>> Benchmark Samples Mean Stdev Geomean Weight >>> specjvm98 8 546.91 12.58 >>> ============================================================================== >>> >>> logs.maxlocal.spec.1: >>> Benchmark Samples Mean Stdev %Diff P >>> Significant >>> specjvm98 8 547.44 12.13 0.10 >>> 0.933 * >>> ============================================================================== >>> >>> >>> ============================================================================== >>> >>> logs.maxlocal_baseline.jbb: >>> Benchmark Samples Mean Stdev Geomean Weight >>> specjbb2005 3 56898.90 481.78 >>> ============================================================================== >>> >>> logs.maxlocal.jbb: >>> Benchmark Samples Mean Stdev %Diff P >>> Significant >>> specjbb2005 3 56901.46 613.98 0.00 >>> 0.996 * >>> ============================================================================== >>> >>> >>> Thanks, >>> Jiangli >> > From jiangli.zhou at oracle.com Thu Dec 6 09:51:56 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 06 Dec 2012 09:51:56 -0800 Subject: Request for review: 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing In-Reply-To: <50C0C496.8070404@oracle.com> References: <50BFB0BC.7060809@oracle.com> <50BFC430.6030201@oracle.com> <50BFC6FF.5020400@oracle.com> <50C0C496.8070404@oracle.com> Message-ID: <50C0DB3C.80508@oracle.com> Hi Coleen, Thanks! Jiangli On 12/06/2012 08:15 AM, Coleen Phillimore wrote: > > On 12/05/2012 05:13 PM, Jiangli Zhou wrote: >> Hi Coleen, >> >> Thanks for the review and bug id. Will try -Xshare:dump on 64 bits. >> For the indentation change in vmStructs.cpp, were you referring to >> line 379 & 380? They follows the other defines for ConstMethod. Or >> maybe you were referring to different lines? > > The indentation is fine. Sorry for the noise. > Coleen > >> >> Thanks, >> Jiangli >> >> On 12/05/2012 02:01 PM, Coleen Phillimore wrote: >>> >>> Hi Jiangli, >>> This looks great! It's also bug 6329051. I had two questions. >>> Can you run -Xshare:dump on 64 bits to see if the SharedReadOnly >>> size is still big enough? JPRT will run -Xshare:dump for you on 32 >>> bit platforms. The other is there is strange indentation in >>> vmStructs around the lines you changed in the webrev, which may or >>> may not be an unintended change. >>> >>> Thanks! >>> Coleen >>> >>> On 12/5/2012 3:38 PM, Jiangli Zhou wrote: >>>> Hi Coleen and others, >>>> >>>> Please review the webrev for moving the Method::_max_locals and >>>> Method::_size_of_parameters to ConstMethod: >>>> >>>> http://cr.openjdk.java.net/~jiangli/8004076/webrev.00/ >>>> >>>> Tested with jprt, runthese and vm.quick.testlist. No noticeable >>>> performance impact with the change. >>>> >>>> ============================================================================== >>>> >>>> logs.maxlocal_baseline.spec.1: >>>> Benchmark Samples Mean Stdev Geomean Weight >>>> specjvm98 8 546.91 12.58 >>>> ============================================================================== >>>> >>>> logs.maxlocal.spec.1: >>>> Benchmark Samples Mean Stdev %Diff P >>>> Significant >>>> specjvm98 8 547.44 12.13 0.10 >>>> 0.933 * >>>> ============================================================================== >>>> >>>> >>>> ============================================================================== >>>> >>>> logs.maxlocal_baseline.jbb: >>>> Benchmark Samples Mean Stdev Geomean Weight >>>> specjbb2005 3 56898.90 481.78 >>>> ============================================================================== >>>> >>>> logs.maxlocal.jbb: >>>> Benchmark Samples Mean Stdev %Diff P >>>> Significant >>>> specjbb2005 3 56901.46 613.98 0.00 >>>> 0.996 * >>>> ============================================================================== >>>> >>>> >>>> Thanks, >>>> Jiangli >>> >> > From jiangli.zhou at oracle.com Thu Dec 6 12:05:10 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 06 Dec 2012 12:05:10 -0800 Subject: Request for review: 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing In-Reply-To: <50BFC6FF.5020400@oracle.com> References: <50BFB0BC.7060809@oracle.com> <50BFC430.6030201@oracle.com> <50BFC6FF.5020400@oracle.com> Message-ID: <50C0FA76.1050705@oracle.com> Hi Coleen, The RO space looks ok on 64bit machine: % bin/java -Xshare:dump Loading classes to share ... done. Rewriting and linking classes ... done. Number of classes 2454 Calculating fingerprints ... done. Removing unshareable information ... done. ro space: 0x0019c978 out of 0x00300000 words allocated at 0x10000000. rw space: 0x001a8c1c out of 0x00300000 words allocated at 0x10c00000. md space: 0x000ba574 out of 0x00200000 words allocated at 0x11800000. mc space: 0x000084f2 out of 0x0001e000 words allocated at 0x11a00000. Thanks, Jiangli On 12/05/2012 02:13 PM, Jiangli Zhou wrote: > Hi Coleen, > > Thanks for the review and bug id. Will try -Xshare:dump on 64 bits. > For the indentation change in vmStructs.cpp, were you referring to > line 379 & 380? They follows the other defines for ConstMethod. Or > maybe you were referring to different lines? > > Thanks, > Jiangli > > On 12/05/2012 02:01 PM, Coleen Phillimore wrote: >> >> Hi Jiangli, >> This looks great! It's also bug 6329051. I had two questions. >> Can you run -Xshare:dump on 64 bits to see if the SharedReadOnly size >> is still big enough? JPRT will run -Xshare:dump for you on 32 bit >> platforms. The other is there is strange indentation in vmStructs >> around the lines you changed in the webrev, which may or may not be >> an unintended change. >> >> Thanks! >> Coleen >> >> On 12/5/2012 3:38 PM, Jiangli Zhou wrote: >>> Hi Coleen and others, >>> >>> Please review the webrev for moving the Method::_max_locals and >>> Method::_size_of_parameters to ConstMethod: >>> >>> http://cr.openjdk.java.net/~jiangli/8004076/webrev.00/ >>> >>> Tested with jprt, runthese and vm.quick.testlist. No noticeable >>> performance impact with the change. >>> >>> ============================================================================== >>> >>> logs.maxlocal_baseline.spec.1: >>> Benchmark Samples Mean Stdev Geomean Weight >>> specjvm98 8 546.91 12.58 >>> ============================================================================== >>> >>> logs.maxlocal.spec.1: >>> Benchmark Samples Mean Stdev %Diff P >>> Significant >>> specjvm98 8 547.44 12.13 0.10 >>> 0.933 * >>> ============================================================================== >>> >>> >>> ============================================================================== >>> >>> logs.maxlocal_baseline.jbb: >>> Benchmark Samples Mean Stdev Geomean Weight >>> specjbb2005 3 56898.90 481.78 >>> ============================================================================== >>> >>> logs.maxlocal.jbb: >>> Benchmark Samples Mean Stdev %Diff P >>> Significant >>> specjbb2005 3 56901.46 613.98 0.00 >>> 0.996 * >>> ============================================================================== >>> >>> >>> Thanks, >>> Jiangli >> > From stefan.karlsson at oracle.com Thu Dec 6 13:56:52 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 06 Dec 2012 22:56:52 +0100 Subject: RFR (XS): Add necessary .inline.hpp files to fix non-PCH build In-Reply-To: References: Message-ID: <50C114A4.7070406@oracle.com> Hi Volker, Bug created: JDK-8004674 Thanks for fixing this. Your patch looks good. Though, I think it's unfortunate that we have to add allocation.inline.hpp whenever this 'new' is used. Can someone who's an official Reviewer also review this? StefanK On 2012-11-30 19:51, Volker Simonis wrote: > Hi, > > I'm currently working on "6889002 : CHECK macros in return constructs > lead to unreachable code" and just realized that the non-PCH build on > Linux is broken (once again). > > The failure manifests itself with a "libjvm.so: undefined reference to > `CHeapObj<(unsigned short)1280>::operator new(unsigned long, unsigned > char*)'" which is caused by the recent "6995781: Native memory > Tracking" change. The problem is that "operator new" is called in the > files "gc_implementation/parallelScavenge/adjoiningVirtualSpaces.cpp" > and "gc_implementation/shared/gcStats.cpp" for classes which have the > template class "CHeapObj" as their base class. CHeapObj defines its > own "new" operator in "memory/allocation.inline.hpp" but this > inline.hpp file is not included into > "gc_implementation/parallelScavenge/adjoiningVirtualSpaces.cpp" and > "gc_implementation/shared/gcStats.cpp". > > Funny enough, the problem doesn't seem to appear neither for older > version of GCC (e.g. 4.4.6 on SLES 10) nor in debug builds. I could > only reproduce it with a product build on Ubuntu 12.04 with GCC 4.6.3. > The reason is most probably the fact that newer versions of GCC create > template instantiations in a much more lazy way. > > The fix is easy - just add the missing includes to the corresponding > files (see attached patch). > Could somebody please open a bug for this issue and review/commit the change. > > Please notice that this actually not exactly the annoying "inline.hpp" > problem which will be addressed with "8003990: Clean up inline > #includes" but very similar because template definition and > instantiation have similar semantics. This only didn't caused any > problems until now because templates have been used very little in > HotSpot. However once this changes, special care has to be taken to > manage them in a way every compiler can cope with. > > Thank you and best regards, > Volker From john.coomes at oracle.com Thu Dec 6 20:44:19 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Dec 2012 04:44:19 +0000 Subject: hg: hsx/hotspot-emb: 6 new changesets Message-ID: <20121207044420.0E36047F94@hg.openjdk.java.net> Changeset: 98a7af257bee Author: erikj Date: 2012-12-03 10:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/98a7af257bee 8003819: build-infra: backslashes at end of LIB and INCLUDE in spec.gmk Summary: Removing trailing backslash from LIB and INCLUDE. Reviewed-by: ohrstrom, ohair ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain_windows.m4 Changeset: 754f91d22e1c Author: erikj Date: 2012-12-05 09:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/754f91d22e1c 8001541: Cannot build on Solaris using softlinks Summary: Fixed softlink resolver macro in configure. Reviewed-by: tbell, ohair ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: ec187d02c95e Author: erikj Date: 2012-12-05 10:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/ec187d02c95e 8004281: build-infra: Move all jar creation to images target and put jars in images/lib Summary: Fixed bug in setting up make dependencies in SetupArchive. Reviewed-by: ohair, tbell, dholmes ! common/makefiles/JavaCompilation.gmk Changeset: bd32ef0789ca Author: erikj Date: 2012-12-05 16:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/bd32ef0789ca 8003414: build-infra: fails on on windows Summary: Added extra check that windows sdk is valid. Reviewed-by: tbell, ohrstrom, ohair ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain_windows.m4 Changeset: 9a6ec97ec45c Author: katleman Date: 2012-12-05 12:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/9a6ec97ec45c Merge Changeset: c91c581321ce Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/c91c581321ce Added tag jdk8-b67 for changeset 9a6ec97ec45c ! .hgtags From john.coomes at oracle.com Thu Dec 6 20:44:25 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Dec 2012 04:44:25 +0000 Subject: hg: hsx/hotspot-emb/corba: Added tag jdk8-b67 for changeset 394515ad2a55 Message-ID: <20121207044428.0A4D647F95@hg.openjdk.java.net> Changeset: 82000531feaa Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/82000531feaa Added tag jdk8-b67 for changeset 394515ad2a55 ! .hgtags From john.coomes at oracle.com Thu Dec 6 20:44:32 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Dec 2012 04:44:32 +0000 Subject: hg: hsx/hotspot-emb/jaxp: Added tag jdk8-b67 for changeset 83df3493ca3c Message-ID: <20121207044440.9996547F96@hg.openjdk.java.net> Changeset: b854e7008421 Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/b854e7008421 Added tag jdk8-b67 for changeset 83df3493ca3c ! .hgtags From john.coomes at oracle.com Thu Dec 6 20:44:45 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Dec 2012 04:44:45 +0000 Subject: hg: hsx/hotspot-emb/jaxws: Added tag jdk8-b67 for changeset eb06aa51dfc2 Message-ID: <20121207044451.B693B47F97@hg.openjdk.java.net> Changeset: d3fe408f3a9a Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/d3fe408f3a9a Added tag jdk8-b67 for changeset eb06aa51dfc2 ! .hgtags From john.coomes at oracle.com Thu Dec 6 20:45:00 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Dec 2012 04:45:00 +0000 Subject: hg: hsx/hotspot-emb/jdk: 4 new changesets Message-ID: <20121207044628.2028747F98@hg.openjdk.java.net> Changeset: b0f008ab45d7 Author: twisti Date: 2012-11-30 11:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/b0f008ab45d7 8001885: JSR 292 classes should use jdk.internal.org.objectweb.asm Reviewed-by: kvn, jrose, twisti Contributed-by: David Chase ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Changeset: 0fda013e4638 Author: erikj Date: 2012-12-05 10:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/0fda013e4638 8004281: build-infra: Move all jar creation to images target and put jars in images/lib Reviewed-by: ohair, tbell, dholmes ! makefiles/CompileDemos.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/Images.gmk ! makefiles/Import.gmk Changeset: ce9b02a3a17e Author: katleman Date: 2012-12-05 12:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/ce9b02a3a17e Merge Changeset: ea0d3a9d0d01 Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/ea0d3a9d0d01 Added tag jdk8-b67 for changeset ce9b02a3a17e ! .hgtags From john.coomes at oracle.com Thu Dec 6 20:47:44 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Dec 2012 04:47:44 +0000 Subject: hg: hsx/hotspot-emb/langtools: Added tag jdk8-b67 for changeset 303b09787a69 Message-ID: <20121207044753.D798647F99@hg.openjdk.java.net> Changeset: e9a13a6c9d5d Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/e9a13a6c9d5d Added tag jdk8-b67 for changeset 303b09787a69 ! .hgtags From john.coomes at oracle.com Thu Dec 6 20:57:47 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Dec 2012 04:57:47 +0000 Subject: hg: hsx/hotspot-rt: 6 new changesets Message-ID: <20121207045748.1BF6147FA0@hg.openjdk.java.net> Changeset: 98a7af257bee Author: erikj Date: 2012-12-03 10:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/98a7af257bee 8003819: build-infra: backslashes at end of LIB and INCLUDE in spec.gmk Summary: Removing trailing backslash from LIB and INCLUDE. Reviewed-by: ohrstrom, ohair ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain_windows.m4 Changeset: 754f91d22e1c Author: erikj Date: 2012-12-05 09:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/754f91d22e1c 8001541: Cannot build on Solaris using softlinks Summary: Fixed softlink resolver macro in configure. Reviewed-by: tbell, ohair ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: ec187d02c95e Author: erikj Date: 2012-12-05 10:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/ec187d02c95e 8004281: build-infra: Move all jar creation to images target and put jars in images/lib Summary: Fixed bug in setting up make dependencies in SetupArchive. Reviewed-by: ohair, tbell, dholmes ! common/makefiles/JavaCompilation.gmk Changeset: bd32ef0789ca Author: erikj Date: 2012-12-05 16:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/bd32ef0789ca 8003414: build-infra: fails on on windows Summary: Added extra check that windows sdk is valid. Reviewed-by: tbell, ohrstrom, ohair ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain_windows.m4 Changeset: 9a6ec97ec45c Author: katleman Date: 2012-12-05 12:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/9a6ec97ec45c Merge Changeset: c91c581321ce Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/c91c581321ce Added tag jdk8-b67 for changeset 9a6ec97ec45c ! .hgtags From john.coomes at oracle.com Thu Dec 6 20:57:52 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Dec 2012 04:57:52 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b67 for changeset 394515ad2a55 Message-ID: <20121207045754.B91F647FA1@hg.openjdk.java.net> Changeset: 82000531feaa Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/82000531feaa Added tag jdk8-b67 for changeset 394515ad2a55 ! .hgtags From john.coomes at oracle.com Thu Dec 6 20:57:59 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Dec 2012 04:57:59 +0000 Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b67 for changeset 83df3493ca3c Message-ID: <20121207045808.BA7D447FA2@hg.openjdk.java.net> Changeset: b854e7008421 Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/b854e7008421 Added tag jdk8-b67 for changeset 83df3493ca3c ! .hgtags From john.coomes at oracle.com Thu Dec 6 20:58:13 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Dec 2012 04:58:13 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b67 for changeset eb06aa51dfc2 Message-ID: <20121207045818.CEFEF47FA3@hg.openjdk.java.net> Changeset: d3fe408f3a9a Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/d3fe408f3a9a Added tag jdk8-b67 for changeset eb06aa51dfc2 ! .hgtags From john.coomes at oracle.com Thu Dec 6 20:58:27 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Dec 2012 04:58:27 +0000 Subject: hg: hsx/hotspot-rt/jdk: 4 new changesets Message-ID: <20121207045954.50A5547FA4@hg.openjdk.java.net> Changeset: b0f008ab45d7 Author: twisti Date: 2012-11-30 11:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b0f008ab45d7 8001885: JSR 292 classes should use jdk.internal.org.objectweb.asm Reviewed-by: kvn, jrose, twisti Contributed-by: David Chase ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Changeset: 0fda013e4638 Author: erikj Date: 2012-12-05 10:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0fda013e4638 8004281: build-infra: Move all jar creation to images target and put jars in images/lib Reviewed-by: ohair, tbell, dholmes ! makefiles/CompileDemos.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/Images.gmk ! makefiles/Import.gmk Changeset: ce9b02a3a17e Author: katleman Date: 2012-12-05 12:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ce9b02a3a17e Merge Changeset: ea0d3a9d0d01 Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ea0d3a9d0d01 Added tag jdk8-b67 for changeset ce9b02a3a17e ! .hgtags From john.coomes at oracle.com Thu Dec 6 21:01:07 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 Dec 2012 05:01:07 +0000 Subject: hg: hsx/hotspot-rt/langtools: Added tag jdk8-b67 for changeset 303b09787a69 Message-ID: <20121207050116.8F2DF47FA5@hg.openjdk.java.net> Changeset: e9a13a6c9d5d Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/e9a13a6c9d5d Added tag jdk8-b67 for changeset 303b09787a69 ! .hgtags From jiangli.zhou at oracle.com Fri Dec 7 13:45:14 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 07 Dec 2012 13:45:14 -0800 Subject: Request for review: 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing In-Reply-To: <50BFB0BC.7060809@oracle.com> References: <50BFB0BC.7060809@oracle.com> Message-ID: <50C2636A.8090401@oracle.com> Hi, Could I have another reviewer for the change? Either official or non-official reviewer is okay. Thanks in advance. Jiangli On 12/05/2012 12:38 PM, Jiangli Zhou wrote: > Hi Coleen and others, > > Please review the webrev for moving the Method::_max_locals and > Method::_size_of_parameters to ConstMethod: > > http://cr.openjdk.java.net/~jiangli/8004076/webrev.00/ > > Tested with jprt, runthese and vm.quick.testlist. No noticeable > performance impact with the change. > > ============================================================================== > > logs.maxlocal_baseline.spec.1: > Benchmark Samples Mean Stdev > Geomean Weight > specjvm98 8 546.91 12.58 > ============================================================================== > > logs.maxlocal.spec.1: > Benchmark Samples Mean Stdev %Diff P > Significant > specjvm98 8 547.44 12.13 0.10 > 0.933 * > ============================================================================== > > > ============================================================================== > > logs.maxlocal_baseline.jbb: > Benchmark Samples Mean Stdev > Geomean Weight > specjbb2005 3 56898.90 481.78 > ============================================================================== > > logs.maxlocal.jbb: > Benchmark Samples Mean Stdev %Diff P > Significant > specjbb2005 3 56901.46 613.98 0.00 > 0.996 * > ============================================================================== > > > Thanks, > Jiangli From yumin.qi at oracle.com Fri Dec 7 14:20:16 2012 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 07 Dec 2012 14:20:16 -0800 Subject: Request for review: 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing In-Reply-To: <50C2636A.8090401@oracle.com> References: <50BFB0BC.7060809@oracle.com> <50C2636A.8090401@oracle.com> Message-ID: <50C26BA0.4090503@oracle.com> Jiangli, Looks good -- my id is 'minqi' on openjdk Thanks Yumin On 12/7/2012 1:45 PM, Jiangli Zhou wrote: > Hi, > > Could I have another reviewer for the change? Either official or > non-official reviewer is okay. > > Thanks in advance. > > Jiangli > > On 12/05/2012 12:38 PM, Jiangli Zhou wrote: >> Hi Coleen and others, >> >> Please review the webrev for moving the Method::_max_locals and >> Method::_size_of_parameters to ConstMethod: >> >> http://cr.openjdk.java.net/~jiangli/8004076/webrev.00/ >> >> Tested with jprt, runthese and vm.quick.testlist. No noticeable >> performance impact with the change. >> >> ============================================================================== >> >> logs.maxlocal_baseline.spec.1: >> Benchmark Samples Mean Stdev >> Geomean Weight >> specjvm98 8 546.91 12.58 >> ============================================================================== >> >> logs.maxlocal.spec.1: >> Benchmark Samples Mean Stdev %Diff P >> Significant >> specjvm98 8 547.44 12.13 0.10 >> 0.933 * >> ============================================================================== >> >> >> ============================================================================== >> >> logs.maxlocal_baseline.jbb: >> Benchmark Samples Mean Stdev >> Geomean Weight >> specjbb2005 3 56898.90 481.78 >> ============================================================================== >> >> logs.maxlocal.jbb: >> Benchmark Samples Mean Stdev %Diff P >> Significant >> specjbb2005 3 56901.46 613.98 0.00 >> 0.996 * >> ============================================================================== >> >> >> Thanks, >> Jiangli > From john.r.rose at oracle.com Fri Dec 7 14:40:46 2012 From: john.r.rose at oracle.com (John Rose) Date: Fri, 7 Dec 2012 14:40:46 -0800 Subject: Request for review: 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing In-Reply-To: <50C2636A.8090401@oracle.com> References: <50BFB0BC.7060809@oracle.com> <50C2636A.8090401@oracle.com> Message-ID: <75AA2E86-8884-441C-B3E7-E4082807A1CD@oracle.com> On Dec 7, 2012, at 1:45 PM, Jiangli Zhou wrote: > Could I have another reviewer for the change? Either official or non-official reviewer is okay. I have a comment on this one. (And you can use me as a reviewer.) In the sparc code, I would prefer to see the Address constants kept around, because they make the code easier to read. - const Address size_of_parameters(G5_method, Method::size_of_parameters_offset()); - const Address size_of_locals (G5_method, Method::size_of_locals_offset()); + const Register G3_constMethod = Glocals_size; + const Address size_of_parameters(G3_ConstMethod, ConstMethod::size_of_parameters_offset()); + const Address size_of_locals (G3_ConstMethod, ConstMethod::size_of_locals_offset()); const Address constMethod (G5_method, Method::const_offset()); int rounded_vm_local_words = round_to( frame::interpreter_frame_vm_local_words, WordsPerLong ); @@ -511,7 +509,8 @@ // Lscratch can't be used as a temporary because the call_stub uses // it to assert that the stack frame was setup correctly. + __ ld_ptr( constMethod, G3_constMethod ); - __ lduh( size_of_parameters, Glocals_size); Maybe the details make it difficult, but I think it's possible in most places. As a side effect, using a fixed register (like G3) for the ConstMethod will make debugging easier. Same comment for x86/64. This may be more difficult to do on x86/32, since there are fewer temp registers. But that's an oddball case. Thanks, ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121207/046313a1/attachment.html From jiangli.zhou at oracle.com Fri Dec 7 14:41:15 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 07 Dec 2012 14:41:15 -0800 Subject: Request for review: 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing In-Reply-To: <50C26BA0.4090503@oracle.com> References: <50BFB0BC.7060809@oracle.com> <50C2636A.8090401@oracle.com> <50C26BA0.4090503@oracle.com> Message-ID: <50C2708B.3070503@oracle.com> Thanks a lot, Yumin! Jiangli On 12/07/2012 02:20 PM, Yumin Qi wrote: > Jiangli, > > Looks good -- my id is 'minqi' on openjdk > > Thanks > Yumin > > On 12/7/2012 1:45 PM, Jiangli Zhou wrote: >> Hi, >> >> Could I have another reviewer for the change? Either official or >> non-official reviewer is okay. >> >> Thanks in advance. >> >> Jiangli >> >> On 12/05/2012 12:38 PM, Jiangli Zhou wrote: >>> Hi Coleen and others, >>> >>> Please review the webrev for moving the Method::_max_locals and >>> Method::_size_of_parameters to ConstMethod: >>> >>> http://cr.openjdk.java.net/~jiangli/8004076/webrev.00/ >>> >>> Tested with jprt, runthese and vm.quick.testlist. No noticeable >>> performance impact with the change. >>> >>> ============================================================================== >>> >>> logs.maxlocal_baseline.spec.1: >>> Benchmark Samples Mean Stdev >>> Geomean Weight >>> specjvm98 8 546.91 12.58 >>> ============================================================================== >>> >>> logs.maxlocal.spec.1: >>> Benchmark Samples Mean Stdev %Diff P >>> Significant >>> specjvm98 8 547.44 12.13 0.10 >>> 0.933 * >>> ============================================================================== >>> >>> >>> ============================================================================== >>> >>> logs.maxlocal_baseline.jbb: >>> Benchmark Samples Mean Stdev >>> Geomean Weight >>> specjbb2005 3 56898.90 481.78 >>> ============================================================================== >>> >>> logs.maxlocal.jbb: >>> Benchmark Samples Mean Stdev %Diff P >>> Significant >>> specjbb2005 3 56901.46 613.98 0.00 >>> 0.996 * >>> ============================================================================== >>> >>> >>> Thanks, >>> Jiangli >> From alejandro.murillo at oracle.com Fri Dec 7 14:45:54 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 07 Dec 2012 22:45:54 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 22 new changesets Message-ID: <20121207224646.9386347FCA@hg.openjdk.java.net> Changeset: 10587a580c51 Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/10587a580c51 Added tag jdk8-b67 for changeset 25bdce771bb3 ! .hgtags Changeset: 7cc69864a29b Author: kvn Date: 2012-11-16 15:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/7cc69864a29b 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum Summary: Increase the stack size in the run parameters. Reviewed-by: kvn Contributed-by: david.r.chase at oracle.com ! test/compiler/6865265/StackOverflowBug.java Changeset: ee32440febeb Author: vlivanov Date: 2012-11-21 05:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/ee32440febeb 8001538: hs_err file does not list anymore compiled methods in compilation events Summary: Fixed message buffer size calculation. Reviewed-by: kvn, twisti ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/utilities/events.hpp Changeset: beebba0acc11 Author: twisti Date: 2012-11-26 17:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/beebba0acc11 7172640: C2: instrinsic implementations in LibraryCallKit should use argument() instead of pop() Reviewed-by: kvn, jrose ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/type.hpp Changeset: 2cd5e15048e6 Author: twisti Date: 2012-11-27 12:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/2cd5e15048e6 8003868: fix shark for latest HotSpot and LLVM Reviewed-by: twisti Contributed-by: Roman Kennke ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/assembler_zero.hpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/globals_zero.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/shark/llvmHeaders.hpp ! src/share/vm/shark/llvmValue.hpp ! src/share/vm/shark/sharkBlock.cpp ! src/share/vm/shark/sharkBuilder.cpp ! src/share/vm/shark/sharkBuilder.hpp ! src/share/vm/shark/sharkCacheDecache.cpp ! src/share/vm/shark/sharkCacheDecache.hpp ! src/share/vm/shark/sharkCodeBuffer.hpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkConstant.cpp ! src/share/vm/shark/sharkContext.cpp ! src/share/vm/shark/sharkContext.hpp ! src/share/vm/shark/sharkFunction.hpp ! src/share/vm/shark/sharkIntrinsics.cpp ! src/share/vm/shark/sharkMemoryManager.cpp ! src/share/vm/shark/sharkMemoryManager.hpp ! src/share/vm/shark/sharkNativeWrapper.cpp ! src/share/vm/shark/sharkStack.cpp ! src/share/vm/shark/sharkStack.hpp ! src/share/vm/shark/sharkState.cpp ! src/share/vm/shark/sharkTopLevelBlock.cpp ! src/share/vm/shark/sharkTopLevelBlock.hpp ! src/share/vm/shark/sharkType.hpp ! src/share/vm/shark/sharkValue.cpp ! src/share/vm/shark/shark_globals.hpp Changeset: 2aff40cb4703 Author: bharadwaj Date: 2012-11-27 17:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/2aff40cb4703 7092905: C2: Keep track of the number of dead nodes Summary: keep an (almost) accurate running count of the reachable (live) flow graph nodes. Reviewed-by: kvn, twisti, jrose, vlivanov ! src/share/tools/LogCompilation/README ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/CallSite.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCompilation.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/Phase.java ! src/share/vm/opto/block.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/stringopts.cpp Changeset: 1acccb7c0b01 Author: kvn Date: 2012-11-27 17:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/1acccb7c0b01 8003850: add support for constants in stub code Summary: remember the code section and switch back to the proper one when adding constants. Reviewed-by: twisti, kvn Contributed-by: goetz.lindenmaier at sap.com ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/codeBuffer.cpp Changeset: 6ab62ad83507 Author: twisti Date: 2012-11-30 11:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/6ab62ad83507 8003195: AbstractAssembler should not store code pointers but use the CodeSection directly Reviewed-by: twisti, kvn Contributed-by: Bharadwaj Yadavalli ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/assembler_x86.inline.hpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/assembler.inline.hpp ! src/share/vm/asm/codeBuffer.hpp Changeset: cd3d6a6b95d9 Author: twisti Date: 2012-11-30 15:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/cd3d6a6b95d9 8003240: x86: move MacroAssembler into separate file Reviewed-by: kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/codeBuffer_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/assembler_x86.inline.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/icBuffer_x86.cpp ! src/cpu/x86/vm/icache_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/jniFastGetField_x86_32.cpp ! src/cpu/x86/vm/jniFastGetField_x86_64.cpp + src/cpu/x86/vm/macroAssembler_x86.cpp + src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/metaspaceShared_x86_32.cpp ! src/cpu/x86/vm/metaspaceShared_x86_64.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.cpp ! src/cpu/x86/vm/relocInfo_x86.cpp ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/runtime_x86_64.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/os/bsd/vm/osThread_bsd.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/osThread_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/solaris/vm/osThread_solaris.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/vm/osThread_windows.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.inline.hpp ! src/os_cpu/bsd_x86/vm/assembler_bsd_x86.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/assembler.inline.hpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp + src/share/vm/asm/macroAssembler.hpp + src/share/vm/asm/macroAssembler.inline.hpp ! src/share/vm/c1/c1_MacroAssembler.hpp ! src/share/vm/code/icBuffer.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/atomic.hpp + src/share/vm/runtime/atomic.inline.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/stubCodeGenerator.cpp Changeset: dd38cfd12c3a Author: twisti Date: 2012-12-03 15:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/dd38cfd12c3a 8004319: test/gc/7168848/HumongousAlloc.java fails after 7172640 Reviewed-by: kvn, johnc ! src/share/vm/opto/library_call.cpp Changeset: c5d414e98fd4 Author: neliasso Date: 2012-11-26 15:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c5d414e98fd4 8003983: LogCompilation tool is broken since c1 support Summary: Fixed emitting and parsing Reviewed-by: jrose, kvn ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCompilation.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java ! src/share/vm/c1/c1_Compilation.cpp Changeset: b7ff5879152e Author: neliasso Date: 2012-12-06 09:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/b7ff5879152e 8003934: Fix generation of malformed options to Projectcreator Summary: Makefile produces unmatched quotes due to nmake bug Reviewed-by: jwilhelm, brutisso ! make/windows/projectfiles/common/Makefile Changeset: 228a94f37a67 Author: neliasso Date: 2012-12-06 14:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/228a94f37a67 Merge Changeset: f0c2369fda5a Author: twisti Date: 2012-12-06 09:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/f0c2369fda5a 8003250: SPARC: move MacroAssembler into separate file Reviewed-by: jrose, kvn ! 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/frame_sparc.inline.hpp ! src/cpu/sparc/vm/icBuffer_sparc.cpp ! src/cpu/sparc/vm/icache_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/jniFastGetField_sparc.cpp + src/cpu/sparc/vm/macroAssembler_sparc.cpp + src/cpu/sparc/vm/macroAssembler_sparc.hpp + src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp ! src/cpu/sparc/vm/metaspaceShared_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/sparc/vm/runtime_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vmreg_sparc.cpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/assembler_zero.hpp ! src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/share/vm/adlc/main.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/macroAssembler.hpp ! src/share/vm/asm/macroAssembler.inline.hpp ! src/share/vm/asm/register.hpp ! src/share/vm/code/vmreg.hpp Changeset: 522662fa9c16 Author: twisti Date: 2012-12-06 11:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/522662fa9c16 Merge Changeset: d2f8c38e543d Author: roland Date: 2012-12-07 01:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/d2f8c38e543d Merge ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/thread.cpp Changeset: 0f80645e9c26 Author: johnc Date: 2012-11-30 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/0f80645e9c26 8004170: G1: Verbose GC output is not getting flushed to log file using JDK 8 Summary: Add flushes to G1CollectedHeap::log_gc_footer() and TraceCPUTime destructor. Reviewed-by: jwilhelm, azeemj, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/timer.cpp Changeset: eade6b2e4782 Author: jmasa Date: 2012-11-29 10:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/eade6b2e4782 8003554: NPG: move Metablock and Metachunk code out of metaspace.cpp Reviewed-by: coleenp + src/share/vm/memory/metablock.cpp + src/share/vm/memory/metachunk.cpp ! src/share/vm/memory/metaspace.cpp Changeset: cbe736bc70fa Author: jwilhelm Date: 2012-12-07 07:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/cbe736bc70fa Merge Changeset: a35a72dd2e12 Author: amurillo Date: 2012-12-07 10:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/a35a72dd2e12 Merge Changeset: 121aa71316af Author: amurillo Date: 2012-12-07 10:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/121aa71316af Added tag hs25-b12 for changeset a35a72dd2e12 ! .hgtags Changeset: 4a2ed49abd51 Author: amurillo Date: 2012-12-07 10:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/4a2ed49abd51 8004724: new hotspot build - hs25-b13 Reviewed-by: jcoomes ! make/hotspot_version From jiangli.zhou at oracle.com Fri Dec 7 14:52:27 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 07 Dec 2012 14:52:27 -0800 Subject: Request for review: 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing In-Reply-To: <75AA2E86-8884-441C-B3E7-E4082807A1CD@oracle.com> References: <50BFB0BC.7060809@oracle.com> <50C2636A.8090401@oracle.com> <75AA2E86-8884-441C-B3E7-E4082807A1CD@oracle.com> Message-ID: <50C2732B.8020801@oracle.com> Hi John, Thanks a lot for the review and suggestion. I'll add Address constants where it's feasible. Jiangli On 12/07/2012 02:40 PM, John Rose wrote: > On Dec 7, 2012, at 1:45 PM, Jiangli Zhou wrote: > >> Could I have another reviewer for the change? Either official or >> non-official reviewer is okay. > > I have a comment on this one. (And you can use me as a reviewer.) > > In the sparc code, I would prefer to see the Address constants kept > around, because they make the code easier to read. > > - const Address size_of_parameters(G5_method, > Method::size_of_parameters_offset()); > - const Address size_of_locals (G5_method, > Method::size_of_locals_offset()); > + const Register G3_constMethod = Glocals_size; > + const Address size_of_parameters(G3_ConstMethod, > ConstMethod::size_of_parameters_offset()); > + const Address size_of_locals > (G3_ConstMethod, ConstMethod::size_of_locals_offset()); > const Address constMethod (G5_method, Method::const_offset()); > int rounded_vm_local_words = round_to( > frame::interpreter_frame_vm_local_words, WordsPerLong ); > @@ -511,7 +509,8 @@ > // Lscratch can't be used as a temporary because the call_stub uses > // it to assert that the stack frame was setup correctly. > + __ ld_ptr( constMethod, G3_constMethod ); > - __ lduh( size_of_parameters, Glocals_size); > > Maybe the details make it difficult, but I think it's possible in most > places. > > As a side effect, using a fixed register (like G3) for the ConstMethod > will make debugging easier. > > Same comment for x86/64. > > This may be more difficult to do on x86/32, since there are fewer temp > registers. But that's an oddball case. > > Thanks, > ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121207/e631479e/attachment.html From alejandro.murillo at oracle.com Fri Dec 7 15:28:26 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 07 Dec 2012 23:28:26 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 22 new changesets Message-ID: <20121207232909.B45ED47FCC@hg.openjdk.java.net> Changeset: 10587a580c51 Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/10587a580c51 Added tag jdk8-b67 for changeset 25bdce771bb3 ! .hgtags Changeset: 7cc69864a29b Author: kvn Date: 2012-11-16 15:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7cc69864a29b 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum Summary: Increase the stack size in the run parameters. Reviewed-by: kvn Contributed-by: david.r.chase at oracle.com ! test/compiler/6865265/StackOverflowBug.java Changeset: ee32440febeb Author: vlivanov Date: 2012-11-21 05:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ee32440febeb 8001538: hs_err file does not list anymore compiled methods in compilation events Summary: Fixed message buffer size calculation. Reviewed-by: kvn, twisti ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/utilities/events.hpp Changeset: beebba0acc11 Author: twisti Date: 2012-11-26 17:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/beebba0acc11 7172640: C2: instrinsic implementations in LibraryCallKit should use argument() instead of pop() Reviewed-by: kvn, jrose ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/type.hpp Changeset: 2cd5e15048e6 Author: twisti Date: 2012-11-27 12:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2cd5e15048e6 8003868: fix shark for latest HotSpot and LLVM Reviewed-by: twisti Contributed-by: Roman Kennke ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/assembler_zero.hpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/globals_zero.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/shark/llvmHeaders.hpp ! src/share/vm/shark/llvmValue.hpp ! src/share/vm/shark/sharkBlock.cpp ! src/share/vm/shark/sharkBuilder.cpp ! src/share/vm/shark/sharkBuilder.hpp ! src/share/vm/shark/sharkCacheDecache.cpp ! src/share/vm/shark/sharkCacheDecache.hpp ! src/share/vm/shark/sharkCodeBuffer.hpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkConstant.cpp ! src/share/vm/shark/sharkContext.cpp ! src/share/vm/shark/sharkContext.hpp ! src/share/vm/shark/sharkFunction.hpp ! src/share/vm/shark/sharkIntrinsics.cpp ! src/share/vm/shark/sharkMemoryManager.cpp ! src/share/vm/shark/sharkMemoryManager.hpp ! src/share/vm/shark/sharkNativeWrapper.cpp ! src/share/vm/shark/sharkStack.cpp ! src/share/vm/shark/sharkStack.hpp ! src/share/vm/shark/sharkState.cpp ! src/share/vm/shark/sharkTopLevelBlock.cpp ! src/share/vm/shark/sharkTopLevelBlock.hpp ! src/share/vm/shark/sharkType.hpp ! src/share/vm/shark/sharkValue.cpp ! src/share/vm/shark/shark_globals.hpp Changeset: 2aff40cb4703 Author: bharadwaj Date: 2012-11-27 17:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2aff40cb4703 7092905: C2: Keep track of the number of dead nodes Summary: keep an (almost) accurate running count of the reachable (live) flow graph nodes. Reviewed-by: kvn, twisti, jrose, vlivanov ! src/share/tools/LogCompilation/README ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/CallSite.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCompilation.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/Phase.java ! src/share/vm/opto/block.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/stringopts.cpp Changeset: 1acccb7c0b01 Author: kvn Date: 2012-11-27 17:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1acccb7c0b01 8003850: add support for constants in stub code Summary: remember the code section and switch back to the proper one when adding constants. Reviewed-by: twisti, kvn Contributed-by: goetz.lindenmaier at sap.com ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/codeBuffer.cpp Changeset: 6ab62ad83507 Author: twisti Date: 2012-11-30 11:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6ab62ad83507 8003195: AbstractAssembler should not store code pointers but use the CodeSection directly Reviewed-by: twisti, kvn Contributed-by: Bharadwaj Yadavalli ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/assembler_x86.inline.hpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/assembler.inline.hpp ! src/share/vm/asm/codeBuffer.hpp Changeset: cd3d6a6b95d9 Author: twisti Date: 2012-11-30 15:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cd3d6a6b95d9 8003240: x86: move MacroAssembler into separate file Reviewed-by: kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/codeBuffer_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/assembler_x86.inline.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/icBuffer_x86.cpp ! src/cpu/x86/vm/icache_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/jniFastGetField_x86_32.cpp ! src/cpu/x86/vm/jniFastGetField_x86_64.cpp + src/cpu/x86/vm/macroAssembler_x86.cpp + src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/metaspaceShared_x86_32.cpp ! src/cpu/x86/vm/metaspaceShared_x86_64.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.cpp ! src/cpu/x86/vm/relocInfo_x86.cpp ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/runtime_x86_64.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/os/bsd/vm/osThread_bsd.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/osThread_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/solaris/vm/osThread_solaris.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/vm/osThread_windows.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.inline.hpp ! src/os_cpu/bsd_x86/vm/assembler_bsd_x86.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/assembler.inline.hpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp + src/share/vm/asm/macroAssembler.hpp + src/share/vm/asm/macroAssembler.inline.hpp ! src/share/vm/c1/c1_MacroAssembler.hpp ! src/share/vm/code/icBuffer.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/atomic.hpp + src/share/vm/runtime/atomic.inline.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/stubCodeGenerator.cpp Changeset: dd38cfd12c3a Author: twisti Date: 2012-12-03 15:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/dd38cfd12c3a 8004319: test/gc/7168848/HumongousAlloc.java fails after 7172640 Reviewed-by: kvn, johnc ! src/share/vm/opto/library_call.cpp Changeset: c5d414e98fd4 Author: neliasso Date: 2012-11-26 15:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c5d414e98fd4 8003983: LogCompilation tool is broken since c1 support Summary: Fixed emitting and parsing Reviewed-by: jrose, kvn ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCompilation.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java ! src/share/vm/c1/c1_Compilation.cpp Changeset: b7ff5879152e Author: neliasso Date: 2012-12-06 09:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b7ff5879152e 8003934: Fix generation of malformed options to Projectcreator Summary: Makefile produces unmatched quotes due to nmake bug Reviewed-by: jwilhelm, brutisso ! make/windows/projectfiles/common/Makefile Changeset: 228a94f37a67 Author: neliasso Date: 2012-12-06 14:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/228a94f37a67 Merge Changeset: f0c2369fda5a Author: twisti Date: 2012-12-06 09:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f0c2369fda5a 8003250: SPARC: move MacroAssembler into separate file Reviewed-by: jrose, kvn ! 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/frame_sparc.inline.hpp ! src/cpu/sparc/vm/icBuffer_sparc.cpp ! src/cpu/sparc/vm/icache_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/jniFastGetField_sparc.cpp + src/cpu/sparc/vm/macroAssembler_sparc.cpp + src/cpu/sparc/vm/macroAssembler_sparc.hpp + src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp ! src/cpu/sparc/vm/metaspaceShared_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/sparc/vm/runtime_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vmreg_sparc.cpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/assembler_zero.hpp ! src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/share/vm/adlc/main.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/macroAssembler.hpp ! src/share/vm/asm/macroAssembler.inline.hpp ! src/share/vm/asm/register.hpp ! src/share/vm/code/vmreg.hpp Changeset: 522662fa9c16 Author: twisti Date: 2012-12-06 11:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/522662fa9c16 Merge Changeset: d2f8c38e543d Author: roland Date: 2012-12-07 01:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d2f8c38e543d Merge ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/thread.cpp Changeset: 0f80645e9c26 Author: johnc Date: 2012-11-30 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0f80645e9c26 8004170: G1: Verbose GC output is not getting flushed to log file using JDK 8 Summary: Add flushes to G1CollectedHeap::log_gc_footer() and TraceCPUTime destructor. Reviewed-by: jwilhelm, azeemj, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/timer.cpp Changeset: eade6b2e4782 Author: jmasa Date: 2012-11-29 10:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/eade6b2e4782 8003554: NPG: move Metablock and Metachunk code out of metaspace.cpp Reviewed-by: coleenp + src/share/vm/memory/metablock.cpp + src/share/vm/memory/metachunk.cpp ! src/share/vm/memory/metaspace.cpp Changeset: cbe736bc70fa Author: jwilhelm Date: 2012-12-07 07:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cbe736bc70fa Merge Changeset: a35a72dd2e12 Author: amurillo Date: 2012-12-07 10:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a35a72dd2e12 Merge Changeset: 121aa71316af Author: amurillo Date: 2012-12-07 10:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/121aa71316af Added tag hs25-b12 for changeset a35a72dd2e12 ! .hgtags Changeset: 4a2ed49abd51 Author: amurillo Date: 2012-12-07 10:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4a2ed49abd51 8004724: new hotspot build - hs25-b13 Reviewed-by: jcoomes ! make/hotspot_version From jiangli.zhou at oracle.com Sun Dec 9 21:53:24 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Sun, 09 Dec 2012 21:53:24 -0800 Subject: Request for review: 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing In-Reply-To: <50C2732B.8020801@oracle.com> References: <50BFB0BC.7060809@oracle.com> <50C2636A.8090401@oracle.com> <75AA2E86-8884-441C-B3E7-E4082807A1CD@oracle.com> <50C2732B.8020801@oracle.com> Message-ID: <50C578D4.10706@oracle.com> Hi John, Here is the updated webrev with Address constant change in where it's appropriate: http://cr.openjdk.java.net/~jiangli/8004076/webrev.01/. I'm also double checking with jprt and runthese tests. Thanks, Jiangli On 12/07/2012 02:52 PM, Jiangli Zhou wrote: > Hi John, > > Thanks a lot for the review and suggestion. I'll add Address constants > where it's feasible. > > Jiangli > > On 12/07/2012 02:40 PM, John Rose wrote: >> On Dec 7, 2012, at 1:45 PM, Jiangli Zhou wrote: >> >>> Could I have another reviewer for the change? Either official or >>> non-official reviewer is okay. >> >> I have a comment on this one. (And you can use me as a reviewer.) >> >> In the sparc code, I would prefer to see the Address constants kept >> around, because they make the code easier to read. >> >> - const Address size_of_parameters(G5_method, >> Method::size_of_parameters_offset()); >> - const Address size_of_locals (G5_method, >> Method::size_of_locals_offset()); >> + const Register G3_constMethod = Glocals_size; >> + const Address size_of_parameters(G3_ConstMethod, >> ConstMethod::size_of_parameters_offset()); >> + const Address size_of_locals >> (G3_ConstMethod, ConstMethod::size_of_locals_offset()); >> const Address constMethod (G5_method, Method::const_offset()); >> int rounded_vm_local_words = round_to( >> frame::interpreter_frame_vm_local_words, WordsPerLong ); >> @@ -511,7 +509,8 @@ >> // Lscratch can't be used as a temporary because the call_stub uses >> // it to assert that the stack frame was setup correctly. >> + __ ld_ptr( constMethod, G3_constMethod ); >> - __ lduh( size_of_parameters, Glocals_size); >> >> Maybe the details make it difficult, but I think it's possible in >> most places. >> >> As a side effect, using a fixed register (like G3) for the >> ConstMethod will make debugging easier. >> >> Same comment for x86/64. >> >> This may be more difficult to do on x86/32, since there are fewer >> temp registers. But that's an oddball case. >> >> Thanks, >> ? John > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121209/d796e1e1/attachment.html From coleen.phillimore at oracle.com Mon Dec 10 13:15:28 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 10 Dec 2012 16:15:28 -0500 Subject: Request for review: 7174978: NPG: Fix bactrace builder for class redefinition In-Reply-To: <50BF9F3E.6010906@oracle.com> References: <50BF9F3E.6010906@oracle.com> Message-ID: <50C650F0.4020405@oracle.com> I have updated this webrev to include cleanups suggested by John Rose for the anonymous class fix. Please review before I add more to this!! open webrev at http://cr.openjdk.java.net/~coleenp/7174978_2/ bug link at http://bugs.sun.com/view_bug.do?bug_id=7174978 Thanks, Coleen On 12/05/2012 02:23 PM, Coleen Phillimore wrote: > Summary: Save the set of backtraces to use for on stack method walking > for redefine classes. > > I also moved metadataOnStackMark class to it's own file because it's > not only used for redefine classes. Some metadata can be > individually deallocated (eg. the Method* created in the relocator). > > open webrev at http://cr.openjdk.java.net/~coleenp/7174978/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=7174978 > > Ran test that will be added to the jdk/tests in > java/lang/instrument/RedefineMethodInBacktrace.sh (to be checked in > separately). > > thanks, > Coleen From john.r.rose at oracle.com Mon Dec 10 15:10:51 2012 From: john.r.rose at oracle.com (John Rose) Date: Mon, 10 Dec 2012 15:10:51 -0800 Subject: Request for review: 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing In-Reply-To: <50C578D4.10706@oracle.com> References: <50BFB0BC.7060809@oracle.com> <50C2636A.8090401@oracle.com> <75AA2E86-8884-441C-B3E7-E4082807A1CD@oracle.com> <50C2732B.8020801@oracle.com> <50C578D4.10706@oracle.com> Message-ID: <0AABC510-5CDE-4C98-9DC4-DEE7183AA1CD@oracle.com> On Dec 9, 2012, at 9:53 PM, Jiangli Zhou wrote: > Hi John, > > Here is the updated webrev with Address constant change in where it's appropriate: > > http://cr.openjdk.java.net/~jiangli/8004076/webrev.01/. > > I'm also double checking with jprt and runthese tests. Yes, that's much nicer; thanks. Has your group been considering compressing the field metadata (type FieldInfo)? I think that, by using a variable-length byte-oriented format, we could easily cut the size of that data by more than 50%. The initval field and the high part of the offset are almost always zero. The number of access flags configurations is very small, much smaller than 2**16. (Low entropy everywhere!) All this means they could be profitably cut out most of the time with profit, as long as the access method does not slow the VM down detectably. I'm thinking about this because of Alexey's work on @Contended and the upcoming work on @Stable. Also, if we do field profiling we may need to add miscellaneous bits to the field metadata. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121210/f330fc34/attachment.html From jiangli.zhou at oracle.com Mon Dec 10 15:30:34 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 10 Dec 2012 15:30:34 -0800 Subject: Request for review: 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing In-Reply-To: <0AABC510-5CDE-4C98-9DC4-DEE7183AA1CD@oracle.com> References: <50BFB0BC.7060809@oracle.com> <50C2636A.8090401@oracle.com> <75AA2E86-8884-441C-B3E7-E4082807A1CD@oracle.com> <50C2732B.8020801@oracle.com> <50C578D4.10706@oracle.com> <0AABC510-5CDE-4C98-9DC4-DEE7183AA1CD@oracle.com> Message-ID: <50C6709A.9010209@oracle.com> Hi John, Thanks a lot for looking at the change again and the field compressing suggestion! I've looked into the FieldInfo array and optimized the memory usage for the generic signature index slot earlier this year. I haven't played with any compression technique. Thanks for the suggestion, definitely worth to look into. I have one question maybe you have quick answer to it. Does C1 or C2 heavily relying on fast accessing to the FieldInfo array? Thanks, Jiangli On 12/10/2012 03:10 PM, John Rose wrote: > On Dec 9, 2012, at 9:53 PM, Jiangli Zhou wrote: > >> Hi John, >> >> Here is the updated webrev with Address constant change in where it's >> appropriate: >> >> http://cr.openjdk.java.net/~jiangli/8004076/webrev.01/. >> >> I'm also double checking with jprt and runthese tests. > > Yes, that's much nicer; thanks. > > Has your group been considering compressing the field metadata > (type FieldInfo)? > > I think that, by using a variable-length byte-oriented format, we > could easily cut the size of that data by more than 50%. > > The initval field and the high part of the offset are almost always > zero. The number of access flags configurations is very small, much > smaller than 2**16. (Low entropy everywhere!) All this means they > could be profitably cut out most of the time with profit, as long as > the access method does not slow the VM down detectably. > > I'm thinking about this because of Alexey's work on @Contended and the > upcoming work on @Stable. Also, if we do field profiling we may need > to add miscellaneous bits to the field metadata. > > ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121210/e044bff9/attachment.html From john.r.rose at oracle.com Mon Dec 10 15:53:51 2012 From: john.r.rose at oracle.com (John Rose) Date: Mon, 10 Dec 2012 15:53:51 -0800 Subject: Request for review: 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing In-Reply-To: <50C6709A.9010209@oracle.com> References: <50BFB0BC.7060809@oracle.com> <50C2636A.8090401@oracle.com> <75AA2E86-8884-441C-B3E7-E4082807A1CD@oracle.com> <50C2732B.8020801@oracle.com> <50C578D4.10706@oracle.com> <0AABC510-5CDE-4C98-9DC4-DEE7183AA1CD@oracle.com> <50C6709A.9010209@oracle.com> Message-ID: <38A475FF-949C-47CA-A7B0-7DF283B5D384@oracle.com> On Dec 10, 2012, at 3:30 PM, Jiangli Zhou wrote: > Does C1 or C2 heavily relying on fast accessing to the FieldInfo array? No. And if it did, the CI interface could unpack metadata into a non-sparse form. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121210/b1187ef6/attachment.html From jiangli.zhou at oracle.com Mon Dec 10 15:54:30 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 10 Dec 2012 15:54:30 -0800 Subject: Request for review: 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing In-Reply-To: <38A475FF-949C-47CA-A7B0-7DF283B5D384@oracle.com> References: <50BFB0BC.7060809@oracle.com> <50C2636A.8090401@oracle.com> <75AA2E86-8884-441C-B3E7-E4082807A1CD@oracle.com> <50C2732B.8020801@oracle.com> <50C578D4.10706@oracle.com> <0AABC510-5CDE-4C98-9DC4-DEE7183AA1CD@oracle.com> <50C6709A.9010209@oracle.com> <38A475FF-949C-47CA-A7B0-7DF283B5D384@oracle.com> Message-ID: <50C67636.4060407@oracle.com> Ok, thanks! Jiangli On 12/10/2012 03:53 PM, John Rose wrote: > On Dec 10, 2012, at 3:30 PM, Jiangli Zhou wrote: > >> Does C1 or C2 heavily relying on fast accessing to the FieldInfo array? > > No. > > And if it did, the CI interface could unpack metadata into a > non-sparse form. > > ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121210/b42032be/attachment.html From coleen.phillimore at oracle.com Tue Dec 11 13:52:20 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 11 Dec 2012 16:52:20 -0500 Subject: RFR (XS): Add necessary .inline.hpp files to fix non-PCH build In-Reply-To: <50C114A4.7070406@oracle.com> References: <50C114A4.7070406@oracle.com> Message-ID: <50C7AB14.8030208@oracle.com> This looks good to me. Coleen On 12/06/2012 04:56 PM, Stefan Karlsson wrote: > Hi Volker, > > Bug created: JDK-8004674 > > Thanks for fixing this. Your patch looks good. Though, I think it's > unfortunate that we have to add allocation.inline.hpp whenever this > 'new' is used. > > Can someone who's an official Reviewer also review this? > > StefanK > > On 2012-11-30 19:51, Volker Simonis wrote: >> Hi, >> >> I'm currently working on "6889002 : CHECK macros in return constructs >> lead to unreachable code" and just realized that the non-PCH build on >> Linux is broken (once again). >> >> The failure manifests itself with a "libjvm.so: undefined reference to >> `CHeapObj<(unsigned short)1280>::operator new(unsigned long, unsigned >> char*)'" which is caused by the recent "6995781: Native memory >> Tracking" change. The problem is that "operator new" is called in the >> files "gc_implementation/parallelScavenge/adjoiningVirtualSpaces.cpp" >> and "gc_implementation/shared/gcStats.cpp" for classes which have the >> template class "CHeapObj" as their base class. CHeapObj defines its >> own "new" operator in "memory/allocation.inline.hpp" but this >> inline.hpp file is not included into >> "gc_implementation/parallelScavenge/adjoiningVirtualSpaces.cpp" and >> "gc_implementation/shared/gcStats.cpp". >> >> Funny enough, the problem doesn't seem to appear neither for older >> version of GCC (e.g. 4.4.6 on SLES 10) nor in debug builds. I could >> only reproduce it with a product build on Ubuntu 12.04 with GCC 4.6.3. >> The reason is most probably the fact that newer versions of GCC create >> template instantiations in a much more lazy way. >> >> The fix is easy - just add the missing includes to the corresponding >> files (see attached patch). >> Could somebody please open a bug for this issue and review/commit the >> change. >> >> Please notice that this actually not exactly the annoying "inline.hpp" >> problem which will be addressed with "8003990: Clean up inline >> #includes" but very similar because template definition and >> instantiation have similar semantics. This only didn't caused any >> problems until now because templates have been used very little in >> HotSpot. However once this changes, special care has to be taken to >> manage them in a way every compiler can cope with. >> >> Thank you and best regards, >> Volker > From serguei.spitsyn at oracle.com Tue Dec 11 14:31:19 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 11 Dec 2012 14:31:19 -0800 Subject: Request for review: 7174978: NPG: Fix bactrace builder for class redefinition In-Reply-To: <50C650F0.4020405@oracle.com> References: <50BF9F3E.6010906@oracle.com> <50C650F0.4020405@oracle.com> Message-ID: <50C7B437.4080409@oracle.com> Coleen, It looks good in general. Just some questions below. src/share/vm/classfile/javaClasses.cpp 1339 void java_lang_Throwable::mark_on_stack(oop throwable) { . . . 1352 if (method == NULL) return; Would it be more safe to continue instead of return? 1352 if (method == NULL) continue; src/share/vm/classfile/backtrace.cpp 63 void Backtrace::do_unloading() { I guess, this can be called at a safepoint only. Would it make sense to place a comment or an assert? I see you already created a new unit test for this: java/lang/instrument/RedefineMethodInBacktrace.sh Thanks, Serguei On 12/10/12 1:15 PM, Coleen Phillimore wrote: > > I have updated this webrev to include cleanups suggested by John Rose > for the anonymous class fix. Please review before I add more to this!! > > open webrev at http://cr.openjdk.java.net/~coleenp/7174978_2/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=7174978 > > Thanks, > Coleen > > > On 12/05/2012 02:23 PM, Coleen Phillimore wrote: >> Summary: Save the set of backtraces to use for on stack method >> walking for redefine classes. >> >> I also moved metadataOnStackMark class to it's own file because it's >> not only used for redefine classes. Some metadata can be >> individually deallocated (eg. the Method* created in the relocator). >> >> open webrev at http://cr.openjdk.java.net/~coleenp/7174978/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=7174978 >> >> Ran test that will be added to the jdk/tests in >> java/lang/instrument/RedefineMethodInBacktrace.sh (to be checked in >> separately). >> >> thanks, >> Coleen > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121211/fa69b9f0/attachment.html From john.r.rose at oracle.com Tue Dec 11 17:02:21 2012 From: john.r.rose at oracle.com (John Rose) Date: Tue, 11 Dec 2012 17:02:21 -0800 Subject: Request for review: 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing In-Reply-To: <50C6709A.9010209@oracle.com> References: <50BFB0BC.7060809@oracle.com> <50C2636A.8090401@oracle.com> <75AA2E86-8884-441C-B3E7-E4082807A1CD@oracle.com> <50C2732B.8020801@oracle.com> <50C578D4.10706@oracle.com> <0AABC510-5CDE-4C98-9DC4-DEE7183AA1CD@oracle.com> <50C6709A.9010209@oracle.com> Message-ID: <7CC0EDC2-E909-47CF-A749-6B5CA5C5D728@oracle.com> On Dec 10, 2012, at 3:30 PM, Jiangli Zhou wrote: > Hi John, > > Thanks a lot for looking at the change again and the field compressing suggestion! I've looked into the FieldInfo array and optimized the memory usage for the generic signature index slot earlier this year. I haven't played with any compression technique. Thanks for the suggestion, definitely worth to look into. I have one question maybe you have quick answer to it. Does C1 or C2 heavily relying on fast accessing to the FieldInfo array? A couple of other bits... I sketched more of a compact design during Alexsey's review: On Dec 11, 2012, at 3:21 PM, John Rose wrote: > On Dec 11, 2012, at 5:06 AM, Aleksey Shipilev wrote: > >>> ...The rework could use something like your tagging >>> scheme (which is clever) but have the exceptional tag value mean "I >>> have extended attributes specified in N additional words of data". >> >> I think we have a little bit of mis-design about FieldInfo here. What >> allows me to piggyback on FieldInfo is that we clearly have the >> classload-scope (CS) metadata info for fields, and runtime-scope (RS) >> metadata info. That allows us to mangle CS data during the classload, >> knowing for sure we substitute that with RS after classload finishes. >> >> This is probably a little dodgy when compared against sparse >> representation, but I feel uncomfortable rebuilding entire field >> attribute mechanics in the course of @Contended work. > > It's totally dodgy. It makes some sense if you are aiming at an in-memory copy of the classfile AST, but is not friendly to the JVM which is actually using the data. If I were rewriting it, I would try to use a temporary FieldInfo structure with a simple but non-dense layout, and a packing phase which would put the necessary field metadata into a dense streamable form, in an array, using CompressedStream. The FieldStream would unpack each successive field descriptor into the FieldInfo structure. By using CompressedStream, the data structure would be 32-bit clean, leading to various other advantages. In general, I think we should make more systematic use of CompressedStream for storing metadata that is not directly accessed by the interpreter or compiled code. Also, I did a quick and dirty "printf" based test for average field-info array size. It suggests that about 30% of the classes have one or more fields, and that of those classes, the average array length is 36 (u2) elements. This is pretty small potatoes, but it's of similar magnitude to the other bit-packing changes to InstanceKlass, so maybe it's worth while. I definitely think using CompressedStream in more places is worthwhile, if we want to pack our metadata down tighter, and at the same time move toward 32-bit clean representations. Thanks, ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121211/e3203517/attachment.html From jiangli.zhou at oracle.com Tue Dec 11 17:38:16 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 11 Dec 2012 17:38:16 -0800 Subject: Request for review: 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing In-Reply-To: <7CC0EDC2-E909-47CF-A749-6B5CA5C5D728@oracle.com> References: <50BFB0BC.7060809@oracle.com> <50C2636A.8090401@oracle.com> <75AA2E86-8884-441C-B3E7-E4082807A1CD@oracle.com> <50C2732B.8020801@oracle.com> <50C578D4.10706@oracle.com> <0AABC510-5CDE-4C98-9DC4-DEE7183AA1CD@oracle.com> <50C6709A.9010209@oracle.com> <7CC0EDC2-E909-47CF-A749-6B5CA5C5D728@oracle.com> Message-ID: <50C7E008.7050403@oracle.com> Hi John, Thanks! Following are some more questions. I see CompressedStream uses UNSIGNED5 coding of Pack200. I tried to google around for the UNSIGNED5 coding compression rate, but without much luck. If you have any info on that, please share. I was trying to find some usage examples in the VM code, but there seems no usage of CompressedStream (except the sa agent java code). Do you have any pointer? Thanks, Jiangli On 12/11/2012 05:02 PM, John Rose wrote: > On Dec 10, 2012, at 3:30 PM, Jiangli Zhou wrote: > >> Hi John, >> >> Thanks a lot for looking at the change again and the field >> compressing suggestion! I've looked into the FieldInfo array and >> optimized the memory usage for the generic signature index slot >> earlier this year. I haven't played with any compression technique. >> Thanks for the suggestion, definitely worth to look into. I have one >> question maybe you have quick answer to it. Does C1 or C2 heavily >> relying on fast accessing to the FieldInfo array? > > A couple of other bits... > > I sketched more of a compact design during Alexsey's review: > > On Dec 11, 2012, at 3:21 PM, John Rose wrote: > >> On Dec 11, 2012, at 5:06 AM, Aleksey Shipilev wrote: >> >>>> ...The rework could use something like your tagging >>>> scheme (which is clever) but have the exceptional tag value mean "I >>>> have extended attributes specified in N additional words of data". >>> >>> I think we have a little bit of mis-design about FieldInfo here. What >>> allows me to piggyback on FieldInfo is that we clearly have the >>> classload-scope (CS) metadata info for fields, and runtime-scope (RS) >>> metadata info. That allows us to mangle CS data during the classload, >>> knowing for sure we substitute that with RS after classload finishes. >>> >>> This is probably a little dodgy when compared against sparse >>> representation, but I feel uncomfortable rebuilding entire field >>> attribute mechanics in the course of @Contended work. >> >> It's totally dodgy. It makes some sense if you are aiming at an >> in-memory copy of the classfile AST, but is not friendly to the JVM >> which is actually using the data. If I were rewriting it, I would >> try to use a temporary FieldInfo structure with a simple but >> non-dense layout, and a packing phase which would put the necessary >> field metadata into a dense streamable form, in an array, using >> CompressedStream. The FieldStream would unpack each successive field >> descriptor into the FieldInfo structure. By using CompressedStream, >> the data structure would be 32-bit clean, leading to various other >> advantages. > > In general, I think we should make more systematic use of > CompressedStream for storing metadata that is not directly accessed by > the interpreter or compiled code. > > Also, I did a quick and dirty "printf" based test for average > field-info array size. It suggests that about 30% of the classes have > one or more fields, and that of those classes, the average array > length is 36 (u2) elements. This is pretty small potatoes, but it's > of similar magnitude to the other bit-packing changes to > InstanceKlass, so maybe it's worth while. I definitely think using > CompressedStream in more places is worthwhile, if we want to pack our > metadata down tighter, and at the same time move toward 32-bit clean > representations. > > Thanks, > ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121211/5096beea/attachment-0001.html From john.r.rose at oracle.com Tue Dec 11 20:00:37 2012 From: john.r.rose at oracle.com (John Rose) Date: Tue, 11 Dec 2012 20:00:37 -0800 Subject: Request for review: 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing In-Reply-To: <50C7E008.7050403@oracle.com> References: <50BFB0BC.7060809@oracle.com> <50C2636A.8090401@oracle.com> <75AA2E86-8884-441C-B3E7-E4082807A1CD@oracle.com> <50C2732B.8020801@oracle.com> <50C578D4.10706@oracle.com> <0AABC510-5CDE-4C98-9DC4-DEE7183AA1CD@oracle.com> <50C6709A.9010209@oracle.com> <7CC0EDC2-E909-47CF-A749-6B5CA5C5D728@oracle.com> <50C7E008.7050403@oracle.com> Message-ID: <9F3C03A3-22DA-4A64-842A-AB418DE72125@oracle.com> On Dec 11, 2012, at 5:38 PM, Jiangli Zhou wrote: > I see CompressedStream uses UNSIGNED5 coding of Pack200. I tried to google around for the UNSIGNED5 coding compression rate, but without much luck. If you have any info on that, please share. I was trying to find some usage examples in the VM code, but there seems no usage of CompressedStream (except the sa agent java code). Do you have any pointer? Right; you started with the comments here: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/tip/src/share/vm/code/compressedStream.hpp Detailed definitions for UNSIGNED5 and related codings are in the pack200 spec: http://docs.oracle.com/javase/6/docs/technotes/guides/pack200/pack-spec.html#tocInEnSc There is also a more focused description here in the Java source code: http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/com/sun/java/util/jar/pack/Coding.java Then we have BandStructure.java: 108: final static Coding UNSIGNED5 = Coding.of(5,64); To search for compressed stream use in HotSpot, look for subtypes of either the read or write version. grep -n CompressedReadStream $(hg loc -I src) grep -n CompressedWriteStream $(hg loc -I src) Then look at DebugInfoReadStream and CompressedLineNumberReadStream, and the writer versions. There's a lot of compressed metadata in the code cache, and interpreter oop maps use it. It is not used in metadata, yet. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121211/55b8b515/attachment.html From erik.helin at oracle.com Wed Dec 12 01:27:33 2012 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 12 Dec 2012 10:27:33 +0100 Subject: RFR (XS): 8004661: Comment and function name java_lang_String::toHash is wrong Message-ID: <50C84E05.6010200@oracle.com> Hi all, the webrev is located at: http://cr.openjdk.java.net/~ehelin/8004661/webrev.00/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004661 Summary: I've renamed the function to_hash to hashCode and also updated the comments to use hashCode instead of to_hash. Testing: JPRT Thanks, Erik From david.holmes at oracle.com Wed Dec 12 01:49:43 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Dec 2012 19:49:43 +1000 Subject: RFR (XS): 8004661: Comment and function name java_lang_String::toHash is wrong In-Reply-To: <50C84E05.6010200@oracle.com> References: <50C84E05.6010200@oracle.com> Message-ID: <50C85337.5060209@oracle.com> Hi Erik, Looks like a correct name change to me. David On 12/12/2012 7:27 PM, Erik Helin wrote: > Hi all, > > the webrev is located at: > http://cr.openjdk.java.net/~ehelin/8004661/webrev.00/ > > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004661 > > Summary: > I've renamed the function to_hash to hashCode and also updated the > comments to use hashCode instead of to_hash. > > Testing: > JPRT > > Thanks, > Erik > From erik.helin at oracle.com Wed Dec 12 01:57:47 2012 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 12 Dec 2012 10:57:47 +0100 Subject: RFR (XS): 8004661: Comment and function name java_lang_String::toHash is wrong In-Reply-To: <50C85337.5060209@oracle.com> References: <50C84E05.6010200@oracle.com> <50C85337.5060209@oracle.com> Message-ID: <50C8551B.1040009@oracle.com> Thanks! Erik On 12/12/2012 10:49 AM, David Holmes wrote: > Hi Erik, > > Looks like a correct name change to me. > > David > > On 12/12/2012 7:27 PM, Erik Helin wrote: >> Hi all, >> >> the webrev is located at: >> http://cr.openjdk.java.net/~ehelin/8004661/webrev.00/ >> >> Bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004661 >> >> Summary: >> I've renamed the function to_hash to hashCode and also updated the >> comments to use hashCode instead of to_hash. >> >> Testing: >> JPRT >> >> Thanks, >> Erik >> From bengt.rutisson at oracle.com Wed Dec 12 04:15:05 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 12 Dec 2012 13:15:05 +0100 Subject: RFR (XS): 8004661: Comment and function name java_lang_String::toHash is wrong In-Reply-To: <50C84E05.6010200@oracle.com> References: <50C84E05.6010200@oracle.com> Message-ID: <50C87549.9040402@oracle.com> Hi Erik, Shouldn't the method be called hash_code() rather than hashCode() ? Other than that it looks good to me. Bengt On 12/12/12 10:27 AM, Erik Helin wrote: > Hi all, > > the webrev is located at: > http://cr.openjdk.java.net/~ehelin/8004661/webrev.00/ > > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004661 > > Summary: > I've renamed the function to_hash to hashCode and also updated the > comments to use hashCode instead of to_hash. > > Testing: > JPRT > > Thanks, > Erik > From erik.helin at oracle.com Wed Dec 12 05:42:14 2012 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 12 Dec 2012 14:42:14 +0100 Subject: RFR (XS): 8004661: Comment and function name java_lang_String::toHash is wrong In-Reply-To: <50C87549.9040402@oracle.com> References: <50C84E05.6010200@oracle.com> <50C87549.9040402@oracle.com> Message-ID: <50C889B6.40707@oracle.com> Bengt, On 12/12/2012 01:15 PM, Bengt Rutisson wrote: > Shouldn't the method be called hash_code() rather than hashCode() ? This is the standard we use throughout the codebase for the C++ code, but I believe that the Coleen wanted the name of the method to match the Java one. Coleen, did I understand this correctly? I'm fine with using any one of hashCode or hash_code, I think both suggestions make sense. On 12/12/2012 01:15 PM, Bengt Rutisson wrote: > Other than that it looks good to me. Thanks! Erik > Bengt > > On 12/12/12 10:27 AM, Erik Helin wrote: >> Hi all, >> >> the webrev is located at: >> http://cr.openjdk.java.net/~ehelin/8004661/webrev.00/ >> >> Bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004661 >> >> Summary: >> I've renamed the function to_hash to hashCode and also updated the >> comments to use hashCode instead of to_hash. >> >> Testing: >> JPRT >> >> Thanks, >> Erik >> > From coleen.phillimore at oracle.com Wed Dec 12 07:10:49 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 12 Dec 2012 10:10:49 -0500 Subject: RFR (XS): 8004661: Comment and function name java_lang_String::toHash is wrong In-Reply-To: <50C889B6.40707@oracle.com> References: <50C84E05.6010200@oracle.com> <50C87549.9040402@oracle.com> <50C889B6.40707@oracle.com> Message-ID: <50C89E79.5050800@oracle.com> On 12/12/2012 8:42 AM, Erik Helin wrote: > Bengt, > > On 12/12/2012 01:15 PM, Bengt Rutisson wrote: >> Shouldn't the method be called hash_code() rather than hashCode() ? > > This is the standard we use throughout the codebase for the C++ code, > but I believe that the Coleen wanted the name of the method to match > the Java one. > > Coleen, did I understand this correctly? > > I'm fine with using any one of hashCode or hash_code, I think both > suggestions make sense. Yes, I think it should be hash_code to follow our coding conventions but the comments should say hashCode (to match the jdk name). Otherwise, looks great. Thanks! Coleen > > On 12/12/2012 01:15 PM, Bengt Rutisson wrote: >> Other than that it looks good to me. > > Thanks! > > Erik > >> Bengt >> >> On 12/12/12 10:27 AM, Erik Helin wrote: >>> Hi all, >>> >>> the webrev is located at: >>> http://cr.openjdk.java.net/~ehelin/8004661/webrev.00/ >>> >>> Bug: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004661 >>> >>> Summary: >>> I've renamed the function to_hash to hashCode and also updated the >>> comments to use hashCode instead of to_hash. >>> >>> Testing: >>> JPRT >>> >>> Thanks, >>> Erik >>> >> > From erik.helin at oracle.com Wed Dec 12 08:01:09 2012 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 12 Dec 2012 17:01:09 +0100 Subject: RFR (XS): 8004661: Comment and function name java_lang_String::toHash is wrong In-Reply-To: <50C89E79.5050800@oracle.com> References: <50C84E05.6010200@oracle.com> <50C87549.9040402@oracle.com> <50C889B6.40707@oracle.com> <50C89E79.5050800@oracle.com> Message-ID: <50C8AA45.6000608@oracle.com> On 12/12/2012 04:10 PM, Coleen Phillimore wrote: > On 12/12/2012 8:42 AM, Erik Helin wrote: >> Bengt, >> >> On 12/12/2012 01:15 PM, Bengt Rutisson wrote: >>> Shouldn't the method be called hash_code() rather than hashCode() ? >> >> This is the standard we use throughout the codebase for the C++ code, >> but I believe that the Coleen wanted the name of the method to match >> the Java one. >> >> Coleen, did I understand this correctly? >> >> I'm fine with using any one of hashCode or hash_code, I think both >> suggestions make sense. > > Yes, I think it should be hash_code to follow our coding conventions but > the comments should say hashCode (to match the jdk name). Otherwise, > looks great. Thanks, I've the updated webrev to use hash_code instead of hashCode for the C++ function names, please see: http://cr.openjdk.java.net/~ehelin/8004661/webrev.01/ Thanks, Erik > Thanks! > Coleen > >> >> On 12/12/2012 01:15 PM, Bengt Rutisson wrote: >>> Other than that it looks good to me. >> >> Thanks! >> >> Erik >> >>> Bengt >>> >>> On 12/12/12 10:27 AM, Erik Helin wrote: >>>> Hi all, >>>> >>>> the webrev is located at: >>>> http://cr.openjdk.java.net/~ehelin/8004661/webrev.00/ >>>> >>>> Bug: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004661 >>>> >>>> Summary: >>>> I've renamed the function to_hash to hashCode and also updated the >>>> comments to use hashCode instead of to_hash. >>>> >>>> Testing: >>>> JPRT >>>> >>>> Thanks, >>>> Erik >>>> >>> >> > From bengt.rutisson at oracle.com Wed Dec 12 08:01:52 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 12 Dec 2012 17:01:52 +0100 Subject: RFR (XS): 8004661: Comment and function name java_lang_String::toHash is wrong In-Reply-To: <50C8AA45.6000608@oracle.com> References: <50C84E05.6010200@oracle.com> <50C87549.9040402@oracle.com> <50C889B6.40707@oracle.com> <50C89E79.5050800@oracle.com> <50C8AA45.6000608@oracle.com> Message-ID: <50C8AA70.2000101@oracle.com> Looks good, Erik! Bengt On 12/12/12 5:01 PM, Erik Helin wrote: > On 12/12/2012 04:10 PM, Coleen Phillimore wrote: >> On 12/12/2012 8:42 AM, Erik Helin wrote: >>> Bengt, >>> >>> On 12/12/2012 01:15 PM, Bengt Rutisson wrote: >>>> Shouldn't the method be called hash_code() rather than hashCode() ? >>> >>> This is the standard we use throughout the codebase for the C++ code, >>> but I believe that the Coleen wanted the name of the method to match >>> the Java one. >>> >>> Coleen, did I understand this correctly? >>> >>> I'm fine with using any one of hashCode or hash_code, I think both >>> suggestions make sense. >> >> Yes, I think it should be hash_code to follow our coding conventions but >> the comments should say hashCode (to match the jdk name). Otherwise, >> looks great. > > Thanks, I've the updated webrev to use hash_code instead of hashCode > for the C++ function names, please see: > > http://cr.openjdk.java.net/~ehelin/8004661/webrev.01/ > > Thanks, > Erik > >> Thanks! >> Coleen >> >>> >>> On 12/12/2012 01:15 PM, Bengt Rutisson wrote: >>>> Other than that it looks good to me. >>> >>> Thanks! >>> >>> Erik >>> >>>> Bengt >>>> >>>> On 12/12/12 10:27 AM, Erik Helin wrote: >>>>> Hi all, >>>>> >>>>> the webrev is located at: >>>>> http://cr.openjdk.java.net/~ehelin/8004661/webrev.00/ >>>>> >>>>> Bug: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004661 >>>>> >>>>> Summary: >>>>> I've renamed the function to_hash to hashCode and also updated the >>>>> comments to use hashCode instead of to_hash. >>>>> >>>>> Testing: >>>>> JPRT >>>>> >>>>> Thanks, >>>>> Erik >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Wed Dec 12 09:15:54 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 12 Dec 2012 12:15:54 -0500 Subject: Request for review: 7174978: NPG: Fix bactrace builder for class redefinition In-Reply-To: <50C7B437.4080409@oracle.com> References: <50BF9F3E.6010906@oracle.com> <50C650F0.4020405@oracle.com> <50C7B437.4080409@oracle.com> Message-ID: <50C8BBCA.3090705@oracle.com> Serguei, Thanks for reviewing this. I'm reworking it because in the pathological case, if there are no full GC's, we wouldn't reclaim this backtrace C heap storage. On 12/11/2012 5:31 PM, serguei.spitsyn at oracle.com wrote: > Coleen, > > It looks good in general. > Just some questions below. > > > src/share/vm/classfile/javaClasses.cpp > > 1339 void java_lang_Throwable::mark_on_stack(oop throwable) { > . . . > 1352 if (method == NULL) return; > > Would it be more safe to continue instead of return? > 1352 if (method == NULL) continue; This is a short circuit that the function above this also has. The trace_next_offset will be null in this case. If I change it, I'd want to change them both. > > > src/share/vm/classfile/backtrace.cpp > 63 void Backtrace::do_unloading() { > > I guess, this can be called at a safepoint only. > Would it make sense to place a comment or an assert? I added an assert because I assume this. I'm not sure if CMS gc can unload classes without a safepoint, but this code wants to be run at a safepoint. > > I see you already created a new unit test for this: > java/lang/instrument/RedefineMethodInBacktrace.sh > I think StefanK was going to add this test after I checked in this fix (or has he already added it?) thanks, Coleen > Thanks, > Serguei > > > > > > > On 12/10/12 1:15 PM, Coleen Phillimore wrote: >> >> I have updated this webrev to include cleanups suggested by John Rose >> for the anonymous class fix. Please review before I add more to this!! >> >> open webrev at http://cr.openjdk.java.net/~coleenp/7174978_2/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=7174978 >> >> Thanks, >> Coleen >> >> >> On 12/05/2012 02:23 PM, Coleen Phillimore wrote: >>> Summary: Save the set of backtraces to use for on stack method >>> walking for redefine classes. >>> >>> I also moved metadataOnStackMark class to it's own file because it's >>> not only used for redefine classes. Some metadata can be >>> individually deallocated (eg. the Method* created in the relocator). >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/7174978/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7174978 >>> >>> Ran test that will be added to the jdk/tests in >>> java/lang/instrument/RedefineMethodInBacktrace.sh (to be checked in >>> separately). >>> >>> thanks, >>> Coleen >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121212/d6aa8674/attachment.html From serguei.spitsyn at oracle.com Wed Dec 12 09:32:30 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 12 Dec 2012 09:32:30 -0800 Subject: Request for review: 7174978: NPG: Fix bactrace builder for class redefinition In-Reply-To: <50C8BBCA.3090705@oracle.com> References: <50BF9F3E.6010906@oracle.com> <50C650F0.4020405@oracle.com> <50C7B437.4080409@oracle.com> <50C8BBCA.3090705@oracle.com> Message-ID: <50C8BFAE.4030401@oracle.com> Ok. Thanks! Serguei On 12/12/12 9:15 AM, Coleen Phillimore wrote: > > Serguei, > > Thanks for reviewing this. I'm reworking it because in the > pathological case, if there are no full GC's, we wouldn't reclaim this > backtrace C heap storage. > > On 12/11/2012 5:31 PM, serguei.spitsyn at oracle.com wrote: >> Coleen, >> >> It looks good in general. >> Just some questions below. >> >> >> src/share/vm/classfile/javaClasses.cpp >> >> 1339 void java_lang_Throwable::mark_on_stack(oop throwable) { >> . . . >> 1352 if (method == NULL) return; >> >> Would it be more safe to continue instead of return? >> 1352 if (method == NULL) continue; > > This is a short circuit that the function above this also has. The > trace_next_offset will be null in this case. If I change it, I'd want > to change them both. >> >> src/share/vm/classfile/backtrace.cpp >> 63 void Backtrace::do_unloading() { >> >> I guess, this can be called at a safepoint only. >> Would it make sense to place a comment or an assert? > > I added an assert because I assume this. I'm not sure if CMS gc can > unload classes without a safepoint, but this code wants to be run at a > safepoint. > >> I see you already created a new unit test for this: >> java/lang/instrument/RedefineMethodInBacktrace.sh >> > I think StefanK was going to add this test after I checked in this fix > (or has he already added it?) > > thanks, > Coleen > >> Thanks, >> Serguei >> >> >> >> >> >> >> On 12/10/12 1:15 PM, Coleen Phillimore wrote: >>> >>> I have updated this webrev to include cleanups suggested by John >>> Rose for the anonymous class fix. Please review before I add more >>> to this!! >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/7174978_2/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7174978 >>> >>> Thanks, >>> Coleen >>> >>> >>> On 12/05/2012 02:23 PM, Coleen Phillimore wrote: >>>> Summary: Save the set of backtraces to use for on stack method >>>> walking for redefine classes. >>>> >>>> I also moved metadataOnStackMark class to it's own file because >>>> it's not only used for redefine classes. Some metadata can be >>>> individually deallocated (eg. the Method* created in the relocator). >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/7174978/ >>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7174978 >>>> >>>> Ran test that will be added to the jdk/tests in >>>> java/lang/instrument/RedefineMethodInBacktrace.sh (to be checked in >>>> separately). >>>> >>>> thanks, >>>> Coleen >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121212/171f2331/attachment.html From vitalyd at gmail.com Wed Dec 12 09:46:12 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 12 Dec 2012 12:46:12 -0500 Subject: Request for review: 7174978: NPG: Fix bactrace builder for class redefinition In-Reply-To: <50C8BBCA.3090705@oracle.com> References: <50BF9F3E.6010906@oracle.com> <50C650F0.4020405@oracle.com> <50C7B437.4080409@oracle.com> <50C8BBCA.3090705@oracle.com> Message-ID: Hi Coleen, Along the same lines, is it OK to omit a fence in do_unloading after storing into _backtraces_head? Not sure if safepoint means no other VM thread can poke around concurrently here, but thought I'd ask just in case. Thanks Sent from my phone -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121212/fb2f5a53/attachment.html From jiangli.zhou at oracle.com Wed Dec 12 10:18:41 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 12 Dec 2012 10:18:41 -0800 Subject: Request for review: 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing In-Reply-To: <9F3C03A3-22DA-4A64-842A-AB418DE72125@oracle.com> References: <50BFB0BC.7060809@oracle.com> <50C2636A.8090401@oracle.com> <75AA2E86-8884-441C-B3E7-E4082807A1CD@oracle.com> <50C2732B.8020801@oracle.com> <50C578D4.10706@oracle.com> <0AABC510-5CDE-4C98-9DC4-DEE7183AA1CD@oracle.com> <50C6709A.9010209@oracle.com> <7CC0EDC2-E909-47CF-A749-6B5CA5C5D728@oracle.com> <50C7E008.7050403@oracle.com> <9F3C03A3-22DA-4A64-842A-AB418DE72125@oracle.com> Message-ID: <50C8CA81.1070805@oracle.com> Thanks, John! Jiangli On 12/11/2012 08:00 PM, John Rose wrote: > On Dec 11, 2012, at 5:38 PM, Jiangli Zhou wrote: > >> I see CompressedStream uses UNSIGNED5 coding of Pack200. I tried to >> google around for the UNSIGNED5 coding compression rate, but without >> much luck. If you have any info on that, please share. I was trying >> to find some usage examples in the VM code, but there seems no usage >> of CompressedStream (except the sa agent java code). Do you have any >> pointer? > > Right; you started with the comments here: > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/tip/src/share/vm/code/compressedStream.hpp > > Detailed definitions for UNSIGNED5 and related codings are in the > pack200 spec: > http://docs.oracle.com/javase/6/docs/technotes/guides/pack200/pack-spec.html#tocInEnSc > > There is also a more focused description here in the Java source code: > http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/com/sun/java/util/jar/pack/Coding.java > > Then we have BandStructure.java: 108: final static Coding UNSIGNED5 = > Coding.of(5,64); > > To search for compressed stream use in HotSpot, look for subtypes of > either the read or write version. > grep -n CompressedReadStream $(hg loc -I src) > grep -n CompressedWriteStream $(hg loc -I src) > > Then look at DebugInfoReadStream and CompressedLineNumberReadStream, > and the writer versions. There's a lot of compressed metadata in the > code cache, and interpreter oop maps use it. It is not used in > metadata, yet. > > ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121212/cfb1b6b6/attachment-0001.html From jiangli.zhou at oracle.com Wed Dec 12 13:52:21 2012 From: jiangli.zhou at oracle.com (jiangli.zhou at oracle.com) Date: Wed, 12 Dec 2012 21:52:21 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing. Message-ID: <20121212215225.4D5C3470DF@hg.openjdk.java.net> Changeset: fd74228fd5ca Author: jiangli Date: 2012-12-11 12:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/fd74228fd5ca 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing. Summary: Move _max_locals and _size_of_parameters to ConstMethod for better sharing. Reviewed-by: coleenp, minqi, jrose ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/vmStructs.cpp From david.holmes at oracle.com Wed Dec 12 15:52:22 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Dec 2012 09:52:22 +1000 Subject: RFR (XS): 8004661: Comment and function name java_lang_String::toHash is wrong In-Reply-To: <50C8AA45.6000608@oracle.com> References: <50C84E05.6010200@oracle.com> <50C87549.9040402@oracle.com> <50C889B6.40707@oracle.com> <50C89E79.5050800@oracle.com> <50C8AA45.6000608@oracle.com> Message-ID: <50C918B6.5020809@oracle.com> Looks fine to me still. David On 13/12/2012 2:01 AM, Erik Helin wrote: > On 12/12/2012 04:10 PM, Coleen Phillimore wrote: >> On 12/12/2012 8:42 AM, Erik Helin wrote: >>> Bengt, >>> >>> On 12/12/2012 01:15 PM, Bengt Rutisson wrote: >>>> Shouldn't the method be called hash_code() rather than hashCode() ? >>> >>> This is the standard we use throughout the codebase for the C++ code, >>> but I believe that the Coleen wanted the name of the method to match >>> the Java one. >>> >>> Coleen, did I understand this correctly? >>> >>> I'm fine with using any one of hashCode or hash_code, I think both >>> suggestions make sense. >> >> Yes, I think it should be hash_code to follow our coding conventions but >> the comments should say hashCode (to match the jdk name). Otherwise, >> looks great. > > Thanks, I've the updated webrev to use hash_code instead of hashCode for > the C++ function names, please see: > > http://cr.openjdk.java.net/~ehelin/8004661/webrev.01/ > > Thanks, > Erik > >> Thanks! >> Coleen >> >>> >>> On 12/12/2012 01:15 PM, Bengt Rutisson wrote: >>>> Other than that it looks good to me. >>> >>> Thanks! >>> >>> Erik >>> >>>> Bengt >>>> >>>> On 12/12/12 10:27 AM, Erik Helin wrote: >>>>> Hi all, >>>>> >>>>> the webrev is located at: >>>>> http://cr.openjdk.java.net/~ehelin/8004661/webrev.00/ >>>>> >>>>> Bug: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004661 >>>>> >>>>> Summary: >>>>> I've renamed the function to_hash to hashCode and also updated the >>>>> comments to use hashCode instead of to_hash. >>>>> >>>>> Testing: >>>>> JPRT >>>>> >>>>> Thanks, >>>>> Erik >>>>> >>>> >>> >> > From jeremymanson at google.com Wed Dec 12 16:11:23 2012 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 12 Dec 2012 16:11:23 -0800 Subject: Minor memory issues in fastdebug build Message-ID: Hi folks, I was playing with the fastdebug build, and I found a couple of trivial memory issues. A patch follows: let me know if you want me to do some footwork to correct it (file a bug, etc). Jeremy diff -r 121aa71316af src/share/vm/runtime/vmStructs.cpp --- a/src/share/vm/runtime/vmStructs.cpp Fri Dec 07 10:46:54 2012 -0800 +++ b/src/share/vm/runtime/vmStructs.cpp Wed Dec 12 16:05:25 2012 -0800 @@ -3146,10 +3146,10 @@ s[len-1] = '\0'; // tty->print_cr("checking \"%s\" for \"%s\"", s, typeName); if (recursiveFindType(origtypes, s, true) == 1) { - delete s; + delete [] s; return 1; } - delete s; + delete [] s; } const char* start = NULL; if (strstr(typeName, "GrowableArray<") == typeName) { @@ -3165,10 +3165,10 @@ s[len-1] = '\0'; // tty->print_cr("checking \"%s\" for \"%s\"", s, typeName); if (recursiveFindType(origtypes, s, true) == 1) { - delete s; + delete [] s; return 1; } - delete s; + delete [] s; } if (strstr(typeName, "const ") == typeName) { const char * s = typeName + strlen("const "); @@ -3182,8 +3182,10 @@ s[len - 6] = '\0'; // tty->print_cr("checking \"%s\" for \"%s\"", s, typeName); if (recursiveFindType(origtypes, s, true) == 1) { + free(s); return 1; } + free(s); } if (!isRecurse) { tty->print_cr("type \"%s\" not found", typeName); From bengt.rutisson at oracle.com Wed Dec 12 22:42:06 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 13 Dec 2012 07:42:06 +0100 Subject: Request for review (s): 7173959 : Jvm crashed during coherence exabus (tmb) testing Message-ID: <50C978BE.8040405@oracle.com> Hi all, Could I have a couple of reviews for this change? http://cr.openjdk.java.net/~brutisso/7173959/webrev.00/ This is for a bug originally reported by the Coherence team: 7173959 : Jvm crashed during coherence exabus (tmb) testing http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173959 The original analysis and proposed fix was done by Mikael Gerdin and me together. I'll handle the webrev and push since Mikael is on vacation starting today. But Mikael did a great job tracking down this very difficult bug, so he should have a large part of the credit for this bug fix, Description from the CR: The reason that we crash is due to how we re-map memory when we want to align it for large pages in ReservedSpace::initialize(). Here is what happens: The reservation of memory is split up to a few steps. When we want a chunk of memory with large pages we first just reserve some memory large enough for what we need. Then we realize that we want large pages, so we want to re-map the reserved memory to use large pages. But since this requires that we have a large-page-aligned memory chunk we may have to fix the recently reserved memory chunk up a bit. We do this in ReservedSpace::initialize() by first releasing the memory we just reserved. Then requesting more memory than we actually need to make sure that we have enough space to do manual large page alignment. After we have gotten this memory we figure out a nicely aligned start address. We then release the memory again and then reserve just enough memory but using the aligned start address as a fixed address to make sure that we get the memory we wanted in an aligned way. This is done in a loop to make sure that we eventually get some memory. The interesting code looks like this: do { char* extra_base = os::reserve_memory(extra_size, NULL, alignment); if (extra_base == NULL) return; // Do manual alignement base = (char*) align_size_up((uintptr_t) extra_base, alignment); assert(base >= extra_base, "just checking"); // Re-reserve the region at the aligned base address. os::release_memory(extra_base, extra_size); // (1) base = os::reserve_memory(size, base); // (2) } while (base == NULL); There is a race here between releasing the memory in (1) and re-reserving it in (2). But the loop is supposed to handle this race. The problem is that on posix platforms you can remap the same memory area several times. The call in (2) will use mmap with MAP_FIXED. This means that the OS will think that you know exactly what you are doing. So, if part of the memory has been mapped already by the process it will just go ahead and reuse that memory. This means that if we are having multiple threads that do mmap. We can end up with a situation where we release our mapping in (1). Then another thread comes in and maps part of the memory that we used to have. Then we remap over that memory again in (2) with MAP_FIXED. Now we have a situation where two threads in our process have mapped the same memory. If both threads try to use it or if one of the threads unmap part or all of the memory we will crash. On posix it is possible to unmap any part of a mapped chunk. So, our proposed solution to the race described above is to not unmap all memory in (1) but rather just unmap the section at the start and at the end of the chunk that we mapped to get alignment. This also removes the need for the loop. However, on Windows you can only unmap _all_ of the memory that you have mapped. On the other hand Windows also will not allow you to map over other mappings, so the original code is actually safe. If we keep the loop. So, our solution is to treat this differently on Windows and posix platforms. Thanks, Bengt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121213/ac6a8fa0/attachment.html From david.holmes at oracle.com Wed Dec 12 23:33:46 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Dec 2012 17:33:46 +1000 Subject: Request for review (s): 7173959 : Jvm crashed during coherence exabus (tmb) testing In-Reply-To: <50C978BE.8040405@oracle.com> References: <50C978BE.8040405@oracle.com> Message-ID: <50C984DA.1070400@oracle.com> Hi Bengt, This has to be one of the absolute best review requests I've ever read :) Thank you. Just a couple of queries. os_posix.cpp: Love the diagram :) I'm assuming that "alignment" has to be >= the underlying page size, and in fact must be a multiple of the underlying page size ? (As I assume you can only unmap whole numbers of pages). If so does that need to be checked somewhere? In virtualSpace.cpp: // Reserve size large enough to do manual alignment and // increase size to a multiple of the desired alignment size = align_size_up(size, alignment); ! base = os::reserve_memory_aligned(size, alignment); The comment doesn't seem necessary now, and the align_size_up seems redundant. Thanks, David On 13/12/2012 4:42 PM, Bengt Rutisson wrote: > > Hi all, > > Could I have a couple of reviews for this change? > > http://cr.openjdk.java.net/~brutisso/7173959/webrev.00/ > > This is for a bug originally reported by the Coherence team: > > 7173959 : Jvm crashed during coherence exabus (tmb) testing > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173959 > > The original analysis and proposed fix was done by Mikael Gerdin and me > together. I'll handle the webrev and push since Mikael is on vacation > starting today. But Mikael did a great job tracking down this very > difficult bug, so he should have a large part of the credit for this bug > fix, > > Description from the CR: > > The reason that we crash is due to how we re-map memory when we want to > align it for large pages in ReservedSpace::initialize(). > > Here is what happens: > > The reservation of memory is split up to a few steps. When we want a > chunk of memory with large pages we first just reserve some memory large > enough for what we need. Then we realize that we want large pages, so we > want to re-map the reserved memory to use large pages. But since this > requires that we have a large-page-aligned memory chunk we may have to > fix the recently reserved memory chunk up a bit. > > We do this in ReservedSpace::initialize() by first releasing the memory > we just reserved. Then requesting more memory than we actually need to > make sure that we have enough space to do manual large page alignment. > After we have gotten this memory we figure out a nicely aligned start > address. We then release the memory again and then reserve just enough > memory but using the aligned start address as a fixed address to make > sure that we get the memory we wanted in an aligned way. > > This is done in a loop to make sure that we eventually get some memory. > The interesting code looks like this: > > do { > char* extra_base = os::reserve_memory(extra_size, NULL, alignment); > if (extra_base == NULL) return; > // Do manual alignement > base = (char*) align_size_up((uintptr_t) extra_base, alignment); > assert(base >= extra_base, "just checking"); > // Re-reserve the region at the aligned base address. > os::release_memory(extra_base, extra_size); // (1) > base = os::reserve_memory(size, base); // (2) > } while (base == NULL); > > > There is a race here between releasing the memory in (1) and > re-reserving it in (2). But the loop is supposed to handle this race. > > The problem is that on posix platforms you can remap the same memory > area several times. The call in (2) will use mmap with MAP_FIXED. This > means that the OS will think that you know exactly what you are doing. > So, if part of the memory has been mapped already by the process it will > just go ahead and reuse that memory. > > This means that if we are having multiple threads that do mmap. We can > end up with a situation where we release our mapping in (1). Then > another thread comes in and maps part of the memory that we used to > have. Then we remap over that memory again in (2) with MAP_FIXED. Now we > have a situation where two threads in our process have mapped the same > memory. If both threads try to use it or if one of the threads unmap > part or all of the memory we will crash. > > On posix it is possible to unmap any part of a mapped chunk. So, our > proposed solution to the race described above is to not unmap all memory > in (1) but rather just unmap the section at the start and at the end of > the chunk that we mapped to get alignment. This also removes the need > for the loop. > > However, on Windows you can only unmap _all_ of the memory that you have > mapped. On the other hand Windows also will not allow you to map over > other mappings, so the original code is actually safe. If we keep the loop. > > So, our solution is to treat this differently on Windows and posix > platforms. > > > Thanks, > Bengt From erik.helin at oracle.com Wed Dec 12 23:45:50 2012 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 13 Dec 2012 08:45:50 +0100 Subject: RFR (XS): 8004661: Comment and function name java_lang_String::toHash is wrong In-Reply-To: <50C8AA70.2000101@oracle.com> References: <50C84E05.6010200@oracle.com> <50C87549.9040402@oracle.com> <50C889B6.40707@oracle.com> <50C89E79.5050800@oracle.com> <50C8AA45.6000608@oracle.com> <50C8AA70.2000101@oracle.com> Message-ID: <50C987AE.20805@oracle.com> Thanks! Erik On 12/12/2012 05:01 PM, Bengt Rutisson wrote: > > Looks good, Erik! > > Bengt > > On 12/12/12 5:01 PM, Erik Helin wrote: >> On 12/12/2012 04:10 PM, Coleen Phillimore wrote: >>> On 12/12/2012 8:42 AM, Erik Helin wrote: >>>> Bengt, >>>> >>>> On 12/12/2012 01:15 PM, Bengt Rutisson wrote: >>>>> Shouldn't the method be called hash_code() rather than hashCode() ? >>>> >>>> This is the standard we use throughout the codebase for the C++ code, >>>> but I believe that the Coleen wanted the name of the method to match >>>> the Java one. >>>> >>>> Coleen, did I understand this correctly? >>>> >>>> I'm fine with using any one of hashCode or hash_code, I think both >>>> suggestions make sense. >>> >>> Yes, I think it should be hash_code to follow our coding conventions but >>> the comments should say hashCode (to match the jdk name). Otherwise, >>> looks great. >> >> Thanks, I've the updated webrev to use hash_code instead of hashCode >> for the C++ function names, please see: >> >> http://cr.openjdk.java.net/~ehelin/8004661/webrev.01/ >> >> Thanks, >> Erik >> >>> Thanks! >>> Coleen >>> >>>> >>>> On 12/12/2012 01:15 PM, Bengt Rutisson wrote: >>>>> Other than that it looks good to me. >>>> >>>> Thanks! >>>> >>>> Erik >>>> >>>>> Bengt >>>>> >>>>> On 12/12/12 10:27 AM, Erik Helin wrote: >>>>>> Hi all, >>>>>> >>>>>> the webrev is located at: >>>>>> http://cr.openjdk.java.net/~ehelin/8004661/webrev.00/ >>>>>> >>>>>> Bug: >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004661 >>>>>> >>>>>> Summary: >>>>>> I've renamed the function to_hash to hashCode and also updated the >>>>>> comments to use hashCode instead of to_hash. >>>>>> >>>>>> Testing: >>>>>> JPRT >>>>>> >>>>>> Thanks, >>>>>> Erik >>>>>> >>>>> >>>> >>> >> > From erik.helin at oracle.com Wed Dec 12 23:46:05 2012 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 13 Dec 2012 08:46:05 +0100 Subject: RFR (XS): 8004661: Comment and function name java_lang_String::toHash is wrong In-Reply-To: <50C918B6.5020809@oracle.com> References: <50C84E05.6010200@oracle.com> <50C87549.9040402@oracle.com> <50C889B6.40707@oracle.com> <50C89E79.5050800@oracle.com> <50C8AA45.6000608@oracle.com> <50C918B6.5020809@oracle.com> Message-ID: <50C987BD.7040001@oracle.com> Thanks! Erik On 12/13/2012 12:52 AM, David Holmes wrote: > Looks fine to me still. > > David > > On 13/12/2012 2:01 AM, Erik Helin wrote: >> On 12/12/2012 04:10 PM, Coleen Phillimore wrote: >>> On 12/12/2012 8:42 AM, Erik Helin wrote: >>>> Bengt, >>>> >>>> On 12/12/2012 01:15 PM, Bengt Rutisson wrote: >>>>> Shouldn't the method be called hash_code() rather than hashCode() ? >>>> >>>> This is the standard we use throughout the codebase for the C++ code, >>>> but I believe that the Coleen wanted the name of the method to match >>>> the Java one. >>>> >>>> Coleen, did I understand this correctly? >>>> >>>> I'm fine with using any one of hashCode or hash_code, I think both >>>> suggestions make sense. >>> >>> Yes, I think it should be hash_code to follow our coding conventions but >>> the comments should say hashCode (to match the jdk name). Otherwise, >>> looks great. >> >> Thanks, I've the updated webrev to use hash_code instead of hashCode for >> the C++ function names, please see: >> >> http://cr.openjdk.java.net/~ehelin/8004661/webrev.01/ >> >> Thanks, >> Erik >> >>> Thanks! >>> Coleen >>> >>>> >>>> On 12/12/2012 01:15 PM, Bengt Rutisson wrote: >>>>> Other than that it looks good to me. >>>> >>>> Thanks! >>>> >>>> Erik >>>> >>>>> Bengt >>>>> >>>>> On 12/12/12 10:27 AM, Erik Helin wrote: >>>>>> Hi all, >>>>>> >>>>>> the webrev is located at: >>>>>> http://cr.openjdk.java.net/~ehelin/8004661/webrev.00/ >>>>>> >>>>>> Bug: >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004661 >>>>>> >>>>>> Summary: >>>>>> I've renamed the function to_hash to hashCode and also updated the >>>>>> comments to use hashCode instead of to_hash. >>>>>> >>>>>> Testing: >>>>>> JPRT >>>>>> >>>>>> Thanks, >>>>>> Erik >>>>>> >>>>> >>>> >>> >> From bengt.rutisson at oracle.com Thu Dec 13 02:02:21 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 13 Dec 2012 11:02:21 +0100 Subject: Request for review (s): 7173959 : Jvm crashed during coherence exabus (tmb) testing In-Reply-To: <50C984DA.1070400@oracle.com> References: <50C978BE.8040405@oracle.com> <50C984DA.1070400@oracle.com> Message-ID: <50C9A7AD.3030307@oracle.com> Hi David, Thanks for looking at this! On 12/13/12 8:33 AM, David Holmes wrote: > Hi Bengt, > > This has to be one of the absolute best review requests I've ever read > :) Thank you. Wow! Thanks! :) > > Just a couple of queries. > > os_posix.cpp: > > Love the diagram :) It was Mikael's way of making sure we got it right. > I'm assuming that "alignment" has to be >= the underlying page size, > and in fact must be a multiple of the underlying page size ? (As I > assume you can only unmap whole numbers of pages). If so does that > need to be checked somewhere? Good point. I'll add an assert to check that. > In virtualSpace.cpp: > > // Reserve size large enough to do manual alignment and > // increase size to a multiple of the desired alignment > size = align_size_up(size, alignment); > ! base = os::reserve_memory_aligned(size, alignment); > > The comment doesn't seem necessary now, and the align_size_up seems > redundant. You are right. I'll remove the comment and the alignment. Thanks, Bengt > > Thanks, > David > > On 13/12/2012 4:42 PM, Bengt Rutisson wrote: >> >> Hi all, >> >> Could I have a couple of reviews for this change? >> >> http://cr.openjdk.java.net/~brutisso/7173959/webrev.00/ >> >> This is for a bug originally reported by the Coherence team: >> >> 7173959 : Jvm crashed during coherence exabus (tmb) testing >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173959 >> >> The original analysis and proposed fix was done by Mikael Gerdin and me >> together. I'll handle the webrev and push since Mikael is on vacation >> starting today. But Mikael did a great job tracking down this very >> difficult bug, so he should have a large part of the credit for this bug >> fix, >> >> Description from the CR: >> >> The reason that we crash is due to how we re-map memory when we want to >> align it for large pages in ReservedSpace::initialize(). >> >> Here is what happens: >> >> The reservation of memory is split up to a few steps. When we want a >> chunk of memory with large pages we first just reserve some memory large >> enough for what we need. Then we realize that we want large pages, so we >> want to re-map the reserved memory to use large pages. But since this >> requires that we have a large-page-aligned memory chunk we may have to >> fix the recently reserved memory chunk up a bit. >> >> We do this in ReservedSpace::initialize() by first releasing the memory >> we just reserved. Then requesting more memory than we actually need to >> make sure that we have enough space to do manual large page alignment. >> After we have gotten this memory we figure out a nicely aligned start >> address. We then release the memory again and then reserve just enough >> memory but using the aligned start address as a fixed address to make >> sure that we get the memory we wanted in an aligned way. >> >> This is done in a loop to make sure that we eventually get some memory. >> The interesting code looks like this: >> >> do { >> char* extra_base = os::reserve_memory(extra_size, NULL, alignment); >> if (extra_base == NULL) return; >> // Do manual alignement >> base = (char*) align_size_up((uintptr_t) extra_base, alignment); >> assert(base >= extra_base, "just checking"); >> // Re-reserve the region at the aligned base address. >> os::release_memory(extra_base, extra_size); // (1) >> base = os::reserve_memory(size, base); // (2) >> } while (base == NULL); >> >> >> There is a race here between releasing the memory in (1) and >> re-reserving it in (2). But the loop is supposed to handle this race. >> >> The problem is that on posix platforms you can remap the same memory >> area several times. The call in (2) will use mmap with MAP_FIXED. This >> means that the OS will think that you know exactly what you are doing. >> So, if part of the memory has been mapped already by the process it will >> just go ahead and reuse that memory. >> >> This means that if we are having multiple threads that do mmap. We can >> end up with a situation where we release our mapping in (1). Then >> another thread comes in and maps part of the memory that we used to >> have. Then we remap over that memory again in (2) with MAP_FIXED. Now we >> have a situation where two threads in our process have mapped the same >> memory. If both threads try to use it or if one of the threads unmap >> part or all of the memory we will crash. >> >> On posix it is possible to unmap any part of a mapped chunk. So, our >> proposed solution to the race described above is to not unmap all memory >> in (1) but rather just unmap the section at the start and at the end of >> the chunk that we mapped to get alignment. This also removes the need >> for the loop. >> >> However, on Windows you can only unmap _all_ of the memory that you have >> mapped. On the other hand Windows also will not allow you to map over >> other mappings, so the original code is actually safe. If we keep the >> loop. >> >> So, our solution is to treat this differently on Windows and posix >> platforms. >> >> >> Thanks, >> Bengt From bengt.rutisson at oracle.com Thu Dec 13 02:37:29 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 13 Dec 2012 11:37:29 +0100 Subject: Request for review (s): 7173959 : Jvm crashed during coherence exabus (tmb) testing In-Reply-To: <50C9A7AD.3030307@oracle.com> References: <50C978BE.8040405@oracle.com> <50C984DA.1070400@oracle.com> <50C9A7AD.3030307@oracle.com> Message-ID: <50C9AFE9.2080601@oracle.com> Hi again, Updated webrev: http://cr.openjdk.java.net/~brutisso/7173959/webrev.01/ I removed the comment and the alignment. But I did not add an assert just yet. At the top of ReservedSpace::initialize() we have this code: const size_t granularity = os::vm_allocation_granularity(); assert((size & (granularity - 1)) == 0, "size not aligned to os::vm_allocation_granularity()"); assert((alignment & (granularity - 1)) == 0, "alignment not aligned to os::vm_allocation_granularity()"); Where os::vm_allocation_granularity() is implemented as page size on all platforms except Windows. There we look it up from the Windows API. I assume that is a page size too, but since the Windows code in our patch does not unmap based on the alignment it should be safe either way. Is this assert enough or would you like me to add an assert closer to the code block were I did the changes? Thanks, Bengt On 12/13/12 11:02 AM, Bengt Rutisson wrote: > > Hi David, > > Thanks for looking at this! > > On 12/13/12 8:33 AM, David Holmes wrote: >> Hi Bengt, >> >> This has to be one of the absolute best review requests I've ever >> read :) Thank you. > > Wow! Thanks! :) > >> >> Just a couple of queries. >> >> os_posix.cpp: >> >> Love the diagram :) > > It was Mikael's way of making sure we got it right. > >> I'm assuming that "alignment" has to be >= the underlying page size, >> and in fact must be a multiple of the underlying page size ? (As I >> assume you can only unmap whole numbers of pages). If so does that >> need to be checked somewhere? > > Good point. I'll add an assert to check that. > >> In virtualSpace.cpp: >> >> // Reserve size large enough to do manual alignment and >> // increase size to a multiple of the desired alignment >> size = align_size_up(size, alignment); >> ! base = os::reserve_memory_aligned(size, alignment); >> >> The comment doesn't seem necessary now, and the align_size_up seems >> redundant. > > You are right. I'll remove the comment and the alignment. > > Thanks, > Bengt > >> >> Thanks, >> David >> >> On 13/12/2012 4:42 PM, Bengt Rutisson wrote: >>> >>> Hi all, >>> >>> Could I have a couple of reviews for this change? >>> >>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.00/ >>> >>> This is for a bug originally reported by the Coherence team: >>> >>> 7173959 : Jvm crashed during coherence exabus (tmb) testing >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173959 >>> >>> The original analysis and proposed fix was done by Mikael Gerdin and me >>> together. I'll handle the webrev and push since Mikael is on vacation >>> starting today. But Mikael did a great job tracking down this very >>> difficult bug, so he should have a large part of the credit for this >>> bug >>> fix, >>> >>> Description from the CR: >>> >>> The reason that we crash is due to how we re-map memory when we want to >>> align it for large pages in ReservedSpace::initialize(). >>> >>> Here is what happens: >>> >>> The reservation of memory is split up to a few steps. When we want a >>> chunk of memory with large pages we first just reserve some memory >>> large >>> enough for what we need. Then we realize that we want large pages, >>> so we >>> want to re-map the reserved memory to use large pages. But since this >>> requires that we have a large-page-aligned memory chunk we may have to >>> fix the recently reserved memory chunk up a bit. >>> >>> We do this in ReservedSpace::initialize() by first releasing the memory >>> we just reserved. Then requesting more memory than we actually need to >>> make sure that we have enough space to do manual large page alignment. >>> After we have gotten this memory we figure out a nicely aligned start >>> address. We then release the memory again and then reserve just enough >>> memory but using the aligned start address as a fixed address to make >>> sure that we get the memory we wanted in an aligned way. >>> >>> This is done in a loop to make sure that we eventually get some memory. >>> The interesting code looks like this: >>> >>> do { >>> char* extra_base = os::reserve_memory(extra_size, NULL, alignment); >>> if (extra_base == NULL) return; >>> // Do manual alignement >>> base = (char*) align_size_up((uintptr_t) extra_base, alignment); >>> assert(base >= extra_base, "just checking"); >>> // Re-reserve the region at the aligned base address. >>> os::release_memory(extra_base, extra_size); // (1) >>> base = os::reserve_memory(size, base); // (2) >>> } while (base == NULL); >>> >>> >>> There is a race here between releasing the memory in (1) and >>> re-reserving it in (2). But the loop is supposed to handle this race. >>> >>> The problem is that on posix platforms you can remap the same memory >>> area several times. The call in (2) will use mmap with MAP_FIXED. This >>> means that the OS will think that you know exactly what you are doing. >>> So, if part of the memory has been mapped already by the process it >>> will >>> just go ahead and reuse that memory. >>> >>> This means that if we are having multiple threads that do mmap. We can >>> end up with a situation where we release our mapping in (1). Then >>> another thread comes in and maps part of the memory that we used to >>> have. Then we remap over that memory again in (2) with MAP_FIXED. >>> Now we >>> have a situation where two threads in our process have mapped the same >>> memory. If both threads try to use it or if one of the threads unmap >>> part or all of the memory we will crash. >>> >>> On posix it is possible to unmap any part of a mapped chunk. So, our >>> proposed solution to the race described above is to not unmap all >>> memory >>> in (1) but rather just unmap the section at the start and at the end of >>> the chunk that we mapped to get alignment. This also removes the need >>> for the loop. >>> >>> However, on Windows you can only unmap _all_ of the memory that you >>> have >>> mapped. On the other hand Windows also will not allow you to map over >>> other mappings, so the original code is actually safe. If we keep >>> the loop. >>> >>> So, our solution is to treat this differently on Windows and posix >>> platforms. >>> >>> >>> Thanks, >>> Bengt > From david.holmes at oracle.com Thu Dec 13 02:50:20 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Dec 2012 20:50:20 +1000 Subject: Request for review (s): 7173959 : Jvm crashed during coherence exabus (tmb) testing In-Reply-To: <50C9AFE9.2080601@oracle.com> References: <50C978BE.8040405@oracle.com> <50C984DA.1070400@oracle.com> <50C9A7AD.3030307@oracle.com> <50C9AFE9.2080601@oracle.com> Message-ID: <50C9B2EC.5090008@oracle.com> On 13/12/2012 8:37 PM, Bengt Rutisson wrote: > > Hi again, > > Updated webrev: > http://cr.openjdk.java.net/~brutisso/7173959/webrev.01/ > > I removed the comment and the alignment. > > But I did not add an assert just yet. > > At the top of ReservedSpace::initialize() we have this code: > > const size_t granularity = os::vm_allocation_granularity(); > assert((size & (granularity - 1)) == 0, > "size not aligned to os::vm_allocation_granularity()"); > assert((alignment & (granularity - 1)) == 0, > "alignment not aligned to os::vm_allocation_granularity()"); > > > Where os::vm_allocation_granularity() is implemented as page size on all > platforms except Windows. There we look it up from the Windows API. I > assume that is a page size too, but since the Windows code in our patch > does not unmap based on the alignment it should be safe either way. > > Is this assert enough or would you like me to add an assert closer to > the code block were I did the changes? As this is a separate method now I think an assert in the method itself would not go astray. David ----- > Thanks, > Bengt > > > On 12/13/12 11:02 AM, Bengt Rutisson wrote: >> >> Hi David, >> >> Thanks for looking at this! >> >> On 12/13/12 8:33 AM, David Holmes wrote: >>> Hi Bengt, >>> >>> This has to be one of the absolute best review requests I've ever >>> read :) Thank you. >> >> Wow! Thanks! :) >> >>> >>> Just a couple of queries. >>> >>> os_posix.cpp: >>> >>> Love the diagram :) >> >> It was Mikael's way of making sure we got it right. >> >>> I'm assuming that "alignment" has to be >= the underlying page size, >>> and in fact must be a multiple of the underlying page size ? (As I >>> assume you can only unmap whole numbers of pages). If so does that >>> need to be checked somewhere? >> >> Good point. I'll add an assert to check that. >> >>> In virtualSpace.cpp: >>> >>> // Reserve size large enough to do manual alignment and >>> // increase size to a multiple of the desired alignment >>> size = align_size_up(size, alignment); >>> ! base = os::reserve_memory_aligned(size, alignment); >>> >>> The comment doesn't seem necessary now, and the align_size_up seems >>> redundant. >> >> You are right. I'll remove the comment and the alignment. >> >> Thanks, >> Bengt >> >>> >>> Thanks, >>> David >>> >>> On 13/12/2012 4:42 PM, Bengt Rutisson wrote: >>>> >>>> Hi all, >>>> >>>> Could I have a couple of reviews for this change? >>>> >>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.00/ >>>> >>>> This is for a bug originally reported by the Coherence team: >>>> >>>> 7173959 : Jvm crashed during coherence exabus (tmb) testing >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173959 >>>> >>>> The original analysis and proposed fix was done by Mikael Gerdin and me >>>> together. I'll handle the webrev and push since Mikael is on vacation >>>> starting today. But Mikael did a great job tracking down this very >>>> difficult bug, so he should have a large part of the credit for this >>>> bug >>>> fix, >>>> >>>> Description from the CR: >>>> >>>> The reason that we crash is due to how we re-map memory when we want to >>>> align it for large pages in ReservedSpace::initialize(). >>>> >>>> Here is what happens: >>>> >>>> The reservation of memory is split up to a few steps. When we want a >>>> chunk of memory with large pages we first just reserve some memory >>>> large >>>> enough for what we need. Then we realize that we want large pages, >>>> so we >>>> want to re-map the reserved memory to use large pages. But since this >>>> requires that we have a large-page-aligned memory chunk we may have to >>>> fix the recently reserved memory chunk up a bit. >>>> >>>> We do this in ReservedSpace::initialize() by first releasing the memory >>>> we just reserved. Then requesting more memory than we actually need to >>>> make sure that we have enough space to do manual large page alignment. >>>> After we have gotten this memory we figure out a nicely aligned start >>>> address. We then release the memory again and then reserve just enough >>>> memory but using the aligned start address as a fixed address to make >>>> sure that we get the memory we wanted in an aligned way. >>>> >>>> This is done in a loop to make sure that we eventually get some memory. >>>> The interesting code looks like this: >>>> >>>> do { >>>> char* extra_base = os::reserve_memory(extra_size, NULL, alignment); >>>> if (extra_base == NULL) return; >>>> // Do manual alignement >>>> base = (char*) align_size_up((uintptr_t) extra_base, alignment); >>>> assert(base >= extra_base, "just checking"); >>>> // Re-reserve the region at the aligned base address. >>>> os::release_memory(extra_base, extra_size); // (1) >>>> base = os::reserve_memory(size, base); // (2) >>>> } while (base == NULL); >>>> >>>> >>>> There is a race here between releasing the memory in (1) and >>>> re-reserving it in (2). But the loop is supposed to handle this race. >>>> >>>> The problem is that on posix platforms you can remap the same memory >>>> area several times. The call in (2) will use mmap with MAP_FIXED. This >>>> means that the OS will think that you know exactly what you are doing. >>>> So, if part of the memory has been mapped already by the process it >>>> will >>>> just go ahead and reuse that memory. >>>> >>>> This means that if we are having multiple threads that do mmap. We can >>>> end up with a situation where we release our mapping in (1). Then >>>> another thread comes in and maps part of the memory that we used to >>>> have. Then we remap over that memory again in (2) with MAP_FIXED. >>>> Now we >>>> have a situation where two threads in our process have mapped the same >>>> memory. If both threads try to use it or if one of the threads unmap >>>> part or all of the memory we will crash. >>>> >>>> On posix it is possible to unmap any part of a mapped chunk. So, our >>>> proposed solution to the race described above is to not unmap all >>>> memory >>>> in (1) but rather just unmap the section at the start and at the end of >>>> the chunk that we mapped to get alignment. This also removes the need >>>> for the loop. >>>> >>>> However, on Windows you can only unmap _all_ of the memory that you >>>> have >>>> mapped. On the other hand Windows also will not allow you to map over >>>> other mappings, so the original code is actually safe. If we keep >>>> the loop. >>>> >>>> So, our solution is to treat this differently on Windows and posix >>>> platforms. >>>> >>>> >>>> Thanks, >>>> Bengt >> > From bengt.rutisson at oracle.com Thu Dec 13 04:58:25 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 13 Dec 2012 13:58:25 +0100 Subject: Request for review (s): 7173959 : Jvm crashed during coherence exabus (tmb) testing In-Reply-To: <50C9B2EC.5090008@oracle.com> References: <50C978BE.8040405@oracle.com> <50C984DA.1070400@oracle.com> <50C9A7AD.3030307@oracle.com> <50C9AFE9.2080601@oracle.com> <50C9B2EC.5090008@oracle.com> Message-ID: <50C9D0F1.9040501@oracle.com> Hi David, Updated webrev: http://cr.openjdk.java.net/~brutisso/7173959/webrev.02/ I moved the alignment of "size" back into ReservedSpace::initialize() since we actually store the size in an instance variable (_size), so I think it is a bit risky to just do the align_up in os::reserve_memory_aligned(). We probably want the instance variables _size and _alignment in ReservedSpace to be consistent. I added an assert in os::reserve_memory_aligned() to verify that the size is correctly aligned. I also added the assert you suggested to check that alignment is page size aligned. Bengt On 12/13/12 11:50 AM, David Holmes wrote: > On 13/12/2012 8:37 PM, Bengt Rutisson wrote: >> >> Hi again, >> >> Updated webrev: >> http://cr.openjdk.java.net/~brutisso/7173959/webrev.01/ >> >> I removed the comment and the alignment. >> >> But I did not add an assert just yet. >> >> At the top of ReservedSpace::initialize() we have this code: >> >> const size_t granularity = os::vm_allocation_granularity(); >> assert((size & (granularity - 1)) == 0, >> "size not aligned to os::vm_allocation_granularity()"); >> assert((alignment & (granularity - 1)) == 0, >> "alignment not aligned to os::vm_allocation_granularity()"); >> >> >> Where os::vm_allocation_granularity() is implemented as page size on all >> platforms except Windows. There we look it up from the Windows API. I >> assume that is a page size too, but since the Windows code in our patch >> does not unmap based on the alignment it should be safe either way. >> >> Is this assert enough or would you like me to add an assert closer to >> the code block were I did the changes? > > As this is a separate method now I think an assert in the method > itself would not go astray. > > David > ----- > >> Thanks, >> Bengt >> >> >> On 12/13/12 11:02 AM, Bengt Rutisson wrote: >>> >>> Hi David, >>> >>> Thanks for looking at this! >>> >>> On 12/13/12 8:33 AM, David Holmes wrote: >>>> Hi Bengt, >>>> >>>> This has to be one of the absolute best review requests I've ever >>>> read :) Thank you. >>> >>> Wow! Thanks! :) >>> >>>> >>>> Just a couple of queries. >>>> >>>> os_posix.cpp: >>>> >>>> Love the diagram :) >>> >>> It was Mikael's way of making sure we got it right. >>> >>>> I'm assuming that "alignment" has to be >= the underlying page size, >>>> and in fact must be a multiple of the underlying page size ? (As I >>>> assume you can only unmap whole numbers of pages). If so does that >>>> need to be checked somewhere? >>> >>> Good point. I'll add an assert to check that. >>> >>>> In virtualSpace.cpp: >>>> >>>> // Reserve size large enough to do manual alignment and >>>> // increase size to a multiple of the desired alignment >>>> size = align_size_up(size, alignment); >>>> ! base = os::reserve_memory_aligned(size, alignment); >>>> >>>> The comment doesn't seem necessary now, and the align_size_up seems >>>> redundant. >>> >>> You are right. I'll remove the comment and the alignment. >>> >>> Thanks, >>> Bengt >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 13/12/2012 4:42 PM, Bengt Rutisson wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Could I have a couple of reviews for this change? >>>>> >>>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.00/ >>>>> >>>>> This is for a bug originally reported by the Coherence team: >>>>> >>>>> 7173959 : Jvm crashed during coherence exabus (tmb) testing >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173959 >>>>> >>>>> The original analysis and proposed fix was done by Mikael Gerdin >>>>> and me >>>>> together. I'll handle the webrev and push since Mikael is on vacation >>>>> starting today. But Mikael did a great job tracking down this very >>>>> difficult bug, so he should have a large part of the credit for this >>>>> bug >>>>> fix, >>>>> >>>>> Description from the CR: >>>>> >>>>> The reason that we crash is due to how we re-map memory when we >>>>> want to >>>>> align it for large pages in ReservedSpace::initialize(). >>>>> >>>>> Here is what happens: >>>>> >>>>> The reservation of memory is split up to a few steps. When we want a >>>>> chunk of memory with large pages we first just reserve some memory >>>>> large >>>>> enough for what we need. Then we realize that we want large pages, >>>>> so we >>>>> want to re-map the reserved memory to use large pages. But since this >>>>> requires that we have a large-page-aligned memory chunk we may >>>>> have to >>>>> fix the recently reserved memory chunk up a bit. >>>>> >>>>> We do this in ReservedSpace::initialize() by first releasing the >>>>> memory >>>>> we just reserved. Then requesting more memory than we actually >>>>> need to >>>>> make sure that we have enough space to do manual large page >>>>> alignment. >>>>> After we have gotten this memory we figure out a nicely aligned start >>>>> address. We then release the memory again and then reserve just >>>>> enough >>>>> memory but using the aligned start address as a fixed address to make >>>>> sure that we get the memory we wanted in an aligned way. >>>>> >>>>> This is done in a loop to make sure that we eventually get some >>>>> memory. >>>>> The interesting code looks like this: >>>>> >>>>> do { >>>>> char* extra_base = os::reserve_memory(extra_size, NULL, alignment); >>>>> if (extra_base == NULL) return; >>>>> // Do manual alignement >>>>> base = (char*) align_size_up((uintptr_t) extra_base, alignment); >>>>> assert(base >= extra_base, "just checking"); >>>>> // Re-reserve the region at the aligned base address. >>>>> os::release_memory(extra_base, extra_size); // (1) >>>>> base = os::reserve_memory(size, base); // (2) >>>>> } while (base == NULL); >>>>> >>>>> >>>>> There is a race here between releasing the memory in (1) and >>>>> re-reserving it in (2). But the loop is supposed to handle this race. >>>>> >>>>> The problem is that on posix platforms you can remap the same memory >>>>> area several times. The call in (2) will use mmap with MAP_FIXED. >>>>> This >>>>> means that the OS will think that you know exactly what you are >>>>> doing. >>>>> So, if part of the memory has been mapped already by the process it >>>>> will >>>>> just go ahead and reuse that memory. >>>>> >>>>> This means that if we are having multiple threads that do mmap. We >>>>> can >>>>> end up with a situation where we release our mapping in (1). Then >>>>> another thread comes in and maps part of the memory that we used to >>>>> have. Then we remap over that memory again in (2) with MAP_FIXED. >>>>> Now we >>>>> have a situation where two threads in our process have mapped the >>>>> same >>>>> memory. If both threads try to use it or if one of the threads unmap >>>>> part or all of the memory we will crash. >>>>> >>>>> On posix it is possible to unmap any part of a mapped chunk. So, our >>>>> proposed solution to the race described above is to not unmap all >>>>> memory >>>>> in (1) but rather just unmap the section at the start and at the >>>>> end of >>>>> the chunk that we mapped to get alignment. This also removes the need >>>>> for the loop. >>>>> >>>>> However, on Windows you can only unmap _all_ of the memory that you >>>>> have >>>>> mapped. On the other hand Windows also will not allow you to map over >>>>> other mappings, so the original code is actually safe. If we keep >>>>> the loop. >>>>> >>>>> So, our solution is to treat this differently on Windows and posix >>>>> platforms. >>>>> >>>>> >>>>> Thanks, >>>>> Bengt >>> >> From vitalyd at gmail.com Thu Dec 13 05:44:50 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 13 Dec 2012 08:44:50 -0500 Subject: Request for review (s): 7173959 : Jvm crashed during coherence exabus (tmb) testing In-Reply-To: <50C9D0F1.9040501@oracle.com> References: <50C978BE.8040405@oracle.com> <50C984DA.1070400@oracle.com> <50C9A7AD.3030307@oracle.com> <50C9AFE9.2080601@oracle.com> <50C9B2EC.5090008@oracle.com> <50C9D0F1.9040501@oracle.com> Message-ID: Hi Bengt, Great write-up! What was in the hs_err file that led you (or Mikael) here? One question I have is why alignment is a multiple of page size and not page size? I imagine callers want to reserve X space and have it page aligned up if necessary. When would someone request multiple page size alignment rather than just increase requested allocation amount and keep alignment at page size? If huge pages are used then vm_allocation_granularity() respects that, right? Or is this for transparent huge page support? Hope that makes sense. The other question is whether it's worth it to check for overflow in the new os_posix function? There are some additions and subtractions on size_t values and maybe on 32 bit some of those adds can overflow a temporary? Specifically, line 118. Disregard if that's not needed :). Thanks Sent from my phone On Dec 13, 2012 7:59 AM, "Bengt Rutisson" wrote: > > Hi David, > > Updated webrev: > http://cr.openjdk.java.net/~**brutisso/7173959/webrev.02/ > > I moved the alignment of "size" back into ReservedSpace::initialize() > since we actually store the size in an instance variable (_size), so I > think it is a bit risky to just do the align_up in > os::reserve_memory_aligned(). We probably want the instance variables _size > and _alignment in ReservedSpace to be consistent. > > I added an assert in os::reserve_memory_aligned() to verify that the size > is correctly aligned. I also added the assert you suggested to check that > alignment is page size aligned. > > Bengt > > On 12/13/12 11:50 AM, David Holmes wrote: > >> On 13/12/2012 8:37 PM, Bengt Rutisson wrote: >> >>> >>> Hi again, >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~**brutisso/7173959/webrev.01/ >>> >>> I removed the comment and the alignment. >>> >>> But I did not add an assert just yet. >>> >>> At the top of ReservedSpace::initialize() we have this code: >>> >>> const size_t granularity = os::vm_allocation_granularity(**); >>> assert((size & (granularity - 1)) == 0, >>> "size not aligned to os::vm_allocation_granularity(**)"); >>> assert((alignment & (granularity - 1)) == 0, >>> "alignment not aligned to os::vm_allocation_granularity(**)"); >>> >>> >>> Where os::vm_allocation_granularity(**) is implemented as page size on >>> all >>> platforms except Windows. There we look it up from the Windows API. I >>> assume that is a page size too, but since the Windows code in our patch >>> does not unmap based on the alignment it should be safe either way. >>> >>> Is this assert enough or would you like me to add an assert closer to >>> the code block were I did the changes? >>> >> >> As this is a separate method now I think an assert in the method itself >> would not go astray. >> >> David >> ----- >> >> Thanks, >>> Bengt >>> >>> >>> On 12/13/12 11:02 AM, Bengt Rutisson wrote: >>> >>>> >>>> Hi David, >>>> >>>> Thanks for looking at this! >>>> >>>> On 12/13/12 8:33 AM, David Holmes wrote: >>>> >>>>> Hi Bengt, >>>>> >>>>> This has to be one of the absolute best review requests I've ever >>>>> read :) Thank you. >>>>> >>>> >>>> Wow! Thanks! :) >>>> >>>> >>>>> Just a couple of queries. >>>>> >>>>> os_posix.cpp: >>>>> >>>>> Love the diagram :) >>>>> >>>> >>>> It was Mikael's way of making sure we got it right. >>>> >>>> I'm assuming that "alignment" has to be >= the underlying page size, >>>>> and in fact must be a multiple of the underlying page size ? (As I >>>>> assume you can only unmap whole numbers of pages). If so does that >>>>> need to be checked somewhere? >>>>> >>>> >>>> Good point. I'll add an assert to check that. >>>> >>>> In virtualSpace.cpp: >>>>> >>>>> // Reserve size large enough to do manual alignment and >>>>> // increase size to a multiple of the desired alignment >>>>> size = align_size_up(size, alignment); >>>>> ! base = os::reserve_memory_aligned(**size, alignment); >>>>> >>>>> The comment doesn't seem necessary now, and the align_size_up seems >>>>> redundant. >>>>> >>>> >>>> You are right. I'll remove the comment and the alignment. >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 13/12/2012 4:42 PM, Bengt Rutisson wrote: >>>>> >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Could I have a couple of reviews for this change? >>>>>> >>>>>> http://cr.openjdk.java.net/~**brutisso/7173959/webrev.00/ >>>>>> >>>>>> This is for a bug originally reported by the Coherence team: >>>>>> >>>>>> 7173959 : Jvm crashed during coherence exabus (tmb) testing >>>>>> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=7173959 >>>>>> >>>>>> The original analysis and proposed fix was done by Mikael Gerdin and >>>>>> me >>>>>> together. I'll handle the webrev and push since Mikael is on vacation >>>>>> starting today. But Mikael did a great job tracking down this very >>>>>> difficult bug, so he should have a large part of the credit for this >>>>>> bug >>>>>> fix, >>>>>> >>>>>> Description from the CR: >>>>>> >>>>>> The reason that we crash is due to how we re-map memory when we want >>>>>> to >>>>>> align it for large pages in ReservedSpace::initialize(). >>>>>> >>>>>> Here is what happens: >>>>>> >>>>>> The reservation of memory is split up to a few steps. When we want a >>>>>> chunk of memory with large pages we first just reserve some memory >>>>>> large >>>>>> enough for what we need. Then we realize that we want large pages, >>>>>> so we >>>>>> want to re-map the reserved memory to use large pages. But since this >>>>>> requires that we have a large-page-aligned memory chunk we may have to >>>>>> fix the recently reserved memory chunk up a bit. >>>>>> >>>>>> We do this in ReservedSpace::initialize() by first releasing the >>>>>> memory >>>>>> we just reserved. Then requesting more memory than we actually need to >>>>>> make sure that we have enough space to do manual large page alignment. >>>>>> After we have gotten this memory we figure out a nicely aligned start >>>>>> address. We then release the memory again and then reserve just enough >>>>>> memory but using the aligned start address as a fixed address to make >>>>>> sure that we get the memory we wanted in an aligned way. >>>>>> >>>>>> This is done in a loop to make sure that we eventually get some >>>>>> memory. >>>>>> The interesting code looks like this: >>>>>> >>>>>> do { >>>>>> char* extra_base = os::reserve_memory(extra_size, NULL, alignment); >>>>>> if (extra_base == NULL) return; >>>>>> // Do manual alignement >>>>>> base = (char*) align_size_up((uintptr_t) extra_base, alignment); >>>>>> assert(base >= extra_base, "just checking"); >>>>>> // Re-reserve the region at the aligned base address. >>>>>> os::release_memory(extra_base, extra_size); // (1) >>>>>> base = os::reserve_memory(size, base); // (2) >>>>>> } while (base == NULL); >>>>>> >>>>>> >>>>>> There is a race here between releasing the memory in (1) and >>>>>> re-reserving it in (2). But the loop is supposed to handle this race. >>>>>> >>>>>> The problem is that on posix platforms you can remap the same memory >>>>>> area several times. The call in (2) will use mmap with MAP_FIXED. This >>>>>> means that the OS will think that you know exactly what you are doing. >>>>>> So, if part of the memory has been mapped already by the process it >>>>>> will >>>>>> just go ahead and reuse that memory. >>>>>> >>>>>> This means that if we are having multiple threads that do mmap. We can >>>>>> end up with a situation where we release our mapping in (1). Then >>>>>> another thread comes in and maps part of the memory that we used to >>>>>> have. Then we remap over that memory again in (2) with MAP_FIXED. >>>>>> Now we >>>>>> have a situation where two threads in our process have mapped the same >>>>>> memory. If both threads try to use it or if one of the threads unmap >>>>>> part or all of the memory we will crash. >>>>>> >>>>>> On posix it is possible to unmap any part of a mapped chunk. So, our >>>>>> proposed solution to the race described above is to not unmap all >>>>>> memory >>>>>> in (1) but rather just unmap the section at the start and at the end >>>>>> of >>>>>> the chunk that we mapped to get alignment. This also removes the need >>>>>> for the loop. >>>>>> >>>>>> However, on Windows you can only unmap _all_ of the memory that you >>>>>> have >>>>>> mapped. On the other hand Windows also will not allow you to map over >>>>>> other mappings, so the original code is actually safe. If we keep >>>>>> the loop. >>>>>> >>>>>> So, our solution is to treat this differently on Windows and posix >>>>>> platforms. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>>> >>>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121213/588d225f/attachment-0001.html From stefan.karlsson at oracle.com Thu Dec 13 10:28:04 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 13 Dec 2012 19:28:04 +0100 Subject: RFR (XS): Add necessary .inline.hpp files to fix non-PCH build In-Reply-To: <50C7AB14.8030208@oracle.com> References: <50C114A4.7070406@oracle.com> <50C7AB14.8030208@oracle.com> Message-ID: <50CA1E34.3060302@oracle.com> Thanks, Coleen. This has now been pushed to hotspot-gc: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/db8a7163c682 StefanK On 12/11/12 10:52 PM, Coleen Phillimore wrote: > > This looks good to me. > Coleen > > On 12/06/2012 04:56 PM, Stefan Karlsson wrote: >> Hi Volker, >> >> Bug created: JDK-8004674 >> >> Thanks for fixing this. Your patch looks good. Though, I think it's >> unfortunate that we have to add allocation.inline.hpp whenever this >> 'new' is used. >> >> Can someone who's an official Reviewer also review this? >> >> StefanK >> >> On 2012-11-30 19:51, Volker Simonis wrote: >>> Hi, >>> >>> I'm currently working on "6889002 : CHECK macros in return constructs >>> lead to unreachable code" and just realized that the non-PCH build on >>> Linux is broken (once again). >>> >>> The failure manifests itself with a "libjvm.so: undefined reference to >>> `CHeapObj<(unsigned short)1280>::operator new(unsigned long, unsigned >>> char*)'" which is caused by the recent "6995781: Native memory >>> Tracking" change. The problem is that "operator new" is called in the >>> files "gc_implementation/parallelScavenge/adjoiningVirtualSpaces.cpp" >>> and "gc_implementation/shared/gcStats.cpp" for classes which have the >>> template class "CHeapObj" as their base class. CHeapObj defines its >>> own "new" operator in "memory/allocation.inline.hpp" but this >>> inline.hpp file is not included into >>> "gc_implementation/parallelScavenge/adjoiningVirtualSpaces.cpp" and >>> "gc_implementation/shared/gcStats.cpp". >>> >>> Funny enough, the problem doesn't seem to appear neither for older >>> version of GCC (e.g. 4.4.6 on SLES 10) nor in debug builds. I could >>> only reproduce it with a product build on Ubuntu 12.04 with GCC 4.6.3. >>> The reason is most probably the fact that newer versions of GCC create >>> template instantiations in a much more lazy way. >>> >>> The fix is easy - just add the missing includes to the corresponding >>> files (see attached patch). >>> Could somebody please open a bug for this issue and review/commit >>> the change. >>> >>> Please notice that this actually not exactly the annoying "inline.hpp" >>> problem which will be addressed with "8003990: Clean up inline >>> #includes" but very similar because template definition and >>> instantiation have similar semantics. This only didn't caused any >>> problems until now because templates have been used very little in >>> HotSpot. However once this changes, special care has to be taken to >>> manage them in a way every compiler can cope with. >>> >>> Thank you and best regards, >>> Volker >> > From daniel.daugherty at oracle.com Thu Dec 13 10:53:10 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 13 Dec 2012 11:53:10 -0700 Subject: code review request for 7153050 remove crufty '_g' support Message-ID: <50CA2416.9070806@oracle.com> Greetings, I'm sponsoring this code review request from Ron Durbin. This change is targeted at JDK8/HSX-25 in the RT_Baseline repo. Please make sure you include Ron on any e-mail replies since he is not yet on the OpenJDK aliases. Dan Intro: This set of changes removes the makefile support for generation of debug versions that follow _g semantics. Defect: 7153050 ?remove crufty '_g' support from HotSpot repo? http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153050 https://jbs.oracle.com/bugs/browse/JDK-7153050 Webrev http://cr.openjdk.java.net/~dcubed/for_rdurbin/7153050-webrev/0 Details: Many makefiles have been modified to remove all reference and support for debug versions that follow _g semantics. From serguei.spitsyn at oracle.com Thu Dec 13 12:22:51 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 13 Dec 2012 12:22:51 -0800 Subject: code review request for 7153050 remove crufty '_g' support In-Reply-To: <50CA2416.9070806@oracle.com> References: <50CA2416.9070806@oracle.com> Message-ID: <50CA391B.3030509@oracle.com> Dan, It is nice fix and simplified many places. Just one minor comment: make/bsd/makefiles/dtrace.make 41 #LIBJVM_DB = libjvm_db.dylib 42 LIBJVM_DB = libjvm_db.dylib 45 #LIBJVM_DTRACE = libjvm_dtrace.dylib 46 LIBJVM_DTRACE = libjvm_dtrace.dylib The lines #41 and #45 can be removed. Thanks, Serguei On 12/13/12 10:53 AM, Daniel D. Daugherty wrote: > Greetings, > > I'm sponsoring this code review request from Ron Durbin. This change > is targeted at JDK8/HSX-25 in the RT_Baseline repo. Please make sure > you include Ron on any e-mail replies since he is not yet on the > OpenJDK aliases. > > Dan > > > Intro: > > This set of changes removes the makefile support for generation of debug > versions that follow _g semantics. > > Defect: > > 7153050 ?remove crufty '_g' support from HotSpot repo? > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153050 > https://jbs.oracle.com/bugs/browse/JDK-7153050 > > > Webrev > > http://cr.openjdk.java.net/~dcubed/for_rdurbin/7153050-webrev/0 > > Details: > > Many makefiles have been modified to remove all reference and support > for debug versions that follow _g semantics. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121213/fbc69578/attachment.html From daniel.daugherty at oracle.com Thu Dec 13 12:43:54 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 13 Dec 2012 13:43:54 -0700 Subject: code review request for 7153050 remove crufty '_g' support In-Reply-To: <50CA2416.9070806@oracle.com> References: <50CA2416.9070806@oracle.com> Message-ID: <50CA3E0A.6020302@oracle.com> Forgot to mention the testing: These changes were tested with a full JPRT-hotspotwest job. Verified that the JPRT bundles no longer contain _g files: $ pwd /net/prt-archiver.us.oracle.com/data/jprt/archive/2012/12/2012-12-13-030336.ddaugher.7153050_exp/bundles $ for zfile in *.zip; do > echo "zfile=$zfile" > unzip -l "$zfile" | grep _g | grep -v _gcc > done zfile=linux_armsflt_2.6-fastdebugEmb.zip zfile=linux_armsflt_2.6-productEmb.zip zfile=linux_armv6_2.6-fastdebug.zip zfile=linux_armv6_2.6-product.zip zfile=linux_armvfp_2.6-fastdebugEmb.zip zfile=linux_armvfp_2.6-productEmb.zip zfile=linux_i586-fastdebug-c1-wbapitest.zip zfile=linux_i586-fastdebug-c2-wbapitest.zip zfile=linux_i586-product-c1-wbapitest.zip zfile=linux_i586-product-c2-wbapitest.zip zfile=linux_i586_2.6-debug.zip zfile=linux_i586_2.6-debugEmb.zip zfile=linux_i586_2.6-fastdebug.zip zfile=linux_i586_2.6-fastdebugEmb.zip zfile=linux_i586_2.6-product.zip zfile=linux_i586_2.6-productEmb.zip zfile=linux_ppc_2.6-fastdebugEmb.zip zfile=linux_ppc_2.6-productEmb.zip zfile=linux_ppcsflt_2.6-fastdebugEmb.zip zfile=linux_ppcsflt_2.6-productEmb.zip zfile=linux_ppcv2_2.6-fastdebugEmb.zip zfile=linux_ppcv2_2.6-productEmb.zip zfile=linux_x64-fastdebug-c2-wbapitest.zip zfile=linux_x64-product-c2-wbapitest.zip zfile=linux_x64_2.6-fastdebug.zip zfile=linux_x64_2.6-product.zip zfile=linux_x64_2.6-productOpen.zip zfile=macosx_x64_10.7-debug.zip zfile=macosx_x64_10.7-fastdebug.zip zfile=macosx_x64_10.7-product.zip zfile=solaris_i586-fastdebug-c1-wbapitest.zip zfile=solaris_i586-fastdebug-c2-wbapitest.zip zfile=solaris_i586-product-c1-wbapitest.zip zfile=solaris_i586-product-c2-wbapitest.zip zfile=solaris_i586_5.10-debug.zip zfile=solaris_i586_5.10-fastdebug.zip zfile=solaris_i586_5.10-product.zip zfile=solaris_i586_5.10-productOpen.zip zfile=solaris_sparc-fastdebug-c1-wbapitest.zip zfile=solaris_sparc-fastdebug-c2-wbapitest.zip zfile=solaris_sparc-product-c1-wbapitest.zip zfile=solaris_sparc-product-c2-wbapitest.zip zfile=solaris_sparc_5.10-debug.zip zfile=solaris_sparc_5.10-fastdebug.zip zfile=solaris_sparc_5.10-product.zip zfile=solaris_sparcv9-fastdebug-c2-wbapitest.zip zfile=solaris_sparcv9-product-c2-wbapitest.zip zfile=solaris_sparcv9_5.10-debug.zip zfile=solaris_sparcv9_5.10-fastdebug.zip zfile=solaris_sparcv9_5.10-product.zip zfile=solaris_x64-fastdebug-c2-wbapitest.zip zfile=solaris_x64-product-c2-wbapitest.zip zfile=solaris_x64_5.10-debug.zip zfile=solaris_x64_5.10-debugOpen.zip zfile=solaris_x64_5.10-fastdebug.zip zfile=solaris_x64_5.10-product.zip zfile=windows_i586-fastdebug-c1-wbapitest.zip zfile=windows_i586-fastdebug-c2-wbapitest.zip zfile=windows_i586-product-c1-wbapitest.zip zfile=windows_i586-product-c2-wbapitest.zip zfile=windows_i586_5.1-debug.zip zfile=windows_i586_5.1-fastdebug.zip zfile=windows_i586_5.1-product.zip zfile=windows_x64-fastdebug-c2-wbapitest.zip zfile=windows_x64-product-c2-wbapitest.zip zfile=windows_x64_5.2-debug.zip zfile=windows_x64_5.2-fastdebug.zip zfile=windows_x64_5.2-product.zip On 12/13/12 11:53 AM, Daniel D. Daugherty wrote: > Greetings, > > I'm sponsoring this code review request from Ron Durbin. This change > is targeted at JDK8/HSX-25 in the RT_Baseline repo. Please make sure > you include Ron on any e-mail replies since he is not yet on the > OpenJDK aliases. > > Dan > > > Intro: > > This set of changes removes the makefile support for generation of debug > versions that follow _g semantics. > > Defect: > > 7153050 ?remove crufty '_g' support from HotSpot repo? > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153050 > https://jbs.oracle.com/bugs/browse/JDK-7153050 > > > Webrev > > http://cr.openjdk.java.net/~dcubed/for_rdurbin/7153050-webrev/0 > > Details: > > Many makefiles have been modified to remove all reference and support > for debug versions that follow _g semantics. > > From daniel.daugherty at oracle.com Thu Dec 13 12:50:36 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 13 Dec 2012 13:50:36 -0700 Subject: code review request for 7153050 remove crufty '_g' support In-Reply-To: <50CA391B.3030509@oracle.com> References: <50CA2416.9070806@oracle.com> <50CA391B.3030509@oracle.com> Message-ID: <50CA3F9C.5050005@oracle.com> Serguei, Thanks for the fast review! I could swear that Ron had removed lines 41 and 45 in an earlier version. Sigh... Will be fixed. Dan On 12/13/12 1:22 PM, serguei.spitsyn at oracle.com wrote: > Dan, > > It is nice fix and simplified many places. > > Just one minor comment: > > make/bsd/makefiles/dtrace.make > > 41 #LIBJVM_DB = libjvm_db.dylib > 42 LIBJVM_DB = libjvm_db.dylib > > 45 #LIBJVM_DTRACE = libjvm_dtrace.dylib > 46 LIBJVM_DTRACE = libjvm_dtrace.dylib > > The lines #41 and #45 can be removed. > > > Thanks, > Serguei > > > On 12/13/12 10:53 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> I'm sponsoring this code review request from Ron Durbin. This change >> is targeted at JDK8/HSX-25 in the RT_Baseline repo. Please make sure >> you include Ron on any e-mail replies since he is not yet on the >> OpenJDK aliases. >> >> Dan >> >> >> Intro: >> >> This set of changes removes the makefile support for generation of debug >> versions that follow _g semantics. >> >> Defect: >> >> 7153050 ?remove crufty '_g' support from HotSpot repo? >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153050 >> https://jbs.oracle.com/bugs/browse/JDK-7153050 >> >> >> Webrev >> >> http://cr.openjdk.java.net/~dcubed/for_rdurbin/7153050-webrev/0 >> >> Details: >> >> Many makefiles have been modified to remove all reference and support >> for debug versions that follow _g semantics. > From ron.durbin at oracle.com Thu Dec 13 12:52:22 2012 From: ron.durbin at oracle.com (Ron Durbin) Date: Thu, 13 Dec 2012 12:52:22 -0800 (PST) Subject: code review request for 7153050 remove crufty '_g' support In-Reply-To: <50CA391B.3030509@oracle.com> References: <50CA2416.9070806@oracle.com> <50CA391B.3030509@oracle.com> Message-ID: <18c12a94-8f10-4268-8820-40239d2c90e9@default> You are correct Thx Ron From: Serguei Spitsyn Sent: Thursday, December 13, 2012 1:23 PM To: Daniel Daugherty Cc: build-dev; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; Ron Durbin Subject: Re: code review request for 7153050 remove crufty '_g' support Dan, It is nice fix and simplified many places. Just one minor comment: make/bsd/makefiles/dtrace.make 41 #LIBJVM_DB = libjvm_db.dylib 42 LIBJVM_DB = libjvm_db.dylib 45 #LIBJVM_DTRACE = libjvm_dtrace.dylib 46 LIBJVM_DTRACE = libjvm_dtrace.dylib The lines #41 and #45 can be removed. Thanks, Serguei On 12/13/12 10:53 AM, Daniel D. Daugherty wrote: Greetings, I'm sponsoring this code review request from Ron Durbin. This change is targeted at JDK8/HSX-25 in the RT_Baseline repo. Please make sure you include Ron on any e-mail replies since he is not yet on the OpenJDK aliases. Dan Intro: This set of changes removes the makefile support for generation of debug versions that follow _g semantics. Defect: 7153050 "remove crufty '_g' support from HotSpot repo" http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153050 https://jbs.oracle.com/bugs/browse/JDK-7153050 Webrev http://cr.openjdk.java.net/~dcubed/for_rdurbin/7153050-webrev/0 Details: Many makefiles have been modified to remove all reference and support for debug versions that follow _g semantics. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121213/991f1a71/attachment.html From ron.durbin at oracle.com Thu Dec 13 12:53:18 2012 From: ron.durbin at oracle.com (Ron Durbin) Date: Thu, 13 Dec 2012 12:53:18 -0800 (PST) Subject: code review request for 7153050 remove crufty '_g' support In-Reply-To: <50CA3F9C.5050005@oracle.com> References: <50CA2416.9070806@oracle.com> <50CA391B.3030509@oracle.com> <50CA3F9C.5050005@oracle.com> Message-ID: <8f2a9523-5390-41db-bf5d-6ddf8040bc8b@default> Thx again -----Original Message----- From: Daniel D. Daugherty Sent: Thursday, December 13, 2012 1:51 PM To: build-dev; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; Ron Durbin Subject: Re: code review request for 7153050 remove crufty '_g' support Serguei, Thanks for the fast review! I could swear that Ron had removed lines 41 and 45 in an earlier version. Sigh... Will be fixed. Dan On 12/13/12 1:22 PM, serguei.spitsyn at oracle.com wrote: > Dan, > > It is nice fix and simplified many places. > > Just one minor comment: > > make/bsd/makefiles/dtrace.make > > 41 #LIBJVM_DB = libjvm_db.dylib > 42 LIBJVM_DB = libjvm_db.dylib > > 45 #LIBJVM_DTRACE = libjvm_dtrace.dylib > 46 LIBJVM_DTRACE = libjvm_dtrace.dylib > > The lines #41 and #45 can be removed. > > > Thanks, > Serguei > > > On 12/13/12 10:53 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> I'm sponsoring this code review request from Ron Durbin. This change >> is targeted at JDK8/HSX-25 in the RT_Baseline repo. Please make sure >> you include Ron on any e-mail replies since he is not yet on the >> OpenJDK aliases. >> >> Dan >> >> >> Intro: >> >> This set of changes removes the makefile support for generation of >> debug versions that follow _g semantics. >> >> Defect: >> >> 7153050 "remove crufty '_g' support from HotSpot repo" >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153050 >> https://jbs.oracle.com/bugs/browse/JDK-7153050 >> >> >> Webrev >> >> http://cr.openjdk.java.net/~dcubed/for_rdurbin/7153050-webrev/0 >> >> Details: >> >> Many makefiles have been modified to remove all reference and support >> for debug versions that follow _g semantics. > From daniel.daugherty at oracle.com Thu Dec 13 13:10:11 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 13 Dec 2012 14:10:11 -0700 Subject: code review request for 7153050 remove crufty '_g' support In-Reply-To: <50CA2416.9070806@oracle.com> References: <50CA2416.9070806@oracle.com> Message-ID: <50CA4433.6000804@oracle.com> Just for the record: I have reviewed all of Ron's changes and I approve them. Dan On 12/13/12 11:53 AM, Daniel D. Daugherty wrote: > Greetings, > > I'm sponsoring this code review request from Ron Durbin. This change > is targeted at JDK8/HSX-25 in the RT_Baseline repo. Please make sure > you include Ron on any e-mail replies since he is not yet on the > OpenJDK aliases. > > Dan > > > Intro: > > This set of changes removes the makefile support for generation of debug > versions that follow _g semantics. > > Defect: > > 7153050 ?remove crufty '_g' support from HotSpot repo? > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153050 > https://jbs.oracle.com/bugs/browse/JDK-7153050 > > > Webrev > > http://cr.openjdk.java.net/~dcubed/for_rdurbin/7153050-webrev/0 > > Details: > > Many makefiles have been modified to remove all reference and support > for debug versions that follow _g semantics. > > From bengt.rutisson at oracle.com Thu Dec 13 13:23:26 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 13 Dec 2012 22:23:26 +0100 Subject: Request for review (s): 7173959 : Jvm crashed during coherence exabus (tmb) testing In-Reply-To: References: <50C978BE.8040405@oracle.com> <50C984DA.1070400@oracle.com> <50C9A7AD.3030307@oracle.com> <50C9AFE9.2080601@oracle.com> <50C9B2EC.5090008@oracle.com> <50C9D0F1.9040501@oracle.com> Message-ID: <50CA474E.9050808@oracle.com> Hi Vitaly, Thanks for looking at this! On 12/13/12 2:44 PM, Vitaly Davidovich wrote: > > Hi Bengt, > > Great write-up! What was in the hs_err file that led you (or Mikael) here? > Using the core file we noticed that the hotspot internal data structures that keep track of the bitmap sizes did not match the mapped memory listed in the hs_err file. We could see that the mapped memory for the bitmap was smaller than what hotspot had requested. After convincing ourselves that we were passing the correct size to mmap we figured that someone must have been unmapping part of the memory that we had mapped. > One question I have is why alignment is a multiple of page size and > not page size? I imagine callers want to reserve X space and have it > page aligned up if necessary. When would someone request multiple > page size alignment rather than just increase requested allocation > amount and keep alignment at page size? If huge pages are used then > vm_allocation_granularity() respects that, right? Or is this for > transparent huge page support? Hope that makes sense. > One such example is with G1. It wants the heap size to be aligned with the region size, which may be a multiple of the page size. Even with large pages. Actually we also need this for our large page support. The ReservedSpace doesn't really know of large pages. We use it to map memory but then we later on use madvice to make the mapped memory use huge pages. This means that at the time we map the memory we can only rely on the small page size, but if we know we will use it for large pages we have to make sure that the memory is aligned to the large page size. So the alignment will be a multiple of the small page size. > > The other question is whether it's worth it to check for overflow in > the new os_posix function? There are some additions and subtractions > on size_t values and maybe on 32 bit some of those adds can overflow a > temporary? Specifically, line 118. Disregard if that's not needed :). > Good point. I think this change is not really increasing the risk of an overflow compared to the existing code. We should not overflow if we are passed sane values. An overflow will indicate that someone higher up was putting together a too large size. I think I would rather have the upper layers verify that they calculate reasonable values. Thanks for your feedback! Bengt > Thanks > > Sent from my phone > > On Dec 13, 2012 7:59 AM, "Bengt Rutisson" > wrote: > > > Hi David, > > Updated webrev: > http://cr.openjdk.java.net/~brutisso/7173959/webrev.02/ > > > I moved the alignment of "size" back into > ReservedSpace::initialize() since we actually store the size in an > instance variable (_size), so I think it is a bit risky to just do > the align_up in os::reserve_memory_aligned(). We probably want the > instance variables _size and _alignment in ReservedSpace to be > consistent. > > I added an assert in os::reserve_memory_aligned() to verify that > the size is correctly aligned. I also added the assert you > suggested to check that alignment is page size aligned. > > Bengt > > On 12/13/12 11:50 AM, David Holmes wrote: > > On 13/12/2012 8:37 PM, Bengt Rutisson wrote: > > > Hi again, > > Updated webrev: > http://cr.openjdk.java.net/~brutisso/7173959/webrev.01/ > > > I removed the comment and the alignment. > > But I did not add an assert just yet. > > At the top of ReservedSpace::initialize() we have this code: > > const size_t granularity = os::vm_allocation_granularity(); > assert((size & (granularity - 1)) == 0, > "size not aligned to os::vm_allocation_granularity()"); > assert((alignment & (granularity - 1)) == 0, > "alignment not aligned to os::vm_allocation_granularity()"); > > > Where os::vm_allocation_granularity() is implemented as > page size on all > platforms except Windows. There we look it up from the > Windows API. I > assume that is a page size too, but since the Windows code > in our patch > does not unmap based on the alignment it should be safe > either way. > > Is this assert enough or would you like me to add an > assert closer to > the code block were I did the changes? > > > As this is a separate method now I think an assert in the > method itself would not go astray. > > David > ----- > > Thanks, > Bengt > > > On 12/13/12 11:02 AM, Bengt Rutisson wrote: > > > Hi David, > > Thanks for looking at this! > > On 12/13/12 8:33 AM, David Holmes wrote: > > Hi Bengt, > > This has to be one of the absolute best review > requests I've ever > read :) Thank you. > > > Wow! Thanks! :) > > > Just a couple of queries. > > os_posix.cpp: > > Love the diagram :) > > > It was Mikael's way of making sure we got it right. > > I'm assuming that "alignment" has to be >= the > underlying page size, > and in fact must be a multiple of the underlying > page size ? (As I > assume you can only unmap whole numbers of pages). > If so does that > need to be checked somewhere? > > > Good point. I'll add an assert to check that. > > In virtualSpace.cpp: > > // Reserve size large enough to do manual > alignment and > // increase size to a multiple of the desired > alignment > size = align_size_up(size, alignment); > ! base = os::reserve_memory_aligned(size, alignment); > > The comment doesn't seem necessary now, and the > align_size_up seems > redundant. > > > You are right. I'll remove the comment and the alignment. > > Thanks, > Bengt > > > Thanks, > David > > On 13/12/2012 4:42 PM, Bengt Rutisson wrote: > > > Hi all, > > Could I have a couple of reviews for this change? > > http://cr.openjdk.java.net/~brutisso/7173959/webrev.00/ > > > This is for a bug originally reported by the > Coherence team: > > 7173959 : Jvm crashed during coherence exabus > (tmb) testing > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173959 > > The original analysis and proposed fix was > done by Mikael Gerdin and me > together. I'll handle the webrev and push > since Mikael is on vacation > starting today. But Mikael did a great job > tracking down this very > difficult bug, so he should have a large part > of the credit for this > bug > fix, > > Description from the CR: > > The reason that we crash is due to how we > re-map memory when we want to > align it for large pages in > ReservedSpace::initialize(). > > Here is what happens: > > The reservation of memory is split up to a few > steps. When we want a > chunk of memory with large pages we first just > reserve some memory > large > enough for what we need. Then we realize that > we want large pages, > so we > want to re-map the reserved memory to use > large pages. But since this > requires that we have a large-page-aligned > memory chunk we may have to > fix the recently reserved memory chunk up a bit. > > We do this in ReservedSpace::initialize() by > first releasing the memory > we just reserved. Then requesting more memory > than we actually need to > make sure that we have enough space to do > manual large page alignment. > After we have gotten this memory we figure out > a nicely aligned start > address. We then release the memory again and > then reserve just enough > memory but using the aligned start address as > a fixed address to make > sure that we get the memory we wanted in an > aligned way. > > This is done in a loop to make sure that we > eventually get some memory. > The interesting code looks like this: > > do { > char* extra_base = > os::reserve_memory(extra_size, NULL, alignment); > if (extra_base == NULL) return; > // Do manual alignement > base = (char*) align_size_up((uintptr_t) > extra_base, alignment); > assert(base >= extra_base, "just checking"); > // Re-reserve the region at the aligned base > address. > os::release_memory(extra_base, extra_size); // (1) > base = os::reserve_memory(size, base); // (2) > } while (base == NULL); > > > There is a race here between releasing the > memory in (1) and > re-reserving it in (2). But the loop is > supposed to handle this race. > > The problem is that on posix platforms you can > remap the same memory > area several times. The call in (2) will use > mmap with MAP_FIXED. This > means that the OS will think that you know > exactly what you are doing. > So, if part of the memory has been mapped > already by the process it > will > just go ahead and reuse that memory. > > This means that if we are having multiple > threads that do mmap. We can > end up with a situation where we release our > mapping in (1). Then > another thread comes in and maps part of the > memory that we used to > have. Then we remap over that memory again in > (2) with MAP_FIXED. > Now we > have a situation where two threads in our > process have mapped the same > memory. If both threads try to use it or if > one of the threads unmap > part or all of the memory we will crash. > > On posix it is possible to unmap any part of a > mapped chunk. So, our > proposed solution to the race described above > is to not unmap all > memory > in (1) but rather just unmap the section at > the start and at the end of > the chunk that we mapped to get alignment. > This also removes the need > for the loop. > > However, on Windows you can only unmap _all_ > of the memory that you > have > mapped. On the other hand Windows also will > not allow you to map over > other mappings, so the original code is > actually safe. If we keep > the loop. > > So, our solution is to treat this differently > on Windows and posix > platforms. > > > Thanks, > Bengt > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121213/857c4c3e/attachment-0001.html From coleen.phillimore at oracle.com Thu Dec 13 15:13:59 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 13 Dec 2012 18:13:59 -0500 Subject: code review request for 7153050 remove crufty '_g' support In-Reply-To: <8f2a9523-5390-41db-bf5d-6ddf8040bc8b@default> References: <50CA2416.9070806@oracle.com> <50CA391B.3030509@oracle.com> <50CA3F9C.5050005@oracle.com> <8f2a9523-5390-41db-bf5d-6ddf8040bc8b@default> Message-ID: <50CA6137.8030402@oracle.com> Ron, I'm so happy this is going away. The code changed looks good. There are some comments in some files that refer to the old jvm_g.dll and libjvm_g.so. Can you remove these too? carrs% ygrep -l libjvm_g ./os/bsd/vm/os_bsd.cpp ./os/linux/vm/os_linux.cpp ./os/solaris/vm/os_solaris.cpp carrs% ygre jvm_g.dll ygre: Command not found. carrs% ygrep jvm_g.dll ./os/windows/vm/os_windows.cpp:// Find the full path to the current module, jvm.dll or jvm_g.dll ./share/tools/ProjectCreator/ProjectCreator.java: + "jvm.dll and jvm_g.dll; no trailing slash>"); Thanks, Coleen On 12/13/2012 03:53 PM, Ron Durbin wrote: > Thx again > -----Original Message----- > From: Daniel D. Daugherty > Sent: Thursday, December 13, 2012 1:51 PM > To: build-dev; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; Ron Durbin > Subject: Re: code review request for 7153050 remove crufty '_g' support > > Serguei, > > Thanks for the fast review! > > I could swear that Ron had removed lines 41 and 45 in an earlier version. Sigh... Will be fixed. > > Dan > > > On 12/13/12 1:22 PM, serguei.spitsyn at oracle.com wrote: >> Dan, >> >> It is nice fix and simplified many places. >> >> Just one minor comment: >> >> make/bsd/makefiles/dtrace.make >> >> 41 #LIBJVM_DB = libjvm_db.dylib >> 42 LIBJVM_DB = libjvm_db.dylib >> >> 45 #LIBJVM_DTRACE = libjvm_dtrace.dylib >> 46 LIBJVM_DTRACE = libjvm_dtrace.dylib >> >> The lines #41 and #45 can be removed. >> >> >> Thanks, >> Serguei >> >> >> On 12/13/12 10:53 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I'm sponsoring this code review request from Ron Durbin. This change >>> is targeted at JDK8/HSX-25 in the RT_Baseline repo. Please make sure >>> you include Ron on any e-mail replies since he is not yet on the >>> OpenJDK aliases. >>> >>> Dan >>> >>> >>> Intro: >>> >>> This set of changes removes the makefile support for generation of >>> debug versions that follow _g semantics. >>> >>> Defect: >>> >>> 7153050 "remove crufty '_g' support from HotSpot repo" >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153050 >>> https://jbs.oracle.com/bugs/browse/JDK-7153050 >>> >>> >>> Webrev >>> >>> http://cr.openjdk.java.net/~dcubed/for_rdurbin/7153050-webrev/0 >>> >>> Details: >>> >>> Many makefiles have been modified to remove all reference and support >>> for debug versions that follow _g semantics. From daniel.daugherty at oracle.com Thu Dec 13 15:32:07 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 13 Dec 2012 16:32:07 -0700 Subject: code review request for 7153050 remove crufty '_g' support In-Reply-To: <50CA6137.8030402@oracle.com> References: <50CA2416.9070806@oracle.com> <50CA391B.3030509@oracle.com> <50CA3F9C.5050005@oracle.com> <8f2a9523-5390-41db-bf5d-6ddf8040bc8b@default> <50CA6137.8030402@oracle.com> Message-ID: <50CA6577.8010809@oracle.com> Adding back in the other OpenJDK aliases... Ron's e-mail has gone off-line (no e-mail for him since 1440 MT)... Coleen, Thanks for the review! This bug (7153050) is just for the Makefile changes so that the reviews are more focused. Ron has separate bugs for the other parts of the hotspot repo that need to be fixed. I believe he is going to attack the src/... paths in his second fix. Dan On 12/13/12 4:13 PM, Coleen Phillimore wrote: > > Ron, I'm so happy this is going away. The code changed looks > good. There are some comments in some files that refer to the old > jvm_g.dll and libjvm_g.so. Can you remove these too? > > carrs% ygrep -l libjvm_g > ./os/bsd/vm/os_bsd.cpp > ./os/linux/vm/os_linux.cpp > ./os/solaris/vm/os_solaris.cpp > carrs% ygre jvm_g.dll > ygre: Command not found. > carrs% ygrep jvm_g.dll > ./os/windows/vm/os_windows.cpp:// Find the full path to the current > module, jvm.dll or jvm_g.dll > ./share/tools/ProjectCreator/ProjectCreator.java: + > "jvm.dll and jvm_g.dll; no trailing slash>"); > > Thanks, > Coleen > > On 12/13/2012 03:53 PM, Ron Durbin wrote: >> Thx again >> -----Original Message----- >> From: Daniel D. Daugherty >> Sent: Thursday, December 13, 2012 1:51 PM >> To: build-dev; serviceability-dev at openjdk.java.net; >> hotspot-runtime-dev at openjdk.java.net; Ron Durbin >> Subject: Re: code review request for 7153050 remove crufty '_g' support >> >> Serguei, >> >> Thanks for the fast review! >> >> I could swear that Ron had removed lines 41 and 45 in an earlier >> version. Sigh... Will be fixed. >> >> Dan >> >> >> On 12/13/12 1:22 PM, serguei.spitsyn at oracle.com wrote: >>> Dan, >>> >>> It is nice fix and simplified many places. >>> >>> Just one minor comment: >>> >>> make/bsd/makefiles/dtrace.make >>> >>> 41 #LIBJVM_DB = libjvm_db.dylib >>> 42 LIBJVM_DB = libjvm_db.dylib >>> >>> 45 #LIBJVM_DTRACE = libjvm_dtrace.dylib >>> 46 LIBJVM_DTRACE = libjvm_dtrace.dylib >>> >>> The lines #41 and #45 can be removed. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 12/13/12 10:53 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I'm sponsoring this code review request from Ron Durbin. This change >>>> is targeted at JDK8/HSX-25 in the RT_Baseline repo. Please make sure >>>> you include Ron on any e-mail replies since he is not yet on the >>>> OpenJDK aliases. >>>> >>>> Dan >>>> >>>> >>>> Intro: >>>> >>>> This set of changes removes the makefile support for generation of >>>> debug versions that follow _g semantics. >>>> >>>> Defect: >>>> >>>> 7153050 "remove crufty '_g' support from HotSpot repo" >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153050 >>>> https://jbs.oracle.com/bugs/browse/JDK-7153050 >>>> >>>> >>>> Webrev >>>> >>>> http://cr.openjdk.java.net/~dcubed/for_rdurbin/7153050-webrev/0 >>>> >>>> Details: >>>> >>>> Many makefiles have been modified to remove all reference and support >>>> for debug versions that follow _g semantics. > From daniel.daugherty at oracle.com Thu Dec 13 15:33:51 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 13 Dec 2012 16:33:51 -0700 Subject: code review request for 7153050 remove crufty '_g' support In-Reply-To: <50CA6137.8030402@oracle.com> References: <50CA2416.9070806@oracle.com> <50CA391B.3030509@oracle.com> <50CA3F9C.5050005@oracle.com> <8f2a9523-5390-41db-bf5d-6ddf8040bc8b@default> <50CA6137.8030402@oracle.com> Message-ID: <50CA65DF.9060700@oracle.com> Trying again... now my e-mail client is complaining... Adding back in the other OpenJDK aliases... Ron's e-mail has gone off-line (no e-mail for him since 1440 MT)... Coleen, Thanks for the review! This bug (7153050) is just for the Makefile changes so that the reviews are more focused. Ron has separate bugs for the other parts of the hotspot repo that need to be fixed. I believe he is going to attack the src/... paths in his second fix. Dan On 12/13/12 4:13 PM, Coleen Phillimore wrote: > > Ron, I'm so happy this is going away. The code changed looks > good. There are some comments in some files that refer to the old > jvm_g.dll and libjvm_g.so. Can you remove these too? > > carrs% ygrep -l libjvm_g > ./os/bsd/vm/os_bsd.cpp > ./os/linux/vm/os_linux.cpp > ./os/solaris/vm/os_solaris.cpp > carrs% ygre jvm_g.dll > ygre: Command not found. > carrs% ygrep jvm_g.dll > ./os/windows/vm/os_windows.cpp:// Find the full path to the current > module, jvm.dll or jvm_g.dll > ./share/tools/ProjectCreator/ProjectCreator.java: + > "jvm.dll and jvm_g.dll; no trailing slash>"); > > Thanks, > Coleen > > On 12/13/2012 03:53 PM, Ron Durbin wrote: >> Thx again >> -----Original Message----- >> From: Daniel D. Daugherty >> Sent: Thursday, December 13, 2012 1:51 PM >> To: build-dev; serviceability-dev at openjdk.java.net; >> hotspot-runtime-dev at openjdk.java.net; Ron Durbin >> Subject: Re: code review request for 7153050 remove crufty '_g' support >> >> Serguei, >> >> Thanks for the fast review! >> >> I could swear that Ron had removed lines 41 and 45 in an earlier >> version. Sigh... Will be fixed. >> >> Dan >> >> >> On 12/13/12 1:22 PM, serguei.spitsyn at oracle.com wrote: >>> Dan, >>> >>> It is nice fix and simplified many places. >>> >>> Just one minor comment: >>> >>> make/bsd/makefiles/dtrace.make >>> >>> 41 #LIBJVM_DB = libjvm_db.dylib >>> 42 LIBJVM_DB = libjvm_db.dylib >>> >>> 45 #LIBJVM_DTRACE = libjvm_dtrace.dylib >>> 46 LIBJVM_DTRACE = libjvm_dtrace.dylib >>> >>> The lines #41 and #45 can be removed. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 12/13/12 10:53 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I'm sponsoring this code review request from Ron Durbin. This change >>>> is targeted at JDK8/HSX-25 in the RT_Baseline repo. Please make sure >>>> you include Ron on any e-mail replies since he is not yet on the >>>> OpenJDK aliases. >>>> >>>> Dan >>>> >>>> >>>> Intro: >>>> >>>> This set of changes removes the makefile support for generation of >>>> debug versions that follow _g semantics. >>>> >>>> Defect: >>>> >>>> 7153050 "remove crufty '_g' support from HotSpot repo" >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153050 >>>> https://jbs.oracle.com/bugs/browse/JDK-7153050 >>>> >>>> >>>> Webrev >>>> >>>> http://cr.openjdk.java.net/~dcubed/for_rdurbin/7153050-webrev/0 >>>> >>>> Details: >>>> >>>> Many makefiles have been modified to remove all reference and support >>>> for debug versions that follow _g semantics. > From vitalyd at gmail.com Thu Dec 13 15:44:34 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 13 Dec 2012 18:44:34 -0500 Subject: Request for review (s): 7173959 : Jvm crashed during coherence exabus (tmb) testing In-Reply-To: <50CA474E.9050808@oracle.com> References: <50C978BE.8040405@oracle.com> <50C984DA.1070400@oracle.com> <50C9A7AD.3030307@oracle.com> <50C9AFE9.2080601@oracle.com> <50C9B2EC.5090008@oracle.com> <50C9D0F1.9040501@oracle.com> <50CA474E.9050808@oracle.com> Message-ID: Nice detective work and thanks for the answers. Vitaly Sent from my phone On Dec 13, 2012 4:23 PM, "Bengt Rutisson" wrote: > > Hi Vitaly, > > Thanks for looking at this! > > On 12/13/12 2:44 PM, Vitaly Davidovich wrote: > > Hi Bengt, > > Great write-up! What was in the hs_err file that led you (or Mikael) here? > > > Using the core file we noticed that the hotspot internal data structures > that keep track of the bitmap sizes did not match the mapped memory listed > in the hs_err file. We could see that the mapped memory for the bitmap was > smaller than what hotspot had requested. After convincing ourselves that we > were passing the correct size to mmap we figured that someone must have > been unmapping part of the memory that we had mapped. > > One question I have is why alignment is a multiple of page size and not > page size? I imagine callers want to reserve X space and have it page > aligned up if necessary. When would someone request multiple page size > alignment rather than just increase requested allocation amount and keep > alignment at page size? If huge pages are used then > vm_allocation_granularity() respects that, right? Or is this for > transparent huge page support? Hope that makes sense. > > One such example is with G1. It wants the heap size to be aligned with the > region size, which may be a multiple of the page size. Even with large > pages. > > Actually we also need this for our large page support. The ReservedSpace > doesn't really know of large pages. We use it to map memory but then we > later on use madvice to make the mapped memory use huge pages. This means > that at the time we map the memory we can only rely on the small page size, > but if we know we will use it for large pages we have to make sure that the > memory is aligned to the large page size. So the alignment will be a > multiple of the small page size. > > The other question is whether it's worth it to check for overflow in the > new os_posix function? There are some additions and subtractions on size_t > values and maybe on 32 bit some of those adds can overflow a temporary? > Specifically, line 118. Disregard if that's not needed :). > > > Good point. I think this change is not really increasing the risk of an > overflow compared to the existing code. We should not overflow if we are > passed sane values. An overflow will indicate that someone higher up was > putting together a too large size. I think I would rather have the upper > layers verify that they calculate reasonable values. > > Thanks for your feedback! > Bengt > > Thanks > > Sent from my phone > On Dec 13, 2012 7:59 AM, "Bengt Rutisson" > wrote: > >> >> Hi David, >> >> Updated webrev: >> http://cr.openjdk.java.net/~brutisso/7173959/webrev.02/ >> >> I moved the alignment of "size" back into ReservedSpace::initialize() >> since we actually store the size in an instance variable (_size), so I >> think it is a bit risky to just do the align_up in >> os::reserve_memory_aligned(). We probably want the instance variables _size >> and _alignment in ReservedSpace to be consistent. >> >> I added an assert in os::reserve_memory_aligned() to verify that the size >> is correctly aligned. I also added the assert you suggested to check that >> alignment is page size aligned. >> >> Bengt >> >> On 12/13/12 11:50 AM, David Holmes wrote: >> >>> On 13/12/2012 8:37 PM, Bengt Rutisson wrote: >>> >>>> >>>> Hi again, >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.01/ >>>> >>>> I removed the comment and the alignment. >>>> >>>> But I did not add an assert just yet. >>>> >>>> At the top of ReservedSpace::initialize() we have this code: >>>> >>>> const size_t granularity = os::vm_allocation_granularity(); >>>> assert((size & (granularity - 1)) == 0, >>>> "size not aligned to os::vm_allocation_granularity()"); >>>> assert((alignment & (granularity - 1)) == 0, >>>> "alignment not aligned to os::vm_allocation_granularity()"); >>>> >>>> >>>> Where os::vm_allocation_granularity() is implemented as page size on all >>>> platforms except Windows. There we look it up from the Windows API. I >>>> assume that is a page size too, but since the Windows code in our patch >>>> does not unmap based on the alignment it should be safe either way. >>>> >>>> Is this assert enough or would you like me to add an assert closer to >>>> the code block were I did the changes? >>>> >>> >>> As this is a separate method now I think an assert in the method itself >>> would not go astray. >>> >>> David >>> ----- >>> >>> Thanks, >>>> Bengt >>>> >>>> >>>> On 12/13/12 11:02 AM, Bengt Rutisson wrote: >>>> >>>>> >>>>> Hi David, >>>>> >>>>> Thanks for looking at this! >>>>> >>>>> On 12/13/12 8:33 AM, David Holmes wrote: >>>>> >>>>>> Hi Bengt, >>>>>> >>>>>> This has to be one of the absolute best review requests I've ever >>>>>> read :) Thank you. >>>>>> >>>>> >>>>> Wow! Thanks! :) >>>>> >>>>> >>>>>> Just a couple of queries. >>>>>> >>>>>> os_posix.cpp: >>>>>> >>>>>> Love the diagram :) >>>>>> >>>>> >>>>> It was Mikael's way of making sure we got it right. >>>>> >>>>> I'm assuming that "alignment" has to be >= the underlying page size, >>>>>> and in fact must be a multiple of the underlying page size ? (As I >>>>>> assume you can only unmap whole numbers of pages). If so does that >>>>>> need to be checked somewhere? >>>>>> >>>>> >>>>> Good point. I'll add an assert to check that. >>>>> >>>>> In virtualSpace.cpp: >>>>>> >>>>>> // Reserve size large enough to do manual alignment and >>>>>> // increase size to a multiple of the desired alignment >>>>>> size = align_size_up(size, alignment); >>>>>> ! base = os::reserve_memory_aligned(size, alignment); >>>>>> >>>>>> The comment doesn't seem necessary now, and the align_size_up seems >>>>>> redundant. >>>>>> >>>>> >>>>> You are right. I'll remove the comment and the alignment. >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 13/12/2012 4:42 PM, Bengt Rutisson wrote: >>>>>> >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Could I have a couple of reviews for this change? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.00/ >>>>>>> >>>>>>> This is for a bug originally reported by the Coherence team: >>>>>>> >>>>>>> 7173959 : Jvm crashed during coherence exabus (tmb) testing >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173959 >>>>>>> >>>>>>> The original analysis and proposed fix was done by Mikael Gerdin and >>>>>>> me >>>>>>> together. I'll handle the webrev and push since Mikael is on vacation >>>>>>> starting today. But Mikael did a great job tracking down this very >>>>>>> difficult bug, so he should have a large part of the credit for this >>>>>>> bug >>>>>>> fix, >>>>>>> >>>>>>> Description from the CR: >>>>>>> >>>>>>> The reason that we crash is due to how we re-map memory when we want >>>>>>> to >>>>>>> align it for large pages in ReservedSpace::initialize(). >>>>>>> >>>>>>> Here is what happens: >>>>>>> >>>>>>> The reservation of memory is split up to a few steps. When we want a >>>>>>> chunk of memory with large pages we first just reserve some memory >>>>>>> large >>>>>>> enough for what we need. Then we realize that we want large pages, >>>>>>> so we >>>>>>> want to re-map the reserved memory to use large pages. But since this >>>>>>> requires that we have a large-page-aligned memory chunk we may have >>>>>>> to >>>>>>> fix the recently reserved memory chunk up a bit. >>>>>>> >>>>>>> We do this in ReservedSpace::initialize() by first releasing the >>>>>>> memory >>>>>>> we just reserved. Then requesting more memory than we actually need >>>>>>> to >>>>>>> make sure that we have enough space to do manual large page >>>>>>> alignment. >>>>>>> After we have gotten this memory we figure out a nicely aligned start >>>>>>> address. We then release the memory again and then reserve just >>>>>>> enough >>>>>>> memory but using the aligned start address as a fixed address to make >>>>>>> sure that we get the memory we wanted in an aligned way. >>>>>>> >>>>>>> This is done in a loop to make sure that we eventually get some >>>>>>> memory. >>>>>>> The interesting code looks like this: >>>>>>> >>>>>>> do { >>>>>>> char* extra_base = os::reserve_memory(extra_size, NULL, alignment); >>>>>>> if (extra_base == NULL) return; >>>>>>> // Do manual alignement >>>>>>> base = (char*) align_size_up((uintptr_t) extra_base, alignment); >>>>>>> assert(base >= extra_base, "just checking"); >>>>>>> // Re-reserve the region at the aligned base address. >>>>>>> os::release_memory(extra_base, extra_size); // (1) >>>>>>> base = os::reserve_memory(size, base); // (2) >>>>>>> } while (base == NULL); >>>>>>> >>>>>>> >>>>>>> There is a race here between releasing the memory in (1) and >>>>>>> re-reserving it in (2). But the loop is supposed to handle this race. >>>>>>> >>>>>>> The problem is that on posix platforms you can remap the same memory >>>>>>> area several times. The call in (2) will use mmap with MAP_FIXED. >>>>>>> This >>>>>>> means that the OS will think that you know exactly what you are >>>>>>> doing. >>>>>>> So, if part of the memory has been mapped already by the process it >>>>>>> will >>>>>>> just go ahead and reuse that memory. >>>>>>> >>>>>>> This means that if we are having multiple threads that do mmap. We >>>>>>> can >>>>>>> end up with a situation where we release our mapping in (1). Then >>>>>>> another thread comes in and maps part of the memory that we used to >>>>>>> have. Then we remap over that memory again in (2) with MAP_FIXED. >>>>>>> Now we >>>>>>> have a situation where two threads in our process have mapped the >>>>>>> same >>>>>>> memory. If both threads try to use it or if one of the threads unmap >>>>>>> part or all of the memory we will crash. >>>>>>> >>>>>>> On posix it is possible to unmap any part of a mapped chunk. So, our >>>>>>> proposed solution to the race described above is to not unmap all >>>>>>> memory >>>>>>> in (1) but rather just unmap the section at the start and at the end >>>>>>> of >>>>>>> the chunk that we mapped to get alignment. This also removes the need >>>>>>> for the loop. >>>>>>> >>>>>>> However, on Windows you can only unmap _all_ of the memory that you >>>>>>> have >>>>>>> mapped. On the other hand Windows also will not allow you to map over >>>>>>> other mappings, so the original code is actually safe. If we keep >>>>>>> the loop. >>>>>>> >>>>>>> So, our solution is to treat this differently on Windows and posix >>>>>>> platforms. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Bengt >>>>>>> >>>>>> >>>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121213/aebd5895/attachment-0001.html From david.holmes at oracle.com Thu Dec 13 16:38:34 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Dec 2012 10:38:34 +1000 Subject: Request for review (s): 7173959 : Jvm crashed during coherence exabus (tmb) testing In-Reply-To: <50C9D0F1.9040501@oracle.com> References: <50C978BE.8040405@oracle.com> <50C984DA.1070400@oracle.com> <50C9A7AD.3030307@oracle.com> <50C9AFE9.2080601@oracle.com> <50C9B2EC.5090008@oracle.com> <50C9D0F1.9040501@oracle.com> Message-ID: <50CA750A.6040007@oracle.com> Hi Bengt, That all sounds good to me. With regard to potential overflow perhaps a simple check that extra_size does not overflow? If that is true and extra_base is not null then I think all the other calculations must be valid. Thanks, David On 13/12/2012 10:58 PM, Bengt Rutisson wrote: > > Hi David, > > Updated webrev: > http://cr.openjdk.java.net/~brutisso/7173959/webrev.02/ > > I moved the alignment of "size" back into ReservedSpace::initialize() > since we actually store the size in an instance variable (_size), so I > think it is a bit risky to just do the align_up in > os::reserve_memory_aligned(). We probably want the instance variables > _size and _alignment in ReservedSpace to be consistent. > > I added an assert in os::reserve_memory_aligned() to verify that the > size is correctly aligned. I also added the assert you suggested to > check that alignment is page size aligned. > > Bengt > > On 12/13/12 11:50 AM, David Holmes wrote: >> On 13/12/2012 8:37 PM, Bengt Rutisson wrote: >>> >>> Hi again, >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.01/ >>> >>> I removed the comment and the alignment. >>> >>> But I did not add an assert just yet. >>> >>> At the top of ReservedSpace::initialize() we have this code: >>> >>> const size_t granularity = os::vm_allocation_granularity(); >>> assert((size & (granularity - 1)) == 0, >>> "size not aligned to os::vm_allocation_granularity()"); >>> assert((alignment & (granularity - 1)) == 0, >>> "alignment not aligned to os::vm_allocation_granularity()"); >>> >>> >>> Where os::vm_allocation_granularity() is implemented as page size on all >>> platforms except Windows. There we look it up from the Windows API. I >>> assume that is a page size too, but since the Windows code in our patch >>> does not unmap based on the alignment it should be safe either way. >>> >>> Is this assert enough or would you like me to add an assert closer to >>> the code block were I did the changes? >> >> As this is a separate method now I think an assert in the method >> itself would not go astray. >> >> David >> ----- >> >>> Thanks, >>> Bengt >>> >>> >>> On 12/13/12 11:02 AM, Bengt Rutisson wrote: >>>> >>>> Hi David, >>>> >>>> Thanks for looking at this! >>>> >>>> On 12/13/12 8:33 AM, David Holmes wrote: >>>>> Hi Bengt, >>>>> >>>>> This has to be one of the absolute best review requests I've ever >>>>> read :) Thank you. >>>> >>>> Wow! Thanks! :) >>>> >>>>> >>>>> Just a couple of queries. >>>>> >>>>> os_posix.cpp: >>>>> >>>>> Love the diagram :) >>>> >>>> It was Mikael's way of making sure we got it right. >>>> >>>>> I'm assuming that "alignment" has to be >= the underlying page size, >>>>> and in fact must be a multiple of the underlying page size ? (As I >>>>> assume you can only unmap whole numbers of pages). If so does that >>>>> need to be checked somewhere? >>>> >>>> Good point. I'll add an assert to check that. >>>> >>>>> In virtualSpace.cpp: >>>>> >>>>> // Reserve size large enough to do manual alignment and >>>>> // increase size to a multiple of the desired alignment >>>>> size = align_size_up(size, alignment); >>>>> ! base = os::reserve_memory_aligned(size, alignment); >>>>> >>>>> The comment doesn't seem necessary now, and the align_size_up seems >>>>> redundant. >>>> >>>> You are right. I'll remove the comment and the alignment. >>>> >>>> Thanks, >>>> Bengt >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 13/12/2012 4:42 PM, Bengt Rutisson wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Could I have a couple of reviews for this change? >>>>>> >>>>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.00/ >>>>>> >>>>>> This is for a bug originally reported by the Coherence team: >>>>>> >>>>>> 7173959 : Jvm crashed during coherence exabus (tmb) testing >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173959 >>>>>> >>>>>> The original analysis and proposed fix was done by Mikael Gerdin >>>>>> and me >>>>>> together. I'll handle the webrev and push since Mikael is on vacation >>>>>> starting today. But Mikael did a great job tracking down this very >>>>>> difficult bug, so he should have a large part of the credit for this >>>>>> bug >>>>>> fix, >>>>>> >>>>>> Description from the CR: >>>>>> >>>>>> The reason that we crash is due to how we re-map memory when we >>>>>> want to >>>>>> align it for large pages in ReservedSpace::initialize(). >>>>>> >>>>>> Here is what happens: >>>>>> >>>>>> The reservation of memory is split up to a few steps. When we want a >>>>>> chunk of memory with large pages we first just reserve some memory >>>>>> large >>>>>> enough for what we need. Then we realize that we want large pages, >>>>>> so we >>>>>> want to re-map the reserved memory to use large pages. But since this >>>>>> requires that we have a large-page-aligned memory chunk we may >>>>>> have to >>>>>> fix the recently reserved memory chunk up a bit. >>>>>> >>>>>> We do this in ReservedSpace::initialize() by first releasing the >>>>>> memory >>>>>> we just reserved. Then requesting more memory than we actually >>>>>> need to >>>>>> make sure that we have enough space to do manual large page >>>>>> alignment. >>>>>> After we have gotten this memory we figure out a nicely aligned start >>>>>> address. We then release the memory again and then reserve just >>>>>> enough >>>>>> memory but using the aligned start address as a fixed address to make >>>>>> sure that we get the memory we wanted in an aligned way. >>>>>> >>>>>> This is done in a loop to make sure that we eventually get some >>>>>> memory. >>>>>> The interesting code looks like this: >>>>>> >>>>>> do { >>>>>> char* extra_base = os::reserve_memory(extra_size, NULL, alignment); >>>>>> if (extra_base == NULL) return; >>>>>> // Do manual alignement >>>>>> base = (char*) align_size_up((uintptr_t) extra_base, alignment); >>>>>> assert(base >= extra_base, "just checking"); >>>>>> // Re-reserve the region at the aligned base address. >>>>>> os::release_memory(extra_base, extra_size); // (1) >>>>>> base = os::reserve_memory(size, base); // (2) >>>>>> } while (base == NULL); >>>>>> >>>>>> >>>>>> There is a race here between releasing the memory in (1) and >>>>>> re-reserving it in (2). But the loop is supposed to handle this race. >>>>>> >>>>>> The problem is that on posix platforms you can remap the same memory >>>>>> area several times. The call in (2) will use mmap with MAP_FIXED. >>>>>> This >>>>>> means that the OS will think that you know exactly what you are >>>>>> doing. >>>>>> So, if part of the memory has been mapped already by the process it >>>>>> will >>>>>> just go ahead and reuse that memory. >>>>>> >>>>>> This means that if we are having multiple threads that do mmap. We >>>>>> can >>>>>> end up with a situation where we release our mapping in (1). Then >>>>>> another thread comes in and maps part of the memory that we used to >>>>>> have. Then we remap over that memory again in (2) with MAP_FIXED. >>>>>> Now we >>>>>> have a situation where two threads in our process have mapped the >>>>>> same >>>>>> memory. If both threads try to use it or if one of the threads unmap >>>>>> part or all of the memory we will crash. >>>>>> >>>>>> On posix it is possible to unmap any part of a mapped chunk. So, our >>>>>> proposed solution to the race described above is to not unmap all >>>>>> memory >>>>>> in (1) but rather just unmap the section at the start and at the >>>>>> end of >>>>>> the chunk that we mapped to get alignment. This also removes the need >>>>>> for the loop. >>>>>> >>>>>> However, on Windows you can only unmap _all_ of the memory that you >>>>>> have >>>>>> mapped. On the other hand Windows also will not allow you to map over >>>>>> other mappings, so the original code is actually safe. If we keep >>>>>> the loop. >>>>>> >>>>>> So, our solution is to treat this differently on Windows and posix >>>>>> platforms. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>> >>> > From ron.durbin at oracle.com Thu Dec 13 16:48:27 2012 From: ron.durbin at oracle.com (Ron Durbin) Date: Thu, 13 Dec 2012 16:48:27 -0800 (PST) Subject: code review request for 7153050 remove crufty '_g' support In-Reply-To: <50CA6137.8030402@oracle.com> References: <50CA2416.9070806@oracle.com> <50CA391B.3030509@oracle.com> <50CA3F9C.5050005@oracle.com> <8f2a9523-5390-41db-bf5d-6ddf8040bc8b@default> <50CA6137.8030402@oracle.com> Message-ID: That will be in my next checkin, this one is for makefiles only. See JDK-8005044 -----Original Message----- From: Coleen Phillimore Sent: Thursday, December 13, 2012 4:14 PM To: hotspot-runtime-dev at openjdk.java.net Subject: Re: code review request for 7153050 remove crufty '_g' support Ron, I'm so happy this is going away. The code changed looks good. There are some comments in some files that refer to the old jvm_g.dll and libjvm_g.so. Can you remove these too? carrs% ygrep -l libjvm_g ./os/bsd/vm/os_bsd.cpp ./os/linux/vm/os_linux.cpp ./os/solaris/vm/os_solaris.cpp carrs% ygre jvm_g.dll ygre: Command not found. carrs% ygrep jvm_g.dll ./os/windows/vm/os_windows.cpp:// Find the full path to the current module, jvm.dll or jvm_g.dll ./share/tools/ProjectCreator/ProjectCreator.java: + "jvm.dll and jvm_g.dll; no trailing slash>"); Thanks, Coleen On 12/13/2012 03:53 PM, Ron Durbin wrote: > Thx again > -----Original Message----- > From: Daniel D. Daugherty > Sent: Thursday, December 13, 2012 1:51 PM > To: build-dev; serviceability-dev at openjdk.java.net; > hotspot-runtime-dev at openjdk.java.net; Ron Durbin > Subject: Re: code review request for 7153050 remove crufty '_g' > support > > Serguei, > > Thanks for the fast review! > > I could swear that Ron had removed lines 41 and 45 in an earlier version. Sigh... Will be fixed. > > Dan > > > On 12/13/12 1:22 PM, serguei.spitsyn at oracle.com wrote: >> Dan, >> >> It is nice fix and simplified many places. >> >> Just one minor comment: >> >> make/bsd/makefiles/dtrace.make >> >> 41 #LIBJVM_DB = libjvm_db.dylib >> 42 LIBJVM_DB = libjvm_db.dylib >> >> 45 #LIBJVM_DTRACE = libjvm_dtrace.dylib >> 46 LIBJVM_DTRACE = libjvm_dtrace.dylib >> >> The lines #41 and #45 can be removed. >> >> >> Thanks, >> Serguei >> >> >> On 12/13/12 10:53 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I'm sponsoring this code review request from Ron Durbin. This change >>> is targeted at JDK8/HSX-25 in the RT_Baseline repo. Please make sure >>> you include Ron on any e-mail replies since he is not yet on the >>> OpenJDK aliases. >>> >>> Dan >>> >>> >>> Intro: >>> >>> This set of changes removes the makefile support for generation of >>> debug versions that follow _g semantics. >>> >>> Defect: >>> >>> 7153050 "remove crufty '_g' support from HotSpot repo" >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153050 >>> https://jbs.oracle.com/bugs/browse/JDK-7153050 >>> >>> >>> Webrev >>> >>> http://cr.openjdk.java.net/~dcubed/for_rdurbin/7153050-webrev/0 >>> >>> Details: >>> >>> Many makefiles have been modified to remove all reference and >>> support for debug versions that follow _g semantics. From ron.durbin at oracle.com Thu Dec 13 16:49:40 2012 From: ron.durbin at oracle.com (Ron Durbin) Date: Thu, 13 Dec 2012 16:49:40 -0800 (PST) Subject: code review request for 7153050 remove crufty '_g' support In-Reply-To: <50CA6577.8010809@oracle.com> References: <50CA2416.9070806@oracle.com> <50CA391B.3030509@oracle.com> <50CA3F9C.5050005@oracle.com> <8f2a9523-5390-41db-bf5d-6ddf8040bc8b@default> <50CA6137.8030402@oracle.com> <50CA6577.8010809@oracle.com> Message-ID: <3131717b-f788-4b26-8bef-c9e271ca0823@default> I am back and Dan has It correct (JDK-8005044) -----Original Message----- From: Daniel D. Daugherty Sent: Thursday, December 13, 2012 4:32 PM To: hotspot-runtime-dev at openjdk.java.net; build-dev; serviceability-dev at openjdk.java.net Subject: Re: code review request for 7153050 remove crufty '_g' support Adding back in the other OpenJDK aliases... Ron's e-mail has gone off-line (no e-mail for him since 1440 MT)... Coleen, Thanks for the review! This bug (7153050) is just for the Makefile changes so that the reviews are more focused. Ron has separate bugs for the other parts of the hotspot repo that need to be fixed. I believe he is going to attack the src/... paths in his second fix. Dan On 12/13/12 4:13 PM, Coleen Phillimore wrote: > > Ron, I'm so happy this is going away. The code changed looks > good. There are some comments in some files that refer to the old > jvm_g.dll and libjvm_g.so. Can you remove these too? > > carrs% ygrep -l libjvm_g > ./os/bsd/vm/os_bsd.cpp > ./os/linux/vm/os_linux.cpp > ./os/solaris/vm/os_solaris.cpp > carrs% ygre jvm_g.dll > ygre: Command not found. > carrs% ygrep jvm_g.dll > ./os/windows/vm/os_windows.cpp:// Find the full path to the current > module, jvm.dll or jvm_g.dll > ./share/tools/ProjectCreator/ProjectCreator.java: + > "jvm.dll and jvm_g.dll; no trailing slash>"); > > Thanks, > Coleen > > On 12/13/2012 03:53 PM, Ron Durbin wrote: >> Thx again >> -----Original Message----- >> From: Daniel D. Daugherty >> Sent: Thursday, December 13, 2012 1:51 PM >> To: build-dev; serviceability-dev at openjdk.java.net; >> hotspot-runtime-dev at openjdk.java.net; Ron Durbin >> Subject: Re: code review request for 7153050 remove crufty '_g' >> support >> >> Serguei, >> >> Thanks for the fast review! >> >> I could swear that Ron had removed lines 41 and 45 in an earlier >> version. Sigh... Will be fixed. >> >> Dan >> >> >> On 12/13/12 1:22 PM, serguei.spitsyn at oracle.com wrote: >>> Dan, >>> >>> It is nice fix and simplified many places. >>> >>> Just one minor comment: >>> >>> make/bsd/makefiles/dtrace.make >>> >>> 41 #LIBJVM_DB = libjvm_db.dylib >>> 42 LIBJVM_DB = libjvm_db.dylib >>> >>> 45 #LIBJVM_DTRACE = libjvm_dtrace.dylib >>> 46 LIBJVM_DTRACE = libjvm_dtrace.dylib >>> >>> The lines #41 and #45 can be removed. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 12/13/12 10:53 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I'm sponsoring this code review request from Ron Durbin. This >>>> change is targeted at JDK8/HSX-25 in the RT_Baseline repo. Please >>>> make sure you include Ron on any e-mail replies since he is not yet >>>> on the OpenJDK aliases. >>>> >>>> Dan >>>> >>>> >>>> Intro: >>>> >>>> This set of changes removes the makefile support for generation of >>>> debug versions that follow _g semantics. >>>> >>>> Defect: >>>> >>>> 7153050 "remove crufty '_g' support from HotSpot repo" >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153050 >>>> https://jbs.oracle.com/bugs/browse/JDK-7153050 >>>> >>>> >>>> Webrev >>>> >>>> http://cr.openjdk.java.net/~dcubed/for_rdurbin/7153050-webrev/0 >>>> >>>> Details: >>>> >>>> Many makefiles have been modified to remove all reference and >>>> support for debug versions that follow _g semantics. > From coleen.phillimore at oracle.com Thu Dec 13 17:00:05 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 13 Dec 2012 20:00:05 -0500 Subject: code review request for 7153050 remove crufty '_g' support In-Reply-To: References: <50CA2416.9070806@oracle.com> <50CA391B.3030509@oracle.com> <50CA3F9C.5050005@oracle.com> <8f2a9523-5390-41db-bf5d-6ddf8040bc8b@default> <50CA6137.8030402@oracle.com> Message-ID: <50CA7A15.9050908@oracle.com> Ok. thanks, Coleen On 12/13/2012 07:48 PM, Ron Durbin wrote: > That will be in my next checkin, this one is for makefiles only. > See > JDK-8005044 > > -----Original Message----- > From: Coleen Phillimore > Sent: Thursday, December 13, 2012 4:14 PM > To: hotspot-runtime-dev at openjdk.java.net > Subject: Re: code review request for 7153050 remove crufty '_g' support > > > Ron, I'm so happy this is going away. The code changed looks good. > There are some comments in some files that refer to the old jvm_g.dll > and libjvm_g.so. Can you remove these too? > > carrs% ygrep -l libjvm_g > ./os/bsd/vm/os_bsd.cpp > ./os/linux/vm/os_linux.cpp > ./os/solaris/vm/os_solaris.cpp > carrs% ygre jvm_g.dll > ygre: Command not found. > carrs% ygrep jvm_g.dll > ./os/windows/vm/os_windows.cpp:// Find the full path to the current module, jvm.dll or jvm_g.dll > ./share/tools/ProjectCreator/ProjectCreator.java: + "jvm.dll > and jvm_g.dll; no trailing slash>"); > > Thanks, > Coleen > > On 12/13/2012 03:53 PM, Ron Durbin wrote: >> Thx again >> -----Original Message----- >> From: Daniel D. Daugherty >> Sent: Thursday, December 13, 2012 1:51 PM >> To: build-dev; serviceability-dev at openjdk.java.net; >> hotspot-runtime-dev at openjdk.java.net; Ron Durbin >> Subject: Re: code review request for 7153050 remove crufty '_g' >> support >> >> Serguei, >> >> Thanks for the fast review! >> >> I could swear that Ron had removed lines 41 and 45 in an earlier version. Sigh... Will be fixed. >> >> Dan >> >> >> On 12/13/12 1:22 PM, serguei.spitsyn at oracle.com wrote: >>> Dan, >>> >>> It is nice fix and simplified many places. >>> >>> Just one minor comment: >>> >>> make/bsd/makefiles/dtrace.make >>> >>> 41 #LIBJVM_DB = libjvm_db.dylib >>> 42 LIBJVM_DB = libjvm_db.dylib >>> >>> 45 #LIBJVM_DTRACE = libjvm_dtrace.dylib >>> 46 LIBJVM_DTRACE = libjvm_dtrace.dylib >>> >>> The lines #41 and #45 can be removed. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 12/13/12 10:53 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I'm sponsoring this code review request from Ron Durbin. This change >>>> is targeted at JDK8/HSX-25 in the RT_Baseline repo. Please make sure >>>> you include Ron on any e-mail replies since he is not yet on the >>>> OpenJDK aliases. >>>> >>>> Dan >>>> >>>> >>>> Intro: >>>> >>>> This set of changes removes the makefile support for generation of >>>> debug versions that follow _g semantics. >>>> >>>> Defect: >>>> >>>> 7153050 "remove crufty '_g' support from HotSpot repo" >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153050 >>>> https://jbs.oracle.com/bugs/browse/JDK-7153050 >>>> >>>> >>>> Webrev >>>> >>>> http://cr.openjdk.java.net/~dcubed/for_rdurbin/7153050-webrev/0 >>>> >>>> Details: >>>> >>>> Many makefiles have been modified to remove all reference and >>>> support for debug versions that follow _g semantics. From bengt.rutisson at oracle.com Fri Dec 14 00:29:56 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 14 Dec 2012 09:29:56 +0100 Subject: Request for review (s): 7173959 : Jvm crashed during coherence exabus (tmb) testing In-Reply-To: <50CA750A.6040007@oracle.com> References: <50C978BE.8040405@oracle.com> <50C984DA.1070400@oracle.com> <50C9A7AD.3030307@oracle.com> <50C9AFE9.2080601@oracle.com> <50C9B2EC.5090008@oracle.com> <50C9D0F1.9040501@oracle.com> <50CA750A.6040007@oracle.com> Message-ID: <50CAE384.6070003@oracle.com> Hi David, On 12/14/12 1:38 AM, David Holmes wrote: > Hi Bengt, > > That all sounds good to me. > > With regard to potential overflow perhaps a simple check that > extra_size does not overflow? If that is true and extra_base is not > null then I think all the other calculations must be valid. Yes, that makes sense. I'll add an overflow check for the extra_size. Thanks, Bengt > > Thanks, > David > > On 13/12/2012 10:58 PM, Bengt Rutisson wrote: >> >> Hi David, >> >> Updated webrev: >> http://cr.openjdk.java.net/~brutisso/7173959/webrev.02/ >> >> I moved the alignment of "size" back into ReservedSpace::initialize() >> since we actually store the size in an instance variable (_size), so I >> think it is a bit risky to just do the align_up in >> os::reserve_memory_aligned(). We probably want the instance variables >> _size and _alignment in ReservedSpace to be consistent. >> >> I added an assert in os::reserve_memory_aligned() to verify that the >> size is correctly aligned. I also added the assert you suggested to >> check that alignment is page size aligned. >> >> Bengt >> >> On 12/13/12 11:50 AM, David Holmes wrote: >>> On 13/12/2012 8:37 PM, Bengt Rutisson wrote: >>>> >>>> Hi again, >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.01/ >>>> >>>> I removed the comment and the alignment. >>>> >>>> But I did not add an assert just yet. >>>> >>>> At the top of ReservedSpace::initialize() we have this code: >>>> >>>> const size_t granularity = os::vm_allocation_granularity(); >>>> assert((size & (granularity - 1)) == 0, >>>> "size not aligned to os::vm_allocation_granularity()"); >>>> assert((alignment & (granularity - 1)) == 0, >>>> "alignment not aligned to os::vm_allocation_granularity()"); >>>> >>>> >>>> Where os::vm_allocation_granularity() is implemented as page size >>>> on all >>>> platforms except Windows. There we look it up from the Windows API. I >>>> assume that is a page size too, but since the Windows code in our >>>> patch >>>> does not unmap based on the alignment it should be safe either way. >>>> >>>> Is this assert enough or would you like me to add an assert closer to >>>> the code block were I did the changes? >>> >>> As this is a separate method now I think an assert in the method >>> itself would not go astray. >>> >>> David >>> ----- >>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>> On 12/13/12 11:02 AM, Bengt Rutisson wrote: >>>>> >>>>> Hi David, >>>>> >>>>> Thanks for looking at this! >>>>> >>>>> On 12/13/12 8:33 AM, David Holmes wrote: >>>>>> Hi Bengt, >>>>>> >>>>>> This has to be one of the absolute best review requests I've ever >>>>>> read :) Thank you. >>>>> >>>>> Wow! Thanks! :) >>>>> >>>>>> >>>>>> Just a couple of queries. >>>>>> >>>>>> os_posix.cpp: >>>>>> >>>>>> Love the diagram :) >>>>> >>>>> It was Mikael's way of making sure we got it right. >>>>> >>>>>> I'm assuming that "alignment" has to be >= the underlying page size, >>>>>> and in fact must be a multiple of the underlying page size ? (As I >>>>>> assume you can only unmap whole numbers of pages). If so does that >>>>>> need to be checked somewhere? >>>>> >>>>> Good point. I'll add an assert to check that. >>>>> >>>>>> In virtualSpace.cpp: >>>>>> >>>>>> // Reserve size large enough to do manual alignment and >>>>>> // increase size to a multiple of the desired alignment >>>>>> size = align_size_up(size, alignment); >>>>>> ! base = os::reserve_memory_aligned(size, alignment); >>>>>> >>>>>> The comment doesn't seem necessary now, and the align_size_up seems >>>>>> redundant. >>>>> >>>>> You are right. I'll remove the comment and the alignment. >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 13/12/2012 4:42 PM, Bengt Rutisson wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Could I have a couple of reviews for this change? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.00/ >>>>>>> >>>>>>> This is for a bug originally reported by the Coherence team: >>>>>>> >>>>>>> 7173959 : Jvm crashed during coherence exabus (tmb) testing >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173959 >>>>>>> >>>>>>> The original analysis and proposed fix was done by Mikael Gerdin >>>>>>> and me >>>>>>> together. I'll handle the webrev and push since Mikael is on >>>>>>> vacation >>>>>>> starting today. But Mikael did a great job tracking down this very >>>>>>> difficult bug, so he should have a large part of the credit for >>>>>>> this >>>>>>> bug >>>>>>> fix, >>>>>>> >>>>>>> Description from the CR: >>>>>>> >>>>>>> The reason that we crash is due to how we re-map memory when we >>>>>>> want to >>>>>>> align it for large pages in ReservedSpace::initialize(). >>>>>>> >>>>>>> Here is what happens: >>>>>>> >>>>>>> The reservation of memory is split up to a few steps. When we >>>>>>> want a >>>>>>> chunk of memory with large pages we first just reserve some memory >>>>>>> large >>>>>>> enough for what we need. Then we realize that we want large pages, >>>>>>> so we >>>>>>> want to re-map the reserved memory to use large pages. But since >>>>>>> this >>>>>>> requires that we have a large-page-aligned memory chunk we may >>>>>>> have to >>>>>>> fix the recently reserved memory chunk up a bit. >>>>>>> >>>>>>> We do this in ReservedSpace::initialize() by first releasing the >>>>>>> memory >>>>>>> we just reserved. Then requesting more memory than we actually >>>>>>> need to >>>>>>> make sure that we have enough space to do manual large page >>>>>>> alignment. >>>>>>> After we have gotten this memory we figure out a nicely aligned >>>>>>> start >>>>>>> address. We then release the memory again and then reserve just >>>>>>> enough >>>>>>> memory but using the aligned start address as a fixed address to >>>>>>> make >>>>>>> sure that we get the memory we wanted in an aligned way. >>>>>>> >>>>>>> This is done in a loop to make sure that we eventually get some >>>>>>> memory. >>>>>>> The interesting code looks like this: >>>>>>> >>>>>>> do { >>>>>>> char* extra_base = os::reserve_memory(extra_size, NULL, alignment); >>>>>>> if (extra_base == NULL) return; >>>>>>> // Do manual alignement >>>>>>> base = (char*) align_size_up((uintptr_t) extra_base, alignment); >>>>>>> assert(base >= extra_base, "just checking"); >>>>>>> // Re-reserve the region at the aligned base address. >>>>>>> os::release_memory(extra_base, extra_size); // (1) >>>>>>> base = os::reserve_memory(size, base); // (2) >>>>>>> } while (base == NULL); >>>>>>> >>>>>>> >>>>>>> There is a race here between releasing the memory in (1) and >>>>>>> re-reserving it in (2). But the loop is supposed to handle this >>>>>>> race. >>>>>>> >>>>>>> The problem is that on posix platforms you can remap the same >>>>>>> memory >>>>>>> area several times. The call in (2) will use mmap with MAP_FIXED. >>>>>>> This >>>>>>> means that the OS will think that you know exactly what you are >>>>>>> doing. >>>>>>> So, if part of the memory has been mapped already by the process it >>>>>>> will >>>>>>> just go ahead and reuse that memory. >>>>>>> >>>>>>> This means that if we are having multiple threads that do mmap. We >>>>>>> can >>>>>>> end up with a situation where we release our mapping in (1). Then >>>>>>> another thread comes in and maps part of the memory that we used to >>>>>>> have. Then we remap over that memory again in (2) with MAP_FIXED. >>>>>>> Now we >>>>>>> have a situation where two threads in our process have mapped the >>>>>>> same >>>>>>> memory. If both threads try to use it or if one of the threads >>>>>>> unmap >>>>>>> part or all of the memory we will crash. >>>>>>> >>>>>>> On posix it is possible to unmap any part of a mapped chunk. So, >>>>>>> our >>>>>>> proposed solution to the race described above is to not unmap all >>>>>>> memory >>>>>>> in (1) but rather just unmap the section at the start and at the >>>>>>> end of >>>>>>> the chunk that we mapped to get alignment. This also removes the >>>>>>> need >>>>>>> for the loop. >>>>>>> >>>>>>> However, on Windows you can only unmap _all_ of the memory that you >>>>>>> have >>>>>>> mapped. On the other hand Windows also will not allow you to map >>>>>>> over >>>>>>> other mappings, so the original code is actually safe. If we keep >>>>>>> the loop. >>>>>>> >>>>>>> So, our solution is to treat this differently on Windows and posix >>>>>>> platforms. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Bengt >>>>> >>>> >> From bengt.rutisson at oracle.com Fri Dec 14 00:48:54 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 14 Dec 2012 09:48:54 +0100 Subject: Request for review (s): 7173959 : Jvm crashed during coherence exabus (tmb) testing In-Reply-To: <50CAE384.6070003@oracle.com> References: <50C978BE.8040405@oracle.com> <50C984DA.1070400@oracle.com> <50C9A7AD.3030307@oracle.com> <50C9AFE9.2080601@oracle.com> <50C9B2EC.5090008@oracle.com> <50C9D0F1.9040501@oracle.com> <50CA750A.6040007@oracle.com> <50CAE384.6070003@oracle.com> Message-ID: <50CAE7F6.2020609@oracle.com> Hi again Runtime team, I need one more review for this change. It is a P1 bug with a fairly small change. Any takers? Latest webrev based on comments from David Holmes and Vitaly Davidovich: http://cr.openjdk.java.net/~brutisso/7173959/webrev.03/ Thanks, Bengt On 12/14/12 9:29 AM, Bengt Rutisson wrote: > > Hi David, > > On 12/14/12 1:38 AM, David Holmes wrote: >> Hi Bengt, >> >> That all sounds good to me. >> >> With regard to potential overflow perhaps a simple check that >> extra_size does not overflow? If that is true and extra_base is not >> null then I think all the other calculations must be valid. > > Yes, that makes sense. I'll add an overflow check for the extra_size. > > Thanks, > Bengt > >> >> Thanks, >> David >> >> On 13/12/2012 10:58 PM, Bengt Rutisson wrote: >>> >>> Hi David, >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.02/ >>> >>> I moved the alignment of "size" back into ReservedSpace::initialize() >>> since we actually store the size in an instance variable (_size), so I >>> think it is a bit risky to just do the align_up in >>> os::reserve_memory_aligned(). We probably want the instance variables >>> _size and _alignment in ReservedSpace to be consistent. >>> >>> I added an assert in os::reserve_memory_aligned() to verify that the >>> size is correctly aligned. I also added the assert you suggested to >>> check that alignment is page size aligned. >>> >>> Bengt >>> >>> On 12/13/12 11:50 AM, David Holmes wrote: >>>> On 13/12/2012 8:37 PM, Bengt Rutisson wrote: >>>>> >>>>> Hi again, >>>>> >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.01/ >>>>> >>>>> I removed the comment and the alignment. >>>>> >>>>> But I did not add an assert just yet. >>>>> >>>>> At the top of ReservedSpace::initialize() we have this code: >>>>> >>>>> const size_t granularity = os::vm_allocation_granularity(); >>>>> assert((size & (granularity - 1)) == 0, >>>>> "size not aligned to os::vm_allocation_granularity()"); >>>>> assert((alignment & (granularity - 1)) == 0, >>>>> "alignment not aligned to os::vm_allocation_granularity()"); >>>>> >>>>> >>>>> Where os::vm_allocation_granularity() is implemented as page size >>>>> on all >>>>> platforms except Windows. There we look it up from the Windows API. I >>>>> assume that is a page size too, but since the Windows code in our >>>>> patch >>>>> does not unmap based on the alignment it should be safe either way. >>>>> >>>>> Is this assert enough or would you like me to add an assert closer to >>>>> the code block were I did the changes? >>>> >>>> As this is a separate method now I think an assert in the method >>>> itself would not go astray. >>>> >>>> David >>>> ----- >>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>> >>>>> On 12/13/12 11:02 AM, Bengt Rutisson wrote: >>>>>> >>>>>> Hi David, >>>>>> >>>>>> Thanks for looking at this! >>>>>> >>>>>> On 12/13/12 8:33 AM, David Holmes wrote: >>>>>>> Hi Bengt, >>>>>>> >>>>>>> This has to be one of the absolute best review requests I've ever >>>>>>> read :) Thank you. >>>>>> >>>>>> Wow! Thanks! :) >>>>>> >>>>>>> >>>>>>> Just a couple of queries. >>>>>>> >>>>>>> os_posix.cpp: >>>>>>> >>>>>>> Love the diagram :) >>>>>> >>>>>> It was Mikael's way of making sure we got it right. >>>>>> >>>>>>> I'm assuming that "alignment" has to be >= the underlying page >>>>>>> size, >>>>>>> and in fact must be a multiple of the underlying page size ? (As I >>>>>>> assume you can only unmap whole numbers of pages). If so does that >>>>>>> need to be checked somewhere? >>>>>> >>>>>> Good point. I'll add an assert to check that. >>>>>> >>>>>>> In virtualSpace.cpp: >>>>>>> >>>>>>> // Reserve size large enough to do manual alignment and >>>>>>> // increase size to a multiple of the desired alignment >>>>>>> size = align_size_up(size, alignment); >>>>>>> ! base = os::reserve_memory_aligned(size, alignment); >>>>>>> >>>>>>> The comment doesn't seem necessary now, and the align_size_up seems >>>>>>> redundant. >>>>>> >>>>>> You are right. I'll remove the comment and the alignment. >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 13/12/2012 4:42 PM, Bengt Rutisson wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Could I have a couple of reviews for this change? >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.00/ >>>>>>>> >>>>>>>> This is for a bug originally reported by the Coherence team: >>>>>>>> >>>>>>>> 7173959 : Jvm crashed during coherence exabus (tmb) testing >>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173959 >>>>>>>> >>>>>>>> The original analysis and proposed fix was done by Mikael Gerdin >>>>>>>> and me >>>>>>>> together. I'll handle the webrev and push since Mikael is on >>>>>>>> vacation >>>>>>>> starting today. But Mikael did a great job tracking down this very >>>>>>>> difficult bug, so he should have a large part of the credit for >>>>>>>> this >>>>>>>> bug >>>>>>>> fix, >>>>>>>> >>>>>>>> Description from the CR: >>>>>>>> >>>>>>>> The reason that we crash is due to how we re-map memory when we >>>>>>>> want to >>>>>>>> align it for large pages in ReservedSpace::initialize(). >>>>>>>> >>>>>>>> Here is what happens: >>>>>>>> >>>>>>>> The reservation of memory is split up to a few steps. When we >>>>>>>> want a >>>>>>>> chunk of memory with large pages we first just reserve some memory >>>>>>>> large >>>>>>>> enough for what we need. Then we realize that we want large pages, >>>>>>>> so we >>>>>>>> want to re-map the reserved memory to use large pages. But >>>>>>>> since this >>>>>>>> requires that we have a large-page-aligned memory chunk we may >>>>>>>> have to >>>>>>>> fix the recently reserved memory chunk up a bit. >>>>>>>> >>>>>>>> We do this in ReservedSpace::initialize() by first releasing the >>>>>>>> memory >>>>>>>> we just reserved. Then requesting more memory than we actually >>>>>>>> need to >>>>>>>> make sure that we have enough space to do manual large page >>>>>>>> alignment. >>>>>>>> After we have gotten this memory we figure out a nicely aligned >>>>>>>> start >>>>>>>> address. We then release the memory again and then reserve just >>>>>>>> enough >>>>>>>> memory but using the aligned start address as a fixed address >>>>>>>> to make >>>>>>>> sure that we get the memory we wanted in an aligned way. >>>>>>>> >>>>>>>> This is done in a loop to make sure that we eventually get some >>>>>>>> memory. >>>>>>>> The interesting code looks like this: >>>>>>>> >>>>>>>> do { >>>>>>>> char* extra_base = os::reserve_memory(extra_size, NULL, >>>>>>>> alignment); >>>>>>>> if (extra_base == NULL) return; >>>>>>>> // Do manual alignement >>>>>>>> base = (char*) align_size_up((uintptr_t) extra_base, alignment); >>>>>>>> assert(base >= extra_base, "just checking"); >>>>>>>> // Re-reserve the region at the aligned base address. >>>>>>>> os::release_memory(extra_base, extra_size); // (1) >>>>>>>> base = os::reserve_memory(size, base); // (2) >>>>>>>> } while (base == NULL); >>>>>>>> >>>>>>>> >>>>>>>> There is a race here between releasing the memory in (1) and >>>>>>>> re-reserving it in (2). But the loop is supposed to handle this >>>>>>>> race. >>>>>>>> >>>>>>>> The problem is that on posix platforms you can remap the same >>>>>>>> memory >>>>>>>> area several times. The call in (2) will use mmap with MAP_FIXED. >>>>>>>> This >>>>>>>> means that the OS will think that you know exactly what you are >>>>>>>> doing. >>>>>>>> So, if part of the memory has been mapped already by the >>>>>>>> process it >>>>>>>> will >>>>>>>> just go ahead and reuse that memory. >>>>>>>> >>>>>>>> This means that if we are having multiple threads that do mmap. We >>>>>>>> can >>>>>>>> end up with a situation where we release our mapping in (1). Then >>>>>>>> another thread comes in and maps part of the memory that we >>>>>>>> used to >>>>>>>> have. Then we remap over that memory again in (2) with MAP_FIXED. >>>>>>>> Now we >>>>>>>> have a situation where two threads in our process have mapped the >>>>>>>> same >>>>>>>> memory. If both threads try to use it or if one of the threads >>>>>>>> unmap >>>>>>>> part or all of the memory we will crash. >>>>>>>> >>>>>>>> On posix it is possible to unmap any part of a mapped chunk. >>>>>>>> So, our >>>>>>>> proposed solution to the race described above is to not unmap all >>>>>>>> memory >>>>>>>> in (1) but rather just unmap the section at the start and at the >>>>>>>> end of >>>>>>>> the chunk that we mapped to get alignment. This also removes >>>>>>>> the need >>>>>>>> for the loop. >>>>>>>> >>>>>>>> However, on Windows you can only unmap _all_ of the memory that >>>>>>>> you >>>>>>>> have >>>>>>>> mapped. On the other hand Windows also will not allow you to >>>>>>>> map over >>>>>>>> other mappings, so the original code is actually safe. If we keep >>>>>>>> the loop. >>>>>>>> >>>>>>>> So, our solution is to treat this differently on Windows and posix >>>>>>>> platforms. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Bengt >>>>>> >>>>> >>> > From john.coomes at oracle.com Fri Dec 14 02:21:12 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 Dec 2012 10:21:12 +0000 Subject: hg: hsx/hotspot-emb: 8 new changesets Message-ID: <20121214102112.AB49447156@hg.openjdk.java.net> Changeset: ab1ab9b148dd Author: smarks Date: 2012-11-28 17:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/ab1ab9b148dd 8004131: move jdi tests out of core testset Reviewed-by: alanb, chegar ! make/jprt.properties Changeset: ad54163c95f5 Author: lana Date: 2012-11-30 16:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/ad54163c95f5 Merge Changeset: 04435608c613 Author: lana Date: 2012-12-10 20:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/04435608c613 Merge Changeset: 6b96b7744913 Author: erikj Date: 2012-12-07 17:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/6b96b7744913 8004045: build-infra: Error 12 from zip when updating src.zip Summary: Hiding this error from make so that it doesn't fail Reviewed-by: ohrstrom, dholmes ! common/makefiles/JavaCompilation.gmk Changeset: 2795874efd16 Author: erikj Date: 2012-12-11 11:29 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/2795874efd16 8003945: build-infra: problems finding compiler when using --with-dev-kit Summary: Search all compiler names in dev-kit dir first. Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: e175ecff1391 Author: erikj Date: 2012-12-11 11:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/e175ecff1391 8001753: build-infra: mismatch with full debug symbol control for hotspot Summary: Enabling hotspot to use the FDS settings established at configure time Reviewed-by: dholmes, ohair ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/jdk-options.m4 ! common/makefiles/NativeCompilation.gmk Changeset: cdb401a60cea Author: katleman Date: 2012-12-12 13:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/cdb401a60cea Merge Changeset: e9ec00893bb4 Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/e9ec00893bb4 Added tag jdk8-b68 for changeset cdb401a60cea ! .hgtags From john.coomes at oracle.com Fri Dec 14 02:21:18 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 Dec 2012 10:21:18 +0000 Subject: hg: hsx/hotspot-emb/corba: Added tag jdk8-b68 for changeset 82000531feaa Message-ID: <20121214102121.70E2D47157@hg.openjdk.java.net> Changeset: 22ddcac208a8 Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/22ddcac208a8 Added tag jdk8-b68 for changeset 82000531feaa ! .hgtags From john.coomes at oracle.com Fri Dec 14 02:21:26 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 Dec 2012 10:21:26 +0000 Subject: hg: hsx/hotspot-emb/jaxp: Added tag jdk8-b68 for changeset b854e7008421 Message-ID: <20121214102132.4872747158@hg.openjdk.java.net> Changeset: 789a855de959 Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/789a855de959 Added tag jdk8-b68 for changeset b854e7008421 ! .hgtags From john.coomes at oracle.com Fri Dec 14 02:21:39 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 Dec 2012 10:21:39 +0000 Subject: hg: hsx/hotspot-emb/jaxws: Added tag jdk8-b68 for changeset d3fe408f3a9a Message-ID: <20121214102144.79A0347159@hg.openjdk.java.net> Changeset: 756323c99011 Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/756323c99011 Added tag jdk8-b68 for changeset d3fe408f3a9a ! .hgtags From john.coomes at oracle.com Fri Dec 14 02:24:46 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 Dec 2012 10:24:46 +0000 Subject: hg: hsx/hotspot-emb/jdk: 69 new changesets Message-ID: <20121214103932.F3BE74715B@hg.openjdk.java.net> Changeset: 39f9b2cc5738 Author: bae Date: 2012-11-28 12:28 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/39f9b2cc5738 4649812: GIFImageReader handles transparency incorrectly Reviewed-by: bae, prr Contributed-by: Vadim Pakhnushev ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java Changeset: 6569819eb2fe Author: bae Date: 2012-11-28 12:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/6569819eb2fe 5082749: GIF stream metadata specification of aspect ratio is incorrect Reviewed-by: bae, prr Contributed-by: Vadim Pakhnushev ! src/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html Changeset: 934595726263 Author: bae Date: 2012-11-28 14:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/934595726263 7064516: ImageIO.read() fails to load an image Reviewed-by: jgodinez, prr ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/awt/image/ColorConvertOp.java + test/sun/java2d/cmm/ColorConvertOp/InvalidRenderIntentTest.java Changeset: d54db1e16b97 Author: bae Date: 2012-11-30 11:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/d54db1e16b97 7124223: [macosx] Regression test failure with new exception, when glyph is positioned explicitly Reviewed-by: jgodinez ! src/share/classes/sun/print/PathGraphics.java Changeset: bd3b3cda125d Author: lana Date: 2012-11-30 16:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/bd3b3cda125d Merge Changeset: 3c5bf5ed45a9 Author: bae Date: 2012-12-03 16:26 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/3c5bf5ed45a9 7124347: [macosx] java.lang.InternalError: not implemented yet on call Graphics2D.drawRenderedImage Reviewed-by: prr, flar ! src/share/classes/sun/java2d/opengl/OGLBlitLoops.java ! src/share/classes/sun/java2d/opengl/OGLSurfaceDataProxy.java + test/sun/java2d/OpenGL/CustomCompositeTest.java Changeset: 1175410d98ea Author: serb Date: 2012-11-21 15:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/1175410d98ea 7124552: [macosx] NullPointerException in getBufferStrategy() 7124219: [macosx] Unable to draw images to fullscreen Reviewed-by: bae, anthony ! src/macosx/classes/sun/awt/CGraphicsConfig.java ! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java ! src/macosx/classes/sun/lwawt/LWCanvasPeer.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java + src/macosx/classes/sun/lwawt/LWGraphicsConfig.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/PlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java - src/share/classes/sun/awt/TextureSizeConstraining.java Changeset: 5b2c31d20a64 Author: serb Date: 2012-11-21 15:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/5b2c31d20a64 7193214: Consider simplifying CPlatformWindow.setResizable() Reviewed-by: anthony, denis ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m Changeset: c9dead63607c Author: serb Date: 2012-11-21 15:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c9dead63607c 7154516: [macosx] Popup menus have no visible borders Reviewed-by: anthony, denis ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java Changeset: 9cd48409539e Author: kizune Date: 2012-11-21 20:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/9cd48409539e 8003273: Missing testcase for 7171812 Reviewed-by: art, serb + test/javax/swing/dnd/7171812/JListWithScroll.java + test/javax/swing/dnd/7171812/bug7171812.java Changeset: 5600005b87fb Author: serb Date: 2012-11-27 17:03 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/5600005b87fb 8002308: [macosx] 7198229 should be applied to the user action only Reviewed-by: anthony, skovatch ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m + test/java/awt/Frame/FrameSetSizeStressTest/FrameSetSizeStressTest.java Changeset: 0e91d6f3019c Author: alexsch Date: 2012-11-29 07:42 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/0e91d6f3019c 8000423: Diacritic is not applyed to a base letter on Linux Reviewed-by: anthony, serb ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: abee1d528df1 Author: kshefov Date: 2012-11-30 12:39 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/abee1d528df1 7124242: [macosx] Test doesn't work because of the frame round corners in the LaF Reviewed-by: anthony, yan, alexsch ! test/javax/swing/text/CSSBorder/6796710/bug6796710.java Changeset: 35d8085aa14a Author: lana Date: 2012-11-30 17:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/35d8085aa14a Merge Changeset: da55ef766e48 Author: alexsch Date: 2012-12-04 15:26 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/da55ef766e48 6671481: NPE at javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelection Reviewed-by: serb ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java Changeset: bd175c70684c Author: alexsch Date: 2012-12-04 15:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/bd175c70684c 8003830: NPE at BasicTreeUI$Actions.page:4470 Reviewed-by: serb, alexsch Contributed-by: Jaroslav Tulach ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java + test/javax/swing/JTree/8003830/bug8003830.java Changeset: 009fd6e1d9f5 Author: alexsch Date: 2012-12-04 16:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/009fd6e1d9f5 8002077: Possible mnemonic issue on JFileChooser Save button on nimbus L&F Reviewed-by: serb ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUI.java Changeset: 4aad3e6f68d2 Author: jviswana Date: 2012-12-04 17:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/4aad3e6f68d2 4631925: JColor Chooser is not fully accessible Reviewed-by: alexsch ! src/share/classes/javax/swing/JColorChooser.java ! src/share/classes/javax/swing/colorchooser/ColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/ColorPanel.java ! src/share/classes/javax/swing/plaf/basic/BasicColorChooserUI.java Changeset: ea20c9388d90 Author: aph Date: 2012-12-04 14:02 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/ea20c9388d90 8004344: Fix a crash in ToolkitErrorHandler() in XlibWrapper.c Summary: Code does not check for JNU_GetEnv returning NULL. Reviewed-by: anthony ! src/solaris/native/sun/xawt/XlibWrapper.c Changeset: bbbb5c70aa59 Author: lana Date: 2012-12-04 11:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/bbbb5c70aa59 Merge - src/share/classes/sun/awt/TextureSizeConstraining.java Changeset: f389bf27fc4f Author: dbuck Date: 2012-11-20 21:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/f389bf27fc4f 7198904: (alt-rt) TreeMap.clone is broken Summary: Test case for cr7198904. Issue only found in OracleJDK, but test case is valid for OpenJDK as well Reviewed-by: mduigou, dholmes + test/java/util/TreeMap/Clone.java Changeset: ee6e5b7d5d55 Author: uta Date: 2012-11-23 13:07 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/ee6e5b7d5d55 8003898: X11 toolkit can be chosen as the default toolkit Summary: XToolkit is not selected for any values of system-wide environment variables (ex. DISPLAY). Reviewed-by: anthony, art ! src/solaris/native/java/lang/java_props_macosx.c Changeset: 621c379d909d Author: xuelei Date: 2012-11-24 03:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/621c379d909d 8001751: Javadoc warnings in JSSE code Reviewed-by: alanb ! src/share/classes/javax/net/ssl/HostnameVerifier.java ! src/share/classes/javax/net/ssl/SNIHostName.java ! src/share/classes/javax/net/ssl/SNIMatcher.java ! src/share/classes/javax/net/ssl/SNIServerName.java ! src/share/classes/javax/net/ssl/SSLParameters.java ! src/share/classes/javax/net/ssl/SSLSocketFactory.java Changeset: f7d45462b225 Author: xuelei Date: 2012-11-24 04:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/f7d45462b225 8003950: Adds missing Override annotations and removes unnecessary imports in sun.security.ssl Reviewed-by: xuelei Contributed-by: Florian Weimer ! src/share/classes/sun/security/ssl/AppInputStream.java ! src/share/classes/sun/security/ssl/AppOutputStream.java ! src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java ! src/share/classes/sun/security/ssl/ByteBufferInputStream.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/CipherSuiteList.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/DHClientKeyExchange.java ! src/share/classes/sun/security/ssl/ECDHClientKeyExchange.java ! src/share/classes/sun/security/ssl/ECDHCrypt.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/EngineWriter.java ! src/share/classes/sun/security/ssl/ExtensionType.java ! src/share/classes/sun/security/ssl/HandshakeHash.java ! src/share/classes/sun/security/ssl/HandshakeInStream.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/HandshakeOutStream.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/HelloExtension.java ! src/share/classes/sun/security/ssl/HelloExtensions.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java ! src/share/classes/sun/security/ssl/KeyManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/Krb5Helper.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/ProtocolList.java ! src/share/classes/sun/security/ssl/ProtocolVersion.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java ! src/share/classes/sun/security/ssl/RSASignature.java ! src/share/classes/sun/security/ssl/RenegotiationInfoExtension.java ! src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java ! src/share/classes/sun/security/ssl/SSLContextImpl.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/ServerNameExtension.java ! src/share/classes/sun/security/ssl/SessionId.java ! src/share/classes/sun/security/ssl/SunJSSE.java ! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/SupportedEllipticCurvesExtension.java ! src/share/classes/sun/security/ssl/SupportedEllipticPointFormatsExtension.java ! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/UnknownExtension.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/X509TrustManagerImpl.java Changeset: d30c13172254 Author: xuelei Date: 2012-11-24 04:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/d30c13172254 8003951: Removes unused variables in sun.security.ssl Reviewed-by: xuelei Contributed-by: Florian Weimer ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/X509TrustManagerImpl.java Changeset: 8970128e040d Author: uta Date: 2012-11-26 15:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/8970128e040d 7162111: TEST_BUG: change tests run in headless mode [macosx] (open) Summary: In problem tests detection of AWT headless mode was introduced or AWT dependence was removed. Reviewed-by: alanb ! test/ProblemList.txt ! test/demo/jvmti/mtrace/TraceJFrame.java ! test/java/io/Serializable/resolveClass/deserializeButton/Foo.java ! test/java/io/Serializable/resolveClass/deserializeButton/Test.java ! test/java/io/Serializable/resolveClass/deserializeButton/run.sh Changeset: 054470092795 Author: mullan Date: 2012-11-26 08:12 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/054470092795 7167056: Clarify that BasicPermission names that contain non-wildcard asterisks are not invalid Reviewed-by: weijun, xuelei ! src/share/classes/com/sun/net/ssl/SSLPermission.java ! src/share/classes/java/lang/RuntimePermission.java ! src/share/classes/java/net/NetPermission.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/sql/SQLPermission.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/javax/net/ssl/SSLPermission.java + test/java/security/BasicPermission/Wildcard.java Changeset: ea66140be78d Author: mullan Date: 2012-11-26 08:23 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/ea66140be78d Merge - makefiles/docs/CORE_PKGS.gmk - makefiles/docs/Makefile - makefiles/docs/NON_CORE_PKGS.gmk - makefiles/docs/Notes.html - makefiles/mapfiles/launchers/mapfile-amd64 - makefiles/mapfiles/launchers/mapfile-i586 - makefiles/mapfiles/libawt_headless/reorder-i586 - makefiles/mapfiles/libjava/reorder-i586 - makefiles/mapfiles/libjpeg/reorder-i586 - makefiles/mapfiles/libnio/mapfile-bsd - makefiles/mapfiles/libnio/reorder-i586 - makefiles/mapfiles/libverify/reorder-i586 - makefiles/mapfiles/libzip/reorder-i586 - makefiles/sun/xawt/ToBin.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/sql/SQLPermission.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/javax/net/ssl/SSLPermission.java - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java Changeset: d7ed56d57d97 Author: mullan Date: 2012-11-26 08:34 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/d7ed56d57d97 Merge Changeset: c2e80176a697 Author: mduigou Date: 2012-11-26 15:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c2e80176a697 8001634: Initial set of functional interface types Summary: Add the core functional interfaces used by the JSR335 libraries. Reviewed-by: dholmes, briangoetz, darcy ! make/docs/CORE_PKGS.gmk ! make/java/java/Makefile + src/share/classes/java/util/function/BinaryOperator.java + src/share/classes/java/util/function/Block.java + src/share/classes/java/util/function/DoubleBinaryOperator.java + src/share/classes/java/util/function/DoubleBlock.java + src/share/classes/java/util/function/DoubleFunction.java + src/share/classes/java/util/function/DoubleSupplier.java + src/share/classes/java/util/function/DoubleUnaryOperator.java + src/share/classes/java/util/function/Function.java + src/share/classes/java/util/function/IntBinaryOperator.java + src/share/classes/java/util/function/IntBlock.java + src/share/classes/java/util/function/IntFunction.java + src/share/classes/java/util/function/IntSupplier.java + src/share/classes/java/util/function/IntUnaryOperator.java + src/share/classes/java/util/function/LongBinaryOperator.java + src/share/classes/java/util/function/LongBlock.java + src/share/classes/java/util/function/LongFunction.java + src/share/classes/java/util/function/LongSupplier.java + src/share/classes/java/util/function/LongUnaryOperator.java + src/share/classes/java/util/function/Predicate.java + src/share/classes/java/util/function/Supplier.java + src/share/classes/java/util/function/UnaryOperator.java + src/share/classes/java/util/function/package-info.java Changeset: ddf97baea570 Author: chegar Date: 2012-11-27 17:15 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/ddf97baea570 8003833: Spurious NPE from Socket.getIn/OutputStream Reviewed-by: alanb, dsamersoff ! src/share/classes/java/net/AbstractPlainSocketImpl.java + test/java/net/Socket/Streams.java Changeset: 40311b5f478f Author: robm Date: 2012-11-28 00:47 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/40311b5f478f 8003597: TEST_BUG: Eliminate dependency on javaweb from closed net tests Reviewed-by: chegar + test/java/net/ResponseCache/Test.java + test/java/net/Socket/B6210227.java Changeset: 39b25d5880c6 Author: sherman Date: 2012-11-27 21:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/39b25d5880c6 4235519: Make sun.misc.BASE64{De,En}coder classes public Summary: to add java.util.Base64 Reviewed-by: alanb, mduigou ! make/java/java/FILES_java.gmk Changeset: c6ed2c238d4f Author: sherman Date: 2012-11-27 22:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c6ed2c238d4f 8004088: hg push for bug#4235519 failed to push all files Summary: pushed all base64 files Reviewed-by: alanb, mduigou + src/share/classes/java/util/Base64.java + test/java/util/Base64/TestBase64.java + test/java/util/Base64/TestBase64Golden.java + test/java/util/Base64/baseEncode.txt + test/java/util/Base64/mimeEncode.txt + test/java/util/Base64/plain.txt + test/java/util/Base64/urlEncode.txt Changeset: 46c627801490 Author: xuelei Date: 2012-11-28 05:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/46c627801490 8004019: Removes unused method HandshakeHash.setCertificateVerifyAlg() Summary: certification verification in HandshakeHash was abandoned during TLS 1.2 implementation Reviewed-by: xuelei, weijun Contributed-by: Florian Weimer ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/HandshakeHash.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java Changeset: 735b93462eed Author: jfranck Date: 2012-11-28 09:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/735b93462eed 7154390: Add support for repeating annotations in j.l.r.AnnotatedElement Reviewed-by: darcy ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/annotation/ContainedBy.java ! src/share/classes/java/lang/annotation/ContainerFor.java + src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java ! src/share/classes/java/lang/reflect/AccessibleObject.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java + src/share/classes/sun/reflect/annotation/AnnotationSupport.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java + test/java/lang/annotation/repeatingAnnotations/RepeatedUnitTest.java + test/java/lang/annotation/repeatingAnnotations/subpackage/Containee.java + test/java/lang/annotation/repeatingAnnotations/subpackage/Container.java + test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainee.java + test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainer.java + test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedNonRepeated.java + test/java/lang/annotation/repeatingAnnotations/subpackage/NonRepeated.java + test/java/lang/annotation/repeatingAnnotations/subpackage/package-info.java Changeset: 3b6a2fe6d75c Author: dfuchs Date: 2012-11-28 15:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/3b6a2fe6d75c 8003476: Cleanup warnings in com.sun.jmx.snmp code Reviewed-by: alanb, smarks ! src/share/classes/com/sun/jmx/snmp/EnumRowStatus.java ! src/share/classes/com/sun/jmx/snmp/Enumerated.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/AclImpl.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMAclBlock.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMInformBlock.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMTrapBlock.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JJTParserState.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/Parser.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/SnmpAcl.java ! src/share/classes/com/sun/jmx/snmp/InetAddressAcl.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpErrorHandlerAgent.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpGenericObjectServer.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpIndex.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibOid.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibRequest.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibRequestImpl.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibSubRequest.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpRequestTree.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpStandardObjectServer.java ! src/share/classes/com/sun/jmx/snmp/daemon/CommunicatorServer.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServer.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServerMBean.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpMibTree.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubBulkRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/defaults/SnmpProperties.java ! src/share/classes/com/sun/jmx/snmp/tasks/ThreadService.java ! src/share/classes/sun/management/snmp/AdaptorBootstrap.java Changeset: 262b3b2f3aa3 Author: dfuchs Date: 2012-11-28 10:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/262b3b2f3aa3 Merge Changeset: 09bef1e118e3 Author: mchung Date: 2012-11-28 10:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/09bef1e118e3 8003851: MethodHandleNatives dependency on java.sql.DriverManager Reviewed-by: alanb, dholmes ! src/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: 80ddee59a21d Author: mchung Date: 2012-11-28 10:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/80ddee59a21d 8003869: Eliminate java.lang.invoke.InnerClassLambdaMetafactory dependency on java.util.logging Reviewed-by: alanb, dholmes ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java Changeset: 13ec794734f5 Author: michaelm Date: 2012-11-29 09:41 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/13ec794734f5 7200720: crash in net.dll during NTLM authentication Reviewed-by: chegar, dsamersoff ! make/java/net/Makefile ! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.java ! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java ! src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.c Changeset: ba5eabd6a37b Author: michaelm Date: 2012-11-29 09:47 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/ba5eabd6a37b Merge Changeset: 2b829a5a46ee Author: jgish Date: 2012-11-29 12:28 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/2b829a5a46ee 8003380: Compiler warnings in logging test code Summary: Use generics, suppress warnings where appropriate, remove unused imports, etc. Reviewed-by: lancea, chegar ! test/java/util/logging/ClassLoaderLeakTest.java ! test/java/util/logging/Listeners.java ! test/java/util/logging/ListenersWithSM.java ! test/java/util/logging/LoggerResourceBundleRace.java ! test/java/util/logging/LoggingDeadlock2.java ! test/java/util/logging/LoggingDeadlock3.java ! test/java/util/logging/LoggingDeadlock4.java ! test/java/util/logging/LoggingMXBeanTest.java ! test/java/util/logging/LoggingMXBeanTest2.java ! test/java/util/logging/MemoryHandlerTest.java ! test/java/util/logging/ParentLoggersTest.java ! test/java/util/logging/SimpleFormatterFormat.java Changeset: d91e6cb1da41 Author: shade Date: 2012-11-29 17:03 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/d91e6cb1da41 8004141: UnsafeStaticFieldAccessorImpl#base should be final Reviewed-by: chegar, alanb Contributed-by: peter.levart at gmail.com ! src/share/classes/sun/reflect/UnsafeStaticFieldAccessorImpl.java Changeset: bf6ceb6b8f80 Author: mduigou Date: 2012-11-29 14:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/bf6ceb6b8f80 7175464: entrySetView field is never updated in NavigableSubMap Summary: The method entrySet() in AscendingSubMap and DescendingSubMap failed to cache the entrySetView. Reviewed-by: alanb, psandoz ! src/share/classes/java/util/TreeMap.java Changeset: 75cb07a7b622 Author: mduigou Date: 2012-11-29 14:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/75cb07a7b622 6553074: String{Buffer,Builder}.indexOf(Str, int) contains unnecessary allocation Summary: It is not necessary to extract the value array with toCharArray. The value array can now be used directly. Reviewed-by: alanb ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/String.java Changeset: 83d9f30ebeed Author: smarks Date: 2012-11-28 17:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/83d9f30ebeed 8004131: move jdi tests out of core testset Reviewed-by: alanb, chegar ! make/jprt.properties Changeset: 7ccf93c60c4d Author: smarks Date: 2012-11-29 14:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/7ccf93c60c4d 8004134: More ProblemList.txt updates (11/2012) Reviewed-by: alanb Contributed-by: amy.lu at oracle.com ! test/ProblemList.txt Changeset: 55f8ddc2f9c6 Author: sla Date: 2012-11-30 08:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/55f8ddc2f9c6 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo Reviewed-by: okutsu ! test/java/util/TimeZone/Bug6912560.java Changeset: e988de7465d4 Author: zhangshj Date: 2012-11-30 17:24 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e988de7465d4 8004211: Remove unused dlinfo local variable in launcher code Reviewed-by: alanb ! src/solaris/bin/java_md_solinux.c Changeset: 72d3d07b625d Author: alanb Date: 2012-11-30 11:18 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/72d3d07b625d 8003949: LogManager, downgrade normative reference to ${java.home}/lib/logging.properties Reviewed-by: psandoz, mchung ! src/share/classes/java/util/logging/LogManager.java Changeset: c370048be8fc Author: alanb Date: 2012-11-30 16:29 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c370048be8fc 7165762: (aio) Default thread pool should be configured so that threads terminated after a timeout period Reviewed-by: chegar ! src/share/classes/sun/nio/ch/ThreadPool.java Changeset: e7edb0da9c6a Author: jfranck Date: 2012-11-30 09:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e7edb0da9c6a 8004110: Remove debug code form sun/reflect/annotation/AnnotationSupport.java Reviewed-by: jjg, darcy ! src/share/classes/sun/reflect/annotation/AnnotationSupport.java Changeset: 43d2e02c4098 Author: khazra Date: 2012-11-30 12:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/43d2e02c4098 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by "couldn't get file lock" Summary: Set -Djava.util.prefs.userRoot to current working directory of user in the prefs tests Reviewed-by: alanb, chegar, weijun, dxu ! test/java/util/prefs/AddNodeChangeListener.java ! test/java/util/prefs/CheckUserPrefsStorage.sh ! test/java/util/prefs/CommentsInXml.java ! test/java/util/prefs/ConflictInFlush.java ! test/java/util/prefs/ExportNode.java ! test/java/util/prefs/ExportSubtree.java ! test/java/util/prefs/PrefsSpi.sh ! test/java/util/prefs/RemoveNullKeyCheck.java ! test/java/util/prefs/RemoveReadOnlyNode.java ! test/java/util/prefs/RemoveUnregedListener.java Changeset: e66ec5b8c15e Author: lana Date: 2012-11-30 16:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e66ec5b8c15e Merge Changeset: fd8ba2d8baec Author: sherman Date: 2012-12-01 11:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/fd8ba2d8baec 8004212: java.util.Base64 methods decodeArray and decodeBuffer should return the number of bytes written Summary: to return the length instead of position Reviewed-by: alanb ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java Changeset: f657adf4fe78 Author: alanb Date: 2012-12-02 16:37 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/f657adf4fe78 8003846: Override mechanism for currency data should not require creating currency.properties in java.home Reviewed-by: naoto ! src/share/classes/java/util/Currency.java ! test/java/util/Currency/PropertiesTest.java ! test/java/util/Currency/PropertiesTest.sh Changeset: 60550cd2b527 Author: dholmes Date: 2012-12-02 19:16 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/60550cd2b527 7200297: agent code does not handle multiple boot library path elements correctly Summary: When bug 6819213 was fixed it enabled sun.boot.library.path property to contain multiple paths. Code in agents does not handle multiple paths when attempting to find dependent shared libs. Reviewed-by: dholmes, sspitsyn, dsamersoff Contributed-by: Bill Pittore ! src/share/back/debugInit.c ! src/share/back/error_messages.c ! src/share/back/transport.c ! src/share/demo/jvmti/hprof/hprof.h ! src/share/demo/jvmti/hprof/hprof_init.c ! src/solaris/back/linker_md.c ! src/solaris/demo/jvmti/hprof/hprof_md.c ! src/solaris/npt/npt_md.h ! src/windows/back/linker_md.c ! src/windows/demo/jvmti/hprof/hprof_md.c ! src/windows/npt/npt_md.h Changeset: a42da685dfca Author: weijun Date: 2012-12-03 17:14 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/a42da685dfca 7198507: [TEST_BUG] sun/security/tools/keytool/console.sh should be rewritten Reviewed-by: xuelei ! test/sun/security/tools/keytool/console.sh Changeset: ead651efb271 Author: xuelei Date: 2012-12-03 06:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/ead651efb271 8004184: security tests leave JSSEServer running Summary: Use othervm mode to release resources, and correct the system properties issues in JSSE Reviewed-by: chegar ! test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java Changeset: ee9846f351d7 Author: mullan Date: 2012-12-03 11:07 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/ee9846f351d7 7199143: RFE: OCSP revocation checker should provide possibility to specify connection timeout Summary: Added com.sun.security.ocsp.timeout system property to control timeout Reviewed-by: mullan, vinnie Contributed-by: jason.uh at oracle.com ! src/share/classes/sun/security/provider/certpath/OCSP.java Changeset: 38ec2838dd86 Author: dxu Date: 2012-12-04 14:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/38ec2838dd86 7142921: (fs) Files.probeContentType reports a MIME type of "text/plain" on Ubuntu 11.04 7144997: (fs) Files.probeContentType returns null on Solaris 64-bit Reviewed-by: alanb, mduigou ! make/java/nio/Makefile ! make/java/nio/mapfile-linux ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/mapfiles/libnio/mapfile-linux ! src/solaris/classes/sun/nio/fs/BsdFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/MacOSXFileSystemProvider.java + src/solaris/classes/sun/nio/fs/MagicFileTypeDetector.java + src/solaris/classes/sun/nio/fs/MimeTypesFileTypeDetector.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java + src/solaris/native/sun/nio/fs/MagicFileTypeDetector.c Changeset: 2e8863c4f7d0 Author: kmo Date: 2012-12-04 15:10 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/2e8863c4f7d0 8004066: TEST_BUG: test/java/lang/Math/DivModTests.java assumes ArithmeticException message Reviewed-by: twisti, alanb, dholmes ! test/java/lang/Math/DivModTests.java Changeset: 87028eb3f020 Author: lana Date: 2012-12-04 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/87028eb3f020 Merge Changeset: b68a5404de60 Author: lana Date: 2012-12-10 20:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/b68a5404de60 Merge ! makefiles/CompileJavaClasses.gmk - src/share/classes/sun/awt/TextureSizeConstraining.java Changeset: 379e3dfa521d Author: erikj Date: 2012-12-06 12:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/379e3dfa521d 8004104: build-infra: Minor cleanup Reviewed-by: ohrstrom, tbell ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk Changeset: 2689f6cfe835 Author: erikj Date: 2012-12-11 12:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/2689f6cfe835 8001753: build-infra: mismatch with full debug symbol control for hotspot Summary: Changing boolean values of ENABLE_DEBUG_SYMBOLS. Reviewed-by: dholmes, ohair ! makefiles/CompileNativeLibraries.gmk Changeset: 53fb43e4d614 Author: katleman Date: 2012-12-12 13:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/53fb43e4d614 Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk Changeset: 7fd56a5abd94 Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/7fd56a5abd94 Added tag jdk8-b68 for changeset 53fb43e4d614 ! .hgtags From john.coomes at oracle.com Fri Dec 14 02:42:16 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 Dec 2012 10:42:16 +0000 Subject: hg: hsx/hotspot-emb/langtools: 13 new changesets Message-ID: <20121214104316.AF2DC4715C@hg.openjdk.java.net> Changeset: d9fe1f80515d Author: vromero Date: 2012-11-21 18:40 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/d9fe1f80515d 7190862: javap shows an incorrect type for operands if the 'wide' prefix is used 7109747: (javap) classfile not treating iinc_w correctly. Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/classfile/Instruction.java ! src/share/classes/com/sun/tools/classfile/Opcode.java + test/tools/javap/T7190862.java Changeset: 3746b071d75b Author: vromero Date: 2012-11-21 19:09 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/3746b071d75b 6574624: javax.tools.JavaCompiler spec contains errors in sample code Reviewed-by: jjg, mcimadamore ! src/share/classes/javax/tools/JavaCompiler.java Changeset: 4d68e2a05b50 Author: jjg Date: 2012-11-27 13:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/4d68e2a05b50 8004068: Fix build problems caused by on-demand imports Reviewed-by: jjg Contributed-by: eric.caspole at amd.com ! src/share/classes/com/sun/tools/javac/code/Types.java Changeset: 1f41a5758cf7 Author: vromero Date: 2012-11-23 15:13 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/1f41a5758cf7 7144981: javac should ignore ignorable characters in input Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java + test/tools/javac/7144981/IgnoreIgnorableCharactersInInput.java Changeset: 969c96b980b7 Author: vromero Date: 2012-11-29 09:41 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/969c96b980b7 7153958: add constant pool reference to class containing inlined constants Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/7153958/CPoolRefClassContainingInlinedCts.java + test/tools/javac/7153958/pkg/ClassToBeStaticallyImported.java Changeset: 4f9853659bf1 Author: mcimadamore Date: 2012-11-30 15:14 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/4f9853659bf1 8004105: Expression statement lambdas should be void-compatible Summary: Fix lambda compatibility rules as per latest EDR Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! test/tools/javac/lambda/LambdaConv21.java ! test/tools/javac/lambda/LambdaConv21.out ! test/tools/javac/lambda/VoidCompatibility.out Changeset: 34d1ebaf4645 Author: mcimadamore Date: 2012-11-30 15:14 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/34d1ebaf4645 8004102: Add support for generic functional descriptors Summary: Method references are allowed to have a generic functional interface descriptor target Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties - test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java + test/tools/javac/diags/examples/InvalidGenericLambdaTarget.java + test/tools/javac/lambda/FunctionalInterfaceConversionTest.java - test/tools/javac/lambda/LambdaConversionTest.java + test/tools/javac/lambda/MethodReference57.java + test/tools/javac/lambda/MethodReference58.java + test/tools/javac/lambda/MethodReference58.out Changeset: 9b26c96f5138 Author: mcimadamore Date: 2012-11-30 15:14 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/9b26c96f5138 8004101: Add checks for method reference well-formedness Summary: Bring method reference type-checking in sync with latest EDR Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/diags/examples/StaticBoundMref.java + test/tools/javac/diags/examples/StaticMrefWithTargs.java ! test/tools/javac/lambda/MethodReference30.java + test/tools/javac/lambda/MethodReference55.java + test/tools/javac/lambda/MethodReference55.out + test/tools/javac/lambda/MethodReference56.java + test/tools/javac/lambda/MethodReference56.out ! test/tools/javac/lambda/methodReference/MethodRef1.java ! test/tools/javac/lambda/methodReference/SamConversion.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestKinds.java Changeset: f6f1fd261f57 Author: mcimadamore Date: 2012-11-30 15:14 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/f6f1fd261f57 8002099: Add support for intersection types in cast expression Summary: Add parser and type-checking support for intersection types in cast expressions Reviewed-by: jjg + src/share/classes/com/sun/source/tree/IntersectionTypeTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java + src/share/classes/javax/lang/model/type/IntersectionType.java ! src/share/classes/javax/lang/model/type/TypeKind.java ! src/share/classes/javax/lang/model/type/TypeVisitor.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java + test/tools/javac/cast/intersection/IntersectionTypeCastTest.java + test/tools/javac/cast/intersection/IntersectionTypeParserTest.java + test/tools/javac/cast/intersection/model/Check.java + test/tools/javac/cast/intersection/model/IntersectionTypeInfo.java + test/tools/javac/cast/intersection/model/Member.java + test/tools/javac/cast/intersection/model/Model01.java + test/tools/javac/cast/intersection/model/ModelChecker.java + test/tools/javac/diags/examples/IntersectionTypesInCastNotSupported.java + test/tools/javac/diags/examples/SecondaryBoundMustBeMarkerIntf.java + test/tools/javac/lambda/Intersection01.java + test/tools/javac/lambda/Intersection01.out ! test/tools/javac/lambda/LambdaParserTest.java + test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java Changeset: 98e14fc9ee11 Author: lana Date: 2012-11-30 16:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/98e14fc9ee11 Merge Changeset: 0e70eb71fec0 Author: mcimadamore Date: 2012-12-04 17:19 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/0e70eb71fec0 8004360: regression test DefaultMethodRegressionTests fails in langtools Summary: ignore broken failing test Reviewed-by: jjg - test/tools/javac/defaultMethodExecution/DefaultMethodRegressionTests.java + test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java Changeset: 014a6a11dfe5 Author: lana Date: 2012-12-10 20:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/014a6a11dfe5 Merge - test/tools/javac/defaultMethodExecution/DefaultMethodRegressionTests.java - test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java - test/tools/javac/lambda/LambdaConversionTest.java Changeset: 13ccb5269f3d Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/13ccb5269f3d Added tag jdk8-b68 for changeset 014a6a11dfe5 ! .hgtags From john.coomes at oracle.com Fri Dec 14 03:10:12 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 Dec 2012 11:10:12 +0000 Subject: hg: hsx/hotspot-rt: 8 new changesets Message-ID: <20121214111013.0E89147163@hg.openjdk.java.net> Changeset: ab1ab9b148dd Author: smarks Date: 2012-11-28 17:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/ab1ab9b148dd 8004131: move jdi tests out of core testset Reviewed-by: alanb, chegar ! make/jprt.properties Changeset: ad54163c95f5 Author: lana Date: 2012-11-30 16:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/ad54163c95f5 Merge Changeset: 04435608c613 Author: lana Date: 2012-12-10 20:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/04435608c613 Merge Changeset: 6b96b7744913 Author: erikj Date: 2012-12-07 17:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/6b96b7744913 8004045: build-infra: Error 12 from zip when updating src.zip Summary: Hiding this error from make so that it doesn't fail Reviewed-by: ohrstrom, dholmes ! common/makefiles/JavaCompilation.gmk Changeset: 2795874efd16 Author: erikj Date: 2012-12-11 11:29 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/2795874efd16 8003945: build-infra: problems finding compiler when using --with-dev-kit Summary: Search all compiler names in dev-kit dir first. Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: e175ecff1391 Author: erikj Date: 2012-12-11 11:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/e175ecff1391 8001753: build-infra: mismatch with full debug symbol control for hotspot Summary: Enabling hotspot to use the FDS settings established at configure time Reviewed-by: dholmes, ohair ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/jdk-options.m4 ! common/makefiles/NativeCompilation.gmk Changeset: cdb401a60cea Author: katleman Date: 2012-12-12 13:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/cdb401a60cea Merge Changeset: e9ec00893bb4 Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/e9ec00893bb4 Added tag jdk8-b68 for changeset cdb401a60cea ! .hgtags From john.coomes at oracle.com Fri Dec 14 03:10:17 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 Dec 2012 11:10:17 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b68 for changeset 82000531feaa Message-ID: <20121214111019.C44BE47164@hg.openjdk.java.net> Changeset: 22ddcac208a8 Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/22ddcac208a8 Added tag jdk8-b68 for changeset 82000531feaa ! .hgtags From john.coomes at oracle.com Fri Dec 14 03:10:24 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 Dec 2012 11:10:24 +0000 Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b68 for changeset b854e7008421 Message-ID: <20121214111036.13B5C47165@hg.openjdk.java.net> Changeset: 789a855de959 Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/789a855de959 Added tag jdk8-b68 for changeset b854e7008421 ! .hgtags From john.coomes at oracle.com Fri Dec 14 03:10:41 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 Dec 2012 11:10:41 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b68 for changeset d3fe408f3a9a Message-ID: <20121214111045.5995F47166@hg.openjdk.java.net> Changeset: 756323c99011 Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/756323c99011 Added tag jdk8-b68 for changeset d3fe408f3a9a ! .hgtags From john.coomes at oracle.com Fri Dec 14 03:13:10 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 Dec 2012 11:13:10 +0000 Subject: hg: hsx/hotspot-rt/jdk: 69 new changesets Message-ID: <20121214112724.32DC647168@hg.openjdk.java.net> Changeset: 39f9b2cc5738 Author: bae Date: 2012-11-28 12:28 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/39f9b2cc5738 4649812: GIFImageReader handles transparency incorrectly Reviewed-by: bae, prr Contributed-by: Vadim Pakhnushev ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java Changeset: 6569819eb2fe Author: bae Date: 2012-11-28 12:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6569819eb2fe 5082749: GIF stream metadata specification of aspect ratio is incorrect Reviewed-by: bae, prr Contributed-by: Vadim Pakhnushev ! src/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html Changeset: 934595726263 Author: bae Date: 2012-11-28 14:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/934595726263 7064516: ImageIO.read() fails to load an image Reviewed-by: jgodinez, prr ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/awt/image/ColorConvertOp.java + test/sun/java2d/cmm/ColorConvertOp/InvalidRenderIntentTest.java Changeset: d54db1e16b97 Author: bae Date: 2012-11-30 11:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d54db1e16b97 7124223: [macosx] Regression test failure with new exception, when glyph is positioned explicitly Reviewed-by: jgodinez ! src/share/classes/sun/print/PathGraphics.java Changeset: bd3b3cda125d Author: lana Date: 2012-11-30 16:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bd3b3cda125d Merge Changeset: 3c5bf5ed45a9 Author: bae Date: 2012-12-03 16:26 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3c5bf5ed45a9 7124347: [macosx] java.lang.InternalError: not implemented yet on call Graphics2D.drawRenderedImage Reviewed-by: prr, flar ! src/share/classes/sun/java2d/opengl/OGLBlitLoops.java ! src/share/classes/sun/java2d/opengl/OGLSurfaceDataProxy.java + test/sun/java2d/OpenGL/CustomCompositeTest.java Changeset: 1175410d98ea Author: serb Date: 2012-11-21 15:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1175410d98ea 7124552: [macosx] NullPointerException in getBufferStrategy() 7124219: [macosx] Unable to draw images to fullscreen Reviewed-by: bae, anthony ! src/macosx/classes/sun/awt/CGraphicsConfig.java ! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java ! src/macosx/classes/sun/lwawt/LWCanvasPeer.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java + src/macosx/classes/sun/lwawt/LWGraphicsConfig.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/PlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java - src/share/classes/sun/awt/TextureSizeConstraining.java Changeset: 5b2c31d20a64 Author: serb Date: 2012-11-21 15:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5b2c31d20a64 7193214: Consider simplifying CPlatformWindow.setResizable() Reviewed-by: anthony, denis ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m Changeset: c9dead63607c Author: serb Date: 2012-11-21 15:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c9dead63607c 7154516: [macosx] Popup menus have no visible borders Reviewed-by: anthony, denis ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java Changeset: 9cd48409539e Author: kizune Date: 2012-11-21 20:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9cd48409539e 8003273: Missing testcase for 7171812 Reviewed-by: art, serb + test/javax/swing/dnd/7171812/JListWithScroll.java + test/javax/swing/dnd/7171812/bug7171812.java Changeset: 5600005b87fb Author: serb Date: 2012-11-27 17:03 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5600005b87fb 8002308: [macosx] 7198229 should be applied to the user action only Reviewed-by: anthony, skovatch ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m + test/java/awt/Frame/FrameSetSizeStressTest/FrameSetSizeStressTest.java Changeset: 0e91d6f3019c Author: alexsch Date: 2012-11-29 07:42 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0e91d6f3019c 8000423: Diacritic is not applyed to a base letter on Linux Reviewed-by: anthony, serb ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: abee1d528df1 Author: kshefov Date: 2012-11-30 12:39 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/abee1d528df1 7124242: [macosx] Test doesn't work because of the frame round corners in the LaF Reviewed-by: anthony, yan, alexsch ! test/javax/swing/text/CSSBorder/6796710/bug6796710.java Changeset: 35d8085aa14a Author: lana Date: 2012-11-30 17:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/35d8085aa14a Merge Changeset: da55ef766e48 Author: alexsch Date: 2012-12-04 15:26 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/da55ef766e48 6671481: NPE at javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelection Reviewed-by: serb ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java Changeset: bd175c70684c Author: alexsch Date: 2012-12-04 15:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bd175c70684c 8003830: NPE at BasicTreeUI$Actions.page:4470 Reviewed-by: serb, alexsch Contributed-by: Jaroslav Tulach ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java + test/javax/swing/JTree/8003830/bug8003830.java Changeset: 009fd6e1d9f5 Author: alexsch Date: 2012-12-04 16:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/009fd6e1d9f5 8002077: Possible mnemonic issue on JFileChooser Save button on nimbus L&F Reviewed-by: serb ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUI.java Changeset: 4aad3e6f68d2 Author: jviswana Date: 2012-12-04 17:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4aad3e6f68d2 4631925: JColor Chooser is not fully accessible Reviewed-by: alexsch ! src/share/classes/javax/swing/JColorChooser.java ! src/share/classes/javax/swing/colorchooser/ColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/ColorPanel.java ! src/share/classes/javax/swing/plaf/basic/BasicColorChooserUI.java Changeset: ea20c9388d90 Author: aph Date: 2012-12-04 14:02 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ea20c9388d90 8004344: Fix a crash in ToolkitErrorHandler() in XlibWrapper.c Summary: Code does not check for JNU_GetEnv returning NULL. Reviewed-by: anthony ! src/solaris/native/sun/xawt/XlibWrapper.c Changeset: bbbb5c70aa59 Author: lana Date: 2012-12-04 11:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bbbb5c70aa59 Merge - src/share/classes/sun/awt/TextureSizeConstraining.java Changeset: f389bf27fc4f Author: dbuck Date: 2012-11-20 21:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f389bf27fc4f 7198904: (alt-rt) TreeMap.clone is broken Summary: Test case for cr7198904. Issue only found in OracleJDK, but test case is valid for OpenJDK as well Reviewed-by: mduigou, dholmes + test/java/util/TreeMap/Clone.java Changeset: ee6e5b7d5d55 Author: uta Date: 2012-11-23 13:07 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ee6e5b7d5d55 8003898: X11 toolkit can be chosen as the default toolkit Summary: XToolkit is not selected for any values of system-wide environment variables (ex. DISPLAY). Reviewed-by: anthony, art ! src/solaris/native/java/lang/java_props_macosx.c Changeset: 621c379d909d Author: xuelei Date: 2012-11-24 03:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/621c379d909d 8001751: Javadoc warnings in JSSE code Reviewed-by: alanb ! src/share/classes/javax/net/ssl/HostnameVerifier.java ! src/share/classes/javax/net/ssl/SNIHostName.java ! src/share/classes/javax/net/ssl/SNIMatcher.java ! src/share/classes/javax/net/ssl/SNIServerName.java ! src/share/classes/javax/net/ssl/SSLParameters.java ! src/share/classes/javax/net/ssl/SSLSocketFactory.java Changeset: f7d45462b225 Author: xuelei Date: 2012-11-24 04:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f7d45462b225 8003950: Adds missing Override annotations and removes unnecessary imports in sun.security.ssl Reviewed-by: xuelei Contributed-by: Florian Weimer ! src/share/classes/sun/security/ssl/AppInputStream.java ! src/share/classes/sun/security/ssl/AppOutputStream.java ! src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java ! src/share/classes/sun/security/ssl/ByteBufferInputStream.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/CipherSuiteList.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/DHClientKeyExchange.java ! src/share/classes/sun/security/ssl/ECDHClientKeyExchange.java ! src/share/classes/sun/security/ssl/ECDHCrypt.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/EngineWriter.java ! src/share/classes/sun/security/ssl/ExtensionType.java ! src/share/classes/sun/security/ssl/HandshakeHash.java ! src/share/classes/sun/security/ssl/HandshakeInStream.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/HandshakeOutStream.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/HelloExtension.java ! src/share/classes/sun/security/ssl/HelloExtensions.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java ! src/share/classes/sun/security/ssl/KeyManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/Krb5Helper.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/ProtocolList.java ! src/share/classes/sun/security/ssl/ProtocolVersion.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java ! src/share/classes/sun/security/ssl/RSASignature.java ! src/share/classes/sun/security/ssl/RenegotiationInfoExtension.java ! src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java ! src/share/classes/sun/security/ssl/SSLContextImpl.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/ServerNameExtension.java ! src/share/classes/sun/security/ssl/SessionId.java ! src/share/classes/sun/security/ssl/SunJSSE.java ! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/SupportedEllipticCurvesExtension.java ! src/share/classes/sun/security/ssl/SupportedEllipticPointFormatsExtension.java ! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/UnknownExtension.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/X509TrustManagerImpl.java Changeset: d30c13172254 Author: xuelei Date: 2012-11-24 04:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d30c13172254 8003951: Removes unused variables in sun.security.ssl Reviewed-by: xuelei Contributed-by: Florian Weimer ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/X509TrustManagerImpl.java Changeset: 8970128e040d Author: uta Date: 2012-11-26 15:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8970128e040d 7162111: TEST_BUG: change tests run in headless mode [macosx] (open) Summary: In problem tests detection of AWT headless mode was introduced or AWT dependence was removed. Reviewed-by: alanb ! test/ProblemList.txt ! test/demo/jvmti/mtrace/TraceJFrame.java ! test/java/io/Serializable/resolveClass/deserializeButton/Foo.java ! test/java/io/Serializable/resolveClass/deserializeButton/Test.java ! test/java/io/Serializable/resolveClass/deserializeButton/run.sh Changeset: 054470092795 Author: mullan Date: 2012-11-26 08:12 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/054470092795 7167056: Clarify that BasicPermission names that contain non-wildcard asterisks are not invalid Reviewed-by: weijun, xuelei ! src/share/classes/com/sun/net/ssl/SSLPermission.java ! src/share/classes/java/lang/RuntimePermission.java ! src/share/classes/java/net/NetPermission.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/sql/SQLPermission.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/javax/net/ssl/SSLPermission.java + test/java/security/BasicPermission/Wildcard.java Changeset: ea66140be78d Author: mullan Date: 2012-11-26 08:23 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ea66140be78d Merge - makefiles/docs/CORE_PKGS.gmk - makefiles/docs/Makefile - makefiles/docs/NON_CORE_PKGS.gmk - makefiles/docs/Notes.html - makefiles/mapfiles/launchers/mapfile-amd64 - makefiles/mapfiles/launchers/mapfile-i586 - makefiles/mapfiles/libawt_headless/reorder-i586 - makefiles/mapfiles/libjava/reorder-i586 - makefiles/mapfiles/libjpeg/reorder-i586 - makefiles/mapfiles/libnio/mapfile-bsd - makefiles/mapfiles/libnio/reorder-i586 - makefiles/mapfiles/libverify/reorder-i586 - makefiles/mapfiles/libzip/reorder-i586 - makefiles/sun/xawt/ToBin.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/sql/SQLPermission.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/javax/net/ssl/SSLPermission.java - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java Changeset: d7ed56d57d97 Author: mullan Date: 2012-11-26 08:34 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d7ed56d57d97 Merge Changeset: c2e80176a697 Author: mduigou Date: 2012-11-26 15:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c2e80176a697 8001634: Initial set of functional interface types Summary: Add the core functional interfaces used by the JSR335 libraries. Reviewed-by: dholmes, briangoetz, darcy ! make/docs/CORE_PKGS.gmk ! make/java/java/Makefile + src/share/classes/java/util/function/BinaryOperator.java + src/share/classes/java/util/function/Block.java + src/share/classes/java/util/function/DoubleBinaryOperator.java + src/share/classes/java/util/function/DoubleBlock.java + src/share/classes/java/util/function/DoubleFunction.java + src/share/classes/java/util/function/DoubleSupplier.java + src/share/classes/java/util/function/DoubleUnaryOperator.java + src/share/classes/java/util/function/Function.java + src/share/classes/java/util/function/IntBinaryOperator.java + src/share/classes/java/util/function/IntBlock.java + src/share/classes/java/util/function/IntFunction.java + src/share/classes/java/util/function/IntSupplier.java + src/share/classes/java/util/function/IntUnaryOperator.java + src/share/classes/java/util/function/LongBinaryOperator.java + src/share/classes/java/util/function/LongBlock.java + src/share/classes/java/util/function/LongFunction.java + src/share/classes/java/util/function/LongSupplier.java + src/share/classes/java/util/function/LongUnaryOperator.java + src/share/classes/java/util/function/Predicate.java + src/share/classes/java/util/function/Supplier.java + src/share/classes/java/util/function/UnaryOperator.java + src/share/classes/java/util/function/package-info.java Changeset: ddf97baea570 Author: chegar Date: 2012-11-27 17:15 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ddf97baea570 8003833: Spurious NPE from Socket.getIn/OutputStream Reviewed-by: alanb, dsamersoff ! src/share/classes/java/net/AbstractPlainSocketImpl.java + test/java/net/Socket/Streams.java Changeset: 40311b5f478f Author: robm Date: 2012-11-28 00:47 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/40311b5f478f 8003597: TEST_BUG: Eliminate dependency on javaweb from closed net tests Reviewed-by: chegar + test/java/net/ResponseCache/Test.java + test/java/net/Socket/B6210227.java Changeset: 39b25d5880c6 Author: sherman Date: 2012-11-27 21:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/39b25d5880c6 4235519: Make sun.misc.BASE64{De,En}coder classes public Summary: to add java.util.Base64 Reviewed-by: alanb, mduigou ! make/java/java/FILES_java.gmk Changeset: c6ed2c238d4f Author: sherman Date: 2012-11-27 22:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c6ed2c238d4f 8004088: hg push for bug#4235519 failed to push all files Summary: pushed all base64 files Reviewed-by: alanb, mduigou + src/share/classes/java/util/Base64.java + test/java/util/Base64/TestBase64.java + test/java/util/Base64/TestBase64Golden.java + test/java/util/Base64/baseEncode.txt + test/java/util/Base64/mimeEncode.txt + test/java/util/Base64/plain.txt + test/java/util/Base64/urlEncode.txt Changeset: 46c627801490 Author: xuelei Date: 2012-11-28 05:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/46c627801490 8004019: Removes unused method HandshakeHash.setCertificateVerifyAlg() Summary: certification verification in HandshakeHash was abandoned during TLS 1.2 implementation Reviewed-by: xuelei, weijun Contributed-by: Florian Weimer ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/HandshakeHash.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java Changeset: 735b93462eed Author: jfranck Date: 2012-11-28 09:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/735b93462eed 7154390: Add support for repeating annotations in j.l.r.AnnotatedElement Reviewed-by: darcy ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/annotation/ContainedBy.java ! src/share/classes/java/lang/annotation/ContainerFor.java + src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java ! src/share/classes/java/lang/reflect/AccessibleObject.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java + src/share/classes/sun/reflect/annotation/AnnotationSupport.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java + test/java/lang/annotation/repeatingAnnotations/RepeatedUnitTest.java + test/java/lang/annotation/repeatingAnnotations/subpackage/Containee.java + test/java/lang/annotation/repeatingAnnotations/subpackage/Container.java + test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainee.java + test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainer.java + test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedNonRepeated.java + test/java/lang/annotation/repeatingAnnotations/subpackage/NonRepeated.java + test/java/lang/annotation/repeatingAnnotations/subpackage/package-info.java Changeset: 3b6a2fe6d75c Author: dfuchs Date: 2012-11-28 15:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3b6a2fe6d75c 8003476: Cleanup warnings in com.sun.jmx.snmp code Reviewed-by: alanb, smarks ! src/share/classes/com/sun/jmx/snmp/EnumRowStatus.java ! src/share/classes/com/sun/jmx/snmp/Enumerated.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/AclImpl.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMAclBlock.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMInformBlock.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMTrapBlock.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JJTParserState.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/Parser.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/SnmpAcl.java ! src/share/classes/com/sun/jmx/snmp/InetAddressAcl.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpErrorHandlerAgent.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpGenericObjectServer.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpIndex.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibOid.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibRequest.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibRequestImpl.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibSubRequest.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpRequestTree.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpStandardObjectServer.java ! src/share/classes/com/sun/jmx/snmp/daemon/CommunicatorServer.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServer.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServerMBean.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpMibTree.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubBulkRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/defaults/SnmpProperties.java ! src/share/classes/com/sun/jmx/snmp/tasks/ThreadService.java ! src/share/classes/sun/management/snmp/AdaptorBootstrap.java Changeset: 262b3b2f3aa3 Author: dfuchs Date: 2012-11-28 10:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/262b3b2f3aa3 Merge Changeset: 09bef1e118e3 Author: mchung Date: 2012-11-28 10:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/09bef1e118e3 8003851: MethodHandleNatives dependency on java.sql.DriverManager Reviewed-by: alanb, dholmes ! src/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: 80ddee59a21d Author: mchung Date: 2012-11-28 10:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/80ddee59a21d 8003869: Eliminate java.lang.invoke.InnerClassLambdaMetafactory dependency on java.util.logging Reviewed-by: alanb, dholmes ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java Changeset: 13ec794734f5 Author: michaelm Date: 2012-11-29 09:41 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/13ec794734f5 7200720: crash in net.dll during NTLM authentication Reviewed-by: chegar, dsamersoff ! make/java/net/Makefile ! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.java ! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java ! src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.c Changeset: ba5eabd6a37b Author: michaelm Date: 2012-11-29 09:47 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ba5eabd6a37b Merge Changeset: 2b829a5a46ee Author: jgish Date: 2012-11-29 12:28 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2b829a5a46ee 8003380: Compiler warnings in logging test code Summary: Use generics, suppress warnings where appropriate, remove unused imports, etc. Reviewed-by: lancea, chegar ! test/java/util/logging/ClassLoaderLeakTest.java ! test/java/util/logging/Listeners.java ! test/java/util/logging/ListenersWithSM.java ! test/java/util/logging/LoggerResourceBundleRace.java ! test/java/util/logging/LoggingDeadlock2.java ! test/java/util/logging/LoggingDeadlock3.java ! test/java/util/logging/LoggingDeadlock4.java ! test/java/util/logging/LoggingMXBeanTest.java ! test/java/util/logging/LoggingMXBeanTest2.java ! test/java/util/logging/MemoryHandlerTest.java ! test/java/util/logging/ParentLoggersTest.java ! test/java/util/logging/SimpleFormatterFormat.java Changeset: d91e6cb1da41 Author: shade Date: 2012-11-29 17:03 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d91e6cb1da41 8004141: UnsafeStaticFieldAccessorImpl#base should be final Reviewed-by: chegar, alanb Contributed-by: peter.levart at gmail.com ! src/share/classes/sun/reflect/UnsafeStaticFieldAccessorImpl.java Changeset: bf6ceb6b8f80 Author: mduigou Date: 2012-11-29 14:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bf6ceb6b8f80 7175464: entrySetView field is never updated in NavigableSubMap Summary: The method entrySet() in AscendingSubMap and DescendingSubMap failed to cache the entrySetView. Reviewed-by: alanb, psandoz ! src/share/classes/java/util/TreeMap.java Changeset: 75cb07a7b622 Author: mduigou Date: 2012-11-29 14:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/75cb07a7b622 6553074: String{Buffer,Builder}.indexOf(Str, int) contains unnecessary allocation Summary: It is not necessary to extract the value array with toCharArray. The value array can now be used directly. Reviewed-by: alanb ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/String.java Changeset: 83d9f30ebeed Author: smarks Date: 2012-11-28 17:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/83d9f30ebeed 8004131: move jdi tests out of core testset Reviewed-by: alanb, chegar ! make/jprt.properties Changeset: 7ccf93c60c4d Author: smarks Date: 2012-11-29 14:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7ccf93c60c4d 8004134: More ProblemList.txt updates (11/2012) Reviewed-by: alanb Contributed-by: amy.lu at oracle.com ! test/ProblemList.txt Changeset: 55f8ddc2f9c6 Author: sla Date: 2012-11-30 08:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/55f8ddc2f9c6 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo Reviewed-by: okutsu ! test/java/util/TimeZone/Bug6912560.java Changeset: e988de7465d4 Author: zhangshj Date: 2012-11-30 17:24 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e988de7465d4 8004211: Remove unused dlinfo local variable in launcher code Reviewed-by: alanb ! src/solaris/bin/java_md_solinux.c Changeset: 72d3d07b625d Author: alanb Date: 2012-11-30 11:18 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/72d3d07b625d 8003949: LogManager, downgrade normative reference to ${java.home}/lib/logging.properties Reviewed-by: psandoz, mchung ! src/share/classes/java/util/logging/LogManager.java Changeset: c370048be8fc Author: alanb Date: 2012-11-30 16:29 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c370048be8fc 7165762: (aio) Default thread pool should be configured so that threads terminated after a timeout period Reviewed-by: chegar ! src/share/classes/sun/nio/ch/ThreadPool.java Changeset: e7edb0da9c6a Author: jfranck Date: 2012-11-30 09:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e7edb0da9c6a 8004110: Remove debug code form sun/reflect/annotation/AnnotationSupport.java Reviewed-by: jjg, darcy ! src/share/classes/sun/reflect/annotation/AnnotationSupport.java Changeset: 43d2e02c4098 Author: khazra Date: 2012-11-30 12:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/43d2e02c4098 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by "couldn't get file lock" Summary: Set -Djava.util.prefs.userRoot to current working directory of user in the prefs tests Reviewed-by: alanb, chegar, weijun, dxu ! test/java/util/prefs/AddNodeChangeListener.java ! test/java/util/prefs/CheckUserPrefsStorage.sh ! test/java/util/prefs/CommentsInXml.java ! test/java/util/prefs/ConflictInFlush.java ! test/java/util/prefs/ExportNode.java ! test/java/util/prefs/ExportSubtree.java ! test/java/util/prefs/PrefsSpi.sh ! test/java/util/prefs/RemoveNullKeyCheck.java ! test/java/util/prefs/RemoveReadOnlyNode.java ! test/java/util/prefs/RemoveUnregedListener.java Changeset: e66ec5b8c15e Author: lana Date: 2012-11-30 16:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e66ec5b8c15e Merge Changeset: fd8ba2d8baec Author: sherman Date: 2012-12-01 11:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/fd8ba2d8baec 8004212: java.util.Base64 methods decodeArray and decodeBuffer should return the number of bytes written Summary: to return the length instead of position Reviewed-by: alanb ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java Changeset: f657adf4fe78 Author: alanb Date: 2012-12-02 16:37 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f657adf4fe78 8003846: Override mechanism for currency data should not require creating currency.properties in java.home Reviewed-by: naoto ! src/share/classes/java/util/Currency.java ! test/java/util/Currency/PropertiesTest.java ! test/java/util/Currency/PropertiesTest.sh Changeset: 60550cd2b527 Author: dholmes Date: 2012-12-02 19:16 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/60550cd2b527 7200297: agent code does not handle multiple boot library path elements correctly Summary: When bug 6819213 was fixed it enabled sun.boot.library.path property to contain multiple paths. Code in agents does not handle multiple paths when attempting to find dependent shared libs. Reviewed-by: dholmes, sspitsyn, dsamersoff Contributed-by: Bill Pittore ! src/share/back/debugInit.c ! src/share/back/error_messages.c ! src/share/back/transport.c ! src/share/demo/jvmti/hprof/hprof.h ! src/share/demo/jvmti/hprof/hprof_init.c ! src/solaris/back/linker_md.c ! src/solaris/demo/jvmti/hprof/hprof_md.c ! src/solaris/npt/npt_md.h ! src/windows/back/linker_md.c ! src/windows/demo/jvmti/hprof/hprof_md.c ! src/windows/npt/npt_md.h Changeset: a42da685dfca Author: weijun Date: 2012-12-03 17:14 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a42da685dfca 7198507: [TEST_BUG] sun/security/tools/keytool/console.sh should be rewritten Reviewed-by: xuelei ! test/sun/security/tools/keytool/console.sh Changeset: ead651efb271 Author: xuelei Date: 2012-12-03 06:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ead651efb271 8004184: security tests leave JSSEServer running Summary: Use othervm mode to release resources, and correct the system properties issues in JSSE Reviewed-by: chegar ! test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java Changeset: ee9846f351d7 Author: mullan Date: 2012-12-03 11:07 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ee9846f351d7 7199143: RFE: OCSP revocation checker should provide possibility to specify connection timeout Summary: Added com.sun.security.ocsp.timeout system property to control timeout Reviewed-by: mullan, vinnie Contributed-by: jason.uh at oracle.com ! src/share/classes/sun/security/provider/certpath/OCSP.java Changeset: 38ec2838dd86 Author: dxu Date: 2012-12-04 14:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/38ec2838dd86 7142921: (fs) Files.probeContentType reports a MIME type of "text/plain" on Ubuntu 11.04 7144997: (fs) Files.probeContentType returns null on Solaris 64-bit Reviewed-by: alanb, mduigou ! make/java/nio/Makefile ! make/java/nio/mapfile-linux ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/mapfiles/libnio/mapfile-linux ! src/solaris/classes/sun/nio/fs/BsdFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/MacOSXFileSystemProvider.java + src/solaris/classes/sun/nio/fs/MagicFileTypeDetector.java + src/solaris/classes/sun/nio/fs/MimeTypesFileTypeDetector.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java + src/solaris/native/sun/nio/fs/MagicFileTypeDetector.c Changeset: 2e8863c4f7d0 Author: kmo Date: 2012-12-04 15:10 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2e8863c4f7d0 8004066: TEST_BUG: test/java/lang/Math/DivModTests.java assumes ArithmeticException message Reviewed-by: twisti, alanb, dholmes ! test/java/lang/Math/DivModTests.java Changeset: 87028eb3f020 Author: lana Date: 2012-12-04 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/87028eb3f020 Merge Changeset: b68a5404de60 Author: lana Date: 2012-12-10 20:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b68a5404de60 Merge ! makefiles/CompileJavaClasses.gmk - src/share/classes/sun/awt/TextureSizeConstraining.java Changeset: 379e3dfa521d Author: erikj Date: 2012-12-06 12:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/379e3dfa521d 8004104: build-infra: Minor cleanup Reviewed-by: ohrstrom, tbell ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk Changeset: 2689f6cfe835 Author: erikj Date: 2012-12-11 12:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2689f6cfe835 8001753: build-infra: mismatch with full debug symbol control for hotspot Summary: Changing boolean values of ENABLE_DEBUG_SYMBOLS. Reviewed-by: dholmes, ohair ! makefiles/CompileNativeLibraries.gmk Changeset: 53fb43e4d614 Author: katleman Date: 2012-12-12 13:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/53fb43e4d614 Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk Changeset: 7fd56a5abd94 Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7fd56a5abd94 Added tag jdk8-b68 for changeset 53fb43e4d614 ! .hgtags From john.coomes at oracle.com Fri Dec 14 03:30:00 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 Dec 2012 11:30:00 +0000 Subject: hg: hsx/hotspot-rt/langtools: 13 new changesets Message-ID: <20121214113036.86EB547169@hg.openjdk.java.net> Changeset: d9fe1f80515d Author: vromero Date: 2012-11-21 18:40 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/d9fe1f80515d 7190862: javap shows an incorrect type for operands if the 'wide' prefix is used 7109747: (javap) classfile not treating iinc_w correctly. Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/classfile/Instruction.java ! src/share/classes/com/sun/tools/classfile/Opcode.java + test/tools/javap/T7190862.java Changeset: 3746b071d75b Author: vromero Date: 2012-11-21 19:09 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/3746b071d75b 6574624: javax.tools.JavaCompiler spec contains errors in sample code Reviewed-by: jjg, mcimadamore ! src/share/classes/javax/tools/JavaCompiler.java Changeset: 4d68e2a05b50 Author: jjg Date: 2012-11-27 13:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/4d68e2a05b50 8004068: Fix build problems caused by on-demand imports Reviewed-by: jjg Contributed-by: eric.caspole at amd.com ! src/share/classes/com/sun/tools/javac/code/Types.java Changeset: 1f41a5758cf7 Author: vromero Date: 2012-11-23 15:13 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/1f41a5758cf7 7144981: javac should ignore ignorable characters in input Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java + test/tools/javac/7144981/IgnoreIgnorableCharactersInInput.java Changeset: 969c96b980b7 Author: vromero Date: 2012-11-29 09:41 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/969c96b980b7 7153958: add constant pool reference to class containing inlined constants Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/7153958/CPoolRefClassContainingInlinedCts.java + test/tools/javac/7153958/pkg/ClassToBeStaticallyImported.java Changeset: 4f9853659bf1 Author: mcimadamore Date: 2012-11-30 15:14 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/4f9853659bf1 8004105: Expression statement lambdas should be void-compatible Summary: Fix lambda compatibility rules as per latest EDR Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! test/tools/javac/lambda/LambdaConv21.java ! test/tools/javac/lambda/LambdaConv21.out ! test/tools/javac/lambda/VoidCompatibility.out Changeset: 34d1ebaf4645 Author: mcimadamore Date: 2012-11-30 15:14 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/34d1ebaf4645 8004102: Add support for generic functional descriptors Summary: Method references are allowed to have a generic functional interface descriptor target Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties - test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java + test/tools/javac/diags/examples/InvalidGenericLambdaTarget.java + test/tools/javac/lambda/FunctionalInterfaceConversionTest.java - test/tools/javac/lambda/LambdaConversionTest.java + test/tools/javac/lambda/MethodReference57.java + test/tools/javac/lambda/MethodReference58.java + test/tools/javac/lambda/MethodReference58.out Changeset: 9b26c96f5138 Author: mcimadamore Date: 2012-11-30 15:14 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/9b26c96f5138 8004101: Add checks for method reference well-formedness Summary: Bring method reference type-checking in sync with latest EDR Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/diags/examples/StaticBoundMref.java + test/tools/javac/diags/examples/StaticMrefWithTargs.java ! test/tools/javac/lambda/MethodReference30.java + test/tools/javac/lambda/MethodReference55.java + test/tools/javac/lambda/MethodReference55.out + test/tools/javac/lambda/MethodReference56.java + test/tools/javac/lambda/MethodReference56.out ! test/tools/javac/lambda/methodReference/MethodRef1.java ! test/tools/javac/lambda/methodReference/SamConversion.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestKinds.java Changeset: f6f1fd261f57 Author: mcimadamore Date: 2012-11-30 15:14 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/f6f1fd261f57 8002099: Add support for intersection types in cast expression Summary: Add parser and type-checking support for intersection types in cast expressions Reviewed-by: jjg + src/share/classes/com/sun/source/tree/IntersectionTypeTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java + src/share/classes/javax/lang/model/type/IntersectionType.java ! src/share/classes/javax/lang/model/type/TypeKind.java ! src/share/classes/javax/lang/model/type/TypeVisitor.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java + test/tools/javac/cast/intersection/IntersectionTypeCastTest.java + test/tools/javac/cast/intersection/IntersectionTypeParserTest.java + test/tools/javac/cast/intersection/model/Check.java + test/tools/javac/cast/intersection/model/IntersectionTypeInfo.java + test/tools/javac/cast/intersection/model/Member.java + test/tools/javac/cast/intersection/model/Model01.java + test/tools/javac/cast/intersection/model/ModelChecker.java + test/tools/javac/diags/examples/IntersectionTypesInCastNotSupported.java + test/tools/javac/diags/examples/SecondaryBoundMustBeMarkerIntf.java + test/tools/javac/lambda/Intersection01.java + test/tools/javac/lambda/Intersection01.out ! test/tools/javac/lambda/LambdaParserTest.java + test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java Changeset: 98e14fc9ee11 Author: lana Date: 2012-11-30 16:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/98e14fc9ee11 Merge Changeset: 0e70eb71fec0 Author: mcimadamore Date: 2012-12-04 17:19 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/0e70eb71fec0 8004360: regression test DefaultMethodRegressionTests fails in langtools Summary: ignore broken failing test Reviewed-by: jjg - test/tools/javac/defaultMethodExecution/DefaultMethodRegressionTests.java + test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java Changeset: 014a6a11dfe5 Author: lana Date: 2012-12-10 20:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/014a6a11dfe5 Merge - test/tools/javac/defaultMethodExecution/DefaultMethodRegressionTests.java - test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java - test/tools/javac/lambda/LambdaConversionTest.java Changeset: 13ccb5269f3d Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/13ccb5269f3d Added tag jdk8-b68 for changeset 014a6a11dfe5 ! .hgtags From coleen.phillimore at oracle.com Fri Dec 14 05:21:04 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 14 Dec 2012 08:21:04 -0500 Subject: Request for review (s): 7173959 : Jvm crashed during coherence exabus (tmb) testing In-Reply-To: <50CAE7F6.2020609@oracle.com> References: <50C978BE.8040405@oracle.com> <50C984DA.1070400@oracle.com> <50C9A7AD.3030307@oracle.com> <50C9AFE9.2080601@oracle.com> <50C9B2EC.5090008@oracle.com> <50C9D0F1.9040501@oracle.com> <50CA750A.6040007@oracle.com> <50CAE384.6070003@oracle.com> <50CAE7F6.2020609@oracle.com> Message-ID: <50CB27C0.6050708@oracle.com> On 12/14/2012 3:48 AM, Bengt Rutisson wrote: > > Hi again Runtime team, > > I need one more review for this change. It is a P1 bug with a fairly > small change. Any takers? > > Latest webrev based on comments from David Holmes and Vitaly Davidovich: > http://cr.openjdk.java.net/~brutisso/7173959/webrev.03/ Hi Bengt, This code looks good to me but I asked Zhengyu to check it to make sure it doesn't have any bad NMT interactions. Also the writeup is great below, but can you add these comments to the code in os_posix.cpp. I had to go back to the email to figure out why you are doing this. I don't understand why there are racing threads. I thought all the heap space was initialized at the start of the vm when it is single threaded? thanks, Coleen > > Thanks, > Bengt > > > On 12/14/12 9:29 AM, Bengt Rutisson wrote: >> >> Hi David, >> >> On 12/14/12 1:38 AM, David Holmes wrote: >>> Hi Bengt, >>> >>> That all sounds good to me. >>> >>> With regard to potential overflow perhaps a simple check that >>> extra_size does not overflow? If that is true and extra_base is not >>> null then I think all the other calculations must be valid. >> >> Yes, that makes sense. I'll add an overflow check for the extra_size. >> >> Thanks, >> Bengt >> >>> >>> Thanks, >>> David >>> >>> On 13/12/2012 10:58 PM, Bengt Rutisson wrote: >>>> >>>> Hi David, >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.02/ >>>> >>>> I moved the alignment of "size" back into ReservedSpace::initialize() >>>> since we actually store the size in an instance variable (_size), so I >>>> think it is a bit risky to just do the align_up in >>>> os::reserve_memory_aligned(). We probably want the instance variables >>>> _size and _alignment in ReservedSpace to be consistent. >>>> >>>> I added an assert in os::reserve_memory_aligned() to verify that the >>>> size is correctly aligned. I also added the assert you suggested to >>>> check that alignment is page size aligned. >>>> >>>> Bengt >>>> >>>> On 12/13/12 11:50 AM, David Holmes wrote: >>>>> On 13/12/2012 8:37 PM, Bengt Rutisson wrote: >>>>>> >>>>>> Hi again, >>>>>> >>>>>> Updated webrev: >>>>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.01/ >>>>>> >>>>>> I removed the comment and the alignment. >>>>>> >>>>>> But I did not add an assert just yet. >>>>>> >>>>>> At the top of ReservedSpace::initialize() we have this code: >>>>>> >>>>>> const size_t granularity = os::vm_allocation_granularity(); >>>>>> assert((size & (granularity - 1)) == 0, >>>>>> "size not aligned to os::vm_allocation_granularity()"); >>>>>> assert((alignment & (granularity - 1)) == 0, >>>>>> "alignment not aligned to os::vm_allocation_granularity()"); >>>>>> >>>>>> >>>>>> Where os::vm_allocation_granularity() is implemented as page size >>>>>> on all >>>>>> platforms except Windows. There we look it up from the Windows >>>>>> API. I >>>>>> assume that is a page size too, but since the Windows code in our >>>>>> patch >>>>>> does not unmap based on the alignment it should be safe either way. >>>>>> >>>>>> Is this assert enough or would you like me to add an assert >>>>>> closer to >>>>>> the code block were I did the changes? >>>>> >>>>> As this is a separate method now I think an assert in the method >>>>> itself would not go astray. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> Thanks, >>>>>> Bengt >>>>>> >>>>>> >>>>>> On 12/13/12 11:02 AM, Bengt Rutisson wrote: >>>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>> Thanks for looking at this! >>>>>>> >>>>>>> On 12/13/12 8:33 AM, David Holmes wrote: >>>>>>>> Hi Bengt, >>>>>>>> >>>>>>>> This has to be one of the absolute best review requests I've ever >>>>>>>> read :) Thank you. >>>>>>> >>>>>>> Wow! Thanks! :) >>>>>>> >>>>>>>> >>>>>>>> Just a couple of queries. >>>>>>>> >>>>>>>> os_posix.cpp: >>>>>>>> >>>>>>>> Love the diagram :) >>>>>>> >>>>>>> It was Mikael's way of making sure we got it right. >>>>>>> >>>>>>>> I'm assuming that "alignment" has to be >= the underlying page >>>>>>>> size, >>>>>>>> and in fact must be a multiple of the underlying page size ? (As I >>>>>>>> assume you can only unmap whole numbers of pages). If so does that >>>>>>>> need to be checked somewhere? >>>>>>> >>>>>>> Good point. I'll add an assert to check that. >>>>>>> >>>>>>>> In virtualSpace.cpp: >>>>>>>> >>>>>>>> // Reserve size large enough to do manual alignment and >>>>>>>> // increase size to a multiple of the desired alignment >>>>>>>> size = align_size_up(size, alignment); >>>>>>>> ! base = os::reserve_memory_aligned(size, alignment); >>>>>>>> >>>>>>>> The comment doesn't seem necessary now, and the align_size_up >>>>>>>> seems >>>>>>>> redundant. >>>>>>> >>>>>>> You are right. I'll remove the comment and the alignment. >>>>>>> >>>>>>> Thanks, >>>>>>> Bengt >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 13/12/2012 4:42 PM, Bengt Rutisson wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Could I have a couple of reviews for this change? >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.00/ >>>>>>>>> >>>>>>>>> This is for a bug originally reported by the Coherence team: >>>>>>>>> >>>>>>>>> 7173959 : Jvm crashed during coherence exabus (tmb) testing >>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173959 >>>>>>>>> >>>>>>>>> The original analysis and proposed fix was done by Mikael Gerdin >>>>>>>>> and me >>>>>>>>> together. I'll handle the webrev and push since Mikael is on >>>>>>>>> vacation >>>>>>>>> starting today. But Mikael did a great job tracking down this >>>>>>>>> very >>>>>>>>> difficult bug, so he should have a large part of the credit >>>>>>>>> for this >>>>>>>>> bug >>>>>>>>> fix, >>>>>>>>> >>>>>>>>> Description from the CR: >>>>>>>>> >>>>>>>>> The reason that we crash is due to how we re-map memory when we >>>>>>>>> want to >>>>>>>>> align it for large pages in ReservedSpace::initialize(). >>>>>>>>> >>>>>>>>> Here is what happens: >>>>>>>>> >>>>>>>>> The reservation of memory is split up to a few steps. When we >>>>>>>>> want a >>>>>>>>> chunk of memory with large pages we first just reserve some >>>>>>>>> memory >>>>>>>>> large >>>>>>>>> enough for what we need. Then we realize that we want large >>>>>>>>> pages, >>>>>>>>> so we >>>>>>>>> want to re-map the reserved memory to use large pages. But >>>>>>>>> since this >>>>>>>>> requires that we have a large-page-aligned memory chunk we may >>>>>>>>> have to >>>>>>>>> fix the recently reserved memory chunk up a bit. >>>>>>>>> >>>>>>>>> We do this in ReservedSpace::initialize() by first releasing the >>>>>>>>> memory >>>>>>>>> we just reserved. Then requesting more memory than we actually >>>>>>>>> need to >>>>>>>>> make sure that we have enough space to do manual large page >>>>>>>>> alignment. >>>>>>>>> After we have gotten this memory we figure out a nicely >>>>>>>>> aligned start >>>>>>>>> address. We then release the memory again and then reserve just >>>>>>>>> enough >>>>>>>>> memory but using the aligned start address as a fixed address >>>>>>>>> to make >>>>>>>>> sure that we get the memory we wanted in an aligned way. >>>>>>>>> >>>>>>>>> This is done in a loop to make sure that we eventually get some >>>>>>>>> memory. >>>>>>>>> The interesting code looks like this: >>>>>>>>> >>>>>>>>> do { >>>>>>>>> char* extra_base = os::reserve_memory(extra_size, NULL, >>>>>>>>> alignment); >>>>>>>>> if (extra_base == NULL) return; >>>>>>>>> // Do manual alignement >>>>>>>>> base = (char*) align_size_up((uintptr_t) extra_base, alignment); >>>>>>>>> assert(base >= extra_base, "just checking"); >>>>>>>>> // Re-reserve the region at the aligned base address. >>>>>>>>> os::release_memory(extra_base, extra_size); // (1) >>>>>>>>> base = os::reserve_memory(size, base); // (2) >>>>>>>>> } while (base == NULL); >>>>>>>>> >>>>>>>>> >>>>>>>>> There is a race here between releasing the memory in (1) and >>>>>>>>> re-reserving it in (2). But the loop is supposed to handle >>>>>>>>> this race. >>>>>>>>> >>>>>>>>> The problem is that on posix platforms you can remap the same >>>>>>>>> memory >>>>>>>>> area several times. The call in (2) will use mmap with MAP_FIXED. >>>>>>>>> This >>>>>>>>> means that the OS will think that you know exactly what you are >>>>>>>>> doing. >>>>>>>>> So, if part of the memory has been mapped already by the >>>>>>>>> process it >>>>>>>>> will >>>>>>>>> just go ahead and reuse that memory. >>>>>>>>> >>>>>>>>> This means that if we are having multiple threads that do >>>>>>>>> mmap. We >>>>>>>>> can >>>>>>>>> end up with a situation where we release our mapping in (1). Then >>>>>>>>> another thread comes in and maps part of the memory that we >>>>>>>>> used to >>>>>>>>> have. Then we remap over that memory again in (2) with MAP_FIXED. >>>>>>>>> Now we >>>>>>>>> have a situation where two threads in our process have mapped the >>>>>>>>> same >>>>>>>>> memory. If both threads try to use it or if one of the threads >>>>>>>>> unmap >>>>>>>>> part or all of the memory we will crash. >>>>>>>>> >>>>>>>>> On posix it is possible to unmap any part of a mapped chunk. >>>>>>>>> So, our >>>>>>>>> proposed solution to the race described above is to not unmap all >>>>>>>>> memory >>>>>>>>> in (1) but rather just unmap the section at the start and at the >>>>>>>>> end of >>>>>>>>> the chunk that we mapped to get alignment. This also removes >>>>>>>>> the need >>>>>>>>> for the loop. >>>>>>>>> >>>>>>>>> However, on Windows you can only unmap _all_ of the memory >>>>>>>>> that you >>>>>>>>> have >>>>>>>>> mapped. On the other hand Windows also will not allow you to >>>>>>>>> map over >>>>>>>>> other mappings, so the original code is actually safe. If we keep >>>>>>>>> the loop. >>>>>>>>> >>>>>>>>> So, our solution is to treat this differently on Windows and >>>>>>>>> posix >>>>>>>>> platforms. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Bengt >>>>>>> >>>>>> >>>> >> > From vitalyd at gmail.com Fri Dec 14 06:46:47 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 14 Dec 2012 09:46:47 -0500 Subject: Request for review (s): 7173959 : Jvm crashed during coherence exabus (tmb) testing In-Reply-To: <50CAE7F6.2020609@oracle.com> References: <50C978BE.8040405@oracle.com> <50C984DA.1070400@oracle.com> <50C9A7AD.3030307@oracle.com> <50C9AFE9.2080601@oracle.com> <50C9B2EC.5090008@oracle.com> <50C9D0F1.9040501@oracle.com> <50CA750A.6040007@oracle.com> <50CAE384.6070003@oracle.com> <50CAE7F6.2020609@oracle.com> Message-ID: Hi Bengt, I'd add an assert(begin_offset < end_offset, "sanity") as well but up to you. Looks good. Thanks Sent from my phone On Dec 14, 2012 3:49 AM, "Bengt Rutisson" wrote: > > Hi again Runtime team, > > I need one more review for this change. It is a P1 bug with a fairly small > change. Any takers? > > Latest webrev based on comments from David Holmes and Vitaly Davidovich: > http://cr.openjdk.java.net/~**brutisso/7173959/webrev.03/ > > Thanks, > Bengt > > > On 12/14/12 9:29 AM, Bengt Rutisson wrote: > >> >> Hi David, >> >> On 12/14/12 1:38 AM, David Holmes wrote: >> >>> Hi Bengt, >>> >>> That all sounds good to me. >>> >>> With regard to potential overflow perhaps a simple check that extra_size >>> does not overflow? If that is true and extra_base is not null then I think >>> all the other calculations must be valid. >>> >> >> Yes, that makes sense. I'll add an overflow check for the extra_size. >> >> Thanks, >> Bengt >> >> >>> Thanks, >>> David >>> >>> On 13/12/2012 10:58 PM, Bengt Rutisson wrote: >>> >>>> >>>> Hi David, >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~**brutisso/7173959/webrev.02/ >>>> >>>> I moved the alignment of "size" back into ReservedSpace::initialize() >>>> since we actually store the size in an instance variable (_size), so I >>>> think it is a bit risky to just do the align_up in >>>> os::reserve_memory_aligned(). We probably want the instance variables >>>> _size and _alignment in ReservedSpace to be consistent. >>>> >>>> I added an assert in os::reserve_memory_aligned() to verify that the >>>> size is correctly aligned. I also added the assert you suggested to >>>> check that alignment is page size aligned. >>>> >>>> Bengt >>>> >>>> On 12/13/12 11:50 AM, David Holmes wrote: >>>> >>>>> On 13/12/2012 8:37 PM, Bengt Rutisson wrote: >>>>> >>>>>> >>>>>> Hi again, >>>>>> >>>>>> Updated webrev: >>>>>> http://cr.openjdk.java.net/~**brutisso/7173959/webrev.01/ >>>>>> >>>>>> I removed the comment and the alignment. >>>>>> >>>>>> But I did not add an assert just yet. >>>>>> >>>>>> At the top of ReservedSpace::initialize() we have this code: >>>>>> >>>>>> const size_t granularity = os::vm_allocation_granularity(**); >>>>>> assert((size & (granularity - 1)) == 0, >>>>>> "size not aligned to os::vm_allocation_granularity(**)"); >>>>>> assert((alignment & (granularity - 1)) == 0, >>>>>> "alignment not aligned to os::vm_allocation_granularity(**)"); >>>>>> >>>>>> >>>>>> Where os::vm_allocation_granularity(**) is implemented as page size >>>>>> on all >>>>>> platforms except Windows. There we look it up from the Windows API. I >>>>>> assume that is a page size too, but since the Windows code in our >>>>>> patch >>>>>> does not unmap based on the alignment it should be safe either way. >>>>>> >>>>>> Is this assert enough or would you like me to add an assert closer to >>>>>> the code block were I did the changes? >>>>>> >>>>> >>>>> As this is a separate method now I think an assert in the method >>>>> itself would not go astray. >>>>> >>>>> David >>>>> ----- >>>>> >>>>> Thanks, >>>>>> Bengt >>>>>> >>>>>> >>>>>> On 12/13/12 11:02 AM, Bengt Rutisson wrote: >>>>>> >>>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>> Thanks for looking at this! >>>>>>> >>>>>>> On 12/13/12 8:33 AM, David Holmes wrote: >>>>>>> >>>>>>>> Hi Bengt, >>>>>>>> >>>>>>>> This has to be one of the absolute best review requests I've ever >>>>>>>> read :) Thank you. >>>>>>>> >>>>>>> >>>>>>> Wow! Thanks! :) >>>>>>> >>>>>>> >>>>>>>> Just a couple of queries. >>>>>>>> >>>>>>>> os_posix.cpp: >>>>>>>> >>>>>>>> Love the diagram :) >>>>>>>> >>>>>>> >>>>>>> It was Mikael's way of making sure we got it right. >>>>>>> >>>>>>> I'm assuming that "alignment" has to be >= the underlying page size, >>>>>>>> and in fact must be a multiple of the underlying page size ? (As I >>>>>>>> assume you can only unmap whole numbers of pages). If so does that >>>>>>>> need to be checked somewhere? >>>>>>>> >>>>>>> >>>>>>> Good point. I'll add an assert to check that. >>>>>>> >>>>>>> In virtualSpace.cpp: >>>>>>>> >>>>>>>> // Reserve size large enough to do manual alignment and >>>>>>>> // increase size to a multiple of the desired alignment >>>>>>>> size = align_size_up(size, alignment); >>>>>>>> ! base = os::reserve_memory_aligned(**size, alignment); >>>>>>>> >>>>>>>> The comment doesn't seem necessary now, and the align_size_up seems >>>>>>>> redundant. >>>>>>>> >>>>>>> >>>>>>> You are right. I'll remove the comment and the alignment. >>>>>>> >>>>>>> Thanks, >>>>>>> Bengt >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 13/12/2012 4:42 PM, Bengt Rutisson wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Could I have a couple of reviews for this change? >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~**brutisso/7173959/webrev.00/ >>>>>>>>> >>>>>>>>> This is for a bug originally reported by the Coherence team: >>>>>>>>> >>>>>>>>> 7173959 : Jvm crashed during coherence exabus (tmb) testing >>>>>>>>> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=7173959 >>>>>>>>> >>>>>>>>> The original analysis and proposed fix was done by Mikael Gerdin >>>>>>>>> and me >>>>>>>>> together. I'll handle the webrev and push since Mikael is on >>>>>>>>> vacation >>>>>>>>> starting today. But Mikael did a great job tracking down this very >>>>>>>>> difficult bug, so he should have a large part of the credit for >>>>>>>>> this >>>>>>>>> bug >>>>>>>>> fix, >>>>>>>>> >>>>>>>>> Description from the CR: >>>>>>>>> >>>>>>>>> The reason that we crash is due to how we re-map memory when we >>>>>>>>> want to >>>>>>>>> align it for large pages in ReservedSpace::initialize(). >>>>>>>>> >>>>>>>>> Here is what happens: >>>>>>>>> >>>>>>>>> The reservation of memory is split up to a few steps. When we want >>>>>>>>> a >>>>>>>>> chunk of memory with large pages we first just reserve some memory >>>>>>>>> large >>>>>>>>> enough for what we need. Then we realize that we want large pages, >>>>>>>>> so we >>>>>>>>> want to re-map the reserved memory to use large pages. But since >>>>>>>>> this >>>>>>>>> requires that we have a large-page-aligned memory chunk we may >>>>>>>>> have to >>>>>>>>> fix the recently reserved memory chunk up a bit. >>>>>>>>> >>>>>>>>> We do this in ReservedSpace::initialize() by first releasing the >>>>>>>>> memory >>>>>>>>> we just reserved. Then requesting more memory than we actually >>>>>>>>> need to >>>>>>>>> make sure that we have enough space to do manual large page >>>>>>>>> alignment. >>>>>>>>> After we have gotten this memory we figure out a nicely aligned >>>>>>>>> start >>>>>>>>> address. We then release the memory again and then reserve just >>>>>>>>> enough >>>>>>>>> memory but using the aligned start address as a fixed address to >>>>>>>>> make >>>>>>>>> sure that we get the memory we wanted in an aligned way. >>>>>>>>> >>>>>>>>> This is done in a loop to make sure that we eventually get some >>>>>>>>> memory. >>>>>>>>> The interesting code looks like this: >>>>>>>>> >>>>>>>>> do { >>>>>>>>> char* extra_base = os::reserve_memory(extra_size, NULL, alignment); >>>>>>>>> if (extra_base == NULL) return; >>>>>>>>> // Do manual alignement >>>>>>>>> base = (char*) align_size_up((uintptr_t) extra_base, alignment); >>>>>>>>> assert(base >= extra_base, "just checking"); >>>>>>>>> // Re-reserve the region at the aligned base address. >>>>>>>>> os::release_memory(extra_base, extra_size); // (1) >>>>>>>>> base = os::reserve_memory(size, base); // (2) >>>>>>>>> } while (base == NULL); >>>>>>>>> >>>>>>>>> >>>>>>>>> There is a race here between releasing the memory in (1) and >>>>>>>>> re-reserving it in (2). But the loop is supposed to handle this >>>>>>>>> race. >>>>>>>>> >>>>>>>>> The problem is that on posix platforms you can remap the same >>>>>>>>> memory >>>>>>>>> area several times. The call in (2) will use mmap with MAP_FIXED. >>>>>>>>> This >>>>>>>>> means that the OS will think that you know exactly what you are >>>>>>>>> doing. >>>>>>>>> So, if part of the memory has been mapped already by the process it >>>>>>>>> will >>>>>>>>> just go ahead and reuse that memory. >>>>>>>>> >>>>>>>>> This means that if we are having multiple threads that do mmap. We >>>>>>>>> can >>>>>>>>> end up with a situation where we release our mapping in (1). Then >>>>>>>>> another thread comes in and maps part of the memory that we used to >>>>>>>>> have. Then we remap over that memory again in (2) with MAP_FIXED. >>>>>>>>> Now we >>>>>>>>> have a situation where two threads in our process have mapped the >>>>>>>>> same >>>>>>>>> memory. If both threads try to use it or if one of the threads >>>>>>>>> unmap >>>>>>>>> part or all of the memory we will crash. >>>>>>>>> >>>>>>>>> On posix it is possible to unmap any part of a mapped chunk. So, >>>>>>>>> our >>>>>>>>> proposed solution to the race described above is to not unmap all >>>>>>>>> memory >>>>>>>>> in (1) but rather just unmap the section at the start and at the >>>>>>>>> end of >>>>>>>>> the chunk that we mapped to get alignment. This also removes the >>>>>>>>> need >>>>>>>>> for the loop. >>>>>>>>> >>>>>>>>> However, on Windows you can only unmap _all_ of the memory that you >>>>>>>>> have >>>>>>>>> mapped. On the other hand Windows also will not allow you to map >>>>>>>>> over >>>>>>>>> other mappings, so the original code is actually safe. If we keep >>>>>>>>> the loop. >>>>>>>>> >>>>>>>>> So, our solution is to treat this differently on Windows and posix >>>>>>>>> platforms. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Bengt >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121214/2f78b20f/attachment-0001.html From zhengyu.gu at oracle.com Fri Dec 14 06:59:14 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Fri, 14 Dec 2012 06:59:14 -0800 (PST) Subject: Fwd: Re: Request for review (s): 7173959 : Jvm crashed during coherence exabus (tmb) testing In-Reply-To: <50CB1F33.60605@oracle.com> References: <50CA750A.6040007@oracle.com> <50CB1F33.60605@oracle.com> Message-ID: <50CB3EC2.2090901@oracle.com> Looks good to me. From NMT perspective, as long as os::xxxx_memory methods are used, you don't need to add NMT hooks, but you do have to be careful about tagging the memory pointers returned by os::reserve_memory() methods. But for VirtualSpace and ReservedSpace, etc. utility classes, they are tagged by their callers. Thanks, -Zhengyu On 12/14/2012 7:44 AM, Coleen Phillimore wrote: > > Does NMT track this? Will this mess up NMT? > Coleen > > > -------- Original Message -------- > Subject: Re: Request for review (s): 7173959 : Jvm crashed during > coherence exabus (tmb) testing > Date: Fri, 14 Dec 2012 10:38:34 +1000 > From: David Holmes > Organization: Oracle Corporation > To: Bengt Rutisson > CC: hotspot-runtime-dev at openjdk.java.net > > > > Hi Bengt, > > That all sounds good to me. > > With regard to potential overflow perhaps a simple check that extra_size > does not overflow? If that is true and extra_base is not null then I > think all the other calculations must be valid. > > Thanks, > David > > On 13/12/2012 10:58 PM, Bengt Rutisson wrote: > > > > Hi David, > > > > Updated webrev: > > http://cr.openjdk.java.net/~brutisso/7173959/webrev.02/ > > > > I moved the alignment of "size" back into ReservedSpace::initialize() > > since we actually store the size in an instance variable (_size), so I > > think it is a bit risky to just do the align_up in > > os::reserve_memory_aligned(). We probably want the instance variables > > _size and _alignment in ReservedSpace to be consistent. > > > > I added an assert in os::reserve_memory_aligned() to verify that the > > size is correctly aligned. I also added the assert you suggested to > > check that alignment is page size aligned. > > > > Bengt > > > > On 12/13/12 11:50 AM, David Holmes wrote: > >> On 13/12/2012 8:37 PM, Bengt Rutisson wrote: > >>> > >>> Hi again, > >>> > >>> Updated webrev: > >>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.01/ > >>> > >>> I removed the comment and the alignment. > >>> > >>> But I did not add an assert just yet. > >>> > >>> At the top of ReservedSpace::initialize() we have this code: > >>> > >>> const size_t granularity = os::vm_allocation_granularity(); > >>> assert((size& (granularity - 1)) == 0, > >>> "size not aligned to os::vm_allocation_granularity()"); > >>> assert((alignment& (granularity - 1)) == 0, > >>> "alignment not aligned to os::vm_allocation_granularity()"); > >>> > >>> > >>> Where os::vm_allocation_granularity() is implemented as page size on all > >>> platforms except Windows. There we look it up from the Windows API. I > >>> assume that is a page size too, but since the Windows code in our patch > >>> does not unmap based on the alignment it should be safe either way. > >>> > >>> Is this assert enough or would you like me to add an assert closer to > >>> the code block were I did the changes? > >> > >> As this is a separate method now I think an assert in the method > >> itself would not go astray. > >> > >> David > >> ----- > >> > >>> Thanks, > >>> Bengt > >>> > >>> > >>> On 12/13/12 11:02 AM, Bengt Rutisson wrote: > >>>> > >>>> Hi David, > >>>> > >>>> Thanks for looking at this! > >>>> > >>>> On 12/13/12 8:33 AM, David Holmes wrote: > >>>>> Hi Bengt, > >>>>> > >>>>> This has to be one of the absolute best review requests I've ever > >>>>> read :) Thank you. > >>>> > >>>> Wow! Thanks! :) > >>>> > >>>>> > >>>>> Just a couple of queries. > >>>>> > >>>>> os_posix.cpp: > >>>>> > >>>>> Love the diagram :) > >>>> > >>>> It was Mikael's way of making sure we got it right. > >>>> > >>>>> I'm assuming that "alignment" has to be>= the underlying page size, > >>>>> and in fact must be a multiple of the underlying page size ? (As I > >>>>> assume you can only unmap whole numbers of pages). If so does that > >>>>> need to be checked somewhere? > >>>> > >>>> Good point. I'll add an assert to check that. > >>>> > >>>>> In virtualSpace.cpp: > >>>>> > >>>>> // Reserve size large enough to do manual alignment and > >>>>> // increase size to a multiple of the desired alignment > >>>>> size = align_size_up(size, alignment); > >>>>> ! base = os::reserve_memory_aligned(size, alignment); > >>>>> > >>>>> The comment doesn't seem necessary now, and the align_size_up seems > >>>>> redundant. > >>>> > >>>> You are right. I'll remove the comment and the alignment. > >>>> > >>>> Thanks, > >>>> Bengt > >>>> > >>>>> > >>>>> Thanks, > >>>>> David > >>>>> > >>>>> On 13/12/2012 4:42 PM, Bengt Rutisson wrote: > >>>>>> > >>>>>> Hi all, > >>>>>> > >>>>>> Could I have a couple of reviews for this change? > >>>>>> > >>>>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.00/ > >>>>>> > >>>>>> This is for a bug originally reported by the Coherence team: > >>>>>> > >>>>>> 7173959 : Jvm crashed during coherence exabus (tmb) testing > >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173959 > >>>>>> > >>>>>> The original analysis and proposed fix was done by Mikael Gerdin > >>>>>> and me > >>>>>> together. I'll handle the webrev and push since Mikael is on vacation > >>>>>> starting today. But Mikael did a great job tracking down this very > >>>>>> difficult bug, so he should have a large part of the credit for this > >>>>>> bug > >>>>>> fix, > >>>>>> > >>>>>> Description from the CR: > >>>>>> > >>>>>> The reason that we crash is due to how we re-map memory when we > >>>>>> want to > >>>>>> align it for large pages in ReservedSpace::initialize(). > >>>>>> > >>>>>> Here is what happens: > >>>>>> > >>>>>> The reservation of memory is split up to a few steps. When we want a > >>>>>> chunk of memory with large pages we first just reserve some memory > >>>>>> large > >>>>>> enough for what we need. Then we realize that we want large pages, > >>>>>> so we > >>>>>> want to re-map the reserved memory to use large pages. But since this > >>>>>> requires that we have a large-page-aligned memory chunk we may > >>>>>> have to > >>>>>> fix the recently reserved memory chunk up a bit. > >>>>>> > >>>>>> We do this in ReservedSpace::initialize() by first releasing the > >>>>>> memory > >>>>>> we just reserved. Then requesting more memory than we actually > >>>>>> need to > >>>>>> make sure that we have enough space to do manual large page > >>>>>> alignment. > >>>>>> After we have gotten this memory we figure out a nicely aligned start > >>>>>> address. We then release the memory again and then reserve just > >>>>>> enough > >>>>>> memory but using the aligned start address as a fixed address to make > >>>>>> sure that we get the memory we wanted in an aligned way. > >>>>>> > >>>>>> This is done in a loop to make sure that we eventually get some > >>>>>> memory. > >>>>>> The interesting code looks like this: > >>>>>> > >>>>>> do { > >>>>>> char* extra_base = os::reserve_memory(extra_size, NULL, alignment); > >>>>>> if (extra_base == NULL) return; > >>>>>> // Do manual alignement > >>>>>> base = (char*) align_size_up((uintptr_t) extra_base, alignment); > >>>>>> assert(base>= extra_base, "just checking"); > >>>>>> // Re-reserve the region at the aligned base address. > >>>>>> os::release_memory(extra_base, extra_size); // (1) > >>>>>> base = os::reserve_memory(size, base); // (2) > >>>>>> } while (base == NULL); > >>>>>> > >>>>>> > >>>>>> There is a race here between releasing the memory in (1) and > >>>>>> re-reserving it in (2). But the loop is supposed to handle this race. > >>>>>> > >>>>>> The problem is that on posix platforms you can remap the same memory > >>>>>> area several times. The call in (2) will use mmap with MAP_FIXED. > >>>>>> This > >>>>>> means that the OS will think that you know exactly what you are > >>>>>> doing. > >>>>>> So, if part of the memory has been mapped already by the process it > >>>>>> will > >>>>>> just go ahead and reuse that memory. > >>>>>> > >>>>>> This means that if we are having multiple threads that do mmap. We > >>>>>> can > >>>>>> end up with a situation where we release our mapping in (1). Then > >>>>>> another thread comes in and maps part of the memory that we used to > >>>>>> have. Then we remap over that memory again in (2) with MAP_FIXED. > >>>>>> Now we > >>>>>> have a situation where two threads in our process have mapped the > >>>>>> same > >>>>>> memory. If both threads try to use it or if one of the threads unmap > >>>>>> part or all of the memory we will crash. > >>>>>> > >>>>>> On posix it is possible to unmap any part of a mapped chunk. So, our > >>>>>> proposed solution to the race described above is to not unmap all > >>>>>> memory > >>>>>> in (1) but rather just unmap the section at the start and at the > >>>>>> end of > >>>>>> the chunk that we mapped to get alignment. This also removes the need > >>>>>> for the loop. > >>>>>> > >>>>>> However, on Windows you can only unmap _all_ of the memory that you > >>>>>> have > >>>>>> mapped. On the other hand Windows also will not allow you to map over > >>>>>> other mappings, so the original code is actually safe. If we keep > >>>>>> the loop. > >>>>>> > >>>>>> So, our solution is to treat this differently on Windows and posix > >>>>>> platforms. > >>>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> Bengt > >>>> > >>> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121214/723cc23f/attachment.html From bengt.rutisson at oracle.com Fri Dec 14 07:24:30 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 14 Dec 2012 16:24:30 +0100 Subject: Request for review (s): 7173959 : Jvm crashed during coherence exabus (tmb) testing In-Reply-To: <50CB27C0.6050708@oracle.com> References: <50C978BE.8040405@oracle.com> <50C984DA.1070400@oracle.com> <50C9A7AD.3030307@oracle.com> <50C9AFE9.2080601@oracle.com> <50C9B2EC.5090008@oracle.com> <50C9D0F1.9040501@oracle.com> <50CA750A.6040007@oracle.com> <50CAE384.6070003@oracle.com> <50CAE7F6.2020609@oracle.com> <50CB27C0.6050708@oracle.com> Message-ID: <50CB44AE.9040509@oracle.com> Hi Coleen, Thanks for looking at this! On 12/14/12 2:21 PM, Coleen Phillimore wrote: > On 12/14/2012 3:48 AM, Bengt Rutisson wrote: >> >> Hi again Runtime team, >> >> I need one more review for this change. It is a P1 bug with a fairly >> small change. Any takers? >> >> Latest webrev based on comments from David Holmes and Vitaly Davidovich: >> http://cr.openjdk.java.net/~brutisso/7173959/webrev.03/ > > Hi Bengt, This code looks good to me but I asked Zhengyu to check it > to make sure it doesn't have any bad NMT interactions. Thanks! He just replied. > > Also the writeup is great below, but can you add these comments to the > code in os_posix.cpp. I had to go back to the email to figure out > why you are doing this. I'm not really sure where to put such a comment. I think the writeup I did mostly makes sense when you compare it to the old code. Also, the affected code is in the middle of ReservedSpace::initialize(). I think it would look strange with a large comment there. In the os_posix/windows files the comment does not make much sense in my opinion. I could add a comment in ReservedSpace::initialize() that refers to the Jira issue. But I'm not a big fan of such comments. > > I don't understand why there are racing threads. I thought all the > heap space was initialized at the start of the vm when it is single > threaded? I would have to look up exactly when we set up the heap to see if we are single threaded at that point. The issue we saw was with setting up the GC bitmaps. At that point we are multithreaded and we are for example mapping memory for the GC worker threads at the same time. Thanks again for looking at this! Bengt > > thanks, > Coleen > >> >> Thanks, >> Bengt >> >> >> On 12/14/12 9:29 AM, Bengt Rutisson wrote: >>> >>> Hi David, >>> >>> On 12/14/12 1:38 AM, David Holmes wrote: >>>> Hi Bengt, >>>> >>>> That all sounds good to me. >>>> >>>> With regard to potential overflow perhaps a simple check that >>>> extra_size does not overflow? If that is true and extra_base is not >>>> null then I think all the other calculations must be valid. >>> >>> Yes, that makes sense. I'll add an overflow check for the extra_size. >>> >>> Thanks, >>> Bengt >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 13/12/2012 10:58 PM, Bengt Rutisson wrote: >>>>> >>>>> Hi David, >>>>> >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.02/ >>>>> >>>>> I moved the alignment of "size" back into ReservedSpace::initialize() >>>>> since we actually store the size in an instance variable (_size), >>>>> so I >>>>> think it is a bit risky to just do the align_up in >>>>> os::reserve_memory_aligned(). We probably want the instance variables >>>>> _size and _alignment in ReservedSpace to be consistent. >>>>> >>>>> I added an assert in os::reserve_memory_aligned() to verify that the >>>>> size is correctly aligned. I also added the assert you suggested to >>>>> check that alignment is page size aligned. >>>>> >>>>> Bengt >>>>> >>>>> On 12/13/12 11:50 AM, David Holmes wrote: >>>>>> On 13/12/2012 8:37 PM, Bengt Rutisson wrote: >>>>>>> >>>>>>> Hi again, >>>>>>> >>>>>>> Updated webrev: >>>>>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.01/ >>>>>>> >>>>>>> I removed the comment and the alignment. >>>>>>> >>>>>>> But I did not add an assert just yet. >>>>>>> >>>>>>> At the top of ReservedSpace::initialize() we have this code: >>>>>>> >>>>>>> const size_t granularity = os::vm_allocation_granularity(); >>>>>>> assert((size & (granularity - 1)) == 0, >>>>>>> "size not aligned to os::vm_allocation_granularity()"); >>>>>>> assert((alignment & (granularity - 1)) == 0, >>>>>>> "alignment not aligned to os::vm_allocation_granularity()"); >>>>>>> >>>>>>> >>>>>>> Where os::vm_allocation_granularity() is implemented as page >>>>>>> size on all >>>>>>> platforms except Windows. There we look it up from the Windows >>>>>>> API. I >>>>>>> assume that is a page size too, but since the Windows code in >>>>>>> our patch >>>>>>> does not unmap based on the alignment it should be safe either way. >>>>>>> >>>>>>> Is this assert enough or would you like me to add an assert >>>>>>> closer to >>>>>>> the code block were I did the changes? >>>>>> >>>>>> As this is a separate method now I think an assert in the method >>>>>> itself would not go astray. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> Thanks, >>>>>>> Bengt >>>>>>> >>>>>>> >>>>>>> On 12/13/12 11:02 AM, Bengt Rutisson wrote: >>>>>>>> >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Thanks for looking at this! >>>>>>>> >>>>>>>> On 12/13/12 8:33 AM, David Holmes wrote: >>>>>>>>> Hi Bengt, >>>>>>>>> >>>>>>>>> This has to be one of the absolute best review requests I've ever >>>>>>>>> read :) Thank you. >>>>>>>> >>>>>>>> Wow! Thanks! :) >>>>>>>> >>>>>>>>> >>>>>>>>> Just a couple of queries. >>>>>>>>> >>>>>>>>> os_posix.cpp: >>>>>>>>> >>>>>>>>> Love the diagram :) >>>>>>>> >>>>>>>> It was Mikael's way of making sure we got it right. >>>>>>>> >>>>>>>>> I'm assuming that "alignment" has to be >= the underlying page >>>>>>>>> size, >>>>>>>>> and in fact must be a multiple of the underlying page size ? >>>>>>>>> (As I >>>>>>>>> assume you can only unmap whole numbers of pages). If so does >>>>>>>>> that >>>>>>>>> need to be checked somewhere? >>>>>>>> >>>>>>>> Good point. I'll add an assert to check that. >>>>>>>> >>>>>>>>> In virtualSpace.cpp: >>>>>>>>> >>>>>>>>> // Reserve size large enough to do manual alignment and >>>>>>>>> // increase size to a multiple of the desired alignment >>>>>>>>> size = align_size_up(size, alignment); >>>>>>>>> ! base = os::reserve_memory_aligned(size, alignment); >>>>>>>>> >>>>>>>>> The comment doesn't seem necessary now, and the align_size_up >>>>>>>>> seems >>>>>>>>> redundant. >>>>>>>> >>>>>>>> You are right. I'll remove the comment and the alignment. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Bengt >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 13/12/2012 4:42 PM, Bengt Rutisson wrote: >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Could I have a couple of reviews for this change? >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.00/ >>>>>>>>>> >>>>>>>>>> This is for a bug originally reported by the Coherence team: >>>>>>>>>> >>>>>>>>>> 7173959 : Jvm crashed during coherence exabus (tmb) testing >>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173959 >>>>>>>>>> >>>>>>>>>> The original analysis and proposed fix was done by Mikael Gerdin >>>>>>>>>> and me >>>>>>>>>> together. I'll handle the webrev and push since Mikael is on >>>>>>>>>> vacation >>>>>>>>>> starting today. But Mikael did a great job tracking down this >>>>>>>>>> very >>>>>>>>>> difficult bug, so he should have a large part of the credit >>>>>>>>>> for this >>>>>>>>>> bug >>>>>>>>>> fix, >>>>>>>>>> >>>>>>>>>> Description from the CR: >>>>>>>>>> >>>>>>>>>> The reason that we crash is due to how we re-map memory when we >>>>>>>>>> want to >>>>>>>>>> align it for large pages in ReservedSpace::initialize(). >>>>>>>>>> >>>>>>>>>> Here is what happens: >>>>>>>>>> >>>>>>>>>> The reservation of memory is split up to a few steps. When we >>>>>>>>>> want a >>>>>>>>>> chunk of memory with large pages we first just reserve some >>>>>>>>>> memory >>>>>>>>>> large >>>>>>>>>> enough for what we need. Then we realize that we want large >>>>>>>>>> pages, >>>>>>>>>> so we >>>>>>>>>> want to re-map the reserved memory to use large pages. But >>>>>>>>>> since this >>>>>>>>>> requires that we have a large-page-aligned memory chunk we may >>>>>>>>>> have to >>>>>>>>>> fix the recently reserved memory chunk up a bit. >>>>>>>>>> >>>>>>>>>> We do this in ReservedSpace::initialize() by first releasing the >>>>>>>>>> memory >>>>>>>>>> we just reserved. Then requesting more memory than we actually >>>>>>>>>> need to >>>>>>>>>> make sure that we have enough space to do manual large page >>>>>>>>>> alignment. >>>>>>>>>> After we have gotten this memory we figure out a nicely >>>>>>>>>> aligned start >>>>>>>>>> address. We then release the memory again and then reserve just >>>>>>>>>> enough >>>>>>>>>> memory but using the aligned start address as a fixed address >>>>>>>>>> to make >>>>>>>>>> sure that we get the memory we wanted in an aligned way. >>>>>>>>>> >>>>>>>>>> This is done in a loop to make sure that we eventually get some >>>>>>>>>> memory. >>>>>>>>>> The interesting code looks like this: >>>>>>>>>> >>>>>>>>>> do { >>>>>>>>>> char* extra_base = os::reserve_memory(extra_size, NULL, >>>>>>>>>> alignment); >>>>>>>>>> if (extra_base == NULL) return; >>>>>>>>>> // Do manual alignement >>>>>>>>>> base = (char*) align_size_up((uintptr_t) extra_base, alignment); >>>>>>>>>> assert(base >= extra_base, "just checking"); >>>>>>>>>> // Re-reserve the region at the aligned base address. >>>>>>>>>> os::release_memory(extra_base, extra_size); // (1) >>>>>>>>>> base = os::reserve_memory(size, base); // (2) >>>>>>>>>> } while (base == NULL); >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> There is a race here between releasing the memory in (1) and >>>>>>>>>> re-reserving it in (2). But the loop is supposed to handle >>>>>>>>>> this race. >>>>>>>>>> >>>>>>>>>> The problem is that on posix platforms you can remap the same >>>>>>>>>> memory >>>>>>>>>> area several times. The call in (2) will use mmap with >>>>>>>>>> MAP_FIXED. >>>>>>>>>> This >>>>>>>>>> means that the OS will think that you know exactly what you are >>>>>>>>>> doing. >>>>>>>>>> So, if part of the memory has been mapped already by the >>>>>>>>>> process it >>>>>>>>>> will >>>>>>>>>> just go ahead and reuse that memory. >>>>>>>>>> >>>>>>>>>> This means that if we are having multiple threads that do >>>>>>>>>> mmap. We >>>>>>>>>> can >>>>>>>>>> end up with a situation where we release our mapping in (1). >>>>>>>>>> Then >>>>>>>>>> another thread comes in and maps part of the memory that we >>>>>>>>>> used to >>>>>>>>>> have. Then we remap over that memory again in (2) with >>>>>>>>>> MAP_FIXED. >>>>>>>>>> Now we >>>>>>>>>> have a situation where two threads in our process have mapped >>>>>>>>>> the >>>>>>>>>> same >>>>>>>>>> memory. If both threads try to use it or if one of the >>>>>>>>>> threads unmap >>>>>>>>>> part or all of the memory we will crash. >>>>>>>>>> >>>>>>>>>> On posix it is possible to unmap any part of a mapped chunk. >>>>>>>>>> So, our >>>>>>>>>> proposed solution to the race described above is to not unmap >>>>>>>>>> all >>>>>>>>>> memory >>>>>>>>>> in (1) but rather just unmap the section at the start and at the >>>>>>>>>> end of >>>>>>>>>> the chunk that we mapped to get alignment. This also removes >>>>>>>>>> the need >>>>>>>>>> for the loop. >>>>>>>>>> >>>>>>>>>> However, on Windows you can only unmap _all_ of the memory >>>>>>>>>> that you >>>>>>>>>> have >>>>>>>>>> mapped. On the other hand Windows also will not allow you to >>>>>>>>>> map over >>>>>>>>>> other mappings, so the original code is actually safe. If we >>>>>>>>>> keep >>>>>>>>>> the loop. >>>>>>>>>> >>>>>>>>>> So, our solution is to treat this differently on Windows and >>>>>>>>>> posix >>>>>>>>>> platforms. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Bengt >>>>>>>> >>>>>>> >>>>> >>> >> > From bengt.rutisson at oracle.com Fri Dec 14 07:26:32 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 14 Dec 2012 16:26:32 +0100 Subject: Fwd: Re: Request for review (s): 7173959 : Jvm crashed during coherence exabus (tmb) testing In-Reply-To: <50CB3EC2.2090901@oracle.com> References: <50CA750A.6040007@oracle.com> <50CB1F33.60605@oracle.com> <50CB3EC2.2090901@oracle.com> Message-ID: <50CB4528.6020405@oracle.com> Hi Zhengyu, Thanks for looking at this! On 12/14/12 3:59 PM, Zhengyu Gu wrote: > Looks good to me. > > From NMT perspective, as long as os::xxxx_memory methods are used, you > don't need to add NMT hooks, but you do have to be careful about > tagging the memory pointers returned by os::reserve_memory() methods. > But for VirtualSpace and ReservedSpace, etc. utility classes, they are > tagged by their callers. Thanks for verifying this. Bengt > > Thanks, > > -Zhengyu > > On 12/14/2012 7:44 AM, Coleen Phillimore wrote: >> >> Does NMT track this? Will this mess up NMT? >> Coleen >> >> >> -------- Original Message -------- >> Subject: Re: Request for review (s): 7173959 : Jvm crashed during >> coherence exabus (tmb) testing >> Date: Fri, 14 Dec 2012 10:38:34 +1000 >> From: David Holmes >> Organization: Oracle Corporation >> To: Bengt Rutisson >> CC: hotspot-runtime-dev at openjdk.java.net >> >> >> >> Hi Bengt, >> >> That all sounds good to me. >> >> With regard to potential overflow perhaps a simple check that extra_size >> does not overflow? If that is true and extra_base is not null then I >> think all the other calculations must be valid. >> >> Thanks, >> David >> >> On 13/12/2012 10:58 PM, Bengt Rutisson wrote: >> > >> > Hi David, >> > >> > Updated webrev: >> >http://cr.openjdk.java.net/~brutisso/7173959/webrev.02/ >> > >> > I moved the alignment of "size" back into ReservedSpace::initialize() >> > since we actually store the size in an instance variable (_size), so I >> > think it is a bit risky to just do the align_up in >> > os::reserve_memory_aligned(). We probably want the instance variables >> > _size and _alignment in ReservedSpace to be consistent. >> > >> > I added an assert in os::reserve_memory_aligned() to verify that the >> > size is correctly aligned. I also added the assert you suggested to >> > check that alignment is page size aligned. >> > >> > Bengt >> > >> > On 12/13/12 11:50 AM, David Holmes wrote: >> >> On 13/12/2012 8:37 PM, Bengt Rutisson wrote: >> >>> >> >>> Hi again, >> >>> >> >>> Updated webrev: >> >>>http://cr.openjdk.java.net/~brutisso/7173959/webrev.01/ >> >>> >> >>> I removed the comment and the alignment. >> >>> >> >>> But I did not add an assert just yet. >> >>> >> >>> At the top of ReservedSpace::initialize() we have this code: >> >>> >> >>> const size_t granularity = os::vm_allocation_granularity(); >> >>> assert((size & (granularity - 1)) == 0, >> >>> "size not aligned to os::vm_allocation_granularity()"); >> >>> assert((alignment & (granularity - 1)) == 0, >> >>> "alignment not aligned to os::vm_allocation_granularity()"); >> >>> >> >>> >> >>> Where os::vm_allocation_granularity() is implemented as page size on all >> >>> platforms except Windows. There we look it up from the Windows API. I >> >>> assume that is a page size too, but since the Windows code in our patch >> >>> does not unmap based on the alignment it should be safe either way. >> >>> >> >>> Is this assert enough or would you like me to add an assert closer to >> >>> the code block were I did the changes? >> >> >> >> As this is a separate method now I think an assert in the method >> >> itself would not go astray. >> >> >> >> David >> >> ----- >> >> >> >>> Thanks, >> >>> Bengt >> >>> >> >>> >> >>> On 12/13/12 11:02 AM, Bengt Rutisson wrote: >> >>>> >> >>>> Hi David, >> >>>> >> >>>> Thanks for looking at this! >> >>>> >> >>>> On 12/13/12 8:33 AM, David Holmes wrote: >> >>>>> Hi Bengt, >> >>>>> >> >>>>> This has to be one of the absolute best review requests I've ever >> >>>>> read :) Thank you. >> >>>> >> >>>> Wow! Thanks! :) >> >>>> >> >>>>> >> >>>>> Just a couple of queries. >> >>>>> >> >>>>> os_posix.cpp: >> >>>>> >> >>>>> Love the diagram :) >> >>>> >> >>>> It was Mikael's way of making sure we got it right. >> >>>> >> >>>>> I'm assuming that "alignment" has to be >= the underlying page size, >> >>>>> and in fact must be a multiple of the underlying page size ? (As I >> >>>>> assume you can only unmap whole numbers of pages). If so does that >> >>>>> need to be checked somewhere? >> >>>> >> >>>> Good point. I'll add an assert to check that. >> >>>> >> >>>>> In virtualSpace.cpp: >> >>>>> >> >>>>> // Reserve size large enough to do manual alignment and >> >>>>> // increase size to a multiple of the desired alignment >> >>>>> size = align_size_up(size, alignment); >> >>>>> ! base = os::reserve_memory_aligned(size, alignment); >> >>>>> >> >>>>> The comment doesn't seem necessary now, and the align_size_up seems >> >>>>> redundant. >> >>>> >> >>>> You are right. I'll remove the comment and the alignment. >> >>>> >> >>>> Thanks, >> >>>> Bengt >> >>>> >> >>>>> >> >>>>> Thanks, >> >>>>> David >> >>>>> >> >>>>> On 13/12/2012 4:42 PM, Bengt Rutisson wrote: >> >>>>>> >> >>>>>> Hi all, >> >>>>>> >> >>>>>> Could I have a couple of reviews for this change? >> >>>>>> >> >>>>>>http://cr.openjdk.java.net/~brutisso/7173959/webrev.00/ >> >>>>>> >> >>>>>> This is for a bug originally reported by the Coherence team: >> >>>>>> >> >>>>>> 7173959 : Jvm crashed during coherence exabus (tmb) testing >> >>>>>>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173959 >> >>>>>> >> >>>>>> The original analysis and proposed fix was done by Mikael Gerdin >> >>>>>> and me >> >>>>>> together. I'll handle the webrev and push since Mikael is on vacation >> >>>>>> starting today. But Mikael did a great job tracking down this very >> >>>>>> difficult bug, so he should have a large part of the credit for this >> >>>>>> bug >> >>>>>> fix, >> >>>>>> >> >>>>>> Description from the CR: >> >>>>>> >> >>>>>> The reason that we crash is due to how we re-map memory when we >> >>>>>> want to >> >>>>>> align it for large pages in ReservedSpace::initialize(). >> >>>>>> >> >>>>>> Here is what happens: >> >>>>>> >> >>>>>> The reservation of memory is split up to a few steps. When we want a >> >>>>>> chunk of memory with large pages we first just reserve some memory >> >>>>>> large >> >>>>>> enough for what we need. Then we realize that we want large pages, >> >>>>>> so we >> >>>>>> want to re-map the reserved memory to use large pages. But since this >> >>>>>> requires that we have a large-page-aligned memory chunk we may >> >>>>>> have to >> >>>>>> fix the recently reserved memory chunk up a bit. >> >>>>>> >> >>>>>> We do this in ReservedSpace::initialize() by first releasing the >> >>>>>> memory >> >>>>>> we just reserved. Then requesting more memory than we actually >> >>>>>> need to >> >>>>>> make sure that we have enough space to do manual large page >> >>>>>> alignment. >> >>>>>> After we have gotten this memory we figure out a nicely aligned start >> >>>>>> address. We then release the memory again and then reserve just >> >>>>>> enough >> >>>>>> memory but using the aligned start address as a fixed address to make >> >>>>>> sure that we get the memory we wanted in an aligned way. >> >>>>>> >> >>>>>> This is done in a loop to make sure that we eventually get some >> >>>>>> memory. >> >>>>>> The interesting code looks like this: >> >>>>>> >> >>>>>> do { >> >>>>>> char* extra_base = os::reserve_memory(extra_size, NULL, alignment); >> >>>>>> if (extra_base == NULL) return; >> >>>>>> // Do manual alignement >> >>>>>> base = (char*) align_size_up((uintptr_t) extra_base, alignment); >> >>>>>> assert(base >= extra_base, "just checking"); >> >>>>>> // Re-reserve the region at the aligned base address. >> >>>>>> os::release_memory(extra_base, extra_size); // (1) >> >>>>>> base = os::reserve_memory(size, base); // (2) >> >>>>>> } while (base == NULL); >> >>>>>> >> >>>>>> >> >>>>>> There is a race here between releasing the memory in (1) and >> >>>>>> re-reserving it in (2). But the loop is supposed to handle this race. >> >>>>>> >> >>>>>> The problem is that on posix platforms you can remap the same memory >> >>>>>> area several times. The call in (2) will use mmap with MAP_FIXED. >> >>>>>> This >> >>>>>> means that the OS will think that you know exactly what you are >> >>>>>> doing. >> >>>>>> So, if part of the memory has been mapped already by the process it >> >>>>>> will >> >>>>>> just go ahead and reuse that memory. >> >>>>>> >> >>>>>> This means that if we are having multiple threads that do mmap. We >> >>>>>> can >> >>>>>> end up with a situation where we release our mapping in (1). Then >> >>>>>> another thread comes in and maps part of the memory that we used to >> >>>>>> have. Then we remap over that memory again in (2) with MAP_FIXED. >> >>>>>> Now we >> >>>>>> have a situation where two threads in our process have mapped the >> >>>>>> same >> >>>>>> memory. If both threads try to use it or if one of the threads unmap >> >>>>>> part or all of the memory we will crash. >> >>>>>> >> >>>>>> On posix it is possible to unmap any part of a mapped chunk. So, our >> >>>>>> proposed solution to the race described above is to not unmap all >> >>>>>> memory >> >>>>>> in (1) but rather just unmap the section at the start and at the >> >>>>>> end of >> >>>>>> the chunk that we mapped to get alignment. This also removes the need >> >>>>>> for the loop. >> >>>>>> >> >>>>>> However, on Windows you can only unmap _all_ of the memory that you >> >>>>>> have >> >>>>>> mapped. On the other hand Windows also will not allow you to map over >> >>>>>> other mappings, so the original code is actually safe. If we keep >> >>>>>> the loop. >> >>>>>> >> >>>>>> So, our solution is to treat this differently on Windows and posix >> >>>>>> platforms. >> >>>>>> >> >>>>>> >> >>>>>> Thanks, >> >>>>>> Bengt >> >>>> >> >>> >> > >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121214/69e05722/attachment.html From coleen.phillimore at oracle.com Fri Dec 14 07:49:44 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 14 Dec 2012 10:49:44 -0500 Subject: Request for review (s): 7173959 : Jvm crashed during coherence exabus (tmb) testing In-Reply-To: <50CB44AE.9040509@oracle.com> References: <50C978BE.8040405@oracle.com> <50C984DA.1070400@oracle.com> <50C9A7AD.3030307@oracle.com> <50C9AFE9.2080601@oracle.com> <50C9B2EC.5090008@oracle.com> <50C9D0F1.9040501@oracle.com> <50CA750A.6040007@oracle.com> <50CAE384.6070003@oracle.com> <50CAE7F6.2020609@oracle.com> <50CB27C0.6050708@oracle.com> <50CB44AE.9040509@oracle.com> Message-ID: <50CB4A98.7070008@oracle.com> On 12/14/2012 10:24 AM, Bengt Rutisson wrote: > > Hi Coleen, > > Thanks for looking at this! > > On 12/14/12 2:21 PM, Coleen Phillimore wrote: >> On 12/14/2012 3:48 AM, Bengt Rutisson wrote: >>> >>> Hi again Runtime team, >>> >>> I need one more review for this change. It is a P1 bug with a fairly >>> small change. Any takers? >>> >>> Latest webrev based on comments from David Holmes and Vitaly >>> Davidovich: >>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.03/ >> >> Hi Bengt, This code looks good to me but I asked Zhengyu to check >> it to make sure it doesn't have any bad NMT interactions. > > Thanks! He just replied. >> >> Also the writeup is great below, but can you add these comments to >> the code in os_posix.cpp. I had to go back to the email to figure >> out why you are doing this. > > I'm not really sure where to put such a comment. I think the writeup I > did mostly makes sense when you compare it to the old code. Also, the > affected code is in the middle of ReservedSpace::initialize(). I think > it would look strange with a large comment there. In the > os_posix/windows files the comment does not make much sense in my > opinion. > > I could add a comment in ReservedSpace::initialize() that refers to > the Jira issue. But I'm not a big fan of such comments. I agree we shouldn't point to bugs in the source code. A comment at the top of the os_posix version of this function that paraphrases below why you are not re-reserving in a loop like windows would be sufficient. That trimming memory at either end is allowed on posix-like os's and is thread-safe, something like: // Multiple threads can race in this code, and can remap over each other with MAP_FIXED, so on posix, unmap the section // at the start and at the end of the chunk that we mapped to get requested alignment. os_windows: // Multiple threads can race in this code but it's not possible to remap with a section of virtual space to get requested alignment, like posix-like os's. // Windows prevents multiple thread from remapping over each other so this loop is thread-safe. I just want something to document why they are different. > >> >> I don't understand why there are racing threads. I thought all the >> heap space was initialized at the start of the vm when it is single >> threaded? > > I would have to look up exactly when we set up the heap to see if we > are single threaded at that point. The issue we saw was with setting > up the GC bitmaps. At that point we are multithreaded and we are for > example mapping memory for the GC worker threads at the same time. I see. Coleen > > > Thanks again for looking at this! > Bengt > >> >> thanks, >> Coleen >> >>> >>> Thanks, >>> Bengt >>> >>> >>> On 12/14/12 9:29 AM, Bengt Rutisson wrote: >>>> >>>> Hi David, >>>> >>>> On 12/14/12 1:38 AM, David Holmes wrote: >>>>> Hi Bengt, >>>>> >>>>> That all sounds good to me. >>>>> >>>>> With regard to potential overflow perhaps a simple check that >>>>> extra_size does not overflow? If that is true and extra_base is >>>>> not null then I think all the other calculations must be valid. >>>> >>>> Yes, that makes sense. I'll add an overflow check for the extra_size. >>>> >>>> Thanks, >>>> Bengt >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 13/12/2012 10:58 PM, Bengt Rutisson wrote: >>>>>> >>>>>> Hi David, >>>>>> >>>>>> Updated webrev: >>>>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.02/ >>>>>> >>>>>> I moved the alignment of "size" back into >>>>>> ReservedSpace::initialize() >>>>>> since we actually store the size in an instance variable (_size), >>>>>> so I >>>>>> think it is a bit risky to just do the align_up in >>>>>> os::reserve_memory_aligned(). We probably want the instance >>>>>> variables >>>>>> _size and _alignment in ReservedSpace to be consistent. >>>>>> >>>>>> I added an assert in os::reserve_memory_aligned() to verify that the >>>>>> size is correctly aligned. I also added the assert you suggested to >>>>>> check that alignment is page size aligned. >>>>>> >>>>>> Bengt >>>>>> >>>>>> On 12/13/12 11:50 AM, David Holmes wrote: >>>>>>> On 13/12/2012 8:37 PM, Bengt Rutisson wrote: >>>>>>>> >>>>>>>> Hi again, >>>>>>>> >>>>>>>> Updated webrev: >>>>>>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.01/ >>>>>>>> >>>>>>>> I removed the comment and the alignment. >>>>>>>> >>>>>>>> But I did not add an assert just yet. >>>>>>>> >>>>>>>> At the top of ReservedSpace::initialize() we have this code: >>>>>>>> >>>>>>>> const size_t granularity = os::vm_allocation_granularity(); >>>>>>>> assert((size & (granularity - 1)) == 0, >>>>>>>> "size not aligned to os::vm_allocation_granularity()"); >>>>>>>> assert((alignment & (granularity - 1)) == 0, >>>>>>>> "alignment not aligned to os::vm_allocation_granularity()"); >>>>>>>> >>>>>>>> >>>>>>>> Where os::vm_allocation_granularity() is implemented as page >>>>>>>> size on all >>>>>>>> platforms except Windows. There we look it up from the Windows >>>>>>>> API. I >>>>>>>> assume that is a page size too, but since the Windows code in >>>>>>>> our patch >>>>>>>> does not unmap based on the alignment it should be safe either >>>>>>>> way. >>>>>>>> >>>>>>>> Is this assert enough or would you like me to add an assert >>>>>>>> closer to >>>>>>>> the code block were I did the changes? >>>>>>> >>>>>>> As this is a separate method now I think an assert in the method >>>>>>> itself would not go astray. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> Thanks, >>>>>>>> Bengt >>>>>>>> >>>>>>>> >>>>>>>> On 12/13/12 11:02 AM, Bengt Rutisson wrote: >>>>>>>>> >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> Thanks for looking at this! >>>>>>>>> >>>>>>>>> On 12/13/12 8:33 AM, David Holmes wrote: >>>>>>>>>> Hi Bengt, >>>>>>>>>> >>>>>>>>>> This has to be one of the absolute best review requests I've >>>>>>>>>> ever >>>>>>>>>> read :) Thank you. >>>>>>>>> >>>>>>>>> Wow! Thanks! :) >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Just a couple of queries. >>>>>>>>>> >>>>>>>>>> os_posix.cpp: >>>>>>>>>> >>>>>>>>>> Love the diagram :) >>>>>>>>> >>>>>>>>> It was Mikael's way of making sure we got it right. >>>>>>>>> >>>>>>>>>> I'm assuming that "alignment" has to be >= the underlying >>>>>>>>>> page size, >>>>>>>>>> and in fact must be a multiple of the underlying page size ? >>>>>>>>>> (As I >>>>>>>>>> assume you can only unmap whole numbers of pages). If so does >>>>>>>>>> that >>>>>>>>>> need to be checked somewhere? >>>>>>>>> >>>>>>>>> Good point. I'll add an assert to check that. >>>>>>>>> >>>>>>>>>> In virtualSpace.cpp: >>>>>>>>>> >>>>>>>>>> // Reserve size large enough to do manual alignment and >>>>>>>>>> // increase size to a multiple of the desired alignment >>>>>>>>>> size = align_size_up(size, alignment); >>>>>>>>>> ! base = os::reserve_memory_aligned(size, alignment); >>>>>>>>>> >>>>>>>>>> The comment doesn't seem necessary now, and the align_size_up >>>>>>>>>> seems >>>>>>>>>> redundant. >>>>>>>>> >>>>>>>>> You are right. I'll remove the comment and the alignment. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Bengt >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 13/12/2012 4:42 PM, Bengt Rutisson wrote: >>>>>>>>>>> >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> Could I have a couple of reviews for this change? >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> This is for a bug originally reported by the Coherence team: >>>>>>>>>>> >>>>>>>>>>> 7173959 : Jvm crashed during coherence exabus (tmb) testing >>>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173959 >>>>>>>>>>> >>>>>>>>>>> The original analysis and proposed fix was done by Mikael >>>>>>>>>>> Gerdin >>>>>>>>>>> and me >>>>>>>>>>> together. I'll handle the webrev and push since Mikael is on >>>>>>>>>>> vacation >>>>>>>>>>> starting today. But Mikael did a great job tracking down >>>>>>>>>>> this very >>>>>>>>>>> difficult bug, so he should have a large part of the credit >>>>>>>>>>> for this >>>>>>>>>>> bug >>>>>>>>>>> fix, >>>>>>>>>>> >>>>>>>>>>> Description from the CR: >>>>>>>>>>> >>>>>>>>>>> The reason that we crash is due to how we re-map memory when we >>>>>>>>>>> want to >>>>>>>>>>> align it for large pages in ReservedSpace::initialize(). >>>>>>>>>>> >>>>>>>>>>> Here is what happens: >>>>>>>>>>> >>>>>>>>>>> The reservation of memory is split up to a few steps. When >>>>>>>>>>> we want a >>>>>>>>>>> chunk of memory with large pages we first just reserve some >>>>>>>>>>> memory >>>>>>>>>>> large >>>>>>>>>>> enough for what we need. Then we realize that we want large >>>>>>>>>>> pages, >>>>>>>>>>> so we >>>>>>>>>>> want to re-map the reserved memory to use large pages. But >>>>>>>>>>> since this >>>>>>>>>>> requires that we have a large-page-aligned memory chunk we may >>>>>>>>>>> have to >>>>>>>>>>> fix the recently reserved memory chunk up a bit. >>>>>>>>>>> >>>>>>>>>>> We do this in ReservedSpace::initialize() by first releasing >>>>>>>>>>> the >>>>>>>>>>> memory >>>>>>>>>>> we just reserved. Then requesting more memory than we actually >>>>>>>>>>> need to >>>>>>>>>>> make sure that we have enough space to do manual large page >>>>>>>>>>> alignment. >>>>>>>>>>> After we have gotten this memory we figure out a nicely >>>>>>>>>>> aligned start >>>>>>>>>>> address. We then release the memory again and then reserve just >>>>>>>>>>> enough >>>>>>>>>>> memory but using the aligned start address as a fixed >>>>>>>>>>> address to make >>>>>>>>>>> sure that we get the memory we wanted in an aligned way. >>>>>>>>>>> >>>>>>>>>>> This is done in a loop to make sure that we eventually get some >>>>>>>>>>> memory. >>>>>>>>>>> The interesting code looks like this: >>>>>>>>>>> >>>>>>>>>>> do { >>>>>>>>>>> char* extra_base = os::reserve_memory(extra_size, NULL, >>>>>>>>>>> alignment); >>>>>>>>>>> if (extra_base == NULL) return; >>>>>>>>>>> // Do manual alignement >>>>>>>>>>> base = (char*) align_size_up((uintptr_t) extra_base, >>>>>>>>>>> alignment); >>>>>>>>>>> assert(base >= extra_base, "just checking"); >>>>>>>>>>> // Re-reserve the region at the aligned base address. >>>>>>>>>>> os::release_memory(extra_base, extra_size); // (1) >>>>>>>>>>> base = os::reserve_memory(size, base); // (2) >>>>>>>>>>> } while (base == NULL); >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> There is a race here between releasing the memory in (1) and >>>>>>>>>>> re-reserving it in (2). But the loop is supposed to handle >>>>>>>>>>> this race. >>>>>>>>>>> >>>>>>>>>>> The problem is that on posix platforms you can remap the >>>>>>>>>>> same memory >>>>>>>>>>> area several times. The call in (2) will use mmap with >>>>>>>>>>> MAP_FIXED. >>>>>>>>>>> This >>>>>>>>>>> means that the OS will think that you know exactly what you are >>>>>>>>>>> doing. >>>>>>>>>>> So, if part of the memory has been mapped already by the >>>>>>>>>>> process it >>>>>>>>>>> will >>>>>>>>>>> just go ahead and reuse that memory. >>>>>>>>>>> >>>>>>>>>>> This means that if we are having multiple threads that do >>>>>>>>>>> mmap. We >>>>>>>>>>> can >>>>>>>>>>> end up with a situation where we release our mapping in (1). >>>>>>>>>>> Then >>>>>>>>>>> another thread comes in and maps part of the memory that we >>>>>>>>>>> used to >>>>>>>>>>> have. Then we remap over that memory again in (2) with >>>>>>>>>>> MAP_FIXED. >>>>>>>>>>> Now we >>>>>>>>>>> have a situation where two threads in our process have >>>>>>>>>>> mapped the >>>>>>>>>>> same >>>>>>>>>>> memory. If both threads try to use it or if one of the >>>>>>>>>>> threads unmap >>>>>>>>>>> part or all of the memory we will crash. >>>>>>>>>>> >>>>>>>>>>> On posix it is possible to unmap any part of a mapped chunk. >>>>>>>>>>> So, our >>>>>>>>>>> proposed solution to the race described above is to not >>>>>>>>>>> unmap all >>>>>>>>>>> memory >>>>>>>>>>> in (1) but rather just unmap the section at the start and at >>>>>>>>>>> the >>>>>>>>>>> end of >>>>>>>>>>> the chunk that we mapped to get alignment. This also removes >>>>>>>>>>> the need >>>>>>>>>>> for the loop. >>>>>>>>>>> >>>>>>>>>>> However, on Windows you can only unmap _all_ of the memory >>>>>>>>>>> that you >>>>>>>>>>> have >>>>>>>>>>> mapped. On the other hand Windows also will not allow you to >>>>>>>>>>> map over >>>>>>>>>>> other mappings, so the original code is actually safe. If we >>>>>>>>>>> keep >>>>>>>>>>> the loop. >>>>>>>>>>> >>>>>>>>>>> So, our solution is to treat this differently on Windows and >>>>>>>>>>> posix >>>>>>>>>>> platforms. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Bengt >>>>>>>>> >>>>>>>> >>>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Fri Dec 14 08:05:47 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 14 Dec 2012 11:05:47 -0500 Subject: Request for review: 7174978: NPG: Fix bactrace builder for class redefinition In-Reply-To: <50C8BBCA.3090705@oracle.com> References: <50BF9F3E.6010906@oracle.com> <50C650F0.4020405@oracle.com> <50C7B437.4080409@oracle.com> <50C8BBCA.3090705@oracle.com> Message-ID: <50CB4E5B.7020900@oracle.com> I have reworked this change to cleanup backtrace saver C heap allocated objects (and changed the name) when weak references are cleaned up, which doesn't have to happen at a full collection. There is still some performance concerns because we create these things but a better way of accounting for Method* in the Java objects is still under design discussions. Ideas welcome! open webrev at http://cr.openjdk.java.net/~coleenp/7174978_4/ bug link at http://bugs.sun.com/view_bug.do?bug_id=7174978_4 One note below. On 12/12/2012 12:15 PM, Coleen Phillimore wrote: > > Serguei, > > Thanks for reviewing this. I'm reworking it because in the > pathological case, if there are no full GC's, we wouldn't reclaim this > backtrace C heap storage. > > On 12/11/2012 5:31 PM, serguei.spitsyn at oracle.com wrote: >> Coleen, >> >> It looks good in general. >> Just some questions below. >> >> >> src/share/vm/classfile/javaClasses.cpp >> >> 1339 void java_lang_Throwable::mark_on_stack(oop throwable) { >> . . . >> 1352 if (method == NULL) return; >> >> Would it be more safe to continue instead of return? >> 1352 if (method == NULL) continue; > > This is a short circuit that the function above this also has. The > trace_next_offset will be null in this case. If I change it, I'd want > to change them both. Actually, it would have to be changed to a 'break' because we create an objArrayOop for the method array and fill it in as the backtrace is created. Finding a null means there are no more methods. I prefer to leave the returns in both places. I had a version where I wrote an iterator, which is "knows" this, but it didn't feel like saving this many lines was worth the amount of code the iterator took. Thanks, Coleen >> >> src/share/vm/classfile/backtrace.cpp >> 63 void Backtrace::do_unloading() { >> >> I guess, this can be called at a safepoint only. >> Would it make sense to place a comment or an assert? > > I added an assert because I assume this. I'm not sure if CMS gc can > unload classes without a safepoint, but this code wants to be run at a > safepoint. > >> I see you already created a new unit test for this: >> java/lang/instrument/RedefineMethodInBacktrace.sh >> > I think StefanK was going to add this test after I checked in this fix > (or has he already added it?) > > thanks, > Coleen > >> Thanks, >> Serguei >> >> >> >> >> >> >> On 12/10/12 1:15 PM, Coleen Phillimore wrote: >>> >>> I have updated this webrev to include cleanups suggested by John >>> Rose for the anonymous class fix. Please review before I add more >>> to this!! >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/7174978_2/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7174978 >>> >>> Thanks, >>> Coleen >>> >>> >>> On 12/05/2012 02:23 PM, Coleen Phillimore wrote: >>>> Summary: Save the set of backtraces to use for on stack method >>>> walking for redefine classes. >>>> >>>> I also moved metadataOnStackMark class to it's own file because >>>> it's not only used for redefine classes. Some metadata can be >>>> individually deallocated (eg. the Method* created in the relocator). >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/7174978/ >>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7174978 >>>> >>>> Ran test that will be added to the jdk/tests in >>>> java/lang/instrument/RedefineMethodInBacktrace.sh (to be checked in >>>> separately). >>>> >>>> thanks, >>>> Coleen >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121214/95264cc5/attachment.html From tim.bell at oracle.com Fri Dec 14 09:57:19 2012 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 14 Dec 2012 09:57:19 -0800 Subject: code review request for 7153050 remove crufty '_g' support In-Reply-To: <50CA65DF.9060700@oracle.com> References: <50CA2416.9070806@oracle.com> <50CA391B.3030509@oracle.com> <50CA3F9C.5050005@oracle.com> <8f2a9523-5390-41db-bf5d-6ddf8040bc8b@default> <50CA6137.8030402@oracle.com> <50CA65DF.9060700@oracle.com> Message-ID: <50CB687F.5000502@oracle.com> This looks fine to me from a build and build-infra perspective. Thanks for taking this on - code deletion is all good. Tim On 12/13/12 15:33, Daniel D. Daugherty wrote: > Trying again... now my e-mail client is complaining... > > Adding back in the other OpenJDK aliases... > > Ron's e-mail has gone off-line (no e-mail for him since 1440 MT)... > > Coleen, > > Thanks for the review! > > This bug (7153050) is just for the Makefile changes so that the > reviews are more focused. Ron has separate bugs for the other parts > of the hotspot repo that need to be fixed. I believe he is going to > attack the src/... paths in his second fix. > > Dan > > > On 12/13/12 4:13 PM, Coleen Phillimore wrote: >> >> Ron, I'm so happy this is going away. The code changed looks >> good. There are some comments in some files that refer to the old >> jvm_g.dll and libjvm_g.so. Can you remove these too? >> >> carrs% ygrep -l libjvm_g >> ./os/bsd/vm/os_bsd.cpp >> ./os/linux/vm/os_linux.cpp >> ./os/solaris/vm/os_solaris.cpp >> carrs% ygre jvm_g.dll >> ygre: Command not found. >> carrs% ygrep jvm_g.dll >> ./os/windows/vm/os_windows.cpp:// Find the full path to the current >> module, jvm.dll or jvm_g.dll >> ./share/tools/ProjectCreator/ProjectCreator.java: + >> "jvm.dll and jvm_g.dll; no trailing slash>"); >> >> Thanks, >> Coleen >> >> On 12/13/2012 03:53 PM, Ron Durbin wrote: >>> Thx again >>> -----Original Message----- >>> From: Daniel D. Daugherty >>> Sent: Thursday, December 13, 2012 1:51 PM >>> To: build-dev; serviceability-dev at openjdk.java.net; >>> hotspot-runtime-dev at openjdk.java.net; Ron Durbin >>> Subject: Re: code review request for 7153050 remove crufty '_g' support >>> >>> Serguei, >>> >>> Thanks for the fast review! >>> >>> I could swear that Ron had removed lines 41 and 45 in an earlier >>> version. Sigh... Will be fixed. >>> >>> Dan >>> >>> >>> On 12/13/12 1:22 PM, serguei.spitsyn at oracle.com wrote: >>>> Dan, >>>> >>>> It is nice fix and simplified many places. >>>> >>>> Just one minor comment: >>>> >>>> make/bsd/makefiles/dtrace.make >>>> >>>> 41 #LIBJVM_DB = libjvm_db.dylib >>>> 42 LIBJVM_DB = libjvm_db.dylib >>>> >>>> 45 #LIBJVM_DTRACE = libjvm_dtrace.dylib >>>> 46 LIBJVM_DTRACE = libjvm_dtrace.dylib >>>> >>>> The lines #41 and #45 can be removed. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 12/13/12 10:53 AM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I'm sponsoring this code review request from Ron Durbin. This change >>>>> is targeted at JDK8/HSX-25 in the RT_Baseline repo. Please make sure >>>>> you include Ron on any e-mail replies since he is not yet on the >>>>> OpenJDK aliases. >>>>> >>>>> Dan >>>>> >>>>> >>>>> Intro: >>>>> >>>>> This set of changes removes the makefile support for generation of >>>>> debug versions that follow _g semantics. >>>>> >>>>> Defect: >>>>> >>>>> 7153050 "remove crufty '_g' support from HotSpot repo" >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153050 >>>>> https://jbs.oracle.com/bugs/browse/JDK-7153050 >>>>> >>>>> >>>>> Webrev >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/for_rdurbin/7153050-webrev/0 >>>>> >>>>> Details: >>>>> >>>>> Many makefiles have been modified to remove all reference and support >>>>> for debug versions that follow _g semantics. >> > From serguei.spitsyn at oracle.com Fri Dec 14 10:17:33 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 14 Dec 2012 10:17:33 -0800 Subject: Request for review: 7174978: NPG: Fix bactrace builder for class redefinition In-Reply-To: <50CB4E5B.7020900@oracle.com> References: <50BF9F3E.6010906@oracle.com> <50C650F0.4020405@oracle.com> <50C7B437.4080409@oracle.com> <50C8BBCA.3090705@oracle.com> <50CB4E5B.7020900@oracle.com> Message-ID: <50CB6D3D.5050707@oracle.com> Coleen, It looks good. Thank you for the comments! Thanks, Serguei On 12/14/12 8:05 AM, Coleen Phillimore wrote: > > I have reworked this change to cleanup backtrace saver C heap > allocated objects (and changed the name) when weak references are > cleaned up, which doesn't have to happen at a full collection. There > is still some performance concerns because we create these things but > a better way of accounting for Method* in the Java objects is still > under design discussions. Ideas welcome! > > open webrev at http://cr.openjdk.java.net/~coleenp/7174978_4/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=7174978_4 > > One note below. > > On 12/12/2012 12:15 PM, Coleen Phillimore wrote: >> >> Serguei, >> >> Thanks for reviewing this. I'm reworking it because in the >> pathological case, if there are no full GC's, we wouldn't reclaim >> this backtrace C heap storage. >> >> On 12/11/2012 5:31 PM, serguei.spitsyn at oracle.com wrote: >>> Coleen, >>> >>> It looks good in general. >>> Just some questions below. >>> >>> >>> src/share/vm/classfile/javaClasses.cpp >>> >>> 1339 void java_lang_Throwable::mark_on_stack(oop throwable) { >>> . . . >>> 1352 if (method == NULL) return; >>> >>> Would it be more safe to continue instead of return? >>> 1352 if (method == NULL) continue; >> >> This is a short circuit that the function above this also has. The >> trace_next_offset will be null in this case. If I change it, I'd >> want to change them both. > > Actually, it would have to be changed to a 'break' because we create > an objArrayOop for the method array and fill it in as the backtrace is > created. Finding a null means there are no more methods. I prefer > to leave the returns in both places. I had a version where I wrote an > iterator, which is "knows" this, but it didn't feel like saving this > many lines was worth the amount of code the iterator took. > > Thanks, > Coleen > >>> >>> src/share/vm/classfile/backtrace.cpp >>> 63 void Backtrace::do_unloading() { >>> >>> I guess, this can be called at a safepoint only. >>> Would it make sense to place a comment or an assert? >> >> I added an assert because I assume this. I'm not sure if CMS gc can >> unload classes without a safepoint, but this code wants to be run at >> a safepoint. >> >>> I see you already created a new unit test for this: >>> java/lang/instrument/RedefineMethodInBacktrace.sh >>> >> I think StefanK was going to add this test after I checked in this >> fix (or has he already added it?) >> >> thanks, >> Coleen >> >>> Thanks, >>> Serguei >>> >>> >>> >>> >>> >>> >>> On 12/10/12 1:15 PM, Coleen Phillimore wrote: >>>> >>>> I have updated this webrev to include cleanups suggested by John >>>> Rose for the anonymous class fix. Please review before I add more >>>> to this!! >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/7174978_2/ >>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7174978 >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>>> On 12/05/2012 02:23 PM, Coleen Phillimore wrote: >>>>> Summary: Save the set of backtraces to use for on stack method >>>>> walking for redefine classes. >>>>> >>>>> I also moved metadataOnStackMark class to it's own file because >>>>> it's not only used for redefine classes. Some metadata can be >>>>> individually deallocated (eg. the Method* created in the relocator). >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/7174978/ >>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7174978 >>>>> >>>>> Ran test that will be added to the jdk/tests in >>>>> java/lang/instrument/RedefineMethodInBacktrace.sh (to be checked >>>>> in separately). >>>>> >>>>> thanks, >>>>> Coleen >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121214/bb16fcb8/attachment-0001.html From peter.levart at gmail.com Fri Dec 14 10:18:24 2012 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 14 Dec 2012 19:18:24 +0100 Subject: java.lang.instrument.Instrumentation.getObjectSize for java.lang.Class instance Message-ID: <50CB6D70.5050306@gmail.com> Hi, Does anybody know what the size returned by java.lang.instrument.Instrumentation.getObjectSize when passed a Class instance actually means? It is different for various Class instances (contains static fields of various classes?). It's also quite big (520 bytes for Object.class on 64bit JVM without compressed OOPS). If I remove some instance fields from java.lang.Class the reported size stays the same. Regards, Peter From daniel.daugherty at oracle.com Fri Dec 14 10:19:45 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 14 Dec 2012 11:19:45 -0700 Subject: code review request for 7153050 remove crufty '_g' support In-Reply-To: <50CB687F.5000502@oracle.com> References: <50CA2416.9070806@oracle.com> <50CA391B.3030509@oracle.com> <50CA3F9C.5050005@oracle.com> <8f2a9523-5390-41db-bf5d-6ddf8040bc8b@default> <50CA6137.8030402@oracle.com> <50CA65DF.9060700@oracle.com> <50CB687F.5000502@oracle.com> Message-ID: <50CB6DC1.7050404@oracle.com> Thanks Tim! Dan On 12/14/12 10:57 AM, Tim Bell wrote: > This looks fine to me from a build and build-infra perspective. > > Thanks for taking this on - code deletion is all good. > > Tim > > On 12/13/12 15:33, Daniel D. Daugherty wrote: >> Trying again... now my e-mail client is complaining... >> >> Adding back in the other OpenJDK aliases... >> >> Ron's e-mail has gone off-line (no e-mail for him since 1440 MT)... >> >> Coleen, >> >> Thanks for the review! >> >> This bug (7153050) is just for the Makefile changes so that the >> reviews are more focused. Ron has separate bugs for the other parts >> of the hotspot repo that need to be fixed. I believe he is going to >> attack the src/... paths in his second fix. >> >> Dan >> >> >> On 12/13/12 4:13 PM, Coleen Phillimore wrote: >>> >>> Ron, I'm so happy this is going away. The code changed looks >>> good. There are some comments in some files that refer to the old >>> jvm_g.dll and libjvm_g.so. Can you remove these too? >>> >>> carrs% ygrep -l libjvm_g >>> ./os/bsd/vm/os_bsd.cpp >>> ./os/linux/vm/os_linux.cpp >>> ./os/solaris/vm/os_solaris.cpp >>> carrs% ygre jvm_g.dll >>> ygre: Command not found. >>> carrs% ygrep jvm_g.dll >>> ./os/windows/vm/os_windows.cpp:// Find the full path to the current >>> module, jvm.dll or jvm_g.dll >>> ./share/tools/ProjectCreator/ProjectCreator.java: + >>> "jvm.dll and jvm_g.dll; no trailing slash>"); >>> >>> Thanks, >>> Coleen >>> >>> On 12/13/2012 03:53 PM, Ron Durbin wrote: >>>> Thx again >>>> -----Original Message----- >>>> From: Daniel D. Daugherty >>>> Sent: Thursday, December 13, 2012 1:51 PM >>>> To: build-dev; serviceability-dev at openjdk.java.net; >>>> hotspot-runtime-dev at openjdk.java.net; Ron Durbin >>>> Subject: Re: code review request for 7153050 remove crufty '_g' >>>> support >>>> >>>> Serguei, >>>> >>>> Thanks for the fast review! >>>> >>>> I could swear that Ron had removed lines 41 and 45 in an earlier >>>> version. Sigh... Will be fixed. >>>> >>>> Dan >>>> >>>> >>>> On 12/13/12 1:22 PM, serguei.spitsyn at oracle.com wrote: >>>>> Dan, >>>>> >>>>> It is nice fix and simplified many places. >>>>> >>>>> Just one minor comment: >>>>> >>>>> make/bsd/makefiles/dtrace.make >>>>> >>>>> 41 #LIBJVM_DB = libjvm_db.dylib >>>>> 42 LIBJVM_DB = libjvm_db.dylib >>>>> >>>>> 45 #LIBJVM_DTRACE = libjvm_dtrace.dylib >>>>> 46 LIBJVM_DTRACE = libjvm_dtrace.dylib >>>>> >>>>> The lines #41 and #45 can be removed. >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 12/13/12 10:53 AM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I'm sponsoring this code review request from Ron Durbin. This change >>>>>> is targeted at JDK8/HSX-25 in the RT_Baseline repo. Please make sure >>>>>> you include Ron on any e-mail replies since he is not yet on the >>>>>> OpenJDK aliases. >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> Intro: >>>>>> >>>>>> This set of changes removes the makefile support for generation of >>>>>> debug versions that follow _g semantics. >>>>>> >>>>>> Defect: >>>>>> >>>>>> 7153050 "remove crufty '_g' support from HotSpot repo" >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153050 >>>>>> https://jbs.oracle.com/bugs/browse/JDK-7153050 >>>>>> >>>>>> >>>>>> Webrev >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/for_rdurbin/7153050-webrev/0 >>>>>> >>>>>> Details: >>>>>> >>>>>> Many makefiles have been modified to remove all reference and >>>>>> support >>>>>> for debug versions that follow _g semantics. >>> >> > > > > From rednaxelafx at gmail.com Fri Dec 14 10:40:19 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Sat, 15 Dec 2012 02:40:19 +0800 Subject: java.lang.instrument.Instrumentation.getObjectSize for java.lang.Class instance In-Reply-To: <50CB6D70.5050306@gmail.com> References: <50CB6D70.5050306@gmail.com> Message-ID: Hi Peter, Which version of JDK are you using? Assuming you're using a JDK6/JDK7 version released to date, the actual implementation for j.l.i.Instrumentation.getObjectSize() is as follows: jvmtiError JvmtiEnv::GetObjectSize(jobject object, jlong* size_ptr) { oop mirror = JNIHandles::resolve_external_guard(object); NULL_CHECK(mirror, JVMTI_ERROR_INVALID_OBJECT); if (mirror->klass() == SystemDictionary::Class_klass()) { if (!java_lang_Class::is_primitive(mirror)) { mirror = java_lang_Class::as_klassOop(mirror); assert(mirror != NULL, "class for non-primitive mirror must exist"); } } *size_ptr = mirror->size() * wordSize; return JVMTI_ERROR_NONE; } /* end GetObjectSize */ So there's special handling for j.l.Class instances' size: it's reporting the size of the klassOop (the VM internal type that holds the metadata). That's why changing the number of fields in j.l.Class doesn't affect the result of getObjectSize(clazz). (BTW, the code is a bit different after NoPermGen, but the idea stays the same.) Regards, Kris On Sat, Dec 15, 2012 at 2:18 AM, Peter Levart wrote: > Hi, > > Does anybody know what the size returned by > java.lang.instrument.Instrumentation.getObjectSize when passed a Class > instance actually means? It is different for various Class instances > (contains static fields of various classes?). It's also quite big (520 bytes > for Object.class on 64bit JVM without compressed OOPS). If I remove some > instance fields from java.lang.Class the reported size stays the same. > > Regards, Peter > From daniel.daugherty at oracle.com Fri Dec 14 16:39:00 2012 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Sat, 15 Dec 2012 00:39:00 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7153050: remove crufty '_g' support from HotSpot repo makefiles Message-ID: <20121215003903.5A4F147188@hg.openjdk.java.net> Changeset: 892acf0431ef Author: dcubed Date: 2012-12-14 10:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/892acf0431ef 7153050: remove crufty '_g' support from HotSpot repo makefiles Summary: Phase 1 is removing '_g' support from the Makefiles. Reviewed-by: dcubed, sspitsyn, coleenp, tbell Contributed-by: ron.durbin at oracle.com ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/debug.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/fastdebug.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/jsig.make ! make/bsd/makefiles/jvmg.make ! make/bsd/makefiles/optimized.make ! make/bsd/makefiles/product.make ! make/bsd/makefiles/saproc.make ! make/bsd/makefiles/vm.make ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/debug.make ! make/linux/makefiles/fastdebug.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/jvmg.make ! make/linux/makefiles/optimized.make ! make/linux/makefiles/product.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/vm.make ! make/solaris/Makefile ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/debug.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/gcc.make ! make/solaris/makefiles/jsig.make ! make/solaris/makefiles/jvmg.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/vm.make ! make/windows/build.make ! make/windows/projectfiles/compiler2/ADLCompiler.dsp ! make/windows/projectfiles/tiered/ADLCompiler.dsp From coleen.phillimore at oracle.com Fri Dec 14 20:49:34 2012 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Sat, 15 Dec 2012 04:49:34 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets Message-ID: <20121215044943.3BB2F47192@hg.openjdk.java.net> Changeset: 30866cd626b0 Author: coleenp Date: 2012-12-12 11:39 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/30866cd626b0 8004883: NPG: clean up anonymous class fix Summary: Add klass_holder() to return either mirror or class_loader depending on if the class is anonymous or not. Reviewed-by: stefank, jrose ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.hpp Changeset: 18712b1caf7a Author: rkennke Date: 2012-12-12 21:40 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/18712b1caf7a 8004898: library_call.cpp build error after 7172640 with GCC 4.7.2 Summary: fix opto/library_call.cpp compilation errors Reviewed-by: twisti, coleenp ! src/share/vm/opto/library_call.cpp Changeset: 8580f22db905 Author: coleenp Date: 2012-12-14 16:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8580f22db905 Merge From alejandro.murillo at oracle.com Fri Dec 14 21:12:14 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 15 Dec 2012 05:12:14 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 10 new changesets Message-ID: <20121215051239.E848147194@hg.openjdk.java.net> Changeset: 8af7d22f1f8f Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/8af7d22f1f8f Added tag jdk8-b68 for changeset 121aa71316af ! .hgtags Changeset: 442f942757c0 Author: johnc Date: 2012-10-01 09:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/442f942757c0 8000244: G1: Ergonomically set MarkStackSize and use virtual space for global marking stack Summary: Set the value of MarkStackSize to a value based on the number of parallel marking threads with a reasonable minimum. Expand the marking stack if we have to restart marking due to an overflow up to a reasonable maximum. Allocate the underlying space for the marking stack from virtual memory. Reviewed-by: jmasa, brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/arguments.cpp Changeset: a14c5698a162 Author: johnc Date: 2012-12-07 16:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/a14c5698a162 Merge Changeset: 2aa953165ade Author: brutisso Date: 2012-12-13 10:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/2aa953165ade 8004661: Comment and function name java_lang_String::toHash is wrong Summary: renamed to hash_code Reviewed-by: dholmes, coleenp, brutisso Contributed-by: erik.helin at oracle.com ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.cpp Changeset: db8a7163c682 Author: stefank Date: 2012-12-13 09:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/db8a7163c682 8004674: Add necessary .inline.hpp files to fix non-PCH build Reviewed-by: stefank, coleenp Contributed-by: volker.simonis at gmail.com ! src/share/vm/gc_implementation/parallelScavenge/adjoiningVirtualSpaces.cpp ! src/share/vm/gc_implementation/shared/gcStats.cpp Changeset: 4459ef2189f5 Author: stefank Date: 2012-12-13 09:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/4459ef2189f5 Merge Changeset: 807f1d348f7b Author: collins Date: 2012-12-14 11:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/807f1d348f7b Merge Changeset: b6c9c0109a60 Author: amurillo Date: 2012-12-14 14:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/b6c9c0109a60 Merge Changeset: cb8a4e04bc8c Author: amurillo Date: 2012-12-14 14:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/cb8a4e04bc8c Added tag hs25-b13 for changeset b6c9c0109a60 ! .hgtags Changeset: 1f323009c3ea Author: amurillo Date: 2012-12-14 14:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/1f323009c3ea 8005036: new hotspot build - hs25-b14 Reviewed-by: jcoomes ! make/hotspot_version From peter.levart at gmail.com Fri Dec 14 23:37:56 2012 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 15 Dec 2012 08:37:56 +0100 Subject: java.lang.instrument.Instrumentation.getObjectSize for java.lang.Class instance In-Reply-To: References: <50CB6D70.5050306@gmail.com> Message-ID: <50CC28D4.8020509@gmail.com> Thanks Kris, very much. That answers my question and more. Regards, Peter On 12/14/2012 07:40 PM, Krystal Mok wrote: > Hi Peter, > > Which version of JDK are you using? Assuming you're using a JDK6/JDK7 > version released to date, the actual implementation for > j.l.i.Instrumentation.getObjectSize() is as follows: > > jvmtiError > JvmtiEnv::GetObjectSize(jobject object, jlong* size_ptr) { > oop mirror = JNIHandles::resolve_external_guard(object); > NULL_CHECK(mirror, JVMTI_ERROR_INVALID_OBJECT); > > if (mirror->klass() == SystemDictionary::Class_klass()) { > if (!java_lang_Class::is_primitive(mirror)) { > mirror = java_lang_Class::as_klassOop(mirror); > assert(mirror != NULL, "class for non-primitive mirror must exist"); > } > } > > *size_ptr = mirror->size() * wordSize; > return JVMTI_ERROR_NONE; > } /* end GetObjectSize */ > > So there's special handling for j.l.Class instances' size: it's > reporting the size of the klassOop (the VM internal type that holds > the metadata). That's why changing the number of fields in j.l.Class > doesn't affect the result of getObjectSize(clazz). > > (BTW, the code is a bit different after NoPermGen, but the idea stays the same.) > > Regards, > Kris > > On Sat, Dec 15, 2012 at 2:18 AM, Peter Levart wrote: >> Hi, >> >> Does anybody know what the size returned by >> java.lang.instrument.Instrumentation.getObjectSize when passed a Class >> instance actually means? It is different for various Class instances >> (contains static fields of various classes?). It's also quite big (520 bytes >> for Object.class on 64bit JVM without compressed OOPS). If I remove some >> instance fields from java.lang.Class the reported size stays the same. >> >> Regards, Peter >> From david.holmes at oracle.com Sun Dec 16 18:01:18 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Dec 2012 12:01:18 +1000 Subject: java.lang.instrument.Instrumentation.getObjectSize for java.lang.Class instance In-Reply-To: References: <50CB6D70.5050306@gmail.com> Message-ID: <50CE7CEE.70900@oracle.com> On 15/12/2012 4:40 AM, Krystal Mok wrote: > Hi Peter, > > Which version of JDK are you using? Assuming you're using a JDK6/JDK7 > version released to date, the actual implementation for > j.l.i.Instrumentation.getObjectSize() is as follows: > > jvmtiError > JvmtiEnv::GetObjectSize(jobject object, jlong* size_ptr) { > oop mirror = JNIHandles::resolve_external_guard(object); > NULL_CHECK(mirror, JVMTI_ERROR_INVALID_OBJECT); > > if (mirror->klass() == SystemDictionary::Class_klass()) { > if (!java_lang_Class::is_primitive(mirror)) { > mirror = java_lang_Class::as_klassOop(mirror); > assert(mirror != NULL, "class for non-primitive mirror must exist"); > } > } > > *size_ptr = mirror->size() * wordSize; > return JVMTI_ERROR_NONE; > } /* end GetObjectSize */ > > So there's special handling for j.l.Class instances' size: it's > reporting the size of the klassOop (the VM internal type that holds > the metadata). That's why changing the number of fields in j.l.Class > doesn't affect the result of getObjectSize(clazz). I had slightly different variants in the testing code I previously put together for JEP-149 - see below. But the key thing is that you need two different API's here: one for regular objects and one for Class instances. To that end Instrumentation.getObjectSize is not that useful for Class instances, but I think the implementation chosen is not what people would generally want when asking about Class sizes. David +// Return the size of an instance of cls +JVM_ENTRY(jlong, JVM_Sizeof(JNIEnv *env, jclass ignored, jclass cls)) + JVMWrapper("JVM_Sizeof"); + // Check if we have null pointers + if (cls == NULL) { + THROW_0(vmSymbols::java_lang_NullPointerException()); + } + oop mirror = JNIHandles::resolve_non_null(cls); + + // exclude primitives and arrays + if (java_lang_Class::is_primitive(mirror) /*|| is array */) { + THROW_0(vmSymbols::java_lang_IllegalArgumentException()); + } + klassOop klass = java_lang_Class::as_klassOop(mirror); + return align_object_size(instanceKlass::cast(klass)->size_helper()) << LogHeapWordSize; +JVM_END + +// Return the size of cls - which is the base size for any instance +// of java.lang.Class plus any static fields for this particular Class +JVM_ENTRY(jlong, JVM_SizeofClass(JNIEnv *env, jclass ignored, jclass cls)) + JVMWrapper("JVM_SizeofClass"); + // Check if we have null pointers + if (cls == NULL) { + THROW_0(vmSymbols::java_lang_NullPointerException()); + } + oop mirror = JNIHandles::resolve_non_null(cls); + return mirror->size() << LogHeapWordSize; +JVM_END From rednaxelafx at gmail.com Sun Dec 16 18:20:40 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Mon, 17 Dec 2012 10:20:40 +0800 Subject: java.lang.instrument.Instrumentation.getObjectSize for java.lang.Class instance In-Reply-To: <50CE7CEE.70900@oracle.com> References: <50CB6D70.5050306@gmail.com> <50CE7CEE.70900@oracle.com> Message-ID: On Mon, Dec 17, 2012 at 10:01 AM, David Holmes wrote: > > But the key thing is that you need two different API's here: one for regular > objects and one for Class instances. To that end > Instrumentation.getObjectSize is not that useful for Class instances, but I > think the implementation chosen is not what people would generally want when > asking about Class sizes. > Yes, I totally agree with having Instrumentation.getObjectSize return a more intuitive value for Class sizes, and perhaps adding another dedicated method for those that need the current behavior for Class. The JavaDoc [1] for this method is quite loose. Does anybody know the history of why there was special handling for Class in the first place? Regards, Kris [1]: http://docs.oracle.com/javase/7/docs/api/java/lang/instrument/Instrumentation.html#getObjectSize(java.lang.Object) > David From david.holmes at oracle.com Sun Dec 16 18:57:47 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Dec 2012 12:57:47 +1000 Subject: java.lang.instrument.Instrumentation.getObjectSize for java.lang.Class instance In-Reply-To: References: <50CB6D70.5050306@gmail.com> <50CE7CEE.70900@oracle.com> Message-ID: <50CE8A2B.20508@oracle.com> On 17/12/2012 12:20 PM, Krystal Mok wrote: > On Mon, Dec 17, 2012 at 10:01 AM, David Holmes wrote: > >> >> But the key thing is that you need two different API's here: one for regular >> objects and one for Class instances. To that end >> Instrumentation.getObjectSize is not that useful for Class instances, but I >> think the implementation chosen is not what people would generally want when >> asking about Class sizes. >> > > Yes, I totally agree with having Instrumentation.getObjectSize return > a more intuitive value for Class sizes, and perhaps adding another > dedicated method for those that need the current behavior for Class. > > The JavaDoc [1] for this method is quite loose. Does anybody know the > history of why there was special handling for Class in the first > place? I can only guess that someone was trying to deal with the fact that you really want to know the size of the class instance for a given Class (ie including the static fields). I'm not 100% sure what it actually does return. The whole setup with class mirrors etc was rather confusing to me pre-PermGenRemoval. But post NPG I don't know what to use to get the "right" size info. David ----- > Regards, > Kris > > [1]: http://docs.oracle.com/javase/7/docs/api/java/lang/instrument/Instrumentation.html#getObjectSize(java.lang.Object) > >> David From bengt.rutisson at oracle.com Sun Dec 16 23:36:15 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 17 Dec 2012 08:36:15 +0100 Subject: Request for review (s): 7173959 : Jvm crashed during coherence exabus (tmb) testing In-Reply-To: <50CB4A98.7070008@oracle.com> References: <50C978BE.8040405@oracle.com> <50C984DA.1070400@oracle.com> <50C9A7AD.3030307@oracle.com> <50C9AFE9.2080601@oracle.com> <50C9B2EC.5090008@oracle.com> <50C9D0F1.9040501@oracle.com> <50CA750A.6040007@oracle.com> <50CAE384.6070003@oracle.com> <50CAE7F6.2020609@oracle.com> <50CB27C0.6050708@oracle.com> <50CB44AE.9040509@oracle.com> <50CB4A98.7070008@oracle.com> Message-ID: <50CECB6F.3050806@oracle.com> Hi Coleen, Thanks for suggesting the comments. I added them to the os files. David, Coleen, Zhengyu and Vitaly, Thanks for the reviews! All set to push this now. Bengt On 12/14/12 4:49 PM, Coleen Phillimore wrote: > On 12/14/2012 10:24 AM, Bengt Rutisson wrote: >> >> Hi Coleen, >> >> Thanks for looking at this! >> >> On 12/14/12 2:21 PM, Coleen Phillimore wrote: >>> On 12/14/2012 3:48 AM, Bengt Rutisson wrote: >>>> >>>> Hi again Runtime team, >>>> >>>> I need one more review for this change. It is a P1 bug with a >>>> fairly small change. Any takers? >>>> >>>> Latest webrev based on comments from David Holmes and Vitaly >>>> Davidovich: >>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.03/ >>> >>> Hi Bengt, This code looks good to me but I asked Zhengyu to check >>> it to make sure it doesn't have any bad NMT interactions. >> >> Thanks! He just replied. >>> >>> Also the writeup is great below, but can you add these comments to >>> the code in os_posix.cpp. I had to go back to the email to figure >>> out why you are doing this. >> >> I'm not really sure where to put such a comment. I think the writeup >> I did mostly makes sense when you compare it to the old code. Also, >> the affected code is in the middle of ReservedSpace::initialize(). I >> think it would look strange with a large comment there. In the >> os_posix/windows files the comment does not make much sense in my >> opinion. >> >> I could add a comment in ReservedSpace::initialize() that refers to >> the Jira issue. But I'm not a big fan of such comments. > > I agree we shouldn't point to bugs in the source code. A comment at > the top of the os_posix version of this function that paraphrases > below why you are not re-reserving in a loop like windows would be > sufficient. That trimming memory at either end is allowed on > posix-like os's and is thread-safe, something like: > > // Multiple threads can race in this code, and can remap over each > other with MAP_FIXED, so on posix, unmap the section > // at the start and at the end of the chunk that we mapped to get > requested alignment. > > os_windows: > > // Multiple threads can race in this code but it's not possible to > remap with a section of virtual space to get requested alignment, like > posix-like os's. > // Windows prevents multiple thread from remapping over each other so > this loop is thread-safe. > > I just want something to document why they are different. > >> >>> >>> I don't understand why there are racing threads. I thought all the >>> heap space was initialized at the start of the vm when it is single >>> threaded? >> >> I would have to look up exactly when we set up the heap to see if we >> are single threaded at that point. The issue we saw was with setting >> up the GC bitmaps. At that point we are multithreaded and we are for >> example mapping memory for the GC worker threads at the same time. > > I see. > > Coleen >> >> >> Thanks again for looking at this! >> Bengt >> >>> >>> thanks, >>> Coleen >>> >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>> On 12/14/12 9:29 AM, Bengt Rutisson wrote: >>>>> >>>>> Hi David, >>>>> >>>>> On 12/14/12 1:38 AM, David Holmes wrote: >>>>>> Hi Bengt, >>>>>> >>>>>> That all sounds good to me. >>>>>> >>>>>> With regard to potential overflow perhaps a simple check that >>>>>> extra_size does not overflow? If that is true and extra_base is >>>>>> not null then I think all the other calculations must be valid. >>>>> >>>>> Yes, that makes sense. I'll add an overflow check for the extra_size. >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 13/12/2012 10:58 PM, Bengt Rutisson wrote: >>>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>> Updated webrev: >>>>>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.02/ >>>>>>> >>>>>>> I moved the alignment of "size" back into >>>>>>> ReservedSpace::initialize() >>>>>>> since we actually store the size in an instance variable >>>>>>> (_size), so I >>>>>>> think it is a bit risky to just do the align_up in >>>>>>> os::reserve_memory_aligned(). We probably want the instance >>>>>>> variables >>>>>>> _size and _alignment in ReservedSpace to be consistent. >>>>>>> >>>>>>> I added an assert in os::reserve_memory_aligned() to verify that >>>>>>> the >>>>>>> size is correctly aligned. I also added the assert you suggested to >>>>>>> check that alignment is page size aligned. >>>>>>> >>>>>>> Bengt >>>>>>> >>>>>>> On 12/13/12 11:50 AM, David Holmes wrote: >>>>>>>> On 13/12/2012 8:37 PM, Bengt Rutisson wrote: >>>>>>>>> >>>>>>>>> Hi again, >>>>>>>>> >>>>>>>>> Updated webrev: >>>>>>>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.01/ >>>>>>>>> >>>>>>>>> I removed the comment and the alignment. >>>>>>>>> >>>>>>>>> But I did not add an assert just yet. >>>>>>>>> >>>>>>>>> At the top of ReservedSpace::initialize() we have this code: >>>>>>>>> >>>>>>>>> const size_t granularity = os::vm_allocation_granularity(); >>>>>>>>> assert((size & (granularity - 1)) == 0, >>>>>>>>> "size not aligned to os::vm_allocation_granularity()"); >>>>>>>>> assert((alignment & (granularity - 1)) == 0, >>>>>>>>> "alignment not aligned to os::vm_allocation_granularity()"); >>>>>>>>> >>>>>>>>> >>>>>>>>> Where os::vm_allocation_granularity() is implemented as page >>>>>>>>> size on all >>>>>>>>> platforms except Windows. There we look it up from the Windows >>>>>>>>> API. I >>>>>>>>> assume that is a page size too, but since the Windows code in >>>>>>>>> our patch >>>>>>>>> does not unmap based on the alignment it should be safe either >>>>>>>>> way. >>>>>>>>> >>>>>>>>> Is this assert enough or would you like me to add an assert >>>>>>>>> closer to >>>>>>>>> the code block were I did the changes? >>>>>>>> >>>>>>>> As this is a separate method now I think an assert in the method >>>>>>>> itself would not go astray. >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Bengt >>>>>>>>> >>>>>>>>> >>>>>>>>> On 12/13/12 11:02 AM, Bengt Rutisson wrote: >>>>>>>>>> >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> Thanks for looking at this! >>>>>>>>>> >>>>>>>>>> On 12/13/12 8:33 AM, David Holmes wrote: >>>>>>>>>>> Hi Bengt, >>>>>>>>>>> >>>>>>>>>>> This has to be one of the absolute best review requests I've >>>>>>>>>>> ever >>>>>>>>>>> read :) Thank you. >>>>>>>>>> >>>>>>>>>> Wow! Thanks! :) >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Just a couple of queries. >>>>>>>>>>> >>>>>>>>>>> os_posix.cpp: >>>>>>>>>>> >>>>>>>>>>> Love the diagram :) >>>>>>>>>> >>>>>>>>>> It was Mikael's way of making sure we got it right. >>>>>>>>>> >>>>>>>>>>> I'm assuming that "alignment" has to be >= the underlying >>>>>>>>>>> page size, >>>>>>>>>>> and in fact must be a multiple of the underlying page size ? >>>>>>>>>>> (As I >>>>>>>>>>> assume you can only unmap whole numbers of pages). If so >>>>>>>>>>> does that >>>>>>>>>>> need to be checked somewhere? >>>>>>>>>> >>>>>>>>>> Good point. I'll add an assert to check that. >>>>>>>>>> >>>>>>>>>>> In virtualSpace.cpp: >>>>>>>>>>> >>>>>>>>>>> // Reserve size large enough to do manual alignment and >>>>>>>>>>> // increase size to a multiple of the desired alignment >>>>>>>>>>> size = align_size_up(size, alignment); >>>>>>>>>>> ! base = os::reserve_memory_aligned(size, alignment); >>>>>>>>>>> >>>>>>>>>>> The comment doesn't seem necessary now, and the >>>>>>>>>>> align_size_up seems >>>>>>>>>>> redundant. >>>>>>>>>> >>>>>>>>>> You are right. I'll remove the comment and the alignment. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Bengt >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> On 13/12/2012 4:42 PM, Bengt Rutisson wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> Could I have a couple of reviews for this change? >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> This is for a bug originally reported by the Coherence team: >>>>>>>>>>>> >>>>>>>>>>>> 7173959 : Jvm crashed during coherence exabus (tmb) testing >>>>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173959 >>>>>>>>>>>> >>>>>>>>>>>> The original analysis and proposed fix was done by Mikael >>>>>>>>>>>> Gerdin >>>>>>>>>>>> and me >>>>>>>>>>>> together. I'll handle the webrev and push since Mikael is >>>>>>>>>>>> on vacation >>>>>>>>>>>> starting today. But Mikael did a great job tracking down >>>>>>>>>>>> this very >>>>>>>>>>>> difficult bug, so he should have a large part of the credit >>>>>>>>>>>> for this >>>>>>>>>>>> bug >>>>>>>>>>>> fix, >>>>>>>>>>>> >>>>>>>>>>>> Description from the CR: >>>>>>>>>>>> >>>>>>>>>>>> The reason that we crash is due to how we re-map memory >>>>>>>>>>>> when we >>>>>>>>>>>> want to >>>>>>>>>>>> align it for large pages in ReservedSpace::initialize(). >>>>>>>>>>>> >>>>>>>>>>>> Here is what happens: >>>>>>>>>>>> >>>>>>>>>>>> The reservation of memory is split up to a few steps. When >>>>>>>>>>>> we want a >>>>>>>>>>>> chunk of memory with large pages we first just reserve some >>>>>>>>>>>> memory >>>>>>>>>>>> large >>>>>>>>>>>> enough for what we need. Then we realize that we want large >>>>>>>>>>>> pages, >>>>>>>>>>>> so we >>>>>>>>>>>> want to re-map the reserved memory to use large pages. But >>>>>>>>>>>> since this >>>>>>>>>>>> requires that we have a large-page-aligned memory chunk we may >>>>>>>>>>>> have to >>>>>>>>>>>> fix the recently reserved memory chunk up a bit. >>>>>>>>>>>> >>>>>>>>>>>> We do this in ReservedSpace::initialize() by first >>>>>>>>>>>> releasing the >>>>>>>>>>>> memory >>>>>>>>>>>> we just reserved. Then requesting more memory than we actually >>>>>>>>>>>> need to >>>>>>>>>>>> make sure that we have enough space to do manual large page >>>>>>>>>>>> alignment. >>>>>>>>>>>> After we have gotten this memory we figure out a nicely >>>>>>>>>>>> aligned start >>>>>>>>>>>> address. We then release the memory again and then reserve >>>>>>>>>>>> just >>>>>>>>>>>> enough >>>>>>>>>>>> memory but using the aligned start address as a fixed >>>>>>>>>>>> address to make >>>>>>>>>>>> sure that we get the memory we wanted in an aligned way. >>>>>>>>>>>> >>>>>>>>>>>> This is done in a loop to make sure that we eventually get >>>>>>>>>>>> some >>>>>>>>>>>> memory. >>>>>>>>>>>> The interesting code looks like this: >>>>>>>>>>>> >>>>>>>>>>>> do { >>>>>>>>>>>> char* extra_base = os::reserve_memory(extra_size, NULL, >>>>>>>>>>>> alignment); >>>>>>>>>>>> if (extra_base == NULL) return; >>>>>>>>>>>> // Do manual alignement >>>>>>>>>>>> base = (char*) align_size_up((uintptr_t) extra_base, >>>>>>>>>>>> alignment); >>>>>>>>>>>> assert(base >= extra_base, "just checking"); >>>>>>>>>>>> // Re-reserve the region at the aligned base address. >>>>>>>>>>>> os::release_memory(extra_base, extra_size); // (1) >>>>>>>>>>>> base = os::reserve_memory(size, base); // (2) >>>>>>>>>>>> } while (base == NULL); >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> There is a race here between releasing the memory in (1) and >>>>>>>>>>>> re-reserving it in (2). But the loop is supposed to handle >>>>>>>>>>>> this race. >>>>>>>>>>>> >>>>>>>>>>>> The problem is that on posix platforms you can remap the >>>>>>>>>>>> same memory >>>>>>>>>>>> area several times. The call in (2) will use mmap with >>>>>>>>>>>> MAP_FIXED. >>>>>>>>>>>> This >>>>>>>>>>>> means that the OS will think that you know exactly what you >>>>>>>>>>>> are >>>>>>>>>>>> doing. >>>>>>>>>>>> So, if part of the memory has been mapped already by the >>>>>>>>>>>> process it >>>>>>>>>>>> will >>>>>>>>>>>> just go ahead and reuse that memory. >>>>>>>>>>>> >>>>>>>>>>>> This means that if we are having multiple threads that do >>>>>>>>>>>> mmap. We >>>>>>>>>>>> can >>>>>>>>>>>> end up with a situation where we release our mapping in >>>>>>>>>>>> (1). Then >>>>>>>>>>>> another thread comes in and maps part of the memory that we >>>>>>>>>>>> used to >>>>>>>>>>>> have. Then we remap over that memory again in (2) with >>>>>>>>>>>> MAP_FIXED. >>>>>>>>>>>> Now we >>>>>>>>>>>> have a situation where two threads in our process have >>>>>>>>>>>> mapped the >>>>>>>>>>>> same >>>>>>>>>>>> memory. If both threads try to use it or if one of the >>>>>>>>>>>> threads unmap >>>>>>>>>>>> part or all of the memory we will crash. >>>>>>>>>>>> >>>>>>>>>>>> On posix it is possible to unmap any part of a mapped >>>>>>>>>>>> chunk. So, our >>>>>>>>>>>> proposed solution to the race described above is to not >>>>>>>>>>>> unmap all >>>>>>>>>>>> memory >>>>>>>>>>>> in (1) but rather just unmap the section at the start and >>>>>>>>>>>> at the >>>>>>>>>>>> end of >>>>>>>>>>>> the chunk that we mapped to get alignment. This also >>>>>>>>>>>> removes the need >>>>>>>>>>>> for the loop. >>>>>>>>>>>> >>>>>>>>>>>> However, on Windows you can only unmap _all_ of the memory >>>>>>>>>>>> that you >>>>>>>>>>>> have >>>>>>>>>>>> mapped. On the other hand Windows also will not allow you >>>>>>>>>>>> to map over >>>>>>>>>>>> other mappings, so the original code is actually safe. If >>>>>>>>>>>> we keep >>>>>>>>>>>> the loop. >>>>>>>>>>>> >>>>>>>>>>>> So, our solution is to treat this differently on Windows >>>>>>>>>>>> and posix >>>>>>>>>>>> platforms. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Bengt >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >>> >> > From bengt.rutisson at oracle.com Mon Dec 17 00:38:01 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 17 Dec 2012 09:38:01 +0100 Subject: Request for review (s): 7173959 : Jvm crashed during coherence exabus (tmb) testing In-Reply-To: References: <50C978BE.8040405@oracle.com> <50C984DA.1070400@oracle.com> <50C9A7AD.3030307@oracle.com> <50C9AFE9.2080601@oracle.com> <50C9B2EC.5090008@oracle.com> <50C9D0F1.9040501@oracle.com> <50CA750A.6040007@oracle.com> <50CAE384.6070003@oracle.com> <50CAE7F6.2020609@oracle.com> Message-ID: <50CED9E9.1020709@oracle.com> Hi Vitaly, On 12/14/12 3:46 PM, Vitaly Davidovich wrote: > > Hi Bengt, > > I'd add an assert(begin_offset < end_offset, "sanity") as well but up > to you. Looks good. > Actually begin_offset and end_offset are the number of bytes we want to umap. So, it is quite possible for end_offset to be less than begin_offset. Bengt > Thanks > > Sent from my phone > > On Dec 14, 2012 3:49 AM, "Bengt Rutisson" > wrote: > > > Hi again Runtime team, > > I need one more review for this change. It is a P1 bug with a > fairly small change. Any takers? > > Latest webrev based on comments from David Holmes and Vitaly > Davidovich: > http://cr.openjdk.java.net/~brutisso/7173959/webrev.03/ > > > Thanks, > Bengt > > > On 12/14/12 9:29 AM, Bengt Rutisson wrote: > > > Hi David, > > On 12/14/12 1:38 AM, David Holmes wrote: > > Hi Bengt, > > That all sounds good to me. > > With regard to potential overflow perhaps a simple check > that extra_size does not overflow? If that is true and > extra_base is not null then I think all the other > calculations must be valid. > > > Yes, that makes sense. I'll add an overflow check for the > extra_size. > > Thanks, > Bengt > > > Thanks, > David > > On 13/12/2012 10:58 PM, Bengt Rutisson wrote: > > > Hi David, > > Updated webrev: > http://cr.openjdk.java.net/~brutisso/7173959/webrev.02/ > > I moved the alignment of "size" back into > ReservedSpace::initialize() > since we actually store the size in an instance > variable (_size), so I > think it is a bit risky to just do the align_up in > os::reserve_memory_aligned(). We probably want the > instance variables > _size and _alignment in ReservedSpace to be consistent. > > I added an assert in os::reserve_memory_aligned() to > verify that the > size is correctly aligned. I also added the assert you > suggested to > check that alignment is page size aligned. > > Bengt > > On 12/13/12 11:50 AM, David Holmes wrote: > > On 13/12/2012 8:37 PM, Bengt Rutisson wrote: > > > Hi again, > > Updated webrev: > http://cr.openjdk.java.net/~brutisso/7173959/webrev.01/ > > > I removed the comment and the alignment. > > But I did not add an assert just yet. > > At the top of ReservedSpace::initialize() we > have this code: > > const size_t granularity = > os::vm_allocation_granularity(); > assert((size & (granularity - 1)) == 0, > "size not aligned to > os::vm_allocation_granularity()"); > assert((alignment & (granularity - 1)) == 0, > "alignment not aligned to > os::vm_allocation_granularity()"); > > > Where os::vm_allocation_granularity() is > implemented as page size on all > platforms except Windows. There we look it up > from the Windows API. I > assume that is a page size too, but since the > Windows code in our patch > does not unmap based on the alignment it > should be safe either way. > > Is this assert enough or would you like me to > add an assert closer to > the code block were I did the changes? > > > As this is a separate method now I think an assert > in the method > itself would not go astray. > > David > ----- > > Thanks, > Bengt > > > On 12/13/12 11:02 AM, Bengt Rutisson wrote: > > > Hi David, > > Thanks for looking at this! > > On 12/13/12 8:33 AM, David Holmes wrote: > > Hi Bengt, > > This has to be one of the absolute > best review requests I've ever > read :) Thank you. > > > Wow! Thanks! :) > > > Just a couple of queries. > > os_posix.cpp: > > Love the diagram :) > > > It was Mikael's way of making sure we got > it right. > > I'm assuming that "alignment" has to > be >= the underlying page size, > and in fact must be a multiple of the > underlying page size ? (As I > assume you can only unmap whole > numbers of pages). If so does that > need to be checked somewhere? > > > Good point. I'll add an assert to check that. > > In virtualSpace.cpp: > > // Reserve size large enough to do > manual alignment and > // increase size to a multiple of the > desired alignment > size = align_size_up(size, alignment); > ! base = > os::reserve_memory_aligned(size, > alignment); > > The comment doesn't seem necessary > now, and the align_size_up seems > redundant. > > > You are right. I'll remove the comment and > the alignment. > > Thanks, > Bengt > > > Thanks, > David > > On 13/12/2012 4:42 PM, Bengt Rutisson > wrote: > > > Hi all, > > Could I have a couple of reviews > for this change? > > http://cr.openjdk.java.net/~brutisso/7173959/webrev.00/ > > > This is for a bug originally > reported by the Coherence team: > > 7173959 : Jvm crashed during > coherence exabus (tmb) testing > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173959 > > The original analysis and proposed > fix was done by Mikael Gerdin > and me > together. I'll handle the webrev > and push since Mikael is on vacation > starting today. But Mikael did a > great job tracking down this very > difficult bug, so he should have a > large part of the credit for this > bug > fix, > > Description from the CR: > > The reason that we crash is due to > how we re-map memory when we > want to > align it for large pages in > ReservedSpace::initialize(). > > Here is what happens: > > The reservation of memory is split > up to a few steps. When we want a > chunk of memory with large pages > we first just reserve some memory > large > enough for what we need. Then we > realize that we want large pages, > so we > want to re-map the reserved memory > to use large pages. But since this > requires that we have a > large-page-aligned memory chunk we may > have to > fix the recently reserved memory > chunk up a bit. > > We do this in > ReservedSpace::initialize() by > first releasing the > memory > we just reserved. Then requesting > more memory than we actually > need to > make sure that we have enough > space to do manual large page > alignment. > After we have gotten this memory > we figure out a nicely aligned start > address. We then release the > memory again and then reserve just > enough > memory but using the aligned start > address as a fixed address to make > sure that we get the memory we > wanted in an aligned way. > > This is done in a loop to make > sure that we eventually get some > memory. > The interesting code looks like this: > > do { > char* extra_base = > os::reserve_memory(extra_size, > NULL, alignment); > if (extra_base == NULL) return; > // Do manual alignement > base = (char*) > align_size_up((uintptr_t) > extra_base, alignment); > assert(base >= extra_base, "just > checking"); > // Re-reserve the region at the > aligned base address. > os::release_memory(extra_base, > extra_size); // (1) > base = os::reserve_memory(size, > base); // (2) > } while (base == NULL); > > > There is a race here between > releasing the memory in (1) and > re-reserving it in (2). But the > loop is supposed to handle this race. > > The problem is that on posix > platforms you can remap the same > memory > area several times. The call in > (2) will use mmap with MAP_FIXED. > This > means that the OS will think that > you know exactly what you are > doing. > So, if part of the memory has been > mapped already by the process it > will > just go ahead and reuse that memory. > > This means that if we are having > multiple threads that do mmap. We > can > end up with a situation where we > release our mapping in (1). Then > another thread comes in and maps > part of the memory that we used to > have. Then we remap over that > memory again in (2) with MAP_FIXED. > Now we > have a situation where two threads > in our process have mapped the > same > memory. If both threads try to use > it or if one of the threads unmap > part or all of the memory we will > crash. > > On posix it is possible to unmap > any part of a mapped chunk. So, our > proposed solution to the race > described above is to not unmap all > memory > in (1) but rather just unmap the > section at the start and at the > end of > the chunk that we mapped to get > alignment. This also removes the need > for the loop. > > However, on Windows you can only > unmap _all_ of the memory that you > have > mapped. On the other hand Windows > also will not allow you to map over > other mappings, so the original > code is actually safe. If we keep > the loop. > > So, our solution is to treat this > differently on Windows and posix > platforms. > > > Thanks, > Bengt > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121217/02ce114a/attachment-0001.html From frederic.parain at oracle.com Mon Dec 17 03:26:55 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 17 Dec 2012 12:26:55 +0100 Subject: RFR: 8004095: Add support for JMX interface to Diagnostic Framework and Commands, Message-ID: <50CF017F.5050502@oracle.com> Hi, Please review the following change for CR 8004095. This changeset is the JDK side of two parts project. The goal of this feature is to allow remote invocations of Diagnostic Commands via JMX. Diagnostic Commands are actually invoked from the jcmd tool, which is a local tool using the attachAPI. It was not possible to remotely invoke these commands. This project creates a new PlatformMBean, remotely accessible via the Platform MBean Server, providing access to Diagnostic Commands too. The JDK side of this project, including the new Platform MBean, is covered in CR 7150256. This changeset contains the modifications in the JVM to support the new API. There are two types of modifications: 1 - extension of the diagnostic command framework 2 - extension of existing diagnostic commands Modifications of the framework: The first modification of the framework is the mechanism to communicate with the DiagnosticCommandsMBean defined in the JDK. Communications are performed via the jmm.h interface. In addition to a few new entries in the jmm structure, several data structures have been declared to export diagnostic command meta-data to the JDK. The second modification of the framework consists in an export control mechanism. Diagnostic Commands are executed inside the JVM, they have access to critical information and can perform very disruptive operations. Even if the DiagnosticCommandsMBean includes some security checks using Java Permissions, it sometime better to simply make a diagnostic command not available from the JMX API. The export control mechanism gives to diagnostic command developers full control on how the command will be accessible. When a diagnostic command is registered to the framework, a list of interfaces allowed to export this command must be provided. The current implementation defines three interfaces: JVM internal, attachAPI and JMX. A diagnostic command can be exported to any combination of these interfaces. Modifications of existing diagnostic commands: Because this feature allows remote invocations, it is important to be able to control who is invoking and what is invoked. Java Permission checks have been introduced in the DiagnosticCommandsMBean and are performed before a remote invocation request is forwarded to the JVM. So, each Diagnostic Command can require a Java Permission to be invoked remotely. Note that invocations from inside the JVM or via the attachAPI do not check these permissions. Invocations from inside the JVM are considered trusted, and the attachAPI has its own security model based on EUID/ EGID. Some existing diagnostic commands that have been identified as begin potentially harmful have been extended to specify the Java Permission required for their execution. The webrev is here: http://cr.openjdk.java.net/~fparain/8004095/webrev.00/ Thanks, Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From staffan.larsen at oracle.com Mon Dec 17 04:27:41 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 17 Dec 2012 13:27:41 +0100 Subject: RFR: 8004095: Add support for JMX interface to Diagnostic Framework and Commands, In-Reply-To: <50CF017F.5050502@oracle.com> References: <50CF017F.5050502@oracle.com> Message-ID: <32B19E42-82A3-424C-85DA-977815A230CD@oracle.com> Frederic, Looks good! Just a few small comments below. diagnosticCommand.cpp:255: When DisableExplicitGC is set, it would be great if the SystemGC command printed on error message so that the caller knows that the GC didn't happen as intended. I also think we should add an entry to GCCause for GCs caused by the DCmd (but that isn't new to this change). diagnosticFramework.hpp:423: nit: misspelled "enabled" in the method name diagnosticFramework.cpp:435: seems some testing code has slipped in diagnosticFramework.cpp:509: nit: missing spaces around '&'. (Consider adding () to clarify the precedence.) Thanks, /Staffan On 17 dec 2012, at 12:26, Frederic Parain wrote: > Hi, > > Please review the following change for CR 8004095. > > This changeset is the JDK side of two parts project. > > The goal of this feature is to allow remote invocations of > Diagnostic Commands via JMX. > > > Diagnostic Commands are actually invoked from the jcmd > tool, which is a local tool using the attachAPI. It was > not possible to remotely invoke these commands. > This project creates a new PlatformMBean, remotely > accessible via the Platform MBean Server, providing > access to Diagnostic Commands too. > > The JDK side of this project, including the new > Platform MBean, is covered in CR 7150256. > > This changeset contains the modifications in the > JVM to support the new API. > > There are two types of modifications: > 1 - extension of the diagnostic command framework > 2 - extension of existing diagnostic commands > > Modifications of the framework: > > The first modification of the framework is the mechanism > to communicate with the DiagnosticCommandsMBean defined > in the JDK. Communications are performed via the jmm.h > interface. In addition to a few new entries in the > jmm structure, several data structures have been declared > to export diagnostic command meta-data to the JDK. > > The second modification of the framework consists in an > export control mechanism. Diagnostic Commands are executed > inside the JVM, they have access to critical information > and can perform very disruptive operations. Even if the > DiagnosticCommandsMBean includes some security checks > using Java Permissions, it sometime better to simply > make a diagnostic command not available from the JMX > API. The export control mechanism gives to diagnostic > command developers full control on how the command will > be accessible. When a diagnostic command is registered > to the framework, a list of interfaces allowed to > export this command must be provided. The current > implementation defines three interfaces: JVM internal, > attachAPI and JMX. A diagnostic command can be > exported to any combination of these interfaces. > > Modifications of existing diagnostic commands: > > Because this feature allows remote invocations, it > is important to be able to control who is invoking > and what is invoked. Java Permission checks have > been introduced in the DiagnosticCommandsMBean and > are performed before a remote invocation request > is forwarded to the JVM. So, each Diagnostic Command > can require a Java Permission to be invoked remotely. > Note that invocations from inside the JVM or via the > attachAPI do not check these permissions. Invocations > from inside the JVM are considered trusted, and the > attachAPI has its own security model based on EUID/ > EGID. > Some existing diagnostic commands that have been > identified as begin potentially harmful have been > extended to specify the Java Permission required > for their execution. > > The webrev is here: > > http://cr.openjdk.java.net/~fparain/8004095/webrev.00/ > > Thanks, > > Fred > > > > > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > Email: Frederic.Parain at Oracle.com > From frederic.parain at oracle.com Mon Dec 17 07:01:04 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 17 Dec 2012 16:01:04 +0100 Subject: RFR: 8004095: Add support for JMX interface to Diagnostic Framework and Commands, In-Reply-To: <32B19E42-82A3-424C-85DA-977815A230CD@oracle.com> References: <50CF017F.5050502@oracle.com> <32B19E42-82A3-424C-85DA-977815A230CD@oracle.com> Message-ID: <50CF33B0.6030301@oracle.com> Staffan, Thank you for the review, I've fixed the code to address all the issue you reported. The new webrev is here: http://cr.openjdk.java.net/~fparain/8004095/webrev.01/ Regards, Fred On 12/17/12 01:27 PM, Staffan Larsen wrote: > Frederic, > > Looks good! Just a few small comments below. > > diagnosticCommand.cpp:255: When DisableExplicitGC is set, it would be great if the SystemGC command printed on error message so that the caller knows that the GC didn't happen as intended. I also think we should add an entry to GCCause for GCs caused by the DCmd (but that isn't new to this change). > > diagnosticFramework.hpp:423: nit: misspelled "enabled" in the method name > > diagnosticFramework.cpp:435: seems some testing code has slipped in > > diagnosticFramework.cpp:509: nit: missing spaces around '&'. (Consider adding () to clarify the precedence.) > > Thanks, > /Staffan > > On 17 dec 2012, at 12:26, Frederic Parain wrote: > >> Hi, >> >> Please review the following change for CR 8004095. >> >> This changeset is the JDK side of two parts project. >> >> The goal of this feature is to allow remote invocations of >> Diagnostic Commands via JMX. >> >> >> Diagnostic Commands are actually invoked from the jcmd >> tool, which is a local tool using the attachAPI. It was >> not possible to remotely invoke these commands. >> This project creates a new PlatformMBean, remotely >> accessible via the Platform MBean Server, providing >> access to Diagnostic Commands too. >> >> The JDK side of this project, including the new >> Platform MBean, is covered in CR 7150256. >> >> This changeset contains the modifications in the >> JVM to support the new API. >> >> There are two types of modifications: >> 1 - extension of the diagnostic command framework >> 2 - extension of existing diagnostic commands >> >> Modifications of the framework: >> >> The first modification of the framework is the mechanism >> to communicate with the DiagnosticCommandsMBean defined >> in the JDK. Communications are performed via the jmm.h >> interface. In addition to a few new entries in the >> jmm structure, several data structures have been declared >> to export diagnostic command meta-data to the JDK. >> >> The second modification of the framework consists in an >> export control mechanism. Diagnostic Commands are executed >> inside the JVM, they have access to critical information >> and can perform very disruptive operations. Even if the >> DiagnosticCommandsMBean includes some security checks >> using Java Permissions, it sometime better to simply >> make a diagnostic command not available from the JMX >> API. The export control mechanism gives to diagnostic >> command developers full control on how the command will >> be accessible. When a diagnostic command is registered >> to the framework, a list of interfaces allowed to >> export this command must be provided. The current >> implementation defines three interfaces: JVM internal, >> attachAPI and JMX. A diagnostic command can be >> exported to any combination of these interfaces. >> >> Modifications of existing diagnostic commands: >> >> Because this feature allows remote invocations, it >> is important to be able to control who is invoking >> and what is invoked. Java Permission checks have >> been introduced in the DiagnosticCommandsMBean and >> are performed before a remote invocation request >> is forwarded to the JVM. So, each Diagnostic Command >> can require a Java Permission to be invoked remotely. >> Note that invocations from inside the JVM or via the >> attachAPI do not check these permissions. Invocations >> from inside the JVM are considered trusted, and the >> attachAPI has its own security model based on EUID/ >> EGID. >> Some existing diagnostic commands that have been >> identified as begin potentially harmful have been >> extended to specify the Java Permission required >> for their execution. >> >> The webrev is here: >> >> http://cr.openjdk.java.net/~fparain/8004095/webrev.00/ >> >> Thanks, >> >> Fred >> >> >> >> >> >> -- >> Frederic Parain - Oracle >> Grenoble Engineering Center - France >> Phone: +33 4 76 18 81 17 >> Email: Frederic.Parain at Oracle.com >> > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From harold.seigel at oracle.com Mon Dec 17 07:23:59 2012 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 17 Dec 2012 10:23:59 -0500 Subject: Request for review 8005075: CDS archive with one alignment causes crash when run with different alignment Message-ID: <50CF390F.9020809@oracle.com> Please review the following change to fix bug 8005075. Summary: This change prevents a crash when a CDS archive is created with a value for -XX:+ObjectAlignmentInBytes that is smaller than the ObjectAlignmentInBytes value used when running with -Xshare:on. This fix stores the ObjectAlignmentInBytes in the CDS archive so that when the archive is read, hotspot can compare the archive's alignment with the current alignment and issue the following diagnostic if the archive's alignment is too small: An error has occurred while processing the shared archive file. The shared archive file was created with a smaller Object Alignment value. This webrev also cleans up some text in globals.hpp and fixes a small problem with -XX:SharedReadOnlySize. The existing code was always setting SharedReadOnlySize to 14M regardless of what was requested. This prevented users from being able to expand the CDS archive's SharedReadOnly section. Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8005076/ Bug link at http://bugs.sun.com/view_bug.do?bug_id=8005076 The changes were tested with JCK, JPRT, JTREG, and UTE tests, and with hand-run tests using different ObjectAlignmentInBytes values. Thanks, Harold -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121217/8654737f/attachment.html From staffan.larsen at oracle.com Mon Dec 17 07:47:34 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 17 Dec 2012 16:47:34 +0100 Subject: RFR: 8004095: Add support for JMX interface to Diagnostic Framework and Commands, In-Reply-To: <50CF33B0.6030301@oracle.com> References: <50CF017F.5050502@oracle.com> <32B19E42-82A3-424C-85DA-977815A230CD@oracle.com> <50CF33B0.6030301@oracle.com> Message-ID: <7CD24BA6-2A19-427B-B51B-29E3FD6436D3@oracle.com> diagnosticCommand.cpp:259: nit: wrong indentation Otherwise: Looks good to me! Thanks, /Staffan On 17 dec 2012, at 16:01, Frederic Parain wrote: > Staffan, > > Thank you for the review, I've fixed the code to address all > the issue you reported. The new webrev is here: > > http://cr.openjdk.java.net/~fparain/8004095/webrev.01/ > > Regards, > > Fred > > On 12/17/12 01:27 PM, Staffan Larsen wrote: >> Frederic, >> >> Looks good! Just a few small comments below. >> >> diagnosticCommand.cpp:255: When DisableExplicitGC is set, it would be great if the SystemGC command printed on error message so that the caller knows that the GC didn't happen as intended. I also think we should add an entry to GCCause for GCs caused by the DCmd (but that isn't new to this change). >> >> diagnosticFramework.hpp:423: nit: misspelled "enabled" in the method name >> >> diagnosticFramework.cpp:435: seems some testing code has slipped in >> >> diagnosticFramework.cpp:509: nit: missing spaces around '&'. (Consider adding () to clarify the precedence.) >> >> Thanks, >> /Staffan >> >> On 17 dec 2012, at 12:26, Frederic Parain wrote: >> >>> Hi, >>> >>> Please review the following change for CR 8004095. >>> >>> This changeset is the JDK side of two parts project. >>> >>> The goal of this feature is to allow remote invocations of >>> Diagnostic Commands via JMX. >>> >>> >>> Diagnostic Commands are actually invoked from the jcmd >>> tool, which is a local tool using the attachAPI. It was >>> not possible to remotely invoke these commands. >>> This project creates a new PlatformMBean, remotely >>> accessible via the Platform MBean Server, providing >>> access to Diagnostic Commands too. >>> >>> The JDK side of this project, including the new >>> Platform MBean, is covered in CR 7150256. >>> >>> This changeset contains the modifications in the >>> JVM to support the new API. >>> >>> There are two types of modifications: >>> 1 - extension of the diagnostic command framework >>> 2 - extension of existing diagnostic commands >>> >>> Modifications of the framework: >>> >>> The first modification of the framework is the mechanism >>> to communicate with the DiagnosticCommandsMBean defined >>> in the JDK. Communications are performed via the jmm.h >>> interface. In addition to a few new entries in the >>> jmm structure, several data structures have been declared >>> to export diagnostic command meta-data to the JDK. >>> >>> The second modification of the framework consists in an >>> export control mechanism. Diagnostic Commands are executed >>> inside the JVM, they have access to critical information >>> and can perform very disruptive operations. Even if the >>> DiagnosticCommandsMBean includes some security checks >>> using Java Permissions, it sometime better to simply >>> make a diagnostic command not available from the JMX >>> API. The export control mechanism gives to diagnostic >>> command developers full control on how the command will >>> be accessible. When a diagnostic command is registered >>> to the framework, a list of interfaces allowed to >>> export this command must be provided. The current >>> implementation defines three interfaces: JVM internal, >>> attachAPI and JMX. A diagnostic command can be >>> exported to any combination of these interfaces. >>> >>> Modifications of existing diagnostic commands: >>> >>> Because this feature allows remote invocations, it >>> is important to be able to control who is invoking >>> and what is invoked. Java Permission checks have >>> been introduced in the DiagnosticCommandsMBean and >>> are performed before a remote invocation request >>> is forwarded to the JVM. So, each Diagnostic Command >>> can require a Java Permission to be invoked remotely. >>> Note that invocations from inside the JVM or via the >>> attachAPI do not check these permissions. Invocations >>> from inside the JVM are considered trusted, and the >>> attachAPI has its own security model based on EUID/ >>> EGID. >>> Some existing diagnostic commands that have been >>> identified as begin potentially harmful have been >>> extended to specify the Java Permission required >>> for their execution. >>> >>> The webrev is here: >>> >>> http://cr.openjdk.java.net/~fparain/8004095/webrev.00/ >>> >>> Thanks, >>> >>> Fred >>> >>> >>> >>> >>> >>> -- >>> Frederic Parain - Oracle >>> Grenoble Engineering Center - France >>> Phone: +33 4 76 18 81 17 >>> Email: Frederic.Parain at Oracle.com >>> >> > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > Email: Frederic.Parain at Oracle.com > From zhengyu.gu at oracle.com Mon Dec 17 10:40:15 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Mon, 17 Dec 2012 13:40:15 -0500 Subject: Fwd: Request for review 8005075: CDS archive with one alignment causes crash when run with different alignment In-Reply-To: <50CF6555.6010904@oracle.com> References: <50CF390F.9020809@oracle.com> <50CF6555.6010904@oracle.com> Message-ID: <50CF670F.4010800@oracle.com> Look good to me. Thanks, -Zhengyu On 12/17/2012 1:32 PM, harold seigel wrote: > > > -------- Original Message -------- > Subject: Request for review 8005075: CDS archive with one alignment > causes crash when run with different alignment > Date: Mon, 17 Dec 2012 10:23:59 -0500 > From: harold seigel > Organization: Oracle Corporation > To: hotspot-runtime-dev at openjdk.java.net > > > > Please review the following change to fix bug 8005075. > > Summary: This change prevents a crash when a CDS archive is created > with a value for -XX:+ObjectAlignmentInBytes that is smaller than the > ObjectAlignmentInBytes value used when running with -Xshare:on. This > fix stores the ObjectAlignmentInBytes in the CDS archive so that when > the archive is read, hotspot can compare the archive's alignment with > the current alignment and issue the following diagnostic if the > archive's alignment is too small: > > An error has occurred while processing the shared archive file. > The shared archive file was created with a smaller Object > Alignment value. > > This webrev also cleans up some text in globals.hpp and fixes a small > problem with -XX:SharedReadOnlySize. The existing code was always > setting SharedReadOnlySize to 14M regardless of what was requested. > This prevented users from being able to expand the CDS archive's > SharedReadOnly section. > > Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8005076/ > > > Bug link at http://bugs.sun.com/view_bug.do?bug_id=8005076 > > The changes were tested with JCK, JPRT, JTREG, and UTE tests, and with > hand-run tests using different ObjectAlignmentInBytes values. > > Thanks, Harold > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121217/58c1f2ed/attachment.html From zhengyu.gu at oracle.com Mon Dec 17 12:26:46 2012 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Mon, 17 Dec 2012 20:26:46 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20121217202650.A879E471F2@hg.openjdk.java.net> Changeset: 3f84e17b6bca Author: zgu Date: 2012-12-17 13:14 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3f84e17b6bca 8004802: jcmd VM.native_memory baseline=false crashes VM Summary: NMT has to check option's value also to determine which command to execute Reviewed-by: acorn, coleenp, hseigel ! src/share/vm/services/nmtDCmd.cpp Changeset: 805aa223d540 Author: zgu Date: 2012-12-17 10:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/805aa223d540 Merge From vitalyd at gmail.com Mon Dec 17 16:10:44 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 17 Dec 2012 19:10:44 -0500 Subject: Request for review 8005075: CDS archive with one alignment causes crash when run with different alignment In-Reply-To: <50CF390F.9020809@oracle.com> References: <50CF390F.9020809@oracle.com> Message-ID: Hi Harold, It might be useful to report the recorded alignment in the CDS archive in the diagnostic message that you print out. What do you think? Thanks Sent from my phone On Dec 17, 2012 10:24 AM, "harold seigel" wrote: > Please review the following change to fix bug 8005075. > > Summary: This change prevents a crash when a CDS archive is created with > a value for -XX:+ObjectAlignmentInBytes that is smaller than the > ObjectAlignmentInBytes value used when running with -Xshare:on. This fix > stores the ObjectAlignmentInBytes in the CDS archive so that when the > archive is read, hotspot can compare the archive's alignment with the > current alignment and issue the following diagnostic if the archive's > alignment is too small: > > An error has occurred while processing the shared archive file. > The shared archive file was created with a smaller Object Alignment value. > > This webrev also cleans up some text in globals.hpp and fixes a small > problem with -XX:SharedReadOnlySize. The existing code was always setting > SharedReadOnlySize to 14M regardless of what was requested. This prevented > users from being able to expand the CDS archive's SharedReadOnly section. > > Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8005076/ > > Bug link at http://bugs.sun.com/view_bug.do?bug_id=8005076 > > The changes were tested with JCK, JPRT, JTREG, and UTE tests, and with > hand-run tests using different ObjectAlignmentInBytes values. > > Thanks, Harold > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121217/8d89bed4/attachment.html From david.holmes at oracle.com Mon Dec 17 18:28:15 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Dec 2012 12:28:15 +1000 Subject: Request for review 8005075: CDS archive with one alignment causes crash when run with different alignment In-Reply-To: <50CF390F.9020809@oracle.com> References: <50CF390F.9020809@oracle.com> Message-ID: <50CFD4BF.6070108@oracle.com> Hi Harold, Looks okay to me. David On 18/12/2012 1:23 AM, harold seigel wrote: > Please review the following change to fix bug 8005075. > > Summary: This change prevents a crash when a CDS archive is created > with a value for -XX:+ObjectAlignmentInBytes that is smaller than the > ObjectAlignmentInBytes value used when running with -Xshare:on. This > fix stores the ObjectAlignmentInBytes in the CDS archive so that when > the archive is read, hotspot can compare the archive's alignment with > the current alignment and issue the following diagnostic if the > archive's alignment is too small: > > An error has occurred while processing the shared archive file. > The shared archive file was created with a smaller Object Alignment > value. > > This webrev also cleans up some text in globals.hpp and fixes a small > problem with -XX:SharedReadOnlySize. The existing code was always > setting SharedReadOnlySize to 14M regardless of what was requested. > This prevented users from being able to expand the CDS archive's > SharedReadOnly section. > > Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8005076/ > > > Bug link at http://bugs.sun.com/view_bug.do?bug_id=8005076 > > The changes were tested with JCK, JPRT, JTREG, and UTE tests, and with > hand-run tests using different ObjectAlignmentInBytes values. > > Thanks, Harold From erik.helin at oracle.com Tue Dec 18 01:52:50 2012 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 18 Dec 2012 10:52:50 +0100 Subject: RFR (XS): 8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag Message-ID: <50D03CF2.6070105@oracle.com> Hi all, this change adds a jtreg test that runs the internal vm tests. Webrev: http://cr.openjdk.java.net/~ehelin/8004691/webrev.00/ Summary: There are a couple of tests in HotSpot C++ source code that can be run with the flag -XX:+ExecuteInternalVMTests. These tests are run in JPRT queues, but they are not run as part of the nightly testing. This change adds an empty jtreg test that starts the VM with the flag -XX:+ExecuteInternalVMTests, thereby running the internal VM tests. Since -XX:+ExecuteInternalVMTests only works with a non-product build of the VM, the test also uses the flag -XX:+IgnoreUnrecognizedVMOptions to make sure the test works, but does nothing, when run with a product build of HotSpot. Testing: JPRT Thanks, Erik From stefan.karlsson at oracle.com Tue Dec 18 02:24:25 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 18 Dec 2012 11:24:25 +0100 Subject: RFR (XS): 8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag In-Reply-To: <50D03CF2.6070105@oracle.com> References: <50D03CF2.6070105@oracle.com> Message-ID: <50D04459.8050309@oracle.com> Looks good. Though, I'd prefer if the test was not put in the gc directory, since this flag could be used by all HotSpot groups. thanks, StefanK On 12/18/2012 10:52 AM, Erik Helin wrote: > Hi all, > > this change adds a jtreg test that runs the internal vm tests. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8004691/webrev.00/ > > Summary: > There are a couple of tests in HotSpot C++ source code that can be run > with the flag -XX:+ExecuteInternalVMTests. These tests are run in JPRT > queues, but they are not run as part of the nightly testing. > > This change adds an empty jtreg test that starts the VM with the flag > -XX:+ExecuteInternalVMTests, thereby running the internal VM tests. > > Since -XX:+ExecuteInternalVMTests only works with a non-product build of > the VM, the test also uses the flag -XX:+IgnoreUnrecognizedVMOptions to > make sure the test works, but does nothing, when run with a product > build of HotSpot. > > Testing: > JPRT > > Thanks, > Erik From erik.helin at oracle.com Tue Dec 18 04:15:11 2012 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 18 Dec 2012 13:15:11 +0100 Subject: RFR (XS): 8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag In-Reply-To: <50D04459.8050309@oracle.com> References: <50D03CF2.6070105@oracle.com> <50D04459.8050309@oracle.com> Message-ID: <50D05E4F.2060906@oracle.com> Hi Stefan, thanks for reviewing this change! See comments inline: On 12/18/2012 11:24 AM, Stefan Karlsson wrote: > Looks good. Thanks! On 12/18/2012 11:24 AM, Stefan Karlsson wrote: > Though, I'd prefer if the test was not put in the gc directory, since > this flag could be used by all HotSpot groups. I agree, I've moved the test to the hotspot/test/sanity folder instead. The new webrev is located at: http://cr.openjdk.java.net/~ehelin/8004691/webrev.01/ I've also updated some spelling errors. Thanks, Erik > thanks, > StefanK > > On 12/18/2012 10:52 AM, Erik Helin wrote: >> Hi all, >> >> this change adds a jtreg test that runs the internal vm tests. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8004691/webrev.00/ >> >> Summary: >> There are a couple of tests in HotSpot C++ source code that can be run >> with the flag -XX:+ExecuteInternalVMTests. These tests are run in JPRT >> queues, but they are not run as part of the nightly testing. >> >> This change adds an empty jtreg test that starts the VM with the flag >> -XX:+ExecuteInternalVMTests, thereby running the internal VM tests. >> >> Since -XX:+ExecuteInternalVMTests only works with a non-product build of >> the VM, the test also uses the flag -XX:+IgnoreUnrecognizedVMOptions to >> make sure the test works, but does nothing, when run with a product >> build of HotSpot. >> >> Testing: >> JPRT >> >> Thanks, >> Erik > From christian.tornqvist at oracle.com Tue Dec 18 04:16:19 2012 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Tue, 18 Dec 2012 04:16:19 -0800 (PST) Subject: RFR (XS): 8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag In-Reply-To: <50D04459.8050309@oracle.com> References: <50D03CF2.6070105@oracle.com> <50D04459.8050309@oracle.com> Message-ID: <4b56d253-bb0f-433e-a54c-370ae6402266@default> I agree with Stefan, test/sanity could be such a place. There's already a WBApi test in there. I also think the bugid directory (/8004691) could be omitted since the bug id is already in the test. Thanks, Christian -----Original Message----- From: Stefan Karlsson Sent: den 18 december 2012 11:24 To: Erik Helin Cc: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR (XS): 8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag Looks good. Though, I'd prefer if the test was not put in the gc directory, since this flag could be used by all HotSpot groups. thanks, StefanK On 12/18/2012 10:52 AM, Erik Helin wrote: > Hi all, > > this change adds a jtreg test that runs the internal vm tests. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8004691/webrev.00/ > > Summary: > There are a couple of tests in HotSpot C++ source code that can be run > with the flag -XX:+ExecuteInternalVMTests. These tests are run in JPRT > queues, but they are not run as part of the nightly testing. > > This change adds an empty jtreg test that starts the VM with the flag > -XX:+ExecuteInternalVMTests, thereby running the internal VM tests. > > Since -XX:+ExecuteInternalVMTests only works with a non-product build > of the VM, the test also uses the flag > -XX:+IgnoreUnrecognizedVMOptions to make sure the test works, but does > nothing, when run with a product build of HotSpot. > > Testing: > JPRT > > Thanks, > Erik From erik.helin at oracle.com Tue Dec 18 04:27:10 2012 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 18 Dec 2012 13:27:10 +0100 Subject: RFR (XS): 8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag In-Reply-To: <4b56d253-bb0f-433e-a54c-370ae6402266@default> References: <50D03CF2.6070105@oracle.com> <50D04459.8050309@oracle.com> <4b56d253-bb0f-433e-a54c-370ae6402266@default> Message-ID: <50D0611E.403@oracle.com> Christian, thanks for reviewing this! See comments inline: On 12/18/2012 01:16 PM, Christian T?rnqvist wrote: > I agree with Stefan, test/sanity could be such a place. There's already a WBApi test in there. I also think the bugid directory (/8004691) could be omitted since the bug id is already in the test. The latest webrev (based on the feedback by Stefan), is available here: http://cr.openjdk.java.net/~ehelin/8004691/webrev.01/ This change moves the test to the hotspot/test/sanity folder and does _not_ make use of a folder named after the bugid. What do you think of this change? Thanks, Erik > Thanks, > Christian > > -----Original Message----- > From: Stefan Karlsson > Sent: den 18 december 2012 11:24 > To: Erik Helin > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR (XS): 8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag > > Looks good. > > Though, I'd prefer if the test was not put in the gc directory, since this flag could be used by all HotSpot groups. > > thanks, > StefanK > > On 12/18/2012 10:52 AM, Erik Helin wrote: >> Hi all, >> >> this change adds a jtreg test that runs the internal vm tests. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8004691/webrev.00/ >> >> Summary: >> There are a couple of tests in HotSpot C++ source code that can be run >> with the flag -XX:+ExecuteInternalVMTests. These tests are run in JPRT >> queues, but they are not run as part of the nightly testing. >> >> This change adds an empty jtreg test that starts the VM with the flag >> -XX:+ExecuteInternalVMTests, thereby running the internal VM tests. >> >> Since -XX:+ExecuteInternalVMTests only works with a non-product build >> of the VM, the test also uses the flag >> -XX:+IgnoreUnrecognizedVMOptions to make sure the test works, but does >> nothing, when run with a product build of HotSpot. >> >> Testing: >> JPRT >> >> Thanks, >> Erik > From christian.tornqvist at oracle.com Tue Dec 18 04:30:06 2012 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Tue, 18 Dec 2012 04:30:06 -0800 (PST) Subject: RFR (XS): 8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag In-Reply-To: <50D0611E.403@oracle.com> References: <50D03CF2.6070105@oracle.com> <50D04459.8050309@oracle.com> <4b56d253-bb0f-433e-a54c-370ae6402266@default> <50D0611E.403@oracle.com> Message-ID: <4bcd132d-1887-4881-a5d7-dc6d4751f8ba@default> Looks good! Thanks, Christian -----Original Message----- From: Erik Helin Sent: den 18 december 2012 13:27 To: Christian T?rnqvist Cc: Stefan Karlsson; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR (XS): 8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag Christian, thanks for reviewing this! See comments inline: On 12/18/2012 01:16 PM, Christian T?rnqvist wrote: > I agree with Stefan, test/sanity could be such a place. There's already a WBApi test in there. I also think the bugid directory (/8004691) could be omitted since the bug id is already in the test. The latest webrev (based on the feedback by Stefan), is available here: http://cr.openjdk.java.net/~ehelin/8004691/webrev.01/ This change moves the test to the hotspot/test/sanity folder and does _not_ make use of a folder named after the bugid. What do you think of this change? Thanks, Erik > Thanks, > Christian > > -----Original Message----- > From: Stefan Karlsson > Sent: den 18 december 2012 11:24 > To: Erik Helin > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR (XS): 8004691: Add a jtreg test that exercises the > ExecuteInternalVMTests flag > > Looks good. > > Though, I'd prefer if the test was not put in the gc directory, since this flag could be used by all HotSpot groups. > > thanks, > StefanK > > On 12/18/2012 10:52 AM, Erik Helin wrote: >> Hi all, >> >> this change adds a jtreg test that runs the internal vm tests. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8004691/webrev.00/ >> >> Summary: >> There are a couple of tests in HotSpot C++ source code that can be >> run with the flag -XX:+ExecuteInternalVMTests. These tests are run in >> JPRT queues, but they are not run as part of the nightly testing. >> >> This change adds an empty jtreg test that starts the VM with the flag >> -XX:+ExecuteInternalVMTests, thereby running the internal VM tests. >> >> Since -XX:+ExecuteInternalVMTests only works with a non-product build >> of the VM, the test also uses the flag >> -XX:+IgnoreUnrecognizedVMOptions to make sure the test works, but >> does nothing, when run with a product build of HotSpot. >> >> Testing: >> JPRT >> >> Thanks, >> Erik > From bengt.rutisson at oracle.com Tue Dec 18 04:40:44 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 18 Dec 2012 13:40:44 +0100 Subject: RFR (XS): 8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag In-Reply-To: <4bcd132d-1887-4881-a5d7-dc6d4751f8ba@default> References: <50D03CF2.6070105@oracle.com> <50D04459.8050309@oracle.com> <4b56d253-bb0f-433e-a54c-370ae6402266@default> <50D0611E.403@oracle.com> <4bcd132d-1887-4881-a5d7-dc6d4751f8ba@default> Message-ID: <50D0644C.5030008@oracle.com> Erik, Looks good! Thanks for fixing this. Bengt On 12/18/12 1:30 PM, Christian T?rnqvist wrote: > Looks good! > > Thanks, > Christian > > -----Original Message----- > From: Erik Helin > Sent: den 18 december 2012 13:27 > To: Christian T?rnqvist > Cc: Stefan Karlsson; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR (XS): 8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag > > Christian, > > thanks for reviewing this! See comments inline: > > On 12/18/2012 01:16 PM, Christian T?rnqvist wrote: >> I agree with Stefan, test/sanity could be such a place. There's already a WBApi test in there. I also think the bugid directory (/8004691) could be omitted since the bug id is already in the test. > The latest webrev (based on the feedback by Stefan), is available here: > > http://cr.openjdk.java.net/~ehelin/8004691/webrev.01/ > > This change moves the test to the hotspot/test/sanity folder and does _not_ make use of a folder named after the bugid. > > What do you think of this change? > > Thanks, > Erik > >> Thanks, >> Christian >> >> -----Original Message----- >> From: Stefan Karlsson >> Sent: den 18 december 2012 11:24 >> To: Erik Helin >> Cc: hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR (XS): 8004691: Add a jtreg test that exercises the >> ExecuteInternalVMTests flag >> >> Looks good. >> >> Though, I'd prefer if the test was not put in the gc directory, since this flag could be used by all HotSpot groups. >> >> thanks, >> StefanK >> >> On 12/18/2012 10:52 AM, Erik Helin wrote: >>> Hi all, >>> >>> this change adds a jtreg test that runs the internal vm tests. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8004691/webrev.00/ >>> >>> Summary: >>> There are a couple of tests in HotSpot C++ source code that can be >>> run with the flag -XX:+ExecuteInternalVMTests. These tests are run in >>> JPRT queues, but they are not run as part of the nightly testing. >>> >>> This change adds an empty jtreg test that starts the VM with the flag >>> -XX:+ExecuteInternalVMTests, thereby running the internal VM tests. >>> >>> Since -XX:+ExecuteInternalVMTests only works with a non-product build >>> of the VM, the test also uses the flag >>> -XX:+IgnoreUnrecognizedVMOptions to make sure the test works, but >>> does nothing, when run with a product build of HotSpot. >>> >>> Testing: >>> JPRT >>> >>> Thanks, >>> Erik From christian.tornqvist at oracle.com Tue Dec 18 06:10:54 2012 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Tue, 18 Dec 2012 06:10:54 -0800 (PST) Subject: RFR (M) 8005012: Add WB APIs to better support NMT testing Message-ID: <1618bca5-45ee-47d0-9ae0-18b29b72053a@default> Hi everyone, ? This change is about adding three new WB APIs to better support NMT testing. The changes are: ? ????????? A Test memory type, used by WB API's NMTAllocTest and NMTFreeTestMemory ????????? Added a WaitForDataMerge WB API to be able to block until the current generation has been merged and is visible, most of this work was done by Zhengyu Gu. ? Webrev can be found at: http://cr.openjdk.java.net/~ehelin/8005012/webrev.00/ ? Thanks, Christian ? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121218/fe89c92c/attachment.html From coleen.phillimore at oracle.com Tue Dec 18 07:15:43 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 18 Dec 2012 10:15:43 -0500 Subject: RFR (XS): 8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag In-Reply-To: <50D04459.8050309@oracle.com> References: <50D03CF2.6070105@oracle.com> <50D04459.8050309@oracle.com> Message-ID: <50D0889F.7010704@oracle.com> I was just about to make the same comment. I think it should go up a level, although this requires people to run all the jtreg tests and not just the one in the subdirectory in the component where they work. Thanks, Coleen On 12/18/2012 05:24 AM, Stefan Karlsson wrote: > Looks good. > > Though, I'd prefer if the test was not put in the gc directory, since > this flag could be used by all HotSpot groups. > > thanks, > StefanK > > On 12/18/2012 10:52 AM, Erik Helin wrote: >> Hi all, >> >> this change adds a jtreg test that runs the internal vm tests. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8004691/webrev.00/ >> >> Summary: >> There are a couple of tests in HotSpot C++ source code that can be run >> with the flag -XX:+ExecuteInternalVMTests. These tests are run in JPRT >> queues, but they are not run as part of the nightly testing. >> >> This change adds an empty jtreg test that starts the VM with the flag >> -XX:+ExecuteInternalVMTests, thereby running the internal VM tests. >> >> Since -XX:+ExecuteInternalVMTests only works with a non-product build of >> the VM, the test also uses the flag -XX:+IgnoreUnrecognizedVMOptions to >> make sure the test works, but does nothing, when run with a product >> build of HotSpot. >> >> Testing: >> JPRT >> >> Thanks, >> Erik > From vladimir.kozlov at oracle.com Tue Dec 18 10:22:49 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Dec 2012 10:22:49 -0800 Subject: RFR (XS): 8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag In-Reply-To: <50D0611E.403@oracle.com> References: <50D03CF2.6070105@oracle.com> <50D04459.8050309@oracle.com> <4b56d253-bb0f-433e-a54c-370ae6402266@default> <50D0611E.403@oracle.com> Message-ID: <50D0B479.5030802@oracle.com> Erik, Your test is missing copyright header which all open tests should have. Also swap flags, IgnoreUnrecognizedVMOptions should be first. Thanks, Vladimir K. On 12/18/12 4:27 AM, Erik Helin wrote: > Christian, > > thanks for reviewing this! See comments inline: > > On 12/18/2012 01:16 PM, Christian T?rnqvist wrote: >> I agree with Stefan, test/sanity could be such a place. There's >> already a WBApi test in there. I also think the bugid directory >> (/8004691) could be omitted since the bug id is already in the test. > > The latest webrev (based on the feedback by Stefan), is available here: > > http://cr.openjdk.java.net/~ehelin/8004691/webrev.01/ > > This change moves the test to the hotspot/test/sanity folder and does > _not_ make use of a folder named after the bugid. > > What do you think of this change? > > Thanks, > Erik > >> Thanks, >> Christian >> >> -----Original Message----- >> From: Stefan Karlsson >> Sent: den 18 december 2012 11:24 >> To: Erik Helin >> Cc: hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR (XS): 8004691: Add a jtreg test that exercises the >> ExecuteInternalVMTests flag >> >> Looks good. >> >> Though, I'd prefer if the test was not put in the gc directory, since >> this flag could be used by all HotSpot groups. >> >> thanks, >> StefanK >> >> On 12/18/2012 10:52 AM, Erik Helin wrote: >>> Hi all, >>> >>> this change adds a jtreg test that runs the internal vm tests. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8004691/webrev.00/ >>> >>> Summary: >>> There are a couple of tests in HotSpot C++ source code that can be run >>> with the flag -XX:+ExecuteInternalVMTests. These tests are run in JPRT >>> queues, but they are not run as part of the nightly testing. >>> >>> This change adds an empty jtreg test that starts the VM with the flag >>> -XX:+ExecuteInternalVMTests, thereby running the internal VM tests. >>> >>> Since -XX:+ExecuteInternalVMTests only works with a non-product build >>> of the VM, the test also uses the flag >>> -XX:+IgnoreUnrecognizedVMOptions to make sure the test works, but does >>> nothing, when run with a product build of HotSpot. >>> >>> Testing: >>> JPRT >>> >>> Thanks, >>> Erik >> > From harold.seigel at oracle.com Tue Dec 18 11:14:42 2012 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 18 Dec 2012 14:14:42 -0500 Subject: Request for review 8005075: CDS archive with one alignment causes crash when run with different alignment In-Reply-To: References: <50CF390F.9020809@oracle.com> Message-ID: <50D0C0A2.2060901@oracle.com> Hi Vitaly, It would be useful to report the actual alignment values. I'll make that change. Thanks, Harold On 12/17/2012 7:10 PM, Vitaly Davidovich wrote: > > Hi Harold, > > It might be useful to report the recorded alignment in the CDS archive > in the diagnostic message that you print out. What do you think? > > Thanks > > Sent from my phone > > On Dec 17, 2012 10:24 AM, "harold seigel" > wrote: > > Please review the following change to fix bug 8005075. > > Summary: This change prevents a crash when a CDS archive is > created with a value for -XX:+ObjectAlignmentInBytes that is > smaller than the ObjectAlignmentInBytes value used when running > with -Xshare:on. This fix stores the ObjectAlignmentInBytes in > the CDS archive so that when the archive is read, hotspot can > compare the archive's alignment with the current alignment and > issue the following diagnostic if the archive's alignment is too > small: > > An error has occurred while processing the shared archive file. > The shared archive file was created with a smaller Object > Alignment value. > > This webrev also cleans up some text in globals.hpp and fixes a > small problem with -XX:SharedReadOnlySize. The existing code was > always setting SharedReadOnlySize to 14M regardless of what was > requested. This prevented users from being able to expand the CDS > archive's SharedReadOnly section. > > Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8005076/ > > > Bug link at http://bugs.sun.com/view_bug.do?bug_id=8005076 > > The changes were tested with JCK, JPRT, JTREG, and UTE tests, and > with hand-run tests using different ObjectAlignmentInBytes values. > > Thanks, Harold > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121218/925937b3/attachment-0001.html From ron.durbin at oracle.com Tue Dec 18 11:31:08 2012 From: ron.durbin at oracle.com (Ron Durbin) Date: Tue, 18 Dec 2012 11:31:08 -0800 (PST) Subject: FW: Code Review fix for 7153050 ?remove crufty '_g' support from HotSpot run time Message-ID: <17d2d036-99a8-411e-8e53-95da33f17137@default> Intro: This set of changes removes the runtime support for generation of debug versions that follow _g semantics. Defect: JDK-8005044 remove crufty '_g' support from HS runtime code Webrev /u/rdurbin/8005044_exp/webrev/index.html Details: Files have been modified to remove all reference and support for debug versions that follow _g semantics. Testing: Passed JPRT last night: Additional Testing In process: ( suggested by Dan): src/share/vm/runtime/arguments.cpp - test with shared archive creation and use; see the e-mail from Coleen src/share/tools/ProjectCreator/ProjectCreator.java - just a usage message; visual inspection of the code src/os/windows/vm/os_windows.cpp - comments only; no testing needed src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp - the only code changes come into play when the "gamma" launcher is used - and when JAVA_HOME refers to a valid JDK, the function fakes up a JVM path so that callers using the JVM path to find other things in the JDK will work. - I can't find any way that the actual JVM path value that is returned is exposed - I don't see a way to test this other than have a debug printf() or manual code inspection. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121218/8c69e9a8/attachment.html From harold.seigel at oracle.com Tue Dec 18 11:58:13 2012 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 18 Dec 2012 14:58:13 -0500 Subject: Request for review 8005075: CDS archive with one alignment causes crash when run with different alignment In-Reply-To: References: <50CF390F.9020809@oracle.com> Message-ID: <50D0CAD5.9090608@oracle.com> Please review the modified fix for bug 8005076. The modified fix can be viewed at http://cr.openjdk.java.net/~hseigel/bug_8005076_2/ It contains two changes from the previous fix. As requested by Vitaly, the diagnostic in filemap.cpp has been changed to include the incompatible ObjectAlignmentInBytes values. Here's sample new message: The shared archive file's ObjectAlignmentInBytes of 8 is too small for the current ObjectAlignmentInBytes of 16. Also, the change to arguments.cpp no longer sets a minimum value for -XX:+ObjectAlignmentInBytes. (This was requested by Coleen.) Thanks, Harold On 12/17/2012 7:10 PM, Vitaly Davidovich wrote: > > Hi Harold, > > It might be useful to report the recorded alignment in the CDS archive > in the diagnostic message that you print out. What do you think? > > Thanks > > Sent from my phone > > On Dec 17, 2012 10:24 AM, "harold seigel" > wrote: > > Please review the following change to fix bug 8005075. > > Summary: This change prevents a crash when a CDS archive is > created with a value for -XX:+ObjectAlignmentInBytes that is > smaller than the ObjectAlignmentInBytes value used when running > with -Xshare:on. This fix stores the ObjectAlignmentInBytes in > the CDS archive so that when the archive is read, hotspot can > compare the archive's alignment with the current alignment and > issue the following diagnostic if the archive's alignment is too > small: > > An error has occurred while processing the shared archive file. > The shared archive file was created with a smaller Object > Alignment value. > > This webrev also cleans up some text in globals.hpp and fixes a > small problem with -XX:SharedReadOnlySize. The existing code was > always setting SharedReadOnlySize to 14M regardless of what was > requested. This prevented users from being able to expand the CDS > archive's SharedReadOnly section. > > Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8005076/ > > > Bug link at http://bugs.sun.com/view_bug.do?bug_id=8005076 > > The changes were tested with JCK, JPRT, JTREG, and UTE tests, and > with hand-run tests using different ObjectAlignmentInBytes values. > > Thanks, Harold > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121218/f66f6622/attachment.html From vladimir.kozlov at oracle.com Tue Dec 18 12:01:34 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Dec 2012 12:01:34 -0800 Subject: Request for review 8005075: CDS archive with one alignment causes crash when run with different alignment In-Reply-To: <50CF390F.9020809@oracle.com> References: <50CF390F.9020809@oracle.com> Message-ID: <50D0CB9E.2060106@oracle.com> Recording ObjectAlignmentInBytes in CDS is good. Thank you for doing it. My question is why bigger original alignment is fine? I thought CDS works only when it is exactly the same. Thanks, Vladimir On 12/17/12 7:23 AM, harold seigel wrote: > Please review the following change to fix bug 8005075. > > Summary: This change prevents a crash when a CDS archive is created > with a value for -XX:+ObjectAlignmentInBytes that is smaller than the > ObjectAlignmentInBytes value used when running with -Xshare:on. This fix > stores the ObjectAlignmentInBytes in the CDS archive so that when the > archive is read, hotspot can compare the archive's alignment with the > current alignment and issue the following diagnostic if the archive's > alignment is too small: > > An error has occurred while processing the shared archive file. > The shared archive file was created with a smaller Object Alignment > value. > > This webrev also cleans up some text in globals.hpp and fixes a small > problem with -XX:SharedReadOnlySize. The existing code was always > setting SharedReadOnlySize to 14M regardless of what was requested. > This prevented users from being able to expand the CDS archive's > SharedReadOnly section. > > Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8005076/ > > > Bug link at http://bugs.sun.com/view_bug.do?bug_id=8005076 > > The changes were tested with JCK, JPRT, JTREG, and UTE tests, and with > hand-run tests using different ObjectAlignmentInBytes values. > > Thanks, Harold From bengt.rutisson at oracle.com Tue Dec 18 12:29:59 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 18 Dec 2012 21:29:59 +0100 Subject: Request for review (s): 7173959 : Jvm crashed during coherence exabus (tmb) testing In-Reply-To: <50CECB6F.3050806@oracle.com> References: <50C978BE.8040405@oracle.com> <50C984DA.1070400@oracle.com> <50C9A7AD.3030307@oracle.com> <50C9AFE9.2080601@oracle.com> <50C9B2EC.5090008@oracle.com> <50C9D0F1.9040501@oracle.com> <50CA750A.6040007@oracle.com> <50CAE384.6070003@oracle.com> <50CAE7F6.2020609@oracle.com> <50CB27C0.6050708@oracle.com> <50CB44AE.9040509@oracle.com> <50CB4A98.7070008@oracle.com> <50CECB6F.3050806@oracle.com> Message-ID: <50D0D247.6010608@oracle.com> Hi all, One final update on this. I pushed this change both in to the hotspot-gc repository and to the hs24 repository: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/730cc4ddd550 http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e1d9b04b560b But I forgot to add "Contributed-by" for Mikael Gerdin ( mgerdin). That should definitely have been the case since he deserves a large part of the credit for this fix. Hopefully this email message will be of some help in recording his work for this fix for future reference. Bengt On 12/17/12 8:36 AM, Bengt Rutisson wrote: > > Hi Coleen, > > Thanks for suggesting the comments. I added them to the os files. > > > David, Coleen, Zhengyu and Vitaly, > > Thanks for the reviews! All set to push this now. > > Bengt > > > On 12/14/12 4:49 PM, Coleen Phillimore wrote: >> On 12/14/2012 10:24 AM, Bengt Rutisson wrote: >>> >>> Hi Coleen, >>> >>> Thanks for looking at this! >>> >>> On 12/14/12 2:21 PM, Coleen Phillimore wrote: >>>> On 12/14/2012 3:48 AM, Bengt Rutisson wrote: >>>>> >>>>> Hi again Runtime team, >>>>> >>>>> I need one more review for this change. It is a P1 bug with a >>>>> fairly small change. Any takers? >>>>> >>>>> Latest webrev based on comments from David Holmes and Vitaly >>>>> Davidovich: >>>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.03/ >>>> >>>> Hi Bengt, This code looks good to me but I asked Zhengyu to check >>>> it to make sure it doesn't have any bad NMT interactions. >>> >>> Thanks! He just replied. >>>> >>>> Also the writeup is great below, but can you add these comments to >>>> the code in os_posix.cpp. I had to go back to the email to figure >>>> out why you are doing this. >>> >>> I'm not really sure where to put such a comment. I think the writeup >>> I did mostly makes sense when you compare it to the old code. Also, >>> the affected code is in the middle of ReservedSpace::initialize(). I >>> think it would look strange with a large comment there. In the >>> os_posix/windows files the comment does not make much sense in my >>> opinion. >>> >>> I could add a comment in ReservedSpace::initialize() that refers to >>> the Jira issue. But I'm not a big fan of such comments. >> >> I agree we shouldn't point to bugs in the source code. A comment at >> the top of the os_posix version of this function that paraphrases >> below why you are not re-reserving in a loop like windows would be >> sufficient. That trimming memory at either end is allowed on >> posix-like os's and is thread-safe, something like: >> >> // Multiple threads can race in this code, and can remap over each >> other with MAP_FIXED, so on posix, unmap the section >> // at the start and at the end of the chunk that we mapped to get >> requested alignment. >> >> os_windows: >> >> // Multiple threads can race in this code but it's not possible to >> remap with a section of virtual space to get requested alignment, >> like posix-like os's. >> // Windows prevents multiple thread from remapping over each other so >> this loop is thread-safe. >> >> I just want something to document why they are different. >> >>> >>>> >>>> I don't understand why there are racing threads. I thought all >>>> the heap space was initialized at the start of the vm when it is >>>> single threaded? >>> >>> I would have to look up exactly when we set up the heap to see if we >>> are single threaded at that point. The issue we saw was with setting >>> up the GC bitmaps. At that point we are multithreaded and we are for >>> example mapping memory for the GC worker threads at the same time. >> >> I see. >> >> Coleen >>> >>> >>> Thanks again for looking at this! >>> Bengt >>> >>>> >>>> thanks, >>>> Coleen >>>> >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>> >>>>> On 12/14/12 9:29 AM, Bengt Rutisson wrote: >>>>>> >>>>>> Hi David, >>>>>> >>>>>> On 12/14/12 1:38 AM, David Holmes wrote: >>>>>>> Hi Bengt, >>>>>>> >>>>>>> That all sounds good to me. >>>>>>> >>>>>>> With regard to potential overflow perhaps a simple check that >>>>>>> extra_size does not overflow? If that is true and extra_base is >>>>>>> not null then I think all the other calculations must be valid. >>>>>> >>>>>> Yes, that makes sense. I'll add an overflow check for the >>>>>> extra_size. >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 13/12/2012 10:58 PM, Bengt Rutisson wrote: >>>>>>>> >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Updated webrev: >>>>>>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.02/ >>>>>>>> >>>>>>>> I moved the alignment of "size" back into >>>>>>>> ReservedSpace::initialize() >>>>>>>> since we actually store the size in an instance variable >>>>>>>> (_size), so I >>>>>>>> think it is a bit risky to just do the align_up in >>>>>>>> os::reserve_memory_aligned(). We probably want the instance >>>>>>>> variables >>>>>>>> _size and _alignment in ReservedSpace to be consistent. >>>>>>>> >>>>>>>> I added an assert in os::reserve_memory_aligned() to verify >>>>>>>> that the >>>>>>>> size is correctly aligned. I also added the assert you >>>>>>>> suggested to >>>>>>>> check that alignment is page size aligned. >>>>>>>> >>>>>>>> Bengt >>>>>>>> >>>>>>>> On 12/13/12 11:50 AM, David Holmes wrote: >>>>>>>>> On 13/12/2012 8:37 PM, Bengt Rutisson wrote: >>>>>>>>>> >>>>>>>>>> Hi again, >>>>>>>>>> >>>>>>>>>> Updated webrev: >>>>>>>>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.01/ >>>>>>>>>> >>>>>>>>>> I removed the comment and the alignment. >>>>>>>>>> >>>>>>>>>> But I did not add an assert just yet. >>>>>>>>>> >>>>>>>>>> At the top of ReservedSpace::initialize() we have this code: >>>>>>>>>> >>>>>>>>>> const size_t granularity = os::vm_allocation_granularity(); >>>>>>>>>> assert((size & (granularity - 1)) == 0, >>>>>>>>>> "size not aligned to os::vm_allocation_granularity()"); >>>>>>>>>> assert((alignment & (granularity - 1)) == 0, >>>>>>>>>> "alignment not aligned to os::vm_allocation_granularity()"); >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Where os::vm_allocation_granularity() is implemented as page >>>>>>>>>> size on all >>>>>>>>>> platforms except Windows. There we look it up from the >>>>>>>>>> Windows API. I >>>>>>>>>> assume that is a page size too, but since the Windows code in >>>>>>>>>> our patch >>>>>>>>>> does not unmap based on the alignment it should be safe >>>>>>>>>> either way. >>>>>>>>>> >>>>>>>>>> Is this assert enough or would you like me to add an assert >>>>>>>>>> closer to >>>>>>>>>> the code block were I did the changes? >>>>>>>>> >>>>>>>>> As this is a separate method now I think an assert in the method >>>>>>>>> itself would not go astray. >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Bengt >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 12/13/12 11:02 AM, Bengt Rutisson wrote: >>>>>>>>>>> >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> Thanks for looking at this! >>>>>>>>>>> >>>>>>>>>>> On 12/13/12 8:33 AM, David Holmes wrote: >>>>>>>>>>>> Hi Bengt, >>>>>>>>>>>> >>>>>>>>>>>> This has to be one of the absolute best review requests >>>>>>>>>>>> I've ever >>>>>>>>>>>> read :) Thank you. >>>>>>>>>>> >>>>>>>>>>> Wow! Thanks! :) >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Just a couple of queries. >>>>>>>>>>>> >>>>>>>>>>>> os_posix.cpp: >>>>>>>>>>>> >>>>>>>>>>>> Love the diagram :) >>>>>>>>>>> >>>>>>>>>>> It was Mikael's way of making sure we got it right. >>>>>>>>>>> >>>>>>>>>>>> I'm assuming that "alignment" has to be >= the underlying >>>>>>>>>>>> page size, >>>>>>>>>>>> and in fact must be a multiple of the underlying page size >>>>>>>>>>>> ? (As I >>>>>>>>>>>> assume you can only unmap whole numbers of pages). If so >>>>>>>>>>>> does that >>>>>>>>>>>> need to be checked somewhere? >>>>>>>>>>> >>>>>>>>>>> Good point. I'll add an assert to check that. >>>>>>>>>>> >>>>>>>>>>>> In virtualSpace.cpp: >>>>>>>>>>>> >>>>>>>>>>>> // Reserve size large enough to do manual alignment and >>>>>>>>>>>> // increase size to a multiple of the desired alignment >>>>>>>>>>>> size = align_size_up(size, alignment); >>>>>>>>>>>> ! base = os::reserve_memory_aligned(size, alignment); >>>>>>>>>>>> >>>>>>>>>>>> The comment doesn't seem necessary now, and the >>>>>>>>>>>> align_size_up seems >>>>>>>>>>>> redundant. >>>>>>>>>>> >>>>>>>>>>> You are right. I'll remove the comment and the alignment. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Bengt >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>> On 13/12/2012 4:42 PM, Bengt Rutisson wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> Could I have a couple of reviews for this change? >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~brutisso/7173959/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> This is for a bug originally reported by the Coherence team: >>>>>>>>>>>>> >>>>>>>>>>>>> 7173959 : Jvm crashed during coherence exabus (tmb) testing >>>>>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173959 >>>>>>>>>>>>> >>>>>>>>>>>>> The original analysis and proposed fix was done by Mikael >>>>>>>>>>>>> Gerdin >>>>>>>>>>>>> and me >>>>>>>>>>>>> together. I'll handle the webrev and push since Mikael is >>>>>>>>>>>>> on vacation >>>>>>>>>>>>> starting today. But Mikael did a great job tracking down >>>>>>>>>>>>> this very >>>>>>>>>>>>> difficult bug, so he should have a large part of the >>>>>>>>>>>>> credit for this >>>>>>>>>>>>> bug >>>>>>>>>>>>> fix, >>>>>>>>>>>>> >>>>>>>>>>>>> Description from the CR: >>>>>>>>>>>>> >>>>>>>>>>>>> The reason that we crash is due to how we re-map memory >>>>>>>>>>>>> when we >>>>>>>>>>>>> want to >>>>>>>>>>>>> align it for large pages in ReservedSpace::initialize(). >>>>>>>>>>>>> >>>>>>>>>>>>> Here is what happens: >>>>>>>>>>>>> >>>>>>>>>>>>> The reservation of memory is split up to a few steps. When >>>>>>>>>>>>> we want a >>>>>>>>>>>>> chunk of memory with large pages we first just reserve >>>>>>>>>>>>> some memory >>>>>>>>>>>>> large >>>>>>>>>>>>> enough for what we need. Then we realize that we want >>>>>>>>>>>>> large pages, >>>>>>>>>>>>> so we >>>>>>>>>>>>> want to re-map the reserved memory to use large pages. But >>>>>>>>>>>>> since this >>>>>>>>>>>>> requires that we have a large-page-aligned memory chunk we >>>>>>>>>>>>> may >>>>>>>>>>>>> have to >>>>>>>>>>>>> fix the recently reserved memory chunk up a bit. >>>>>>>>>>>>> >>>>>>>>>>>>> We do this in ReservedSpace::initialize() by first >>>>>>>>>>>>> releasing the >>>>>>>>>>>>> memory >>>>>>>>>>>>> we just reserved. Then requesting more memory than we >>>>>>>>>>>>> actually >>>>>>>>>>>>> need to >>>>>>>>>>>>> make sure that we have enough space to do manual large page >>>>>>>>>>>>> alignment. >>>>>>>>>>>>> After we have gotten this memory we figure out a nicely >>>>>>>>>>>>> aligned start >>>>>>>>>>>>> address. We then release the memory again and then reserve >>>>>>>>>>>>> just >>>>>>>>>>>>> enough >>>>>>>>>>>>> memory but using the aligned start address as a fixed >>>>>>>>>>>>> address to make >>>>>>>>>>>>> sure that we get the memory we wanted in an aligned way. >>>>>>>>>>>>> >>>>>>>>>>>>> This is done in a loop to make sure that we eventually get >>>>>>>>>>>>> some >>>>>>>>>>>>> memory. >>>>>>>>>>>>> The interesting code looks like this: >>>>>>>>>>>>> >>>>>>>>>>>>> do { >>>>>>>>>>>>> char* extra_base = os::reserve_memory(extra_size, NULL, >>>>>>>>>>>>> alignment); >>>>>>>>>>>>> if (extra_base == NULL) return; >>>>>>>>>>>>> // Do manual alignement >>>>>>>>>>>>> base = (char*) align_size_up((uintptr_t) extra_base, >>>>>>>>>>>>> alignment); >>>>>>>>>>>>> assert(base >= extra_base, "just checking"); >>>>>>>>>>>>> // Re-reserve the region at the aligned base address. >>>>>>>>>>>>> os::release_memory(extra_base, extra_size); // (1) >>>>>>>>>>>>> base = os::reserve_memory(size, base); // (2) >>>>>>>>>>>>> } while (base == NULL); >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> There is a race here between releasing the memory in (1) and >>>>>>>>>>>>> re-reserving it in (2). But the loop is supposed to handle >>>>>>>>>>>>> this race. >>>>>>>>>>>>> >>>>>>>>>>>>> The problem is that on posix platforms you can remap the >>>>>>>>>>>>> same memory >>>>>>>>>>>>> area several times. The call in (2) will use mmap with >>>>>>>>>>>>> MAP_FIXED. >>>>>>>>>>>>> This >>>>>>>>>>>>> means that the OS will think that you know exactly what >>>>>>>>>>>>> you are >>>>>>>>>>>>> doing. >>>>>>>>>>>>> So, if part of the memory has been mapped already by the >>>>>>>>>>>>> process it >>>>>>>>>>>>> will >>>>>>>>>>>>> just go ahead and reuse that memory. >>>>>>>>>>>>> >>>>>>>>>>>>> This means that if we are having multiple threads that do >>>>>>>>>>>>> mmap. We >>>>>>>>>>>>> can >>>>>>>>>>>>> end up with a situation where we release our mapping in >>>>>>>>>>>>> (1). Then >>>>>>>>>>>>> another thread comes in and maps part of the memory that >>>>>>>>>>>>> we used to >>>>>>>>>>>>> have. Then we remap over that memory again in (2) with >>>>>>>>>>>>> MAP_FIXED. >>>>>>>>>>>>> Now we >>>>>>>>>>>>> have a situation where two threads in our process have >>>>>>>>>>>>> mapped the >>>>>>>>>>>>> same >>>>>>>>>>>>> memory. If both threads try to use it or if one of the >>>>>>>>>>>>> threads unmap >>>>>>>>>>>>> part or all of the memory we will crash. >>>>>>>>>>>>> >>>>>>>>>>>>> On posix it is possible to unmap any part of a mapped >>>>>>>>>>>>> chunk. So, our >>>>>>>>>>>>> proposed solution to the race described above is to not >>>>>>>>>>>>> unmap all >>>>>>>>>>>>> memory >>>>>>>>>>>>> in (1) but rather just unmap the section at the start and >>>>>>>>>>>>> at the >>>>>>>>>>>>> end of >>>>>>>>>>>>> the chunk that we mapped to get alignment. This also >>>>>>>>>>>>> removes the need >>>>>>>>>>>>> for the loop. >>>>>>>>>>>>> >>>>>>>>>>>>> However, on Windows you can only unmap _all_ of the memory >>>>>>>>>>>>> that you >>>>>>>>>>>>> have >>>>>>>>>>>>> mapped. On the other hand Windows also will not allow you >>>>>>>>>>>>> to map over >>>>>>>>>>>>> other mappings, so the original code is actually safe. If >>>>>>>>>>>>> we keep >>>>>>>>>>>>> the loop. >>>>>>>>>>>>> >>>>>>>>>>>>> So, our solution is to treat this differently on Windows >>>>>>>>>>>>> and posix >>>>>>>>>>>>> platforms. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Bengt >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121218/048acdf3/attachment-0001.html From daniel.daugherty at oracle.com Tue Dec 18 12:46:16 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 18 Dec 2012 13:46:16 -0700 Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code Message-ID: <50D0D618.6020001@oracle.com> Greetings, I'm sponsoring this code review request from Ron Durbin. This change is targeted at JDK8/HSX-25 in the RT_Baseline repo. Dan Sending again with correct subject line, bug URLs and webrev URL. Intro: This set of changes removes the runtimesupport for generation of debug versions that follow _g semantics. Defect: JDK-8005044 remove crufty '_g' support from HS runtime code http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 https://jbs.oracle.com/bugs/browse/JDK-8005044 Webrev http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 Details: Files have been modified to remove all reference and support for debug versions that follow _g semantics. Testing: Passed JPRT last night: Additional Testing In process: (suggested by Dan): src/share/vm/runtime/arguments.cpp - test with shared archive creation and use; see the e-mail from Coleen src/share/tools/ProjectCreator/ProjectCreator.java - just a usage message; visual inspection of the code src/os/windows/vm/os_windows.cpp - comments only; no testing needed src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp - the only code changes come into play when the "gamma" launcher is used - and when JAVA_HOME refers to a valid JDK, the function fakes up a JVM path so that callers using the JVM path to find other things in the JDK will work. - I can't find any way that the actual JVM path value that is returned is exposed - I don't see a way to test this other than have a debug printf() or manual code inspection. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121218/8aebcc8c/attachment.html From kelly.ohair at oracle.com Tue Dec 18 13:06:23 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 18 Dec 2012 13:06:23 -0800 Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <50D0D618.6020001@oracle.com> References: <50D0D618.6020001@oracle.com> Message-ID: I don't see any makefile changes. -kto On Dec 18, 2012, at 12:46 PM, Daniel D. Daugherty wrote: > Greetings, > > I'm sponsoring this code review request from Ron Durbin. This change > is targeted at JDK8/HSX-25 in the RT_Baseline repo. > > Dan > > Sending again with correct subject line, bug URLs and webrev URL. > > > Intro: > > This set of changes removes the runtimesupport for generation of debug versions that follow _g semantics. > > Defect: > JDK-8005044 remove crufty '_g' support from HS runtime code > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 > https://jbs.oracle.com/bugs/browse/JDK-8005044 > > > Webrev > http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 > > > Details: > Files have been modified to remove all reference and support for debug versions that follow _g semantics. > > Testing: > > Passed JPRT last night: > > Additional Testing In process: (suggested by Dan): > > src/share/vm/runtime/arguments.cpp > - test with shared archive creation and use; see the e-mail > from Coleen > > src/share/tools/ProjectCreator/ProjectCreator.java > - just a usage message; visual inspection of the code > > src/os/windows/vm/os_windows.cpp > - comments only; no testing needed > > src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp > - the only code changes come into play when the "gamma" > launcher is used > - and when JAVA_HOME refers to a valid JDK, the function > fakes up a JVM path so that callers using the JVM path > to find other things in the JDK will work. > - I can't find any way that the actual JVM path value > that is returned is exposed > - I don't see a way to test this other than have a debug > printf() or manual code inspection. From daniel.daugherty at oracle.com Tue Dec 18 13:11:52 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 18 Dec 2012 14:11:52 -0700 Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <50D0D618.6020001@oracle.com> References: <50D0D618.6020001@oracle.com> Message-ID: <50D0DC18.3020403@oracle.com> Just for the record: I have reviewed all of Ron's changes and I approve them. One thing I noticed of interest to launcher folks that is not due to any changes that Ron made: src/os/windows/vm/os_windows.cpp: 1718 // Find the full path to the current module, jvm.dll 1719 void os::jvm_path(char *buf, jint buflen) { 1720 // Error checking. 1721 if (buflen < MAX_PATH) { 1722 assert(false, "must use a large-enough buffer"); 1723 buf[0] = '\0'; 1724 return; 1725 } 1726 // Lazy resolve the path to current module. 1727 if (saved_jvm_path[0] != 0) { 1728 strcpy(buf, saved_jvm_path); 1729 return; 1730 } 1731 1732 buf[0] = '\0'; 1733 if (Arguments::created_by_gamma_launcher()) { 1734 // Support for the gamma launcher. Check for an 1735 // JAVA_HOME environment variable 1736 // and fix up the path so it looks like 1737 // libjvm.so is installed there (append a fake suffix 1738 // hotspot/libjvm.so). 1739 char* java_home_var = ::getenv("JAVA_HOME"); 1740 if (java_home_var != NULL && java_home_var[0] != 0) { 1741 1742 strncpy(buf, java_home_var, buflen); 1743 1744 // determine if this is a legacy image or modules image 1745 // modules image doesn't have "jre" subdirectory 1746 size_t len = strlen(buf); 1747 char* jrebin_p = buf + len; 1748 jio_snprintf(jrebin_p, buflen-len, "\\jre\\bin\\"); 1749 if (0 != _access(buf, 0)) { 1750 jio_snprintf(jrebin_p, buflen-len, "\\bin\\"); 1751 } 1752 len = strlen(buf); 1753 jio_snprintf(buf + len, buflen-len, "hotspot\\jvm.dll"); 1754 } 1755 } 1756 1757 if(buf[0] == '\0') { 1758 GetModuleFileName(vm_lib_handle, buf, buflen); 1759 } 1760 strcpy(saved_jvm_path, buf); 1761 } the block from line 1733 -> 1755 is dead code on Windows. The launcher on Windows is now called "hotspot" and is not called "gamma" so Arguments::created_by_gamma_launcher() will not return true on Windows. And one more launcher nit: $ grep gamma make/windows/makefiles/launcher.make /D LAUNCHER_TYPE=\"gamma\" \ Dan On 12/18/12 1:46 PM, Daniel D. Daugherty wrote: > Greetings, > > I'm sponsoring this code review request from Ron Durbin. This change > is targeted at JDK8/HSX-25 in the RT_Baseline repo. > > Dan > > Sending again with correct subject line, bug URLs and webrev URL. > > > Intro: > > This set of changes removes the runtimesupport for generation of debug > versions that follow _g semantics. > > Defect: > JDK-8005044 remove crufty '_g' support from HS runtime code > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 > https://jbs.oracle.com/bugs/browse/JDK-8005044 > > > Webrev > http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 > > > Details: > Files have been modified to remove all reference and support for > debug versions that follow _g semantics. > > Testing: > > Passed JPRT last night: > > Additional Testing In process: (suggested by Dan): > > src/share/vm/runtime/arguments.cpp > - test with shared archive creation and use; see the e-mail > from Coleen > > src/share/tools/ProjectCreator/ProjectCreator.java > - just a usage message; visual inspection of the code > > src/os/windows/vm/os_windows.cpp > - comments only; no testing needed > > src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp > - the only code changes come into play when the "gamma" > launcher is used > - and when JAVA_HOME refers to a valid JDK, the function > fakes up a JVM path so that callers using the JVM path > to find other things in the JDK will work. > - I can't find any way that the actual JVM path value > that is returned is exposed > - I don't see a way to test this other than have a debug > printf() or manual code inspection. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121218/5bb2eb24/attachment-0001.html From daniel.daugherty at oracle.com Tue Dec 18 13:13:55 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 18 Dec 2012 14:13:55 -0700 Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: References: <50D0D618.6020001@oracle.com> Message-ID: <50D0DC93.3030309@oracle.com> Kelly, The Makefile changes were reviewed under 7153050 last week and pushed to RT_Baseline. See the attached notification. Dan On 12/18/12 2:06 PM, Kelly O'Hair wrote: > I don't see any makefile changes. > > -kto > > On Dec 18, 2012, at 12:46 PM, Daniel D. Daugherty wrote: > >> Greetings, >> >> I'm sponsoring this code review request from Ron Durbin. This change >> is targeted at JDK8/HSX-25 in the RT_Baseline repo. >> >> Dan >> >> Sending again with correct subject line, bug URLs and webrev URL. >> >> >> Intro: >> >> This set of changes removes the runtimesupport for generation of debug versions that follow _g semantics. >> >> Defect: >> JDK-8005044 remove crufty '_g' support from HS runtime code >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 >> https://jbs.oracle.com/bugs/browse/JDK-8005044 >> >> >> Webrev >> http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 >> >> >> Details: >> Files have been modified to remove all reference and support for debug versions that follow _g semantics. >> >> Testing: >> >> Passed JPRT last night: >> >> Additional Testing In process: (suggested by Dan): >> >> src/share/vm/runtime/arguments.cpp >> - test with shared archive creation and use; see the e-mail >> from Coleen >> >> src/share/tools/ProjectCreator/ProjectCreator.java >> - just a usage message; visual inspection of the code >> >> src/os/windows/vm/os_windows.cpp >> - comments only; no testing needed >> >> src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp >> - the only code changes come into play when the "gamma" >> launcher is used >> - and when JAVA_HOME refers to a valid JDK, the function >> fakes up a JVM path so that callers using the JVM path >> to find other things in the JDK will work. >> - I can't find any way that the actual JVM path value >> that is returned is exposed >> - I don't see a way to test this other than have a debug >> printf() or manual code inspection. -------------- next part -------------- An embedded message was scrubbed... From: daniel.daugherty at oracle.com Subject: hg: hsx/hotspot-rt/hotspot: 7153050: remove crufty '_g' support from HotSpot repo makefiles Date: Sat, 15 Dec 2012 00:39:00 +0000 Size: 4186 Url: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121218/22d67472/AttachedMessage.nws From ron.durbin at oracle.com Tue Dec 18 13:18:29 2012 From: ron.durbin at oracle.com (Ron Durbin) Date: Tue, 18 Dec 2012 13:18:29 -0800 (PST) Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <50D0DC93.3030309@oracle.com> References: <50D0D618.6020001@oracle.com> <50D0DC93.3030309@oracle.com> Message-ID: <65f435f8-42ce-42a7-9abf-0a0e3029cbdf@default> Dan is correct. -----Original Message----- From: Daniel D. Daugherty Sent: Tuesday, December 18, 2012 2:14 PM To: Kelly O'Hair Cc: serviceability-dev at openjdk.java.net; build-dev; hotspot-runtime-dev at openjdk.java.net Subject: Re: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code Kelly, The Makefile changes were reviewed under 7153050 last week and pushed to RT_Baseline. See the attached notification. Dan On 12/18/12 2:06 PM, Kelly O'Hair wrote: > I don't see any makefile changes. > > -kto > > On Dec 18, 2012, at 12:46 PM, Daniel D. Daugherty wrote: > >> Greetings, >> >> I'm sponsoring this code review request from Ron Durbin. This change >> is targeted at JDK8/HSX-25 in the RT_Baseline repo. >> >> Dan >> >> Sending again with correct subject line, bug URLs and webrev URL. >> >> >> Intro: >> >> This set of changes removes the runtimesupport for generation of debug versions that follow _g semantics. >> >> Defect: >> JDK-8005044 remove crufty '_g' support from HS runtime code >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 >> https://jbs.oracle.com/bugs/browse/JDK-8005044 >> >> >> Webrev >> http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 >> >> >> Details: >> Files have been modified to remove all reference and support for debug versions that follow _g semantics. >> >> Testing: >> >> Passed JPRT last night: >> >> Additional Testing In process: (suggested by Dan): >> >> src/share/vm/runtime/arguments.cpp >> - test with shared archive creation and use; see the e-mail >> from Coleen >> >> src/share/tools/ProjectCreator/ProjectCreator.java >> - just a usage message; visual inspection of the code >> >> src/os/windows/vm/os_windows.cpp >> - comments only; no testing needed >> >> src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp >> - the only code changes come into play when the "gamma" >> launcher is used >> - and when JAVA_HOME refers to a valid JDK, the function >> fakes up a JVM path so that callers using the JVM path >> to find other things in the JDK will work. >> - I can't find any way that the actual JVM path value >> that is returned is exposed >> - I don't see a way to test this other than have a debug >> printf() or manual code inspection. From coleen.phillimore at oracle.com Tue Dec 18 13:20:18 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 18 Dec 2012 16:20:18 -0500 Subject: Request for review 8005075: CDS archive with one alignment causes crash when run with different alignment In-Reply-To: <50D0CAD5.9090608@oracle.com> References: <50CF390F.9020809@oracle.com> <50D0CAD5.9090608@oracle.com> Message-ID: <50D0DE12.7040000@oracle.com> This looks good. On 12/18/2012 02:58 PM, harold seigel wrote: > Please review the modified fix for bug 8005076. The modified fix can > be viewed at http://cr.openjdk.java.net/~hseigel/bug_8005076_2/ > > > It contains two changes from the previous fix. > > As requested by Vitaly, the diagnostic in filemap.cpp has been changed > to include the incompatible ObjectAlignmentInBytes values. Here's > sample new message: > > The shared archive file's ObjectAlignmentInBytes of 8 is too small > for the current ObjectAlignmentInBytes of 16. > > Also, the change to arguments.cpp no longer sets a minimum value for > -XX:+ObjectAlignmentInBytes. (This was requested by Coleen.) ^^ -XX:SharedReadOnlySize. Thanks, Coleen > > Thanks, Harold > > > On 12/17/2012 7:10 PM, Vitaly Davidovich wrote: >> >> Hi Harold, >> >> It might be useful to report the recorded alignment in the CDS >> archive in the diagnostic message that you print out. What do you think? >> >> Thanks >> >> Sent from my phone >> >> On Dec 17, 2012 10:24 AM, "harold seigel" > > wrote: >> >> Please review the following change to fix bug 8005075. >> >> Summary: This change prevents a crash when a CDS archive is >> created with a value for -XX:+ObjectAlignmentInBytes that is >> smaller than the ObjectAlignmentInBytes value used when running >> with -Xshare:on. This fix stores the ObjectAlignmentInBytes in >> the CDS archive so that when the archive is read, hotspot can >> compare the archive's alignment with the current alignment and >> issue the following diagnostic if the archive's alignment is too >> small: >> >> An error has occurred while processing the shared archive file. >> The shared archive file was created with a smaller Object >> Alignment value. >> >> This webrev also cleans up some text in globals.hpp and fixes a >> small problem with -XX:SharedReadOnlySize. The existing code was >> always setting SharedReadOnlySize to 14M regardless of what was >> requested. This prevented users from being able to expand the >> CDS archive's SharedReadOnly section. >> >> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8005076/ >> >> >> Bug link at http://bugs.sun.com/view_bug.do?bug_id=8005076 >> >> The changes were tested with JCK, JPRT, JTREG, and UTE tests, and >> with hand-run tests using different ObjectAlignmentInBytes values. >> >> Thanks, Harold >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121218/e8e74b02/attachment.html From kelly.ohair at oracle.com Tue Dec 18 13:31:21 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 18 Dec 2012 13:31:21 -0800 Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <65f435f8-42ce-42a7-9abf-0a0e3029cbdf@default> References: <50D0D618.6020001@oracle.com> <50D0DC93.3030309@oracle.com> <65f435f8-42ce-42a7-9abf-0a0e3029cbdf@default> Message-ID: <023777FC-D0C1-4BBF-9361-157987C0C884@oracle.com> I suspected that, but you sent it to build-dev and I was expecting makefile changes. So good to go from build-dev -kto On Dec 18, 2012, at 1:18 PM, Ron Durbin wrote: > > Dan is correct. > -----Original Message----- > From: Daniel D. Daugherty > Sent: Tuesday, December 18, 2012 2:14 PM > To: Kelly O'Hair > Cc: serviceability-dev at openjdk.java.net; build-dev; hotspot-runtime-dev at openjdk.java.net > Subject: Re: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code > > Kelly, > > The Makefile changes were reviewed under 7153050 last week and pushed to RT_Baseline. > > See the attached notification. > > Dan > > > > On 12/18/12 2:06 PM, Kelly O'Hair wrote: >> I don't see any makefile changes. >> >> -kto >> >> On Dec 18, 2012, at 12:46 PM, Daniel D. Daugherty wrote: >> >>> Greetings, >>> >>> I'm sponsoring this code review request from Ron Durbin. This change >>> is targeted at JDK8/HSX-25 in the RT_Baseline repo. >>> >>> Dan >>> >>> Sending again with correct subject line, bug URLs and webrev URL. >>> >>> >>> Intro: >>> >>> This set of changes removes the runtimesupport for generation of debug versions that follow _g semantics. >>> >>> Defect: >>> JDK-8005044 remove crufty '_g' support from HS runtime code >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 >>> https://jbs.oracle.com/bugs/browse/JDK-8005044 >>> >>> >>> Webrev >>> http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 >>> >>> >>> Details: >>> Files have been modified to remove all reference and support for debug versions that follow _g semantics. >>> >>> Testing: >>> >>> Passed JPRT last night: >>> >>> Additional Testing In process: (suggested by Dan): >>> >>> src/share/vm/runtime/arguments.cpp >>> - test with shared archive creation and use; see the e-mail >>> from Coleen >>> >>> src/share/tools/ProjectCreator/ProjectCreator.java >>> - just a usage message; visual inspection of the code >>> >>> src/os/windows/vm/os_windows.cpp >>> - comments only; no testing needed >>> >>> src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp >>> - the only code changes come into play when the "gamma" >>> launcher is used >>> - and when JAVA_HOME refers to a valid JDK, the function >>> fakes up a JVM path so that callers using the JVM path >>> to find other things in the JDK will work. >>> - I can't find any way that the actual JVM path value >>> that is returned is exposed >>> - I don't see a way to test this other than have a debug >>> printf() or manual code inspection. > From coleen.phillimore at oracle.com Tue Dec 18 13:29:05 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 18 Dec 2012 16:29:05 -0500 Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <50D0D618.6020001@oracle.com> References: <50D0D618.6020001@oracle.com> Message-ID: <50D0E021.30505@oracle.com> This looks good. Thank you for doing this. Coleen On 12/18/2012 03:46 PM, Daniel D. Daugherty wrote: > Greetings, > > I'm sponsoring this code review request from Ron Durbin. This change > is targeted at JDK8/HSX-25 in the RT_Baseline repo. > > Dan > > Sending again with correct subject line, bug URLs and webrev URL. > > > Intro: > > This set of changes removes the runtimesupport for generation of debug > versions that follow _g semantics. > > Defect: > JDK-8005044 remove crufty '_g' support from HS runtime code > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 > https://jbs.oracle.com/bugs/browse/JDK-8005044 > > > Webrev > http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 > > > Details: > Files have been modified to remove all reference and support for > debug versions that follow _g semantics. > > Testing: > > Passed JPRT last night: > > Additional Testing In process: (suggested by Dan): > > src/share/vm/runtime/arguments.cpp > - test with shared archive creation and use; see the e-mail > from Coleen > > src/share/tools/ProjectCreator/ProjectCreator.java > - just a usage message; visual inspection of the code > > src/os/windows/vm/os_windows.cpp > - comments only; no testing needed > > src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp > - the only code changes come into play when the "gamma" > launcher is used > - and when JAVA_HOME refers to a valid JDK, the function > fakes up a JVM path so that callers using the JVM path > to find other things in the JDK will work. > - I can't find any way that the actual JVM path value > that is returned is exposed > - I don't see a way to test this other than have a debug > printf() or manual code inspection. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121218/df0a8965/attachment-0001.html From harold.seigel at oracle.com Tue Dec 18 13:34:17 2012 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 18 Dec 2012 16:34:17 -0500 Subject: Request for review 8005075: CDS archive with one alignment causes crash when run with different alignment In-Reply-To: <50D0CB9E.2060106@oracle.com> References: <50CF390F.9020809@oracle.com> <50D0CB9E.2060106@oracle.com> Message-ID: <50D0E159.4040307@oracle.com> Hi Vladimir, A bigger original alignment is okay because alignment values must be powers of 2. This means that bigger alignments will always be multiples of smaller alignments. So, a bigger aligned object will also meet the requirements of a smaller alignment. For example, if the bigger alignment is 32 then the smaller alignment must be either 8 or 16. And, a 32 byte aligned object is also 8 and 16 byte aligned. Harold On 12/18/2012 3:01 PM, Vladimir Kozlov wrote: > Recording ObjectAlignmentInBytes in CDS is good. Thank you for doing it. > My question is why bigger original alignment is fine? I thought CDS > works only when it is exactly the same. > > Thanks, > Vladimir > > On 12/17/12 7:23 AM, harold seigel wrote: >> Please review the following change to fix bug 8005075. >> >> Summary: This change prevents a crash when a CDS archive is created >> with a value for -XX:+ObjectAlignmentInBytes that is smaller than the >> ObjectAlignmentInBytes value used when running with -Xshare:on. This fix >> stores the ObjectAlignmentInBytes in the CDS archive so that when the >> archive is read, hotspot can compare the archive's alignment with the >> current alignment and issue the following diagnostic if the archive's >> alignment is too small: >> >> An error has occurred while processing the shared archive file. >> The shared archive file was created with a smaller Object Alignment >> value. >> >> This webrev also cleans up some text in globals.hpp and fixes a small >> problem with -XX:SharedReadOnlySize. The existing code was always >> setting SharedReadOnlySize to 14M regardless of what was requested. >> This prevented users from being able to expand the CDS archive's >> SharedReadOnly section. >> >> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8005076/ >> >> >> Bug link at http://bugs.sun.com/view_bug.do?bug_id=8005076 >> >> The changes were tested with JCK, JPRT, JTREG, and UTE tests, and with >> hand-run tests using different ObjectAlignmentInBytes values. >> >> Thanks, Harold From harold.seigel at oracle.com Tue Dec 18 13:48:47 2012 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 18 Dec 2012 16:48:47 -0500 Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <50D0D618.6020001@oracle.com> References: <50D0D618.6020001@oracle.com> Message-ID: <50D0E4BF.305@oracle.com> Hi Ron, I think these calls to snprintf() in os_solaris.cpp and the other os_....cpp files could be replaced with calls to strncpy(). It might be a little simpler. Otherwise, it looks good. Thanks, Harold 2539 if (0 == access(buf, F_OK)) { 2540 // Use current module name "libjvm.so" 2541 len = strlen(buf); 2542 *snprintf(buf + len, buflen-len, "/hotspot/libjvm.so");* 2543 } else { 2544 // Go back to path of .so 2545 realpath((char *)dlinfo.dli_fname, buf); 2546 } On 12/18/2012 3:46 PM, Daniel D. Daugherty wrote: > Greetings, > > I'm sponsoring this code review request from Ron Durbin. This change > is targeted at JDK8/HSX-25 in the RT_Baseline repo. > > Dan > > Sending again with correct subject line, bug URLs and webrev URL. > > > Intro: > > This set of changes removes the runtimesupport for generation of debug > versions that follow _g semantics. > > Defect: > JDK-8005044 remove crufty '_g' support from HS runtime code > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 > https://jbs.oracle.com/bugs/browse/JDK-8005044 > > > Webrev > http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 > > > Details: > Files have been modified to remove all reference and support for > debug versions that follow _g semantics. > > Testing: > > Passed JPRT last night: > > Additional Testing In process: (suggested by Dan): > > src/share/vm/runtime/arguments.cpp > - test with shared archive creation and use; see the e-mail > from Coleen > > src/share/tools/ProjectCreator/ProjectCreator.java > - just a usage message; visual inspection of the code > > src/os/windows/vm/os_windows.cpp > - comments only; no testing needed > > src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp > - the only code changes come into play when the "gamma" > launcher is used > - and when JAVA_HOME refers to a valid JDK, the function > fakes up a JVM path so that callers using the JVM path > to find other things in the JDK will work. > - I can't find any way that the actual JVM path value > that is returned is exposed > - I don't see a way to test this other than have a debug > printf() or manual code inspection. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121218/d9406680/attachment.html From vladimir.kozlov at oracle.com Tue Dec 18 14:24:43 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Dec 2012 14:24:43 -0800 Subject: Request for review 8005075: CDS archive with one alignment causes crash when run with different alignment In-Reply-To: <50D0E159.4040307@oracle.com> References: <50CF390F.9020809@oracle.com> <50D0CB9E.2060106@oracle.com> <50D0E159.4040307@oracle.com> Message-ID: <50D0ED2B.2070003@oracle.com> But different alignment will require different encoding with compressed oops. How you solve that? Thanks, Vladimir On 12/18/12 1:34 PM, harold seigel wrote: > Hi Vladimir, > > A bigger original alignment is okay because alignment values must be > powers of 2. This means that bigger alignments will always be multiples > of smaller alignments. So, a bigger aligned object will also meet the > requirements of a smaller alignment. For example, if the bigger > alignment is 32 then the smaller alignment must be either 8 or 16. And, > a 32 byte aligned object is also 8 and 16 byte aligned. > > Harold > > On 12/18/2012 3:01 PM, Vladimir Kozlov wrote: >> Recording ObjectAlignmentInBytes in CDS is good. Thank you for doing it. >> My question is why bigger original alignment is fine? I thought CDS >> works only when it is exactly the same. >> >> Thanks, >> Vladimir >> >> On 12/17/12 7:23 AM, harold seigel wrote: >>> Please review the following change to fix bug 8005075. >>> >>> Summary: This change prevents a crash when a CDS archive is created >>> with a value for -XX:+ObjectAlignmentInBytes that is smaller than the >>> ObjectAlignmentInBytes value used when running with -Xshare:on. This fix >>> stores the ObjectAlignmentInBytes in the CDS archive so that when the >>> archive is read, hotspot can compare the archive's alignment with the >>> current alignment and issue the following diagnostic if the archive's >>> alignment is too small: >>> >>> An error has occurred while processing the shared archive file. >>> The shared archive file was created with a smaller Object Alignment >>> value. >>> >>> This webrev also cleans up some text in globals.hpp and fixes a small >>> problem with -XX:SharedReadOnlySize. The existing code was always >>> setting SharedReadOnlySize to 14M regardless of what was requested. >>> This prevented users from being able to expand the CDS archive's >>> SharedReadOnly section. >>> >>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8005076/ >>> >>> >>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=8005076 >>> >>> The changes were tested with JCK, JPRT, JTREG, and UTE tests, and with >>> hand-run tests using different ObjectAlignmentInBytes values. >>> >>> Thanks, Harold From daniel.daugherty at oracle.com Tue Dec 18 14:30:49 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 18 Dec 2012 15:30:49 -0700 Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <023777FC-D0C1-4BBF-9361-157987C0C884@oracle.com> References: <50D0D618.6020001@oracle.com> <50D0DC93.3030309@oracle.com> <65f435f8-42ce-42a7-9abf-0a0e3029cbdf@default> <023777FC-D0C1-4BBF-9361-157987C0C884@oracle.com> Message-ID: <50D0EE99.9030502@oracle.com> Ahhh... now I understand... The review threads for: 7153050 remove crufty '_g' support from HotSpot repo made mention of the need for fixes in the Runtime src/... files so I included all the aliases on the 7153050 review as my way of closing the loop. Ron, if you end up tackling the other two bugs, we should only include build-dev if there are Makefile changes. You may have to remind me down the road... :-) Dan On 12/18/12 2:31 PM, Kelly O'Hair wrote: > I suspected that, but you sent it to build-dev and I was expecting makefile changes. > > So good to go from build-dev > > -kto > > On Dec 18, 2012, at 1:18 PM, Ron Durbin wrote: > >> Dan is correct. >> -----Original Message----- >> From: Daniel D. Daugherty >> Sent: Tuesday, December 18, 2012 2:14 PM >> To: Kelly O'Hair >> Cc: serviceability-dev at openjdk.java.net; build-dev; hotspot-runtime-dev at openjdk.java.net >> Subject: Re: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code >> >> Kelly, >> >> The Makefile changes were reviewed under 7153050 last week and pushed to RT_Baseline. >> >> See the attached notification. >> >> Dan >> >> >> >> On 12/18/12 2:06 PM, Kelly O'Hair wrote: >>> I don't see any makefile changes. >>> >>> -kto >>> >>> On Dec 18, 2012, at 12:46 PM, Daniel D. Daugherty wrote: >>> >>>> Greetings, >>>> >>>> I'm sponsoring this code review request from Ron Durbin. This change >>>> is targeted at JDK8/HSX-25 in the RT_Baseline repo. >>>> >>>> Dan >>>> >>>> Sending again with correct subject line, bug URLs and webrev URL. >>>> >>>> >>>> Intro: >>>> >>>> This set of changes removes the runtimesupport for generation of debug versions that follow _g semantics. >>>> >>>> Defect: >>>> JDK-8005044 remove crufty '_g' support from HS runtime code >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 >>>> https://jbs.oracle.com/bugs/browse/JDK-8005044 >>>> >>>> >>>> Webrev >>>> http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 >>>> >>>> >>>> Details: >>>> Files have been modified to remove all reference and support for debug versions that follow _g semantics. >>>> >>>> Testing: >>>> >>>> Passed JPRT last night: >>>> >>>> Additional Testing In process: (suggested by Dan): >>>> >>>> src/share/vm/runtime/arguments.cpp >>>> - test with shared archive creation and use; see the e-mail >>>> from Coleen >>>> >>>> src/share/tools/ProjectCreator/ProjectCreator.java >>>> - just a usage message; visual inspection of the code >>>> >>>> src/os/windows/vm/os_windows.cpp >>>> - comments only; no testing needed >>>> >>>> src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp >>>> - the only code changes come into play when the "gamma" >>>> launcher is used >>>> - and when JAVA_HOME refers to a valid JDK, the function >>>> fakes up a JVM path so that callers using the JVM path >>>> to find other things in the JDK will work. >>>> - I can't find any way that the actual JVM path value >>>> that is returned is exposed >>>> - I don't see a way to test this other than have a debug >>>> printf() or manual code inspection. From daniel.daugherty at oracle.com Tue Dec 18 14:32:19 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 18 Dec 2012 15:32:19 -0700 Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <50D0E021.30505@oracle.com> References: <50D0D618.6020001@oracle.com> <50D0E021.30505@oracle.com> Message-ID: <50D0EEF3.5020102@oracle.com> Adding back in the other aliases... Coleen, thanks for the fast review! Dan On 12/18/12 2:29 PM, Coleen Phillimore wrote: > > This looks good. Thank you for doing this. > Coleen > > On 12/18/2012 03:46 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I'm sponsoring this code review request from Ron Durbin. This change >> is targeted at JDK8/HSX-25 in the RT_Baseline repo. >> >> Dan >> >> Sending again with correct subject line, bug URLs and webrev URL. >> >> >> Intro: >> >> This set of changes removes the runtimesupport for generation of >> debug versions that follow _g semantics. >> >> Defect: >> JDK-8005044 remove crufty '_g' support from HS runtime code >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 >> https://jbs.oracle.com/bugs/browse/JDK-8005044 >> >> >> Webrev >> http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 >> >> >> Details: >> Files have been modified to remove all reference and support for >> debug versions that follow _g semantics. >> >> Testing: >> >> Passed JPRT last night: >> >> Additional Testing In process: (suggested by Dan): >> >> src/share/vm/runtime/arguments.cpp >> - test with shared archive creation and use; see the e-mail >> from Coleen >> >> src/share/tools/ProjectCreator/ProjectCreator.java >> - just a usage message; visual inspection of the code >> >> src/os/windows/vm/os_windows.cpp >> - comments only; no testing needed >> >> src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp >> - the only code changes come into play when the "gamma" >> launcher is used >> - and when JAVA_HOME refers to a valid JDK, the function >> fakes up a JVM path so that callers using the JVM path >> to find other things in the JDK will work. >> - I can't find any way that the actual JVM path value >> that is returned is exposed >> - I don't see a way to test this other than have a debug >> printf() or manual code inspection. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121218/35246ded/attachment-0001.html From daniel.daugherty at oracle.com Tue Dec 18 14:57:20 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 18 Dec 2012 15:57:20 -0700 Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <50D0E4BF.305@oracle.com> References: <50D0D618.6020001@oracle.com> <50D0E4BF.305@oracle.com> Message-ID: <50D0F4D0.2010108@oracle.com> Adding back in the other aliases... Harold, The equivalentof: snprintf(buf, n, str); is: strncpy(buf, str, n - 1); buf[n - 1] = '\0'; because snprintf() will only write out (n-1) bytes from 'str' to 'buf'and then write a NUL in the lastslot. strncpy() copies up to 'n' bytes from'str'to 'buf'. strncpy() will not copy past aNUL character in'str', but it will also not NULterminate 'buf' if a NULis not found in 'str'before the limit 'n' is reached. Dan On 12/18/12 2:48 PM, harold seigel wrote: > Hi Ron, > > I think these calls to snprintf() in os_solaris.cpp and the other > os_....cpp files could be replaced with calls to strncpy(). It might > be a little simpler. > > Otherwise, it looks good. > > Thanks, Harold > > 2539 if (0 == access(buf, F_OK)) { > 2540 // Use current module name "libjvm.so" > 2541 len = strlen(buf); > 2542 *snprintf(buf + len, buflen-len, "/hotspot/libjvm.so");* > 2543 } else { > 2544 // Go back to path of .so > 2545 realpath((char *)dlinfo.dli_fname, buf); 2546 } > > On 12/18/2012 3:46 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I'm sponsoring this code review request from Ron Durbin. This change >> is targeted at JDK8/HSX-25 in the RT_Baseline repo. >> >> Dan >> >> Sending again with correct subject line, bug URLs and webrev URL. >> >> >> Intro: >> >> This set of changes removes the runtimesupport for generation of >> debug versions that follow _g semantics. >> >> Defect: >> JDK-8005044 remove crufty '_g' support from HS runtime code >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 >> https://jbs.oracle.com/bugs/browse/JDK-8005044 >> >> >> Webrev >> http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 >> >> >> Details: >> Files have been modified to remove all reference and support for >> debug versions that follow _g semantics. >> >> Testing: >> >> Passed JPRT last night: >> >> Additional Testing In process: (suggested by Dan): >> >> src/share/vm/runtime/arguments.cpp >> - test with shared archive creation and use; see the e-mail >> from Coleen >> >> src/share/tools/ProjectCreator/ProjectCreator.java >> - just a usage message; visual inspection of the code >> >> src/os/windows/vm/os_windows.cpp >> - comments only; no testing needed >> >> src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp >> - the only code changes come into play when the "gamma" >> launcher is used >> - and when JAVA_HOME refers to a valid JDK, the function >> fakes up a JVM path so that callers using the JVM path >> to find other things in the JDK will work. >> - I can't find any way that the actual JVM path value >> that is returned is exposed >> - I don't see a way to test this other than have a debug >> printf() or manual code inspection. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121218/b78922f5/attachment.html From daniel.daugherty at oracle.com Tue Dec 18 15:03:19 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 18 Dec 2012 16:03:19 -0700 Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <50D0F4D0.2010108@oracle.com> References: <50D0D618.6020001@oracle.com> <50D0E4BF.305@oracle.com> <50D0F4D0.2010108@oracle.com> Message-ID: <50D0F637.9080607@oracle.com> Sorry, I lost my manners somewhere... :-( Thanks for the fast review! Dan On 12/18/12 3:57 PM, Daniel D. Daugherty wrote: > Adding back in the other aliases... > > Harold, > > The equivalentof: > > snprintf(buf, n, str); > > is: > > strncpy(buf, str, n - 1); > buf[n - 1] = '\0'; > > because snprintf() will only write out (n-1) bytes from > 'str' to 'buf'and then write a NUL in the lastslot. > strncpy() copies up to 'n' bytes from'str'to 'buf'. > strncpy() will not copy past aNUL character in'str', but > it will also not NULterminate 'buf' if a NULis not found > in 'str'before the limit 'n' is reached. > > Dan > > > On 12/18/12 2:48 PM, harold seigel wrote: >> Hi Ron, >> >> I think these calls to snprintf() in os_solaris.cpp and the other >> os_....cpp files could be replaced with calls to strncpy(). It might >> be a little simpler. >> >> Otherwise, it looks good. >> >> Thanks, Harold >> >> 2539 if (0 == access(buf, F_OK)) { >> 2540 // Use current module name "libjvm.so" >> 2541 len = strlen(buf); >> 2542 *snprintf(buf + len, buflen-len, "/hotspot/libjvm.so");* >> 2543 } else { >> 2544 // Go back to path of .so >> 2545 realpath((char *)dlinfo.dli_fname, buf); 2546 } >> >> On 12/18/2012 3:46 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I'm sponsoring this code review request from Ron Durbin. This change >>> is targeted at JDK8/HSX-25 in the RT_Baseline repo. >>> >>> Dan >>> >>> Sending again with correct subject line, bug URLs and webrev URL. >>> >>> >>> Intro: >>> >>> This set of changes removes the runtimesupport for generation of >>> debug versions that follow _g semantics. >>> >>> Defect: >>> JDK-8005044 remove crufty '_g' support from HS runtime code >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 >>> https://jbs.oracle.com/bugs/browse/JDK-8005044 >>> >>> >>> Webrev >>> http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 >>> >>> >>> Details: >>> Files have been modified to remove all reference and support for >>> debug versions that follow _g semantics. >>> >>> Testing: >>> >>> Passed JPRT last night: >>> >>> Additional Testing In process: (suggested by Dan): >>> >>> src/share/vm/runtime/arguments.cpp >>> - test with shared archive creation and use; see the e-mail >>> from Coleen >>> >>> src/share/tools/ProjectCreator/ProjectCreator.java >>> - just a usage message; visual inspection of the code >>> >>> src/os/windows/vm/os_windows.cpp >>> - comments only; no testing needed >>> >>> src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp >>> - the only code changes come into play when the "gamma" >>> launcher is used >>> - and when JAVA_HOME refers to a valid JDK, the function >>> fakes up a JVM path so that callers using the JVM path >>> to find other things in the JDK will work. >>> - I can't find any way that the actual JVM path value >>> that is returned is exposed >>> - I don't see a way to test this other than have a debug >>> printf() or manual code inspection. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121218/7c5496bc/attachment-0001.html From david.holmes at oracle.com Tue Dec 18 15:21:06 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Dec 2012 09:21:06 +1000 Subject: RFR (M) 8005012: Add WB APIs to better support NMT testing In-Reply-To: <1618bca5-45ee-47d0-9ae0-18b29b72053a@default> References: <1618bca5-45ee-47d0-9ae0-18b29b72053a@default> Message-ID: <50D0FA62.6040506@oracle.com> On 19/12/2012 12:10 AM, Christian T?rnqvist wrote: > Hi everyone, > > This change is about adding three new WB APIs to better support NMT > testing. The changes are: > > ?A Test memory type, used by WB API?s NMTAllocTest and NMTFreeTestMemory > > ?Added a WaitForDataMerge WB API to be able to block until the current > generation has been merged and is visible, most of this work was done by > Zhengyu Gu. This method blocks while holding the query_lock - is that intended? Aside: the MemSnapshot::wait method is troubling me. What are you waiting upon ie what state condition? The notification is done in the destructor but how can the destructor be called if someone is calling wait() upon the object's lock ??? It means you are destroying an object that is still in use, including the lock that is being waited upon!!! David ----- > > Webrev can be found at: > > http://cr.openjdk.java.net/~ehelin/8005012/webrev.00/ > > Thanks, > > Christian > From ron.durbin at oracle.com Tue Dec 18 15:50:19 2012 From: ron.durbin at oracle.com (Ron Durbin) Date: Tue, 18 Dec 2012 15:50:19 -0800 (PST) Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <50D0F637.9080607@oracle.com> References: <50D0D618.6020001@oracle.com> <50D0E4BF.305@oracle.com> <50D0F4D0.2010108@oracle.com> <50D0F637.9080607@oracle.com> Message-ID: <07e8ed19-fa2d-42f4-a862-824530c88441@default> Thanks for the quick reviews by all. I will agree with Dan on this one, sprint will stay. Ron From: Daniel D. Daugherty Sent: Tuesday, December 18, 2012 4:03 PM To: hotspot-runtime-dev at openjdk.java.net; build-dev; serviceability-dev at openjdk.java.net Subject: Re: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code Sorry, I lost my manners somewhere... :-( Thanks for the fast review! Dan On 12/18/12 3:57 PM, Daniel D. Daugherty wrote: Adding back in the other aliases... Harold, The equivalent of: snprintf(buf, n, str); is: strncpy(buf, str, n - 1); buf[n - 1] = '\0'; because snprintf() will only write out (n - 1) bytes from 'str' to 'buf' and then write a NUL in the last slot. strncpy() copies up to 'n' bytes from 'str' to 'buf'. strncpy() will not copy past a NUL character in 'str', but it will also not NUL terminate 'buf' if a NUL is not found in 'str' before the limit 'n' is reached. Dan On 12/18/12 2:48 PM, harold seigel wrote: Hi Ron, I think these calls to snprintf() in os_solaris.cpp and the other os_....cpp files could be replaced with calls to strncpy(). It might be a little simpler. Otherwise, it looks good. Thanks, Harold 2539 if (0 == access(buf, F_OK)) { 2540 // Use current module name "libjvm.so" 2541 len = strlen(buf); 2542 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); 2543 } else { 2544 // Go back to path of .so 2545 realpath((char *)dlinfo.dli_fname, buf); 2546 } On 12/18/2012 3:46 PM, Daniel D. Daugherty wrote: Greetings, I'm sponsoring this code review request from Ron Durbin. This change is targeted at JDK8/HSX-25 in the RT_Baseline repo. Dan Sending again with correct subject line, bug URLs and webrev URL. Intro: This set of changes removes the runtime support for generation of debug versions that follow _g semantics. Defect: JDK-8005044 remove crufty '_g' support from HS runtime code http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 https://jbs.oracle.com/bugs/browse/JDK-8005044 Webrev HYPERLINK "http://cr.openjdk.java.net/%7Edcubed/for_rdurbin/8005044-webrev/0"http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 Details: Files have been modified to remove all reference and support for debug versions that follow _g semantics. Testing: Passed JPRT last night: Additional Testing In process: (suggested by Dan): src/share/vm/runtime/arguments.cpp - test with shared archive creation and use; see the e-mail from Coleen src/share/tools/ProjectCreator/ProjectCreator.java - just a usage message; visual inspection of the code src/os/windows/vm/os_windows.cpp - comments only; no testing needed src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp - the only code changes come into play when the "gamma" launcher is used - and when JAVA_HOME refers to a valid JDK, the function fakes up a JVM path so that callers using the JVM path to find other things in the JDK will work. - I can't find any way that the actual JVM path value that is returned is exposed - I don't see a way to test this other than have a debug printf() or manual code inspection. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121218/312cc428/attachment.html From erik.helin at oracle.com Wed Dec 19 00:11:15 2012 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 19 Dec 2012 09:11:15 +0100 Subject: RFR (XS): 8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag In-Reply-To: <50D0B479.5030802@oracle.com> References: <50D03CF2.6070105@oracle.com> <50D04459.8050309@oracle.com> <4b56d253-bb0f-433e-a54c-370ae6402266@default> <50D0611E.403@oracle.com> <50D0B479.5030802@oracle.com> Message-ID: <50D176A3.50105@oracle.com> Hi Vladimir, thanks for reviewing this change! See my comments inline: On 12/18/2012 07:22 PM, Vladimir Kozlov wrote: > Your test is missing copyright header which all open tests should have. Thanks, I've now added it. On 12/18/2012 07:22 PM, Vladimir Kozlov wrote: > Also swap flags, IgnoreUnrecognizedVMOptions should be first. Ok, done. I've uploaded a new webrev to: http://cr.openjdk.java.net/~ehelin/8004691/webrev.02/ What do you think of the change now? Thanks, Erik > > Thanks, > Vladimir K. > > On 12/18/12 4:27 AM, Erik Helin wrote: >> Christian, >> >> thanks for reviewing this! See comments inline: >> >> On 12/18/2012 01:16 PM, Christian T?rnqvist wrote: >>> I agree with Stefan, test/sanity could be such a place. There's >>> already a WBApi test in there. I also think the bugid directory >>> (/8004691) could be omitted since the bug id is already in the test. >> >> The latest webrev (based on the feedback by Stefan), is available here: >> >> http://cr.openjdk.java.net/~ehelin/8004691/webrev.01/ >> >> This change moves the test to the hotspot/test/sanity folder and does >> _not_ make use of a folder named after the bugid. >> >> What do you think of this change? >> >> Thanks, >> Erik >> >>> Thanks, >>> Christian >>> >>> -----Original Message----- >>> From: Stefan Karlsson >>> Sent: den 18 december 2012 11:24 >>> To: Erik Helin >>> Cc: hotspot-runtime-dev at openjdk.java.net >>> Subject: Re: RFR (XS): 8004691: Add a jtreg test that exercises the >>> ExecuteInternalVMTests flag >>> >>> Looks good. >>> >>> Though, I'd prefer if the test was not put in the gc directory, since >>> this flag could be used by all HotSpot groups. >>> >>> thanks, >>> StefanK >>> >>> On 12/18/2012 10:52 AM, Erik Helin wrote: >>>> Hi all, >>>> >>>> this change adds a jtreg test that runs the internal vm tests. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ehelin/8004691/webrev.00/ >>>> >>>> Summary: >>>> There are a couple of tests in HotSpot C++ source code that can be run >>>> with the flag -XX:+ExecuteInternalVMTests. These tests are run in JPRT >>>> queues, but they are not run as part of the nightly testing. >>>> >>>> This change adds an empty jtreg test that starts the VM with the flag >>>> -XX:+ExecuteInternalVMTests, thereby running the internal VM tests. >>>> >>>> Since -XX:+ExecuteInternalVMTests only works with a non-product build >>>> of the VM, the test also uses the flag >>>> -XX:+IgnoreUnrecognizedVMOptions to make sure the test works, but does >>>> nothing, when run with a product build of HotSpot. >>>> >>>> Testing: >>>> JPRT >>>> >>>> Thanks, >>>> Erik >>> >> From staffan.larsen at oracle.com Wed Dec 19 00:27:25 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 19 Dec 2012 09:27:25 +0100 Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <50D0DC18.3020403@oracle.com> References: <50D0D618.6020001@oracle.com> <50D0DC18.3020403@oracle.com> Message-ID: On 18 dec 2012, at 22:11, Daniel D. Daugherty wrote: > Just for the record: I have reviewed all of Ron's changes > and I approve them. > > One thing I noticed of interest to launcher folks that > is not due to any changes that Ron made: > > src/os/windows/vm/os_windows.cpp: > > 1718 // Find the full path to the current module, jvm.dll > 1719 void os::jvm_path(char *buf, jint buflen) { > 1720 // Error checking. > 1721 if (buflen < MAX_PATH) { > 1722 assert(false, "must use a large-enough buffer"); > 1723 buf[0] = '\0'; > 1724 return; > 1725 } > 1726 // Lazy resolve the path to current module. > 1727 if (saved_jvm_path[0] != 0) { > 1728 strcpy(buf, saved_jvm_path); > 1729 return; > 1730 } > 1731 > 1732 buf[0] = '\0'; > 1733 if (Arguments::created_by_gamma_launcher()) { > 1734 // Support for the gamma launcher. Check for an > 1735 // JAVA_HOME environment variable > 1736 // and fix up the path so it looks like > 1737 // libjvm.so is installed there (append a fake suffix > 1738 // hotspot/libjvm.so). > 1739 char* java_home_var = ::getenv("JAVA_HOME"); > 1740 if (java_home_var != NULL && java_home_var[0] != 0) { > 1741 > 1742 strncpy(buf, java_home_var, buflen); > 1743 > 1744 // determine if this is a legacy image or modules image > 1745 // modules image doesn't have "jre" subdirectory > 1746 size_t len = strlen(buf); > 1747 char* jrebin_p = buf + len; > 1748 jio_snprintf(jrebin_p, buflen-len, "\\jre\\bin\\"); > 1749 if (0 != _access(buf, 0)) { > 1750 jio_snprintf(jrebin_p, buflen-len, "\\bin\\"); > 1751 } > 1752 len = strlen(buf); > 1753 jio_snprintf(buf + len, buflen-len, "hotspot\\jvm.dll"); > 1754 } > 1755 } > 1756 > 1757 if(buf[0] == '\0') { > 1758 GetModuleFileName(vm_lib_handle, buf, buflen); > 1759 } > 1760 strcpy(saved_jvm_path, buf); > 1761 } > > the block from line 1733 -> 1755 is dead code on Windows. > The launcher on Windows is now called "hotspot" and is not > called "gamma" so Arguments::created_by_gamma_launcher() > will not return true on Windows. > > And one more launcher nit: > > $ grep gamma make/windows/makefiles/launcher.make > /D LAUNCHER_TYPE=\"gamma\" \ > Isn't it this line that makes it work? Arguments::created_by_gamma_launcher() essentially checks that -Dsun.java.launcher=gamma is set. And the LAUNCHER_TYPE=gamma is what sets -Dsun.java.launcher=gamma. I think, but I may be missing something? Thanks, /Staffan > Dan > > > On 12/18/12 1:46 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I'm sponsoring this code review request from Ron Durbin. This change >> is targeted at JDK8/HSX-25 in the RT_Baseline repo. >> >> Dan >> >> Sending again with correct subject line, bug URLs and webrev URL. >> >> >> Intro: >> >> This set of changes removes the runtimesupport for generation of debug versions that follow _g semantics. >> >> Defect: >> JDK-8005044 remove crufty '_g' support from HS runtime code >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 >> https://jbs.oracle.com/bugs/browse/JDK-8005044 >> >> >> Webrev >> http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 >> >> >> Details: >> Files have been modified to remove all reference and support for debug versions that follow _g semantics. >> >> Testing: >> >> Passed JPRT last night: >> >> Additional Testing In process: (suggested by Dan): >> >> src/share/vm/runtime/arguments.cpp >> - test with shared archive creation and use; see the e-mail >> from Coleen >> >> src/share/tools/ProjectCreator/ProjectCreator.java >> - just a usage message; visual inspection of the code >> >> src/os/windows/vm/os_windows.cpp >> - comments only; no testing needed >> >> src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp >> - the only code changes come into play when the "gamma" >> launcher is used >> - and when JAVA_HOME refers to a valid JDK, the function >> fakes up a JVM path so that callers using the JVM path >> to find other things in the JDK will work. >> - I can't find any way that the actual JVM path value >> that is returned is exposed >> - I don't see a way to test this other than have a debug >> printf() or manual code inspection. > From vladimir.kozlov at oracle.com Wed Dec 19 00:34:47 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Dec 2012 00:34:47 -0800 Subject: RFR (XS): 8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag In-Reply-To: <50D176A3.50105@oracle.com> References: <50D03CF2.6070105@oracle.com> <50D04459.8050309@oracle.com> <4b56d253-bb0f-433e-a54c-370ae6402266@default> <50D0611E.403@oracle.com> <50D0B479.5030802@oracle.com> <50D176A3.50105@oracle.com> Message-ID: <50D17C27.40400@oracle.com> Looks good. Thanks, Vladimir On 12/19/12 12:11 AM, Erik Helin wrote: > Hi Vladimir, > > thanks for reviewing this change! See my comments inline: > > On 12/18/2012 07:22 PM, Vladimir Kozlov wrote: >> Your test is missing copyright header which all open tests should have. > > Thanks, I've now added it. > > On 12/18/2012 07:22 PM, Vladimir Kozlov wrote: >> Also swap flags, IgnoreUnrecognizedVMOptions should be first. > > Ok, done. > > I've uploaded a new webrev to: > > http://cr.openjdk.java.net/~ehelin/8004691/webrev.02/ > > What do you think of the change now? > > Thanks, > Erik > >> >> Thanks, >> Vladimir K. >> >> On 12/18/12 4:27 AM, Erik Helin wrote: >>> Christian, >>> >>> thanks for reviewing this! See comments inline: >>> >>> On 12/18/2012 01:16 PM, Christian T?rnqvist wrote: >>>> I agree with Stefan, test/sanity could be such a place. There's >>>> already a WBApi test in there. I also think the bugid directory >>>> (/8004691) could be omitted since the bug id is already in the test. >>> >>> The latest webrev (based on the feedback by Stefan), is available here: >>> >>> http://cr.openjdk.java.net/~ehelin/8004691/webrev.01/ >>> >>> This change moves the test to the hotspot/test/sanity folder and does >>> _not_ make use of a folder named after the bugid. >>> >>> What do you think of this change? >>> >>> Thanks, >>> Erik >>> >>>> Thanks, >>>> Christian >>>> >>>> -----Original Message----- >>>> From: Stefan Karlsson >>>> Sent: den 18 december 2012 11:24 >>>> To: Erik Helin >>>> Cc: hotspot-runtime-dev at openjdk.java.net >>>> Subject: Re: RFR (XS): 8004691: Add a jtreg test that exercises the >>>> ExecuteInternalVMTests flag >>>> >>>> Looks good. >>>> >>>> Though, I'd prefer if the test was not put in the gc directory, since >>>> this flag could be used by all HotSpot groups. >>>> >>>> thanks, >>>> StefanK >>>> >>>> On 12/18/2012 10:52 AM, Erik Helin wrote: >>>>> Hi all, >>>>> >>>>> this change adds a jtreg test that runs the internal vm tests. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~ehelin/8004691/webrev.00/ >>>>> >>>>> Summary: >>>>> There are a couple of tests in HotSpot C++ source code that can be run >>>>> with the flag -XX:+ExecuteInternalVMTests. These tests are run in JPRT >>>>> queues, but they are not run as part of the nightly testing. >>>>> >>>>> This change adds an empty jtreg test that starts the VM with the flag >>>>> -XX:+ExecuteInternalVMTests, thereby running the internal VM tests. >>>>> >>>>> Since -XX:+ExecuteInternalVMTests only works with a non-product build >>>>> of the VM, the test also uses the flag >>>>> -XX:+IgnoreUnrecognizedVMOptions to make sure the test works, but does >>>>> nothing, when run with a product build of HotSpot. >>>>> >>>>> Testing: >>>>> JPRT >>>>> >>>>> Thanks, >>>>> Erik >>>> >>> > From ron.durbin at oracle.com Wed Dec 19 06:17:14 2012 From: ron.durbin at oracle.com (Ron Durbin) Date: Wed, 19 Dec 2012 06:17:14 -0800 (PST) Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <07e8ed19-fa2d-42f4-a862-824530c88441@default> References: <50D0D618.6020001@oracle.com> <50D0E4BF.305@oracle.com> <50D0F4D0.2010108@oracle.com> <50D0F637.9080607@oracle.com> <07e8ed19-fa2d-42f4-a862-824530c88441@default> Message-ID: <955b2245-7480-4af0-bd88-16eb1dd5856a@default> Harold, Did you have any more points or counter points to make on the use of snprintf and strncpy ? Ron From: Ron Durbin Sent: Tuesday, December 18, 2012 4:50 PM To: Daniel Daugherty; hotspot-runtime-dev at openjdk.java.net; build-dev; serviceability-dev at openjdk.java.net Subject: RE: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code Thanks for the quick reviews by all. I will agree with Dan on this one, sprint will stay. Ron From: Daniel D. Daugherty Sent: Tuesday, December 18, 2012 4:03 PM To: HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net; build-dev; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: Re: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code Sorry, I lost my manners somewhere... :-( Thanks for the fast review! Dan On 12/18/12 3:57 PM, Daniel D. Daugherty wrote: Adding back in the other aliases... Harold, The equivalent of: snprintf(buf, n, str); is: strncpy(buf, str, n - 1); buf[n - 1] = '\0'; because snprintf() will only write out (n - 1) bytes from 'str' to 'buf' and then write a NUL in the last slot. strncpy() copies up to 'n' bytes from 'str' to 'buf'. strncpy() will not copy past a NUL character in 'str', but it will also not NUL terminate 'buf' if a NUL is not found in 'str' before the limit 'n' is reached. Dan On 12/18/12 2:48 PM, harold seigel wrote: Hi Ron, I think these calls to snprintf() in os_solaris.cpp and the other os_....cpp files could be replaced with calls to strncpy(). It might be a little simpler. Otherwise, it looks good. Thanks, Harold 2539 if (0 == access(buf, F_OK)) { 2540 // Use current module name "libjvm.so" 2541 len = strlen(buf); 2542 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); 2543 } else { 2544 // Go back to path of .so 2545 realpath((char *)dlinfo.dli_fname, buf); 2546 } On 12/18/2012 3:46 PM, Daniel D. Daugherty wrote: Greetings, I'm sponsoring this code review request from Ron Durbin. This change is targeted at JDK8/HSX-25 in the RT_Baseline repo. Dan Sending again with correct subject line, bug URLs and webrev URL. Intro: This set of changes removes the runtime support for generation of debug versions that follow _g semantics. Defect: JDK-8005044 remove crufty '_g' support from HS runtime code http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 https://jbs.oracle.com/bugs/browse/JDK-8005044 Webrev HYPERLINK "http://cr.openjdk.java.net/%7Edcubed/for_rdurbin/8005044-webrev/0"http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 Details: Files have been modified to remove all reference and support for debug versions that follow _g semantics. Testing: Passed JPRT last night: Additional Testing In process: (suggested by Dan): src/share/vm/runtime/arguments.cpp - test with shared archive creation and use; see the e-mail from Coleen src/share/tools/ProjectCreator/ProjectCreator.java - just a usage message; visual inspection of the code src/os/windows/vm/os_windows.cpp - comments only; no testing needed src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp - the only code changes come into play when the "gamma" launcher is used - and when JAVA_HOME refers to a valid JDK, the function fakes up a JVM path so that callers using the JVM path to find other things in the JDK will work. - I can't find any way that the actual JVM path value that is returned is exposed - I don't see a way to test this other than have a debug printf() or manual code inspection. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121219/17851c4d/attachment.html From harold.seigel at oracle.com Wed Dec 19 06:51:13 2012 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 19 Dec 2012 09:51:13 -0500 Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <955b2245-7480-4af0-bd88-16eb1dd5856a@default> References: <50D0D618.6020001@oracle.com> <50D0E4BF.305@oracle.com> <50D0F4D0.2010108@oracle.com> <50D0F637.9080607@oracle.com> <07e8ed19-fa2d-42f4-a862-824530c88441@default> <955b2245-7480-4af0-bd88-16eb1dd5856a@default> Message-ID: <50D1D461.50109@oracle.com> Hi Ron, I'm ok with using snprinft(). Another nit: Is it worth checking that all of "/hotspot/libjvm.so" could get copied to buf? (i.e.: that buflen-len > strlen("/hotspot/libjvm.so") Thanks, Harold On 12/19/2012 9:17 AM, Ron Durbin wrote: > > Harold, > > Did you have any more points or counter points to make on the use of > snprintf and strncpy ? > > Ron > > *From:*Ron Durbin > *Sent:* Tuesday, December 18, 2012 4:50 PM > *To:* Daniel Daugherty; hotspot-runtime-dev at openjdk.java.net; > build-dev; serviceability-dev at openjdk.java.net > *Subject:* RE: Code Review fix for 8005044 remove crufty '_g' support > from HS runtime code > > Thanks for the quick reviews by all. > > I will agree with Dan on this one, sprint will stay. > > Ron > > *From:*Daniel D. Daugherty > *Sent:* Tuesday, December 18, 2012 4:03 PM > *To:* hotspot-runtime-dev at openjdk.java.net > ; build-dev; > serviceability-dev at openjdk.java.net > > *Subject:* Re: Code Review fix for 8005044 remove crufty '_g' support > from HS runtime code > > Sorry, I lost my manners somewhere... :-( > > Thanks for the fast review! > > Dan > > On 12/18/12 3:57 PM, Daniel D. Daugherty wrote: > > Adding back in the other aliases... > > Harold, > > The equivalent of: > > snprintf(buf, n, str); > > is: > > strncpy(buf, str, n - 1); > buf[n - 1] = '\0'; > > because snprintf() will only write out (n - 1) bytes from > 'str' to 'buf' and then write a NUL in the last slot. > strncpy() copies up to 'n' bytes from 'str' to 'buf'. > strncpy() will not copy past a NUL character in 'str', but > it will also not NUL terminate 'buf' if a NUL is not found > in 'str' before the limit 'n' is reached. > > Dan > > On 12/18/12 2:48 PM, harold seigel wrote: > > Hi Ron, > > I think these calls to snprintf() in os_solaris.cpp and the > other os_....cpp files could be replaced with calls to > strncpy(). It might be a little simpler. > > Otherwise, it looks good. > > Thanks, Harold > > 2539 if (0 == access(buf, F_OK)) { > 2540 // Use current module name "libjvm.so" > 2541 len = strlen(buf); > 2542 *snprintf(buf + len, buflen-len, "/hotspot/libjvm.so");* > 2543 } else { > 2544 // Go back to path of .so > 2545 realpath((char *)dlinfo.dli_fname, buf); 2546 } > > On 12/18/2012 3:46 PM, Daniel D. Daugherty wrote: > > Greetings, > > I'm sponsoring this code review request from Ron Durbin. This > change > is targeted at JDK8/HSX-25 in the RT_Baseline repo. > > Dan > > Sending again with correct subject line, bug URLs and webrev URL. > > > Intro: > > This set of changes removes the runtime support for generation > of debug versions that follow _g semantics. > > Defect: > JDK-8005044 remove crufty '_g' support from HS runtime code > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 > https://jbs.oracle.com/bugs/browse/JDK-8005044 > > > Webrev > http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 > > > > Details: > Files have been modified to remove all reference and support > for debug versions that follow _g semantics. > > Testing: > > Passed JPRT last night: > > Additional Testing In process: (suggested by Dan): > > src/share/vm/runtime/arguments.cpp > - test with shared archive creation and use; see the e-mail > from Coleen > > src/share/tools/ProjectCreator/ProjectCreator.java > - just a usage message; visual inspection of the code > > src/os/windows/vm/os_windows.cpp > - comments only; no testing needed > > src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp > - the only code changes come into play when the "gamma" > launcher is used > - and when JAVA_HOME refers to a valid JDK, the function > fakes up a JVM path so that callers using the JVM path > to find other things in the JDK will work. > - I can't find any way that the actual JVM path value > that is returned is exposed > - I don't see a way to test this other than have a debug > printf() or manual code inspection. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121219/b398cb2c/attachment-0001.html From daniel.daugherty at oracle.com Wed Dec 19 07:22:31 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 19 Dec 2012 08:22:31 -0700 Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: References: <50D0D618.6020001@oracle.com> <50D0DC18.3020403@oracle.com> Message-ID: <50D1DBB7.6040101@oracle.com> On 12/19/12 1:27 AM, Staffan Larsen wrote: > On 18 dec 2012, at 22:11, Daniel D. Daugherty wrote: > >> Just for the record: I have reviewed all of Ron's changes >> and I approve them. >> >> One thing I noticed of interest to launcher folks that >> is not due to any changes that Ron made: >> >> src/os/windows/vm/os_windows.cpp: >> >> 1718 // Find the full path to the current module, jvm.dll >> 1719 void os::jvm_path(char *buf, jint buflen) { >> 1720 // Error checking. >> 1721 if (buflen < MAX_PATH) { >> 1722 assert(false, "must use a large-enough buffer"); >> 1723 buf[0] = '\0'; >> 1724 return; >> 1725 } >> 1726 // Lazy resolve the path to current module. >> 1727 if (saved_jvm_path[0] != 0) { >> 1728 strcpy(buf, saved_jvm_path); >> 1729 return; >> 1730 } >> 1731 >> 1732 buf[0] = '\0'; >> 1733 if (Arguments::created_by_gamma_launcher()) { >> 1734 // Support for the gamma launcher. Check for an >> 1735 // JAVA_HOME environment variable >> 1736 // and fix up the path so it looks like >> 1737 // libjvm.so is installed there (append a fake suffix >> 1738 // hotspot/libjvm.so). >> 1739 char* java_home_var = ::getenv("JAVA_HOME"); >> 1740 if (java_home_var != NULL && java_home_var[0] != 0) { >> 1741 >> 1742 strncpy(buf, java_home_var, buflen); >> 1743 >> 1744 // determine if this is a legacy image or modules image >> 1745 // modules image doesn't have "jre" subdirectory >> 1746 size_t len = strlen(buf); >> 1747 char* jrebin_p = buf + len; >> 1748 jio_snprintf(jrebin_p, buflen-len, "\\jre\\bin\\"); >> 1749 if (0 != _access(buf, 0)) { >> 1750 jio_snprintf(jrebin_p, buflen-len, "\\bin\\"); >> 1751 } >> 1752 len = strlen(buf); >> 1753 jio_snprintf(buf + len, buflen-len, "hotspot\\jvm.dll"); >> 1754 } >> 1755 } >> 1756 >> 1757 if(buf[0] == '\0') { >> 1758 GetModuleFileName(vm_lib_handle, buf, buflen); >> 1759 } >> 1760 strcpy(saved_jvm_path, buf); >> 1761 } >> >> the block from line 1733 -> 1755 is dead code on Windows. >> The launcher on Windows is now called "hotspot" and is not >> called "gamma" so Arguments::created_by_gamma_launcher() >> will not return true on Windows. >> >> And one more launcher nit: >> >> $ grep gamma make/windows/makefiles/launcher.make >> /D LAUNCHER_TYPE=\"gamma\" \ >> > Isn't it this line that makes it work? Arguments::created_by_gamma_launcher() essentially checks that -Dsun.java.launcher=gamma is set. And the LAUNCHER_TYPE=gamma is what sets -Dsun.java.launcher=gamma. I think, but I may be missing something? > > Thanks, > /Staffan Nope you weren't missing anything. I was thinking process name is "hotspot" instead of looking more closely at how the launcher origin was determined. Just curious, when gamma was renamed to hotspot on Windows, that change wasn't made on Linux on Solaris. Any particular reason? Gory details below... Dan Chasing it back... src/os/windows/vm/os_windows.cpp: 1733 if (Arguments::created_by_gamma_launcher()) { src/share/vm/runtime/arguments.cpp: 1671 bool Arguments::created_by_gamma_launcher() { 1672 return _created_by_gamma_launcher; 1673 } 1659 void Arguments::process_java_launcher_argument(const char* launcher, void* extra_info) { 1660 _sun_java_launcher = strdup(launcher); 1661 if (strcmp("gamma", _sun_java_launcher) == 0) { 1662 _created_by_gamma_launcher = true; 1663 } 1664 } 126 // Process java launcher properties. 127 void Arguments::process_sun_java_launcher_properties(JavaVMInitArgs* args) { 128 // See if sun.java.launcher or sun.java.launcher.pid is defined. 129 // Must do this before setting up other system properties, 130 // as some of them may depend on launcher type. 131 for (int index = 0; index < args->nOptions; index++) { 132 const JavaVMOption* option = args->options + index; 133 const char* tail; 134 135 if (match_option(option, "-Dsun.java.launcher=", &tail)) { 136 process_java_launcher_argument(tail, option->extraInfo); 137 continue; 138 } src/share/tools/launcher/java.c: 1659 /* 1660 * JVM would like to know if it's created by a standard Sun launcher, or by 1661 * user native application, the following property indicates the former. 1662 */ 1663 void SetJavaLauncherProp() { 1664 AddOption("-Dsun.java.launcher=" LAUNCHER_TYPE, NULL); 1665 } make/windows/makefiles/launcher.make 26 LAUNCHER_FLAGS=$(CXX_FLAGS) $(ARCHFLAG) \ 27 /D FULL_VERSION=\"$(HOTSPOT_RELEASE_VERSION)\" \ 28 /D JDK_MAJOR_VERSION=\"$(JDK_MAJOR_VERSION)\" \ 29 /D JDK_MINOR_VERSION=\"$(JDK_MINOR_VERSION)\" \ 30 /D GAMMA \ 31 /D LAUNCHER_TYPE=\"gamma\" \ From daniel.daugherty at oracle.com Wed Dec 19 08:30:06 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 19 Dec 2012 09:30:06 -0700 Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <50D1D461.50109@oracle.com> References: <50D0D618.6020001@oracle.com> <50D0E4BF.305@oracle.com> <50D0F4D0.2010108@oracle.com> <50D0F637.9080607@oracle.com> <07e8ed19-fa2d-42f4-a862-824530c88441@default> <955b2245-7480-4af0-bd88-16eb1dd5856a@default> <50D1D461.50109@oracle.com> Message-ID: <50D1EB8E.1030302@oracle.com> Adding the other aliases back in... Harold, This question: > Another nit: Is it worth checking that all of > "/hotspot/libjvm.so"could get copied to buf? (i.e.: that > buflen-len > strlen("/hotspot/libjvm.so") is straight forward and the short answer is: yes, that code makes assumptions that "/hotspot/libjvm.so" will fit into 'buf'. It should not do that. It is Ron's callas to whether he wants to fix this existing bugas part of thiswork. It is easy enough to fix the obvious part of the bug, but... asis normal with HotSpot, there is more going on here than meets the eye... The slightly longer answer is that it probably doesn't matter because the path being created here is a fake. As long as the "/hotspot/l" part gets copied, then the callers of os::jvm_path() will be able to handle the fakery. Of course, there is an even longer answer. Read on if you want gory details(and a history lesson). This gamma launcher stuff is giving me an absolute headache. Unfortunately, there is a lot of history involved here... Here are the variations: src/os/bsd/vm/os_bsd.cpp: 1715 if (Arguments::created_by_gamma_launcher()) { 1716 // Support for the gamma launcher. Typical value for buf is 1717 // "/jre/lib///libjvm". If "/jre/lib/" appears at 1718 // the right place in the string, then assume we are installed in a JDK and 1719 // we're done. Otherwise, check for a JAVA_HOME environment variable and 1720 // construct a path to the JVM being overridden. 1762 // If the path exists within JAVA_HOME, add the JVM library name 1763 // to complete the path to JVM being overridden. Otherwise fallback 1764 // to the path to the current library. 1765 if (0 == access(buf, F_OK)) { 1766 // Use current module name "libjvm" 1767 len = strlen(buf); 1768 snprintf(buf + len, buflen-len, "/libjvm%s", JNI_LIB_SUFFIX); 1769 } else { 1770 // Fall back to path of current library 1771 rp = realpath(dli_fname, buf); 1772 if (rp == NULL) 1773 return; 1774 } src/os/linux/vm/os_linux.cpp: 2206 if (Arguments::created_by_gamma_launcher()) { 2207 // Support for the gamma launcher. Typical value for buf is 2208 // "/jre/lib///libjvm.so". If "/jre/lib/" appears at 2209 // the right place in the string, then assume we are installed in a JDK and 2210 // we're done. Otherwise, check for a JAVA_HOME environment variable and fix 2211 // up the path so it looks like libjvm.so is installed there (append a 2212 // fake suffix hotspot/libjvm.so). 2243 if (0 == access(buf, F_OK)) { 2244 // Use current module name "libjvm.so" 2245 len = strlen(buf); 2246 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); 2247 } else { 2248 // Go back to path of .so 2249 rp = realpath(dli_fname, buf); 2250 if (rp == NULL) 2251 return; 2252 } src/os/solaris/vm/os_solaris.cpp: 2496 if (Arguments::created_by_gamma_launcher()) { 2497 // Support for the gamma launcher. Typical value for buf is 2498 // "/jre/lib///libjvm.so". If "/jre/lib/" appears at 2499 // the right place in the string, then assume we are installed in a JDK and 2500 // we're done. Otherwise, check for a JAVA_HOME environment variable and fix 2501 // up the path so it looks like libjvm.so is installed there (append a 2502 // fake suffix hotspot/libjvm.so). 2539 if (0 == access(buf, F_OK)) { 2540 // Use current module name "libjvm.so" 2541 len = strlen(buf); 2542 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); 2543 } else { 2544 // Go back to path of .so 2545 realpath((char *)dlinfo.dli_fname, buf); 2546 } src/os/windows/vm/os_windows.cpp: 1732 buf[0] = '\0'; 1733 if (Arguments::created_by_gamma_launcher()) { 1734 // Support for the gamma launcher. Check for an 1735 // JAVA_HOME environment variable 1736 // and fix up the path so it looks like 1737 // libjvm.so is installed there (append a fake suffix 1738 // hotspot/libjvm.so). 1739 char* java_home_var = ::getenv("JAVA_HOME"); 1740 if (java_home_var != NULL && java_home_var[0] != 0) { 1741 1742 strncpy(buf, java_home_var, buflen); 1743 1744 // determine if this is a legacy image or modules image 1745 // modules image doesn't have "jre" subdirectory 1746 size_t len = strlen(buf); 1747 char* jrebin_p = buf + len; 1748 jio_snprintf(jrebin_p, buflen-len, "\\jre\\bin\\"); 1749 if (0 != _access(buf, 0)) { 1750 jio_snprintf(jrebin_p, buflen-len, "\\bin\\"); 1751 } 1752 len = strlen(buf); 1753 jio_snprintf(buf + len, buflen-len, "hotspot\\jvm.dll"); 1754 } 1755 } Linux, Solaris and Windows all recognize that if they get to the point where they are appending a "hotspot/..." path to the jvm_path value, then they are making a fake path. Why are they making a fake path? Well, the gamma launcher lets someone use a libjvm.so/jvm.dll that is not located in the usual place in a JDK. And, you get to use that libjvm.so/jvm.dll WITH THAT JDK. Sounds pretty cooland it is pretty cool... until you realize that there is code in the VM that tries to find other libraries _relative_ to the libjvm.so/jvm.dll that is running. Ouch! So enter the above codeblocks that fake a path to the libjvm.so/jvm.dll so that callers to os::jvm_path() don't get confused. To make matters more convoluted... yes, I know this is convoluted enough... The os_bsd.cpp doesn't seem to realize that it is creating a fake path here. At one point, the os_bsd.cpp code was a copy of os_linux.cpp code, but it was obviously tweaked. It will take more investigation to figure out the right course of action for os_bsd.cpp Dan On 12/19/12 7:51 AM, harold seigel wrote: > Hi Ron, > > I'm ok with using snprinft(). > > Another nit: Is it worth checking that all of "/hotspot/libjvm.so" > could get copied to buf? (i.e.: that buflen-len > > strlen("/hotspot/libjvm.so") > > Thanks, Harold > > On 12/19/2012 9:17 AM, Ron Durbin wrote: >> >> Harold, >> >> Did you have any more points or counter points to make on the use of >> snprintf and strncpy ? >> >> Ron >> >> *From:*Ron Durbin >> *Sent:* Tuesday, December 18, 2012 4:50 PM >> *To:* Daniel Daugherty; hotspot-runtime-dev at openjdk.java.net; >> build-dev; serviceability-dev at openjdk.java.net >> *Subject:* RE: Code Review fix for 8005044 remove crufty '_g' support >> from HS runtime code >> >> Thanks for the quick reviews by all. >> >> I will agree with Dan on this one, sprint will stay. >> >> Ron >> >> *From:*Daniel D. Daugherty >> *Sent:* Tuesday, December 18, 2012 4:03 PM >> *To:* hotspot-runtime-dev at openjdk.java.net >> ; build-dev; >> serviceability-dev at openjdk.java.net >> >> *Subject:* Re: Code Review fix for 8005044 remove crufty '_g' support >> from HS runtime code >> >> Sorry, I lost my manners somewhere... :-( >> >> Thanks for the fast review! >> >> Dan >> >> On 12/18/12 3:57 PM, Daniel D. Daugherty wrote: >> >> Adding back in the other aliases... >> >> Harold, >> >> The equivalent of: >> >> snprintf(buf, n, str); >> >> is: >> >> strncpy(buf, str, n - 1); >> buf[n - 1] = '\0'; >> >> because snprintf() will only write out (n - 1) bytes from >> 'str' to 'buf' and then write a NUL in the last slot. >> strncpy() copies up to 'n' bytes from 'str' to 'buf'. >> strncpy() will not copy past a NUL character in 'str', but >> it will also not NUL terminate 'buf' if a NUL is not found >> in 'str' before the limit 'n' is reached. >> >> Dan >> >> On 12/18/12 2:48 PM, harold seigel wrote: >> >> Hi Ron, >> >> I think these calls to snprintf() in os_solaris.cpp and the >> other os_....cpp files could be replaced with calls to >> strncpy(). It might be a little simpler. >> >> Otherwise, it looks good. >> >> Thanks, Harold >> >> 2539 if (0 == access(buf, F_OK)) { >> 2540 // Use current module name "libjvm.so" >> 2541 len = strlen(buf); >> 2542 *snprintf(buf + len, buflen-len, "/hotspot/libjvm.so");* >> 2543 } else { >> 2544 // Go back to path of .so >> 2545 realpath((char *)dlinfo.dli_fname, buf); 2546 } >> >> On 12/18/2012 3:46 PM, Daniel D. Daugherty wrote: >> >> Greetings, >> >> I'm sponsoring this code review request from Ron Durbin. This >> change >> is targeted at JDK8/HSX-25 in the RT_Baseline repo. >> >> Dan >> >> Sending again with correct subject line, bug URLs and webrev URL. >> >> >> Intro: >> >> This set of changes removes the runtime support for >> generation of debug versions that follow _g semantics. >> >> Defect: >> JDK-8005044 remove crufty '_g' support from HS runtime code >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 >> https://jbs.oracle.com/bugs/browse/JDK-8005044 >> >> >> Webrev >> http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 >> >> >> >> >> Details: >> Files have been modified to remove all reference and support >> for debug versions that follow _g semantics. >> >> Testing: >> >> Passed JPRT last night: >> >> Additional Testing In process: (suggested by Dan): >> >> src/share/vm/runtime/arguments.cpp >> - test with shared archive creation and use; see the e-mail >> from Coleen >> >> src/share/tools/ProjectCreator/ProjectCreator.java >> - just a usage message; visual inspection of the code >> >> src/os/windows/vm/os_windows.cpp >> - comments only; no testing needed >> >> src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp >> - the only code changes come into play when the "gamma" >> launcher is used >> - and when JAVA_HOME refers to a valid JDK, the function >> fakes up a JVM path so that callers using the JVM path >> to find other things in the JDK will work. >> - I can't find any way that the actual JVM path value >> that is returned is exposed >> - I don't see a way to test this other than have a debug >> printf() or manual code inspection. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121219/f9fbba09/attachment-0001.html From karen.kinnear at oracle.com Wed Dec 19 08:36:56 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 19 Dec 2012 11:36:56 -0500 Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <50D1EB8E.1030302@oracle.com> References: <50D0D618.6020001@oracle.com> <50D0E4BF.305@oracle.com> <50D0F4D0.2010108@oracle.com> <50D0F637.9080607@oracle.com> <07e8ed19-fa2d-42f4-a862-824530c88441@default> <955b2245-7480-4af0-bd88-16eb1dd5856a@default> <50D1D461.50109@oracle.com> <50D1EB8E.1030302@oracle.com> Message-ID: <75196DF1-8F29-44D2-934C-385DD4AB6AAE@oracle.com> Sounds like time to file a separate bug to track that issue down (particularly the bsd issue) and move on with this one. Thank you so much Dan for the history and details, Karen On Dec 19, 2012, at 11:30 AM, Daniel D. Daugherty wrote: > Adding the other aliases back in... > > Harold, > > This question: > > > Another nit: Is it worth checking that all of > > "/hotspot/libjvm.so" could get copied to buf? (i.e.: that > > buflen-len > strlen("/hotspot/libjvm.so") > > is straight forward and the short answer is: yes, that > code makes assumptions that "/hotspot/libjvm.so" will > fit into 'buf'. It should not do that. > > It is Ron's call as to whether he wants to fix this existing > bug as part of this work. It is easy enough to fix the obvious > part of the bug, but... as is normal with HotSpot, there > is more going on here than meets the eye... > > The slightly longer answer is that it probably doesn't > matter because the path being created here is a fake. > As long as the "/hotspot/l" part gets copied, then the > callers of os::jvm_path() will be able to handle the > fakery. > > Of course, there is an even longer answer. Read on if > you want gory details (and a history lesson). > > This gamma launcher stuff is giving me an absolute headache. > Unfortunately, there is a lot of history involved here... > > Here are the variations: > > src/os/bsd/vm/os_bsd.cpp: > > 1715 if (Arguments::created_by_gamma_launcher()) { > 1716 // Support for the gamma launcher. Typical value for buf is > 1717 // "/jre/lib///libjvm". If "/jre/lib/" appears at > 1718 // the right place in the string, then assume we are installed in a JDK and > 1719 // we're done. Otherwise, check for a JAVA_HOME environment variable and > 1720 // construct a path to the JVM being overridden. > > > > 1762 // If the path exists within JAVA_HOME, add the JVM library name > 1763 // to complete the path to JVM being overridden. Otherwise fallback > 1764 // to the path to the current library. > 1765 if (0 == access(buf, F_OK)) { > 1766 // Use current module name "libjvm" > 1767 len = strlen(buf); > 1768 snprintf(buf + len, buflen-len, "/libjvm%s", JNI_LIB_SUFFIX); > 1769 } else { > 1770 // Fall back to path of current library > 1771 rp = realpath(dli_fname, buf); > 1772 if (rp == NULL) > 1773 return; > 1774 } > > src/os/linux/vm/os_linux.cpp: > > 2206 if (Arguments::created_by_gamma_launcher()) { > 2207 // Support for the gamma launcher. Typical value for buf is > 2208 // "/jre/lib///libjvm.so". If "/jre/lib/" appears at > 2209 // the right place in the string, then assume we are installed in a JDK and > 2210 // we're done. Otherwise, check for a JAVA_HOME environment variable and fix > 2211 // up the path so it looks like libjvm.so is installed there (append a > 2212 // fake suffix hotspot/libjvm.so). > > > > 2243 if (0 == access(buf, F_OK)) { > 2244 // Use current module name "libjvm.so" > 2245 len = strlen(buf); > 2246 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); > 2247 } else { > 2248 // Go back to path of .so > 2249 rp = realpath(dli_fname, buf); > 2250 if (rp == NULL) > 2251 return; > 2252 } > > src/os/solaris/vm/os_solaris.cpp: > > 2496 if (Arguments::created_by_gamma_launcher()) { > 2497 // Support for the gamma launcher. Typical value for buf is > 2498 // "/jre/lib///libjvm.so". If "/jre/lib/" appears at > 2499 // the right place in the string, then assume we are installed in a JDK and > 2500 // we're done. Otherwise, check for a JAVA_HOME environment variable and fix > 2501 // up the path so it looks like libjvm.so is installed there (append a > 2502 // fake suffix hotspot/libjvm.so). > > > > 2539 if (0 == access(buf, F_OK)) { > 2540 // Use current module name "libjvm.so" > 2541 len = strlen(buf); > 2542 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); > 2543 } else { > 2544 // Go back to path of .so > 2545 realpath((char *)dlinfo.dli_fname, buf); > 2546 } > > src/os/windows/vm/os_windows.cpp: > > 1732 buf[0] = '\0'; > 1733 if (Arguments::created_by_gamma_launcher()) { > 1734 // Support for the gamma launcher. Check for an > 1735 // JAVA_HOME environment variable > 1736 // and fix up the path so it looks like > 1737 // libjvm.so is installed there (append a fake suffix > 1738 // hotspot/libjvm.so). > 1739 char* java_home_var = ::getenv("JAVA_HOME"); > 1740 if (java_home_var != NULL && java_home_var[0] != 0) { > 1741 > 1742 strncpy(buf, java_home_var, buflen); > 1743 > 1744 // determine if this is a legacy image or modules image > 1745 // modules image doesn't have "jre" subdirectory > 1746 size_t len = strlen(buf); > 1747 char* jrebin_p = buf + len; > 1748 jio_snprintf(jrebin_p, buflen-len, "\\jre\\bin\\"); > 1749 if (0 != _access(buf, 0)) { > 1750 jio_snprintf(jrebin_p, buflen-len, "\\bin\\"); > 1751 } > 1752 len = strlen(buf); > 1753 jio_snprintf(buf + len, buflen-len, "hotspot\\jvm.dll"); > 1754 } > 1755 } > > > Linux, Solaris and Windows all recognize that if they > get to the point where they are appending a "hotspot/..." > path to the jvm_path value, then they are making a fake > path. Why are they making a fake path? Well, the gamma > launcher lets someone use a libjvm.so/jvm.dll that is > not located in the usual place in a JDK. And, you get > to use that libjvm.so/jvm.dll WITH THAT JDK. Sounds > pretty cool and it is pretty cool... until you realize > that there is code in the VM that tries to find other > libraries _relative_ to the libjvm.so/jvm.dll that is > running. Ouch! So enter the above code blocks that fake > a path to the libjvm.so/jvm.dll so that callers to > os::jvm_path() don't get confused. > > To make matters more convoluted... yes, I know this is > convoluted enough... The os_bsd.cpp doesn't seem to > realize that it is creating a fake path here. At one > point, the os_bsd.cpp code was a copy of os_linux.cpp > code, but it was obviously tweaked. It will take more > investigation to figure out the right course of action > for os_bsd.cpp > > Dan > > > > On 12/19/12 7:51 AM, harold seigel wrote: >> Hi Ron, >> >> I'm ok with using snprinft(). >> >> Another nit: Is it worth checking that all of "/hotspot/libjvm.so" could get copied to buf? (i.e.: that buflen-len > strlen("/hotspot/libjvm.so") >> >> Thanks, Harold >> >> On 12/19/2012 9:17 AM, Ron Durbin wrote: >>> >>> >>> Harold, >>> >>> Did you have any more points or counter points to make on the use of snprintf and strncpy ? >>> >>> Ron >>> From: Ron Durbin >>> Sent: Tuesday, December 18, 2012 4:50 PM >>> To: Daniel Daugherty; hotspot-runtime-dev at openjdk.java.net; build-dev; serviceability-dev at openjdk.java.net >>> Subject: RE: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code >>> >>> Thanks for the quick reviews by all. >>> >>> I will agree with Dan on this one, sprint will stay. >>> Ron >>> >>> >>> From: Daniel D. Daugherty >>> Sent: Tuesday, December 18, 2012 4:03 PM >>> To: hotspot-runtime-dev at openjdk.java.net; build-dev; serviceability-dev at openjdk.java.net >>> Subject: Re: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code >>> >>> Sorry, I lost my manners somewhere... :-( >>> >>> Thanks for the fast review! >>> >>> Dan >>> >>> On 12/18/12 3:57 PM, Daniel D. Daugherty wrote: >>> Adding back in the other aliases... >>> >>> Harold, >>> >>> The equivalent of: >>> >>> snprintf(buf, n, str); >>> >>> is: >>> >>> strncpy(buf, str, n - 1); >>> buf[n - 1] = '\0'; >>> >>> because snprintf() will only write out (n - 1) bytes from >>> 'str' to 'buf' and then write a NUL in the last slot. >>> strncpy() copies up to 'n' bytes from 'str' to 'buf'. >>> strncpy() will not copy past a NUL character in 'str', but >>> it will also not NUL terminate 'buf' if a NUL is not found >>> in 'str' before the limit 'n' is reached. >>> >>> Dan >>> >>> On 12/18/12 2:48 PM, harold seigel wrote: >>> Hi Ron, >>> >>> I think these calls to snprintf() in os_solaris.cpp and the other os_....cpp files could be replaced with calls to strncpy(). It might be a little simpler. >>> >>> Otherwise, it looks good. >>> >>> Thanks, Harold >>> >>> 2539 if (0 == access(buf, F_OK)) { >>> 2540 // Use current module name "libjvm.so" >>> 2541 len = strlen(buf); >>> 2542 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); >>> 2543 } else { >>> 2544 // Go back to path of .so >>> 2545 realpath((char *)dlinfo.dli_fname, buf); 2546 } >>> >>> On 12/18/2012 3:46 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I'm sponsoring this code review request from Ron Durbin. This change >>> is targeted at JDK8/HSX-25 in the RT_Baseline repo. >>> >>> Dan >>> >>> Sending again with correct subject line, bug URLs and webrev URL. >>> >>> >>> Intro: >>> >>> This set of changes removes the runtime support for generation of debug versions that follow _g semantics. >>> >>> Defect: >>> JDK-8005044 remove crufty '_g' support from HS runtime code >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 >>> https://jbs.oracle.com/bugs/browse/JDK-8005044 >>> >>> >>> Webrev >>> http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 >>> >>> >>> Details: >>> Files have been modified to remove all reference and support for debug versions that follow _g semantics. >>> >>> Testing: >>> >>> Passed JPRT last night: >>> >>> Additional Testing In process: (suggested by Dan): >>> >>> src/share/vm/runtime/arguments.cpp >>> - test with shared archive creation and use; see the e-mail >>> from Coleen >>> >>> src/share/tools/ProjectCreator/ProjectCreator.java >>> - just a usage message; visual inspection of the code >>> >>> src/os/windows/vm/os_windows.cpp >>> - comments only; no testing needed >>> >>> src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp >>> - the only code changes come into play when the "gamma" >>> launcher is used >>> - and when JAVA_HOME refers to a valid JDK, the function >>> fakes up a JVM path so that callers using the JVM path >>> to find other things in the JDK will work. >>> - I can't find any way that the actual JVM path value >>> that is returned is exposed >>> - I don't see a way to test this other than have a debug >>> printf() or manual code inspection. >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121219/d2f8c98f/attachment-0001.html From ron.durbin at oracle.com Wed Dec 19 09:11:31 2012 From: ron.durbin at oracle.com (Ron Durbin) Date: Wed, 19 Dec 2012 09:11:31 -0800 (PST) Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <50D1EB8E.1030302@oracle.com> References: <50D0D618.6020001@oracle.com> <50D0E4BF.305@oracle.com> <50D0F4D0.2010108@oracle.com> <50D0F637.9080607@oracle.com> <07e8ed19-fa2d-42f4-a862-824530c88441@default> <955b2245-7480-4af0-bd88-16eb1dd5856a@default> <50D1D461.50109@oracle.com> <50D1EB8E.1030302@oracle.com> Message-ID: <684945f3-4869-4674-bf17-74193ff9ffa7@default> Harold I would say first off this is not a bug that has manifested itself yet. So it is low priority. That being said this exposure is not introduced or made more risky by my changes. This is the only issue that we have against this code review and it does not belong to the changes being reviewed=. I say file the bug merely to document the issue and get this code checked in. Ron From: Daniel D. Daugherty Sent: Wednesday, December 19, 2012 9:30 AM To: hotspot-runtime-dev at openjdk.java.net; build-dev; serviceability-dev at openjdk.java.net Subject: Re: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code Adding the other aliases back in... Harold, This question: > Another nit: Is it worth checking that all of > "/hotspot/libjvm.so" could get copied to buf? (i.e.: that > buflen-len > strlen("/hotspot/libjvm.so") is straight forward and the short answer is: yes, that code makes assumptions that "/hotspot/libjvm.so" will fit into 'buf'. It should not do that. It is Ron's call as to whether he wants to fix this existing bug as part of this work. It is easy enough to fix the obvious part of the bug, but... as is normal with HotSpot, there is more going on here than meets the eye... The slightly longer answer is that it probably doesn't matter because the path being created here is a fake. As long as the "/hotspot/l" part gets copied, then the callers of os::jvm_path() will be able to handle the fakery. Of course, there is an even longer answer. Read on if you want gory details (and a history lesson). This gamma launcher stuff is giving me an absolute headache. Unfortunately, there is a lot of history involved here... Here are the variations: src/os/bsd/vm/os_bsd.cpp: 1715 if (Arguments::created_by_gamma_launcher()) { 1716 // Support for the gamma launcher. Typical value for buf is 1717 // "/jre/lib///libjvm". If "/jre/lib/" appears at 1718 // the right place in the string, then assume we are installed in a JDK and 1719 // we're done. Otherwise, check for a JAVA_HOME environment variable and 1720 // construct a path to the JVM being overridden. 1762 // If the path exists within JAVA_HOME, add the JVM library name 1763 // to complete the path to JVM being overridden. Otherwise fallback 1764 // to the path to the current library. 1765 if (0 == access(buf, F_OK)) { 1766 // Use current module name "libjvm" 1767 len = strlen(buf); 1768 snprintf(buf + len, buflen-len, "/libjvm%s", JNI_LIB_SUFFIX); 1769 } else { 1770 // Fall back to path of current library 1771 rp = realpath(dli_fname, buf); 1772 if (rp == NULL) 1773 return; 1774 } src/os/linux/vm/os_linux.cpp: 2206 if (Arguments::created_by_gamma_launcher()) { 2207 // Support for the gamma launcher. Typical value for buf is 2208 // "/jre/lib///libjvm.so". If "/jre/lib/" appears at 2209 // the right place in the string, then assume we are installed in a JDK and 2210 // we're done. Otherwise, check for a JAVA_HOME environment variable and fix 2211 // up the path so it looks like libjvm.so is installed there (append a 2212 // fake suffix hotspot/libjvm.so). 2243 if (0 == access(buf, F_OK)) { 2244 // Use current module name "libjvm.so" 2245 len = strlen(buf); 2246 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); 2247 } else { 2248 // Go back to path of .so 2249 rp = realpath(dli_fname, buf); 2250 if (rp == NULL) 2251 return; 2252 } src/os/solaris/vm/os_solaris.cpp: 2496 if (Arguments::created_by_gamma_launcher()) { 2497 // Support for the gamma launcher. Typical value for buf is 2498 // "/jre/lib///libjvm.so". If "/jre/lib/" appears at 2499 // the right place in the string, then assume we are installed in a JDK and 2500 // we're done. Otherwise, check for a JAVA_HOME environment variable and fix 2501 // up the path so it looks like libjvm.so is installed there (append a 2502 // fake suffix hotspot/libjvm.so). 2539 if (0 == access(buf, F_OK)) { 2540 // Use current module name "libjvm.so" 2541 len = strlen(buf); 2542 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); 2543 } else { 2544 // Go back to path of .so 2545 realpath((char *)dlinfo.dli_fname, buf); 2546 } src/os/windows/vm/os_windows.cpp: 1732 buf[0] = '\0'; 1733 if (Arguments::created_by_gamma_launcher()) { 1734 // Support for the gamma launcher. Check for an 1735 // JAVA_HOME environment variable 1736 // and fix up the path so it looks like 1737 // libjvm.so is installed there (append a fake suffix 1738 // hotspot/libjvm.so). 1739 char* java_home_var = ::getenv("JAVA_HOME"); 1740 if (java_home_var != NULL && java_home_var[0] != 0) { 1741 1742 strncpy(buf, java_home_var, buflen); 1743 1744 // determine if this is a legacy image or modules image 1745 // modules image doesn't have "jre" subdirectory 1746 size_t len = strlen(buf); 1747 char* jrebin_p = buf + len; 1748 jio_snprintf(jrebin_p, buflen-len, "HYPERLINK "file:///\\jre\bin\"\\jre\\bin\\"); 1749 if (0 != _access(buf, 0)) { 1750 jio_snprintf(jrebin_p, buflen-len, "HYPERLINK "file:///\\bin\"\\bin\\"); 1751 } 1752 len = strlen(buf); 1753 jio_snprintf(buf + len, buflen-len, "hotspot\\jvm.dll"); 1754 } 1755 } Linux, Solaris and Windows all recognize that if they get to the point where they are appending a "hotspot/..." path to the jvm_path value, then they are making a fake path. Why are they making a fake path? Well, the gamma launcher lets someone use a libjvm.so/jvm.dll that is not located in the usual place in a JDK. And, you get to use that libjvm.so/jvm.dll WITH THAT JDK. Sounds pretty cool and it is pretty cool... until you realize that there is code in the VM that tries to find other libraries _relative_ to the libjvm.so/jvm.dll that is running. Ouch! So enter the above code blocks that fake a path to the libjvm.so/jvm.dll so that callers to os::jvm_path() don't get confused. To make matters more convoluted... yes, I know this is convoluted enough... The os_bsd.cpp doesn't seem to realize that it is creating a fake path here. At one point, the os_bsd.cpp code was a copy of os_linux.cpp code, but it was obviously tweaked. It will take more investigation to figure out the right course of action for os_bsd.cpp Dan On 12/19/12 7:51 AM, harold seigel wrote: Hi Ron, I'm ok with using snprinft(). Another nit: Is it worth checking that all of "/hotspot/libjvm.so" could get copied to buf? (i.e.: that buflen-len > strlen("/hotspot/libjvm.so") Thanks, Harold On 12/19/2012 9:17 AM, Ron Durbin wrote: Harold, Did you have any more points or counter points to make on the use of snprintf and strncpy ? Ron From: Ron Durbin Sent: Tuesday, December 18, 2012 4:50 PM To: Daniel Daugherty; HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net; build-dev; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: RE: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code Thanks for the quick reviews by all. I will agree with Dan on this one, sprint will stay. Ron From: Daniel D. Daugherty Sent: Tuesday, December 18, 2012 4:03 PM To: HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net; build-dev; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: Re: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code Sorry, I lost my manners somewhere... :-( Thanks for the fast review! Dan On 12/18/12 3:57 PM, Daniel D. Daugherty wrote: Adding back in the other aliases... Harold, The equivalent of: snprintf(buf, n, str); is: strncpy(buf, str, n - 1); buf[n - 1] = '\0'; because snprintf() will only write out (n - 1) bytes from 'str' to 'buf' and then write a NUL in the last slot. strncpy() copies up to 'n' bytes from 'str' to 'buf'. strncpy() will not copy past a NUL character in 'str', but it will also not NUL terminate 'buf' if a NUL is not found in 'str' before the limit 'n' is reached. Dan On 12/18/12 2:48 PM, harold seigel wrote: Hi Ron, I think these calls to snprintf() in os_solaris.cpp and the other os_....cpp files could be replaced with calls to strncpy(). It might be a little simpler. Otherwise, it looks good. Thanks, Harold 2539 if (0 == access(buf, F_OK)) { 2540 // Use current module name "libjvm.so" 2541 len = strlen(buf); 2542 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); 2543 } else { 2544 // Go back to path of .so 2545 realpath((char *)dlinfo.dli_fname, buf); 2546 } On 12/18/2012 3:46 PM, Daniel D. Daugherty wrote: Greetings, I'm sponsoring this code review request from Ron Durbin. This change is targeted at JDK8/HSX-25 in the RT_Baseline repo. Dan Sending again with correct subject line, bug URLs and webrev URL. Intro: This set of changes removes the runtime support for generation of debug versions that follow _g semantics. Defect: JDK-8005044 remove crufty '_g' support from HS runtime code http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 https://jbs.oracle.com/bugs/browse/JDK-8005044 Webrev HYPERLINK "http://cr.openjdk.java.net/%7Edcubed/for_rdurbin/8005044-webrev/0"http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 Details: Files have been modified to remove all reference and support for debug versions that follow _g semantics. Testing: Passed JPRT last night: Additional Testing In process: (suggested by Dan): src/share/vm/runtime/arguments.cpp - test with shared archive creation and use; see the e-mail from Coleen src/share/tools/ProjectCreator/ProjectCreator.java - just a usage message; visual inspection of the code src/os/windows/vm/os_windows.cpp - comments only; no testing needed src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp - the only code changes come into play when the "gamma" launcher is used - and when JAVA_HOME refers to a valid JDK, the function fakes up a JVM path so that callers using the JVM path to find other things in the JDK will work. - I can't find any way that the actual JVM path value that is returned is exposed - I don't see a way to test this other than have a debug printf() or manual code inspection. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121219/35760d4a/attachment-0001.html From harold.seigel at oracle.com Wed Dec 19 09:39:29 2012 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 19 Dec 2012 12:39:29 -0500 Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <684945f3-4869-4674-bf17-74193ff9ffa7@default> References: <50D0D618.6020001@oracle.com> <50D0E4BF.305@oracle.com> <50D0F4D0.2010108@oracle.com> <50D0F637.9080607@oracle.com> <07e8ed19-fa2d-42f4-a862-824530c88441@default> <955b2245-7480-4af0-bd88-16eb1dd5856a@default> <50D1D461.50109@oracle.com> <50D1EB8E.1030302@oracle.com> <684945f3-4869-4674-bf17-74193ff9ffa7@default> Message-ID: <50D1FBD1.3000504@oracle.com> >> I say file the bug merely to document the issue and get this code checked in I agree. Harold On 12/19/2012 12:11 PM, Ron Durbin wrote: > > Harold > > I would say first off this is not a bug that has manifested itself yet. > > So it is low priority. > > That being said this exposure is not introduced or made more risky by > my changes. > > This is the only issue that we have against this code review and it > does not belong to the changes being reviewed=. > > I say file the bug merely to document the issue and get this code > checked in. > > Ron > > *From:*Daniel D. Daugherty > *Sent:* Wednesday, December 19, 2012 9:30 AM > *To:* hotspot-runtime-dev at openjdk.java.net; build-dev; > serviceability-dev at openjdk.java.net > *Subject:* Re: Code Review fix for 8005044 remove crufty '_g' support > from HS runtime code > > Adding the other aliases back in... > > Harold, > > This question: > > > Another nit: Is it worth checking that all of > > "/hotspot/libjvm.so" could get copied to buf? (i.e.: that > > buflen-len > strlen("/hotspot/libjvm.so") > > is straight forward and the short answer is: yes, that > code makes assumptions that "/hotspot/libjvm.so" will > fit into 'buf'. It should not do that. > > It is Ron's call as to whether he wants to fix this existing > bug as part of this work. It is easy enough to fix the obvious > part of the bug, but... as is normal with HotSpot, there > is more going on here than meets the eye... > > The slightly longer answer is that it probably doesn't > matter because the path being created here is a fake. > As long as the "/hotspot/l" part gets copied, then the > callers of os::jvm_path() will be able to handle the > fakery. > > Of course, there is an even longer answer. Read on if > you want gory details (and a history lesson). > > This gamma launcher stuff is giving me an absolute headache. > Unfortunately, there is a lot of history involved here... > > Here are the variations: > > src/os/bsd/vm/os_bsd.cpp: > > 1715 if (Arguments::created_by_gamma_launcher()) { > 1716 // Support for the gamma launcher. Typical value for buf is > 1717 // "/jre/lib///libjvm". If > "/jre/lib/" appears at > 1718 // the right place in the string, then assume we are > installed in a JDK and > 1719 // we're done. Otherwise, check for a JAVA_HOME > environment variable and > 1720 // construct a path to the JVM being overridden. > > > > 1762 // If the path exists within JAVA_HOME, add the JVM > library name > 1763 // to complete the path to JVM being overridden. > Otherwise fallback > 1764 // to the path to the current library. > 1765 if (0 == access(buf, F_OK)) { > 1766 // Use current module name "libjvm" > 1767 len = strlen(buf); > 1768 snprintf(buf + len, buflen-len, "/libjvm%s", > JNI_LIB_SUFFIX); > 1769 } else { > 1770 // Fall back to path of current library > 1771 rp = realpath(dli_fname, buf); > 1772 if (rp == NULL) > 1773 return; > 1774 } > > src/os/linux/vm/os_linux.cpp: > > 2206 if (Arguments::created_by_gamma_launcher()) { > 2207 // Support for the gamma launcher. Typical value for buf is > 2208 // "/jre/lib///libjvm.so". If > "/jre/lib/" appears at > 2209 // the right place in the string, then assume we are > installed in a JDK and > 2210 // we're done. Otherwise, check for a JAVA_HOME > environment variable and fix > 2211 // up the path so it looks like libjvm.so is installed > there (append a > 2212 // fake suffix hotspot/libjvm.so). > > > > 2243 if (0 == access(buf, F_OK)) { > 2244 // Use current module name "libjvm.so" > 2245 len = strlen(buf); > 2246 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); > 2247 } else { > 2248 // Go back to path of .so > 2249 rp = realpath(dli_fname, buf); > 2250 if (rp == NULL) > 2251 return; > 2252 } > > src/os/solaris/vm/os_solaris.cpp: > > 2496 if (Arguments::created_by_gamma_launcher()) { > 2497 // Support for the gamma launcher. Typical value for buf is > 2498 // "/jre/lib///libjvm.so". If > "/jre/lib/" appears at > 2499 // the right place in the string, then assume we are > installed in a JDK and > 2500 // we're done. Otherwise, check for a JAVA_HOME > environment variable and fix > 2501 // up the path so it looks like libjvm.so is installed > there (append a > 2502 // fake suffix hotspot/libjvm.so). > > > > 2539 if (0 == access(buf, F_OK)) { > 2540 // Use current module name "libjvm.so" > 2541 len = strlen(buf); > 2542 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); > 2543 } else { > 2544 // Go back to path of .so > 2545 realpath((char *)dlinfo.dli_fname, buf); > 2546 } > > src/os/windows/vm/os_windows.cpp: > > 1732 buf[0] = '\0'; > 1733 if (Arguments::created_by_gamma_launcher()) { > 1734 // Support for the gamma launcher. Check for an > 1735 // JAVA_HOME environment variable > 1736 // and fix up the path so it looks like > 1737 // libjvm.so is installed there (append a fake suffix > 1738 // hotspot/libjvm.so). > 1739 char* java_home_var = ::getenv("JAVA_HOME"); > 1740 if (java_home_var != NULL && java_home_var[0] != 0) { > 1741 > 1742 strncpy(buf, java_home_var, buflen); > 1743 > 1744 // determine if this is a legacy image or modules image > 1745 // modules image doesn't have "jre" subdirectory > 1746 size_t len = strlen(buf); > 1747 char* jrebin_p = buf + len; > 1748 jio_snprintf(jrebin_p, buflen-len, "\\jre\\bin\\ > "); > 1749 if (0 != _access(buf, 0)) { > 1750 jio_snprintf(jrebin_p, buflen-len, "\\bin\\ > "); > 1751 } > 1752 len = strlen(buf); > 1753 jio_snprintf(buf + len, buflen-len, "hotspot\\jvm.dll"); > 1754 } > 1755 } > > > Linux, Solaris and Windows all recognize that if they > get to the point where they are appending a "hotspot/..." > path to the jvm_path value, then they are making a fake > path. Why are they making a fake path? Well, the gamma > launcher lets someone use a libjvm.so/jvm.dll that is > not located in the usual place in a JDK. And, you get > to use that libjvm.so/jvm.dll WITH THAT JDK. Sounds > pretty cool and it is pretty cool... until you realize > that there is code in the VM that tries to find other > libraries _relative_ to the libjvm.so/jvm.dll that is > running. Ouch! So enter the above code blocks that fake > a path to the libjvm.so/jvm.dll so that callers to > os::jvm_path() don't get confused. > > To make matters more convoluted... yes, I know this is > convoluted enough... The os_bsd.cpp doesn't seem to > realize that it is creating a fake path here. At one > point, the os_bsd.cpp code was a copy of os_linux.cpp > code, but it was obviously tweaked. It will take more > investigation to figure out the right course of action > for os_bsd.cpp > > Dan > > > > On 12/19/12 7:51 AM, harold seigel wrote: > > Hi Ron, > > I'm ok with using snprinft(). > > Another nit: Is it worth checking that all of "/hotspot/libjvm.so" > could get copied to buf? (i.e.: that buflen-len > > strlen("/hotspot/libjvm.so") > > Thanks, Harold > > On 12/19/2012 9:17 AM, Ron Durbin wrote: > > Harold, > > Did you have any more points or counter points to make on the use of > snprintf and strncpy ? > > Ron > > *From:*Ron Durbin > *Sent:* Tuesday, December 18, 2012 4:50 PM > *To:* Daniel Daugherty; hotspot-runtime-dev at openjdk.java.net > ; build-dev; > serviceability-dev at openjdk.java.net > > *Subject:* RE: Code Review fix for 8005044 remove crufty '_g' support > from HS runtime code > > Thanks for the quick reviews by all. > > I will agree with Dan on this one, sprint will stay. > > Ron > > *From:*Daniel D. Daugherty > *Sent:* Tuesday, December 18, 2012 4:03 PM > *To:* hotspot-runtime-dev at openjdk.java.net > ; build-dev; > serviceability-dev at openjdk.java.net > > *Subject:* Re: Code Review fix for 8005044 remove crufty '_g' support > from HS runtime code > > Sorry, I lost my manners somewhere... :-( > > Thanks for the fast review! > > Dan > > On 12/18/12 3:57 PM, Daniel D. Daugherty wrote: > > Adding back in the other aliases... > > Harold, > > The equivalent of: > > snprintf(buf, n, str); > > is: > > strncpy(buf, str, n - 1); > buf[n - 1] = '\0'; > > because snprintf() will only write out (n - 1) bytes from > 'str' to 'buf' and then write a NUL in the last slot. > strncpy() copies up to 'n' bytes from 'str' to 'buf'. > strncpy() will not copy past a NUL character in 'str', but > it will also not NUL terminate 'buf' if a NUL is not found > in 'str' before the limit 'n' is reached. > > Dan > > On 12/18/12 2:48 PM, harold seigel wrote: > > Hi Ron, > > I think these calls to snprintf() in os_solaris.cpp and the > other os_....cpp files could be replaced with calls to > strncpy(). It might be a little simpler. > > Otherwise, it looks good. > > Thanks, Harold > > 2539 if (0 == access(buf, F_OK)) { > 2540 // Use current module name "libjvm.so" > 2541 len = strlen(buf); > 2542 *snprintf(buf + len, buflen-len, "/hotspot/libjvm.so");* > 2543 } else { > 2544 // Go back to path of .so > 2545 realpath((char *)dlinfo.dli_fname, buf); 2546 } > > On 12/18/2012 3:46 PM, Daniel D. Daugherty wrote: > > Greetings, > > I'm sponsoring this code review request from Ron Durbin. This > change > is targeted at JDK8/HSX-25 in the RT_Baseline repo. > > Dan > > Sending again with correct subject line, bug URLs and webrev URL. > > > Intro: > > This set of changes removes the runtime support for generation > of debug versions that follow _g semantics. > > Defect: > JDK-8005044 remove crufty '_g' support from HS runtime code > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 > https://jbs.oracle.com/bugs/browse/JDK-8005044 > > > Webrev > http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 > > > > Details: > Files have been modified to remove all reference and support > for debug versions that follow _g semantics. > > Testing: > > Passed JPRT last night: > > Additional Testing In process: (suggested by Dan): > > src/share/vm/runtime/arguments.cpp > - test with shared archive creation and use; see the e-mail > from Coleen > > src/share/tools/ProjectCreator/ProjectCreator.java > - just a usage message; visual inspection of the code > > src/os/windows/vm/os_windows.cpp > - comments only; no testing needed > > src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp > - the only code changes come into play when the "gamma" > launcher is used > - and when JAVA_HOME refers to a valid JDK, the function > fakes up a JVM path so that callers using the JVM path > to find other things in the JDK will work. > - I can't find any way that the actual JVM path value > that is returned is exposed > - I don't see a way to test this other than have a debug > printf() or manual code inspection. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121219/d9015fd0/attachment-0001.html From staffan.larsen at oracle.com Wed Dec 19 09:55:56 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 19 Dec 2012 18:55:56 +0100 Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <50D1DBB7.6040101@oracle.com> References: <50D0D618.6020001@oracle.com> <50D0DC18.3020403@oracle.com> <50D1DBB7.6040101@oracle.com> Message-ID: <99AD299F-5BAB-400F-8DBC-58BE3A714A2F@oracle.com> On 19 dec 2012, at 16:22, Daniel D. Daugherty wrote: > On 12/19/12 1:27 AM, Staffan Larsen wrote: >> On 18 dec 2012, at 22:11, Daniel D. Daugherty wrote: >> >>> Just for the record: I have reviewed all of Ron's changes >>> and I approve them. >>> >>> One thing I noticed of interest to launcher folks that >>> is not due to any changes that Ron made: >>> >>> src/os/windows/vm/os_windows.cpp: >>> >>> 1718 // Find the full path to the current module, jvm.dll >>> 1719 void os::jvm_path(char *buf, jint buflen) { >>> 1720 // Error checking. >>> 1721 if (buflen < MAX_PATH) { >>> 1722 assert(false, "must use a large-enough buffer"); >>> 1723 buf[0] = '\0'; >>> 1724 return; >>> 1725 } >>> 1726 // Lazy resolve the path to current module. >>> 1727 if (saved_jvm_path[0] != 0) { >>> 1728 strcpy(buf, saved_jvm_path); >>> 1729 return; >>> 1730 } >>> 1731 >>> 1732 buf[0] = '\0'; >>> 1733 if (Arguments::created_by_gamma_launcher()) { >>> 1734 // Support for the gamma launcher. Check for an >>> 1735 // JAVA_HOME environment variable >>> 1736 // and fix up the path so it looks like >>> 1737 // libjvm.so is installed there (append a fake suffix >>> 1738 // hotspot/libjvm.so). >>> 1739 char* java_home_var = ::getenv("JAVA_HOME"); >>> 1740 if (java_home_var != NULL && java_home_var[0] != 0) { >>> 1741 >>> 1742 strncpy(buf, java_home_var, buflen); >>> 1743 >>> 1744 // determine if this is a legacy image or modules image >>> 1745 // modules image doesn't have "jre" subdirectory >>> 1746 size_t len = strlen(buf); >>> 1747 char* jrebin_p = buf + len; >>> 1748 jio_snprintf(jrebin_p, buflen-len, "\\jre\\bin\\"); >>> 1749 if (0 != _access(buf, 0)) { >>> 1750 jio_snprintf(jrebin_p, buflen-len, "\\bin\\"); >>> 1751 } >>> 1752 len = strlen(buf); >>> 1753 jio_snprintf(buf + len, buflen-len, "hotspot\\jvm.dll"); >>> 1754 } >>> 1755 } >>> 1756 >>> 1757 if(buf[0] == '\0') { >>> 1758 GetModuleFileName(vm_lib_handle, buf, buflen); >>> 1759 } >>> 1760 strcpy(saved_jvm_path, buf); >>> 1761 } >>> >>> the block from line 1733 -> 1755 is dead code on Windows. >>> The launcher on Windows is now called "hotspot" and is not >>> called "gamma" so Arguments::created_by_gamma_launcher() >>> will not return true on Windows. >>> >>> And one more launcher nit: >>> >>> $ grep gamma make/windows/makefiles/launcher.make >>> /D LAUNCHER_TYPE=\"gamma\" \ >>> >> Isn't it this line that makes it work? Arguments::created_by_gamma_launcher() essentially checks that -Dsun.java.launcher=gamma is set. And the LAUNCHER_TYPE=gamma is what sets -Dsun.java.launcher=gamma. I think, but I may be missing something? >> >> Thanks, >> /Staffan > > Nope you weren't missing anything. I was thinking process name > is "hotspot" instead of looking more closely at how the launcher > origin was determined. > > Just curious, when gamma was renamed to hotspot on Windows, that > change wasn't made on Linux on Solaris. Any particular reason? The "gamma" launcher still exists on Linux and Solaris, just as it were. There is a "hotspot" launcher however, which is just a script that wraps "gamma" but sets up the correct LD_LIBRARY_PATH and such. I don't think there was a "gamma" launcher on windows. /Staffan > > Gory details below... > > Dan > > > > Chasing it back... > > src/os/windows/vm/os_windows.cpp: > > 1733 if (Arguments::created_by_gamma_launcher()) { > > src/share/vm/runtime/arguments.cpp: > > 1671 bool Arguments::created_by_gamma_launcher() { > 1672 return _created_by_gamma_launcher; > 1673 } > > 1659 void Arguments::process_java_launcher_argument(const char* launcher, void* extra_info) { > 1660 _sun_java_launcher = strdup(launcher); > 1661 if (strcmp("gamma", _sun_java_launcher) == 0) { > 1662 _created_by_gamma_launcher = true; > 1663 } > 1664 } > > 126 // Process java launcher properties. > 127 void Arguments::process_sun_java_launcher_properties(JavaVMInitArgs* args) { > 128 // See if sun.java.launcher or sun.java.launcher.pid is defined. > 129 // Must do this before setting up other system properties, > 130 // as some of them may depend on launcher type. > 131 for (int index = 0; index < args->nOptions; index++) { > 132 const JavaVMOption* option = args->options + index; > 133 const char* tail; > 134 > 135 if (match_option(option, "-Dsun.java.launcher=", &tail)) { > 136 process_java_launcher_argument(tail, option->extraInfo); > 137 continue; > 138 } > > src/share/tools/launcher/java.c: > > 1659 /* > 1660 * JVM would like to know if it's created by a standard Sun launcher, or by > 1661 * user native application, the following property indicates the former. > 1662 */ > 1663 void SetJavaLauncherProp() { > 1664 AddOption("-Dsun.java.launcher=" LAUNCHER_TYPE, NULL); > 1665 } > > make/windows/makefiles/launcher.make > 26 LAUNCHER_FLAGS=$(CXX_FLAGS) $(ARCHFLAG) \ > 27 /D FULL_VERSION=\"$(HOTSPOT_RELEASE_VERSION)\" \ > 28 /D JDK_MAJOR_VERSION=\"$(JDK_MAJOR_VERSION)\" \ > 29 /D JDK_MINOR_VERSION=\"$(JDK_MINOR_VERSION)\" \ > 30 /D GAMMA \ > 31 /D LAUNCHER_TYPE=\"gamma\" \ > From daniel.daugherty at oracle.com Wed Dec 19 09:56:20 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 19 Dec 2012 10:56:20 -0700 Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <50D1DBB7.6040101@oracle.com> References: <50D0D618.6020001@oracle.com> <50D0DC18.3020403@oracle.com> <50D1DBB7.6040101@oracle.com> Message-ID: <50D1FFC4.6080401@oracle.com> Closing the loop on this question that I asked earlier: > Just curious, when gamma was renamed to hotspot on Windows, that > change wasn't made on Linux on Solaris. Any particular reason? On Solaris there is a "hotspot" shell script and a "gamma" binary. I suspect the same it true for Linux (and possibly MacOS). Dan On 12/19/12 8:22 AM, Daniel D. Daugherty wrote: > On 12/19/12 1:27 AM, Staffan Larsen wrote: >> On 18 dec 2012, at 22:11, Daniel D. Daugherty >> wrote: >> >>> Just for the record: I have reviewed all of Ron's changes >>> and I approve them. >>> >>> One thing I noticed of interest to launcher folks that >>> is not due to any changes that Ron made: >>> >>> src/os/windows/vm/os_windows.cpp: >>> >>> 1718 // Find the full path to the current module, jvm.dll >>> 1719 void os::jvm_path(char *buf, jint buflen) { >>> 1720 // Error checking. >>> 1721 if (buflen < MAX_PATH) { >>> 1722 assert(false, "must use a large-enough buffer"); >>> 1723 buf[0] = '\0'; >>> 1724 return; >>> 1725 } >>> 1726 // Lazy resolve the path to current module. >>> 1727 if (saved_jvm_path[0] != 0) { >>> 1728 strcpy(buf, saved_jvm_path); >>> 1729 return; >>> 1730 } >>> 1731 >>> 1732 buf[0] = '\0'; >>> 1733 if (Arguments::created_by_gamma_launcher()) { >>> 1734 // Support for the gamma launcher. Check for an >>> 1735 // JAVA_HOME environment variable >>> 1736 // and fix up the path so it looks like >>> 1737 // libjvm.so is installed there (append a fake suffix >>> 1738 // hotspot/libjvm.so). >>> 1739 char* java_home_var = ::getenv("JAVA_HOME"); >>> 1740 if (java_home_var != NULL && java_home_var[0] != 0) { >>> 1741 >>> 1742 strncpy(buf, java_home_var, buflen); >>> 1743 >>> 1744 // determine if this is a legacy image or modules image >>> 1745 // modules image doesn't have "jre" subdirectory >>> 1746 size_t len = strlen(buf); >>> 1747 char* jrebin_p = buf + len; >>> 1748 jio_snprintf(jrebin_p, buflen-len, "\\jre\\bin\\"); >>> 1749 if (0 != _access(buf, 0)) { >>> 1750 jio_snprintf(jrebin_p, buflen-len, "\\bin\\"); >>> 1751 } >>> 1752 len = strlen(buf); >>> 1753 jio_snprintf(buf + len, buflen-len, "hotspot\\jvm.dll"); >>> 1754 } >>> 1755 } >>> 1756 >>> 1757 if(buf[0] == '\0') { >>> 1758 GetModuleFileName(vm_lib_handle, buf, buflen); >>> 1759 } >>> 1760 strcpy(saved_jvm_path, buf); >>> 1761 } >>> >>> the block from line 1733 -> 1755 is dead code on Windows. >>> The launcher on Windows is now called "hotspot" and is not >>> called "gamma" so Arguments::created_by_gamma_launcher() >>> will not return true on Windows. >>> >>> And one more launcher nit: >>> >>> $ grep gamma make/windows/makefiles/launcher.make >>> /D LAUNCHER_TYPE=\"gamma\" \ >>> >> Isn't it this line that makes it work? >> Arguments::created_by_gamma_launcher() essentially checks that >> -Dsun.java.launcher=gamma is set. And the LAUNCHER_TYPE=gamma is what >> sets -Dsun.java.launcher=gamma. I think, but I may be missing something? >> >> Thanks, >> /Staffan > > Nope you weren't missing anything. I was thinking process name > is "hotspot" instead of looking more closely at how the launcher > origin was determined. > > Just curious, when gamma was renamed to hotspot on Windows, that > change wasn't made on Linux on Solaris. Any particular reason? > > Gory details below... > > Dan > > > > Chasing it back... > > src/os/windows/vm/os_windows.cpp: > > 1733 if (Arguments::created_by_gamma_launcher()) { > > src/share/vm/runtime/arguments.cpp: > > 1671 bool Arguments::created_by_gamma_launcher() { > 1672 return _created_by_gamma_launcher; > 1673 } > > 1659 void Arguments::process_java_launcher_argument(const char* > launcher, void* extra_info) { > 1660 _sun_java_launcher = strdup(launcher); > 1661 if (strcmp("gamma", _sun_java_launcher) == 0) { > 1662 _created_by_gamma_launcher = true; > 1663 } > 1664 } > > 126 // Process java launcher properties. > 127 void > Arguments::process_sun_java_launcher_properties(JavaVMInitArgs* args) { > 128 // See if sun.java.launcher or sun.java.launcher.pid is > defined. > 129 // Must do this before setting up other system properties, > 130 // as some of them may depend on launcher type. > 131 for (int index = 0; index < args->nOptions; index++) { > 132 const JavaVMOption* option = args->options + index; > 133 const char* tail; > 134 > 135 if (match_option(option, "-Dsun.java.launcher=", &tail)) { > 136 process_java_launcher_argument(tail, option->extraInfo); > 137 continue; > 138 } > > src/share/tools/launcher/java.c: > > 1659 /* > 1660 * JVM would like to know if it's created by a standard Sun > launcher, or by > 1661 * user native application, the following property indicates > the former. > 1662 */ > 1663 void SetJavaLauncherProp() { > 1664 AddOption("-Dsun.java.launcher=" LAUNCHER_TYPE, NULL); > 1665 } > > make/windows/makefiles/launcher.make > 26 LAUNCHER_FLAGS=$(CXX_FLAGS) $(ARCHFLAG) \ > 27 /D FULL_VERSION=\"$(HOTSPOT_RELEASE_VERSION)\" \ > 28 /D JDK_MAJOR_VERSION=\"$(JDK_MAJOR_VERSION)\" \ > 29 /D JDK_MINOR_VERSION=\"$(JDK_MINOR_VERSION)\" \ > 30 /D GAMMA \ > 31 /D LAUNCHER_TYPE=\"gamma\" \ > > > From coleen.phillimore at oracle.com Wed Dec 19 10:18:31 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 19 Dec 2012 13:18:31 -0500 Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <50D1FBD1.3000504@oracle.com> References: <50D0D618.6020001@oracle.com> <50D0E4BF.305@oracle.com> <50D0F4D0.2010108@oracle.com> <50D0F637.9080607@oracle.com> <07e8ed19-fa2d-42f4-a862-824530c88441@default> <955b2245-7480-4af0-bd88-16eb1dd5856a@default> <50D1D461.50109@oracle.com> <50D1EB8E.1030302@oracle.com> <684945f3-4869-4674-bf17-74193ff9ffa7@default> <50D1FBD1.3000504@oracle.com> Message-ID: <50D204F7.7050805@oracle.com> On 12/19/2012 12:39 PM, harold seigel wrote: > >> I say file the bug merely to document the issue and get this code > checked in > I agree. Harold, Thank you for looking at this change closely. Dan, please file a bug about the fake path and include this writeup below, because I think I hit this bug with testing CDS with the gamma launcher and it might explain it. Thanks, Coleen > > Harold > > On 12/19/2012 12:11 PM, Ron Durbin wrote: >> >> Harold >> >> I would say first off this is not a bug that has manifested itself yet. >> >> So it is low priority. >> >> That being said this exposure is not introduced or made more risky by >> my changes. >> >> This is the only issue that we have against this code review and it >> does not belong to the changes being reviewed=. >> >> I say file the bug merely to document the issue and get this code >> checked in. >> >> Ron >> >> *From:*Daniel D. Daugherty >> *Sent:* Wednesday, December 19, 2012 9:30 AM >> *To:* hotspot-runtime-dev at openjdk.java.net; build-dev; >> serviceability-dev at openjdk.java.net >> *Subject:* Re: Code Review fix for 8005044 remove crufty '_g' support >> from HS runtime code >> >> Adding the other aliases back in... >> >> Harold, >> >> This question: >> >> > Another nit: Is it worth checking that all of >> > "/hotspot/libjvm.so" could get copied to buf? (i.e.: that >> > buflen-len > strlen("/hotspot/libjvm.so") >> >> is straight forward and the short answer is: yes, that >> code makes assumptions that "/hotspot/libjvm.so" will >> fit into 'buf'. It should not do that. >> >> It is Ron's call as to whether he wants to fix this existing >> bug as part of this work. It is easy enough to fix the obvious >> part of the bug, but... as is normal with HotSpot, there >> is more going on here than meets the eye... >> >> The slightly longer answer is that it probably doesn't >> matter because the path being created here is a fake. >> As long as the "/hotspot/l" part gets copied, then the >> callers of os::jvm_path() will be able to handle the >> fakery. >> >> Of course, there is an even longer answer. Read on if >> you want gory details (and a history lesson). >> >> This gamma launcher stuff is giving me an absolute headache. >> Unfortunately, there is a lot of history involved here... >> >> Here are the variations: >> >> src/os/bsd/vm/os_bsd.cpp: >> >> 1715 if (Arguments::created_by_gamma_launcher()) { >> 1716 // Support for the gamma launcher. Typical value for buf is >> 1717 // "/jre/lib///libjvm". If >> "/jre/lib/" appears at >> 1718 // the right place in the string, then assume we are >> installed in a JDK and >> 1719 // we're done. Otherwise, check for a JAVA_HOME >> environment variable and >> 1720 // construct a path to the JVM being overridden. >> >> >> >> 1762 // If the path exists within JAVA_HOME, add the JVM >> library name >> 1763 // to complete the path to JVM being overridden. >> Otherwise fallback >> 1764 // to the path to the current library. >> 1765 if (0 == access(buf, F_OK)) { >> 1766 // Use current module name "libjvm" >> 1767 len = strlen(buf); >> 1768 snprintf(buf + len, buflen-len, "/libjvm%s", >> JNI_LIB_SUFFIX); >> 1769 } else { >> 1770 // Fall back to path of current library >> 1771 rp = realpath(dli_fname, buf); >> 1772 if (rp == NULL) >> 1773 return; >> 1774 } >> >> src/os/linux/vm/os_linux.cpp: >> >> 2206 if (Arguments::created_by_gamma_launcher()) { >> 2207 // Support for the gamma launcher. Typical value for buf is >> 2208 // "/jre/lib///libjvm.so". If >> "/jre/lib/" appears at >> 2209 // the right place in the string, then assume we are >> installed in a JDK and >> 2210 // we're done. Otherwise, check for a JAVA_HOME >> environment variable and fix >> 2211 // up the path so it looks like libjvm.so is installed >> there (append a >> 2212 // fake suffix hotspot/libjvm.so). >> >> >> >> 2243 if (0 == access(buf, F_OK)) { >> 2244 // Use current module name "libjvm.so" >> 2245 len = strlen(buf); >> 2246 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); >> 2247 } else { >> 2248 // Go back to path of .so >> 2249 rp = realpath(dli_fname, buf); >> 2250 if (rp == NULL) >> 2251 return; >> 2252 } >> >> src/os/solaris/vm/os_solaris.cpp: >> >> 2496 if (Arguments::created_by_gamma_launcher()) { >> 2497 // Support for the gamma launcher. Typical value for buf is >> 2498 // "/jre/lib///libjvm.so". If >> "/jre/lib/" appears at >> 2499 // the right place in the string, then assume we are >> installed in a JDK and >> 2500 // we're done. Otherwise, check for a JAVA_HOME >> environment variable and fix >> 2501 // up the path so it looks like libjvm.so is installed >> there (append a >> 2502 // fake suffix hotspot/libjvm.so). >> >> >> >> 2539 if (0 == access(buf, F_OK)) { >> 2540 // Use current module name "libjvm.so" >> 2541 len = strlen(buf); >> 2542 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); >> 2543 } else { >> 2544 // Go back to path of .so >> 2545 realpath((char *)dlinfo.dli_fname, buf); >> 2546 } >> >> src/os/windows/vm/os_windows.cpp: >> >> 1732 buf[0] = '\0'; >> 1733 if (Arguments::created_by_gamma_launcher()) { >> 1734 // Support for the gamma launcher. Check for an >> 1735 // JAVA_HOME environment variable >> 1736 // and fix up the path so it looks like >> 1737 // libjvm.so is installed there (append a fake suffix >> 1738 // hotspot/libjvm.so). >> 1739 char* java_home_var = ::getenv("JAVA_HOME"); >> 1740 if (java_home_var != NULL && java_home_var[0] != 0) { >> 1741 >> 1742 strncpy(buf, java_home_var, buflen); >> 1743 >> 1744 // determine if this is a legacy image or modules image >> 1745 // modules image doesn't have "jre" subdirectory >> 1746 size_t len = strlen(buf); >> 1747 char* jrebin_p = buf + len; >> 1748 jio_snprintf(jrebin_p, buflen-len, "\\jre\\bin\\ >> "); >> 1749 if (0 != _access(buf, 0)) { >> 1750 jio_snprintf(jrebin_p, buflen-len, "\\bin\\ >> "); >> 1751 } >> 1752 len = strlen(buf); >> 1753 jio_snprintf(buf + len, buflen-len, "hotspot\\jvm.dll"); >> 1754 } >> 1755 } >> >> >> Linux, Solaris and Windows all recognize that if they >> get to the point where they are appending a "hotspot/..." >> path to the jvm_path value, then they are making a fake >> path. Why are they making a fake path? Well, the gamma >> launcher lets someone use a libjvm.so/jvm.dll that is >> not located in the usual place in a JDK. And, you get >> to use that libjvm.so/jvm.dll WITH THAT JDK. Sounds >> pretty cool and it is pretty cool... until you realize >> that there is code in the VM that tries to find other >> libraries _relative_ to the libjvm.so/jvm.dll that is >> running. Ouch! So enter the above code blocks that fake >> a path to the libjvm.so/jvm.dll so that callers to >> os::jvm_path() don't get confused. >> >> To make matters more convoluted... yes, I know this is >> convoluted enough... The os_bsd.cpp doesn't seem to >> realize that it is creating a fake path here. At one >> point, the os_bsd.cpp code was a copy of os_linux.cpp >> code, but it was obviously tweaked. It will take more >> investigation to figure out the right course of action >> for os_bsd.cpp >> >> Dan >> >> >> >> On 12/19/12 7:51 AM, harold seigel wrote: >> >> Hi Ron, >> >> I'm ok with using snprinft(). >> >> Another nit: Is it worth checking that all of "/hotspot/libjvm.so" >> could get copied to buf? (i.e.: that buflen-len > >> strlen("/hotspot/libjvm.so") >> >> Thanks, Harold >> >> On 12/19/2012 9:17 AM, Ron Durbin wrote: >> >> Harold, >> >> Did you have any more points or counter points to make on the use of >> snprintf and strncpy ? >> >> Ron >> >> *From:*Ron Durbin >> *Sent:* Tuesday, December 18, 2012 4:50 PM >> *To:* Daniel Daugherty; hotspot-runtime-dev at openjdk.java.net >> ; build-dev; >> serviceability-dev at openjdk.java.net >> >> *Subject:* RE: Code Review fix for 8005044 remove crufty '_g' support >> from HS runtime code >> >> Thanks for the quick reviews by all. >> >> I will agree with Dan on this one, sprint will stay. >> >> Ron >> >> *From:*Daniel D. Daugherty >> *Sent:* Tuesday, December 18, 2012 4:03 PM >> *To:* hotspot-runtime-dev at openjdk.java.net >> ; build-dev; >> serviceability-dev at openjdk.java.net >> >> *Subject:* Re: Code Review fix for 8005044 remove crufty '_g' support >> from HS runtime code >> >> Sorry, I lost my manners somewhere... :-( >> >> Thanks for the fast review! >> >> Dan >> >> On 12/18/12 3:57 PM, Daniel D. Daugherty wrote: >> >> Adding back in the other aliases... >> >> Harold, >> >> The equivalent of: >> >> snprintf(buf, n, str); >> >> is: >> >> strncpy(buf, str, n - 1); >> buf[n - 1] = '\0'; >> >> because snprintf() will only write out (n - 1) bytes from >> 'str' to 'buf' and then write a NUL in the last slot. >> strncpy() copies up to 'n' bytes from 'str' to 'buf'. >> strncpy() will not copy past a NUL character in 'str', but >> it will also not NUL terminate 'buf' if a NUL is not found >> in 'str' before the limit 'n' is reached. >> >> Dan >> >> On 12/18/12 2:48 PM, harold seigel wrote: >> >> Hi Ron, >> >> I think these calls to snprintf() in os_solaris.cpp and the >> other os_....cpp files could be replaced with calls to >> strncpy(). It might be a little simpler. >> >> Otherwise, it looks good. >> >> Thanks, Harold >> >> 2539 if (0 == access(buf, F_OK)) { >> 2540 // Use current module name "libjvm.so" >> 2541 len = strlen(buf); >> 2542 *snprintf(buf + len, buflen-len, "/hotspot/libjvm.so");* >> 2543 } else { >> 2544 // Go back to path of .so >> 2545 realpath((char *)dlinfo.dli_fname, buf); 2546 } >> >> On 12/18/2012 3:46 PM, Daniel D. Daugherty wrote: >> >> Greetings, >> >> I'm sponsoring this code review request from Ron Durbin. This >> change >> is targeted at JDK8/HSX-25 in the RT_Baseline repo. >> >> Dan >> >> Sending again with correct subject line, bug URLs and webrev URL. >> >> >> Intro: >> >> This set of changes removes the runtime support for >> generation of debug versions that follow _g semantics. >> >> Defect: >> JDK-8005044 remove crufty '_g' support from HS runtime code >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 >> https://jbs.oracle.com/bugs/browse/JDK-8005044 >> >> >> Webrev >> http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 >> >> >> >> >> Details: >> Files have been modified to remove all reference and support >> for debug versions that follow _g semantics. >> >> Testing: >> >> Passed JPRT last night: >> >> Additional Testing In process: (suggested by Dan): >> >> src/share/vm/runtime/arguments.cpp >> - test with shared archive creation and use; see the e-mail >> from Coleen >> >> src/share/tools/ProjectCreator/ProjectCreator.java >> - just a usage message; visual inspection of the code >> >> src/os/windows/vm/os_windows.cpp >> - comments only; no testing needed >> >> src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp >> - the only code changes come into play when the "gamma" >> launcher is used >> - and when JAVA_HOME refers to a valid JDK, the function >> fakes up a JVM path so that callers using the JVM path >> to find other things in the JDK will work. >> - I can't find any way that the actual JVM path value >> that is returned is exposed >> - I don't see a way to test this other than have a debug >> printf() or manual code inspection. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121219/d78c0d66/attachment-0001.html From daniel.daugherty at oracle.com Wed Dec 19 10:37:34 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 19 Dec 2012 11:37:34 -0700 Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <50D204F7.7050805@oracle.com> References: <50D0D618.6020001@oracle.com> <50D0E4BF.305@oracle.com> <50D0F4D0.2010108@oracle.com> <50D0F637.9080607@oracle.com> <07e8ed19-fa2d-42f4-a862-824530c88441@default> <955b2245-7480-4af0-bd88-16eb1dd5856a@default> <50D1D461.50109@oracle.com> <50D1EB8E.1030302@oracle.com> <684945f3-4869-4674-bf17-74193ff9ffa7@default> <50D1FBD1.3000504@oracle.com> <50D204F7.7050805@oracle.com> Message-ID: <50D2096E.80001@oracle.com> Bug filed: JDK-8005262possible gamma launcher issues https://jbs.oracle.com/bugs/browse/JDK-8005262 Dan On 12/19/12 11:18 AM, Coleen Phillimore wrote: > On 12/19/2012 12:39 PM, harold seigel wrote: >> >> I say file the bug merely to document the issue and get this code >> checked in >> I agree. > > Harold, Thank you for looking at this change closely. > Dan, please file a bug about the fake path and include this writeup > below, because I think I hit this bug with testing CDS with the gamma > launcher and it might explain it. > Thanks, > Coleen > >> >> Harold >> >> On 12/19/2012 12:11 PM, Ron Durbin wrote: >>> >>> Harold >>> >>> I would say first off this is not a bug that has manifested itself yet. >>> >>> So it is low priority. >>> >>> That being said this exposure is not introduced or made more risky >>> by my changes. >>> >>> This is the only issue that we have against this code review and it >>> does not belong to the changes being reviewed=. >>> >>> I say file the bug merely to document the issue and get this code >>> checked in. >>> >>> Ron >>> >>> *From:*Daniel D. Daugherty >>> *Sent:* Wednesday, December 19, 2012 9:30 AM >>> *To:* hotspot-runtime-dev at openjdk.java.net; build-dev; >>> serviceability-dev at openjdk.java.net >>> *Subject:* Re: Code Review fix for 8005044 remove crufty '_g' >>> support from HS runtime code >>> >>> Adding the other aliases back in... >>> >>> Harold, >>> >>> This question: >>> >>> > Another nit: Is it worth checking that all of >>> > "/hotspot/libjvm.so" could get copied to buf? (i.e.: that >>> > buflen-len > strlen("/hotspot/libjvm.so") >>> >>> is straight forward and the short answer is: yes, that >>> code makes assumptions that "/hotspot/libjvm.so" will >>> fit into 'buf'. It should not do that. >>> >>> It is Ron's call as to whether he wants to fix this existing >>> bug as part of this work. It is easy enough to fix the obvious >>> part of the bug, but... as is normal with HotSpot, there >>> is more going on here than meets the eye... >>> >>> The slightly longer answer is that it probably doesn't >>> matter because the path being created here is a fake. >>> As long as the "/hotspot/l" part gets copied, then the >>> callers of os::jvm_path() will be able to handle the >>> fakery. >>> >>> Of course, there is an even longer answer. Read on if >>> you want gory details (and a history lesson). >>> >>> This gamma launcher stuff is giving me an absolute headache. >>> Unfortunately, there is a lot of history involved here... >>> >>> Here are the variations: >>> >>> src/os/bsd/vm/os_bsd.cpp: >>> >>> 1715 if (Arguments::created_by_gamma_launcher()) { >>> 1716 // Support for the gamma launcher. Typical value for buf is >>> 1717 // "/jre/lib///libjvm". If >>> "/jre/lib/" appears at >>> 1718 // the right place in the string, then assume we are >>> installed in a JDK and >>> 1719 // we're done. Otherwise, check for a JAVA_HOME >>> environment variable and >>> 1720 // construct a path to the JVM being overridden. >>> >>> >>> >>> 1762 // If the path exists within JAVA_HOME, add the JVM >>> library name >>> 1763 // to complete the path to JVM being overridden. >>> Otherwise fallback >>> 1764 // to the path to the current library. >>> 1765 if (0 == access(buf, F_OK)) { >>> 1766 // Use current module name "libjvm" >>> 1767 len = strlen(buf); >>> 1768 snprintf(buf + len, buflen-len, "/libjvm%s", >>> JNI_LIB_SUFFIX); >>> 1769 } else { >>> 1770 // Fall back to path of current library >>> 1771 rp = realpath(dli_fname, buf); >>> 1772 if (rp == NULL) >>> 1773 return; >>> 1774 } >>> >>> src/os/linux/vm/os_linux.cpp: >>> >>> 2206 if (Arguments::created_by_gamma_launcher()) { >>> 2207 // Support for the gamma launcher. Typical value for buf is >>> 2208 // "/jre/lib///libjvm.so". If >>> "/jre/lib/" appears at >>> 2209 // the right place in the string, then assume we are >>> installed in a JDK and >>> 2210 // we're done. Otherwise, check for a JAVA_HOME >>> environment variable and fix >>> 2211 // up the path so it looks like libjvm.so is installed >>> there (append a >>> 2212 // fake suffix hotspot/libjvm.so). >>> >>> >>> >>> 2243 if (0 == access(buf, F_OK)) { >>> 2244 // Use current module name "libjvm.so" >>> 2245 len = strlen(buf); >>> 2246 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); >>> 2247 } else { >>> 2248 // Go back to path of .so >>> 2249 rp = realpath(dli_fname, buf); >>> 2250 if (rp == NULL) >>> 2251 return; >>> 2252 } >>> >>> src/os/solaris/vm/os_solaris.cpp: >>> >>> 2496 if (Arguments::created_by_gamma_launcher()) { >>> 2497 // Support for the gamma launcher. Typical value for buf is >>> 2498 // "/jre/lib///libjvm.so". If >>> "/jre/lib/" appears at >>> 2499 // the right place in the string, then assume we are >>> installed in a JDK and >>> 2500 // we're done. Otherwise, check for a JAVA_HOME >>> environment variable and fix >>> 2501 // up the path so it looks like libjvm.so is installed >>> there (append a >>> 2502 // fake suffix hotspot/libjvm.so). >>> >>> >>> >>> 2539 if (0 == access(buf, F_OK)) { >>> 2540 // Use current module name "libjvm.so" >>> 2541 len = strlen(buf); >>> 2542 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); >>> 2543 } else { >>> 2544 // Go back to path of .so >>> 2545 realpath((char *)dlinfo.dli_fname, buf); >>> 2546 } >>> >>> src/os/windows/vm/os_windows.cpp: >>> >>> 1732 buf[0] = '\0'; >>> 1733 if (Arguments::created_by_gamma_launcher()) { >>> 1734 // Support for the gamma launcher. Check for an >>> 1735 // JAVA_HOME environment variable >>> 1736 // and fix up the path so it looks like >>> 1737 // libjvm.so is installed there (append a fake suffix >>> 1738 // hotspot/libjvm.so). >>> 1739 char* java_home_var = ::getenv("JAVA_HOME"); >>> 1740 if (java_home_var != NULL && java_home_var[0] != 0) { >>> 1741 >>> 1742 strncpy(buf, java_home_var, buflen); >>> 1743 >>> 1744 // determine if this is a legacy image or modules image >>> 1745 // modules image doesn't have "jre" subdirectory >>> 1746 size_t len = strlen(buf); >>> 1747 char* jrebin_p = buf + len; >>> 1748 jio_snprintf(jrebin_p, buflen-len, "\\jre\\bin\\ >>> "); >>> 1749 if (0 != _access(buf, 0)) { >>> 1750 jio_snprintf(jrebin_p, buflen-len, "\\bin\\ >>> "); >>> 1751 } >>> 1752 len = strlen(buf); >>> 1753 jio_snprintf(buf + len, buflen-len, "hotspot\\jvm.dll"); >>> 1754 } >>> 1755 } >>> >>> >>> Linux, Solaris and Windows all recognize that if they >>> get to the point where they are appending a "hotspot/..." >>> path to the jvm_path value, then they are making a fake >>> path. Why are they making a fake path? Well, the gamma >>> launcher lets someone use a libjvm.so/jvm.dll that is >>> not located in the usual place in a JDK. And, you get >>> to use that libjvm.so/jvm.dll WITH THAT JDK. Sounds >>> pretty cool and it is pretty cool... until you realize >>> that there is code in the VM that tries to find other >>> libraries _relative_ to the libjvm.so/jvm.dll that is >>> running. Ouch! So enter the above code blocks that fake >>> a path to the libjvm.so/jvm.dll so that callers to >>> os::jvm_path() don't get confused. >>> >>> To make matters more convoluted... yes, I know this is >>> convoluted enough... The os_bsd.cpp doesn't seem to >>> realize that it is creating a fake path here. At one >>> point, the os_bsd.cpp code was a copy of os_linux.cpp >>> code, but it was obviously tweaked. It will take more >>> investigation to figure out the right course of action >>> for os_bsd.cpp >>> >>> Dan >>> >>> >>> >>> On 12/19/12 7:51 AM, harold seigel wrote: >>> >>> Hi Ron, >>> >>> I'm ok with using snprinft(). >>> >>> Another nit: Is it worth checking that all of "/hotspot/libjvm.so" >>> could get copied to buf? (i.e.: that buflen-len > >>> strlen("/hotspot/libjvm.so") >>> >>> Thanks, Harold >>> >>> On 12/19/2012 9:17 AM, Ron Durbin wrote: >>> >>> Harold, >>> >>> Did you have any more points or counter points to make on the use of >>> snprintf and strncpy ? >>> >>> Ron >>> >>> *From:*Ron Durbin >>> *Sent:* Tuesday, December 18, 2012 4:50 PM >>> *To:* Daniel Daugherty; hotspot-runtime-dev at openjdk.java.net >>> ; build-dev; >>> serviceability-dev at openjdk.java.net >>> >>> *Subject:* RE: Code Review fix for 8005044 remove crufty '_g' >>> support from HS runtime code >>> >>> Thanks for the quick reviews by all. >>> >>> I will agree with Dan on this one, sprint will stay. >>> >>> Ron >>> >>> *From:*Daniel D. Daugherty >>> *Sent:* Tuesday, December 18, 2012 4:03 PM >>> *To:* hotspot-runtime-dev at openjdk.java.net >>> ; build-dev; >>> serviceability-dev at openjdk.java.net >>> >>> *Subject:* Re: Code Review fix for 8005044 remove crufty '_g' >>> support from HS runtime code >>> >>> Sorry, I lost my manners somewhere... :-( >>> >>> Thanks for the fast review! >>> >>> Dan >>> >>> On 12/18/12 3:57 PM, Daniel D. Daugherty wrote: >>> >>> Adding back in the other aliases... >>> >>> Harold, >>> >>> The equivalent of: >>> >>> snprintf(buf, n, str); >>> >>> is: >>> >>> strncpy(buf, str, n - 1); >>> buf[n - 1] = '\0'; >>> >>> because snprintf() will only write out (n - 1) bytes from >>> 'str' to 'buf' and then write a NUL in the last slot. >>> strncpy() copies up to 'n' bytes from 'str' to 'buf'. >>> strncpy() will not copy past a NUL character in 'str', but >>> it will also not NUL terminate 'buf' if a NUL is not found >>> in 'str' before the limit 'n' is reached. >>> >>> Dan >>> >>> On 12/18/12 2:48 PM, harold seigel wrote: >>> >>> Hi Ron, >>> >>> I think these calls to snprintf() in os_solaris.cpp and the >>> other os_....cpp files could be replaced with calls to >>> strncpy(). It might be a little simpler. >>> >>> Otherwise, it looks good. >>> >>> Thanks, Harold >>> >>> 2539 if (0 == access(buf, F_OK)) { >>> 2540 // Use current module name "libjvm.so" >>> 2541 len = strlen(buf); >>> 2542 *snprintf(buf + len, buflen-len, "/hotspot/libjvm.so");* >>> 2543 } else { >>> 2544 // Go back to path of .so >>> 2545 realpath((char *)dlinfo.dli_fname, buf); 2546 } >>> >>> On 12/18/2012 3:46 PM, Daniel D. Daugherty wrote: >>> >>> Greetings, >>> >>> I'm sponsoring this code review request from Ron Durbin. >>> This change >>> is targeted at JDK8/HSX-25 in the RT_Baseline repo. >>> >>> Dan >>> >>> Sending again with correct subject line, bug URLs and webrev >>> URL. >>> >>> >>> Intro: >>> >>> This set of changes removes the runtime support for >>> generation of debug versions that follow _g semantics. >>> >>> Defect: >>> JDK-8005044 remove crufty '_g' support from HS runtime code >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 >>> https://jbs.oracle.com/bugs/browse/JDK-8005044 >>> >>> >>> Webrev >>> http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 >>> >>> >>> >>> >>> Details: >>> Files have been modified to remove all reference and support >>> for debug versions that follow _g semantics. >>> >>> Testing: >>> >>> Passed JPRT last night: >>> >>> Additional Testing In process: (suggested by Dan): >>> >>> src/share/vm/runtime/arguments.cpp >>> - test with shared archive creation and use; see the e-mail >>> from Coleen >>> >>> src/share/tools/ProjectCreator/ProjectCreator.java >>> - just a usage message; visual inspection of the code >>> >>> src/os/windows/vm/os_windows.cpp >>> - comments only; no testing needed >>> >>> src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp >>> - the only code changes come into play when the "gamma" >>> launcher is used >>> - and when JAVA_HOME refers to a valid JDK, the function >>> fakes up a JVM path so that callers using the JVM path >>> to find other things in the JDK will work. >>> - I can't find any way that the actual JVM path value >>> that is returned is exposed >>> - I don't see a way to test this other than have a debug >>> printf() or manual code inspection. >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121219/e03f2d2e/attachment-0001.html From ron.durbin at oracle.com Wed Dec 19 10:42:12 2012 From: ron.durbin at oracle.com (Ron Durbin) Date: Wed, 19 Dec 2012 10:42:12 -0800 (PST) Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <50D2096E.80001@oracle.com> References: <50D0D618.6020001@oracle.com> <50D0E4BF.305@oracle.com> <50D0F4D0.2010108@oracle.com> <50D0F637.9080607@oracle.com> <07e8ed19-fa2d-42f4-a862-824530c88441@default> <955b2245-7480-4af0-bd88-16eb1dd5856a@default> <50D1D461.50109@oracle.com> <50D1EB8E.1030302@oracle.com> <684945f3-4869-4674-bf17-74193ff9ffa7@default> <50D1FBD1.3000504@oracle.com> <50D204F7.7050805@oracle.com> <50D2096E.80001@oracle.com> Message-ID: Coleen If we are hitting this in an existing test. Would this not raise the priority? From: Daniel D. Daugherty Sent: Wednesday, December 19, 2012 11:38 AM To: Coleen Phillimore Cc: hotspot-runtime-dev at openjdk.java.net Subject: Re: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code Bug filed: JDK-8005262 possible gamma launcher issues https://jbs.oracle.com/bugs/browse/JDK-8005262 Dan On 12/19/12 11:18 AM, Coleen Phillimore wrote: On 12/19/2012 12:39 PM, harold seigel wrote: >> I say file the bug merely to document the issue and get this code checked in I agree. Harold, Thank you for looking at this change closely. Dan, please file a bug about the fake path and include this writeup below, because I think I hit this bug with testing CDS with the gamma launcher and it might explain it. Thanks, Coleen Harold On 12/19/2012 12:11 PM, Ron Durbin wrote: Harold I would say first off this is not a bug that has manifested itself yet. So it is low priority. That being said this exposure is not introduced or made more risky by my changes. This is the only issue that we have against this code review and it does not belong to the changes being reviewed=. I say file the bug merely to document the issue and get this code checked in. Ron From: Daniel D. Daugherty Sent: Wednesday, December 19, 2012 9:30 AM To: HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net; build-dev; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: Re: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code Adding the other aliases back in... Harold, This question: > Another nit: Is it worth checking that all of > "/hotspot/libjvm.so" could get copied to buf? (i.e.: that > buflen-len > strlen("/hotspot/libjvm.so") is straight forward and the short answer is: yes, that code makes assumptions that "/hotspot/libjvm.so" will fit into 'buf'. It should not do that. It is Ron's call as to whether he wants to fix this existing bug as part of this work. It is easy enough to fix the obvious part of the bug, but... as is normal with HotSpot, there is more going on here than meets the eye... The slightly longer answer is that it probably doesn't matter because the path being created here is a fake. As long as the "/hotspot/l" part gets copied, then the callers of os::jvm_path() will be able to handle the fakery. Of course, there is an even longer answer. Read on if you want gory details (and a history lesson). This gamma launcher stuff is giving me an absolute headache. Unfortunately, there is a lot of history involved here... Here are the variations: src/os/bsd/vm/os_bsd.cpp: 1715 if (Arguments::created_by_gamma_launcher()) { 1716 // Support for the gamma launcher. Typical value for buf is 1717 // "/jre/lib///libjvm". If "/jre/lib/" appears at 1718 // the right place in the string, then assume we are installed in a JDK and 1719 // we're done. Otherwise, check for a JAVA_HOME environment variable and 1720 // construct a path to the JVM being overridden. 1762 // If the path exists within JAVA_HOME, add the JVM library name 1763 // to complete the path to JVM being overridden. Otherwise fallback 1764 // to the path to the current library. 1765 if (0 == access(buf, F_OK)) { 1766 // Use current module name "libjvm" 1767 len = strlen(buf); 1768 snprintf(buf + len, buflen-len, "/libjvm%s", JNI_LIB_SUFFIX); 1769 } else { 1770 // Fall back to path of current library 1771 rp = realpath(dli_fname, buf); 1772 if (rp == NULL) 1773 return; 1774 } src/os/linux/vm/os_linux.cpp: 2206 if (Arguments::created_by_gamma_launcher()) { 2207 // Support for the gamma launcher. Typical value for buf is 2208 // "/jre/lib///libjvm.so". If "/jre/lib/" appears at 2209 // the right place in the string, then assume we are installed in a JDK and 2210 // we're done. Otherwise, check for a JAVA_HOME environment variable and fix 2211 // up the path so it looks like libjvm.so is installed there (append a 2212 // fake suffix hotspot/libjvm.so). 2243 if (0 == access(buf, F_OK)) { 2244 // Use current module name "libjvm.so" 2245 len = strlen(buf); 2246 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); 2247 } else { 2248 // Go back to path of .so 2249 rp = realpath(dli_fname, buf); 2250 if (rp == NULL) 2251 return; 2252 } src/os/solaris/vm/os_solaris.cpp: 2496 if (Arguments::created_by_gamma_launcher()) { 2497 // Support for the gamma launcher. Typical value for buf is 2498 // "/jre/lib///libjvm.so". If "/jre/lib/" appears at 2499 // the right place in the string, then assume we are installed in a JDK and 2500 // we're done. Otherwise, check for a JAVA_HOME environment variable and fix 2501 // up the path so it looks like libjvm.so is installed there (append a 2502 // fake suffix hotspot/libjvm.so). 2539 if (0 == access(buf, F_OK)) { 2540 // Use current module name "libjvm.so" 2541 len = strlen(buf); 2542 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); 2543 } else { 2544 // Go back to path of .so 2545 realpath((char *)dlinfo.dli_fname, buf); 2546 } src/os/windows/vm/os_windows.cpp: 1732 buf[0] = '\0'; 1733 if (Arguments::created_by_gamma_launcher()) { 1734 // Support for the gamma launcher. Check for an 1735 // JAVA_HOME environment variable 1736 // and fix up the path so it looks like 1737 // libjvm.so is installed there (append a fake suffix 1738 // hotspot/libjvm.so). 1739 char* java_home_var = ::getenv("JAVA_HOME"); 1740 if (java_home_var != NULL && java_home_var[0] != 0) { 1741 1742 strncpy(buf, java_home_var, buflen); 1743 1744 // determine if this is a legacy image or modules image 1745 // modules image doesn't have "jre" subdirectory 1746 size_t len = strlen(buf); 1747 char* jrebin_p = buf + len; 1748 jio_snprintf(jrebin_p, buflen-len, "HYPERLINK "file:///\\%5C%5Cjre%5Cbin%5C"\\jre\\bin\\"); 1749 if (0 != _access(buf, 0)) { 1750 jio_snprintf(jrebin_p, buflen-len, "HYPERLINK "file:///\\%5C%5Cbin%5C"\\bin\\"); 1751 } 1752 len = strlen(buf); 1753 jio_snprintf(buf + len, buflen-len, "hotspot\\jvm.dll"); 1754 } 1755 } Linux, Solaris and Windows all recognize that if they get to the point where they are appending a "hotspot/..." path to the jvm_path value, then they are making a fake path. Why are they making a fake path? Well, the gamma launcher lets someone use a libjvm.so/jvm.dll that is not located in the usual place in a JDK. And, you get to use that libjvm.so/jvm.dll WITH THAT JDK. Sounds pretty cool and it is pretty cool... until you realize that there is code in the VM that tries to find other libraries _relative_ to the libjvm.so/jvm.dll that is running. Ouch! So enter the above code blocks that fake a path to the libjvm.so/jvm.dll so that callers to os::jvm_path() don't get confused. To make matters more convoluted... yes, I know this is convoluted enough... The os_bsd.cpp doesn't seem to realize that it is creating a fake path here. At one point, the os_bsd.cpp code was a copy of os_linux.cpp code, but it was obviously tweaked. It will take more investigation to figure out the right course of action for os_bsd.cpp Dan On 12/19/12 7:51 AM, harold seigel wrote: Hi Ron, I'm ok with using snprinft(). Another nit: Is it worth checking that all of "/hotspot/libjvm.so" could get copied to buf? (i.e.: that buflen-len > strlen("/hotspot/libjvm.so") Thanks, Harold On 12/19/2012 9:17 AM, Ron Durbin wrote: Harold, Did you have any more points or counter points to make on the use of snprintf and strncpy ? Ron From: Ron Durbin Sent: Tuesday, December 18, 2012 4:50 PM To: Daniel Daugherty; HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net; build-dev; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: RE: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code Thanks for the quick reviews by all. I will agree with Dan on this one, sprint will stay. Ron From: Daniel D. Daugherty Sent: Tuesday, December 18, 2012 4:03 PM To: HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net; build-dev; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: Re: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code Sorry, I lost my manners somewhere... :-( Thanks for the fast review! Dan On 12/18/12 3:57 PM, Daniel D. Daugherty wrote: Adding back in the other aliases... Harold, The equivalent of: snprintf(buf, n, str); is: strncpy(buf, str, n - 1); buf[n - 1] = '\0'; because snprintf() will only write out (n - 1) bytes from 'str' to 'buf' and then write a NUL in the last slot. strncpy() copies up to 'n' bytes from 'str' to 'buf'. strncpy() will not copy past a NUL character in 'str', but it will also not NUL terminate 'buf' if a NUL is not found in 'str' before the limit 'n' is reached. Dan On 12/18/12 2:48 PM, harold seigel wrote: Hi Ron, I think these calls to snprintf() in os_solaris.cpp and the other os_....cpp files could be replaced with calls to strncpy(). It might be a little simpler. Otherwise, it looks good. Thanks, Harold 2539 if (0 == access(buf, F_OK)) { 2540 // Use current module name "libjvm.so" 2541 len = strlen(buf); 2542 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); 2543 } else { 2544 // Go back to path of .so 2545 realpath((char *)dlinfo.dli_fname, buf); 2546 } On 12/18/2012 3:46 PM, Daniel D. Daugherty wrote: Greetings, I'm sponsoring this code review request from Ron Durbin. This change is targeted at JDK8/HSX-25 in the RT_Baseline repo. Dan Sending again with correct subject line, bug URLs and webrev URL. Intro: This set of changes removes the runtime support for generation of debug versions that follow _g semantics. Defect: JDK-8005044 remove crufty '_g' support from HS runtime code http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 https://jbs.oracle.com/bugs/browse/JDK-8005044 Webrev HYPERLINK "http://cr.openjdk.java.net/%7Edcubed/for_rdurbin/8005044-webrev/0"http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 Details: Files have been modified to remove all reference and support for debug versions that follow _g semantics. Testing: Passed JPRT last night: Additional Testing In process: (suggested by Dan): src/share/vm/runtime/arguments.cpp - test with shared archive creation and use; see the e-mail from Coleen src/share/tools/ProjectCreator/ProjectCreator.java - just a usage message; visual inspection of the code src/os/windows/vm/os_windows.cpp - comments only; no testing needed src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp - the only code changes come into play when the "gamma" launcher is used - and when JAVA_HOME refers to a valid JDK, the function fakes up a JVM path so that callers using the JVM path to find other things in the JDK will work. - I can't find any way that the actual JVM path value that is returned is exposed - I don't see a way to test this other than have a debug printf() or manual code inspection. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121219/82be0f1f/attachment-0001.html From coleen.phillimore at oracle.com Wed Dec 19 10:49:36 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 19 Dec 2012 13:49:36 -0500 Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: References: <50D0D618.6020001@oracle.com> <50D0E4BF.305@oracle.com> <50D0F4D0.2010108@oracle.com> <50D0F637.9080607@oracle.com> <07e8ed19-fa2d-42f4-a862-824530c88441@default> <955b2245-7480-4af0-bd88-16eb1dd5856a@default> <50D1D461.50109@oracle.com> <50D1EB8E.1030302@oracle.com> <684945f3-4869-4674-bf17-74193ff9ffa7@default> <50D1FBD1.3000504@oracle.com> <50D204F7.7050805@oracle.com> <50D2096E.80001@oracle.com> Message-ID: <50D20C40.9010902@oracle.com> On 12/19/2012 1:42 PM, Ron Durbin wrote: > > Coleen > > If we are hitting this in an existing test. Would this not raise the > priority? > No test, just private testing. Coleen > *From:*Daniel D. Daugherty > *Sent:* Wednesday, December 19, 2012 11:38 AM > *To:* Coleen Phillimore > *Cc:* hotspot-runtime-dev at openjdk.java.net > *Subject:* Re: Code Review fix for 8005044 remove crufty '_g' support > from HS runtime code > > Bug filed: > > JDK-8005262 possible gamma launcher issues > https://jbs.oracle.com/bugs/browse/JDK-8005262 > > Dan > > On 12/19/12 11:18 AM, Coleen Phillimore wrote: > > On 12/19/2012 12:39 PM, harold seigel wrote: > > >> I say file the bug merely to document the issue and get > this code checked in > I agree. > > > Harold, Thank you for looking at this change closely. > Dan, please file a bug about the fake path and include this > writeup below, because I think I hit this bug with testing CDS > with the gamma launcher and it might explain it. > Thanks, > Coleen > > > > Harold > > On 12/19/2012 12:11 PM, Ron Durbin wrote: > > Harold > > I would say first off this is not a bug that has manifested itself > yet. > > So it is low priority. > > That being said this exposure is not introduced or made more risky > by my changes. > > This is the only issue that we have against this code review and > it does not belong to the changes being reviewed=. > > I say file the bug merely to document the issue and get this code > checked in. > > Ron > > *From:*Daniel D. Daugherty > *Sent:* Wednesday, December 19, 2012 9:30 AM > *To:* hotspot-runtime-dev at openjdk.java.net > ; build-dev; > serviceability-dev at openjdk.java.net > > *Subject:* Re: Code Review fix for 8005044 remove crufty '_g' > support from HS runtime code > > Adding the other aliases back in... > > Harold, > > This question: > > > Another nit: Is it worth checking that all of > > "/hotspot/libjvm.so" could get copied to buf? (i.e.: that > > buflen-len > strlen("/hotspot/libjvm.so") > > is straight forward and the short answer is: yes, that > code makes assumptions that "/hotspot/libjvm.so" will > fit into 'buf'. It should not do that. > > It is Ron's call as to whether he wants to fix this existing > bug as part of this work. It is easy enough to fix the obvious > part of the bug, but... as is normal with HotSpot, there > is more going on here than meets the eye... > > The slightly longer answer is that it probably doesn't > matter because the path being created here is a fake. > As long as the "/hotspot/l" part gets copied, then the > callers of os::jvm_path() will be able to handle the > fakery. > > Of course, there is an even longer answer. Read on if > you want gory details (and a history lesson). > > This gamma launcher stuff is giving me an absolute headache. > Unfortunately, there is a lot of history involved here... > > Here are the variations: > > src/os/bsd/vm/os_bsd.cpp: > > 1715 if (Arguments::created_by_gamma_launcher()) { > 1716 // Support for the gamma launcher. Typical value for > buf is > 1717 // "/jre/lib///libjvm". If > "/jre/lib/" appears at > 1718 // the right place in the string, then assume we are > installed in a JDK and > 1719 // we're done. Otherwise, check for a JAVA_HOME > environment variable and > 1720 // construct a path to the JVM being overridden. > > > > 1762 // If the path exists within JAVA_HOME, add the > JVM library name > 1763 // to complete the path to JVM being overridden. > Otherwise fallback > 1764 // to the path to the current library. > 1765 if (0 == access(buf, F_OK)) { > 1766 // Use current module name "libjvm" > 1767 len = strlen(buf); > 1768 snprintf(buf + len, buflen-len, "/libjvm%s", JNI_LIB_SUFFIX); > 1769 } else { > 1770 // Fall back to path of current library > 1771 rp = realpath(dli_fname, buf); > 1772 if (rp == NULL) > 1773 return; > 1774 } > > src/os/linux/vm/os_linux.cpp: > > 2206 if (Arguments::created_by_gamma_launcher()) { > 2207 // Support for the gamma launcher. Typical value for > buf is > 2208 // "/jre/lib///libjvm.so". If > "/jre/lib/" appears at > 2209 // the right place in the string, then assume we are > installed in a JDK and > 2210 // we're done. Otherwise, check for a JAVA_HOME > environment variable and fix > 2211 // up the path so it looks like libjvm.so is installed > there (append a > 2212 // fake suffix hotspot/libjvm.so). > > > > 2243 if (0 == access(buf, F_OK)) { > 2244 // Use current module name "libjvm.so" > 2245 len = strlen(buf); > 2246 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); > 2247 } else { > 2248 // Go back to path of .so > 2249 rp = realpath(dli_fname, buf); > 2250 if (rp == NULL) > 2251 return; > 2252 } > > src/os/solaris/vm/os_solaris.cpp: > > 2496 if (Arguments::created_by_gamma_launcher()) { > 2497 // Support for the gamma launcher. Typical value for > buf is > 2498 // "/jre/lib///libjvm.so". If > "/jre/lib/" appears at > 2499 // the right place in the string, then assume we are > installed in a JDK and > 2500 // we're done. Otherwise, check for a JAVA_HOME > environment variable and fix > 2501 // up the path so it looks like libjvm.so is installed > there (append a > 2502 // fake suffix hotspot/libjvm.so). > > > > 2539 if (0 == access(buf, F_OK)) { > 2540 // Use current module name "libjvm.so" > 2541 len = strlen(buf); > 2542 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); > 2543 } else { > 2544 // Go back to path of .so > 2545 realpath((char *)dlinfo.dli_fname, buf); > 2546 } > > src/os/windows/vm/os_windows.cpp: > > 1732 buf[0] = '\0'; > 1733 if (Arguments::created_by_gamma_launcher()) { > 1734 // Support for the gamma launcher. Check for an > 1735 // JAVA_HOME environment variable > 1736 // and fix up the path so it looks like > 1737 // libjvm.so is installed there (append a fake suffix > 1738 // hotspot/libjvm.so). > 1739 char* java_home_var = ::getenv("JAVA_HOME"); > 1740 if (java_home_var != NULL && java_home_var[0] != 0) { > 1741 > 1742 strncpy(buf, java_home_var, buflen); > 1743 > 1744 // determine if this is a legacy image or modules > image > 1745 // modules image doesn't have "jre" subdirectory > 1746 size_t len = strlen(buf); > 1747 char* jrebin_p = buf + len; > 1748 jio_snprintf(jrebin_p, buflen-len, "\\jre\\bin\\ > "); > 1749 if (0 != _access(buf, 0)) { > 1750 jio_snprintf(jrebin_p, buflen-len, "\\bin\\ > "); > 1751 } > 1752 len = strlen(buf); > 1753 jio_snprintf(buf + len, buflen-len, "hotspot\\jvm.dll"); > 1754 } > 1755 } > > > Linux, Solaris and Windows all recognize that if they > get to the point where they are appending a "hotspot/..." > path to the jvm_path value, then they are making a fake > path. Why are they making a fake path? Well, the gamma > launcher lets someone use a libjvm.so/jvm.dll that is > not located in the usual place in a JDK. And, you get > to use that libjvm.so/jvm.dll WITH THAT JDK. Sounds > pretty cool and it is pretty cool... until you realize > that there is code in the VM that tries to find other > libraries _relative_ to the libjvm.so/jvm.dll that is > running. Ouch! So enter the above code blocks that fake > a path to the libjvm.so/jvm.dll so that callers to > os::jvm_path() don't get confused. > > To make matters more convoluted... yes, I know this is > convoluted enough... The os_bsd.cpp doesn't seem to > realize that it is creating a fake path here. At one > point, the os_bsd.cpp code was a copy of os_linux.cpp > code, but it was obviously tweaked. It will take more > investigation to figure out the right course of action > for os_bsd.cpp > > Dan > > > > On 12/19/12 7:51 AM, harold seigel wrote: > > > Hi Ron, > > I'm ok with using snprinft(). > > Another nit: Is it worth checking that all of "/hotspot/libjvm.so" > could get copied to buf? (i.e.: that buflen-len > > strlen("/hotspot/libjvm.so") > > Thanks, Harold > > On 12/19/2012 9:17 AM, Ron Durbin wrote: > > Harold, > > Did you have any more points or counter points to make on the use > of snprintf and strncpy ? > > Ron > > *From:*Ron Durbin > *Sent:* Tuesday, December 18, 2012 4:50 PM > *To:* Daniel Daugherty; hotspot-runtime-dev at openjdk.java.net > ; build-dev; > serviceability-dev at openjdk.java.net > > *Subject:* RE: Code Review fix for 8005044 remove crufty '_g' > support from HS runtime code > > Thanks for the quick reviews by all. > > I will agree with Dan on this one, sprint will stay. > > Ron > > *From:*Daniel D. Daugherty > *Sent:* Tuesday, December 18, 2012 4:03 PM > *To:* hotspot-runtime-dev at openjdk.java.net > ; build-dev; > serviceability-dev at openjdk.java.net > > *Subject:* Re: Code Review fix for 8005044 remove crufty '_g' > support from HS runtime code > > Sorry, I lost my manners somewhere... :-( > > Thanks for the fast review! > > Dan > > On 12/18/12 3:57 PM, Daniel D. Daugherty wrote: > > Adding back in the other aliases... > > Harold, > > The equivalent of: > > snprintf(buf, n, str); > > is: > > strncpy(buf, str, n - 1); > buf[n - 1] = '\0'; > > because snprintf() will only write out (n - 1) bytes from > 'str' to 'buf' and then write a NUL in the last slot. > strncpy() copies up to 'n' bytes from 'str' to 'buf'. > strncpy() will not copy past a NUL character in 'str', but > it will also not NUL terminate 'buf' if a NUL is not found > in 'str' before the limit 'n' is reached. > > Dan > > On 12/18/12 2:48 PM, harold seigel wrote: > > Hi Ron, > > I think these calls to snprintf() in os_solaris.cpp and > the other os_....cpp files could be replaced with calls to > strncpy(). It might be a little simpler. > > Otherwise, it looks good. > > Thanks, Harold > > 2539 if (0 == access(buf, F_OK)) { > 2540 // Use current module name "libjvm.so" > 2541 len = strlen(buf); > 2542 *snprintf(buf + len, buflen-len, "/hotspot/libjvm.so");* > 2543 } else { > 2544 // Go back to path of .so > 2545 realpath((char *)dlinfo.dli_fname, buf); 2546 } > > On 12/18/2012 3:46 PM, Daniel D. Daugherty wrote: > > Greetings, > > I'm sponsoring this code review request from Ron Durbin. > This change > is targeted at JDK8/HSX-25 in the RT_Baseline repo. > > Dan > > Sending again with correct subject line, bug URLs and > webrev URL. > > > Intro: > > This set of changes removes the runtime support for > generation of debug versions that follow _g semantics. > > Defect: > JDK-8005044 remove crufty '_g' support from HS runtime code > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 > https://jbs.oracle.com/bugs/browse/JDK-8005044 > > > Webrev > http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 > > > > > Details: > Files have been modified to remove all reference and > support for debug versions that follow _g semantics. > > Testing: > > Passed JPRT last night: > > Additional Testing In process: (suggested by Dan): > > src/share/vm/runtime/arguments.cpp > - test with shared archive creation and use; see the > e-mail > from Coleen > > src/share/tools/ProjectCreator/ProjectCreator.java > - just a usage message; visual inspection of the code > > src/os/windows/vm/os_windows.cpp > - comments only; no testing needed > > src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp > - the only code changes come into play when the "gamma" > launcher is used > - and when JAVA_HOME refers to a valid JDK, the function > fakes up a JVM path so that callers using the JVM path > to find other things in the JDK will work. > - I can't find any way that the actual JVM path value > that is returned is exposed > - I don't see a way to test this other than have a debug > printf() or manual code inspection. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121219/db7021b1/attachment-0001.html From daniel.daugherty at oracle.com Wed Dec 19 10:59:00 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 19 Dec 2012 11:59:00 -0700 Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <50D204F7.7050805@oracle.com> References: <50D0D618.6020001@oracle.com> <50D0E4BF.305@oracle.com> <50D0F4D0.2010108@oracle.com> <50D0F637.9080607@oracle.com> <07e8ed19-fa2d-42f4-a862-824530c88441@default> <955b2245-7480-4af0-bd88-16eb1dd5856a@default> <50D1D461.50109@oracle.com> <50D1EB8E.1030302@oracle.com> <684945f3-4869-4674-bf17-74193ff9ffa7@default> <50D1FBD1.3000504@oracle.com> <50D204F7.7050805@oracle.com> Message-ID: <50D20E74.10107@oracle.com> Resending...adding back the other aliases... Bug filed: JDK-8005262possible gamma launcher issues https://jbs.oracle.com/bugs/browse/JDK-8005262 Dan On 12/19/12 11:18 AM, Coleen Phillimore wrote: > On 12/19/2012 12:39 PM, harold seigel wrote: >> >> I say file the bug merely to document the issue and get this code >> checked in >> I agree. > > Harold, Thank you for looking at this change closely. > Dan, please file a bug about the fake path and include this writeup > below, because I think I hit this bug with testing CDS with the gamma > launcher and it might explain it. > Thanks, > Coleen > >> >> Harold >> >> On 12/19/2012 12:11 PM, Ron Durbin wrote: >>> >>> Harold >>> >>> I would say first off this is not a bug that has manifested itself yet. >>> >>> So it is low priority. >>> >>> That being said this exposure is not introduced or made more risky >>> by my changes. >>> >>> This is the only issue that we have against this code review and it >>> does not belong to the changes being reviewed=. >>> >>> I say file the bug merely to document the issue and get this code >>> checked in. >>> >>> Ron >>> >>> *From:*Daniel D. Daugherty >>> *Sent:* Wednesday, December 19, 2012 9:30 AM >>> *To:* hotspot-runtime-dev at openjdk.java.net; build-dev; >>> serviceability-dev at openjdk.java.net >>> *Subject:* Re: Code Review fix for 8005044 remove crufty '_g' >>> support from HS runtime code >>> >>> Adding the other aliases back in... >>> >>> Harold, >>> >>> This question: >>> >>> > Another nit: Is it worth checking that all of >>> > "/hotspot/libjvm.so" could get copied to buf? (i.e.: that >>> > buflen-len > strlen("/hotspot/libjvm.so") >>> >>> is straight forward and the short answer is: yes, that >>> code makes assumptions that "/hotspot/libjvm.so" will >>> fit into 'buf'. It should not do that. >>> >>> It is Ron's call as to whether he wants to fix this existing >>> bug as part of this work. It is easy enough to fix the obvious >>> part of the bug, but... as is normal with HotSpot, there >>> is more going on here than meets the eye... >>> >>> The slightly longer answer is that it probably doesn't >>> matter because the path being created here is a fake. >>> As long as the "/hotspot/l" part gets copied, then the >>> callers of os::jvm_path() will be able to handle the >>> fakery. >>> >>> Of course, there is an even longer answer. Read on if >>> you want gory details (and a history lesson). >>> >>> This gamma launcher stuff is giving me an absolute headache. >>> Unfortunately, there is a lot of history involved here... >>> >>> Here are the variations: >>> >>> src/os/bsd/vm/os_bsd.cpp: >>> >>> 1715 if (Arguments::created_by_gamma_launcher()) { >>> 1716 // Support for the gamma launcher. Typical value for buf is >>> 1717 // "/jre/lib///libjvm". If >>> "/jre/lib/" appears at >>> 1718 // the right place in the string, then assume we are >>> installed in a JDK and >>> 1719 // we're done. Otherwise, check for a JAVA_HOME >>> environment variable and >>> 1720 // construct a path to the JVM being overridden. >>> >>> >>> >>> 1762 // If the path exists within JAVA_HOME, add the JVM >>> library name >>> 1763 // to complete the path to JVM being overridden. >>> Otherwise fallback >>> 1764 // to the path to the current library. >>> 1765 if (0 == access(buf, F_OK)) { >>> 1766 // Use current module name "libjvm" >>> 1767 len = strlen(buf); >>> 1768 snprintf(buf + len, buflen-len, "/libjvm%s", >>> JNI_LIB_SUFFIX); >>> 1769 } else { >>> 1770 // Fall back to path of current library >>> 1771 rp = realpath(dli_fname, buf); >>> 1772 if (rp == NULL) >>> 1773 return; >>> 1774 } >>> >>> src/os/linux/vm/os_linux.cpp: >>> >>> 2206 if (Arguments::created_by_gamma_launcher()) { >>> 2207 // Support for the gamma launcher. Typical value for buf is >>> 2208 // "/jre/lib///libjvm.so". If >>> "/jre/lib/" appears at >>> 2209 // the right place in the string, then assume we are >>> installed in a JDK and >>> 2210 // we're done. Otherwise, check for a JAVA_HOME >>> environment variable and fix >>> 2211 // up the path so it looks like libjvm.so is installed >>> there (append a >>> 2212 // fake suffix hotspot/libjvm.so). >>> >>> >>> >>> 2243 if (0 == access(buf, F_OK)) { >>> 2244 // Use current module name "libjvm.so" >>> 2245 len = strlen(buf); >>> 2246 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); >>> 2247 } else { >>> 2248 // Go back to path of .so >>> 2249 rp = realpath(dli_fname, buf); >>> 2250 if (rp == NULL) >>> 2251 return; >>> 2252 } >>> >>> src/os/solaris/vm/os_solaris.cpp: >>> >>> 2496 if (Arguments::created_by_gamma_launcher()) { >>> 2497 // Support for the gamma launcher. Typical value for buf is >>> 2498 // "/jre/lib///libjvm.so". If >>> "/jre/lib/" appears at >>> 2499 // the right place in the string, then assume we are >>> installed in a JDK and >>> 2500 // we're done. Otherwise, check for a JAVA_HOME >>> environment variable and fix >>> 2501 // up the path so it looks like libjvm.so is installed >>> there (append a >>> 2502 // fake suffix hotspot/libjvm.so). >>> >>> >>> >>> 2539 if (0 == access(buf, F_OK)) { >>> 2540 // Use current module name "libjvm.so" >>> 2541 len = strlen(buf); >>> 2542 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); >>> 2543 } else { >>> 2544 // Go back to path of .so >>> 2545 realpath((char *)dlinfo.dli_fname, buf); >>> 2546 } >>> >>> src/os/windows/vm/os_windows.cpp: >>> >>> 1732 buf[0] = '\0'; >>> 1733 if (Arguments::created_by_gamma_launcher()) { >>> 1734 // Support for the gamma launcher. Check for an >>> 1735 // JAVA_HOME environment variable >>> 1736 // and fix up the path so it looks like >>> 1737 // libjvm.so is installed there (append a fake suffix >>> 1738 // hotspot/libjvm.so). >>> 1739 char* java_home_var = ::getenv("JAVA_HOME"); >>> 1740 if (java_home_var != NULL && java_home_var[0] != 0) { >>> 1741 >>> 1742 strncpy(buf, java_home_var, buflen); >>> 1743 >>> 1744 // determine if this is a legacy image or modules image >>> 1745 // modules image doesn't have "jre" subdirectory >>> 1746 size_t len = strlen(buf); >>> 1747 char* jrebin_p = buf + len; >>> 1748 jio_snprintf(jrebin_p, buflen-len, "\\jre\\bin\\ >>> "); >>> 1749 if (0 != _access(buf, 0)) { >>> 1750 jio_snprintf(jrebin_p, buflen-len, "\\bin\\ >>> "); >>> 1751 } >>> 1752 len = strlen(buf); >>> 1753 jio_snprintf(buf + len, buflen-len, "hotspot\\jvm.dll"); >>> 1754 } >>> 1755 } >>> >>> >>> Linux, Solaris and Windows all recognize that if they >>> get to the point where they are appending a "hotspot/..." >>> path to the jvm_path value, then they are making a fake >>> path. Why are they making a fake path? Well, the gamma >>> launcher lets someone use a libjvm.so/jvm.dll that is >>> not located in the usual place in a JDK. And, you get >>> to use that libjvm.so/jvm.dll WITH THAT JDK. Sounds >>> pretty cool and it is pretty cool... until you realize >>> that there is code in the VM that tries to find other >>> libraries _relative_ to the libjvm.so/jvm.dll that is >>> running. Ouch! So enter the above code blocks that fake >>> a path to the libjvm.so/jvm.dll so that callers to >>> os::jvm_path() don't get confused. >>> >>> To make matters more convoluted... yes, I know this is >>> convoluted enough... The os_bsd.cpp doesn't seem to >>> realize that it is creating a fake path here. At one >>> point, the os_bsd.cpp code was a copy of os_linux.cpp >>> code, but it was obviously tweaked. It will take more >>> investigation to figure out the right course of action >>> for os_bsd.cpp >>> >>> Dan >>> >>> >>> >>> On 12/19/12 7:51 AM, harold seigel wrote: >>> >>> Hi Ron, >>> >>> I'm ok with using snprinft(). >>> >>> Another nit: Is it worth checking that all of "/hotspot/libjvm.so" >>> could get copied to buf? (i.e.: that buflen-len > >>> strlen("/hotspot/libjvm.so") >>> >>> Thanks, Harold >>> >>> On 12/19/2012 9:17 AM, Ron Durbin wrote: >>> >>> Harold, >>> >>> Did you have any more points or counter points to make on the use of >>> snprintf and strncpy ? >>> >>> Ron >>> >>> *From:*Ron Durbin >>> *Sent:* Tuesday, December 18, 2012 4:50 PM >>> *To:* Daniel Daugherty; hotspot-runtime-dev at openjdk.java.net >>> ; build-dev; >>> serviceability-dev at openjdk.java.net >>> >>> *Subject:* RE: Code Review fix for 8005044 remove crufty '_g' >>> support from HS runtime code >>> >>> Thanks for the quick reviews by all. >>> >>> I will agree with Dan on this one, sprint will stay. >>> >>> Ron >>> >>> *From:*Daniel D. Daugherty >>> *Sent:* Tuesday, December 18, 2012 4:03 PM >>> *To:* hotspot-runtime-dev at openjdk.java.net >>> ; build-dev; >>> serviceability-dev at openjdk.java.net >>> >>> *Subject:* Re: Code Review fix for 8005044 remove crufty '_g' >>> support from HS runtime code >>> >>> Sorry, I lost my manners somewhere... :-( >>> >>> Thanks for the fast review! >>> >>> Dan >>> >>> On 12/18/12 3:57 PM, Daniel D. Daugherty wrote: >>> >>> Adding back in the other aliases... >>> >>> Harold, >>> >>> The equivalent of: >>> >>> snprintf(buf, n, str); >>> >>> is: >>> >>> strncpy(buf, str, n - 1); >>> buf[n - 1] = '\0'; >>> >>> because snprintf() will only write out (n - 1) bytes from >>> 'str' to 'buf' and then write a NUL in the last slot. >>> strncpy() copies up to 'n' bytes from 'str' to 'buf'. >>> strncpy() will not copy past a NUL character in 'str', but >>> it will also not NUL terminate 'buf' if a NUL is not found >>> in 'str' before the limit 'n' is reached. >>> >>> Dan >>> >>> On 12/18/12 2:48 PM, harold seigel wrote: >>> >>> Hi Ron, >>> >>> I think these calls to snprintf() in os_solaris.cpp and the >>> other os_....cpp files could be replaced with calls to >>> strncpy(). It might be a little simpler. >>> >>> Otherwise, it looks good. >>> >>> Thanks, Harold >>> >>> 2539 if (0 == access(buf, F_OK)) { >>> 2540 // Use current module name "libjvm.so" >>> 2541 len = strlen(buf); >>> 2542 *snprintf(buf + len, buflen-len, "/hotspot/libjvm.so");* >>> 2543 } else { >>> 2544 // Go back to path of .so >>> 2545 realpath((char *)dlinfo.dli_fname, buf); 2546 } >>> >>> On 12/18/2012 3:46 PM, Daniel D. Daugherty wrote: >>> >>> Greetings, >>> >>> I'm sponsoring this code review request from Ron Durbin. >>> This change >>> is targeted at JDK8/HSX-25 in the RT_Baseline repo. >>> >>> Dan >>> >>> Sending again with correct subject line, bug URLs and webrev >>> URL. >>> >>> >>> Intro: >>> >>> This set of changes removes the runtime support for >>> generation of debug versions that follow _g semantics. >>> >>> Defect: >>> JDK-8005044 remove crufty '_g' support from HS runtime code >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 >>> https://jbs.oracle.com/bugs/browse/JDK-8005044 >>> >>> >>> Webrev >>> http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 >>> >>> >>> >>> >>> Details: >>> Files have been modified to remove all reference and support >>> for debug versions that follow _g semantics. >>> >>> Testing: >>> >>> Passed JPRT last night: >>> >>> Additional Testing In process: (suggested by Dan): >>> >>> src/share/vm/runtime/arguments.cpp >>> - test with shared archive creation and use; see the e-mail >>> from Coleen >>> >>> src/share/tools/ProjectCreator/ProjectCreator.java >>> - just a usage message; visual inspection of the code >>> >>> src/os/windows/vm/os_windows.cpp >>> - comments only; no testing needed >>> >>> src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp >>> - the only code changes come into play when the "gamma" >>> launcher is used >>> - and when JAVA_HOME refers to a valid JDK, the function >>> fakes up a JVM path so that callers using the JVM path >>> to find other things in the JDK will work. >>> - I can't find any way that the actual JVM path value >>> that is returned is exposed >>> - I don't see a way to test this other than have a debug >>> printf() or manual code inspection. >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121219/c94a6701/attachment-0001.html From ron.durbin at oracle.com Wed Dec 19 11:50:01 2012 From: ron.durbin at oracle.com (Ron Durbin) Date: Wed, 19 Dec 2012 11:50:01 -0800 (PST) Subject: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code In-Reply-To: <50D20C40.9010902@oracle.com> References: <50D0D618.6020001@oracle.com> <50D0E4BF.305@oracle.com> <50D0F4D0.2010108@oracle.com> <50D0F637.9080607@oracle.com> <07e8ed19-fa2d-42f4-a862-824530c88441@default> <955b2245-7480-4af0-bd88-16eb1dd5856a@default> <50D1D461.50109@oracle.com> <50D1EB8E.1030302@oracle.com> <684945f3-4869-4674-bf17-74193ff9ffa7@default> <50D1FBD1.3000504@oracle.com> <50D204F7.7050805@oracle.com> <50D2096E.80001@oracle.com> <50D20C40.9010902@oracle.com> Message-ID: <7e433106-e4ee-4c10-abce-5ce440749680@default> ok From: Coleen Phillimore Sent: Wednesday, December 19, 2012 11:50 AM To: Ron Durbin Cc: Daniel Daugherty; hotspot-runtime-dev at openjdk.java.net Subject: Re: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code On 12/19/2012 1:42 PM, Ron Durbin wrote: Coleen If we are hitting this in an existing test. Would this not raise the priority? No test, just private testing. Coleen From: Daniel D. Daugherty Sent: Wednesday, December 19, 2012 11:38 AM To: Coleen Phillimore Cc: HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net Subject: Re: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code Bug filed: JDK-8005262 possible gamma launcher issues https://jbs.oracle.com/bugs/browse/JDK-8005262 Dan On 12/19/12 11:18 AM, Coleen Phillimore wrote: On 12/19/2012 12:39 PM, harold seigel wrote: >> I say file the bug merely to document the issue and get this code checked in I agree. Harold, Thank you for looking at this change closely. Dan, please file a bug about the fake path and include this writeup below, because I think I hit this bug with testing CDS with the gamma launcher and it might explain it. Thanks, Coleen Harold On 12/19/2012 12:11 PM, Ron Durbin wrote: Harold I would say first off this is not a bug that has manifested itself yet. So it is low priority. That being said this exposure is not introduced or made more risky by my changes. This is the only issue that we have against this code review and it does not belong to the changes being reviewed=. I say file the bug merely to document the issue and get this code checked in. Ron From: Daniel D. Daugherty Sent: Wednesday, December 19, 2012 9:30 AM To: HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net; build-dev; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: Re: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code Adding the other aliases back in... Harold, This question: > Another nit: Is it worth checking that all of > "/hotspot/libjvm.so" could get copied to buf? (i.e.: that > buflen-len > strlen("/hotspot/libjvm.so") is straight forward and the short answer is: yes, that code makes assumptions that "/hotspot/libjvm.so" will fit into 'buf'. It should not do that. It is Ron's call as to whether he wants to fix this existing bug as part of this work. It is easy enough to fix the obvious part of the bug, but... as is normal with HotSpot, there is more going on here than meets the eye... The slightly longer answer is that it probably doesn't matter because the path being created here is a fake. As long as the "/hotspot/l" part gets copied, then the callers of os::jvm_path() will be able to handle the fakery. Of course, there is an even longer answer. Read on if you want gory details (and a history lesson). This gamma launcher stuff is giving me an absolute headache. Unfortunately, there is a lot of history involved here... Here are the variations: src/os/bsd/vm/os_bsd.cpp: 1715 if (Arguments::created_by_gamma_launcher()) { 1716 // Support for the gamma launcher. Typical value for buf is 1717 // "/jre/lib///libjvm". If "/jre/lib/" appears at 1718 // the right place in the string, then assume we are installed in a JDK and 1719 // we're done. Otherwise, check for a JAVA_HOME environment variable and 1720 // construct a path to the JVM being overridden. 1762 // If the path exists within JAVA_HOME, add the JVM library name 1763 // to complete the path to JVM being overridden. Otherwise fallback 1764 // to the path to the current library. 1765 if (0 == access(buf, F_OK)) { 1766 // Use current module name "libjvm" 1767 len = strlen(buf); 1768 snprintf(buf + len, buflen-len, "/libjvm%s", JNI_LIB_SUFFIX); 1769 } else { 1770 // Fall back to path of current library 1771 rp = realpath(dli_fname, buf); 1772 if (rp == NULL) 1773 return; 1774 } src/os/linux/vm/os_linux.cpp: 2206 if (Arguments::created_by_gamma_launcher()) { 2207 // Support for the gamma launcher. Typical value for buf is 2208 // "/jre/lib///libjvm.so". If "/jre/lib/" appears at 2209 // the right place in the string, then assume we are installed in a JDK and 2210 // we're done. Otherwise, check for a JAVA_HOME environment variable and fix 2211 // up the path so it looks like libjvm.so is installed there (append a 2212 // fake suffix hotspot/libjvm.so). 2243 if (0 == access(buf, F_OK)) { 2244 // Use current module name "libjvm.so" 2245 len = strlen(buf); 2246 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); 2247 } else { 2248 // Go back to path of .so 2249 rp = realpath(dli_fname, buf); 2250 if (rp == NULL) 2251 return; 2252 } src/os/solaris/vm/os_solaris.cpp: 2496 if (Arguments::created_by_gamma_launcher()) { 2497 // Support for the gamma launcher. Typical value for buf is 2498 // "/jre/lib///libjvm.so". If "/jre/lib/" appears at 2499 // the right place in the string, then assume we are installed in a JDK and 2500 // we're done. Otherwise, check for a JAVA_HOME environment variable and fix 2501 // up the path so it looks like libjvm.so is installed there (append a 2502 // fake suffix hotspot/libjvm.so). 2539 if (0 == access(buf, F_OK)) { 2540 // Use current module name "libjvm.so" 2541 len = strlen(buf); 2542 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); 2543 } else { 2544 // Go back to path of .so 2545 realpath((char *)dlinfo.dli_fname, buf); 2546 } src/os/windows/vm/os_windows.cpp: 1732 buf[0] = '\0'; 1733 if (Arguments::created_by_gamma_launcher()) { 1734 // Support for the gamma launcher. Check for an 1735 // JAVA_HOME environment variable 1736 // and fix up the path so it looks like 1737 // libjvm.so is installed there (append a fake suffix 1738 // hotspot/libjvm.so). 1739 char* java_home_var = ::getenv("JAVA_HOME"); 1740 if (java_home_var != NULL && java_home_var[0] != 0) { 1741 1742 strncpy(buf, java_home_var, buflen); 1743 1744 // determine if this is a legacy image or modules image 1745 // modules image doesn't have "jre" subdirectory 1746 size_t len = strlen(buf); 1747 char* jrebin_p = buf + len; 1748 jio_snprintf(jrebin_p, buflen-len, "HYPERLINK "file:///\\%5C%5C%5C%5Cjre%5Cbin%5C"\\jre\\bin\\"); 1749 if (0 != _access(buf, 0)) { 1750 jio_snprintf(jrebin_p, buflen-len, "HYPERLINK "file:///\\%5C%5C%5C%5Cbin%5C"\\bin\\"); 1751 } 1752 len = strlen(buf); 1753 jio_snprintf(buf + len, buflen-len, "hotspot\\jvm.dll"); 1754 } 1755 } Linux, Solaris and Windows all recognize that if they get to the point where they are appending a "hotspot/..." path to the jvm_path value, then they are making a fake path. Why are they making a fake path? Well, the gamma launcher lets someone use a libjvm.so/jvm.dll that is not located in the usual place in a JDK. And, you get to use that libjvm.so/jvm.dll WITH THAT JDK. Sounds pretty cool and it is pretty cool... until you realize that there is code in the VM that tries to find other libraries _relative_ to the libjvm.so/jvm.dll that is running. Ouch! So enter the above code blocks that fake a path to the libjvm.so/jvm.dll so that callers to os::jvm_path() don't get confused. To make matters more convoluted... yes, I know this is convoluted enough... The os_bsd.cpp doesn't seem to realize that it is creating a fake path here. At one point, the os_bsd.cpp code was a copy of os_linux.cpp code, but it was obviously tweaked. It will take more investigation to figure out the right course of action for os_bsd.cpp Dan On 12/19/12 7:51 AM, harold seigel wrote: Hi Ron, I'm ok with using snprinft(). Another nit: Is it worth checking that all of "/hotspot/libjvm.so" could get copied to buf? (i.e.: that buflen-len > strlen("/hotspot/libjvm.so") Thanks, Harold On 12/19/2012 9:17 AM, Ron Durbin wrote: Harold, Did you have any more points or counter points to make on the use of snprintf and strncpy ? Ron From: Ron Durbin Sent: Tuesday, December 18, 2012 4:50 PM To: Daniel Daugherty; HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net; build-dev; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: RE: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code Thanks for the quick reviews by all. I will agree with Dan on this one, sprint will stay. Ron From: Daniel D. Daugherty Sent: Tuesday, December 18, 2012 4:03 PM To: HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net; build-dev; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: Re: Code Review fix for 8005044 remove crufty '_g' support from HS runtime code Sorry, I lost my manners somewhere... :-( Thanks for the fast review! Dan On 12/18/12 3:57 PM, Daniel D. Daugherty wrote: Adding back in the other aliases... Harold, The equivalent of: snprintf(buf, n, str); is: strncpy(buf, str, n - 1); buf[n - 1] = '\0'; because snprintf() will only write out (n - 1) bytes from 'str' to 'buf' and then write a NUL in the last slot. strncpy() copies up to 'n' bytes from 'str' to 'buf'. strncpy() will not copy past a NUL character in 'str', but it will also not NUL terminate 'buf' if a NUL is not found in 'str' before the limit 'n' is reached. Dan On 12/18/12 2:48 PM, harold seigel wrote: Hi Ron, I think these calls to snprintf() in os_solaris.cpp and the other os_....cpp files could be replaced with calls to strncpy(). It might be a little simpler. Otherwise, it looks good. Thanks, Harold 2539 if (0 == access(buf, F_OK)) { 2540 // Use current module name "libjvm.so" 2541 len = strlen(buf); 2542 snprintf(buf + len, buflen-len, "/hotspot/libjvm.so"); 2543 } else { 2544 // Go back to path of .so 2545 realpath((char *)dlinfo.dli_fname, buf); 2546 } On 12/18/2012 3:46 PM, Daniel D. Daugherty wrote: Greetings, I'm sponsoring this code review request from Ron Durbin. This change is targeted at JDK8/HSX-25 in the RT_Baseline repo. Dan Sending again with correct subject line, bug URLs and webrev URL. Intro: This set of changes removes the runtime support for generation of debug versions that follow _g semantics. Defect: JDK-8005044 remove crufty '_g' support from HS runtime code http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 https://jbs.oracle.com/bugs/browse/JDK-8005044 Webrev HYPERLINK "http://cr.openjdk.java.net/%7Edcubed/for_rdurbin/8005044-webrev/0"http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 Details: Files have been modified to remove all reference and support for debug versions that follow _g semantics. Testing: Passed JPRT last night: Additional Testing In process: (suggested by Dan): src/share/vm/runtime/arguments.cpp - test with shared archive creation and use; see the e-mail from Coleen src/share/tools/ProjectCreator/ProjectCreator.java - just a usage message; visual inspection of the code src/os/windows/vm/os_windows.cpp - comments only; no testing needed src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp - the only code changes come into play when the "gamma" launcher is used - and when JAVA_HOME refers to a valid JDK, the function fakes up a JVM path so that callers using the JVM path to find other things in the JDK will work. - I can't find any way that the actual JVM path value that is returned is exposed - I don't see a way to test this other than have a debug printf() or manual code inspection. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121219/13a46436/attachment-0001.html From peter.levart at gmail.com Wed Dec 19 14:28:08 2012 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 19 Dec 2012 23:28:08 +0100 Subject: build error in jdk8/tl Message-ID: <50D23F78.8020703@gmail.com> Hi, I'm trying to build a jdk/tl forest (hotspot repo is at 8af7d22f1f8f tip) and get the following error: Compiling /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/oops/klass.cpp Compiling /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/oops/klassVtable.cpp Compiling /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/opto/lcm.cpp Compiling /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/opto/library_call.cpp Compiling /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/interpreter/linkResolver.cpp Assembling /home/peter/work/hg/jdk8-tl/hotspot/src/os_cpu/linux_x86/vm/linux_x86_64.s /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/opto/library_call.cpp: In member function 'CallGenerator* Compile::make_vm_intrinsic(ciMethod*, bool)': /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/opto/library_call.cpp:415:67: error: converting 'false' to pointer type 'CallGenerator*' [-Werror=conversion-null]Compiling /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/opto/live.cpp /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/opto/library_call.cpp:418:67: error: converting 'false' to pointer type 'CallGenerator*' [-Werror=conversion-null] /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/opto/library_call.cpp:421:67: error: converting 'false' to pointer type 'CallGenerator*' [-Werror=conversion-null] /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/opto/library_call.cpp:424:67: error: converting 'false' to pointer type 'CallGenerator*' [-Werror=conversion-null] Compiling /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/classfile/loaderConstraints.cpp cc1plus: all warnings being treated as errors gmake[6]: *** [library_call.o] Error 1 gmake[6]: *** Waiting for unfinished jobs.... gmake[5]: *** [the_vm] Error 2 gmake[4]: *** [product] Error 2 gmake[3]: *** [generic_build2] Error 2 gmake[2]: *** [product] Error 2 gmake[1]: *** [/home/peter/work/hg/jdk8-tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2 make: *** [hotspot-only] Error 2 Does anybody else get this? I'm using gcc 4.7.2 on 64bit Intel, Linux Regards, Peter From vladimir.kozlov at oracle.com Wed Dec 19 14:46:57 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Dec 2012 14:46:57 -0800 Subject: build error in jdk8/tl In-Reply-To: <50D23F78.8020703@gmail.com> References: <50D23F78.8020703@gmail.com> Message-ID: <50D243E1.8050709@oracle.com> https://jbs.oracle.com/bugs/browse/JDK-8004898 On 12/19/12 2:28 PM, Peter Levart wrote: > Hi, > > I'm trying to build a jdk/tl forest (hotspot repo is at 8af7d22f1f8f > tip) and get the following error: > > Compiling /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/oops/klass.cpp > Compiling > /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/oops/klassVtable.cpp > Compiling /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/opto/lcm.cpp > Compiling > /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/opto/library_call.cpp > Compiling > /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/interpreter/linkResolver.cpp > > Assembling > /home/peter/work/hg/jdk8-tl/hotspot/src/os_cpu/linux_x86/vm/linux_x86_64.s > /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/opto/library_call.cpp: > In member function 'CallGenerator* Compile::make_vm_intrinsic(ciMethod*, > bool)': > /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/opto/library_call.cpp:415:67: > error: converting 'false' to pointer type 'CallGenerator*' > [-Werror=conversion-null]Compiling > /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/opto/live.cpp > > /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/opto/library_call.cpp:418:67: > error: converting 'false' to pointer type 'CallGenerator*' > [-Werror=conversion-null] > /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/opto/library_call.cpp:421:67: > error: converting 'false' to pointer type 'CallGenerator*' > [-Werror=conversion-null] > /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/opto/library_call.cpp:424:67: > error: converting 'false' to pointer type 'CallGenerator*' > [-Werror=conversion-null] > Compiling > /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/classfile/loaderConstraints.cpp > > cc1plus: all warnings being treated as errors > gmake[6]: *** [library_call.o] Error 1 > gmake[6]: *** Waiting for unfinished jobs.... > gmake[5]: *** [the_vm] Error 2 > gmake[4]: *** [product] Error 2 > gmake[3]: *** [generic_build2] Error 2 > gmake[2]: *** [product] Error 2 > gmake[1]: *** > [/home/peter/work/hg/jdk8-tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] > Error 2 > make: *** [hotspot-only] Error 2 > > Does anybody else get this? > > I'm using gcc 4.7.2 on 64bit Intel, Linux > > > Regards, Peter > From vladimir.kozlov at oracle.com Wed Dec 19 14:58:03 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Dec 2012 14:58:03 -0800 Subject: build error in jdk8/tl In-Reply-To: <50D23F78.8020703@gmail.com> References: <50D23F78.8020703@gmail.com> Message-ID: <50D2467B.1000007@oracle.com> Peter, http://bugs.sun.com/view_bug.do?bug_id=8004898 Please, wait next promotion. Or you can get fixed VM sources from: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/ Regards, Vladimir On 12/19/12 2:28 PM, Peter Levart wrote: > Hi, > > I'm trying to build a jdk/tl forest (hotspot repo is at 8af7d22f1f8f > tip) and get the following error: > > Compiling /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/oops/klass.cpp > Compiling > /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/oops/klassVtable.cpp > Compiling /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/opto/lcm.cpp > Compiling > /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/opto/library_call.cpp > Compiling > /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/interpreter/linkResolver.cpp > > Assembling > /home/peter/work/hg/jdk8-tl/hotspot/src/os_cpu/linux_x86/vm/linux_x86_64.s > /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/opto/library_call.cpp: > In member function 'CallGenerator* Compile::make_vm_intrinsic(ciMethod*, > bool)': > /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/opto/library_call.cpp:415:67: > error: converting 'false' to pointer type 'CallGenerator*' > [-Werror=conversion-null]Compiling > /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/opto/live.cpp > > /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/opto/library_call.cpp:418:67: > error: converting 'false' to pointer type 'CallGenerator*' > [-Werror=conversion-null] > /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/opto/library_call.cpp:421:67: > error: converting 'false' to pointer type 'CallGenerator*' > [-Werror=conversion-null] > /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/opto/library_call.cpp:424:67: > error: converting 'false' to pointer type 'CallGenerator*' > [-Werror=conversion-null] > Compiling > /home/peter/work/hg/jdk8-tl/hotspot/src/share/vm/classfile/loaderConstraints.cpp > > cc1plus: all warnings being treated as errors > gmake[6]: *** [library_call.o] Error 1 > gmake[6]: *** Waiting for unfinished jobs.... > gmake[5]: *** [the_vm] Error 2 > gmake[4]: *** [product] Error 2 > gmake[3]: *** [generic_build2] Error 2 > gmake[2]: *** [product] Error 2 > gmake[1]: *** > [/home/peter/work/hg/jdk8-tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] > Error 2 > make: *** [hotspot-only] Error 2 > > Does anybody else get this? > > I'm using gcc 4.7.2 on 64bit Intel, Linux > > > Regards, Peter > From daniel.daugherty at oracle.com Wed Dec 19 15:13:55 2012 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 19 Dec 2012 23:13:55 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8005044: remove crufty '_g' support from HS runtime code Message-ID: <20121219231359.C22BE4729E@hg.openjdk.java.net> Changeset: 7d42f3b08300 Author: dcubed Date: 2012-12-19 10:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7d42f3b08300 8005044: remove crufty '_g' support from HS runtime code Summary: Phase 2 is removing '_g' support from the Runtime code. Reviewed-by: dcubed, coleenp, hseigel Contributed-by: ron.durbin at oracle.com ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/tools/ProjectCreator/ProjectCreator.java ! src/share/vm/runtime/arguments.cpp From xerox.time.tech at gmail.com Wed Dec 19 19:49:11 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Wed, 19 Dec 2012 22:49:11 -0500 Subject: class metadata start and end address Message-ID: Hi How can i get the Java class metadata start and end address in the hotspot VM ? Xin From stefan.karlsson at oracle.com Thu Dec 20 03:37:10 2012 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Thu, 20 Dec 2012 11:37:10 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8004823: Add VM support for type annotation reflection Message-ID: <20121220113729.3807A472CA@hg.openjdk.java.net> Changeset: 35431a769282 Author: stefank Date: 2012-12-20 10:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/35431a769282 8004823: Add VM support for type annotation reflection Reviewed-by: dholmes, coleenp Contributed-by: joel.franck at oracle.com ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/annotations.cpp ! src/share/vm/oops/annotations.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/reflection.cpp From coleen.phillimore at oracle.com Thu Dec 20 08:36:56 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 20 Dec 2012 11:36:56 -0500 Subject: class metadata start and end address In-Reply-To: References: Message-ID: <50D33EA8.8040303@oracle.com> On 12/19/2012 10:49 PM, Xin Tong wrote: > Hi > > How can i get the Java class metadata start and end address in the hotspot VM ? It depends on your configuration and version of Hotspot. For jdk7 and below, the class metadata is in the Permgen, so Universe::print_on() will print these addresses. After jdk7 and in hsx, the class metadata is class metaspace. If you have UseCompressedKlassPointers on, this space is in a ReservedSpace below the Java heap (right now). See Universe::reserve_heap(). If CompressedKlassPointers is false, a small space is allocated below the heap but it grows into mmap regions wherever the OS gives us these regions. Thanks, Coleen > > Xin From harold.seigel at oracle.com Thu Dec 20 09:09:41 2012 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 20 Dec 2012 12:09:41 -0500 Subject: Request for review 8003705: CDS failed on Windows: cannot map in the CDS Message-ID: <50D34655.2030105@oracle.com> Hi, Please review the following changes to fix bug 8003705. Summary: When trying to read the CDS file, the existing code was calling both the Windows VirtualAlloc() and MapViewOfFileEx() api's. The calls to MapViewOfFileEx() were failing with ERROR_INVALID_ADDRESS because VirtualAlloc() had already reserved the memory. This fix prevents the call to VirtualAlloc(), allowing the MapViewOfFileEx() calls to succeed. Another problem was that 'java -Xshare:dump calls were unable to overwrite an existing CDS file. This change fixes this by granting the owner full permission when creating the CDS file (mode o744). Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8003705/ Bug link at http://bugs.sun.com/view_bug.do?bug_id=8003705 Thanks! Harold From karen.kinnear at oracle.com Thu Dec 20 10:41:34 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 20 Dec 2012 13:41:34 -0500 Subject: Request for review 8003705: CDS failed on Windows: cannot map in the CDS In-Reply-To: <50D34655.2030105@oracle.com> References: <50D34655.2030105@oracle.com> Message-ID: Harold, Thank you for fixing these. The code in itself looks good. How does it interact with NMT? We want to ensure that the CDS space shows up in NMT on Windows as well - so if we skip the virtual mapping you may need to do that manually. thanks, Karen On Dec 20, 2012, at 12:09 PM, harold seigel wrote: > Hi, > > Please review the following changes to fix bug 8003705. > > Summary: > When trying to read the CDS file, the existing code was calling both the Windows VirtualAlloc() and MapViewOfFileEx() api's. The calls to MapViewOfFileEx() were failing with ERROR_INVALID_ADDRESS because VirtualAlloc() had already reserved the memory. > > This fix prevents the call to VirtualAlloc(), allowing the MapViewOfFileEx() calls to succeed. > > Another problem was that 'java -Xshare:dump calls were unable to overwrite an existing CDS file. This change fixes this by granting the owner full permission when creating the CDS file (mode o744). > > Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8003705/ > > Bug link at http://bugs.sun.com/view_bug.do?bug_id=8003705 > > > Thanks! > Harold From harold.seigel at oracle.com Thu Dec 20 10:53:01 2012 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 20 Dec 2012 13:53:01 -0500 Subject: Request for review 8005075: CDS archive with one alignment causes crash when run with different alignment In-Reply-To: <50D0ED2B.2070003@oracle.com> References: <50CF390F.9020809@oracle.com> <50D0CB9E.2060106@oracle.com> <50D0E159.4040307@oracle.com> <50D0ED2B.2070003@oracle.com> Message-ID: <50D35E8D.3050507@oracle.com> Hi, Based on Vladimir's comments, I changed the code to require that both alignments need to be the same. Here's an example of the modified diagnostic: The shared archive file's ObjectAlignmentInBytes of 16 does not equal the current ObjectAlignmentInBytes of 8. Please review this latest change at: http://cr.openjdk.java.net/~hseigel/bug_8005076_3/ Thank you, Harold On 12/18/2012 5:24 PM, Vladimir Kozlov wrote: > But different alignment will require different encoding with > compressed oops. How you solve that? > > Thanks, > Vladimir > > On 12/18/12 1:34 PM, harold seigel wrote: >> Hi Vladimir, >> >> A bigger original alignment is okay because alignment values must be >> powers of 2. This means that bigger alignments will always be multiples >> of smaller alignments. So, a bigger aligned object will also meet the >> requirements of a smaller alignment. For example, if the bigger >> alignment is 32 then the smaller alignment must be either 8 or 16. And, >> a 32 byte aligned object is also 8 and 16 byte aligned. >> >> Harold >> >> On 12/18/2012 3:01 PM, Vladimir Kozlov wrote: >>> Recording ObjectAlignmentInBytes in CDS is good. Thank you for doing >>> it. >>> My question is why bigger original alignment is fine? I thought CDS >>> works only when it is exactly the same. >>> >>> Thanks, >>> Vladimir >>> >>> On 12/17/12 7:23 AM, harold seigel wrote: >>>> Please review the following change to fix bug 8005075. >>>> >>>> Summary: This change prevents a crash when a CDS archive is created >>>> with a value for -XX:+ObjectAlignmentInBytes that is smaller than the >>>> ObjectAlignmentInBytes value used when running with -Xshare:on. >>>> This fix >>>> stores the ObjectAlignmentInBytes in the CDS archive so that when the >>>> archive is read, hotspot can compare the archive's alignment with the >>>> current alignment and issue the following diagnostic if the archive's >>>> alignment is too small: >>>> >>>> An error has occurred while processing the shared archive file. >>>> The shared archive file was created with a smaller Object >>>> Alignment >>>> value. >>>> >>>> This webrev also cleans up some text in globals.hpp and fixes a small >>>> problem with -XX:SharedReadOnlySize. The existing code was always >>>> setting SharedReadOnlySize to 14M regardless of what was requested. >>>> This prevented users from being able to expand the CDS archive's >>>> SharedReadOnly section. >>>> >>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8005076/ >>>> >>>> >>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=8005076 >>>> >>>> The changes were tested with JCK, JPRT, JTREG, and UTE tests, and with >>>> hand-run tests using different ObjectAlignmentInBytes values. >>>> >>>> Thanks, Harold -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121220/17c3cd5e/attachment.html From coleen.phillimore at oracle.com Thu Dec 20 11:43:59 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 20 Dec 2012 14:43:59 -0500 Subject: Request for review 8005075: CDS archive with one alignment causes crash when run with different alignment In-Reply-To: <50D35E8D.3050507@oracle.com> References: <50CF390F.9020809@oracle.com> <50D0CB9E.2060106@oracle.com> <50D0E159.4040307@oracle.com> <50D0ED2B.2070003@oracle.com> <50D35E8D.3050507@oracle.com> Message-ID: <50D36A7F.3020805@oracle.com> I think this looks good. The fail_continue should just stop using the shared archive if you have -Xshare:auto. I believe it only prints a message and dies if you have -Xshare:on. The default for server is -Xshare:off right now but someday it might be -Xshare:auto if we get the performance problems resolved. (-XX:+RewriteBytecodes is off for CDS and affects server performance) Coleen On 12/20/2012 01:53 PM, harold seigel wrote: > Hi, > > Based on Vladimir's comments, I changed the code to require that both > alignments need to be the same. Here's an example of the modified > diagnostic: > > The shared archive file's ObjectAlignmentInBytes of 16 does not > equal the current ObjectAlignmentInBytes of 8. > > Please review this latest change at: > http://cr.openjdk.java.net/~hseigel/bug_8005076_3/ > > > Thank you, > Harold > > > On 12/18/2012 5:24 PM, Vladimir Kozlov wrote: >> But different alignment will require different encoding with >> compressed oops. How you solve that? >> >> Thanks, >> Vladimir >> >> On 12/18/12 1:34 PM, harold seigel wrote: >>> Hi Vladimir, >>> >>> A bigger original alignment is okay because alignment values must be >>> powers of 2. This means that bigger alignments will always be >>> multiples >>> of smaller alignments. So, a bigger aligned object will also meet the >>> requirements of a smaller alignment. For example, if the bigger >>> alignment is 32 then the smaller alignment must be either 8 or 16. >>> And, >>> a 32 byte aligned object is also 8 and 16 byte aligned. >>> >>> Harold >>> >>> On 12/18/2012 3:01 PM, Vladimir Kozlov wrote: >>>> Recording ObjectAlignmentInBytes in CDS is good. Thank you for >>>> doing it. >>>> My question is why bigger original alignment is fine? I thought CDS >>>> works only when it is exactly the same. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 12/17/12 7:23 AM, harold seigel wrote: >>>>> Please review the following change to fix bug 8005075. >>>>> >>>>> Summary: This change prevents a crash when a CDS archive is created >>>>> with a value for -XX:+ObjectAlignmentInBytes that is smaller than the >>>>> ObjectAlignmentInBytes value used when running with -Xshare:on. >>>>> This fix >>>>> stores the ObjectAlignmentInBytes in the CDS archive so that when the >>>>> archive is read, hotspot can compare the archive's alignment with the >>>>> current alignment and issue the following diagnostic if the archive's >>>>> alignment is too small: >>>>> >>>>> An error has occurred while processing the shared archive file. >>>>> The shared archive file was created with a smaller Object >>>>> Alignment >>>>> value. >>>>> >>>>> This webrev also cleans up some text in globals.hpp and fixes a small >>>>> problem with -XX:SharedReadOnlySize. The existing code was always >>>>> setting SharedReadOnlySize to 14M regardless of what was requested. >>>>> This prevented users from being able to expand the CDS archive's >>>>> SharedReadOnly section. >>>>> >>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8005076/ >>>>> >>>>> >>>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=8005076 >>>>> >>>>> The changes were tested with JCK, JPRT, JTREG, and UTE tests, and >>>>> with >>>>> hand-run tests using different ObjectAlignmentInBytes values. >>>>> >>>>> Thanks, Harold -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121220/f252cf99/attachment.html From rasbold at google.com Fri Dec 21 12:21:49 2012 From: rasbold at google.com (Chuck Rasbold) Date: Fri, 21 Dec 2012 12:21:49 -0800 Subject: Minor memory issues in fastdebug build In-Reply-To: References: Message-ID: Jeremy needs a bug id and a sponsor for this change. While it fixes only a minor memory leak, he is looking to get his feet wet as we engage with the contribution process. I've taken the liberty of creating a webrev at http://cr.openjdk.java.net/~rasbold/XXXXXXX/webrev.00/ -- Chuck On Wed, Dec 12, 2012 at 4:11 PM, Jeremy Manson wrote: > Hi folks, > > I was playing with the fastdebug build, and I found a couple of > trivial memory issues. A patch follows: let me know if you want me to > do some footwork to correct it (file a bug, etc). > > Jeremy > > diff -r 121aa71316af src/share/vm/runtime/vmStructs.cpp > --- a/src/share/vm/runtime/vmStructs.cpp Fri Dec 07 10:46:54 2012 > -0800 > +++ b/src/share/vm/runtime/vmStructs.cpp Wed Dec 12 16:05:25 2012 > -0800 > @@ -3146,10 +3146,10 @@ > s[len-1] = '\0'; > // tty->print_cr("checking \"%s\" for \"%s\"", s, typeName); > if (recursiveFindType(origtypes, s, true) == 1) { > - delete s; > + delete [] s; > return 1; > } > - delete s; > + delete [] s; > } > const char* start = NULL; > if (strstr(typeName, "GrowableArray<") == typeName) { > @@ -3165,10 +3165,10 @@ > s[len-1] = '\0'; > // tty->print_cr("checking \"%s\" for \"%s\"", s, typeName); > if (recursiveFindType(origtypes, s, true) == 1) { > - delete s; > + delete [] s; > return 1; > } > - delete s; > + delete [] s; > } > if (strstr(typeName, "const ") == typeName) { > const char * s = typeName + strlen("const "); > @@ -3182,8 +3182,10 @@ > s[len - 6] = '\0'; > // tty->print_cr("checking \"%s\" for \"%s\"", s, typeName); > if (recursiveFindType(origtypes, s, true) == 1) { > + free(s); > return 1; > } > + free(s); > } > if (!isRecurse) { > tty->print_cr("type \"%s\" not found", typeName); > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121221/945c9b8f/attachment.html From alejandro.murillo at oracle.com Fri Dec 21 21:49:41 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 22 Dec 2012 05:49:41 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 34 new changesets Message-ID: <20121222055048.91CFD47367@hg.openjdk.java.net> Changeset: 8b4810c80f5d Author: katleman Date: 2012-12-20 09:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/8b4810c80f5d Added tag jdk8-b69 for changeset cb8a4e04bc8c ! .hgtags Changeset: 892acf0431ef Author: dcubed Date: 2012-12-14 10:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/892acf0431ef 7153050: remove crufty '_g' support from HotSpot repo makefiles Summary: Phase 1 is removing '_g' support from the Makefiles. Reviewed-by: dcubed, sspitsyn, coleenp, tbell Contributed-by: ron.durbin at oracle.com ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/debug.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/fastdebug.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/jsig.make ! make/bsd/makefiles/jvmg.make ! make/bsd/makefiles/optimized.make ! make/bsd/makefiles/product.make ! make/bsd/makefiles/saproc.make ! make/bsd/makefiles/vm.make ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/debug.make ! make/linux/makefiles/fastdebug.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/jvmg.make ! make/linux/makefiles/optimized.make ! make/linux/makefiles/product.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/vm.make ! make/solaris/Makefile ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/debug.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/gcc.make ! make/solaris/makefiles/jsig.make ! make/solaris/makefiles/jvmg.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/vm.make ! make/windows/build.make ! make/windows/projectfiles/compiler2/ADLCompiler.dsp ! make/windows/projectfiles/tiered/ADLCompiler.dsp Changeset: 30866cd626b0 Author: coleenp Date: 2012-12-12 11:39 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/30866cd626b0 8004883: NPG: clean up anonymous class fix Summary: Add klass_holder() to return either mirror or class_loader depending on if the class is anonymous or not. Reviewed-by: stefank, jrose ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.hpp Changeset: 18712b1caf7a Author: rkennke Date: 2012-12-12 21:40 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/18712b1caf7a 8004898: library_call.cpp build error after 7172640 with GCC 4.7.2 Summary: fix opto/library_call.cpp compilation errors Reviewed-by: twisti, coleenp ! src/share/vm/opto/library_call.cpp Changeset: 8580f22db905 Author: coleenp Date: 2012-12-14 16:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/8580f22db905 Merge Changeset: 3f84e17b6bca Author: zgu Date: 2012-12-17 13:14 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/3f84e17b6bca 8004802: jcmd VM.native_memory baseline=false crashes VM Summary: NMT has to check option's value also to determine which command to execute Reviewed-by: acorn, coleenp, hseigel ! src/share/vm/services/nmtDCmd.cpp Changeset: 805aa223d540 Author: zgu Date: 2012-12-17 10:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/805aa223d540 Merge Changeset: 594b9b2119ed Author: minqi Date: 2012-12-19 16:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/594b9b2119ed Merge Changeset: 0c535211ef13 Author: bharadwaj Date: 2012-12-07 18:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/0c535211ef13 8004668: Build failure for Zero target Summary: fixed build failure for Zero target Reviewed-by: twisti, kvn ! src/cpu/zero/vm/assembler_zero.cpp Changeset: a70c88896791 Author: kvn Date: 2012-12-13 17:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/a70c88896791 8004713: Stackoverflowerror thrown when thread stack straddles 0x80000000 Summary: use unsigned comparison when checking for stack overflow Reviewed-by: kvn, twisti Contributed-by: paul.nauman at oracle.com ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp Changeset: 1b1e16471e46 Author: stefank Date: 2012-12-12 22:41 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/1b1e16471e46 8005002: Crash because of a raw oop in ClassLoaderData::add_dependency Summary: Move the handelization of 'last' to a point before the GC might enter. Reviewed-by: dholmes, sspitsyn, coleenp ! src/share/vm/classfile/classLoaderData.cpp Changeset: 5c0931d15474 Author: twisti Date: 2012-12-14 12:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/5c0931d15474 8003238: JSR 292: intermittent exception failure with java/lang/invoke/CallSiteTest.java Reviewed-by: jrose, kvn ! src/share/vm/prims/methodHandles.cpp Changeset: 3c433d080bae Author: twisti Date: 2012-12-14 12:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/3c433d080bae Merge Changeset: 18d56ca3e901 Author: twisti Date: 2012-12-17 11:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/18d56ca3e901 8004548: remove unused AbstractAssembler::print(Label&) Reviewed-by: kvn, twisti Contributed-by: Bharadwaj Yadavalli ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.hpp ! src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/assembler_zero.hpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp Changeset: ad5dd04754ee Author: roland Date: 2012-12-18 14:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/ad5dd04754ee 8005031: Some cleanup in c2 to prepare for incremental inlining support Summary: collection of small changes to prepare for incremental inlining. Reviewed-by: twisti, kvn ! src/share/vm/ci/ciField.cpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/stringopts.cpp Changeset: eb409f2f146e Author: vlivanov Date: 2012-12-18 06:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/eb409f2f146e 8003135: HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop Summary: Make the load of TLS._osthread._interrupted flag in Thread.isInterrupted(Z)Z intrinsic effectively volatile. Reviewed-by: kvn, jrose ! src/share/vm/opto/library_call.cpp Changeset: 620e502e3f47 Author: vlivanov Date: 2012-12-18 08:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/620e502e3f47 Merge ! src/share/vm/opto/library_call.cpp Changeset: c4bd2eccea46 Author: twisti Date: 2012-12-18 10:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c4bd2eccea46 8004536: replace AbstractAssembler emit_word with emit_int16 Reviewed-by: jrose, kvn, twisti Contributed-by: Morris Meyer ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/asm/assembler.hpp Changeset: 1e41b0bc58a0 Author: kvn Date: 2012-12-18 17:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/1e41b0bc58a0 8004318: JEP-171: Support Unsafe fences intrinsics Summary: Add three memory-ordering intrinsics to the sun.misc.Unsafe class. Reviewed-by: twisti, kvn Contributed-by: Aleksey Shipilev ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/unsafe.cpp Changeset: 65c8342f726a Author: twisti Date: 2012-12-19 14:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/65c8342f726a 8005033: clear high word for integer pop count on SPARC Reviewed-by: kvn, twisti Contributed-by: Richard Reingruber ! src/cpu/sparc/vm/sparc.ad + test/compiler/8005033/Test8005033.java Changeset: 2c7f594145dc Author: kvn Date: 2012-12-19 15:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/2c7f594145dc 8004835: Improve AES intrinsics on x86 Summary: Enable AES intrinsics on non-AVX cpus, group together aes instructions in crypto stubs. Reviewed-by: roland, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! test/compiler/7184394/TestAESBase.java ! test/compiler/7184394/TestAESMain.java Changeset: 2d6c433b1f38 Author: kvn Date: 2012-12-19 19:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/2d6c433b1f38 8004741: Missing compiled exception handle table entry for multidimensional array allocation Summary: Added missing exception path for multidimensional array allocation and use Throwable type instead of OutOfMemoryError for allocation's exception. Reviewed-by: twisti ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp + test/compiler/8004741/Test8004741.java Changeset: a46457045d66 Author: kvn Date: 2012-12-20 14:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/a46457045d66 8004330: Add missing Unsafe entry points for addAndGet() family Summary: Fix java names for getAndSet intrinsics Reviewed-by: kvn Contributed-by: aleksey.shipilev at oracle.com ! src/share/vm/classfile/vmSymbols.hpp Changeset: d02120b7a34f Author: twisti Date: 2012-12-20 18:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/d02120b7a34f 8004250: replace AbstractAssembler a_byte/a_long with emit_int8/emit_int32 Reviewed-by: jrose, kvn, twisti Contributed-by: Morris Meyer ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp Changeset: c52660592f37 Author: roland Date: 2012-12-21 01:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c52660592f37 Merge ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/opto/library_call.cpp Changeset: 0b3d19153cc6 Author: johnc Date: 2012-12-12 12:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/0b3d19153cc6 8001028: Improve GC option handling Summary: If there are not enough native resources to create the ReferenceHandler or Finalizer Java threads, the VM will attempt to throw an OOME before the java.lang.Class class has been initialized. This can result in assertion failures and other crashes. Move the initialization of the java.lang.Class class to just before the initialization of the java.lang.ref.Finalizer class. Reviewed-by: jwilhelm, dholmes, coleenp ! src/share/vm/runtime/thread.cpp Changeset: 730cc4ddd550 Author: brutisso Date: 2012-12-17 08:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/730cc4ddd550 7173959: Jvm crashed during coherence exabus (tmb) testing Summary: Mapping of aligned memory needs to be MT safe. Also reviewed by: vitalyd at gmail.com Reviewed-by: dholmes, coleenp, zgu ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/virtualspace.cpp Changeset: 32164d89fe9c Author: brutisso Date: 2012-12-17 15:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/32164d89fe9c 8004845: Catch incorrect usage of new and delete during compile time for value objects and stack objects Summary: Makes the "new" and "delete" operator of _ValueObj and StackObj private Reviewed-by: dholmes, coleenp Contributed-by: erik.helin at oracle.com ! src/share/vm/memory/allocation.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/services/memBaseline.hpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: c71879335291 Author: stefank Date: 2012-12-18 10:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c71879335291 8005108: NPG: MetaspaceAux::used_in_bytes(), capacity_in_bytes() and reserved_in_bytes() return inconsistent numbers Summary: Reverted the changes to these functions from JDK-8000662 Reviewed-by: brutisso, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: 345bd97a77be Author: brutisso Date: 2012-12-20 05:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/345bd97a77be 8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag Reviewed-by: stefank, brutisso, kvn, ctornqvi Contributed-by: erik.helin at oracle.com + test/sanity/ExecuteInternalVMTests.java Changeset: 69627aa9ab10 Author: jwilhelm Date: 2012-12-21 16:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/69627aa9ab10 Merge ! src/share/vm/runtime/thread.cpp Changeset: 990bbd393c23 Author: amurillo Date: 2012-12-21 10:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/990bbd393c23 Merge Changeset: 6a1fc440b396 Author: amurillo Date: 2012-12-21 10:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/6a1fc440b396 Added tag hs25-b14 for changeset 990bbd393c23 ! .hgtags Changeset: cd962e15c08e Author: amurillo Date: 2012-12-21 10:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/cd962e15c08e 8005382: new hotspot build - hs25-b15 Reviewed-by: jcoomes ! make/hotspot_version From bharadwaj.yadavalli at oracle.com Mon Dec 24 07:44:41 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Mon, 24 Dec 2012 10:44:41 -0500 Subject: RFR (S) : 8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call Message-ID: <50D87869.8070700@oracle.com> I updated legality verification of default methods of a Java 8 interfaces. This update fixes JDK-8004967 and three other failures in Lambda's test-ng tests. I also cleaned up the legality verification of interface methods of pre-Java 8 interface methods. I refactored the code by separating the checks depending on the version being pre-Java 8 or Java 8 and later. Please review the changes at http://cr.openjdk.java.net/~bharadwaj/8004967/hotspot/webrev/ Ran api, lang and vm JCK tests; no new failures. Thanks, Bharadwaj From yumin.qi at oracle.com Mon Dec 24 13:59:57 2012 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Mon, 24 Dec 2012 21:59:57 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 40 new changesets Message-ID: <20121224220115.32DAD47391@hg.openjdk.java.net> Changeset: 442f942757c0 Author: johnc Date: 2012-10-01 09:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/442f942757c0 8000244: G1: Ergonomically set MarkStackSize and use virtual space for global marking stack Summary: Set the value of MarkStackSize to a value based on the number of parallel marking threads with a reasonable minimum. Expand the marking stack if we have to restart marking due to an overflow up to a reasonable maximum. Allocate the underlying space for the marking stack from virtual memory. Reviewed-by: jmasa, brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/arguments.cpp Changeset: a14c5698a162 Author: johnc Date: 2012-12-07 16:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a14c5698a162 Merge Changeset: 2aa953165ade Author: brutisso Date: 2012-12-13 10:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2aa953165ade 8004661: Comment and function name java_lang_String::toHash is wrong Summary: renamed to hash_code Reviewed-by: dholmes, coleenp, brutisso Contributed-by: erik.helin at oracle.com ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.cpp Changeset: db8a7163c682 Author: stefank Date: 2012-12-13 09:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/db8a7163c682 8004674: Add necessary .inline.hpp files to fix non-PCH build Reviewed-by: stefank, coleenp Contributed-by: volker.simonis at gmail.com ! src/share/vm/gc_implementation/parallelScavenge/adjoiningVirtualSpaces.cpp ! src/share/vm/gc_implementation/shared/gcStats.cpp Changeset: 4459ef2189f5 Author: stefank Date: 2012-12-13 09:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4459ef2189f5 Merge Changeset: fd74228fd5ca Author: jiangli Date: 2012-12-11 12:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/fd74228fd5ca 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing. Summary: Move _max_locals and _size_of_parameters to ConstMethod for better sharing. Reviewed-by: coleenp, minqi, jrose ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 807f1d348f7b Author: collins Date: 2012-12-14 11:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/807f1d348f7b Merge Changeset: 8af7d22f1f8f Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8af7d22f1f8f Added tag jdk8-b68 for changeset 121aa71316af ! .hgtags Changeset: b6c9c0109a60 Author: amurillo Date: 2012-12-14 14:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b6c9c0109a60 Merge Changeset: cb8a4e04bc8c Author: amurillo Date: 2012-12-14 14:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cb8a4e04bc8c Added tag hs25-b13 for changeset b6c9c0109a60 ! .hgtags Changeset: 1f323009c3ea Author: amurillo Date: 2012-12-14 14:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1f323009c3ea 8005036: new hotspot build - hs25-b14 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 594b9b2119ed Author: minqi Date: 2012-12-19 16:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/594b9b2119ed Merge Changeset: 0c535211ef13 Author: bharadwaj Date: 2012-12-07 18:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0c535211ef13 8004668: Build failure for Zero target Summary: fixed build failure for Zero target Reviewed-by: twisti, kvn ! src/cpu/zero/vm/assembler_zero.cpp Changeset: a70c88896791 Author: kvn Date: 2012-12-13 17:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a70c88896791 8004713: Stackoverflowerror thrown when thread stack straddles 0x80000000 Summary: use unsigned comparison when checking for stack overflow Reviewed-by: kvn, twisti Contributed-by: paul.nauman at oracle.com ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp Changeset: 1b1e16471e46 Author: stefank Date: 2012-12-12 22:41 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1b1e16471e46 8005002: Crash because of a raw oop in ClassLoaderData::add_dependency Summary: Move the handelization of 'last' to a point before the GC might enter. Reviewed-by: dholmes, sspitsyn, coleenp ! src/share/vm/classfile/classLoaderData.cpp Changeset: 5c0931d15474 Author: twisti Date: 2012-12-14 12:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5c0931d15474 8003238: JSR 292: intermittent exception failure with java/lang/invoke/CallSiteTest.java Reviewed-by: jrose, kvn ! src/share/vm/prims/methodHandles.cpp Changeset: 3c433d080bae Author: twisti Date: 2012-12-14 12:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3c433d080bae Merge Changeset: 18d56ca3e901 Author: twisti Date: 2012-12-17 11:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/18d56ca3e901 8004548: remove unused AbstractAssembler::print(Label&) Reviewed-by: kvn, twisti Contributed-by: Bharadwaj Yadavalli ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.hpp ! src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/assembler_zero.hpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp Changeset: ad5dd04754ee Author: roland Date: 2012-12-18 14:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ad5dd04754ee 8005031: Some cleanup in c2 to prepare for incremental inlining support Summary: collection of small changes to prepare for incremental inlining. Reviewed-by: twisti, kvn ! src/share/vm/ci/ciField.cpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/stringopts.cpp Changeset: eb409f2f146e Author: vlivanov Date: 2012-12-18 06:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/eb409f2f146e 8003135: HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop Summary: Make the load of TLS._osthread._interrupted flag in Thread.isInterrupted(Z)Z intrinsic effectively volatile. Reviewed-by: kvn, jrose ! src/share/vm/opto/library_call.cpp Changeset: 620e502e3f47 Author: vlivanov Date: 2012-12-18 08:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/620e502e3f47 Merge ! src/share/vm/opto/library_call.cpp Changeset: c4bd2eccea46 Author: twisti Date: 2012-12-18 10:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c4bd2eccea46 8004536: replace AbstractAssembler emit_word with emit_int16 Reviewed-by: jrose, kvn, twisti Contributed-by: Morris Meyer ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/asm/assembler.hpp Changeset: 1e41b0bc58a0 Author: kvn Date: 2012-12-18 17:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1e41b0bc58a0 8004318: JEP-171: Support Unsafe fences intrinsics Summary: Add three memory-ordering intrinsics to the sun.misc.Unsafe class. Reviewed-by: twisti, kvn Contributed-by: Aleksey Shipilev ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/unsafe.cpp Changeset: 65c8342f726a Author: twisti Date: 2012-12-19 14:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/65c8342f726a 8005033: clear high word for integer pop count on SPARC Reviewed-by: kvn, twisti Contributed-by: Richard Reingruber ! src/cpu/sparc/vm/sparc.ad + test/compiler/8005033/Test8005033.java Changeset: 2c7f594145dc Author: kvn Date: 2012-12-19 15:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2c7f594145dc 8004835: Improve AES intrinsics on x86 Summary: Enable AES intrinsics on non-AVX cpus, group together aes instructions in crypto stubs. Reviewed-by: roland, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! test/compiler/7184394/TestAESBase.java ! test/compiler/7184394/TestAESMain.java Changeset: 2d6c433b1f38 Author: kvn Date: 2012-12-19 19:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2d6c433b1f38 8004741: Missing compiled exception handle table entry for multidimensional array allocation Summary: Added missing exception path for multidimensional array allocation and use Throwable type instead of OutOfMemoryError for allocation's exception. Reviewed-by: twisti ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp + test/compiler/8004741/Test8004741.java Changeset: a46457045d66 Author: kvn Date: 2012-12-20 14:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a46457045d66 8004330: Add missing Unsafe entry points for addAndGet() family Summary: Fix java names for getAndSet intrinsics Reviewed-by: kvn Contributed-by: aleksey.shipilev at oracle.com ! src/share/vm/classfile/vmSymbols.hpp Changeset: d02120b7a34f Author: twisti Date: 2012-12-20 18:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d02120b7a34f 8004250: replace AbstractAssembler a_byte/a_long with emit_int8/emit_int32 Reviewed-by: jrose, kvn, twisti Contributed-by: Morris Meyer ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp Changeset: c52660592f37 Author: roland Date: 2012-12-21 01:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c52660592f37 Merge ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/opto/library_call.cpp Changeset: 0b3d19153cc6 Author: johnc Date: 2012-12-12 12:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0b3d19153cc6 8001028: Improve GC option handling Summary: If there are not enough native resources to create the ReferenceHandler or Finalizer Java threads, the VM will attempt to throw an OOME before the java.lang.Class class has been initialized. This can result in assertion failures and other crashes. Move the initialization of the java.lang.Class class to just before the initialization of the java.lang.ref.Finalizer class. Reviewed-by: jwilhelm, dholmes, coleenp ! src/share/vm/runtime/thread.cpp Changeset: 730cc4ddd550 Author: brutisso Date: 2012-12-17 08:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/730cc4ddd550 7173959: Jvm crashed during coherence exabus (tmb) testing Summary: Mapping of aligned memory needs to be MT safe. Also reviewed by: vitalyd at gmail.com Reviewed-by: dholmes, coleenp, zgu ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/virtualspace.cpp Changeset: 32164d89fe9c Author: brutisso Date: 2012-12-17 15:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/32164d89fe9c 8004845: Catch incorrect usage of new and delete during compile time for value objects and stack objects Summary: Makes the "new" and "delete" operator of _ValueObj and StackObj private Reviewed-by: dholmes, coleenp Contributed-by: erik.helin at oracle.com ! src/share/vm/memory/allocation.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/services/memBaseline.hpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: c71879335291 Author: stefank Date: 2012-12-18 10:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c71879335291 8005108: NPG: MetaspaceAux::used_in_bytes(), capacity_in_bytes() and reserved_in_bytes() return inconsistent numbers Summary: Reverted the changes to these functions from JDK-8000662 Reviewed-by: brutisso, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: 345bd97a77be Author: brutisso Date: 2012-12-20 05:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/345bd97a77be 8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag Reviewed-by: stefank, brutisso, kvn, ctornqvi Contributed-by: erik.helin at oracle.com + test/sanity/ExecuteInternalVMTests.java Changeset: 69627aa9ab10 Author: jwilhelm Date: 2012-12-21 16:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/69627aa9ab10 Merge ! src/share/vm/runtime/thread.cpp Changeset: 8b4810c80f5d Author: katleman Date: 2012-12-20 09:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8b4810c80f5d Added tag jdk8-b69 for changeset cb8a4e04bc8c ! .hgtags Changeset: 990bbd393c23 Author: amurillo Date: 2012-12-21 10:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/990bbd393c23 Merge Changeset: 6a1fc440b396 Author: amurillo Date: 2012-12-21 10:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6a1fc440b396 Added tag hs25-b14 for changeset 990bbd393c23 ! .hgtags Changeset: cd962e15c08e Author: amurillo Date: 2012-12-21 10:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cd962e15c08e 8005382: new hotspot build - hs25-b15 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 4daebd4cc1dd Author: minqi Date: 2012-12-24 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4daebd4cc1dd Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/arguments.cpp From peter.levart at gmail.com Wed Dec 26 03:58:21 2012 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 26 Dec 2012 12:58:21 +0100 Subject: final vs. volatile instance fields Message-ID: <50DAE65D.4060902@gmail.com> Hi hotspot gurus, I have a question (actually two) someone might answer off the top of his/her hat: Are there any performance differences in reading and writing of volatile vs. final instance fields? I can see that reflection is doing the same for both types (via UnsafeQualifiedFieldAccessorImpl subtypes) and is reading/writing the fields using Unsafe.getXxxVolatile/putXxxVolatile. So what does the JIT compiled code do? a) Are there any differences between writing to those two types of fields? The Java spec. mandates writing to final fields exactly once in the constructors and Java Memory Model says that they are "frozen" at the end of constructor. What does "freeze" actually translate to in the compiled code? b) I can understand that the JIT compiler can generate code that caches the value of final field say in a register, but initially the code has to load the value from a final field and the question is whether this initial load is any different from a volatile read? Thank you, Peter From sergey.kuksenko at oracle.com Wed Dec 26 04:30:24 2012 From: sergey.kuksenko at oracle.com (Sergey Kuksenko) Date: Wed, 26 Dec 2012 16:30:24 +0400 Subject: final vs. volatile instance fields In-Reply-To: <50DAE65D.4060902@gmail.com> References: <50DAE65D.4060902@gmail.com> Message-ID: <50DAEDE0.9010503@oracle.com> Hi Peter, You may find a general (not exactly about hotspot) answer in "The JSR-133 Cookbook for Compiler Writers". http://g.oswego.edu/dl/jmm/cookbook.html On 12/26/2012 03:58 PM, Peter Levart wrote: > Hi hotspot gurus, > > I have a question (actually two) someone might answer off the top of > his/her hat: > > Are there any performance differences in reading and writing of volatile > vs. final instance fields? I can see that reflection is doing the same > for both types (via UnsafeQualifiedFieldAccessorImpl subtypes) and is > reading/writing the fields using Unsafe.getXxxVolatile/putXxxVolatile. > So what does the JIT compiled code do? > > a) Are there any differences between writing to those two types of > fields? The Java spec. mandates writing to final fields exactly once in > the constructors and Java Memory Model says that they are "frozen" at > the end of constructor. What does "freeze" actually translate to in the > compiled code? > > b) I can understand that the JIT compiler can generate code that caches > the value of final field say in a register, but initially the code has > to load the value from a final field and the question is whether this > initial load is any different from a volatile read? > > Thank you, > > Peter > -- Best regards, Sergey Kuksenko From aleksey.shipilev at oracle.com Wed Dec 26 04:31:57 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 26 Dec 2012 16:31:57 +0400 Subject: final vs. volatile instance fields In-Reply-To: <50DAE65D.4060902@gmail.com> References: <50DAE65D.4060902@gmail.com> Message-ID: <4EBB542F-1E73-47F0-86E0-34C0929A8F33@oracle.com> Hi Peter, You should really consider reading JSR 133 Cookbook: http://g.oswego.edu/dl/jmm/cookbook.html I think you will need to move this discussion on concurrency-interest@ if you want the discussion on broader cross-hardware cross-implementation scope. On 26.12.2012, at 15:58, Peter Levart wrote: > Are there any performance differences in reading and writing of volatile vs. final instance fields? I can see that reflection is doing the same for both types (via UnsafeQualifiedFieldAccessorImpl subtypes) and is reading/writing the fields using Unsafe.getXxxVolatile/putXxxVolatile. So what does the JIT compiled code do? The short answer is that volatile read generally entails more than just a read, it should also conform to JMM, and as such entail barriers, which might exhibit performance costs due to breaking the pipelining, register allocation, ant other fruitful optimizations. While the barriers might be no-oped on some hardware (x86 included), the compiler effects are still in place. Writing final fields is troublesome to reason, and I fully expect JVMs to bailout to volatile-like semantics to preserve (weaker) final fields invariants. > a) Are there any differences between writing to those two types of fields? The Java spec. mandates writing to final fields exactly once in the constructors and Java Memory Model says that they are "frozen" at the end of constructor. What does "freeze" actually translate to in the compiled code? Final fields entail the barrier at the end of constructor, and then piggyback heavily on data-dependency (absence) of reordering. Cookbook explains this well enough. And writing volatile fields can incur prohibitive costs due to JMM effects needing to be enforced. > b) I can understand that the JIT compiler can generate code that caches the value of final field say in a register, but initially the code has to load the value from a final field and the question is whether this initial load is any different from a volatile read? Uhm... Depends on "difference". Yes, reading the final field requires reading the object reference first, and so we can piggyback for almost all of the commodity hardware to not to reorder dependent reads. On hypothetical hardware (Alpha, die already!) you have no such guarantee and reading the final fields will incur barriers similar to volatile read. -Aleksey. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121226/c546132c/attachment.html From peter.levart at gmail.com Wed Dec 26 05:29:41 2012 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 26 Dec 2012 14:29:41 +0100 Subject: final vs. volatile instance fields In-Reply-To: <4EBB542F-1E73-47F0-86E0-34C0929A8F33@oracle.com> References: <50DAE65D.4060902@gmail.com> <4EBB542F-1E73-47F0-86E0-34C0929A8F33@oracle.com> Message-ID: <50DAFBC5.6000606@marand.si> On 12/26/2012 01:31 PM, Aleksey Shipilev wrote: > Hi Peter, > > You should really consider reading JSR 133 Cookbook: > http://g.oswego.edu/dl/jmm/cookbook.html > Sergey, Aleksey, thank you very much for the pointer to the Coockbook. This is a valuable resource. All the best, Peter > I think you will need to move this discussion on concurrency-interest@ > if you want the discussion on broader cross-hardware > cross-implementation scope. > > On 26.12.2012, at 15:58, Peter Levart > wrote: > >> Are there any performance differences in reading and writing of >> volatile vs. final instance fields? I can see that reflection is >> doing the same for both types (via UnsafeQualifiedFieldAccessorImpl >> subtypes) and is reading/writing the fields using >> Unsafe.getXxxVolatile/putXxxVolatile. So what does the JIT compiled >> code do? > > The short answer is that volatile read generally entails more than > just a read, it should also conform to JMM, and as such entail > barriers, which might exhibit performance costs due to breaking the > pipelining, register allocation, ant other fruitful optimizations. > While the barriers might be no-oped on some hardware (x86 included), > the compiler effects are still in place. > > Writing final fields is troublesome to reason, and I fully expect JVMs > to bailout to volatile-like semantics to preserve (weaker) final > fields invariants. > >> a) Are there any differences between writing to those two types of >> fields? The Java spec. mandates writing to final fields exactly once >> in the constructors and Java Memory Model says that they are "frozen" >> at the end of constructor. What does "freeze" actually translate to >> in the compiled code? > > Final fields entail the barrier at the end of constructor, and then > piggyback heavily on data-dependency (absence) of reordering. Cookbook > explains this well enough. And writing volatile fields can incur > prohibitive costs due to JMM effects needing to be enforced. > >> b) I can understand that the JIT compiler can generate code that >> caches the value of final field say in a register, but initially the >> code has to load the value from a final field and the question is >> whether this initial load is any different from a volatile read? > > Uhm... Depends on "difference". Yes, reading the final field requires > reading the object reference first, and so we can piggyback for almost > all of the commodity hardware to not to reorder dependent reads. On > hypothetical hardware (Alpha, die already!) you have no such guarantee > and reading the final fields will incur barriers similar to volatile > read. > > -Aleksey. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121226/2c426770/attachment.html From harold.seigel at oracle.com Wed Dec 26 11:56:32 2012 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 26 Dec 2012 14:56:32 -0500 Subject: Request for review 8003705: CDS failed on Windows: cannot map in the CDS In-Reply-To: References: <50D34655.2030105@oracle.com> Message-ID: <50DB5670.2030009@oracle.com> Hi, Please review this new fix for bug 8003705. This new fix contains a Windows-only call to MemTracker::record_virtual_memory_type() to ensure that the CDS region gets marked as shared memory on Windows. The new webrev is at: http://cr.openjdk.java.net/~hseigel/bug_8003705_2/ Thanks! Harold On 12/20/2012 1:41 PM, Karen Kinnear wrote: > Harold, > > Thank you for fixing these. The code in itself looks good. > > How does it interact with NMT? We want to ensure that the CDS space shows up in NMT > on Windows as well - so if we skip the virtual mapping you may need to do that manually. > > thanks, > Karen > > On Dec 20, 2012, at 12:09 PM, harold seigel wrote: > >> Hi, >> >> Please review the following changes to fix bug 8003705. >> >> Summary: >> When trying to read the CDS file, the existing code was calling both the Windows VirtualAlloc() and MapViewOfFileEx() api's. The calls to MapViewOfFileEx() were failing with ERROR_INVALID_ADDRESS because VirtualAlloc() had already reserved the memory. >> >> This fix prevents the call to VirtualAlloc(), allowing the MapViewOfFileEx() calls to succeed. >> >> Another problem was that 'java -Xshare:dump calls were unable to overwrite an existing CDS file. This change fixes this by granting the owner full permission when creating the CDS file (mode o744). >> >> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8003705/ >> >> Bug link at http://bugs.sun.com/view_bug.do?bug_id=8003705 >> >> >> Thanks! >> Harold From coleen.phillimore at oracle.com Thu Dec 27 08:23:01 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 27 Dec 2012 11:23:01 -0500 Subject: Request for review 8005494: SIGSEGV in Rewriter::relocate_and_link() when testing Weblogic with Compre,ssedOops and KlassPtrs Message-ID: <50DC75E5.4050405@oracle.com> Summary: Relocate functions with jsr's when rewriting so not repeated after reading shared archive. open webrev at http://cr.openjdk.java.net/~coleenp/8005494/ bug link at http://bugs.sun.com/view_bug.do?bug_id=8005494 Ran runThese jck and parallel class loading tests (called from redefine classes). A note about the change to handles.inline.hpp. From trying to debug bug https://jbs.oracle.com/bugs/browse/JDK-8005521 , I decided from code inspection that the _thread should be set to NULL (wasn't the cause of the bug). Also, this change removes dead code that is no longer used for JSR 292. Thanks, Coleen From vladimir.kozlov at oracle.com Thu Dec 27 09:49:00 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 27 Dec 2012 09:49:00 -0800 Subject: RFR (S) : 8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <50D87869.8070700@oracle.com> References: <50D87869.8070700@oracle.com> Message-ID: <50DC8A0C.9000806@oracle.com> Bharadwaj, I would check for < jdk8 instead of !>=, it is more clear : + if (! (_major_version >= JAVA_8_VERSION)) { Next should be one line "} else {": + } + else { I would move the legality table comment inside "if (is_interface)". Why is_public and is_abstract in your table are illegal before jdk5? The conditions check the opposite. Should you also check for (is_protected) for versions before jdk8? It may be not defined for those versions but for condition completeness we should check. Also I don't see checks for is_bridge, is_varargs, is_synthetic. And what about pre jdk5? I would split >=jdk5 and pre versions to follow the table: if (major_gte_8) { ... } else if (major_gte_15) { ... } else { ... } Thanks, Vladimir On 12/24/12 7:44 AM, Bharadwaj Yadavalli wrote: > I updated legality verification of default methods of a Java 8 > interfaces. This update > fixes JDK-8004967 and three other failures in Lambda's test-ng tests. > > I also cleaned up the legality verification of interface methods of > pre-Java 8 interface > methods. I refactored the code by separating the checks depending on the > version > being pre-Java 8 or Java 8 and later. > > Please review the changes at > http://cr.openjdk.java.net/~bharadwaj/8004967/hotspot/webrev/ > > Ran api, lang and vm JCK tests; no new failures. > > Thanks, > > Bharadwaj > From bharadwaj.yadavalli at oracle.com Thu Dec 27 11:43:35 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Thu, 27 Dec 2012 14:43:35 -0500 Subject: RFR (S) : 8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <50DC8A0C.9000806@oracle.com> References: <50D87869.8070700@oracle.com> <50DC8A0C.9000806@oracle.com> Message-ID: <50DCA4E7.3030102@oracle.com> Thanks for your review, Vladimir. On 12/27/2012 12:49 PM, Vladimir Kozlov wrote: > Bharadwaj, > > I would check for < jdk8 instead of !>=, it is more clear : > > + if (! (_major_version >= JAVA_8_VERSION)) { > OK. > Next should be one line "} else {": > > + } > + else { > OK. > I would move the legality table comment inside "if (is_interface)". OK. > Why is_public and is_abstract in your table are illegal before jdk5? > The conditions check the opposite. > I'll change the comment. I believe that they should be legal across all JDK versions. > Should you also check for (is_protected) for versions before jdk8? I thought about that. But, for now, as I am not aware of the history about its apparent omission in the original code, I took the conservative route of retaining the code that has been working for all pre-Java 8 versions (see the diff at http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/diff/4735d2c84362/src/share/vm/classfile/classFileParser.cpp). That was also the reason why I did the refactoring as: if (major_gte_8) { ... } else { /* Working code */ ... } > It may be not defined for those versions but for condition > completeness we should check. Also I don't see checks for is_bridge, > is_varargs, is_synthetic. And what about pre jdk5? I would split > >=jdk5 and pre versions to follow the table: > > if (major_gte_8) { > ... > } else if (major_gte_15) { > ... > } else { > ... > } > Yes, that would be ideal. I will try to get some more definitive information about the legality of all the interface method modifiers for all supported Java versions. I would be grateful if anyone on the mailing list has the information and can provide the same. Thanks, Bharadwaj From john.coomes at oracle.com Thu Dec 27 21:09:50 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Dec 2012 05:09:50 +0000 Subject: hg: hsx/hotspot-emb: 10 new changesets Message-ID: <20121228050951.456AD47400@hg.openjdk.java.net> Changeset: fb1bf5e5bc9e Author: henryjen Date: 2012-12-06 15:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/fb1bf5e5bc9e 8004685: add java.util.function to CORE_PKGS.gmk Reviewed-by: mduigou ! common/makefiles/javadoc/CORE_PKGS.gmk Changeset: e08b0096058f Author: lana Date: 2012-12-14 11:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/e08b0096058f Merge Changeset: 8e36a0fabf58 Author: ohrstrom Date: 2012-12-18 09:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/8e36a0fabf58 8004145: New improved hgforest.sh, ctrl-c now properly terminates mercurial processes. Reviewed-by: ohair, erikj + common/bin/hgforest.sh ! get_source.sh Changeset: 51d3b65b8093 Author: erikj Date: 2012-12-18 17:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/51d3b65b8093 8001901: build-infra: Fix "misbehaving" which command on Solaris Summary: Removed all uses of which in configure on solaris. Reviewed-by: ohair ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: 6ee8080a6efe Author: katleman Date: 2012-12-19 13:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/6ee8080a6efe Merge Changeset: 32148e971ac8 Author: katleman Date: 2012-12-20 09:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/32148e971ac8 Added tag jdk8-b69 for changeset 6ee8080a6efe ! .hgtags Changeset: 6b93e7a4401d Author: dholmes Date: 2012-12-20 01:44 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/6b93e7a4401d 7190137: Add support for JVM_VARIANT minimal1 Summary: Allow configuration of minimal1 as a target VM along with client and server Reviewed-by: ohair, erikj ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: cd06b2ea58dd Author: katleman Date: 2012-12-20 16:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/cd06b2ea58dd 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! common/makefiles/RMICompilation.gmk Changeset: 105a25ffa4a4 Author: katleman Date: 2012-12-26 14:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/105a25ffa4a4 Merge Changeset: 3fb32a5a2388 Author: katleman Date: 2012-12-27 12:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/3fb32a5a2388 Added tag jdk8-b70 for changeset 105a25ffa4a4 ! .hgtags From john.coomes at oracle.com Thu Dec 27 21:09:55 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Dec 2012 05:09:55 +0000 Subject: hg: hsx/hotspot-emb/corba: 2 new changesets Message-ID: <20121228050958.6A97E47401@hg.openjdk.java.net> Changeset: 603cceb495c8 Author: katleman Date: 2012-12-20 09:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/603cceb495c8 Added tag jdk8-b69 for changeset 22ddcac208a8 ! .hgtags Changeset: 8171d23e914d Author: katleman Date: 2012-12-27 12:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/8171d23e914d Added tag jdk8-b70 for changeset 603cceb495c8 ! .hgtags From john.coomes at oracle.com Thu Dec 27 21:10:03 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Dec 2012 05:10:03 +0000 Subject: hg: hsx/hotspot-emb/jaxp: 4 new changesets Message-ID: <20121228051017.D9B7947402@hg.openjdk.java.net> Changeset: 27421008f050 Author: katleman Date: 2012-12-20 09:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/27421008f050 Added tag jdk8-b69 for changeset 789a855de959 ! .hgtags Changeset: a72c8391cdd6 Author: katleman Date: 2012-12-20 16:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/a72c8391cdd6 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! src/com/sun/org/apache/xalan/internal/XalanConstants.java ! src/com/sun/org/apache/xalan/internal/utils/FactoryImpl.java Changeset: 6ec9edffc286 Author: katleman Date: 2012-12-26 14:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/6ec9edffc286 Merge Changeset: 63815efd132f Author: katleman Date: 2012-12-27 12:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/63815efd132f Added tag jdk8-b70 for changeset 6ec9edffc286 ! .hgtags From john.coomes at oracle.com Thu Dec 27 21:10:22 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Dec 2012 05:10:22 +0000 Subject: hg: hsx/hotspot-emb/jaxws: 2 new changesets Message-ID: <20121228051029.25AFA47403@hg.openjdk.java.net> Changeset: 3b1c2733d47e Author: katleman Date: 2012-12-20 09:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/3b1c2733d47e Added tag jdk8-b69 for changeset 756323c99011 ! .hgtags Changeset: f577a39c9fb3 Author: katleman Date: 2012-12-27 12:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/f577a39c9fb3 Added tag jdk8-b70 for changeset 3b1c2733d47e ! .hgtags From john.coomes at oracle.com Thu Dec 27 21:11:52 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Dec 2012 05:11:52 +0000 Subject: hg: hsx/hotspot-emb/jdk: 52 new changesets Message-ID: <20121228052214.E848347404@hg.openjdk.java.net> Changeset: e8b54ae97344 Author: jviswana Date: 2012-12-12 13:28 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e8b54ae97344 8004316: Printer - tempfile having incorrect extension Reviewed-by: bae, jgodinez ! src/solaris/classes/sun/print/UnixPrintJob.java Changeset: fd9e6b4c8488 Author: lana Date: 2012-12-14 11:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/fd9e6b4c8488 Merge Changeset: c69424f78060 Author: serb Date: 2012-12-11 19:45 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c69424f78060 7154778: [macosx] NSView-based implementation of sun.awt.EmbeddedFrame Summary: The new implementation of EmbeddedFrame to support SWT_AWT Bridge Reviewed-by: anthony, serb, leonidr Contributed-by: Petr Pchelko ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/PlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPrinterDialogPeer.java + src/macosx/classes/sun/lwawt/macosx/CViewEmbeddedFrame.java + src/macosx/classes/sun/lwawt/macosx/CViewPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CWrapper.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/AWTSurfaceLayers.m ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.m ! src/macosx/native/sun/awt/CCursorManager.m ! src/macosx/native/sun/awt/CWrapper.m ! src/macosx/native/sun/awt/awt.m ! src/macosx/native/sun/java2d/opengl/CGLLayer.m ! src/macosx/native/sun/osxapp/ThreadUtilities.h ! src/macosx/native/sun/osxapp/ThreadUtilities.m Changeset: e016ad35a764 Author: kshefov Date: 2012-12-13 15:14 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e016ad35a764 7132385: [macosx] IconifyTest of RepaintManager could use some delay Reviewed-by: serb, alexsch + test/javax/swing/RepaintManager/IconifyTest/IconifyTest.java Changeset: 71e03e17c183 Author: kshefov Date: 2012-12-14 13:32 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/71e03e17c183 6757986: javax/swing/JInternalFrame/5066752/bug5066752.java needs correction Reviewed-by: serb, alexsch + test/javax/swing/JInternalFrame/5066752/bug5066752.java Changeset: 9fc7460ca3ac Author: lana Date: 2012-12-14 11:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/9fc7460ca3ac Merge Changeset: 7004848974a2 Author: jgish Date: 2012-12-04 20:21 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/7004848974a2 8003596: TEST_BUG: java/util/logging/CheckLockLocationTest.java failing [win] Reviewed-by: alanb ! test/ProblemList.txt ! test/java/util/logging/CheckLockLocationTest.java Changeset: 44ae777564eb Author: mullan Date: 2012-12-04 17:40 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/44ae777564eb 8004188: Rename src/share/lib/security/java.security to java.security-linux Reviewed-by: mullan, mchung Contributed-by: jason.uh at oracle.com ! make/java/security/Makefile - src/share/lib/security/java.security + src/share/lib/security/java.security-linux Changeset: b54a5b7d2e65 Author: alanb Date: 2012-12-05 12:20 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/b54a5b7d2e65 8004491: Build breakage on Linux due to 8004188 Reviewed-by: chegar, erikj ! makefiles/CopyFiles.gmk Changeset: a971516029ab Author: jgish Date: 2012-12-05 21:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/a971516029ab 8004317: TestLibrary.getUnusedRandomPort() fails intermittently, but exception not reported Reviewed-by: alanb, dmocek, smarks ! test/java/rmi/testlibrary/TestLibrary.java Changeset: 41a1b110f34d Author: lancea Date: 2012-12-06 15:51 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/41a1b110f34d 8004374: CachedRowSetSwriter.writeData reports wrong number of conflicts in SyncProviderException Reviewed-by: naoto ! src/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java Changeset: 896d4af2ebfd Author: rfield Date: 2012-12-06 21:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/896d4af2ebfd 8003881: Prevent lambda implementing inner classes from allowing the creation of new instances Summary: Lambda implementing inner classes now has private constructor (thanks Kumar) Reviewed-by: ksrini ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java + test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java + test/java/lang/invoke/lambda/LambdaAccessControlTest.java Changeset: da387f0cecb7 Author: ksrini Date: 2012-12-09 07:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/da387f0cecb7 8004042: Arrrghs.java test failed on windows with access error. Reviewed-by: smarks, jjh, ksrini Contributed-by: david.dehaven at oracle.com ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java Changeset: 343615aa0539 Author: dxu Date: 2012-12-09 19:13 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/343615aa0539 7194370: (fs) WatchService fails if volume S/N is 0 [win] Reviewed-by: alanb, forax ! src/windows/classes/sun/nio/fs/WindowsFileAttributes.java Changeset: fda257689786 Author: okutsu Date: 2012-12-10 10:52 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/fda257689786 8000983: Support narrow display names for calendar fields 8003267: Support generic time zone names in TimeZoneNameProvider (SPI) Reviewed-by: naoto ! make/tools/src/build/tools/cldrconverter/Bundle.java ! make/tools/src/build/tools/cldrconverter/BundleGenerator.java ! make/tools/src/build/tools/cldrconverter/CLDRConverter.java ! make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java ! make/tools/src/build/tools/cldrconverter/MetaZonesParseHandler.java ! make/tools/src/build/tools/cldrconverter/ResourceBundleGenerator.java ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/JapaneseImperialCalendar.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/java/util/spi/CalendarNameProvider.java ! src/share/classes/java/util/spi/TimeZoneNameProvider.java ! src/share/classes/sun/text/resources/FormatData.java ! src/share/classes/sun/text/resources/ar/FormatData_ar.java ! src/share/classes/sun/text/resources/be/FormatData_be.java ! src/share/classes/sun/text/resources/bg/FormatData_bg.java ! src/share/classes/sun/text/resources/ca/FormatData_ca.java ! src/share/classes/sun/text/resources/cs/FormatData_cs.java ! src/share/classes/sun/text/resources/da/FormatData_da.java ! src/share/classes/sun/text/resources/de/FormatData_de.java ! src/share/classes/sun/text/resources/el/FormatData_el.java ! src/share/classes/sun/text/resources/es/FormatData_es.java ! src/share/classes/sun/text/resources/et/FormatData_et.java ! src/share/classes/sun/text/resources/fi/FormatData_fi.java ! src/share/classes/sun/text/resources/fr/FormatData_fr.java ! src/share/classes/sun/text/resources/hi/FormatData_hi_IN.java ! src/share/classes/sun/text/resources/hr/FormatData_hr.java ! src/share/classes/sun/text/resources/hu/FormatData_hu.java ! src/share/classes/sun/text/resources/is/FormatData_is.java ! src/share/classes/sun/text/resources/it/FormatData_it.java ! src/share/classes/sun/text/resources/iw/FormatData_iw.java ! src/share/classes/sun/text/resources/ja/FormatData_ja.java ! src/share/classes/sun/text/resources/ko/FormatData_ko.java ! src/share/classes/sun/text/resources/lt/FormatData_lt.java ! src/share/classes/sun/text/resources/lv/FormatData_lv.java ! src/share/classes/sun/text/resources/mk/FormatData_mk.java ! src/share/classes/sun/text/resources/ms/FormatData_ms.java ! src/share/classes/sun/text/resources/mt/FormatData_mt.java ! src/share/classes/sun/text/resources/nl/FormatData_nl.java ! src/share/classes/sun/text/resources/pl/FormatData_pl.java ! src/share/classes/sun/text/resources/pt/FormatData_pt.java ! src/share/classes/sun/text/resources/ro/FormatData_ro.java ! src/share/classes/sun/text/resources/ru/FormatData_ru.java ! src/share/classes/sun/text/resources/sk/FormatData_sk.java ! src/share/classes/sun/text/resources/sl/FormatData_sl.java ! src/share/classes/sun/text/resources/sq/FormatData_sq.java ! src/share/classes/sun/text/resources/sr/FormatData_sr.java ! src/share/classes/sun/text/resources/sv/FormatData_sv.java ! src/share/classes/sun/text/resources/th/FormatData_th.java ! src/share/classes/sun/text/resources/tr/FormatData_tr.java ! src/share/classes/sun/text/resources/uk/FormatData_uk.java ! src/share/classes/sun/text/resources/vi/FormatData_vi.java ! src/share/classes/sun/text/resources/zh/FormatData_zh.java ! src/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/CalendarDataUtility.java ! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleResources.java ! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java ! src/share/classes/sun/util/resources/LocaleData.java ! src/share/classes/sun/util/resources/OpenListResourceBundle.java ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNamesBundle.java + test/java/util/Calendar/GenericTimeZoneNamesTest.java + test/java/util/Calendar/GenericTimeZoneNamesTest.sh + test/java/util/Calendar/NarrowNamesTest.java + test/java/util/Calendar/NarrowNamesTest.sh ! test/java/util/PluggableLocale/GenericTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.sh ! test/java/util/PluggableLocale/barprovider.jar + test/java/util/PluggableLocale/providersrc/GenericTimeZoneNameProviderImpl.java ! test/java/util/PluggableLocale/providersrc/Makefile ! test/java/util/PluggableLocale/providersrc/java.util.spi.TimeZoneNameProvider ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: fda2b2b5b98b Author: michaelm Date: 2012-12-10 14:56 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/fda2b2b5b98b 8003948: NTLM/Negotiate authentication problem Reviewed-by: chegar, weijun ! src/share/classes/sun/net/www/MessageHeader.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/MessageHeaderTest.java Changeset: cac1bfaceaaa Author: mchung Date: 2012-12-10 15:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/cac1bfaceaaa 4819681: Typo in http://java.sun.com/j2se/1.4.1/docs/api/java/util/logging/LogManager.html Summary: Simple capitalization typo in LogManager() description Reviewed-by: darcy, mchung ! src/share/classes/java/util/logging/LogManager.java Changeset: 883feced1cdd Author: dingxmin Date: 2012-12-11 10:42 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/883feced1cdd 6512101: Incorrect encoding in NetworkInterface.getDisplayName() Reviewed-by: chegar, dsamersoff ! src/windows/native/java/net/NetworkInterface.c Changeset: d206e52bf8a6 Author: weijun Date: 2012-12-11 13:14 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/d206e52bf8a6 8004488: wrong permissions checked in krb5 Reviewed-by: xuelei ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java + test/sun/security/krb5/auto/KeyPermissions.java ! test/sun/security/krb5/auto/KeyTabCompat.java Changeset: c4bd81de2868 Author: akhil Date: 2012-12-11 15:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c4bd81de2868 8003246: Add InitialValue Supplier to ThreadLocal Reviewed-by: mduigou, forax, dl, chegar, briangoetz ! src/share/classes/java/lang/ThreadLocal.java + test/java/lang/ThreadLocal/ThreadLocalSupplierTest.java Changeset: 6c795437f212 Author: mduigou Date: 2012-12-11 20:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/6c795437f212 8004905: Correct license of test to remove classpath exception Reviewed-by: akhil ! test/java/lang/ThreadLocal/ThreadLocalSupplierTest.java Changeset: 12fba0974a9d Author: weijun Date: 2012-12-12 18:39 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/12fba0974a9d 8004904: Makefile for ntlm Reviewed-by: erikj, chegar ! make/com/sun/security/Makefile + make/com/sun/security/ntlm/Makefile Changeset: 806cf26e5063 Author: chegar Date: 2012-12-12 11:35 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/806cf26e5063 8004921: Trivial javadoc warnings in Base64 Reviewed-by: darcy ! src/share/classes/java/util/Base64.java Changeset: 81640e75c7a7 Author: alanb Date: 2012-12-12 13:03 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/81640e75c7a7 8004874: Reduce dependency on java.beans to only add/removePropertyChangeListener Reviewed-by: ksrini, mchung, dholmes ! src/share/classes/com/sun/java/util/jar/pack/PropMap.java ! src/share/classes/java/util/logging/LogManager.java Changeset: 346c0af4af41 Author: mullan Date: 2012-12-12 09:25 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/346c0af4af41 8004064: Downgrade normative references to ${java.home}/lib/security/java.security Reviewed-by: alanb, vinnie, xuelei ! src/share/classes/com/sun/net/ssl/KeyManagerFactory.java ! src/share/classes/com/sun/net/ssl/TrustManagerFactory.java ! src/share/classes/com/sun/security/auth/PolicyFile.java ! src/share/classes/com/sun/security/auth/login/ConfigFile.java ! src/share/classes/java/net/doc-files/net-properties.html ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/Policy.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/cert/CertPathBuilder.java ! src/share/classes/java/security/cert/CertPathValidator.java ! src/share/classes/java/security/cert/CertStore.java ! src/share/classes/javax/net/ssl/KeyManagerFactory.java ! src/share/classes/javax/net/ssl/TrustManagerFactory.java ! src/share/classes/javax/security/auth/Policy.java ! src/share/classes/javax/security/auth/callback/CallbackHandler.java ! src/share/classes/javax/security/auth/login/Configuration.java ! src/share/classes/javax/security/auth/login/LoginContext.java ! src/share/classes/javax/security/cert/X509Certificate.java Changeset: c7f86908d5fd Author: mullan Date: 2012-12-12 09:27 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c7f86908d5fd Merge - src/share/lib/security/java.security Changeset: 68374c6e65c1 Author: robm Date: 2012-12-12 15:57 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/68374c6e65c1 8004337: java/sql tests aren't run in test/Makefile Reviewed-by: lancea, alanb ! test/Makefile Changeset: bd84d0927a2e Author: smarks Date: 2012-12-12 09:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/bd84d0927a2e 8004748: clean up @build tags in RMI tests Reviewed-by: alanb, darcy, mchung ! test/java/rmi/MarshalledObject/compare/Compare.java ! test/java/rmi/MarshalledObject/compare/HashCode.java ! test/java/rmi/MarshalledObject/compare/NullReference.java ! test/java/rmi/Naming/DefaultRegistryPort.java ! test/java/rmi/Naming/LookupIPv6.java ! test/java/rmi/Naming/RmiIsNoScheme.java ! test/java/rmi/Naming/UnderscoreHost.java ! test/java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java ! test/java/rmi/RMISecurityManager/checkPackageAccess/CheckPackageAccess.java ! test/java/rmi/activation/Activatable/checkActivateRef/CheckActivateRef.java ! test/java/rmi/activation/Activatable/checkAnnotations/CheckAnnotations.java ! test/java/rmi/activation/Activatable/checkImplClassLoader/CheckImplClassLoader.java ! test/java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java ! test/java/rmi/activation/Activatable/createPrivateActivable/CreatePrivateActivatable.java ! test/java/rmi/activation/Activatable/downloadParameterClass/DownloadParameterClass.java ! test/java/rmi/activation/Activatable/elucidateNoSuchMethod/ElucidateNoSuchMethod.java ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/activation/Activatable/forceLogSnapshot/ForceLogSnapshot.java ! test/java/rmi/activation/Activatable/inactiveGroup/InactiveGroup.java ! test/java/rmi/activation/Activatable/lookupActivationSystem/LookupActivationSystem.java ! test/java/rmi/activation/Activatable/nestedActivate/NestedActivate.java ! test/java/rmi/activation/Activatable/nonExistentActivatable/NonExistentActivatable.java ! test/java/rmi/activation/Activatable/restartCrashedService/RestartCrashedService.java ! test/java/rmi/activation/Activatable/restartLatecomer/RestartLatecomer.java ! test/java/rmi/activation/Activatable/restartService/RestartService.java ! test/java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java ! test/java/rmi/activation/Activatable/unregisterInactive/UnregisterInactive.java ! test/java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java ! test/java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java ! test/java/rmi/activation/ActivationGroupDesc/checkDefaultGroupName/CheckDefaultGroupName.java ! test/java/rmi/activation/ActivationSystem/activeGroup/IdempotentActiveGroup.java ! test/java/rmi/activation/ActivationSystem/modifyDescriptor/ModifyDescriptor.java ! test/java/rmi/activation/ActivationSystem/stubClassesPermitted/StubClassesPermitted.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java ! test/java/rmi/activation/CommandEnvironment/NullOptions.java ! test/java/rmi/activation/CommandEnvironment/SetChildEnv.java ! test/java/rmi/activation/checkusage/CheckUsage.java ! test/java/rmi/activation/log/LogTest.java ! test/java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java ! test/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java ! test/java/rmi/dgc/VMID/CheckVMID.java ! test/java/rmi/dgc/dgcAckFailure/DGCAckFailure.java ! test/java/rmi/dgc/dgcImplInsulation/DGCImplInsulation.java ! test/java/rmi/dgc/retryDirtyCalls/RetryDirtyCalls.java ! test/java/rmi/invalidName/InvalidName.java ! test/java/rmi/registry/altSecurityManager/AltSecurityManager.java ! test/java/rmi/registry/checkusage/CheckUsage.java ! test/java/rmi/registry/classPathCodebase/ClassPathCodebase.java ! test/java/rmi/registry/interfaceHash/InterfaceHash.java ! test/java/rmi/registry/multipleRegistries/MultipleRegistries.java ! test/java/rmi/registry/readTest/readTest.sh ! test/java/rmi/registry/reexport/Reexport.java ! test/java/rmi/reliability/benchmark/runRmiBench.sh ! test/java/rmi/reliability/benchmark/runSerialBench.sh ! test/java/rmi/reliability/juicer/AppleUserImpl.java ! test/java/rmi/server/ObjID/randomIDs/RandomIDs.java ! test/java/rmi/server/RMIClassLoader/delegateBeforePermissionCheck/DelegateBeforePermissionCheck.java ! test/java/rmi/server/RMIClassLoader/delegateToContextLoader/DelegateToContextLoader.java ! test/java/rmi/server/RMIClassLoader/downloadArrayClass/DownloadArrayClass.java ! test/java/rmi/server/RMIClassLoader/getClassAnnotation/NullClass.java ! test/java/rmi/server/RMIClassLoader/getClassLoader/GetClassLoader.java ! test/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java ! test/java/rmi/server/RMIClassLoader/noSecurityManager/NoSecurityManager.java ! test/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java ! test/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java ! test/java/rmi/server/RMIClassLoader/spi/Installed.java ! test/java/rmi/server/RMIClassLoader/spi/InvalidProperty.java ! test/java/rmi/server/RMIClassLoader/spi/Property.java ! test/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java ! test/java/rmi/server/RMIClassLoader/useGetURLs/UseGetURLs.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/UseCustomSocketFactory.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/registry/UseCustomSocketFactory.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/unicast/UseCustomSocketFactory.java ! test/java/rmi/server/RemoteObject/notExtending/NotExtending.java ! test/java/rmi/server/RemoteObject/verifyRemoteEquals/VerifyRemoteEquals.java ! test/java/rmi/server/RemoteServer/AddrInUse.java ! test/java/rmi/server/UnicastRemoteObject/changeHostName/ChangeHostName.java ! test/java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java ! test/java/rmi/server/UnicastRemoteObject/keepAliveDuringCall/KeepAliveDuringCall.java ! test/java/rmi/server/UnicastRemoteObject/marshalAfterUnexport/MarshalAfterUnexport.java ! test/java/rmi/server/UnicastRemoteObject/marshalAfterUnexport/MarshalAfterUnexport2.java ! test/java/rmi/server/UnicastRemoteObject/unexportObject/UnexportLeak.java ! test/java/rmi/server/Unmarshal/PrimitiveClasses.java + test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshal.java ! test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshalOnStopThread.java - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java ! test/java/rmi/server/Unreferenced/finiteGCLatency/FiniteGCLatency.java ! test/java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java ! test/java/rmi/server/Unreferenced/marshalledObjectGet/MarshalledObjectGet.java ! test/java/rmi/server/Unreferenced/unreferencedContext/UnreferencedContext.java ! test/java/rmi/server/clientStackTrace/ClientStackTrace.java ! test/java/rmi/server/getRemoteClass/GetRemoteClass.java ! test/java/rmi/server/serverStackTrace/ServerStackTrace.java ! test/java/rmi/server/serverStackTrace/SuppressStackTraces.java ! test/java/rmi/server/useCustomRef/UseCustomRef.java ! test/java/rmi/transport/acceptLoop/CloseServerSocketOnTermination.java ! test/java/rmi/transport/checkFQDN/CheckFQDN.java ! test/java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java ! test/java/rmi/transport/closeServerSocket/CloseServerSocket.java ! test/java/rmi/transport/dgcDeadLock/DGCDeadLock.java ! test/java/rmi/transport/handshakeFailure/HandshakeFailure.java ! test/java/rmi/transport/handshakeTimeout/HandshakeTimeout.java ! test/java/rmi/transport/httpSocket/HttpSocketTest.java ! test/java/rmi/transport/rapidExportUnexport/RapidExportUnexport.java ! test/java/rmi/transport/readTimeout/ReadTimeoutTest.java ! test/java/rmi/transport/reuseDefaultPort/ReuseDefaultPort.java ! test/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java ! test/javax/rmi/ssl/SocketFactoryTest.java ! test/sun/rmi/log/ReliableLog/LogAlignmentTest.java ! test/sun/rmi/log/ReliableLog/SnapshotSize.java ! test/sun/rmi/rmic/RMIGenerator/RmicDefault.java ! test/sun/rmi/rmic/newrmic/equivalence/run.sh ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java ! test/sun/rmi/runtime/Log/checkLogging/CheckLogStreams.java ! test/sun/rmi/runtime/Log/checkLogging/CheckLogging.java ! test/sun/rmi/server/MarshalOutputStream/marshalForeignStub/MarshalForeignStub.java ! test/sun/rmi/transport/proxy/EagerHttpFallback.java ! test/sun/rmi/transport/tcp/DeadCachedConnection.java ! test/sun/rmi/transport/tcp/blockAccept/BlockAcceptTest.java ! test/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java Changeset: 56fd5479a98f Author: jgish Date: 2012-12-12 15:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/56fd5479a98f 8004651: TEST: java/util/logging/CheckLockLocationTest.java failed to delete file (win) Summary: Failure to delete test log file should be a warning instead of test failure Reviewed-by: mduigou, smarks ! test/java/util/logging/CheckLockLocationTest.java Changeset: 5a2ab2c3f106 Author: weijun Date: 2012-12-13 08:11 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/5a2ab2c3f106 8004235: Disable native JGSS provider on Mac Reviewed-by: erikj, valeriep ! make/sun/security/Makefile ! makefiles/CompileNativeLibraries.gmk ! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java Changeset: 7a8978a5bb6e Author: lancea Date: 2012-12-12 20:57 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/7a8978a5bb6e 8004357: Implement various methods in SerialBlob/Clob/Array and specify Thread Safety Reviewed-by: naoto ! src/share/classes/javax/sql/rowset/serial/SerialArray.java ! src/share/classes/javax/sql/rowset/serial/SerialBlob.java ! src/share/classes/javax/sql/rowset/serial/SerialClob.java ! src/share/classes/javax/sql/rowset/serial/SerialDatalink.java ! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java ! src/share/classes/javax/sql/rowset/serial/SerialRef.java ! src/share/classes/javax/sql/rowset/serial/SerialStruct.java Changeset: 775b0050144a Author: chegar Date: 2012-12-13 09:55 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/775b0050144a 8004925: java/net/Socks/SocksV4Test.java failing on all platforms Reviewed-by: alanb, dsamersoff ! test/java/net/Socks/SocksV4Test.java Changeset: 682d2d3ccff5 Author: chegar Date: 2012-12-13 14:33 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/682d2d3ccff5 8004675: Inet6Address.getHostAddress should use string scope identifier where available Summary: ...and some minor stylistic cleanup Reviewed-by: khazra, dsamersoff, michaelm ! src/share/classes/java/net/Inet6Address.java ! src/share/native/java/net/Inet6Address.c + test/java/net/Inet6Address/StringScope.java Changeset: c97618a3c8c2 Author: juh Date: 2012-12-13 09:35 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/c97618a3c8c2 7193792: sun/security/pkcs11/ec/TestECDSA.java failing intermittently Reviewed-by: vinnie, wetmore ! test/ProblemList.txt ! test/sun/security/pkcs11/ec/TestECDSA.java Changeset: 7b697da6626a Author: mullan Date: 2012-12-13 09:37 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/7b697da6626a Merge Changeset: ae5d04dbacd6 Author: chegar Date: 2012-12-13 14:47 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/ae5d04dbacd6 8003890: corelibs test scripts should pass TESTVMOPTS Reviewed-by: chegar, alanb Contributed-by: Mark Sheppard ! test/com/oracle/net/sanity.sh ! test/com/sun/corba/cachedSocket/7056731.sh ! test/com/sun/management/OperatingSystemMXBean/TestTotalSwap.sh ! test/com/sun/management/UnixOperatingSystemMXBean/GetMaxFileDescriptorCount.sh ! test/com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh ! test/com/sun/tools/attach/ApplicationSetup.sh ! test/com/sun/tools/attach/BasicTests.sh ! test/com/sun/tools/attach/PermissionTests.sh ! test/com/sun/tools/attach/ProviderTests.sh ! test/com/sun/tools/extcheck/TestExtcheckArgs.sh ! test/demo/zipfs/basic.sh ! test/java/io/File/GetXSpace.sh ! test/java/io/File/MacPathTest.sh ! test/java/io/File/basic.sh ! test/java/io/FileOutputStream/FileOpen.sh ! test/java/io/Serializable/class/run.sh ! test/java/io/Serializable/evolution/AddedExternField/run.sh ! test/java/io/Serializable/evolution/RenamePackage/run.sh ! test/java/io/Serializable/maskSyntheticModifier/run.sh ! test/java/io/Serializable/packageAccess/run.sh ! test/java/io/Serializable/resolveClass/consTest/run.sh ! test/java/io/Serializable/resolveClass/deserializeButton/run.sh ! test/java/io/Serializable/subclass/run.sh ! test/java/io/Serializable/superclassDataLoss/run.sh ! test/java/io/Serializable/unnamedPackageSwitch/run.sh ! test/java/lang/Class/forName/NonJavaNames.sh ! test/java/lang/ClassLoader/Assert.sh ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh ! test/java/lang/ClassLoader/getdotresource.sh ! test/java/lang/Runtime/exec/setcwd.sh ! test/java/lang/StringCoding/CheckEncodings.sh ! test/java/lang/System/finalization/FinExit.sh ! test/java/lang/annotation/loaderLeak/LoaderLeak.sh ! test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh ! test/java/net/Authenticator/B4933582.sh ! test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh ! test/java/net/InetAddress/ptr/lookup.sh ! test/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.sh ! test/java/net/Socket/OldSocketImpl.sh ! test/java/net/URL/B5086147.sh ! test/java/net/URL/runconstructor.sh ! test/java/net/URLClassLoader/B5077773.sh ! test/java/net/URLClassLoader/getresourceasstream/test.sh ! test/java/net/URLClassLoader/sealing/checksealed.sh ! test/java/net/URLConnection/6212146/test.sh ! test/java/net/URLConnection/UNCTest.sh ! test/java/nio/Buffer/LimitDirectMemory.sh ! test/java/nio/channels/AsynchronousChannelGroup/run_any_task.sh ! test/java/nio/channels/spi/AsynchronousChannelProvider/custom_provider.sh ! test/java/nio/charset/Charset/default.sh ! test/java/nio/charset/coders/CheckSJISMappingProp.sh ! test/java/nio/charset/spi/basic.sh ! test/java/nio/file/Files/delete_on_close.sh ! test/java/nio/file/Files/walkFileTree/walk_file_tree.sh ! test/java/nio/file/Path/MacPathTest.sh ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/registry/readTest/readTest.sh ! test/java/rmi/reliability/benchmark/runSerialBench.sh ! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh ! test/java/security/Security/signedfirst/Dyn.sh ! test/java/security/Security/signedfirst/Static.sh ! test/java/security/cert/CertificateFactory/slowstream.sh ! test/java/util/Currency/PropertiesTest.sh ! test/java/util/Locale/LocaleCategory.sh ! test/java/util/Locale/LocaleProviders.sh ! test/java/util/PluggableLocale/ExecTest.sh ! test/java/util/ResourceBundle/Bug6299235Test.sh ! test/java/util/ResourceBundle/Control/MissingResourceCauseTest.sh ! test/java/util/ServiceLoader/basic.sh ! test/java/util/TimeZone/OldIDMappingTest.sh ! test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh ! test/java/util/prefs/CheckUserPrefsStorage.sh ! test/java/util/prefs/PrefsSpi.sh ! test/java/util/spi/ResourceBundleControlProvider/UserDefaultControlTest.sh ! test/java/util/zip/3GBZipFiles.sh ! test/java/util/zip/ZipFile/deletetempjar.sh ! test/javax/crypto/SecretKeyFactory/FailOverTest.sh ! test/javax/print/applet/AppletPrintLookup.sh ! test/javax/script/ProviderTest.sh ! test/javax/security/auth/Subject/doAs/Test.sh ! test/lib/security/java.policy/Ext_AllPolicy.sh ! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.sh ! test/sun/management/jmxremote/bootstrap/LocalManagementTest.sh ! test/sun/management/jmxremote/bootstrap/PasswordFilePermissionTest.sh ! test/sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.sh ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh ! test/sun/misc/Cleaner/exitOnThrow.sh ! test/sun/net/InetAddress/nameservice/dns/cname.sh ! test/sun/net/sdp/sanity.sh ! test/sun/net/www/MarkResetTest.sh ! test/sun/net/www/http/HttpClient/RetryPost.sh ! test/sun/net/www/protocol/file/DirPermissionDenied.sh ! test/sun/net/www/protocol/jar/B5105410.sh ! test/sun/net/www/protocol/jar/getcontenttype.sh ! test/sun/net/www/protocol/jar/jarbug/run.sh ! test/sun/rmi/rmic/manifestClassPath/run.sh ! test/sun/rmi/rmic/minimizeWrapperInstances/run.sh ! test/sun/rmi/rmic/oldjavacRemoved/sunToolsJavacMain.sh ! test/sun/security/krb5/runNameEquals.sh ! test/sun/security/krb5/tools/ktcheck.sh ! test/sun/security/mscapi/AccessKeyStore.sh ! test/sun/security/mscapi/IsSunMSCAPIAvailable.sh ! test/sun/security/mscapi/KeyStoreCompatibilityMode.sh ! test/sun/security/mscapi/PublicKeyInterop.sh ! test/sun/security/mscapi/RSAEncryptDecrypt.sh ! test/sun/security/mscapi/ShortRSAKey1024.sh ! test/sun/security/mscapi/SignUsingNONEwithRSA.sh ! test/sun/security/mscapi/SignUsingSHA2withRSA.sh ! test/sun/security/pkcs11/KeyStore/Basic.sh ! test/sun/security/pkcs11/KeyStore/ClientAuth.sh ! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh ! test/sun/security/pkcs11/KeyStore/Solaris.sh ! test/sun/security/pkcs11/Provider/ConfigQuotedString.sh ! test/sun/security/pkcs11/Provider/Login.sh ! test/sun/security/provider/PolicyFile/GrantAllPermToExtWhenNoPolicy.sh ! test/sun/security/provider/PolicyFile/getinstance/getinstance.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh ! test/sun/security/tools/jarsigner/emptymanifest.sh ! test/sun/security/tools/jarsigner/ts.sh ! test/sun/security/tools/keytool/printssl.sh ! test/sun/security/tools/keytool/standard.sh ! test/sun/security/validator/certreplace.sh ! test/sun/security/validator/samedn.sh ! test/tools/launcher/6842838/Test6842838.sh ! test/tools/launcher/MultipleJRE.sh Changeset: 087425441a48 Author: robm Date: 2012-12-13 15:28 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/087425441a48 8000525: Java.net.httpcookie api does not support 2-digit year format Reviewed-by: chegar ! src/share/classes/java/net/HttpCookie.java ! test/java/net/CookieHandler/B6791927.java ! test/java/net/CookieHandler/CookieManagerTest.java + test/java/net/HttpCookie/ExpiredCookieTest.java Changeset: 8d7323a9d8ed Author: dholmes Date: 2012-12-13 21:18 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/8d7323a9d8ed 8003632: HPROF class file version java.lang.RuntimeException errors Reviewed-by: mchung, lancea ! src/share/javavm/export/classfile_constants.h Changeset: de6b54a60d60 Author: lana Date: 2012-12-14 13:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/de6b54a60d60 Merge ! makefiles/CompileNativeLibraries.gmk - src/share/lib/security/java.security - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java Changeset: 4ea0ac8e02d2 Author: erikj Date: 2012-12-19 09:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/4ea0ac8e02d2 8004803: build-infra: Cannot use icedtea as boot for closed build. Summary: Set bootclasspath to javac and not the running jvm Reviewed-by: ohair ! makefiles/CreateJars.gmk Changeset: a8012d8d7e9c Author: katleman Date: 2012-12-19 13:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/a8012d8d7e9c Merge Changeset: 4d5db5c038b4 Author: katleman Date: 2012-12-20 09:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/4d5db5c038b4 Added tag jdk8-b69 for changeset a8012d8d7e9c ! .hgtags Changeset: ad6097d547e1 Author: kvn Date: 2012-12-18 17:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/ad6097d547e1 8004318: JEP-171: Support Unsafe fences intrinsics Summary: Add three memory-ordering intrinsics to the sun.misc.Unsafe class. Reviewed-by: twisti, kvn Contributed-by: Aleksey Shipilev ! src/share/classes/sun/misc/Unsafe.java Changeset: 12fa4d7ecaf5 Author: twisti Date: 2012-12-20 11:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/12fa4d7ecaf5 8005345: JSR 292: JDK performance tweaks Reviewed-by: kvn, jrose ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/sun/invoke/util/ValueConversions.java Changeset: 8cf5b18488d1 Author: dl Date: 2012-12-20 12:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/8cf5b18488d1 8004330: Add missing Unsafe entry points for addAndGet() family Summary: Add Unsafe addAndGet() methods which have intrinsics in Hotspot (7023898) Reviewed-by: alanb, kvn ! src/share/classes/sun/misc/Unsafe.java Changeset: 6b41b40526c6 Author: amurillo Date: 2012-12-21 10:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/6b41b40526c6 Merge Changeset: 1ad29569d6e9 Author: erikj Date: 2012-12-20 13:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/1ad29569d6e9 8005178: build-infra: Dependency on libfdlibm on mac is broken Reviewed-by: tbell, ohair ! makefiles/CompileNativeLibraries.gmk Changeset: a68090f0dc1a Author: katleman Date: 2012-12-20 16:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/a68090f0dc1a 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! src/macosx/native/sun/font/CCharToGlyphMapper.m ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/Block.java ! src/share/classes/java/util/function/DoubleBlock.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/IntBlock.java ! src/share/classes/java/util/function/LongBlock.java ! src/share/classes/java/util/function/Predicate.java ! src/share/classes/sun/java2d/pipe/ParallelogramPipe.java ! src/share/classes/sun/tools/jcmd/JCmd.java ! src/share/native/java/util/zip/zlib-1.2.5/gzlib.c ! src/solaris/native/common/jdk_util_md.h ! src/solaris/native/sun/tools/attach/BsdVirtualMachine.c ! src/windows/classes/java/net/DualStackPlainDatagramSocketImpl.java ! src/windows/native/common/jdk_util_md.h ! test/com/sun/java/swing/plaf/windows/WindowsRadioButtonUI/7089914/bug7089914.java ! test/java/awt/Focus/6981400/Test1.java ! test/java/awt/Focus/6981400/Test2.java ! test/java/awt/Focus/6981400/Test3.java ! test/java/awt/Frame/ResizeAfterSetFont/ResizeAfterSetFont.java ! test/java/awt/JAWT/JAWT.sh ! test/java/awt/JAWT/Makefile.cygwin ! test/java/awt/JAWT/Makefile.unix ! test/java/awt/JAWT/Makefile.win ! test/java/awt/JAWT/MyCanvas.java ! test/java/awt/JAWT/myfile.c ! test/java/awt/JAWT/myfile.cpp ! test/java/awt/TextArea/DisposeTest/TestDispose.java ! test/java/awt/TextArea/TextAreaCaretVisibilityTest/bug7129742.java ! test/java/awt/TextField/DisposeTest/TestDispose.java ! test/java/lang/Integer/Unsigned.java ! test/java/lang/Long/Unsigned.java ! test/java/lang/Math/CubeRootTests.java ! test/java/lang/Math/Expm1Tests.java ! test/java/lang/Math/HyperbolicTests.java ! test/java/lang/Math/Log10Tests.java ! test/java/lang/Math/Log1pTests.java ! test/java/lang/Math/Tests.java ! test/java/lang/StringBuffer/TestSynchronization.java ! test/java/lang/invoke/remote/RemoteExample.java ! test/java/math/BigDecimal/FloatDoubleValueTests.java ! test/java/math/BigDecimal/StrippingZerosTest.java ! test/java/net/Inet4Address/PingThis.java ! test/java/net/ProxySelector/MultiThreadedSystemProxies.java ! test/java/security/Signature/VerifyRangeCheckOverflow.java ! test/java/util/AbstractCollection/ToArrayTest.java ! test/java/util/Map/EntryHashCode.java ! test/java/util/concurrent/FutureTask/DoneTimedGetLoops.java ! test/java/util/logging/LoggerResourceBundleRace.java ! test/java/util/logging/LoggingDeadlock2.java ! test/java/util/logging/LoggingDeadlock3.java ! test/java/util/logging/SimpleFormatterFormat.java ! test/java/util/spi/ResourceBundleControlProvider/providersrc/XmlRB.xml ! test/java/util/spi/ResourceBundleControlProvider/providersrc/XmlRB_ja.xml ! test/javax/swing/JComponent/7154030/bug7154030.java ! test/javax/swing/JTabbedPane/4310381/bug4310381.java ! test/javax/swing/JTable/4235420/bug4235420.java ! test/javax/swing/JTable/6788484/bug6788484.java ! test/javax/swing/JTable/7055065/bug7055065.java ! test/javax/swing/JTable/7188612/JTableAccessibleGetLocationOnScreen.java ! test/javax/swing/JTextArea/7049024/bug7049024.java ! test/javax/swing/border/Test7022041.java ! test/javax/swing/text/DefaultCaret/6938583/bug6938583.java ! test/sun/management/AgentCMETest.java ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh ! test/sun/nio/ch/SelProvider.java ! test/sun/rmi/rmic/classpath/RMICClassPathTest.java ! test/sun/security/krb5/auto/ReplayCache.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java ! test/sun/tools/jps/jps-V_2.sh ! test/tools/jar/JarBackSlash.java ! test/tools/launcher/UnicodeTest.java Changeset: 9dc1990c7d90 Author: yhuang Date: 2012-12-20 18:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/9dc1990c7d90 7195759: ISO 4217 Amendment 154 Reviewed-by: naoto ! src/share/classes/java/util/CurrencyData.properties ! src/share/classes/java/util/LocaleISOData.java ! src/share/classes/sun/util/resources/CurrencyNames.properties ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Currency/tablea1.txt ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: cbf255324369 Author: yhuang Date: 2012-12-23 19:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/cbf255324369 Merge - src/share/lib/security/java.security - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: a996b57e5541 Author: katleman Date: 2012-12-26 14:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/a996b57e5541 Merge Changeset: 8d7651351cfe Author: katleman Date: 2012-12-27 12:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/8d7651351cfe Added tag jdk8-b70 for changeset a996b57e5541 ! .hgtags From john.coomes at oracle.com Thu Dec 27 21:24:31 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Dec 2012 05:24:31 +0000 Subject: hg: hsx/hotspot-emb/langtools: 10 new changesets Message-ID: <20121228052500.349E547405@hg.openjdk.java.net> Changeset: c78acf6c2f3e Author: mcimadamore Date: 2012-12-10 12:10 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/c78acf6c2f3e 8004094: Javac compiler error - synthetic method accessor generated with duplicate name Summary: method clash check logic should skip methods marked with ACC_SYNTHETIC Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/8004094/B.java + test/tools/javac/generics/8004094/T8004094.java Changeset: fcf89720ae71 Author: vromero Date: 2012-12-10 16:21 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/fcf89720ae71 8003967: detect and remove all mutable implicit static enum fields in langtools Reviewed-by: jjg ! src/share/classes/com/sun/tools/classfile/Opcode.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFileFactory.java ! src/share/classes/com/sun/tools/javac/Server.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/TargetType.java ! src/share/classes/com/sun/tools/javac/code/TypeTag.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/ConstFold.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/javax/lang/model/element/Modifier.java ! src/share/classes/javax/lang/model/util/ElementFilter.java ! src/share/classes/javax/tools/StandardLocation.java + test/tools/javac/T8003967/DetectMutableStaticFields.java Changeset: cfde9737131e Author: jjg Date: 2012-12-11 15:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/cfde9737131e 8004828: refactor init of *DocImpl classes Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ConstructorDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/MemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java Changeset: 170e486632d9 Author: jlahoda Date: 2012-12-12 20:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/170e486632d9 8004504: ListBuffer could reuse List.nil() as the sentinel element Summary: ListBuffer.last now points to the last elements with client data, or null if none. Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/util/ListBuffer.java + test/tools/javac/util/list/ListBufferTest.java Changeset: 376d6c1b49e5 Author: jfranck Date: 2012-12-03 11:16 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/376d6c1b49e5 8001114: Container annotation is not checked for semantic correctness Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.java ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.out ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.java ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.out ! test/tools/javac/annotations/repeatingAnnotations/NoRepeatableAnno.out + test/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.java + test/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.out ! test/tools/javac/diags/examples/ContainedByNonDefault.java + test/tools/javac/diags/examples/InvalidDuplicateAnnotation.java Changeset: d7360bf35ee1 Author: lana Date: 2012-12-14 13:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/d7360bf35ee1 Merge Changeset: 2001991b1b40 Author: katleman Date: 2012-12-20 09:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/2001991b1b40 Added tag jdk8-b69 for changeset d7360bf35ee1 ! .hgtags Changeset: 7d34e91f66bb Author: katleman Date: 2012-12-20 16:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/7d34e91f66bb 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! make/Makefile-classic ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor8.java ! test/tools/javac/StringsInSwitch/StringSwitches.java ! test/tools/javac/api/T6395981.java ! test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java ! test/tools/javac/diags/examples/DuplicateAnnotation.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestKinds.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase1.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase2.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase4.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/AttributeInjector.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassFile.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassFilePreprocessor.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassToInterfaceConverter.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/Compiler.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/DirectedClassLoader.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/SourceModel.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/TestHarness.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/FDSeparateCompilationTest.java ! test/tools/javac/nativeHeaders/javahComparison/CompareTest.java ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java Changeset: 47f71d7c124f Author: katleman Date: 2012-12-26 14:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/47f71d7c124f Merge Changeset: 7d5032c2d747 Author: katleman Date: 2012-12-27 12:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/7d5032c2d747 Added tag jdk8-b70 for changeset 47f71d7c124f ! .hgtags From john.coomes at oracle.com Thu Dec 27 21:48:26 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Dec 2012 05:48:26 +0000 Subject: hg: hsx/hotspot-rt: 10 new changesets Message-ID: <20121228054827.1336F4740F@hg.openjdk.java.net> Changeset: fb1bf5e5bc9e Author: henryjen Date: 2012-12-06 15:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/fb1bf5e5bc9e 8004685: add java.util.function to CORE_PKGS.gmk Reviewed-by: mduigou ! common/makefiles/javadoc/CORE_PKGS.gmk Changeset: e08b0096058f Author: lana Date: 2012-12-14 11:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/e08b0096058f Merge Changeset: 8e36a0fabf58 Author: ohrstrom Date: 2012-12-18 09:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/8e36a0fabf58 8004145: New improved hgforest.sh, ctrl-c now properly terminates mercurial processes. Reviewed-by: ohair, erikj + common/bin/hgforest.sh ! get_source.sh Changeset: 51d3b65b8093 Author: erikj Date: 2012-12-18 17:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/51d3b65b8093 8001901: build-infra: Fix "misbehaving" which command on Solaris Summary: Removed all uses of which in configure on solaris. Reviewed-by: ohair ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: 6ee8080a6efe Author: katleman Date: 2012-12-19 13:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/6ee8080a6efe Merge Changeset: 32148e971ac8 Author: katleman Date: 2012-12-20 09:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/32148e971ac8 Added tag jdk8-b69 for changeset 6ee8080a6efe ! .hgtags Changeset: 6b93e7a4401d Author: dholmes Date: 2012-12-20 01:44 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/6b93e7a4401d 7190137: Add support for JVM_VARIANT minimal1 Summary: Allow configuration of minimal1 as a target VM along with client and server Reviewed-by: ohair, erikj ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: cd06b2ea58dd Author: katleman Date: 2012-12-20 16:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/cd06b2ea58dd 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! common/makefiles/RMICompilation.gmk Changeset: 105a25ffa4a4 Author: katleman Date: 2012-12-26 14:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/105a25ffa4a4 Merge Changeset: 3fb32a5a2388 Author: katleman Date: 2012-12-27 12:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/3fb32a5a2388 Added tag jdk8-b70 for changeset 105a25ffa4a4 ! .hgtags From john.coomes at oracle.com Thu Dec 27 21:48:31 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Dec 2012 05:48:31 +0000 Subject: hg: hsx/hotspot-rt/corba: 2 new changesets Message-ID: <20121228054834.6277147410@hg.openjdk.java.net> Changeset: 603cceb495c8 Author: katleman Date: 2012-12-20 09:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/603cceb495c8 Added tag jdk8-b69 for changeset 22ddcac208a8 ! .hgtags Changeset: 8171d23e914d Author: katleman Date: 2012-12-27 12:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/8171d23e914d Added tag jdk8-b70 for changeset 603cceb495c8 ! .hgtags From john.coomes at oracle.com Thu Dec 27 21:48:39 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Dec 2012 05:48:39 +0000 Subject: hg: hsx/hotspot-rt/jaxp: 4 new changesets Message-ID: <20121228054855.A9BB447411@hg.openjdk.java.net> Changeset: 27421008f050 Author: katleman Date: 2012-12-20 09:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/27421008f050 Added tag jdk8-b69 for changeset 789a855de959 ! .hgtags Changeset: a72c8391cdd6 Author: katleman Date: 2012-12-20 16:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/a72c8391cdd6 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! src/com/sun/org/apache/xalan/internal/XalanConstants.java ! src/com/sun/org/apache/xalan/internal/utils/FactoryImpl.java Changeset: 6ec9edffc286 Author: katleman Date: 2012-12-26 14:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/6ec9edffc286 Merge Changeset: 63815efd132f Author: katleman Date: 2012-12-27 12:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/63815efd132f Added tag jdk8-b70 for changeset 6ec9edffc286 ! .hgtags From john.coomes at oracle.com Thu Dec 27 21:49:01 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Dec 2012 05:49:01 +0000 Subject: hg: hsx/hotspot-rt/jaxws: 2 new changesets Message-ID: <20121228054907.B88EA47412@hg.openjdk.java.net> Changeset: 3b1c2733d47e Author: katleman Date: 2012-12-20 09:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/3b1c2733d47e Added tag jdk8-b69 for changeset 756323c99011 ! .hgtags Changeset: f577a39c9fb3 Author: katleman Date: 2012-12-27 12:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/f577a39c9fb3 Added tag jdk8-b70 for changeset 3b1c2733d47e ! .hgtags From john.coomes at oracle.com Thu Dec 27 21:50:21 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Dec 2012 05:50:21 +0000 Subject: hg: hsx/hotspot-rt/jdk: 52 new changesets Message-ID: <20121228060146.7B1D847413@hg.openjdk.java.net> Changeset: e8b54ae97344 Author: jviswana Date: 2012-12-12 13:28 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e8b54ae97344 8004316: Printer - tempfile having incorrect extension Reviewed-by: bae, jgodinez ! src/solaris/classes/sun/print/UnixPrintJob.java Changeset: fd9e6b4c8488 Author: lana Date: 2012-12-14 11:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/fd9e6b4c8488 Merge Changeset: c69424f78060 Author: serb Date: 2012-12-11 19:45 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c69424f78060 7154778: [macosx] NSView-based implementation of sun.awt.EmbeddedFrame Summary: The new implementation of EmbeddedFrame to support SWT_AWT Bridge Reviewed-by: anthony, serb, leonidr Contributed-by: Petr Pchelko ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/PlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPrinterDialogPeer.java + src/macosx/classes/sun/lwawt/macosx/CViewEmbeddedFrame.java + src/macosx/classes/sun/lwawt/macosx/CViewPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CWrapper.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/AWTSurfaceLayers.m ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.m ! src/macosx/native/sun/awt/CCursorManager.m ! src/macosx/native/sun/awt/CWrapper.m ! src/macosx/native/sun/awt/awt.m ! src/macosx/native/sun/java2d/opengl/CGLLayer.m ! src/macosx/native/sun/osxapp/ThreadUtilities.h ! src/macosx/native/sun/osxapp/ThreadUtilities.m Changeset: e016ad35a764 Author: kshefov Date: 2012-12-13 15:14 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e016ad35a764 7132385: [macosx] IconifyTest of RepaintManager could use some delay Reviewed-by: serb, alexsch + test/javax/swing/RepaintManager/IconifyTest/IconifyTest.java Changeset: 71e03e17c183 Author: kshefov Date: 2012-12-14 13:32 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/71e03e17c183 6757986: javax/swing/JInternalFrame/5066752/bug5066752.java needs correction Reviewed-by: serb, alexsch + test/javax/swing/JInternalFrame/5066752/bug5066752.java Changeset: 9fc7460ca3ac Author: lana Date: 2012-12-14 11:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9fc7460ca3ac Merge Changeset: 7004848974a2 Author: jgish Date: 2012-12-04 20:21 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7004848974a2 8003596: TEST_BUG: java/util/logging/CheckLockLocationTest.java failing [win] Reviewed-by: alanb ! test/ProblemList.txt ! test/java/util/logging/CheckLockLocationTest.java Changeset: 44ae777564eb Author: mullan Date: 2012-12-04 17:40 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/44ae777564eb 8004188: Rename src/share/lib/security/java.security to java.security-linux Reviewed-by: mullan, mchung Contributed-by: jason.uh at oracle.com ! make/java/security/Makefile - src/share/lib/security/java.security + src/share/lib/security/java.security-linux Changeset: b54a5b7d2e65 Author: alanb Date: 2012-12-05 12:20 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b54a5b7d2e65 8004491: Build breakage on Linux due to 8004188 Reviewed-by: chegar, erikj ! makefiles/CopyFiles.gmk Changeset: a971516029ab Author: jgish Date: 2012-12-05 21:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a971516029ab 8004317: TestLibrary.getUnusedRandomPort() fails intermittently, but exception not reported Reviewed-by: alanb, dmocek, smarks ! test/java/rmi/testlibrary/TestLibrary.java Changeset: 41a1b110f34d Author: lancea Date: 2012-12-06 15:51 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/41a1b110f34d 8004374: CachedRowSetSwriter.writeData reports wrong number of conflicts in SyncProviderException Reviewed-by: naoto ! src/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java Changeset: 896d4af2ebfd Author: rfield Date: 2012-12-06 21:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/896d4af2ebfd 8003881: Prevent lambda implementing inner classes from allowing the creation of new instances Summary: Lambda implementing inner classes now has private constructor (thanks Kumar) Reviewed-by: ksrini ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java + test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java + test/java/lang/invoke/lambda/LambdaAccessControlTest.java Changeset: da387f0cecb7 Author: ksrini Date: 2012-12-09 07:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/da387f0cecb7 8004042: Arrrghs.java test failed on windows with access error. Reviewed-by: smarks, jjh, ksrini Contributed-by: david.dehaven at oracle.com ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java Changeset: 343615aa0539 Author: dxu Date: 2012-12-09 19:13 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/343615aa0539 7194370: (fs) WatchService fails if volume S/N is 0 [win] Reviewed-by: alanb, forax ! src/windows/classes/sun/nio/fs/WindowsFileAttributes.java Changeset: fda257689786 Author: okutsu Date: 2012-12-10 10:52 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/fda257689786 8000983: Support narrow display names for calendar fields 8003267: Support generic time zone names in TimeZoneNameProvider (SPI) Reviewed-by: naoto ! make/tools/src/build/tools/cldrconverter/Bundle.java ! make/tools/src/build/tools/cldrconverter/BundleGenerator.java ! make/tools/src/build/tools/cldrconverter/CLDRConverter.java ! make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java ! make/tools/src/build/tools/cldrconverter/MetaZonesParseHandler.java ! make/tools/src/build/tools/cldrconverter/ResourceBundleGenerator.java ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/JapaneseImperialCalendar.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/java/util/spi/CalendarNameProvider.java ! src/share/classes/java/util/spi/TimeZoneNameProvider.java ! src/share/classes/sun/text/resources/FormatData.java ! src/share/classes/sun/text/resources/ar/FormatData_ar.java ! src/share/classes/sun/text/resources/be/FormatData_be.java ! src/share/classes/sun/text/resources/bg/FormatData_bg.java ! src/share/classes/sun/text/resources/ca/FormatData_ca.java ! src/share/classes/sun/text/resources/cs/FormatData_cs.java ! src/share/classes/sun/text/resources/da/FormatData_da.java ! src/share/classes/sun/text/resources/de/FormatData_de.java ! src/share/classes/sun/text/resources/el/FormatData_el.java ! src/share/classes/sun/text/resources/es/FormatData_es.java ! src/share/classes/sun/text/resources/et/FormatData_et.java ! src/share/classes/sun/text/resources/fi/FormatData_fi.java ! src/share/classes/sun/text/resources/fr/FormatData_fr.java ! src/share/classes/sun/text/resources/hi/FormatData_hi_IN.java ! src/share/classes/sun/text/resources/hr/FormatData_hr.java ! src/share/classes/sun/text/resources/hu/FormatData_hu.java ! src/share/classes/sun/text/resources/is/FormatData_is.java ! src/share/classes/sun/text/resources/it/FormatData_it.java ! src/share/classes/sun/text/resources/iw/FormatData_iw.java ! src/share/classes/sun/text/resources/ja/FormatData_ja.java ! src/share/classes/sun/text/resources/ko/FormatData_ko.java ! src/share/classes/sun/text/resources/lt/FormatData_lt.java ! src/share/classes/sun/text/resources/lv/FormatData_lv.java ! src/share/classes/sun/text/resources/mk/FormatData_mk.java ! src/share/classes/sun/text/resources/ms/FormatData_ms.java ! src/share/classes/sun/text/resources/mt/FormatData_mt.java ! src/share/classes/sun/text/resources/nl/FormatData_nl.java ! src/share/classes/sun/text/resources/pl/FormatData_pl.java ! src/share/classes/sun/text/resources/pt/FormatData_pt.java ! src/share/classes/sun/text/resources/ro/FormatData_ro.java ! src/share/classes/sun/text/resources/ru/FormatData_ru.java ! src/share/classes/sun/text/resources/sk/FormatData_sk.java ! src/share/classes/sun/text/resources/sl/FormatData_sl.java ! src/share/classes/sun/text/resources/sq/FormatData_sq.java ! src/share/classes/sun/text/resources/sr/FormatData_sr.java ! src/share/classes/sun/text/resources/sv/FormatData_sv.java ! src/share/classes/sun/text/resources/th/FormatData_th.java ! src/share/classes/sun/text/resources/tr/FormatData_tr.java ! src/share/classes/sun/text/resources/uk/FormatData_uk.java ! src/share/classes/sun/text/resources/vi/FormatData_vi.java ! src/share/classes/sun/text/resources/zh/FormatData_zh.java ! src/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/CalendarDataUtility.java ! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleResources.java ! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java ! src/share/classes/sun/util/resources/LocaleData.java ! src/share/classes/sun/util/resources/OpenListResourceBundle.java ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNamesBundle.java + test/java/util/Calendar/GenericTimeZoneNamesTest.java + test/java/util/Calendar/GenericTimeZoneNamesTest.sh + test/java/util/Calendar/NarrowNamesTest.java + test/java/util/Calendar/NarrowNamesTest.sh ! test/java/util/PluggableLocale/GenericTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.sh ! test/java/util/PluggableLocale/barprovider.jar + test/java/util/PluggableLocale/providersrc/GenericTimeZoneNameProviderImpl.java ! test/java/util/PluggableLocale/providersrc/Makefile ! test/java/util/PluggableLocale/providersrc/java.util.spi.TimeZoneNameProvider ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: fda2b2b5b98b Author: michaelm Date: 2012-12-10 14:56 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/fda2b2b5b98b 8003948: NTLM/Negotiate authentication problem Reviewed-by: chegar, weijun ! src/share/classes/sun/net/www/MessageHeader.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/MessageHeaderTest.java Changeset: cac1bfaceaaa Author: mchung Date: 2012-12-10 15:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cac1bfaceaaa 4819681: Typo in http://java.sun.com/j2se/1.4.1/docs/api/java/util/logging/LogManager.html Summary: Simple capitalization typo in LogManager() description Reviewed-by: darcy, mchung ! src/share/classes/java/util/logging/LogManager.java Changeset: 883feced1cdd Author: dingxmin Date: 2012-12-11 10:42 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/883feced1cdd 6512101: Incorrect encoding in NetworkInterface.getDisplayName() Reviewed-by: chegar, dsamersoff ! src/windows/native/java/net/NetworkInterface.c Changeset: d206e52bf8a6 Author: weijun Date: 2012-12-11 13:14 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d206e52bf8a6 8004488: wrong permissions checked in krb5 Reviewed-by: xuelei ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java + test/sun/security/krb5/auto/KeyPermissions.java ! test/sun/security/krb5/auto/KeyTabCompat.java Changeset: c4bd81de2868 Author: akhil Date: 2012-12-11 15:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c4bd81de2868 8003246: Add InitialValue Supplier to ThreadLocal Reviewed-by: mduigou, forax, dl, chegar, briangoetz ! src/share/classes/java/lang/ThreadLocal.java + test/java/lang/ThreadLocal/ThreadLocalSupplierTest.java Changeset: 6c795437f212 Author: mduigou Date: 2012-12-11 20:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6c795437f212 8004905: Correct license of test to remove classpath exception Reviewed-by: akhil ! test/java/lang/ThreadLocal/ThreadLocalSupplierTest.java Changeset: 12fba0974a9d Author: weijun Date: 2012-12-12 18:39 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/12fba0974a9d 8004904: Makefile for ntlm Reviewed-by: erikj, chegar ! make/com/sun/security/Makefile + make/com/sun/security/ntlm/Makefile Changeset: 806cf26e5063 Author: chegar Date: 2012-12-12 11:35 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/806cf26e5063 8004921: Trivial javadoc warnings in Base64 Reviewed-by: darcy ! src/share/classes/java/util/Base64.java Changeset: 81640e75c7a7 Author: alanb Date: 2012-12-12 13:03 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/81640e75c7a7 8004874: Reduce dependency on java.beans to only add/removePropertyChangeListener Reviewed-by: ksrini, mchung, dholmes ! src/share/classes/com/sun/java/util/jar/pack/PropMap.java ! src/share/classes/java/util/logging/LogManager.java Changeset: 346c0af4af41 Author: mullan Date: 2012-12-12 09:25 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/346c0af4af41 8004064: Downgrade normative references to ${java.home}/lib/security/java.security Reviewed-by: alanb, vinnie, xuelei ! src/share/classes/com/sun/net/ssl/KeyManagerFactory.java ! src/share/classes/com/sun/net/ssl/TrustManagerFactory.java ! src/share/classes/com/sun/security/auth/PolicyFile.java ! src/share/classes/com/sun/security/auth/login/ConfigFile.java ! src/share/classes/java/net/doc-files/net-properties.html ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/Policy.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/cert/CertPathBuilder.java ! src/share/classes/java/security/cert/CertPathValidator.java ! src/share/classes/java/security/cert/CertStore.java ! src/share/classes/javax/net/ssl/KeyManagerFactory.java ! src/share/classes/javax/net/ssl/TrustManagerFactory.java ! src/share/classes/javax/security/auth/Policy.java ! src/share/classes/javax/security/auth/callback/CallbackHandler.java ! src/share/classes/javax/security/auth/login/Configuration.java ! src/share/classes/javax/security/auth/login/LoginContext.java ! src/share/classes/javax/security/cert/X509Certificate.java Changeset: c7f86908d5fd Author: mullan Date: 2012-12-12 09:27 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c7f86908d5fd Merge - src/share/lib/security/java.security Changeset: 68374c6e65c1 Author: robm Date: 2012-12-12 15:57 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/68374c6e65c1 8004337: java/sql tests aren't run in test/Makefile Reviewed-by: lancea, alanb ! test/Makefile Changeset: bd84d0927a2e Author: smarks Date: 2012-12-12 09:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bd84d0927a2e 8004748: clean up @build tags in RMI tests Reviewed-by: alanb, darcy, mchung ! test/java/rmi/MarshalledObject/compare/Compare.java ! test/java/rmi/MarshalledObject/compare/HashCode.java ! test/java/rmi/MarshalledObject/compare/NullReference.java ! test/java/rmi/Naming/DefaultRegistryPort.java ! test/java/rmi/Naming/LookupIPv6.java ! test/java/rmi/Naming/RmiIsNoScheme.java ! test/java/rmi/Naming/UnderscoreHost.java ! test/java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java ! test/java/rmi/RMISecurityManager/checkPackageAccess/CheckPackageAccess.java ! test/java/rmi/activation/Activatable/checkActivateRef/CheckActivateRef.java ! test/java/rmi/activation/Activatable/checkAnnotations/CheckAnnotations.java ! test/java/rmi/activation/Activatable/checkImplClassLoader/CheckImplClassLoader.java ! test/java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java ! test/java/rmi/activation/Activatable/createPrivateActivable/CreatePrivateActivatable.java ! test/java/rmi/activation/Activatable/downloadParameterClass/DownloadParameterClass.java ! test/java/rmi/activation/Activatable/elucidateNoSuchMethod/ElucidateNoSuchMethod.java ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/activation/Activatable/forceLogSnapshot/ForceLogSnapshot.java ! test/java/rmi/activation/Activatable/inactiveGroup/InactiveGroup.java ! test/java/rmi/activation/Activatable/lookupActivationSystem/LookupActivationSystem.java ! test/java/rmi/activation/Activatable/nestedActivate/NestedActivate.java ! test/java/rmi/activation/Activatable/nonExistentActivatable/NonExistentActivatable.java ! test/java/rmi/activation/Activatable/restartCrashedService/RestartCrashedService.java ! test/java/rmi/activation/Activatable/restartLatecomer/RestartLatecomer.java ! test/java/rmi/activation/Activatable/restartService/RestartService.java ! test/java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java ! test/java/rmi/activation/Activatable/unregisterInactive/UnregisterInactive.java ! test/java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java ! test/java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java ! test/java/rmi/activation/ActivationGroupDesc/checkDefaultGroupName/CheckDefaultGroupName.java ! test/java/rmi/activation/ActivationSystem/activeGroup/IdempotentActiveGroup.java ! test/java/rmi/activation/ActivationSystem/modifyDescriptor/ModifyDescriptor.java ! test/java/rmi/activation/ActivationSystem/stubClassesPermitted/StubClassesPermitted.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java ! test/java/rmi/activation/CommandEnvironment/NullOptions.java ! test/java/rmi/activation/CommandEnvironment/SetChildEnv.java ! test/java/rmi/activation/checkusage/CheckUsage.java ! test/java/rmi/activation/log/LogTest.java ! test/java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java ! test/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java ! test/java/rmi/dgc/VMID/CheckVMID.java ! test/java/rmi/dgc/dgcAckFailure/DGCAckFailure.java ! test/java/rmi/dgc/dgcImplInsulation/DGCImplInsulation.java ! test/java/rmi/dgc/retryDirtyCalls/RetryDirtyCalls.java ! test/java/rmi/invalidName/InvalidName.java ! test/java/rmi/registry/altSecurityManager/AltSecurityManager.java ! test/java/rmi/registry/checkusage/CheckUsage.java ! test/java/rmi/registry/classPathCodebase/ClassPathCodebase.java ! test/java/rmi/registry/interfaceHash/InterfaceHash.java ! test/java/rmi/registry/multipleRegistries/MultipleRegistries.java ! test/java/rmi/registry/readTest/readTest.sh ! test/java/rmi/registry/reexport/Reexport.java ! test/java/rmi/reliability/benchmark/runRmiBench.sh ! test/java/rmi/reliability/benchmark/runSerialBench.sh ! test/java/rmi/reliability/juicer/AppleUserImpl.java ! test/java/rmi/server/ObjID/randomIDs/RandomIDs.java ! test/java/rmi/server/RMIClassLoader/delegateBeforePermissionCheck/DelegateBeforePermissionCheck.java ! test/java/rmi/server/RMIClassLoader/delegateToContextLoader/DelegateToContextLoader.java ! test/java/rmi/server/RMIClassLoader/downloadArrayClass/DownloadArrayClass.java ! test/java/rmi/server/RMIClassLoader/getClassAnnotation/NullClass.java ! test/java/rmi/server/RMIClassLoader/getClassLoader/GetClassLoader.java ! test/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java ! test/java/rmi/server/RMIClassLoader/noSecurityManager/NoSecurityManager.java ! test/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java ! test/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java ! test/java/rmi/server/RMIClassLoader/spi/Installed.java ! test/java/rmi/server/RMIClassLoader/spi/InvalidProperty.java ! test/java/rmi/server/RMIClassLoader/spi/Property.java ! test/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java ! test/java/rmi/server/RMIClassLoader/useGetURLs/UseGetURLs.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/UseCustomSocketFactory.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/registry/UseCustomSocketFactory.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/unicast/UseCustomSocketFactory.java ! test/java/rmi/server/RemoteObject/notExtending/NotExtending.java ! test/java/rmi/server/RemoteObject/verifyRemoteEquals/VerifyRemoteEquals.java ! test/java/rmi/server/RemoteServer/AddrInUse.java ! test/java/rmi/server/UnicastRemoteObject/changeHostName/ChangeHostName.java ! test/java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java ! test/java/rmi/server/UnicastRemoteObject/keepAliveDuringCall/KeepAliveDuringCall.java ! test/java/rmi/server/UnicastRemoteObject/marshalAfterUnexport/MarshalAfterUnexport.java ! test/java/rmi/server/UnicastRemoteObject/marshalAfterUnexport/MarshalAfterUnexport2.java ! test/java/rmi/server/UnicastRemoteObject/unexportObject/UnexportLeak.java ! test/java/rmi/server/Unmarshal/PrimitiveClasses.java + test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshal.java ! test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshalOnStopThread.java - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java ! test/java/rmi/server/Unreferenced/finiteGCLatency/FiniteGCLatency.java ! test/java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java ! test/java/rmi/server/Unreferenced/marshalledObjectGet/MarshalledObjectGet.java ! test/java/rmi/server/Unreferenced/unreferencedContext/UnreferencedContext.java ! test/java/rmi/server/clientStackTrace/ClientStackTrace.java ! test/java/rmi/server/getRemoteClass/GetRemoteClass.java ! test/java/rmi/server/serverStackTrace/ServerStackTrace.java ! test/java/rmi/server/serverStackTrace/SuppressStackTraces.java ! test/java/rmi/server/useCustomRef/UseCustomRef.java ! test/java/rmi/transport/acceptLoop/CloseServerSocketOnTermination.java ! test/java/rmi/transport/checkFQDN/CheckFQDN.java ! test/java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java ! test/java/rmi/transport/closeServerSocket/CloseServerSocket.java ! test/java/rmi/transport/dgcDeadLock/DGCDeadLock.java ! test/java/rmi/transport/handshakeFailure/HandshakeFailure.java ! test/java/rmi/transport/handshakeTimeout/HandshakeTimeout.java ! test/java/rmi/transport/httpSocket/HttpSocketTest.java ! test/java/rmi/transport/rapidExportUnexport/RapidExportUnexport.java ! test/java/rmi/transport/readTimeout/ReadTimeoutTest.java ! test/java/rmi/transport/reuseDefaultPort/ReuseDefaultPort.java ! test/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java ! test/javax/rmi/ssl/SocketFactoryTest.java ! test/sun/rmi/log/ReliableLog/LogAlignmentTest.java ! test/sun/rmi/log/ReliableLog/SnapshotSize.java ! test/sun/rmi/rmic/RMIGenerator/RmicDefault.java ! test/sun/rmi/rmic/newrmic/equivalence/run.sh ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java ! test/sun/rmi/runtime/Log/checkLogging/CheckLogStreams.java ! test/sun/rmi/runtime/Log/checkLogging/CheckLogging.java ! test/sun/rmi/server/MarshalOutputStream/marshalForeignStub/MarshalForeignStub.java ! test/sun/rmi/transport/proxy/EagerHttpFallback.java ! test/sun/rmi/transport/tcp/DeadCachedConnection.java ! test/sun/rmi/transport/tcp/blockAccept/BlockAcceptTest.java ! test/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java Changeset: 56fd5479a98f Author: jgish Date: 2012-12-12 15:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/56fd5479a98f 8004651: TEST: java/util/logging/CheckLockLocationTest.java failed to delete file (win) Summary: Failure to delete test log file should be a warning instead of test failure Reviewed-by: mduigou, smarks ! test/java/util/logging/CheckLockLocationTest.java Changeset: 5a2ab2c3f106 Author: weijun Date: 2012-12-13 08:11 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5a2ab2c3f106 8004235: Disable native JGSS provider on Mac Reviewed-by: erikj, valeriep ! make/sun/security/Makefile ! makefiles/CompileNativeLibraries.gmk ! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java Changeset: 7a8978a5bb6e Author: lancea Date: 2012-12-12 20:57 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7a8978a5bb6e 8004357: Implement various methods in SerialBlob/Clob/Array and specify Thread Safety Reviewed-by: naoto ! src/share/classes/javax/sql/rowset/serial/SerialArray.java ! src/share/classes/javax/sql/rowset/serial/SerialBlob.java ! src/share/classes/javax/sql/rowset/serial/SerialClob.java ! src/share/classes/javax/sql/rowset/serial/SerialDatalink.java ! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java ! src/share/classes/javax/sql/rowset/serial/SerialRef.java ! src/share/classes/javax/sql/rowset/serial/SerialStruct.java Changeset: 775b0050144a Author: chegar Date: 2012-12-13 09:55 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/775b0050144a 8004925: java/net/Socks/SocksV4Test.java failing on all platforms Reviewed-by: alanb, dsamersoff ! test/java/net/Socks/SocksV4Test.java Changeset: 682d2d3ccff5 Author: chegar Date: 2012-12-13 14:33 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/682d2d3ccff5 8004675: Inet6Address.getHostAddress should use string scope identifier where available Summary: ...and some minor stylistic cleanup Reviewed-by: khazra, dsamersoff, michaelm ! src/share/classes/java/net/Inet6Address.java ! src/share/native/java/net/Inet6Address.c + test/java/net/Inet6Address/StringScope.java Changeset: c97618a3c8c2 Author: juh Date: 2012-12-13 09:35 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c97618a3c8c2 7193792: sun/security/pkcs11/ec/TestECDSA.java failing intermittently Reviewed-by: vinnie, wetmore ! test/ProblemList.txt ! test/sun/security/pkcs11/ec/TestECDSA.java Changeset: 7b697da6626a Author: mullan Date: 2012-12-13 09:37 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7b697da6626a Merge Changeset: ae5d04dbacd6 Author: chegar Date: 2012-12-13 14:47 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ae5d04dbacd6 8003890: corelibs test scripts should pass TESTVMOPTS Reviewed-by: chegar, alanb Contributed-by: Mark Sheppard ! test/com/oracle/net/sanity.sh ! test/com/sun/corba/cachedSocket/7056731.sh ! test/com/sun/management/OperatingSystemMXBean/TestTotalSwap.sh ! test/com/sun/management/UnixOperatingSystemMXBean/GetMaxFileDescriptorCount.sh ! test/com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh ! test/com/sun/tools/attach/ApplicationSetup.sh ! test/com/sun/tools/attach/BasicTests.sh ! test/com/sun/tools/attach/PermissionTests.sh ! test/com/sun/tools/attach/ProviderTests.sh ! test/com/sun/tools/extcheck/TestExtcheckArgs.sh ! test/demo/zipfs/basic.sh ! test/java/io/File/GetXSpace.sh ! test/java/io/File/MacPathTest.sh ! test/java/io/File/basic.sh ! test/java/io/FileOutputStream/FileOpen.sh ! test/java/io/Serializable/class/run.sh ! test/java/io/Serializable/evolution/AddedExternField/run.sh ! test/java/io/Serializable/evolution/RenamePackage/run.sh ! test/java/io/Serializable/maskSyntheticModifier/run.sh ! test/java/io/Serializable/packageAccess/run.sh ! test/java/io/Serializable/resolveClass/consTest/run.sh ! test/java/io/Serializable/resolveClass/deserializeButton/run.sh ! test/java/io/Serializable/subclass/run.sh ! test/java/io/Serializable/superclassDataLoss/run.sh ! test/java/io/Serializable/unnamedPackageSwitch/run.sh ! test/java/lang/Class/forName/NonJavaNames.sh ! test/java/lang/ClassLoader/Assert.sh ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh ! test/java/lang/ClassLoader/getdotresource.sh ! test/java/lang/Runtime/exec/setcwd.sh ! test/java/lang/StringCoding/CheckEncodings.sh ! test/java/lang/System/finalization/FinExit.sh ! test/java/lang/annotation/loaderLeak/LoaderLeak.sh ! test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh ! test/java/net/Authenticator/B4933582.sh ! test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh ! test/java/net/InetAddress/ptr/lookup.sh ! test/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.sh ! test/java/net/Socket/OldSocketImpl.sh ! test/java/net/URL/B5086147.sh ! test/java/net/URL/runconstructor.sh ! test/java/net/URLClassLoader/B5077773.sh ! test/java/net/URLClassLoader/getresourceasstream/test.sh ! test/java/net/URLClassLoader/sealing/checksealed.sh ! test/java/net/URLConnection/6212146/test.sh ! test/java/net/URLConnection/UNCTest.sh ! test/java/nio/Buffer/LimitDirectMemory.sh ! test/java/nio/channels/AsynchronousChannelGroup/run_any_task.sh ! test/java/nio/channels/spi/AsynchronousChannelProvider/custom_provider.sh ! test/java/nio/charset/Charset/default.sh ! test/java/nio/charset/coders/CheckSJISMappingProp.sh ! test/java/nio/charset/spi/basic.sh ! test/java/nio/file/Files/delete_on_close.sh ! test/java/nio/file/Files/walkFileTree/walk_file_tree.sh ! test/java/nio/file/Path/MacPathTest.sh ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/registry/readTest/readTest.sh ! test/java/rmi/reliability/benchmark/runSerialBench.sh ! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh ! test/java/security/Security/signedfirst/Dyn.sh ! test/java/security/Security/signedfirst/Static.sh ! test/java/security/cert/CertificateFactory/slowstream.sh ! test/java/util/Currency/PropertiesTest.sh ! test/java/util/Locale/LocaleCategory.sh ! test/java/util/Locale/LocaleProviders.sh ! test/java/util/PluggableLocale/ExecTest.sh ! test/java/util/ResourceBundle/Bug6299235Test.sh ! test/java/util/ResourceBundle/Control/MissingResourceCauseTest.sh ! test/java/util/ServiceLoader/basic.sh ! test/java/util/TimeZone/OldIDMappingTest.sh ! test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh ! test/java/util/prefs/CheckUserPrefsStorage.sh ! test/java/util/prefs/PrefsSpi.sh ! test/java/util/spi/ResourceBundleControlProvider/UserDefaultControlTest.sh ! test/java/util/zip/3GBZipFiles.sh ! test/java/util/zip/ZipFile/deletetempjar.sh ! test/javax/crypto/SecretKeyFactory/FailOverTest.sh ! test/javax/print/applet/AppletPrintLookup.sh ! test/javax/script/ProviderTest.sh ! test/javax/security/auth/Subject/doAs/Test.sh ! test/lib/security/java.policy/Ext_AllPolicy.sh ! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.sh ! test/sun/management/jmxremote/bootstrap/LocalManagementTest.sh ! test/sun/management/jmxremote/bootstrap/PasswordFilePermissionTest.sh ! test/sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.sh ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh ! test/sun/misc/Cleaner/exitOnThrow.sh ! test/sun/net/InetAddress/nameservice/dns/cname.sh ! test/sun/net/sdp/sanity.sh ! test/sun/net/www/MarkResetTest.sh ! test/sun/net/www/http/HttpClient/RetryPost.sh ! test/sun/net/www/protocol/file/DirPermissionDenied.sh ! test/sun/net/www/protocol/jar/B5105410.sh ! test/sun/net/www/protocol/jar/getcontenttype.sh ! test/sun/net/www/protocol/jar/jarbug/run.sh ! test/sun/rmi/rmic/manifestClassPath/run.sh ! test/sun/rmi/rmic/minimizeWrapperInstances/run.sh ! test/sun/rmi/rmic/oldjavacRemoved/sunToolsJavacMain.sh ! test/sun/security/krb5/runNameEquals.sh ! test/sun/security/krb5/tools/ktcheck.sh ! test/sun/security/mscapi/AccessKeyStore.sh ! test/sun/security/mscapi/IsSunMSCAPIAvailable.sh ! test/sun/security/mscapi/KeyStoreCompatibilityMode.sh ! test/sun/security/mscapi/PublicKeyInterop.sh ! test/sun/security/mscapi/RSAEncryptDecrypt.sh ! test/sun/security/mscapi/ShortRSAKey1024.sh ! test/sun/security/mscapi/SignUsingNONEwithRSA.sh ! test/sun/security/mscapi/SignUsingSHA2withRSA.sh ! test/sun/security/pkcs11/KeyStore/Basic.sh ! test/sun/security/pkcs11/KeyStore/ClientAuth.sh ! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh ! test/sun/security/pkcs11/KeyStore/Solaris.sh ! test/sun/security/pkcs11/Provider/ConfigQuotedString.sh ! test/sun/security/pkcs11/Provider/Login.sh ! test/sun/security/provider/PolicyFile/GrantAllPermToExtWhenNoPolicy.sh ! test/sun/security/provider/PolicyFile/getinstance/getinstance.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh ! test/sun/security/tools/jarsigner/emptymanifest.sh ! test/sun/security/tools/jarsigner/ts.sh ! test/sun/security/tools/keytool/printssl.sh ! test/sun/security/tools/keytool/standard.sh ! test/sun/security/validator/certreplace.sh ! test/sun/security/validator/samedn.sh ! test/tools/launcher/6842838/Test6842838.sh ! test/tools/launcher/MultipleJRE.sh Changeset: 087425441a48 Author: robm Date: 2012-12-13 15:28 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/087425441a48 8000525: Java.net.httpcookie api does not support 2-digit year format Reviewed-by: chegar ! src/share/classes/java/net/HttpCookie.java ! test/java/net/CookieHandler/B6791927.java ! test/java/net/CookieHandler/CookieManagerTest.java + test/java/net/HttpCookie/ExpiredCookieTest.java Changeset: 8d7323a9d8ed Author: dholmes Date: 2012-12-13 21:18 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8d7323a9d8ed 8003632: HPROF class file version java.lang.RuntimeException errors Reviewed-by: mchung, lancea ! src/share/javavm/export/classfile_constants.h Changeset: de6b54a60d60 Author: lana Date: 2012-12-14 13:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/de6b54a60d60 Merge ! makefiles/CompileNativeLibraries.gmk - src/share/lib/security/java.security - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java Changeset: 4ea0ac8e02d2 Author: erikj Date: 2012-12-19 09:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4ea0ac8e02d2 8004803: build-infra: Cannot use icedtea as boot for closed build. Summary: Set bootclasspath to javac and not the running jvm Reviewed-by: ohair ! makefiles/CreateJars.gmk Changeset: a8012d8d7e9c Author: katleman Date: 2012-12-19 13:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a8012d8d7e9c Merge Changeset: 4d5db5c038b4 Author: katleman Date: 2012-12-20 09:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4d5db5c038b4 Added tag jdk8-b69 for changeset a8012d8d7e9c ! .hgtags Changeset: ad6097d547e1 Author: kvn Date: 2012-12-18 17:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ad6097d547e1 8004318: JEP-171: Support Unsafe fences intrinsics Summary: Add three memory-ordering intrinsics to the sun.misc.Unsafe class. Reviewed-by: twisti, kvn Contributed-by: Aleksey Shipilev ! src/share/classes/sun/misc/Unsafe.java Changeset: 12fa4d7ecaf5 Author: twisti Date: 2012-12-20 11:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/12fa4d7ecaf5 8005345: JSR 292: JDK performance tweaks Reviewed-by: kvn, jrose ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/sun/invoke/util/ValueConversions.java Changeset: 8cf5b18488d1 Author: dl Date: 2012-12-20 12:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8cf5b18488d1 8004330: Add missing Unsafe entry points for addAndGet() family Summary: Add Unsafe addAndGet() methods which have intrinsics in Hotspot (7023898) Reviewed-by: alanb, kvn ! src/share/classes/sun/misc/Unsafe.java Changeset: 6b41b40526c6 Author: amurillo Date: 2012-12-21 10:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6b41b40526c6 Merge Changeset: 1ad29569d6e9 Author: erikj Date: 2012-12-20 13:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1ad29569d6e9 8005178: build-infra: Dependency on libfdlibm on mac is broken Reviewed-by: tbell, ohair ! makefiles/CompileNativeLibraries.gmk Changeset: a68090f0dc1a Author: katleman Date: 2012-12-20 16:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a68090f0dc1a 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! src/macosx/native/sun/font/CCharToGlyphMapper.m ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/Block.java ! src/share/classes/java/util/function/DoubleBlock.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/IntBlock.java ! src/share/classes/java/util/function/LongBlock.java ! src/share/classes/java/util/function/Predicate.java ! src/share/classes/sun/java2d/pipe/ParallelogramPipe.java ! src/share/classes/sun/tools/jcmd/JCmd.java ! src/share/native/java/util/zip/zlib-1.2.5/gzlib.c ! src/solaris/native/common/jdk_util_md.h ! src/solaris/native/sun/tools/attach/BsdVirtualMachine.c ! src/windows/classes/java/net/DualStackPlainDatagramSocketImpl.java ! src/windows/native/common/jdk_util_md.h ! test/com/sun/java/swing/plaf/windows/WindowsRadioButtonUI/7089914/bug7089914.java ! test/java/awt/Focus/6981400/Test1.java ! test/java/awt/Focus/6981400/Test2.java ! test/java/awt/Focus/6981400/Test3.java ! test/java/awt/Frame/ResizeAfterSetFont/ResizeAfterSetFont.java ! test/java/awt/JAWT/JAWT.sh ! test/java/awt/JAWT/Makefile.cygwin ! test/java/awt/JAWT/Makefile.unix ! test/java/awt/JAWT/Makefile.win ! test/java/awt/JAWT/MyCanvas.java ! test/java/awt/JAWT/myfile.c ! test/java/awt/JAWT/myfile.cpp ! test/java/awt/TextArea/DisposeTest/TestDispose.java ! test/java/awt/TextArea/TextAreaCaretVisibilityTest/bug7129742.java ! test/java/awt/TextField/DisposeTest/TestDispose.java ! test/java/lang/Integer/Unsigned.java ! test/java/lang/Long/Unsigned.java ! test/java/lang/Math/CubeRootTests.java ! test/java/lang/Math/Expm1Tests.java ! test/java/lang/Math/HyperbolicTests.java ! test/java/lang/Math/Log10Tests.java ! test/java/lang/Math/Log1pTests.java ! test/java/lang/Math/Tests.java ! test/java/lang/StringBuffer/TestSynchronization.java ! test/java/lang/invoke/remote/RemoteExample.java ! test/java/math/BigDecimal/FloatDoubleValueTests.java ! test/java/math/BigDecimal/StrippingZerosTest.java ! test/java/net/Inet4Address/PingThis.java ! test/java/net/ProxySelector/MultiThreadedSystemProxies.java ! test/java/security/Signature/VerifyRangeCheckOverflow.java ! test/java/util/AbstractCollection/ToArrayTest.java ! test/java/util/Map/EntryHashCode.java ! test/java/util/concurrent/FutureTask/DoneTimedGetLoops.java ! test/java/util/logging/LoggerResourceBundleRace.java ! test/java/util/logging/LoggingDeadlock2.java ! test/java/util/logging/LoggingDeadlock3.java ! test/java/util/logging/SimpleFormatterFormat.java ! test/java/util/spi/ResourceBundleControlProvider/providersrc/XmlRB.xml ! test/java/util/spi/ResourceBundleControlProvider/providersrc/XmlRB_ja.xml ! test/javax/swing/JComponent/7154030/bug7154030.java ! test/javax/swing/JTabbedPane/4310381/bug4310381.java ! test/javax/swing/JTable/4235420/bug4235420.java ! test/javax/swing/JTable/6788484/bug6788484.java ! test/javax/swing/JTable/7055065/bug7055065.java ! test/javax/swing/JTable/7188612/JTableAccessibleGetLocationOnScreen.java ! test/javax/swing/JTextArea/7049024/bug7049024.java ! test/javax/swing/border/Test7022041.java ! test/javax/swing/text/DefaultCaret/6938583/bug6938583.java ! test/sun/management/AgentCMETest.java ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh ! test/sun/nio/ch/SelProvider.java ! test/sun/rmi/rmic/classpath/RMICClassPathTest.java ! test/sun/security/krb5/auto/ReplayCache.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java ! test/sun/tools/jps/jps-V_2.sh ! test/tools/jar/JarBackSlash.java ! test/tools/launcher/UnicodeTest.java Changeset: 9dc1990c7d90 Author: yhuang Date: 2012-12-20 18:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9dc1990c7d90 7195759: ISO 4217 Amendment 154 Reviewed-by: naoto ! src/share/classes/java/util/CurrencyData.properties ! src/share/classes/java/util/LocaleISOData.java ! src/share/classes/sun/util/resources/CurrencyNames.properties ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Currency/tablea1.txt ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: cbf255324369 Author: yhuang Date: 2012-12-23 19:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cbf255324369 Merge - src/share/lib/security/java.security - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: a996b57e5541 Author: katleman Date: 2012-12-26 14:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a996b57e5541 Merge Changeset: 8d7651351cfe Author: katleman Date: 2012-12-27 12:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8d7651351cfe Added tag jdk8-b70 for changeset a996b57e5541 ! .hgtags From john.coomes at oracle.com Thu Dec 27 22:04:16 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 Dec 2012 06:04:16 +0000 Subject: hg: hsx/hotspot-rt/langtools: 10 new changesets Message-ID: <20121228060445.8326347414@hg.openjdk.java.net> Changeset: c78acf6c2f3e Author: mcimadamore Date: 2012-12-10 12:10 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/c78acf6c2f3e 8004094: Javac compiler error - synthetic method accessor generated with duplicate name Summary: method clash check logic should skip methods marked with ACC_SYNTHETIC Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/8004094/B.java + test/tools/javac/generics/8004094/T8004094.java Changeset: fcf89720ae71 Author: vromero Date: 2012-12-10 16:21 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/fcf89720ae71 8003967: detect and remove all mutable implicit static enum fields in langtools Reviewed-by: jjg ! src/share/classes/com/sun/tools/classfile/Opcode.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFileFactory.java ! src/share/classes/com/sun/tools/javac/Server.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/TargetType.java ! src/share/classes/com/sun/tools/javac/code/TypeTag.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/ConstFold.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/javax/lang/model/element/Modifier.java ! src/share/classes/javax/lang/model/util/ElementFilter.java ! src/share/classes/javax/tools/StandardLocation.java + test/tools/javac/T8003967/DetectMutableStaticFields.java Changeset: cfde9737131e Author: jjg Date: 2012-12-11 15:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/cfde9737131e 8004828: refactor init of *DocImpl classes Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ConstructorDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/MemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java Changeset: 170e486632d9 Author: jlahoda Date: 2012-12-12 20:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/170e486632d9 8004504: ListBuffer could reuse List.nil() as the sentinel element Summary: ListBuffer.last now points to the last elements with client data, or null if none. Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/util/ListBuffer.java + test/tools/javac/util/list/ListBufferTest.java Changeset: 376d6c1b49e5 Author: jfranck Date: 2012-12-03 11:16 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/376d6c1b49e5 8001114: Container annotation is not checked for semantic correctness Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.java ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.out ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.java ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.out ! test/tools/javac/annotations/repeatingAnnotations/NoRepeatableAnno.out + test/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.java + test/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.out ! test/tools/javac/diags/examples/ContainedByNonDefault.java + test/tools/javac/diags/examples/InvalidDuplicateAnnotation.java Changeset: d7360bf35ee1 Author: lana Date: 2012-12-14 13:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/d7360bf35ee1 Merge Changeset: 2001991b1b40 Author: katleman Date: 2012-12-20 09:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/2001991b1b40 Added tag jdk8-b69 for changeset d7360bf35ee1 ! .hgtags Changeset: 7d34e91f66bb Author: katleman Date: 2012-12-20 16:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/7d34e91f66bb 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! make/Makefile-classic ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor8.java ! test/tools/javac/StringsInSwitch/StringSwitches.java ! test/tools/javac/api/T6395981.java ! test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java ! test/tools/javac/diags/examples/DuplicateAnnotation.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestKinds.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase1.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase2.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase4.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/AttributeInjector.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassFile.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassFilePreprocessor.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassToInterfaceConverter.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/Compiler.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/DirectedClassLoader.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/SourceModel.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/TestHarness.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/FDSeparateCompilationTest.java ! test/tools/javac/nativeHeaders/javahComparison/CompareTest.java ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java Changeset: 47f71d7c124f Author: katleman Date: 2012-12-26 14:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/47f71d7c124f Merge Changeset: 7d5032c2d747 Author: katleman Date: 2012-12-27 12:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/7d5032c2d747 Added tag jdk8-b70 for changeset 47f71d7c124f ! .hgtags