From thomas.rodriguez at sun.com Thu Oct 1 13:23:37 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Thu, 01 Oct 2009 20:23:37 +0000 Subject: hg: hsx/hsx16/baseline: 6854812: 6.0_14-b08 crashes with a SIGSEGV Message-ID: <20091001202344.A33E141799@hg.openjdk.java.net> Changeset: b0d917e25d28 Author: never Date: 2009-09-30 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/b0d917e25d28 6854812: 6.0_14-b08 crashes with a SIGSEGV Reviewed-by: kvn, twisti ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/opto/parse1.cpp From gbenson at redhat.com Fri Oct 2 07:21:47 2009 From: gbenson at redhat.com (Gary Benson) Date: Fri, 2 Oct 2009 15:21:47 +0100 Subject: Second Zero review request In-Reply-To: <604C5161-8E04-45EA-A093-A7D7EFBEFDA3@sun.com> References: <20090924125631.GD3292@redhat.com> <604C5161-8E04-45EA-A093-A7D7EFBEFDA3@sun.com> Message-ID: <20091002142147.GC3260@redhat.com> Tom Rodriguez wrote: > I'm looking through these changes right now but I finally looked > into getting the arch into the build directory name. Basically I > added an extra variable called VARIANTARCH that is used to override > BUILDARCH in PLATFORM_DIR and modified the zero build rules to use > ZERO_LIBARCH for this. This results in linux_i386_zero for example, > so it won't use the same arch names as regular hotspot builds since > they use i486 for historical reasons but it's a more accurate naming > than zero_zero. You could do this: diff -r c39480d3aae6 hotspot/make/linux/Makefile --- a/hotspot/make/linux/Makefile Fri Oct 02 15:00:09 2009 +0100 +++ b/hotspot/make/linux/Makefile Fri Oct 02 15:02:20 2009 +0100 @@ -257,7 +257,7 @@ $(SUBDIRS_ZERO): $(BUILDTREE_MAKE) platform_zero $(QUIETLY) $(MAKE) -f $(GAMMADIR)/make/$(OSNAME)/Makefile checks - $(BUILDTREE) VARIANT=zero VARIANTARCH=$(ZERO_LIBARCH) + $(BUILDTREE) VARIANT=zero VARIANTARCH=$(subst i386, i486, $(ZERO_LIBARCH)) platform_zero: $(GAMMADIR)/make/$(OSNAME)/platform_zero.in $(SED) 's/@ZERO_ARCHDEF@/$(ZERO_ARCHDEF)/g;s/@ZERO_LIBARCH@/$(ZERO_LIBARCH)/g;' < $< > $@ That would make it linux_i486_zero. I think i486 is the only odd one. > I also found that I couldn't build zero by simply cd'ing to > make/linux and type make jvmgzero (plus all the required ZERO_ defs) > as I would expect. The reason is that the code that generates > platform_zero refers to OUTPUTDIR which doesn't mean anything unless > you invoke make from make/Makefile. It has a value but that value > isn't the necessarily the actual output directory. The platform > makefiles always build in the current directory so simply removing > $(OUTPUTDIR) for that platform_zero rule allows it to work as > expected and shouldn't change it's behaviour since OUTPUTDIR is > always equivalent to pwd. I've attached a patch that does both the > VARIANTARCH changes and the platform_zero changes. I was able to > build successfully with both make/Makefile and make/linux/Makefile > producing linux_i386_zero as the build directory. Thank you. > Unfortunately the bits crashed when running Queens but that happened > with or without my changes. The make command I issued was: > > make ZERO_ARCHDEF=IA32 ZERO_BUILD=true ZERO_LIBARCH=i386 > ZERO_ENDIANNESS=little ARCH_DATA_MODEL=32 ZERO_ARCHFLAG=-m32 jvmgzero > LIBFFI_LIBS=-lffi > > This is the crash message. > > cd linux_i386_zero/jvmg && ./test_gamma > java full version "1.6.0_14-b08" > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/ bytecodeInterpreter.cpp:427 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/never/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:427), pid=9886, tid=1082800448 > # Error: assert(istate->_stack_limit == istate->_thread->last_Java_sp() + 1,"wrong") > # > # JRE version: 6.0_14-b08 > # Java VM: OpenJDK Zero VM (17.0-b01-internal-jvmg interpreted mode linux-i386 ) > # An error report file with more information is saved as: > # /home/never/hotspot/make/linux/linux_i386_zero/jvmg/hs_err_pid9886.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > Current thread is 1082800448 > Dumping core ... > Aborted > make: *** [jvmgzero] Error 134 Someone else reported this the other day. I'll look into it... Cheers, Gary -- http://gbenson.net/ From Paul.Hohensee at Sun.COM Fri Oct 2 07:32:58 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Fri, 02 Oct 2009 10:32:58 -0400 Subject: Pls review 6887571 Message-ID: <4AC60F1A.2010801@sun.com> 6887571: Increase default heap config sizes Webrev at http://cr.openjdk.java.net/~phh/6887571/webrev.00/ From the CR description: The default client vm heap config since ~2000 has been the equivalent of -Xmx64m -XX:OldSize=4m -XX:NewSize=2m -XX:NewRatio=8 -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 for sparc32, and -Xmx64m -XX:OldSize=4m -XX:NewSize=1m -XX:NewRatio=12 -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 for x86. OldSize and NewSize are the initial committed sizes of the old and young gens respectively. A full gc is required to increase the committed size of the old gen. At the time, 64m was half of the 128m of memory typically available on high-end desktops, many client applications were satisfied with small heaps (hence the low -Xms value), and gc times were such that the young gen had to be fairly small in order to minimize pause times. Since that time, low end desktops and laptops, as well as netbooks and smartbooks, typically come with 256m, client applications have become much more "server-like", and we've realized that small young gen sizes increase the frequency of young gcs and the amount of transient data promoted to the old gen to levels that noticeably impact startup and steady-state performance, principally by provoking full GCs. We also note that young gen collection times are proportional to the total survivor size rather than young gen size and that small (in absolute terms) survivor spaces cause promotion of transient objects, thereby eventually provoking unnecessary full GCs. This change make the default heap config -Xmx128m -XX:OldSize=14m -XX:NewSize=4m -XX:NewRatio=2 -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 I.e., it leaves SurvivorRatio and MaxTenuringThreshold alone, but increases absolute survivor space size significantly. We still want as many objects to die in the young gen as possible, so MaxTenuringThreshold reamins at maximum. NewRatio is set to the server default of 2, thereby increasing reducing the number of young collections. JavaFX startup benchmark runs show an almost 11% improvement, while generic client startup benchmark runs show up to 14% improvement. Footprint increases somewhat, ranging from 2% for noop to 37% for netbeans. Thanks, Paul From Paul.Hohensee at Sun.COM Fri Oct 2 08:44:37 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Fri, 02 Oct 2009 11:44:37 -0400 Subject: Pls review 6887571 In-Reply-To: <4AC60F1A.2010801@sun.com> References: <4AC60F1A.2010801@sun.com> Message-ID: <4AC61FE5.7040400@sun.com> Typo toward the end: "thereby increasing reducing the number of young collections" should of course be "thereby reducing the number of young collections". Paul Paul Hohensee wrote: > 6887571: Increase default heap config sizes > > Webrev at > > http://cr.openjdk.java.net/~phh/6887571/webrev.00/ > > From the CR description: > > The default client vm heap config since ~2000 has been the equivalent of > > -Xmx64m -XX:OldSize=4m -XX:NewSize=2m -XX:NewRatio=8 > -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 > > for sparc32, and > > -Xmx64m -XX:OldSize=4m -XX:NewSize=1m -XX:NewRatio=12 > -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 > > for x86. OldSize and NewSize are the initial committed sizes of the old > and young gens respectively. A full gc is required to increase the > committed > size of the old gen. > > At the time, 64m was half of the 128m of memory typically available on > high-end > desktops, many client applications were satisfied with small heaps > (hence the > low -Xms value), and gc times were such that the young gen had to be > fairly small > in order to minimize pause times. > > Since that time, low end desktops and laptops, as well as netbooks and > smartbooks, > typically come with 256m, client applications have become much more > "server-like", > and we've realized that small young gen sizes increase the frequency > of young gcs > and the amount of transient data promoted to the old gen to levels > that noticeably > impact startup and steady-state performance, principally by provoking > full GCs. > We also note that young gen collection times are proportional to the > total survivor > size rather than young gen size and that small (in absolute terms) > survivor spaces > cause promotion of transient objects, thereby eventually provoking > unnecessary > full GCs. > > This change make the default heap config > > -Xmx128m -XX:OldSize=14m -XX:NewSize=4m -XX:NewRatio=2 > -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 > > I.e., it leaves SurvivorRatio and MaxTenuringThreshold alone, but > increases absolute > survivor space size significantly. We still want as many objects to > die in the young > gen as possible, so MaxTenuringThreshold reamins at maximum. NewRatio is > set to the server default of 2, thereby increasing reducing the number > of young collections. > > JavaFX startup benchmark runs show an almost 11% improvement, while > generic > client startup benchmark runs show up to 14% improvement. Footprint > increases > somewhat, ranging from 2% for noop to 37% for netbeans. > > Thanks, > > Paul > From Y.S.Ramakrishna at Sun.COM Fri Oct 2 09:57:28 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Fri, 02 Oct 2009 09:57:28 -0700 Subject: Pls review 6887571 In-Reply-To: <4AC60F1A.2010801@sun.com> References: <4AC60F1A.2010801@sun.com> Message-ID: <4AC630F8.9040204@Sun.COM> Hi Paul -- Looks good (and about time too!). Should the parameters whose defaults are now uniform across platforms migrate back to globals.hpp from their current lobals_*.hpp locations? Or do you see the need for continuing to keep them in platform-specific globals_*.hpp? -- ramki On 10/02/09 07:32, Paul Hohensee wrote: > 6887571: Increase default heap config sizes > > Webrev at > > http://cr.openjdk.java.net/~phh/6887571/webrev.00/ > > From the CR description: > > The default client vm heap config since ~2000 has been the equivalent of > > -Xmx64m -XX:OldSize=4m -XX:NewSize=2m -XX:NewRatio=8 > -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 > > for sparc32, and > > -Xmx64m -XX:OldSize=4m -XX:NewSize=1m -XX:NewRatio=12 > -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 > > for x86. OldSize and NewSize are the initial committed sizes of the old > and young gens respectively. A full gc is required to increase the > committed > size of the old gen. > > At the time, 64m was half of the 128m of memory typically available on > high-end > desktops, many client applications were satisfied with small heaps > (hence the > low -Xms value), and gc times were such that the young gen had to be > fairly small > in order to minimize pause times. > > Since that time, low end desktops and laptops, as well as netbooks and > smartbooks, > typically come with 256m, client applications have become much more > "server-like", > and we've realized that small young gen sizes increase the frequency of > young gcs > and the amount of transient data promoted to the old gen to levels that > noticeably > impact startup and steady-state performance, principally by provoking > full GCs. > We also note that young gen collection times are proportional to the > total survivor > size rather than young gen size and that small (in absolute terms) > survivor spaces > cause promotion of transient objects, thereby eventually provoking > unnecessary > full GCs. > > This change make the default heap config > > -Xmx128m -XX:OldSize=14m -XX:NewSize=4m -XX:NewRatio=2 > -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 > > I.e., it leaves SurvivorRatio and MaxTenuringThreshold alone, but > increases absolute > survivor space size significantly. We still want as many objects to die > in the young > gen as possible, so MaxTenuringThreshold reamins at maximum. NewRatio is > set to the server default of 2, thereby increasing reducing the number > of young collections. > > JavaFX startup benchmark runs show an almost 11% improvement, while generic > client startup benchmark runs show up to 14% improvement. Footprint > increases > somewhat, ranging from 2% for noop to 37% for netbeans. > > Thanks, > > Paul > From Paul.Hohensee at Sun.COM Fri Oct 2 10:05:29 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Fri, 02 Oct 2009 13:05:29 -0400 Subject: Pls review 6887571 In-Reply-To: <4AC630F8.9040204@Sun.COM> References: <4AC60F1A.2010801@sun.com> <4AC630F8.9040204@Sun.COM> Message-ID: <4AC632D9.4000804@sun.com> You're right, they should migrate back. If there's a need for them to diverge in the future, we can split them back out then. Thanks, Paul Y.S.Ramakrishna at Sun.COM wrote: > Hi Paul -- > > Looks good (and about time too!). > Should the parameters whose defaults are now > uniform across platforms migrate back to globals.hpp > from their current lobals_*.hpp locations? Or do you > see the need for continuing to keep them in platform-specific > globals_*.hpp? > > -- ramki > > On 10/02/09 07:32, Paul Hohensee wrote: >> 6887571: Increase default heap config sizes >> >> Webrev at >> >> http://cr.openjdk.java.net/~phh/6887571/webrev.00/ >> >> From the CR description: >> >> The default client vm heap config since ~2000 has been the equivalent of >> >> -Xmx64m -XX:OldSize=4m -XX:NewSize=2m -XX:NewRatio=8 >> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 >> >> for sparc32, and >> >> -Xmx64m -XX:OldSize=4m -XX:NewSize=1m -XX:NewRatio=12 >> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 >> >> for x86. OldSize and NewSize are the initial committed sizes of the old >> and young gens respectively. A full gc is required to increase the >> committed >> size of the old gen. >> >> At the time, 64m was half of the 128m of memory typically available >> on high-end >> desktops, many client applications were satisfied with small heaps >> (hence the >> low -Xms value), and gc times were such that the young gen had to be >> fairly small >> in order to minimize pause times. >> >> Since that time, low end desktops and laptops, as well as netbooks >> and smartbooks, >> typically come with 256m, client applications have become much more >> "server-like", >> and we've realized that small young gen sizes increase the frequency >> of young gcs >> and the amount of transient data promoted to the old gen to levels >> that noticeably >> impact startup and steady-state performance, principally by provoking >> full GCs. >> We also note that young gen collection times are proportional to the >> total survivor >> size rather than young gen size and that small (in absolute terms) >> survivor spaces >> cause promotion of transient objects, thereby eventually provoking >> unnecessary >> full GCs. >> >> This change make the default heap config >> >> -Xmx128m -XX:OldSize=14m -XX:NewSize=4m -XX:NewRatio=2 >> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 >> >> I.e., it leaves SurvivorRatio and MaxTenuringThreshold alone, but >> increases absolute >> survivor space size significantly. We still want as many objects to >> die in the young >> gen as possible, so MaxTenuringThreshold reamins at maximum. >> NewRatio is >> set to the server default of 2, thereby increasing reducing the >> number of young collections. >> >> JavaFX startup benchmark runs show an almost 11% improvement, while >> generic >> client startup benchmark runs show up to 14% improvement. Footprint >> increases >> somewhat, ranging from 2% for noop to 37% for netbeans. >> >> Thanks, >> >> Paul >> > From Vasanth.Venkatachalam at amd.com Fri Oct 2 13:44:28 2009 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Fri, 2 Oct 2009 15:44:28 -0500 Subject: Request for reviews (M): 6580131: Exposing Method Inlining InformationTo JVMTI Agents In-Reply-To: <4ABBE7F8.6030904@sun.com> References: <7E25251AA9AC1F47937B3C615B77ADA86A00D3@SAUSEXMB2.amd.com> <4ABBE7F8.6030904@sun.com> Message-ID: Hi Dan, I'm 90% of the way done incorporating the changes that you've suggested. There are two changes left that I have yet to make and wanted to ask clarification about. 1) You mention, >- the "next" field is bothering me due to it making the data stream > difficult to copy and relocate, but regular JVM/TI does pointers > in returned data structures also. Can you clarify what you mean by this? 2) You mention, > >line 1756 > >record->methods[record->numstackframes] = sd->method()->jmethod_id(); >This code does not check for a NULL method() return, but >the code that calls this function does. I'm guessing that >means that it is possible for sd->method() to return NULL >here... >Dan One solution to this would be to insert a null check that marks the whole JvmtiCompiledMethodLoadInlineRecord as invalid if sd->method() returns null. (In the header we could hash-define a constant value that indicates an invalid record). A JVMTI agent would then have to check that the record is valid before proceeding to use it. Would this be an acceptable solution? Regards, Vasanth -----Original Message----- From: Daniel.Daugherty at Sun.COM [mailto:Daniel.Daugherty at Sun.COM] Sent: Thursday, September 24, 2009 4:43 PM To: Venkatachalam, Vasanth Cc: hotspot-dev at openjdk.java.net; Pollan, Ben; Thomas.Rodriguez at Sun.COM Subject: Re: Request for reviews (M): 6580131: Exposing Method Inlining InformationTo JVMTI Agents Vasanth, Sorry it has taken me so long to get to this review. - is this targeted at OpenJDK6 or OpenJDK7? - original notes says needs 64-bit testing; still true? - will this need CCC approval? I hope not since this is a VM specific data stream that we're exporting. However ... - need to check with Kelly/Tim to see the right way to get the header file exported in the JDK. - the samples need some cleanup, but that's a side issue; they could be used as the basis for some new tests. src/share/vm/code/jvmticmlr.h > struct JvmtiCompiledMethodLoadRecordHeader_s - the "_s" suffix is not same style as JVM/TI; JVM/TI style is typedef struct _foo foo. - the "next" field is bothering me due to it making the data stream difficult to copy and relocate, but regular JVM/TI does pointers in returned data structures also. - version info should be explicit rather than bundled in "type" field - need to add version info constants, perhaps a major and minor number > struct JvmtiCompiledMethodLoadInlineRecord_s - The header field comment makes things a little more clear about the layout of this data. I'm thinking that the "void *" points to a blob of memory that we cast to: - JvmtiCompiledMethodLoadRecordHeader * which tells us the "type" of this record and tells us where the next record is or NULL. - JvmtiCompiledMethodLoadInlineRecord * which allows us to decode this first record - the "methods" and "bcis" fields possibly point to data that immediately follows the JvmtiCompiledMethodLoadInlineRecord; could be that all of the methods arrays and all of the bcis arrays are together in one place rather than interleaved Update: now that I've gone back and read the original e-mail, it is much more clear, but should some of this info be in the header file? > struct JvmtiCompiledMethodLoadDummyRecord_s - header comment mentions JvmtiCompiledMethodLoadRecord, but that does not exist src/share/vm/prims/jvmtiExport.cpp > line 1737 > int numstackframes = 0; This should be a "jint" just to match types. > line 1743 > "Assertion violation in add_inline_records:pc_address must be non-null" Drop the "Assertion violation in add_inline_records:" part; we know it's an assertion failure, the system will tell us where it is and the function name is wrong. > line 1753 > record->numstackframes = 0; You've already counted the frames by looping on 1748-1749. Why not set that value here rather than count again? If you're thinking that the ScopeDesc list size can change, then you need to check for an overflow in the loop on line 1755. > line 1754 > "Assertion violation in jvmtiExport::add_inline_records: numstackframes must be nonzero." Drop the "Assertion violation in jvmtiExport::add_inline_records:" part > line 1756 > record->methods[record->numstackframes] = sd->method()->jmethod_id(); This code does not check for a NULL method() return, but the code that calls this function does. I'm guessing that means that it is possible for sd->method() to return NULL here... Dan Venkatachalam, Vasanth wrote: > > Hi Tom, > > Thank you again for your detailed and insightful review. We have > revised our implementation based on your suggestions and submitted new > diffs for bugid 100085 with the changes described below. We have > attached these diffs and new sample JVMTI agents to the bug report at: > > > > https://bugs.openjdk.java.net/show_bug.cgi?id=100085 > > > > > > 1. Overall Structure > > > We have added one new header file to the Hotspot JVM, jvmticmlr.h. > This header defines a struct JvmtiCompiledMethodLoadRecordHeader that > represents arbitrary information passed through the void pointer. The > struct has a type field to indicate the type of information being > passed, and a next pointer. The type field can also be used to capture > versioning information. > > > > We also defined another struct, JvmtiCompiledMethodLoadInlineRecord, > which contains the previous struct as the first member but in addition > has extra fields for storing inlining information. One can similarly > define additional structs to pass other kinds of information. As an > example, we've defined a struct JvmtiCompiledMethodLoadDummyRecord, > which contains a string "I am a dummy record." When the sample JVMTI > agents that we have provided encounter a record of this type, they > print the string contained in the dummy record. > > > > This new header file jvmticmlr.h lives in the Hotspot > src/share/vm/code directory. However, we envision that the JDK > installer would copy it to the JDK include/ directory to make this > file available to external JVMTI agents, in the same way that it makes > jni.h available. > > > When a CompiledMethodLoad event is generated for an nmethod, the void > pointer will contain a list of JvmtiCompiledMethodLoadInlineRecords. > Each record has a pc address which actually represents a range of pc > addresses between that JvmtiCompiledMethodLoadInlineRecord and the pc > address of the next one in the list. > > > > When the sample JVMTI agents we have provided detect a > CompiledMethodLoad event, they first cast the void pointer,of the > CompiledMethodLoad callback to a JvmtiCompiledMethodLoadRecordHeader > * list, and iterate over each of the records in the list, checking > its type and then casting the record to the appropriate subtype > (e.g., JvmtiCompiledMethodLoadInlineRecords) before deciding how to > process it. > > > 2. Code Changes > > > > The main code changes are to the jvmtiExport.cpp file, located in > src/share/vm/prims. We have defined a new global method, > create_inline_records which returns a list of records containing > inline information for a given nmethod. The post_compiled_method_load > method of JvmtiExport calls this method to retrieve the > inlining information and pass it rhrough the void pointer. > > > > In addition to these changes, we have made the following miscellaneous > changes that were requested: > > > > -We changed the date of the copyright notices in the new header files > to 2009. > -We have changed all function names to use lowercase with underscores. > -We replaced null checks of impossible conditions with assertions as > recommended. > -We removed the unused type and offset fields from the data structure > that was previously called InlineInfoRecord and is now called > JVMTICompiledMethodLoadInlineRecord. We renamed the jmethodID[] array > to methods and bytecodeindexes to bcis. > -We removed the PCDescriptorList class since it was redundant. > > -We modified our code to use resource allocation rather than C heap > allocations. Please see the create_inline_records method in > jvmtiExport.cpp. > -We modified jvmtiExport.cpp to set the _compile_info void pointer > inside the JvmtiCompiledMethodLoadEventMark constructor, rather than > setting this pointer in a separate method call. > > > > 3. Sample Agents > > The sample agents now use the jvmticmlr.h header file. For ease of > testing, we have copied this header file from the JVM > > src/share/vm/code directory into the c and cpp directories containing > the agents. However, as noted before, the JDK installer would ideally > copy this header file to the JDK /include directory, so that it can be > made available in the same way that jni.h is available. > > > Again, we thank you for your detailed feedback. Please let us know if > you have additional comments or questions > > > > Regards, > > > > Vasanth > > > > > > *From:* Venkatachalam, Vasanth > *Sent:* Tuesday, August 04, 2009 10:47 AM > *To:* 'hotspot-dev at openjdk.java.net' > *Cc:* 'Thomas.Rodriguez at sun.com'; Joshi, Shrinivas; Pollan, Ben > *Subject:* RE: Request for reviews (M): 6580131: Exposing Method > Inlining InformationTo JVMTI Agents > > > > Hi Tom, > > > > Thank you for your detailed and insightful feedback on my JVMTI method > inlining submission. Sorry for the delay in responding to your > comments. We are scoping out the changes that you have recommended. > Some of these changes could take longer, but we hope to be able to > respond in a few days with some changes or at least a timeline on when > we can get them in. > > > > Regards, > > > > Vasanth > > > > > > -- > > Vasanth Venkatachalam > > AMD Java Labs > > (512)602-6177 > > > From erik.trimble at sun.com Sat Oct 3 06:34:49 2009 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Sat, 03 Oct 2009 13:34:49 +0000 Subject: hg: hsx/hsx16/baseline: 6887914: Bump the HS16 build number to 10 Message-ID: <20091003133454.10A6241A52@hg.openjdk.java.net> Changeset: 6bdfda9a7120 Author: trims Date: 2009-10-02 14:16 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/6bdfda9a7120 6887914: Bump the HS16 build number to 10 Summary: Update the HS16 build number to 10 Reviewed-by: jcoomes ! make/hotspot_version From antonios.printezis at sun.com Sat Oct 3 14:18:57 2009 From: antonios.printezis at sun.com (antonios.printezis at sun.com) Date: Sat, 03 Oct 2009 21:18:57 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20091003211905.34E6441ACE@hg.openjdk.java.net> Changeset: a0107ba3bc53 Author: johnc Date: 2009-10-01 15:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a0107ba3bc53 6887186: G1: Incorrect code generated for G1 pre-barrier by C1 on SPARC Summary: Modify operand passed to C1 pre-barrier to be the operand representing the address of the object field that is being stored. Reviewed-by: never ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp Changeset: 708275a44e4a Author: tonyp Date: 2009-10-03 10:53 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/708275a44e4a Merge ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp From erik.trimble at sun.com Sat Oct 3 18:56:54 2009 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Sun, 04 Oct 2009 01:56:54 +0000 Subject: hg: hsx/hsx16/master: 6 new changesets Message-ID: <20091004015713.A0EFA41B1A@hg.openjdk.java.net> Changeset: f00a893fee8c Author: acorn Date: 2009-09-11 13:41 -0400 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/f00a893fee8c 6879572: SA fails with "RuntimeException: field "_is_marked_dependent" not found Reviewed-by: dcubed, kamg ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f324a7d7fd56 Author: kvn Date: 2009-09-18 09:47 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/f324a7d7fd56 6880053: assert(alloc_obj->as_CheckCastPP()->type() != TypeInstPtr::NOTNULL) Summary: Removed second CheckCastPP and instead use MembarCPUOrder. Reviewed-by: never ! src/share/vm/opto/library_call.cpp Changeset: 2c0279a08300 Author: kvn Date: 2009-09-25 13:21 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/2c0279a08300 6883468: C2 compiler enters infinite loop in PhaseIterGVN::transform Summary: Avoid ideal transformation ping-pong between AddPNode::Ideal() and CastX2PNode::Ideal(). Reviewed-by: cfang ! src/share/vm/opto/connode.cpp Changeset: d19a5a05d449 Author: never Date: 2009-09-30 11:57 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/d19a5a05d449 6855215: Calculation error (NaN) after about 1500 calculations Reviewed-by: kvn ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_LinearScan_x86.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp + test/compiler/6855215/Test6855215.java Changeset: b0d917e25d28 Author: never Date: 2009-09-30 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/b0d917e25d28 6854812: 6.0_14-b08 crashes with a SIGSEGV Reviewed-by: kvn, twisti ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/opto/parse1.cpp Changeset: 6bdfda9a7120 Author: trims Date: 2009-10-02 14:16 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/6bdfda9a7120 6887914: Bump the HS16 build number to 10 Summary: Update the HS16 build number to 10 Reviewed-by: jcoomes ! make/hotspot_version From Daniel.Daugherty at Sun.COM Mon Oct 5 09:31:31 2009 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Mon, 05 Oct 2009 10:31:31 -0600 Subject: Request for reviews (M): 6580131: Exposing Method Inlining InformationTo JVMTI Agents In-Reply-To: References: <7E25251AA9AC1F47937B3C615B77ADA86A00D3@SAUSEXMB2.amd.com> <4ABBE7F8.6030904@sun.com> Message-ID: <4ACA1F63.3010908@sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20091005/3fc2efb4/attachment.html From Thomas.Rodriguez at Sun.COM Mon Oct 5 12:53:32 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 05 Oct 2009 12:53:32 -0700 Subject: Request for reviews (M): 6580131: Exposing Method Inlining InformationTo JVMTI Agents In-Reply-To: <4ACA1F63.3010908@sun.com> References: <7E25251AA9AC1F47937B3C615B77ADA86A00D3@SAUSEXMB2.amd.com> <4ABBE7F8.6030904@sun.com> <4ACA1F63.3010908@sun.com> Message-ID: >>>> line 1756 >>>> >> > >record->methods[record->numstackframes] = sd->method()- >> >jmethod_id(); >> >> >>> This code does not check for a NULL method() return, but >>> the code that calls this function does. I'm guessing that >>> means that it is possible for sd->method() to return NULL >>> here... >>> >> >> One solution to this would be to insert a null check that marks the >> whole JvmtiCompiledMethodLoadInlineRecord as invalid if sd- >> >method() returns null. (In the header we could hash-define a >> constant value that indicates an invalid record). A JVMTI agent >> would then have to check that the record is valid before proceeding >> to use it. Would this be an acceptable solution? >> > > I think for this "failure mode", you're going to need Tom's opinion > about what a NULL sd->method() return means. It seems to me that you > could potentially be invalidating a lot of data due to one glitch. > It might be better to return a dummy jmethodID, e.g., NO_METHOD_FOUND, > for that method and let the agent sort out it out amongst the rest of > the data... I think the method can be NULL for stubs but never for nmethods. If you wanted to be completely robust then ignore them if you encounter them but include an assert that you should never see them. tom > > Dan > From David.Holmes at Sun.COM Mon Oct 5 17:40:59 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Tue, 06 Oct 2009 10:40:59 +1000 Subject: Pls review 6887571 In-Reply-To: <4AC632D9.4000804@sun.com> References: <4AC60F1A.2010801@sun.com> <4AC630F8.9040204@Sun.COM> <4AC632D9.4000804@sun.com> Message-ID: <4ACA921B.5070502@sun.com> Any reason -Xmx has to be hardcoded rather than calculated based on the installed/available memory ? Then OldSize and newSize can/should be fractions on mx value. Just a thought ... David Paul Hohensee said the following on 10/03/09 03:05: > You're right, they should migrate back. If there's a need for them to > diverge > in the future, we can split them back out then. > > Thanks, > > Paul > > Y.S.Ramakrishna at Sun.COM wrote: >> Hi Paul -- >> >> Looks good (and about time too!). >> Should the parameters whose defaults are now >> uniform across platforms migrate back to globals.hpp >> from their current lobals_*.hpp locations? Or do you >> see the need for continuing to keep them in platform-specific >> globals_*.hpp? >> >> -- ramki >> >> On 10/02/09 07:32, Paul Hohensee wrote: >>> 6887571: Increase default heap config sizes >>> >>> Webrev at >>> >>> http://cr.openjdk.java.net/~phh/6887571/webrev.00/ >>> >>> From the CR description: >>> >>> The default client vm heap config since ~2000 has been the equivalent of >>> >>> -Xmx64m -XX:OldSize=4m -XX:NewSize=2m -XX:NewRatio=8 >>> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 >>> >>> for sparc32, and >>> >>> -Xmx64m -XX:OldSize=4m -XX:NewSize=1m -XX:NewRatio=12 >>> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 >>> >>> for x86. OldSize and NewSize are the initial committed sizes of the old >>> and young gens respectively. A full gc is required to increase the >>> committed >>> size of the old gen. >>> >>> At the time, 64m was half of the 128m of memory typically available >>> on high-end >>> desktops, many client applications were satisfied with small heaps >>> (hence the >>> low -Xms value), and gc times were such that the young gen had to be >>> fairly small >>> in order to minimize pause times. >>> >>> Since that time, low end desktops and laptops, as well as netbooks >>> and smartbooks, >>> typically come with 256m, client applications have become much more >>> "server-like", >>> and we've realized that small young gen sizes increase the frequency >>> of young gcs >>> and the amount of transient data promoted to the old gen to levels >>> that noticeably >>> impact startup and steady-state performance, principally by provoking >>> full GCs. >>> We also note that young gen collection times are proportional to the >>> total survivor >>> size rather than young gen size and that small (in absolute terms) >>> survivor spaces >>> cause promotion of transient objects, thereby eventually provoking >>> unnecessary >>> full GCs. >>> >>> This change make the default heap config >>> >>> -Xmx128m -XX:OldSize=14m -XX:NewSize=4m -XX:NewRatio=2 >>> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 >>> >>> I.e., it leaves SurvivorRatio and MaxTenuringThreshold alone, but >>> increases absolute >>> survivor space size significantly. We still want as many objects to >>> die in the young >>> gen as possible, so MaxTenuringThreshold reamins at maximum. >>> NewRatio is >>> set to the server default of 2, thereby increasing reducing the >>> number of young collections. >>> >>> JavaFX startup benchmark runs show an almost 11% improvement, while >>> generic >>> client startup benchmark runs show up to 14% improvement. Footprint >>> increases >>> somewhat, ranging from 2% for noop to 37% for netbeans. >>> >>> Thanks, >>> >>> Paul >>> >> From Peter.Kessler at Sun.COM Mon Oct 5 18:21:10 2009 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Mon, 05 Oct 2009 18:21:10 -0700 Subject: Pls review 6887571 In-Reply-To: <4ACA921B.5070502@sun.com> References: <4AC60F1A.2010801@sun.com> <4AC630F8.9040204@Sun.COM> <4AC632D9.4000804@sun.com> <4ACA921B.5070502@sun.com> Message-ID: <4ACA9B86.4020202@Sun.COM> I think that's http://bugs.sun.com/view_bug.do?bug_id=6255634 The argument against it is multiple (identical?) JVM's, each requesting 75% of the _installed_ memory. Or multiple JVM's the first of which gets 75% of the _available_ memory, and the second of which gets 75% of what's left, and the third of which gets 75% of what's left, etc. But for a single JVM on a machine, it might make sense, at least as an option. Really what's wanted is "external ergonomics", and chunked heaps. ... peter David Holmes - Sun Microsystems wrote: > Any reason -Xmx has to be hardcoded rather than calculated based on the > installed/available memory ? Then OldSize and newSize can/should be > fractions on mx value. > > Just a thought ... > > David > > Paul Hohensee said the following on 10/03/09 03:05: >> You're right, they should migrate back. If there's a need for them to >> diverge >> in the future, we can split them back out then. >> >> Thanks, >> >> Paul >> >> Y.S.Ramakrishna at Sun.COM wrote: >>> Hi Paul -- >>> >>> Looks good (and about time too!). >>> Should the parameters whose defaults are now >>> uniform across platforms migrate back to globals.hpp >>> from their current lobals_*.hpp locations? Or do you >>> see the need for continuing to keep them in platform-specific >>> globals_*.hpp? >>> >>> -- ramki >>> >>> On 10/02/09 07:32, Paul Hohensee wrote: >>>> 6887571: Increase default heap config sizes >>>> >>>> Webrev at >>>> >>>> http://cr.openjdk.java.net/~phh/6887571/webrev.00/ >>>> >>>> From the CR description: >>>> >>>> The default client vm heap config since ~2000 has been the >>>> equivalent of >>>> >>>> -Xmx64m -XX:OldSize=4m -XX:NewSize=2m -XX:NewRatio=8 >>>> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 >>>> >>>> for sparc32, and >>>> >>>> -Xmx64m -XX:OldSize=4m -XX:NewSize=1m -XX:NewRatio=12 >>>> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 >>>> >>>> for x86. OldSize and NewSize are the initial committed sizes of the >>>> old >>>> and young gens respectively. A full gc is required to increase the >>>> committed >>>> size of the old gen. >>>> >>>> At the time, 64m was half of the 128m of memory typically available >>>> on high-end >>>> desktops, many client applications were satisfied with small heaps >>>> (hence the >>>> low -Xms value), and gc times were such that the young gen had to be >>>> fairly small >>>> in order to minimize pause times. >>>> >>>> Since that time, low end desktops and laptops, as well as netbooks >>>> and smartbooks, >>>> typically come with 256m, client applications have become much more >>>> "server-like", >>>> and we've realized that small young gen sizes increase the frequency >>>> of young gcs >>>> and the amount of transient data promoted to the old gen to levels >>>> that noticeably >>>> impact startup and steady-state performance, principally by >>>> provoking full GCs. >>>> We also note that young gen collection times are proportional to the >>>> total survivor >>>> size rather than young gen size and that small (in absolute terms) >>>> survivor spaces >>>> cause promotion of transient objects, thereby eventually provoking >>>> unnecessary >>>> full GCs. >>>> >>>> This change make the default heap config >>>> >>>> -Xmx128m -XX:OldSize=14m -XX:NewSize=4m -XX:NewRatio=2 >>>> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 >>>> >>>> I.e., it leaves SurvivorRatio and MaxTenuringThreshold alone, but >>>> increases absolute >>>> survivor space size significantly. We still want as many objects to >>>> die in the young >>>> gen as possible, so MaxTenuringThreshold reamins at maximum. >>>> NewRatio is >>>> set to the server default of 2, thereby increasing reducing the >>>> number of young collections. >>>> >>>> JavaFX startup benchmark runs show an almost 11% improvement, while >>>> generic >>>> client startup benchmark runs show up to 14% improvement. Footprint >>>> increases >>>> somewhat, ranging from 2% for noop to 37% for netbeans. >>>> >>>> Thanks, >>>> >>>> Paul >>>> >>> From Paul.Hohensee at Sun.COM Tue Oct 6 05:20:33 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Tue, 06 Oct 2009 08:20:33 -0400 Subject: Pls review 6887571 In-Reply-To: <4ACA921B.5070502@sun.com> References: <4AC60F1A.2010801@sun.com> <4AC630F8.9040204@Sun.COM> <4AC632D9.4000804@sun.com> <4ACA921B.5070502@sun.com> Message-ID: <4ACB3611.1010609@sun.com> Could. Jon has suggested the same thing. Problem is that available memory at startup doesn't say anything about what the future will be, ditto installed memory. Paul David Holmes - Sun Microsystems wrote: > Any reason -Xmx has to be hardcoded rather than calculated based on > the installed/available memory ? Then OldSize and newSize can/should > be fractions on mx value. > > Just a thought ... > > David > > Paul Hohensee said the following on 10/03/09 03:05: >> You're right, they should migrate back. If there's a need for them >> to diverge >> in the future, we can split them back out then. >> >> Thanks, >> >> Paul >> >> Y.S.Ramakrishna at Sun.COM wrote: >>> Hi Paul -- >>> >>> Looks good (and about time too!). >>> Should the parameters whose defaults are now >>> uniform across platforms migrate back to globals.hpp >>> from their current lobals_*.hpp locations? Or do you >>> see the need for continuing to keep them in platform-specific >>> globals_*.hpp? >>> >>> -- ramki >>> >>> On 10/02/09 07:32, Paul Hohensee wrote: >>>> 6887571: Increase default heap config sizes >>>> >>>> Webrev at >>>> >>>> http://cr.openjdk.java.net/~phh/6887571/webrev.00/ >>>> >>>> From the CR description: >>>> >>>> The default client vm heap config since ~2000 has been the >>>> equivalent of >>>> >>>> -Xmx64m -XX:OldSize=4m -XX:NewSize=2m -XX:NewRatio=8 >>>> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 >>>> >>>> for sparc32, and >>>> >>>> -Xmx64m -XX:OldSize=4m -XX:NewSize=1m -XX:NewRatio=12 >>>> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 >>>> >>>> for x86. OldSize and NewSize are the initial committed sizes of >>>> the old >>>> and young gens respectively. A full gc is required to increase the >>>> committed >>>> size of the old gen. >>>> >>>> At the time, 64m was half of the 128m of memory typically available >>>> on high-end >>>> desktops, many client applications were satisfied with small heaps >>>> (hence the >>>> low -Xms value), and gc times were such that the young gen had to >>>> be fairly small >>>> in order to minimize pause times. >>>> >>>> Since that time, low end desktops and laptops, as well as netbooks >>>> and smartbooks, >>>> typically come with 256m, client applications have become much more >>>> "server-like", >>>> and we've realized that small young gen sizes increase the >>>> frequency of young gcs >>>> and the amount of transient data promoted to the old gen to levels >>>> that noticeably >>>> impact startup and steady-state performance, principally by >>>> provoking full GCs. >>>> We also note that young gen collection times are proportional to >>>> the total survivor >>>> size rather than young gen size and that small (in absolute terms) >>>> survivor spaces >>>> cause promotion of transient objects, thereby eventually provoking >>>> unnecessary >>>> full GCs. >>>> >>>> This change make the default heap config >>>> >>>> -Xmx128m -XX:OldSize=14m -XX:NewSize=4m -XX:NewRatio=2 >>>> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 >>>> >>>> I.e., it leaves SurvivorRatio and MaxTenuringThreshold alone, but >>>> increases absolute >>>> survivor space size significantly. We still want as many objects >>>> to die in the young >>>> gen as possible, so MaxTenuringThreshold reamins at maximum. >>>> NewRatio is >>>> set to the server default of 2, thereby increasing reducing the >>>> number of young collections. >>>> >>>> JavaFX startup benchmark runs show an almost 11% improvement, while >>>> generic >>>> client startup benchmark runs show up to 14% improvement. >>>> Footprint increases >>>> somewhat, ranging from 2% for noop to 37% for netbeans. >>>> >>>> Thanks, >>>> >>>> Paul >>>> >>> From Thomas.Rodriguez at Sun.COM Tue Oct 6 14:06:23 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 06 Oct 2009 14:06:23 -0700 Subject: Second Zero review request In-Reply-To: <20091002142147.GC3260@redhat.com> References: <20090924125631.GD3292@redhat.com> <604C5161-8E04-45EA-A093-A7D7EFBEFDA3@sun.com> <20091002142147.GC3260@redhat.com> Message-ID: <7CBADC95-0F02-4431-8B82-8989C124370B@Sun.COM> On Oct 2, 2009, at 7:21 AM, Gary Benson wrote: > Tom Rodriguez wrote: >> I'm looking through these changes right now but I finally looked >> into getting the arch into the build directory name. Basically I >> added an extra variable called VARIANTARCH that is used to override >> BUILDARCH in PLATFORM_DIR and modified the zero build rules to use >> ZERO_LIBARCH for this. This results in linux_i386_zero for example, >> so it won't use the same arch names as regular hotspot builds since >> they use i486 for historical reasons but it's a more accurate naming >> than zero_zero. > > You could do this: > > diff -r c39480d3aae6 hotspot/make/linux/Makefile > --- a/hotspot/make/linux/Makefile Fri Oct 02 15:00:09 2009 +0100 > +++ b/hotspot/make/linux/Makefile Fri Oct 02 15:02:20 2009 +0100 > @@ -257,7 +257,7 @@ > > $(SUBDIRS_ZERO): $(BUILDTREE_MAKE) platform_zero > $(QUIETLY) $(MAKE) -f $(GAMMADIR)/make/$(OSNAME)/Makefile checks > - $(BUILDTREE) VARIANT=zero VARIANTARCH=$(ZERO_LIBARCH) > + $(BUILDTREE) VARIANT=zero VARIANTARCH=$(subst i386, i486, $ > (ZERO_LIBARCH)) > > platform_zero: $(GAMMADIR)/make/$(OSNAME)/platform_zero.in > $(SED) 's/@ZERO_ARCHDEF@/$(ZERO_ARCHDEF)/g;s/@ZERO_LIBARCH@/$ > (ZERO_LIBARCH)/g;' < $< > $@ > > That would make it linux_i486_zero. I think i486 is the only odd one. That's a good idea. tom > >> I also found that I couldn't build zero by simply cd'ing to >> make/linux and type make jvmgzero (plus all the required ZERO_ defs) >> as I would expect. The reason is that the code that generates >> platform_zero refers to OUTPUTDIR which doesn't mean anything unless >> you invoke make from make/Makefile. It has a value but that value >> isn't the necessarily the actual output directory. The platform >> makefiles always build in the current directory so simply removing >> $(OUTPUTDIR) for that platform_zero rule allows it to work as >> expected and shouldn't change it's behaviour since OUTPUTDIR is >> always equivalent to pwd. I've attached a patch that does both the >> VARIANTARCH changes and the platform_zero changes. I was able to >> build successfully with both make/Makefile and make/linux/Makefile >> producing linux_i386_zero as the build directory. > > Thank you. > >> Unfortunately the bits crashed when running Queens but that happened >> with or without my changes. The make command I issued was: >> >> make ZERO_ARCHDEF=IA32 ZERO_BUILD=true ZERO_LIBARCH=i386 >> ZERO_ENDIANNESS=little ARCH_DATA_MODEL=32 ZERO_ARCHFLAG=-m32 jvmgzero >> LIBFFI_LIBS=-lffi >> >> This is the crash message. >> >> cd linux_i386_zero/jvmg && ./test_gamma >> java full version "1.6.0_14-b08" >> # To suppress the following error report, specify this argument >> # after -XX: or in .hotspotrc: SuppressErrorAt=/ >> bytecodeInterpreter.cpp:427 >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/home/never/hotspot/src/share/vm/interpreter/ >> bytecodeInterpreter.cpp:427), pid=9886, tid=1082800448 >> # Error: assert(istate->_stack_limit == istate->_thread- >> >last_Java_sp() + 1,"wrong") >> # >> # JRE version: 6.0_14-b08 >> # Java VM: OpenJDK Zero VM (17.0-b01-internal-jvmg interpreted mode >> linux-i386 ) >> # An error report file with more information is saved as: >> # /home/never/hotspot/make/linux/linux_i386_zero/jvmg/ >> hs_err_pid9886.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> Current thread is 1082800448 >> Dumping core ... >> Aborted >> make: *** [jvmgzero] Error 134 > > Someone else reported this the other day. I'll look into it... > > Cheers, > Gary > > -- > http://gbenson.net/ From Thomas.Rodriguez at Sun.COM Tue Oct 6 14:06:34 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 06 Oct 2009 14:06:34 -0700 Subject: Second Zero review request In-Reply-To: <20090924125631.GD3292@redhat.com> References: <20090924125631.GD3292@redhat.com> Message-ID: <7E60E07E-4162-4FFF-BA60-3D9DC1F5896C@sun.com> On Sep 24, 2009, at 5:56 AM, Gary Benson wrote: > Hi all, > > Zero is an interpreter-only port of HotSpot that uses no assembler and > can trivially be built on any Linux system. The following webrev adds > Zero support to OpenJDK: > > http://cr.openjdk.java.net/~gbenson/zero-10/ > > Building is largely the same as the previous webrev (zero-07) except > for the following changes: > > - The variable CORE_BUILD is no longer used. > - The variable ZERO_BITSPERWORD has been replaced with > ARCH_DATA_MODEL > > Summary of changes > ================== > This all looks fine. > > Summary of non-changes > ====================== > > - The variable ZERO_ENDIANNESS remains unchanged. I haven't renamed > it as ENDIANNESS because it's only used during Zero builds. It's > possible that the makefiles could be refactored such that, for > example, existing platforms set ENDIANNESS (leaving Zero requiring > it to be set externally) but I wasn't sure I should be doing this > in this patch. ok. > > - The build directory is linux_zero_zero (or linux_zero_shark) rather > than linux_$(ARCH)_zero. There is no variable defining the name of > the build directory as such, it's always referenced as > $(OSNAME)_$(BUILDARCH)_whatever, and in addition to specifiying the > build directory, BUILDARCH is used in conditionals in various > makefiles to add extra compiler flags, etc. If BUILDARCH is set to > "i486", for example, then extra compiler flags are added which are > unnecessary (and possibly problematic) for Zero. I'll assume you're ok with my change to make work, combined with you change to make i386 be i486. > > - The variable ZERO_LIBARCH remains. It's used in several different > places, and I couldn't figure out a place to put the logic to > convert a uname string to the correct ZERO_LIBARCH value where the > result would be accessible everywhere it is required. That's fine. So I'm fine with the hotspot parts and assume others have no complaints since we haven't heard any. Have you gotten reviews of the other parts from their respective owners? tom > > Build Instructions > ================== > > There are a number of environment variables that need setting before > running make, but if you are using jdk/make/jdk_generic_profile.sh > to set up your environment then you only need to set one, and a build > can be as simple as: > > export ZERO_BUILD=true > . jdk/make/jdk_generic_profile.sh > gmake sanity && gmake > > The mandatory environment variable does the following: > > ZERO_BUILD > Setting ZERO_BUILD to "true" will cause the Zero interpreter to > be used. If ZERO_BUILD is unset, or set to any other value than > "true", the standard, platform-specific interpreter will be used. > > Of the other environment variables the following are required when > ZERO_BUILD is set to "true". These are set by > jdk/make/jdk_generic_profile.sh based on the result of uname -m: > > ZERO_LIBARCH > This is the name of the architecture-specific subdirectory under > $JAVA_HOME/jre/lib. Typically this will be the same as the > output > of uname -m, although there are some exceptions: "amd64" instead > of "x86_64", for example, and "i386" instead of "i686". > > ZERO_ARCHDEF > The value of ZERO_ARCHDEF will be passed to the C++ compiler > using > -D${ZERO_ARCHDEF} to allow conditionalized platform-specific > code. > This is typically set to ZERO_LIBARCH converted to uppercase but, > again, there are exceptions. "i386" becomes "IA32", to match > what > HotSpot already does, and on platforms with both 32- and 64-bit > variants ZERO_ARCHDEF corresponds to the 32-bit version, so both > ppc and ppc64 have ZERO_ARCHDEF set to "PPC". > > ZERO_ENDIANNESS > This is set to "little" or "big". > > ARCH_DATA_MODEL > This is set to "32" or "64". > > ZERO_ARCHFLAG > This is a flag that will be passed to the C++ compiler and to the > linker to instruct them to generate code for the particular > platform. This is required for platforms with both 32- and 64- > bit > variants where the compiler needs to be told which variant to > build for. ZERO_ARCHFLAG will typically be set to "-m32" or > "-m64", except on 31-bit zSeries where it will be set to "-m31". > > Zero uses one external library, libffi, for JNI method invocation. > The following two variables are used to tell the compiler and linker > how to find libffi. These can be set by the user, but if left unset > then jdk/make/jdk_generic_profile.sh will attempt to set them using > pkg-config or, failing that, by supplying defaults pointing to the > standard locations: > > LIBFFI_CFLAGS > Flags to be passed to the C++ compiler to build against libffi. > If unset (and pkg-config is not installed, or if libffi is not > built with pkg-config) then this defaults to "". > > LIBFFI_LIBS > Flags to be passed to the linker to link against libffi. If > unset (and pkg-config is not installed, or if libffi is not > built with pkg-config) then this defaults to "-lffi". > > -- > http://gbenson.net/ From Vasanth.Venkatachalam at amd.com Tue Oct 6 16:32:43 2009 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Tue, 6 Oct 2009 18:32:43 -0500 Subject: Request for reviews (M): 6580131: Exposing Method Inlining InformationTo JVMTI Agents Message-ID: Hi Tom, Dan, Thank you again for your detailed feedback. We have revised our implementation based on your suggestions and submitted new diffs for bugid 100085 with the changes described below. We have attached these diffs and new sample JVMTI agents to the bug report at: https://bugs.openjdk.java.net/show_bug.cgi?id=100085 We have tested the code on both a 32-bit Windows system and a 64-bit Linux system. We don't know whether these changes will require CCC team approval. We are hoping these changes will get into JDK6 update 20, but if this is not possible we would like to target JDK 7. Note that this implementation reports inlining information for CompiledMethodLoad events that are not triggered by the GenerateEvents mechanism. For those that are triggered by GenerateEvents, the void pointer will be initialized to NULL. We can discuss whether to add support for GenerateEvents in a future submission. 1. Overall Structure Following Tom Rodriguez's suggestion, we made changes so that for every compiled method, the JVM passes a single JvmtiCompiledMethodLoadInlineRecord through the void pointer. This record contains an array of PCStackInfo structs, which give the inlining information for each pc address of that method. In the previous submission, the JVM was instead passing multiple JvmtiCompiledMethodLoadInlineRecords, one for each pc address. These changes affect jvmticmlr.h (which defines the new data structure) and jvmtiExport.cpp, where we have defined a new method, create_inline_record. 2. Miscellaneous changes We made the following additional changes requested by Dan Daugherty: -We modified the naming conventions for structs defined in jvmticmlr.h to make them consistent with the conventions used by JVMTI. -We added explicit version info major and minor constants to the JvmtiCompiledMethodLoadRecordHeader struct. The JVM initializes these fields to 0 in jvmtiExport.cpp, but this can be changed as needed. -We have added more detailed comments to the jvmticmlr.h header file, to describe the sequence of events that takes place when a JVMTI agent accesses the void pointer. -We removed from jvmticmlr.h a comment that referenced JvmtiCompiledMethodLoadRecord, which doesn't exist. -We changed "int" to "jint" to match types where applicable. -We removed redundant comments from assertion violations in the create_inline_record method in jvmtiExport.cpp. -We removed redundant code that was counting the number of stack frames twice in create_inline_record. -We added an assertion to check for a null sd->method( ) in create_inline_record, as suggested by Tom Rodriguez. Please let us know if you have any additional questions or concerns. We hope this revision addresses your comments. Regards, Vasanth -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20091006/05dc87c5/attachment.html From gbenson at redhat.com Wed Oct 7 01:50:42 2009 From: gbenson at redhat.com (Gary Benson) Date: Wed, 7 Oct 2009 04:50:42 -0400 Subject: Second Zero review request In-Reply-To: <7E60E07E-4162-4FFF-BA60-3D9DC1F5896C@sun.com> References: <20090924125631.GD3292@redhat.com> <7E60E07E-4162-4FFF-BA60-3D9DC1F5896C@sun.com> Message-ID: <20091007085042.GA10383@shell.devel.redhat.com> Tom Rodriguez wrote: > On Sep 24, 2009, at 5:56 AM, Gary Benson wrote: > > Zero is an interpreter-only port of HotSpot that uses no assembler > > and can trivially be built on any Linux system. The following > > webrev adds Zero support to OpenJDK: > > > > http://cr.openjdk.java.net/~gbenson/zero-10/ > > > > Building is largely the same as the previous webrev (zero-07) except > > for the following changes: > > > > - The variable CORE_BUILD is no longer used. > > - The variable ZERO_BITSPERWORD has been replaced with ARCH_DATA_MODEL > > > > Summary of changes > > ================== > > This all looks fine. Excellent :) > > - The build directory is linux_zero_zero (or linux_zero_shark) rather > > than linux_$(ARCH)_zero. There is no variable defining the name > > of the build directory as such, it's always referenced as > > $(OSNAME)_$(BUILDARCH)_whatever, and in addition to specifiying > > the build directory, BUILDARCH is used in conditionals in > > various makefiles to add extra compiler flags, etc. If > > BUILDARCH is set to "i486", for example, then extra compiler > > flags are added which are unnecessary (and possibly problematic) > > for Zero. > > I'll assume you're ok with my change to make work, combined with you > change to make i386 be i486. Yes. > So I'm fine with the hotspot parts and assume others have no > complaints since we haven't heard any. Have you gotten reviews of > the other parts from their respective owners? No, but I haven't posted it anywhere but this list yet. I'm not 100% familiar with how everything is organised, but I'm assuming your approval goes for paths starting with "hotspot" and that other bits need approving by others? I guess core-libs-dev is the list for the "jdk" makefiles. Is that list the one for the "corba" makefile change too? Also, who owns the top-level file make/hotspot-rules.gmk? I'll roll a new webrev with the build directory changes before I post anything, and copy it here. Cheers, Gary -- http://gbenson.net/ From gnu_andrew at member.fsf.org Wed Oct 7 01:57:21 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 7 Oct 2009 09:57:21 +0100 Subject: Second Zero review request In-Reply-To: <20091007085042.GA10383@shell.devel.redhat.com> References: <20090924125631.GD3292@redhat.com> <7E60E07E-4162-4FFF-BA60-3D9DC1F5896C@sun.com> <20091007085042.GA10383@shell.devel.redhat.com> Message-ID: <17c6771e0910070157h4694e7eqa434787e300b94e6@mail.gmail.com> 2009/10/7 Gary Benson : > Tom Rodriguez wrote: >> On Sep 24, 2009, at 5:56 AM, Gary Benson wrote: >> > Zero is an interpreter-only port of HotSpot that uses no assembler >> > and can trivially be built on any Linux system. ?The following >> > webrev adds Zero support to OpenJDK: >> > >> > ?http://cr.openjdk.java.net/~gbenson/zero-10/ >> > >> > Building is largely the same as the previous webrev (zero-07) except >> > for the following changes: >> > >> > ?- The variable CORE_BUILD is no longer used. >> > ?- The variable ZERO_BITSPERWORD has been replaced with ARCH_DATA_MODEL >> > >> > Summary of changes >> > ================== >> >> This all looks fine. > > Excellent :) > >> > - The build directory is linux_zero_zero (or linux_zero_shark) rather >> > ? than linux_$(ARCH)_zero. ?There is no variable defining the name >> > ? of the build directory as such, it's always referenced as >> > ? $(OSNAME)_$(BUILDARCH)_whatever, and in addition to specifiying >> > ? the build directory, BUILDARCH is used in conditionals in >> > ? various makefiles to add extra compiler flags, etc. ?If >> > ? BUILDARCH is set to "i486", for example, then extra compiler >> > ? flags are added which are unnecessary (and possibly problematic) >> > ? for Zero. >> >> I'll assume you're ok with my change to make work, combined with you >> change to make i386 be i486. > > Yes. > >> So I'm fine with the hotspot parts and assume others have no >> complaints since we haven't heard any. ?Have you gotten reviews of >> the other parts from their respective owners? > > No, but I haven't posted it anywhere but this list yet. ?I'm not 100% > familiar with how everything is organised, but I'm assuming your > approval goes for paths starting with "hotspot" and that other bits > need approving by others? > > I guess core-libs-dev is the list for the "jdk" makefiles. ?Is that > list the one for the "corba" makefile change too? ?Also, who owns the > top-level file make/hotspot-rules.gmk? > The mapping of areas to mailing lists is here: http://openjdk.java.net/guide/repositories.html CORBA is maintained upstream as part of Glassfish, so build-dev is responsible for the OpenJDK copy. Which mailing list is appropriate for the jdk changes depends on which areas are affected. IIRC it's all Makefile alterations so build-dev might be the best place to post the non-HotSpot changes, at least initially. > I'll roll a new webrev with the build directory changes before I post > anything, and copy it here. > > Cheers, > Gary > > -- > http://gbenson.net/ > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Christian.Thalinger at Sun.COM Wed Oct 7 02:19:41 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 07 Oct 2009 11:19:41 +0200 Subject: Improper usage of CHECK macros generates unreachable code In-Reply-To: References: Message-ID: <1254907181.20991.6.camel@macbook> On Wed, 2009-09-30 at 19:05 +0200, Volker Simonis wrote: > If somebody would be so kind to open a bug for this issue, I would contribute > a patch which fixes the mentioned 'misuses' of the CHECK macro. Hi Volker! Sorry for the long delay. That definitely seems to be a problem. I opened: 6889002: CHECK macros in return constructs lead to unreachable code -- Christian From David.Holmes at Sun.COM Wed Oct 7 03:20:04 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Wed, 07 Oct 2009 20:20:04 +1000 Subject: Improper usage of CHECK macros generates unreachable code In-Reply-To: <1254907181.20991.6.camel@macbook> References: <1254907181.20991.6.camel@macbook> Message-ID: <4ACC6B54.8040305@sun.com> Christian Thalinger said the following on 10/07/09 19:19: > On Wed, 2009-09-30 at 19:05 +0200, Volker Simonis wrote: >> If somebody would be so kind to open a bug for this issue, I would contribute >> a patch which fixes the mentioned 'misuses' of the CHECK macro. > > Hi Volker! > > Sorry for the long delay. That definitely seems to be a problem. I > opened: > > 6889002: CHECK macros in return constructs lead to unreachable code I just updated the CR with the following: I dont think it sufficient to simply replace CHECK with THREAD. The problem is that the value being returned may be complete garbage. ie given: return create_string_variable(ns, name, 0, s, CHECK); the intent is to return NULL if create_string_variable triggers an exception, but if we change this to: return create_string_variable(ns, name, 0, s, THREAD); we don't know what value will be returned without examining the internals of create_string_variable. So the replacement would be unsafe unless we verified that create_string_variable always returns NULL if it detects an exception is generated, but if that were the case there would be no need to use the CHECK macro in the first place. We may find that we are returning a garbage value. Cheers, David Holmes From Christian.Thalinger at Sun.COM Wed Oct 7 03:35:30 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 07 Oct 2009 12:35:30 +0200 Subject: Improper usage of CHECK macros generates unreachable code In-Reply-To: <4ACC6B54.8040305@sun.com> References: <1254907181.20991.6.camel@macbook> <4ACC6B54.8040305@sun.com> Message-ID: <1254911730.20991.16.camel@macbook> On Wed, 2009-10-07 at 20:20 +1000, David Holmes - Sun Microsystems wrote: > I dont think it sufficient to simply replace CHECK with THREAD. The > problem is that the value being returned may be complete garbage. ie given: > > return create_string_variable(ns, name, 0, s, CHECK); > > the intent is to return NULL if create_string_variable triggers an > exception, but if we change this to: > > return create_string_variable(ns, name, 0, s, THREAD); > > we don't know what value will be returned without examining the > internals of create_string_variable. So the replacement would be unsafe > unless we verified that create_string_variable always returns NULL if it > detects an exception is generated, but if that were the case there would > be no need to use the CHECK macro in the first place. We may find that > we are returning a garbage value. That's true. But the current CHECK actually does what THREAD would do, given the macro expands to: static PerfStringVariable* create_string_variable(CounterNS ns, const char* name, const char *s, TRAPS) { return create_string_variable(ns, name, 0, s, THREAD); if (HAS_PENDING_EXCEPTION) return NULL; (0); }; I don't see how we would not return garbage here too. So we have to store the return value in temporary variable, as suggested by Volker. -- Christian From volker.simonis at gmail.com Wed Oct 7 08:45:19 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 7 Oct 2009 17:45:19 +0200 Subject: Improper usage of CHECK macros generates unreachable code In-Reply-To: <1254911730.20991.16.camel@macbook> References: <1254907181.20991.6.camel@macbook> <4ACC6B54.8040305@sun.com> <1254911730.20991.16.camel@macbook> Message-ID: On 10/7/09, Christian Thalinger wrote: > On Wed, 2009-10-07 at 20:20 +1000, David Holmes - Sun Microsystems > wrote: > > > I dont think it sufficient to simply replace CHECK with THREAD. The > > problem is that the value being returned may be complete garbage. ie given: > > > > return create_string_variable(ns, name, 0, s, CHECK); > > > > the intent is to return NULL if create_string_variable triggers an > > exception, but if we change this to: > > > > return create_string_variable(ns, name, 0, s, THREAD); > > > > we don't know what value will be returned without examining the > > internals of create_string_variable. So the replacement would be unsafe > > unless we verified that create_string_variable always returns NULL if it > > detects an exception is generated, but if that were the case there would > > be no need to use the CHECK macro in the first place. We may find that > > we are returning a garbage value. > > > That's true. But the current CHECK actually does what THREAD would do, > given the macro expands to: > > > static PerfStringVariable* create_string_variable(CounterNS ns, > const char* name, > const char *s, TRAPS) { > > return create_string_variable(ns, name, 0, s, THREAD); > > if (HAS_PENDING_EXCEPTION) return NULL; (0); > > }; > > I don't see how we would not return garbage here too. So we have to > store the return value in temporary variable, as suggested by Volker. > That's exactly my point. Changing CHECK to THREAD would just keep the current behaviour without the creation of unreachable code. If we want or need a more elaborate solution (and this was what I was actually asking in my first mail), we should store the result of a call which uses the check macro into a temporary variable and return that one. This will actually trigger the check in the CHECK macro as expected. My impression is that just replacing CHECK with THREAD would work because usually the caller of the method which does the call with the CHECK macro also checks for pending exception such that invalid return values do no harm. At least this is my only explanation for why this has not lead to any serious problems until now. But personally I would vote for the much cleaner solution with the temporary variable because it's not more overhead and there's still a small chance to catch some undiscovered errors. Regards, Volker > > -- Christian > > From Thomas.Rodriguez at Sun.COM Wed Oct 7 09:33:16 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 07 Oct 2009 09:33:16 -0700 Subject: Improper usage of CHECK macros generates unreachable code In-Reply-To: References: <1254907181.20991.6.camel@macbook> <4ACC6B54.8040305@sun.com> <1254911730.20991.16.camel@macbook> Message-ID: <54096A23-F0E8-473C-B2F6-B4C4B37A2D07@sun.com> > My impression is that just replacing CHECK with THREAD would work > because usually the caller of the method which does the call with the > CHECK macro also checks for pending exception such that invalid return > values do no harm. At least this is my only explanation for why this > has not lead to any serious problems until now. If all the places where this happens are for allocation then it's because they will always return null if an exception is thrown. I you're calling something that uses CHECK_NULL then the return value will already agree with HAS_PENDING_EXCEPTION. > But personally I would vote for the much cleaner solution with the > temporary variable because it's not more overhead and there's still a > small chance to catch some undiscovered errors. I believe this is the right solution as well. tom > > Regards, > Volker > >> >> -- Christian >> >> From Thomas.Rodriguez at Sun.COM Wed Oct 7 13:27:23 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 07 Oct 2009 13:27:23 -0700 Subject: Second Zero review request In-Reply-To: <20091007085042.GA10383@shell.devel.redhat.com> References: <20090924125631.GD3292@redhat.com> <7E60E07E-4162-4FFF-BA60-3D9DC1F5896C@sun.com> <20091007085042.GA10383@shell.devel.redhat.com> Message-ID: >> So I'm fine with the hotspot parts and assume others have no >> complaints since we haven't heard any. Have you gotten reviews of >> the other parts from their respective owners? > > No, but I haven't posted it anywhere but this list yet. I'm not 100% > familiar with how everything is organised, but I'm assuming your > approval goes for paths starting with "hotspot" and that other bits > need approving by others? > > I guess core-libs-dev is the list for the "jdk" makefiles. Is that > list the one for the "corba" makefile change too? Also, who owns the > top-level file make/hotspot-rules.gmk? I think Andrew might be right that build-dev might be the place to start. I believe Kelly essentially owns hotspot-rules.gmk. > > I'll roll a new webrev with the build directory changes before I post > anything, and copy it here. Since these changes largely affect hotspot we definitely want the hotspot part to go through JPRT but there really isn't any easy way to push both hotspot and jdk changes through at one time. Would you mind if we separated the hotspot and non-hotspot changes into different changesets to make the mechanics simpler? tom > > Cheers, > Gary > > -- > http://gbenson.net/ From Thomas.Rodriguez at Sun.COM Wed Oct 7 14:24:36 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 07 Oct 2009 14:24:36 -0700 Subject: review (XS) for 6889302: TraceExceptions output should include detail message Message-ID: http://cr.openjdk.java.net/~never/6889302 From John.Rose at Sun.COM Wed Oct 7 14:27:03 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 07 Oct 2009 14:27:03 -0700 Subject: review (XS) for 6889302: TraceExceptions output should include detail message In-Reply-To: References: Message-ID: <21B6C989-BDD1-42BA-8AB6-D9962253BF2B@sun.com> Looks good. -- John On Oct 7, 2009, at 2:24 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6889302 From Vladimir.Kozlov at Sun.COM Wed Oct 7 14:37:36 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 07 Oct 2009 14:37:36 -0700 Subject: review (XS) for 6889302: TraceExceptions output should include detail message In-Reply-To: References: Message-ID: <4ACD0A20.4090406@sun.com> Good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6889302 From David.Holmes at Sun.COM Wed Oct 7 17:02:40 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Thu, 08 Oct 2009 10:02:40 +1000 Subject: Improper usage of CHECK macros generates unreachable code In-Reply-To: <54096A23-F0E8-473C-B2F6-B4C4B37A2D07@sun.com> References: <1254907181.20991.6.camel@macbook> <4ACC6B54.8040305@sun.com> <1254911730.20991.16.camel@macbook> <54096A23-F0E8-473C-B2F6-B4C4B37A2D07@sun.com> Message-ID: <4ACD2C20.7060001@sun.com> Tom Rodriguez said the following on 10/08/09 02:33: >> My impression is that just replacing CHECK with THREAD would work >> because usually the caller of the method which does the call with the >> CHECK macro also checks for pending exception such that invalid return >> values do no harm. At least this is my only explanation for why this >> has not lead to any serious problems until now. > > If all the places where this happens are for allocation then it's > because they will always return null if an exception is thrown. I > you're calling something that uses CHECK_NULL then the return value will > already agree with HAS_PENDING_EXCEPTION. > >> But personally I would vote for the much cleaner solution with the >> temporary variable because it's not more overhead and there's still a >> small chance to catch some undiscovered errors. > > I believe this is the right solution as well. I third the motion for fixing this properly rather than just removing the compiler warning. It may be that some of the uses of CHECK are redundant anyway once you peek inside the method being CHECKed - and those can then be replaced by THREAD (or perhaps even elided completely). In some cases though it will be a thousand times faster to use the temporary result than to try to figure out if the check is needed - eg ObjectLocker::complete_exit :) David > tom > >> >> Regards, >> Volker >> >>> >>> -- Christian >>> >>> > From John.Rose at Sun.COM Wed Oct 7 21:23:24 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 07 Oct 2009 21:23:24 -0700 Subject: Improper usage of CHECK macros generates unreachable code In-Reply-To: References: <1254907181.20991.6.camel@macbook> <4ACC6B54.8040305@sun.com> <1254911730.20991.16.camel@macbook> Message-ID: <6AF8F79F-3E8F-4DB1-98AC-6C1E51FCC45F@sun.com> On Oct 7, 2009, at 8:45 AM, Volker Simonis wrote: > That's exactly my point. Changing CHECK to THREAD would just keep the > current behaviour without the creation of unreachable code. I've been doing this already, personally; look for "return.*THREAD" in files I've touched. This style allows compilers to emit tail calls. And allows humans to understand them that way. I think making a temporary variable here is often waste motion and noise. (Sometimes it clarifies things, especially if the variable has an informative name.) There's no issue of failing to catch the exception, since the caller is also required to poll for exceptions. > If we want or need a more elaborate solution (and this was what I was > actually asking in my first mail), we should store the result of a > call which uses the check macro into a temporary variable and return > that one. This will actually trigger the check in the CHECK macro as > expected. > > My impression is that just replacing CHECK with THREAD would work > because usually the caller of the method which does the call with the > CHECK macro also checks for pending exception such that invalid return > values do no harm. At least this is my only explanation for why this > has not lead to any serious problems until now. > > But personally I would vote for the much cleaner solution with the > temporary variable because it's not more overhead and there's still a > small chance to catch some undiscovered errors. I don't see useless variables and duplicated tests as producing cleanliness. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20091007/b197c848/attachment.html From David.Holmes at Sun.COM Wed Oct 7 21:31:32 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Thu, 08 Oct 2009 14:31:32 +1000 Subject: Improper usage of CHECK macros generates unreachable code In-Reply-To: <6AF8F79F-3E8F-4DB1-98AC-6C1E51FCC45F@sun.com> References: <1254907181.20991.6.camel@macbook> <4ACC6B54.8040305@sun.com> <1254911730.20991.16.camel@macbook> <6AF8F79F-3E8F-4DB1-98AC-6C1E51FCC45F@sun.com> Message-ID: <4ACD6B24.9060900@sun.com> Hi John, John Rose said the following on 10/08/09 14:23: > There's no issue of failing to catch the exception, since the caller is > also required to poll for exceptions. In that case use of CHECK was completely superfluous in the first place. If that is indeed always the case then changing to THREAD is fine as has been stated. >> But personally I would vote for the much cleaner solution with the >> temporary variable because it's not more overhead and there's still a >> small chance to catch some undiscovered errors. > > I don't see useless variables and duplicated tests as producing cleanliness. The assumption was that the functionality performed by CHECK was actually necessary, hence the variables would not be useless nor the test duplicated. Cheers, David From John.Rose at Sun.COM Wed Oct 7 22:01:11 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 07 Oct 2009 22:01:11 -0700 Subject: Improper usage of CHECK macros generates unreachable code In-Reply-To: <4ACD6B24.9060900@sun.com> References: <1254907181.20991.6.camel@macbook> <4ACC6B54.8040305@sun.com> <1254911730.20991.16.camel@macbook> <6AF8F79F-3E8F-4DB1-98AC-6C1E51FCC45F@sun.com> <4ACD6B24.9060900@sun.com> Message-ID: On Oct 7, 2009, at 9:31 PM, David Holmes - Sun Microsystems wrote: > The assumption was that the functionality performed by CHECK was > actually necessary, hence the variables would not be useless nor the > test duplicated. OK, I missed that. I was working from Volker's initial example, of create_string_variable, where the CHECK is not necessary, since it has the same TRAPS contract with its caller that its caller has with it. (That is, all callers of create_string_variable also use the CHECK macro, which contains a duplicable test.) Your example of ObjectSynchronizer::complete_exit is similar. In those cases, if the middle function uses CHECK, as well as the outer function, there is a duplicated test (for an exception posted to the thread object by the inner function). -- John From volker.simonis at gmail.com Thu Oct 8 01:11:51 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 8 Oct 2009 10:11:51 +0200 Subject: Improper usage of CHECK macros generates unreachable code In-Reply-To: References: <1254907181.20991.6.camel@macbook> <4ACC6B54.8040305@sun.com> <1254911730.20991.16.camel@macbook> <6AF8F79F-3E8F-4DB1-98AC-6C1E51FCC45F@sun.com> <4ACD6B24.9060900@sun.com> Message-ID: Ok, from this discussion I've learned that an automatic solution (i.e. a script which changes every CHECK macro in a return statement into either THREAD or introduces a temporary variable) is not the optimal way to go. Instead we should have a look at every single method which uses the check macro in a return statement: - if it only has callers which check for pending exceptions themselves we can safely replace CHECK with THREAD. This would eliminate the unreachable code and allow the compiler to emit tail calls. - if it has callers which don't check for pending exception, we should introduce a temporary variable. Is this ok? I'll start a changeset and post a webrev once I'm done. Regards, Volker On 10/8/09, John Rose wrote: > On Oct 7, 2009, at 9:31 PM, David Holmes - Sun Microsystems wrote: > > > > The assumption was that the functionality performed by CHECK was actually > necessary, hence the variables would not be useless nor the test duplicated. > > > > OK, I missed that. I was working from Volker's initial example, of > create_string_variable, where the CHECK is not necessary, since it has the > same TRAPS contract with its caller that its caller has with it. (That is, > all callers of create_string_variable also use the CHECK macro, which > contains a duplicable test.) Your example of > ObjectSynchronizer::complete_exit is similar. In those > cases, if the middle function uses CHECK, as well as the outer function, > there is a duplicated test (for an exception posted to the thread object by > the inner function). > > -- John > From Christian.Thalinger at Sun.COM Thu Oct 8 01:34:16 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 08 Oct 2009 10:34:16 +0200 Subject: review (XS) for 6889302: TraceExceptions output should include detail message In-Reply-To: References: Message-ID: <1254990856.1187.0.camel@macbook> On Wed, 2009-10-07 at 14:24 -0700, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6889302 That's a very good idea. -- Christian From Christian.Thalinger at Sun.COM Thu Oct 8 01:34:16 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 08 Oct 2009 10:34:16 +0200 Subject: review (XS) for 6889302: TraceExceptions output should include detail message In-Reply-To: References: Message-ID: <1254990856.1187.0.camel@macbook> On Wed, 2009-10-07 at 14:24 -0700, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6889302 That's a very good idea. -- Christian From gbenson at redhat.com Thu Oct 8 02:38:50 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 8 Oct 2009 10:38:50 +0100 Subject: Second Zero review request In-Reply-To: References: <20090924125631.GD3292@redhat.com> <7E60E07E-4162-4FFF-BA60-3D9DC1F5896C@sun.com> <20091007085042.GA10383@shell.devel.redhat.com> Message-ID: <20091008093850.GA11519@redhat.com> Tom Rodriguez wrote: > Gary Benson wrote: > > I guess core-libs-dev is the list for the "jdk" makefiles. Is > > that list the one for the "corba" makefile change too? Also, who > > owns the top-level file make/hotspot-rules.gmk? > > I think Andrew might be right that build-dev might be the place to > start. I believe Kelly essentially owns hotspot-rules.gmk. Ok. > > I'll roll a new webrev with the build directory changes before I > > post anything, and copy it here. > > Since these changes largely affect hotspot we definitely want the > hotspot part to go through JPRT but there really isn't any easy way > to push both hotspot and jdk changes through at one time. Would you > mind if we separated the hotspot and non-hotspot changes into > different changesets to make the mechanics simpler? No, that's simple enough, and it should make the review easier for the build-dev guys; that way they don't have to filter through a huge webrev. I'm just testing a couple of fixes I had to make as a result of the build directory change (and trying to replicate your test_gamma failure) and then I'll post them, by end of day Friday at the latest. Cheers, Gary PS what is JPRT? -- http://gbenson.net/ From gbenson at redhat.com Thu Oct 8 09:45:57 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 8 Oct 2009 17:45:57 +0100 Subject: Second Zero review request In-Reply-To: References: <20090924125631.GD3292@redhat.com> <7E60E07E-4162-4FFF-BA60-3D9DC1F5896C@sun.com> <20091007085042.GA10383@shell.devel.redhat.com> Message-ID: <20091008164556.GB11519@redhat.com> Tom Rodriguez wrote: > > I'll roll a new webrev with the build directory changes before I > > post anything, and copy it here. > > Since these changes largely affect hotspot we definitely want > the hotspot part to go through JPRT but there really isn't any > easy way to push both hotspot and jdk changes through at one time. > Would you mind if we separated the hotspot and non-hotspot changes > into different changesets to make the mechanics simpler? Ok, the HotSpot parts of the new webrev are here: http://cr.openjdk.java.net/~gbenson/zero-11-hotspot/ I had to make a couple of tweaks to get the build directory name change to work in the context of a full build (I'm guessing you did a build using only part of the OpenJDK tree?) but there shouldn't be anything surprising in there. I'm currently making a separate webrev with the other changes to mail to build-dev. I'm guessing the various repositories will require separate pushes. If you're ok with this HotSpot-only webrev do you think we should start the process of committing it now? I don't think there's anything in it that would break non-Zero builds if it was applied before the other parts (I'm checking this now...) Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Thu Oct 8 10:24:59 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 8 Oct 2009 18:24:59 +0100 Subject: Second Zero review request In-Reply-To: <20091008164556.GB11519@redhat.com> References: <20090924125631.GD3292@redhat.com> <7E60E07E-4162-4FFF-BA60-3D9DC1F5896C@sun.com> <20091007085042.GA10383@shell.devel.redhat.com> <20091008164556.GB11519@redhat.com> Message-ID: <20091008172459.GA980@redhat.com> Gary Benson wrote: > Ok, the HotSpot parts of the new webrev are here: > > http://cr.openjdk.java.net/~gbenson/zero-11-hotspot/ > [snip] > > I'm guessing the various repositories will require separate pushes. > If you're ok with this HotSpot-only webrev do you think we should > start the process of committing it now? I don't think there's > anything in it that would break non-Zero builds if it was applied > before the other parts (I'm checking this now...) I just did a full build with only the HotSpot webrev and it's fine. Cheers, Gary -- http://gbenson.net/ From Thomas.Rodriguez at Sun.COM Thu Oct 8 10:28:28 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 08 Oct 2009 10:28:28 -0700 Subject: Second Zero review request In-Reply-To: <20091008093850.GA11519@redhat.com> References: <20090924125631.GD3292@redhat.com> <7E60E07E-4162-4FFF-BA60-3D9DC1F5896C@sun.com> <20091007085042.GA10383@shell.devel.redhat.com> <20091008093850.GA11519@redhat.com> Message-ID: > No, that's simple enough, and it should make the review easier for > the build-dev guys; that way they don't have to filter through a huge > webrev. I'm just testing a couple of fixes I had to make as a result > of the build directory change (and trying to replicate your test_gamma > failure) and then I'll post them, by end of day Friday at the latest. Great. > > Cheers, > Gary > > PS what is JPRT? JPRT is our automated build/test setup and every hotspot push is required to go through it to ensure our repos always compile and work. The bits get built on all our supported platforms and runs around 450 tests before the changeset is pushed to a repo. The JDK teams also use it though I don't think they require it. Hotspot has been using JPRT since the switch to mercurial and before that we used PRT which was a hotspot only system created back in 2003. tom > > -- > http://gbenson.net/ From John.Rose at Sun.COM Thu Oct 8 10:37:03 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 08 Oct 2009 10:37:03 -0700 Subject: Improper usage of CHECK macros generates unreachable code In-Reply-To: References: <1254907181.20991.6.camel@macbook> <4ACC6B54.8040305@sun.com> <1254911730.20991.16.camel@macbook> <6AF8F79F-3E8F-4DB1-98AC-6C1E51FCC45F@sun.com> <4ACD6B24.9060900@sun.com> Message-ID: <5DFA451C-C6A8-4DF3-9206-A69A6BE123F7@Sun.COM> On Oct 8, 2009, at 1:11 AM, Volker Simonis wrote: > - if it only has callers which check for pending exceptions themselves > we can safely replace CHECK with THREAD. This would eliminate the > unreachable code and allow the compiler to emit tail calls. > - if it has callers which don't check for pending exception, we should > introduce a temporary variable. That's very good. I think you'll find that the second case is rare or even non-existent. -- John From Thomas.Rodriguez at Sun.COM Thu Oct 8 10:52:03 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 08 Oct 2009 10:52:03 -0700 Subject: Improper usage of CHECK macros generates unreachable code In-Reply-To: References: <1254907181.20991.6.camel@macbook> <4ACC6B54.8040305@sun.com> <1254911730.20991.16.camel@macbook> <6AF8F79F-3E8F-4DB1-98AC-6C1E51FCC45F@sun.com> <4ACD6B24.9060900@sun.com> Message-ID: <3EEBA5C3-C8AB-45A0-AFDD-93CCD05F4F94@sun.com> On Oct 8, 2009, at 1:11 AM, Volker Simonis wrote: > Ok, from this discussion I've learned that an automatic solution (i.e. > a script which changes every CHECK macro in a return statement into > either THREAD or introduces a temporary variable) is not the optimal > way to go. > > Instead we should have a look at every single method which uses the > check macro in a return statement: > - if it only has callers which check for pending exceptions themselves > we can safely replace CHECK with THREAD. This would eliminate the > unreachable code and allow the compiler to emit tail calls. > - if it has callers which don't check for pending exception, we should > introduce a temporary variable. > > Is this ok? This sounds good to me as well. tom > > I'll start a changeset and post a webrev once I'm done. > > Regards, > Volker > > On 10/8/09, John Rose wrote: >> On Oct 7, 2009, at 9:31 PM, David Holmes - Sun Microsystems wrote: >> >> >>> The assumption was that the functionality performed by CHECK was >>> actually >> necessary, hence the variables would not be useless nor the test >> duplicated. >>> >> >> OK, I missed that. I was working from Volker's initial example, of >> create_string_variable, where the CHECK is not necessary, since it >> has the >> same TRAPS contract with its caller that its caller has with it. >> (That is, >> all callers of create_string_variable also use the CHECK macro, which >> contains a duplicable test.) Your example of >> ObjectSynchronizer::complete_exit is similar. In those >> cases, if the middle function uses CHECK, as well as the outer >> function, >> there is a duplicated test (for an exception posted to the thread >> object by >> the inner function). >> >> -- John >> From gnu_andrew at member.fsf.org Thu Oct 8 13:24:40 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 8 Oct 2009 21:24:40 +0100 Subject: Second Zero review request In-Reply-To: References: <20090924125631.GD3292@redhat.com> <7E60E07E-4162-4FFF-BA60-3D9DC1F5896C@sun.com> <20091007085042.GA10383@shell.devel.redhat.com> <20091008093850.GA11519@redhat.com> Message-ID: <17c6771e0910081324g248ce991h283e5297182bf28a@mail.gmail.com> 2009/10/8 Tom Rodriguez : >> No, that's simple enough, and it should make the review easier for >> the build-dev guys; that way they don't have to filter through a huge >> webrev. ?I'm just testing a couple of fixes I had to make as a result >> of the build directory change (and trying to replicate your test_gamma >> failure) and then I'll post them, by end of day Friday at the latest. > > Great. > >> >> Cheers, >> Gary >> >> PS what is JPRT? > > JPRT is our automated build/test setup and every hotspot push is required to > go through it to ensure our repos always compile and work. ?The bits get > built on all our supported platforms and runs around 450 tests before the > changeset is pushed to a repo. ?The JDK teams also use it though I don't > think they require it. ?Hotspot has been using JPRT since the switch to > mercurial and before that we used PRT which was a hotspot only system > created back in 2003. > The JDK webrevs I've submitted have all been pushed manually by me. HotSpot is the only one where JPRT has been used, and even then it hasn't been done consistently (I've pushed at least one to hotspot-rt manually). Tom, from Gary's email it sounds like http://cr.openjdk.java.net/~gbenson/zero-11-hotspot/ could be submitted to JPRT now unless you have any further objections. > tom > >> >> -- >> http://gbenson.net/ > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From John.Coomes at sun.com Thu Oct 8 21:17:23 2009 From: John.Coomes at sun.com (John Coomes) Date: Thu, 8 Oct 2009 21:17:23 -0700 Subject: Second Zero review request In-Reply-To: <17c6771e0910081324g248ce991h283e5297182bf28a@mail.gmail.com> References: <20090924125631.GD3292@redhat.com> <7E60E07E-4162-4FFF-BA60-3D9DC1F5896C@sun.com> <20091007085042.GA10383@shell.devel.redhat.com> <20091008093850.GA11519@redhat.com> <17c6771e0910081324g248ce991h283e5297182bf28a@mail.gmail.com> Message-ID: <19150.47443.345414.992647@sun.com> Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: > ... > The JDK webrevs I've submitted have all been pushed manually by me. > HotSpot is the only one where JPRT has been used, and even then it > hasn't been done consistently (I've pushed at least one to hotspot-rt > manually). That slipped through, but shouldn't have. We've been extremely consistent about using JPRT for HotSpot; every push must use it, even trivial ones. It drastically improves the day-to-day reliability of the source. -John From ericjvandervelden at gmail.com Thu Oct 8 22:02:23 2009 From: ericjvandervelden at gmail.com (Eric J. Van der Velden) Date: Thu, 8 Oct 2009 22:02:23 -0700 (PDT) Subject: classloader Message-ID: <25815539.post@talk.nabble.com> Hi, Suppose X is a class type, and a class loader is created, ClassLoader l=... Thread.currentThread().setContextClassLoader(l) Object o=new X() Why is X not loaded by l, but still by the application class loader? Thanks. -- View this message in context: http://www.nabble.com/classloader-tp25815539p25815539.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From David.Holmes at Sun.COM Fri Oct 9 01:00:53 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Fri, 09 Oct 2009 18:00:53 +1000 Subject: classloader In-Reply-To: <25815539.post@talk.nabble.com> References: <25815539.post@talk.nabble.com> Message-ID: <4ACEEDB5.20503@sun.com> Hi Eric, Eric J. Van der Velden said the following on 10/09/09 15:02: > Suppose X is a class type, and a class loader is created, > > ClassLoader l=... > Thread.currentThread().setContextClassLoader(l) > Object o=new X() > > Why is X not loaded by l, but still by the application class loader? This is off-topic for this hotspot-dev mailing and would be better asked in one of the Java programming forums. But the simple answer is because the application class loader remains the current classloader for the current thread within the code that does "new X()". The context classloader is typically used by code that executes under the boot loader or extensions loader and which needs to load a type that can only be found by a classloader lower in the hierarchy - hence they will query for it and then use it to load a class by name eg: Class xClass = Thread.currentThread().getContextClassLoader().loadClass("X"); Hope this helps, but please don't post follow ups on the mailing list. David Holmes From gbenson at redhat.com Fri Oct 9 02:13:06 2009 From: gbenson at redhat.com (Gary Benson) Date: Fri, 9 Oct 2009 10:13:06 +0100 Subject: Second Zero review request In-Reply-To: <17c6771e0910081324g248ce991h283e5297182bf28a@mail.gmail.com> References: <20090924125631.GD3292@redhat.com> <7E60E07E-4162-4FFF-BA60-3D9DC1F5896C@sun.com> <20091007085042.GA10383@shell.devel.redhat.com> <20091008093850.GA11519@redhat.com> <17c6771e0910081324g248ce991h283e5297182bf28a@mail.gmail.com> Message-ID: <20091009091306.GA3506@redhat.com> Andrew John Hughes wrote: > Tom, from Gary's email it sounds like > http://cr.openjdk.java.net/~gbenson/zero-11-hotspot/ could be > submitted to JPRT now unless you have any further objections. Yes, it should be ready to go. Is there anything I need to do to make this happen? Cheers, Gary -- http://gbenson.net/ From Thomas.Rodriguez at Sun.COM Fri Oct 9 09:12:33 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 09 Oct 2009 09:12:33 -0700 Subject: Second Zero review request In-Reply-To: <20091009091306.GA3506@redhat.com> References: <20090924125631.GD3292@redhat.com> <7E60E07E-4162-4FFF-BA60-3D9DC1F5896C@sun.com> <20091007085042.GA10383@shell.devel.redhat.com> <20091008093850.GA11519@redhat.com> <17c6771e0910081324g248ce991h283e5297182bf28a@mail.gmail.com> <20091009091306.GA3506@redhat.com> Message-ID: <5B5964A8-D50F-458C-81CA-BB882A9CCC80@Sun.COM> I've got a workspace ready to go. There's no bug id for this already right? I'll create one and do the push to hotspot-comp today. tom On Oct 9, 2009, at 2:13 AM, Gary Benson wrote: > Andrew John Hughes wrote: >> Tom, from Gary's email it sounds like >> http://cr.openjdk.java.net/~gbenson/zero-11-hotspot/ could be >> submitted to JPRT now unless you have any further objections. > > Yes, it should be ready to go. > > Is there anything I need to do to make this happen? > > Cheers, > Gary > > -- > http://gbenson.net/ From gbenson at redhat.com Fri Oct 9 09:24:04 2009 From: gbenson at redhat.com (Gary Benson) Date: Fri, 9 Oct 2009 17:24:04 +0100 Subject: Second Zero review request In-Reply-To: <5B5964A8-D50F-458C-81CA-BB882A9CCC80@Sun.COM> References: <20090924125631.GD3292@redhat.com> <7E60E07E-4162-4FFF-BA60-3D9DC1F5896C@sun.com> <20091007085042.GA10383@shell.devel.redhat.com> <20091008093850.GA11519@redhat.com> <17c6771e0910081324g248ce991h283e5297182bf28a@mail.gmail.com> <20091009091306.GA3506@redhat.com> <5B5964A8-D50F-458C-81CA-BB882A9CCC80@Sun.COM> Message-ID: <20091009162404.GE3506@redhat.com> No, there's no existing bug id. Could you add my email address when you create it -- if that's possible -- so I can keep track of it? Thanks! Gary Tom Rodriguez wrote: > I've got a workspace ready to go. There's no bug id for this > already right? I'll create one and do the push to hotspot-comp > today. > > tom > > On Oct 9, 2009, at 2:13 AM, Gary Benson wrote: > > Andrew John Hughes wrote: > > > Tom, from Gary's email it sounds like > > > http://cr.openjdk.java.net/~gbenson/zero-11-hotspot/ could be > > > submitted to JPRT now unless you have any further objections. > > > > Yes, it should be ready to go. > > > > Is there anything I need to do to make this happen? > > > > Cheers, > > Gary > > > > -- > > http://gbenson.net/ From Thomas.Rodriguez at Sun.COM Fri Oct 9 16:19:49 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 09 Oct 2009 16:19:49 -0700 Subject: Second Zero review request In-Reply-To: <20091009162404.GE3506@redhat.com> References: <20090924125631.GD3292@redhat.com> <7E60E07E-4162-4FFF-BA60-3D9DC1F5896C@sun.com> <20091007085042.GA10383@shell.devel.redhat.com> <20091008093850.GA11519@redhat.com> <17c6771e0910081324g248ce991h283e5297182bf28a@mail.gmail.com> <20091009091306.GA3506@redhat.com> <5B5964A8-D50F-458C-81CA-BB882A9CCC80@Sun.COM> <20091009162404.GE3506@redhat.com> Message-ID: <983D9629-E622-4021-9B2B-D0AB8A55AEDE@Sun.COM> This is bug 6890308 and you are on the interest list so you should see updates to it. JPRT is slightly backed up on pushes but the zero changes should be through in the next day or so. tom On Oct 9, 2009, at 9:24 AM, Gary Benson wrote: > No, there's no existing bug id. Could you add my email address > when you create it -- if that's possible -- so I can keep track > of it? > > Thanks! > Gary > > Tom Rodriguez wrote: >> I've got a workspace ready to go. There's no bug id for this >> already right? I'll create one and do the push to hotspot-comp >> today. >> >> tom >> >> On Oct 9, 2009, at 2:13 AM, Gary Benson wrote: >>> Andrew John Hughes wrote: >>>> Tom, from Gary's email it sounds like >>>> http://cr.openjdk.java.net/~gbenson/zero-11-hotspot/ could be >>>> submitted to JPRT now unless you have any further objections. >>> >>> Yes, it should be ready to go. >>> >>> Is there anything I need to do to make this happen? >>> >>> Cheers, >>> Gary >>> >>> -- >>> http://gbenson.net/ From danhicks at ieee.org Sat Oct 10 12:25:27 2009 From: danhicks at ieee.org (Dan Hicks) Date: Sat, 10 Oct 2009 14:25:27 -0500 Subject: hotspot-dev Digest, Vol 30, Issue 10 In-Reply-To: References: Message-ID: <4AD0DFA7.1030506@ieee.org> I have been told that Java 7 JDK will include support for a new "invoke dynamic" opcode. Is there somewhere I can get info on this? And does anyone know if the Java language will be modified to use this opcode, or is it just for dynamic languages? -- Dan Hicks If the wind will not serve, take to the oars. --Latin proverb From Tim.Bell at Sun.COM Sat Oct 10 14:26:43 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Sat, 10 Oct 2009 14:26:43 -0700 Subject: hotspot-dev Digest, Vol 30, Issue 10 In-Reply-To: <4AD0DFA7.1030506@ieee.org> References: <4AD0DFA7.1030506@ieee.org> Message-ID: <4AD0FC13.7020806@sun.com> Hi Dan: It is the weekend here, and I am sure others will send more in follow up messages. I'll take a crack at it to get you started: > I have been told that Java 7 JDK will include support for a new "invoke > dynamic" opcode. Is there somewhere I can get info on this? People tend to sling around JSR numbers without the definition, so for those (like me :-) without a decoder ring, let me record that Invoke Dynamic is JSR-000292: "Supporting Dynamically Typed Languages on the JavaTM Platform" http://jcp.org/en/jsr/detail?id=292 The initial implementation is already there. If you want to get down and read the source, take a look at the first two listed here: 6829144: JSR 292 JVM features need a provisional Java API http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/d201987cb76c 6655646: dynamic languages need dynamically linked call sites http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/be93aad57795 For background, start with John Rose and "Notes on an Architecture for Dynamic Invocation" http://blogs.sun.com/jrose/entry/notes_on_an_architecture_for JSR 292 Cookbook talk at last year's JavaOne[TM] conference: http://cr.openjdk.java.net/~jrose/pres/200906-Cookbook.htm JVM Language Summit http://blogs.sun.com/jrose/entry/thursday_at_the_summit http://openjdk.java.net/projects/mlvm/jvmlangsummit/ > And does anyone know if the Java language will be modified to use this > opcode, or is it just for dynamic languages? As far as I know, mostly the latter. Having said that, there are a lot of ideas floating around in the community, so you never know... HTH- Tim From John.Coomes at sun.com Sat Oct 10 16:10:55 2009 From: John.Coomes at sun.com (John Coomes) Date: Sat, 10 Oct 2009 16:10:55 -0700 Subject: review review (S) 6888953 - missing semicolons Message-ID: <19153.5247.920251.668468@sun.com> 6888953: some calls to function-like macros are missing semicolons http://cr.openjdk.java.net/~jcoomes/6888953-semicolons/ Simple change to add missing semicolons after assert(), guarantee(), etc. -John From John.Coomes at sun.com Sat Oct 10 16:21:28 2009 From: John.Coomes at sun.com (John Coomes) Date: Sat, 10 Oct 2009 16:21:28 -0700 Subject: review request (M) 6888954 - arg formatting for assert Message-ID: <19153.5880.570192.216310@sun.com> 6888954: argument formatting for assert() and friends Enable argument formatting for assert(), guarantee() and related macros. http://cr.openjdk.java.net/~jcoomes/6888954-assert-args/ -John From Vladimir.Kozlov at Sun.COM Sun Oct 11 22:02:43 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Sun, 11 Oct 2009 22:02:43 -0700 Subject: review review (S) 6888953 - missing semicolons In-Reply-To: <19153.5247.920251.668468@sun.com> References: <19153.5247.920251.668468@sun.com> Message-ID: <4AD2B873.9030606@sun.com> Looks good. Vladimir John Coomes wrote: > 6888953: some calls to function-like macros are missing semicolons > > http://cr.openjdk.java.net/~jcoomes/6888953-semicolons/ > > Simple change to add missing semicolons after assert(), guarantee(), > etc. > > -John > From Vladimir.Kozlov at Sun.COM Mon Oct 12 00:20:01 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 12 Oct 2009 00:20:01 -0700 Subject: review request (M) 6888954 - arg formatting for assert In-Reply-To: <19153.5880.570192.216310@sun.com> References: <19153.5880.570192.216310@sun.com> Message-ID: <4AD2D8A1.5000601@sun.com> It looks good. In FormatBuffer class specify _buf[] first then copy constructor and then public constructor and operator. I don't think you need to break some long lines to two, especially for just one word, for example: - if (index != -1) fatal1("binary search bug: should have found entry %d", index); + assert(index == -1, err_msg("binary search should have found entry %d", + index)); Vladimir John Coomes wrote: > 6888954: argument formatting for assert() and friends > > Enable argument formatting for assert(), guarantee() and related > macros. > > http://cr.openjdk.java.net/~jcoomes/6888954-assert-args/ > > -John > From John.Coomes at sun.com Mon Oct 12 08:45:16 2009 From: John.Coomes at sun.com (John Coomes) Date: Mon, 12 Oct 2009 08:45:16 -0700 Subject: review review (S) 6888953 - missing semicolons In-Reply-To: <4AD2B873.9030606@sun.com> References: <19153.5247.920251.668468@sun.com> <4AD2B873.9030606@sun.com> Message-ID: <19155.20236.981677.224055@sun.com> Vladimir Kozlov (Vladimir.Kozlov at Sun.COM) wrote: > Looks good. Thanks! -John > John Coomes wrote: > > 6888953: some calls to function-like macros are missing semicolons > > > > http://cr.openjdk.java.net/~jcoomes/6888953-semicolons/ > > > > Simple change to add missing semicolons after assert(), guarantee(), > > etc. > > > > -John > > From Christian.Thalinger at Sun.COM Mon Oct 12 09:02:59 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 12 Oct 2009 18:02:59 +0200 Subject: review request (M) 6888954 - arg formatting for assert In-Reply-To: <19153.5880.570192.216310@sun.com> References: <19153.5880.570192.216310@sun.com> Message-ID: <1255363379.29170.13.camel@macbook> On Sat, 2009-10-10 at 16:21 -0700, John Coomes wrote: > 6888954: argument formatting for assert() and friends > > Enable argument formatting for assert(), guarantee() and related > macros. > > http://cr.openjdk.java.net/~jcoomes/6888954-assert-args/ Except the curly brace on an extra line: +class FormatBuffer +{ it looks good. Thanks for doing that change! -- Christian From Thomas.Rodriguez at Sun.COM Mon Oct 12 13:31:30 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 12 Oct 2009 13:31:30 -0700 Subject: review request (M) 6888954 - arg formatting for assert In-Reply-To: <19153.5880.570192.216310@sun.com> References: <19153.5880.570192.216310@sun.com> Message-ID: <69B30B11-C005-4B3F-9AA9-275EFFD9F605@sun.com> Can you explain the lifetime of the buffer returned by the const char* conversion? Offhand it doesn't seem safe to me. I'm don't think fatal(err_msg(a, b)) is an improvement over fatal1(a, b) but then I would have been fine with assert1 and friends. You could make fatal appear variadic with some other macro tricks. #define fatal \ begin_failure(__FILE__, __LINE__) && report_fatal report_fatal would expect to get file and line from some thread local buffer where it was cached by begin_failure. Alternatively you could have a stack allocated object with a report_fatal method and use dot instead of and. tom On Oct 10, 2009, at 4:21 PM, John Coomes wrote: > 6888954: argument formatting for assert() and friends > > Enable argument formatting for assert(), guarantee() and related > macros. > > http://cr.openjdk.java.net/~jcoomes/6888954-assert-args/ > > -John > From John.Coomes at sun.com Mon Oct 12 16:25:00 2009 From: John.Coomes at sun.com (John Coomes) Date: Mon, 12 Oct 2009 16:25:00 -0700 Subject: review request (M) 6888954 - arg formatting for assert In-Reply-To: <69B30B11-C005-4B3F-9AA9-275EFFD9F605@sun.com> References: <19153.5880.570192.216310@sun.com> <69B30B11-C005-4B3F-9AA9-275EFFD9F605@sun.com> Message-ID: <19155.47820.983546.345181@sun.com> Tom Rodriguez (Thomas.Rodriguez at Sun.COM) wrote: > Can you explain the lifetime of the buffer returned by the const char* > conversion? Offhand it doesn't seem safe to me. The temporary object created by err_msg() is destroyed at the end of evaluation of the full expression that contains it. In this case, the containing full expression is the call to report_vm_error(), so the buffer is live until report_vm_error() completes. > I'm don't think fatal(err_msg(a, b)) is an improvement over fatal1(a, > b) but then I would have been fine with assert1 and friends. ... I'd rather not count arguments. If it were just fatal1, I might live with it. But when you get to fatal4, fatal5, ..., and then multiply that by guarantee and assert, there should be something better. > ... You > could make fatal appear variadic with some other macro tricks. > > #define fatal \ > begin_failure(__FILE__, __LINE__) && report_fatal > > report_fatal would expect to get file and line from some thread local > buffer where it was cached by begin_failure. Alternatively you could > have a stack allocated object with a report_fatal method and use dot > instead of and. The syntax at the use point is better. Of the two, I like the latter as it's more localized. Both would treat the current string literals as format strings, which would require auditing; the gcc __attribute__((format)) mechanism (suggested by Ian Rogers) would help for shared and linux-specific code. Also, using a normal macro instead of a function-like macro would replace non-function-like uses: $ cat x.cc #define fatal(a) printf(a) #define fatalx printf int main(int argc, char **argv) { int fatal = 0; int fatalx = 0; return 0; } $ CC -E x.cc int main ( int argc , char * * argv ) { int fatal = 0 ; int printf = 0 ; return 0 ; } So it would prohibit variables and fields named assert, fatal, guarantee, etc. We could probably live with it, but it's worth pointing out. Other opinions? -John > On Oct 10, 2009, at 4:21 PM, John Coomes wrote: > > > 6888954: argument formatting for assert() and friends > > > > Enable argument formatting for assert(), guarantee() and related > > macros. > > > > http://cr.openjdk.java.net/~jcoomes/6888954-assert-args/ > > > > -John > > > From John.Coomes at sun.com Tue Oct 13 14:52:59 2009 From: John.Coomes at sun.com (John Coomes) Date: Tue, 13 Oct 2009 14:52:59 -0700 Subject: review request (M) 6888954 - arg formatting for assert In-Reply-To: <19155.47820.983546.345181@sun.com> References: <19153.5880.570192.216310@sun.com> <69B30B11-C005-4B3F-9AA9-275EFFD9F605@sun.com> <19155.47820.983546.345181@sun.com> Message-ID: <19156.63163.396909.851139@sun.com> I (John.Coomes at Sun.COM) wrote: > Tom Rodriguez (Thomas.Rodriguez at Sun.COM) wrote: > ... > > I'm don't think fatal(err_msg(a, b)) is an improvement over fatal1(a, > > b) but then I would have been fine with assert1 and friends. ... > > I'd rather not count arguments. If it were just fatal1, I might live > with it. But when you get to fatal4, fatal5, ..., and then multiply > that by guarantee and assert, there should be something better. > > > ... You > > could make fatal appear variadic with some other macro tricks. > > > > #define fatal \ > > begin_failure(__FILE__, __LINE__) && report_fatal > > > > report_fatal would expect to get file and line from some thread local > > buffer where it was cached by begin_failure. Alternatively you could > > have a stack allocated object with a report_fatal method and use dot > > instead of and. > > The syntax at the use point is better. Of the two, I like the latter > as it's more localized. > > Both would treat the current string literals as format strings, which > would require auditing; the gcc __attribute__((format)) mechanism > (suggested by Ian Rogers) would help for shared and linux-specific > code. Also, using a normal macro instead of a function-like macro > would replace non-function-like uses: > > $ cat x.cc > #define fatal(a) printf(a) > #define fatalx printf > int main(int argc, char **argv) { int fatal = 0; int fatalx = 0; return 0; } > $ CC -E x.cc > int main ( int argc , char * * argv ) { int fatal = 0 ; int printf = 0 ; return 0 ; } > > So it would prohibit variables and fields named assert, fatal, > guarantee, etc. We could probably live with it, but it's worth > pointing out. Scratch the assert and guarantee from the above paragraph. The suggestion would only work with fatal, which doesn't have a condition to evaluate. I'm not too fond of the assymetry. I could just add #define fatal1(p, msg, arg) fatal(p, err_msg(msg, arg)) to the proposed changes. Then you can choose which style you want to use: numbered macro or err_msg(). -John > > On Oct 10, 2009, at 4:21 PM, John Coomes wrote: > > > > > 6888954: argument formatting for assert() and friends > > > > > > Enable argument formatting for assert(), guarantee() and related > > > macros. > > > > > > http://cr.openjdk.java.net/~jcoomes/6888954-assert-args/ > > > > > > -John > > > > > > From Thomas.Rodriguez at Sun.COM Tue Oct 13 15:18:47 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 13 Oct 2009 15:18:47 -0700 Subject: review request (M) 6888954 - arg formatting for assert In-Reply-To: <19156.63163.396909.851139@sun.com> References: <19153.5880.570192.216310@sun.com> <69B30B11-C005-4B3F-9AA9-275EFFD9F605@sun.com> <19155.47820.983546.345181@sun.com> <19156.63163.396909.851139@sun.com> Message-ID: > Scratch the assert and guarantee from the above paragraph. The > suggestion would only work with fatal, which doesn't have a condition > to evaluate. I'm not too fond of the assymetry. > > I could just add > > #define fatal1(p, msg, arg) fatal(p, err_msg(msg, arg)) > > to the proposed changes. Then you can choose which style you want to > use: numbered macro or err_msg(). None of these are very attractive and no one else seems to mind so just stick with what you had. tom > > -John > >>> On Oct 10, 2009, at 4:21 PM, John Coomes wrote: >>> >>>> 6888954: argument formatting for assert() and friends >>>> >>>> Enable argument formatting for assert(), guarantee() and related >>>> macros. >>>> >>>> http://cr.openjdk.java.net/~jcoomes/6888954-assert-args/ >>>> >>>> -John >>>> >>> >> > From erik.trimble at sun.com Tue Oct 13 16:32:25 2009 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Tue, 13 Oct 2009 23:32:25 +0000 Subject: hg: jdk7/hotspot/hotspot: 9 new changesets Message-ID: <20091013233245.31F874144F@hg.openjdk.java.net> Changeset: 6e6427f797c0 Author: xdono Date: 2009-09-03 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6e6427f797c0 Added tag jdk7-b71 for changeset 50a95aa4a247 ! .hgtags Changeset: a94714c55065 Author: trims Date: 2009-09-15 20:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a94714c55065 Merge Changeset: 1e5f0e56d242 Author: xdono Date: 2009-09-17 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1e5f0e56d242 Added tag jdk7-b72 for changeset a94714c55065 ! .hgtags Changeset: 89e0543e1737 Author: xdono Date: 2009-09-22 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/89e0543e1737 6884624: Update copyright year Summary: Update copyright for files that have been modified in 2009 through Septermber Reviewed-by: tbell, ohair ! agent/make/saenv.sh ! agent/make/saenv64.sh ! agent/src/os/solaris/proc/Makefile ! agent/src/os/solaris/proc/mapfile ! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java ! agent/src/share/classes/sun/jvm/hotspot/memory/FreeChunk.java ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp ! src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/code/debugInfoRec.hpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/compiler/oopMap.hpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.cpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/serialize.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/oops/objArrayOop.hpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/atomic.hpp ! src/share/vm/runtime/perfData.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/vframeArray.hpp ! src/share/vm/runtime/vframe_hp.hpp ! src/share/vm/services/threadService.cpp ! src/share/vm/services/threadService.hpp Changeset: 7a102acc9f17 Author: trims Date: 2009-09-25 12:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7a102acc9f17 Merge ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/prims/jvm.h Changeset: faf94d94786b Author: trims Date: 2009-09-25 12:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/faf94d94786b 6885900: Bump the HS17 build number to 02 Summary: Update the HS17 build number to 02 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 6ddec5389232 Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6ddec5389232 Added tag jdk7-b73 for changeset faf94d94786b ! .hgtags Changeset: a1423fe86a18 Author: trims Date: 2009-10-09 15:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a1423fe86a18 Merge ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/runtime/sweeper.cpp Changeset: f4b900403d6e Author: trims Date: 2009-10-09 15:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f4b900403d6e 6890293: Bump the HS17 build number to 03 Summary: Update the HS17 build number to 03 Reviewed-by: jcoomes ! make/hotspot_version From xiaobin.lu at sun.com Wed Oct 14 17:09:21 2009 From: xiaobin.lu at sun.com (xiaobin.lu at sun.com) Date: Thu, 15 Oct 2009 00:09:21 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20091015000931.10ECD41642@hg.openjdk.java.net> Changeset: 528d98fe1037 Author: xlu Date: 2009-09-24 12:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/528d98fe1037 6880029: JDK 1.6.0_u14p Application crashed very early Reviewed-by: never, ysr, acorn ! src/share/vm/runtime/safepoint.cpp Changeset: 054afbef9081 Author: acorn Date: 2009-09-28 12:27 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/054afbef9081 Merge Changeset: a2ad635573fb Author: xlu Date: 2009-10-14 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a2ad635573fb Merge From John.Rose at Sun.COM Thu Oct 15 11:48:09 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 15 Oct 2009 11:48:09 -0700 Subject: upcoming coordinated pushes; pre-integration testing In-Reply-To: References: Message-ID: <61BDC3E2-7E41-47E0-B800-123EBCA13B16@sun.com> [Reposted to a wider audience. See original message at http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2009-October/002003.html ] Two "interesting" changes (as in "we live in interesting times") are coming soon to our JDK7 workflow in the Hotspot team, and specifically in the hotspot-comp repository. Here is a heads-up. 1. Christian and I are going to push some coordinated changes for JSR 292 to hotspot-comp, which will then flow up through hotspot into JDK7. The changes are coordinated because they affect both jdk and hotspot sub-repositories, and must be pushed together. They involve changes to the JSR 292 API and the JVM, which have to be packaged together. These changes will have to be pushed together by the gatekeeper at the hotspot-comp level and at the parent level (the integration repo.). 2. These changes will come with new regression tests, in hotspot-comp/ jdk/test/java/dyn/. These regression tests will be packaged as JUnit 4.5 tests. In order to run them, I've enhanced jtreg (with Mark and Jon G's help) to accept such tests. (I suspect having a jtreg to JUnit bridge will make other people happy too.) If you use jtreg to run regression tests, the JUnit-based tests in jdk/ test/java/dyn will fail unless you upgrade jtreg. We are working on this change, which is tracked under bug 6891715 and may be inspected here: http://cr.openjdk.java.net/~jrose/6891715/webrev.00/ . If you need a provisional binary, you can find one at http://hg.openjdk.java.net/mlvm/mlvm/file/tip/jtreg/ . Follow the instructions to drop junit.jar into the jtreg installation. The first step will consist of a "trial balloon" in which I will push a single JUnit test file to jdk, which performs a warm-and-breathing test on the API which is currently in the JDK7 builds (the JavaOne Preview version). Stay tuned for a review request. -- John From John.Rose at Sun.COM Thu Oct 15 11:52:59 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 15 Oct 2009 11:52:59 -0700 Subject: review (S) for 6891770: JSR 292 API needs initial unit tests In-Reply-To: References: Message-ID: <8B93B466-8DB7-4DCE-A80D-FD58C081323C@sun.com> [Reposted to a wider audience. See original message at http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2009-October/002005.html ] Here is the first JUnit-based test for JSR 292: http://cr.openjdk.java.net/~jrose/6891770/webrev.00 I have marked this review as small (S) because there is little or no need to look at the details of the unit test, as an API test. (Although you may if you like!) The important thing is the "@test" comment which links it into the jtreg regression suite in the JDK. The test is a backport of the corresponding test 'MethodHandlesTest.java' in the following mlvm patch: http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/indy.tests.patch To backport it for the present purpose, I simply removed test cases that do not pass on the JDK7 M3 version of the JSR 292 RI, which is what is in the JDK7 repo. at this moment. (There is more to come soon!) This unit test passes fully, both the full version in the mlvm patch repo (running on a JDK7 with those patches), and the abbreviated version (running on the present unpatched JDK7). This test is known to work on i386 platforms. It automatically senses other platforms and excludes itself. See the method named 'checkImplementedPlatform'. (There are tracking bugs filed for JSR 292 on those platforms.) In order to successfully run this unit test, jtreg must be upgraded (to 4.1, including JUnit support). This means that some nightly and pre-integration jtreg runs are likely to show this new test failing, in an uninteresting way. I have verified that this happens in a clean way with jtreg 4.0, and that the other unit tests will run correctly. The error looks like this: test result: Error. Bad action for script: junit The new test may appear to fail in nightly and pre-integration testing, until the upgraded test harness is accepted and installed by SQE. (It is not clear whether this will happen, because the selection of tests might not include java.dyn.) Independently of this push, I am working with them on the appropriate upgrades and test inclusions. -- John From john.coomes at sun.com Fri Oct 16 01:42:45 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 16 Oct 2009 08:42:45 +0000 Subject: hg: jdk7/hotspot: 7 new changesets Message-ID: <20091016084245.255FF41880@hg.openjdk.java.net> Changeset: e76b72562a98 Author: ohair Date: 2009-09-03 17:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/e76b72562a98 6855174: Improve log output when builds transition from one workspace to another Reviewed-by: jjg ! make/Defs-internal.gmk ! make/corba-rules.gmk ! make/deploy-rules.gmk ! make/hotspot-rules.gmk ! make/install-rules.gmk ! make/jaxp-rules.gmk ! make/jaxws-rules.gmk ! make/jdk-rules.gmk ! make/langtools-rules.gmk ! make/sponsors-rules.gmk Changeset: 931f7f7501da Author: ohair Date: 2009-09-17 13:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/931f7f7501da Merge Changeset: 76f6380ac0b4 Author: xdono Date: 2009-09-18 09:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/76f6380ac0b4 Merge Changeset: d70b157f6407 Author: xdono Date: 2009-09-22 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/d70b157f6407 6884624: Update copyright year Summary: Update copyright for files that have been modified in 2009 through Septermber Reviewed-by: tbell, ohair ! make/corba-rules.gmk ! make/hotspot-rules.gmk ! make/install-rules.gmk ! make/jaxp-rules.gmk ! make/jaxws-rules.gmk ! make/langtools-rules.gmk ! make/sponsors-rules.gmk Changeset: 3ac6dcf78232 Author: robilad Date: 2009-09-23 20:06 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/3ac6dcf78232 6872735: Further update build readme for new platforms 6641691: Bring build readme's up-to-date Summary: Added build instructions for Debian, Ubuntu 8.04, 8.10, 9.04, Fedora 10, 11, OpenSolaris 2009.06, OpenSUSE and Mandriva Reviewed-by: ohair, andrew ! README-builds.html Changeset: 2c88089b6e1c Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/2c88089b6e1c Added tag jdk7-b73 for changeset 3ac6dcf78232 ! .hgtags Changeset: d1516b9f2395 Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/d1516b9f2395 Added tag jdk7-b74 for changeset 2c88089b6e1c ! .hgtags From john.coomes at sun.com Fri Oct 16 01:42:49 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 16 Oct 2009 08:42:49 +0000 Subject: hg: jdk7/hotspot/corba: 8 new changesets Message-ID: <20091016084258.82DC641881@hg.openjdk.java.net> Changeset: 1c130e7b7a2e Author: ohair Date: 2009-09-02 09:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/1c130e7b7a2e 6875240: Reduce Makefile build time by limiting repeated exec's (mostly for cygwin building) Reviewed-by: jjg, iris ! make/Makefile ! make/common/BuildToolJar.gmk ! make/common/CancelImplicits.gmk ! make/common/Defs.gmk ! make/common/Rules.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Platform.gmk ! make/jprt.properties Changeset: 085333867e39 Author: xdono Date: 2009-09-14 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/085333867e39 Merge Changeset: 546970b224ca Author: xdono Date: 2009-09-18 09:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/546970b224ca Merge Changeset: 31ce3cac3cc1 Author: ohair Date: 2009-09-18 16:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/31ce3cac3cc1 6883790: corba build problem related to wildcard and vpath, regression Reviewed-by: tbell ! make/common/Rules.gmk Changeset: 2aa5665d86a5 Author: ohair Date: 2009-09-18 17:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/2aa5665d86a5 6883816: corba fix for missing javax/transaction/xa classes (the real fix) Reviewed-by: tbell ! make/common/Rules.gmk Changeset: b751c528c555 Author: xdono Date: 2009-09-22 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/b751c528c555 6884624: Update copyright year Summary: Update copyright for files that have been modified in 2009 through Septermber Reviewed-by: tbell, ohair ! make/common/CancelImplicits.gmk Changeset: 5d0cf59a3203 Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/5d0cf59a3203 Added tag jdk7-b73 for changeset b751c528c555 ! .hgtags Changeset: 0fb137085952 Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/0fb137085952 Added tag jdk7-b74 for changeset 5d0cf59a3203 ! .hgtags From john.coomes at sun.com Fri Oct 16 01:46:08 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 16 Oct 2009 08:46:08 +0000 Subject: hg: jdk7/hotspot/jaxp: 6 new changesets Message-ID: <20091016084620.2BBD541883@hg.openjdk.java.net> Changeset: 534e23823a1b Author: ohair Date: 2009-09-21 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/534e23823a1b 6856630: Restructure jaxp/jaxws repositories Reviewed-by: darcy, tbell ! .hgignore ! README + build-defs.xml + build-drop-template.xml + build.properties + build.xml + jaxp.properties ! make/Makefile - make/build.properties - make/build.xml ! make/jprt.properties - make/tools/StripProperties/StripProperties.java - make/tools/StripProperties/StripPropertiesTask.java + nbproject/findbugs.settings + nbproject/project.xml + nbproject/sqe.properties + patches/jaxp_src/README Changeset: 0748962aa825 Author: ohair Date: 2009-09-21 17:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/0748962aa825 6884220: Have drop sources ignore the output.dir property Reviewed-by: xdono ! build.properties Changeset: ee9c7578aca5 Author: xdono Date: 2009-09-22 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/ee9c7578aca5 6884624: Update copyright year Summary: Update copyright for files that have been modified in 2009 through Septermber Reviewed-by: tbell, ohair ! src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLScanner.java Changeset: feb05980f9f2 Author: ohair Date: 2009-09-28 19:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/feb05980f9f2 6886359: Missing jaxws property files and missing changes in jaxp/jaxws drop bundles Reviewed-by: jjg, tbell ! build-defs.xml ! jaxp.properties Changeset: ea7b88c676dd Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/ea7b88c676dd Added tag jdk7-b73 for changeset feb05980f9f2 ! .hgtags Changeset: 555fb78ee4ce Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/555fb78ee4ce Added tag jdk7-b74 for changeset ea7b88c676dd ! .hgtags From john.coomes at sun.com Fri Oct 16 01:46:25 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 16 Oct 2009 08:46:25 +0000 Subject: hg: jdk7/hotspot/jaxws: 5 new changesets Message-ID: <20091016084634.8C0E041884@hg.openjdk.java.net> Changeset: ae2bec597586 Author: ohair Date: 2009-09-21 13:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/ae2bec597586 6856630: Restructure jaxp/jaxws repositories Reviewed-by: darcy, tbell ! .hgignore ! README + build-defs.xml + build-drop-template.xml + build.properties + build.xml + jaxws.properties ! make/Makefile - make/build.properties - make/build.xml ! make/jprt.properties - make/tools/StripProperties/StripProperties.java - make/tools/StripProperties/StripPropertiesTask.java + nbproject/findbugs.settings + nbproject/project.xml + nbproject/sqe.properties + patches/jaxws_src/README Changeset: 77708e68db52 Author: ohair Date: 2009-09-21 17:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/77708e68db52 6884220: Have drop sources ignore the output.dir property Reviewed-by: xdono ! build.properties Changeset: 558985e26fe1 Author: ohair Date: 2009-09-28 19:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/558985e26fe1 6886359: Missing jaxws property files and missing changes in jaxp/jaxws drop bundles Reviewed-by: jjg, tbell ! build-defs.xml ! jaxws.properties Changeset: f4466e1b6080 Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/f4466e1b6080 Added tag jdk7-b73 for changeset 558985e26fe1 ! .hgtags Changeset: fcf2b8b5d606 Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/fcf2b8b5d606 Added tag jdk7-b74 for changeset f4466e1b6080 ! .hgtags From john.coomes at sun.com Fri Oct 16 01:49:59 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 16 Oct 2009 08:49:59 +0000 Subject: hg: jdk7/hotspot/jdk: 101 new changesets Message-ID: <20091016091147.6C25E4188C@hg.openjdk.java.net> Changeset: fdf11ce72e8e Author: mchung Date: 2009-08-06 11:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/fdf11ce72e8e 4917309: (cl) Reduce internal usage of ClassNotFoundExceptions during class-loading Summary: Change findBootstrapClass to return null instead of throwing CNFE if class not found Reviewed-by: alanb, dholmes, iris ! src/share/classes/java/lang/ClassLoader.java ! src/share/javavm/export/jvm.h ! src/share/native/java/lang/ClassLoader.c Changeset: 3323e6c925f9 Author: mchung Date: 2009-08-06 16:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3323e6c925f9 6864028: Update the java launcher to use the new entry point JVM_FindClassFromBootLoader Summary: Update the java launcher to use the new entry point JVM_FindClassFromBootLoader Reviewed-by: ksrini ! src/share/bin/java.h ! src/solaris/bin/java_md.c ! src/windows/bin/java_md.c Changeset: 1f1c824e6244 Author: mchung Date: 2009-08-24 10:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1f1c824e6244 Merge - src/share/classes/com/sun/crypto/provider/JarVerifier.java - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java - src/share/classes/sun/nio/ch/AbstractFuture.java - src/share/classes/sun/security/pkcs11/JarVerifier.java - src/windows/classes/sun/security/mscapi/JarVerifier.java Changeset: 799731b1cd03 Author: mchung Date: 2009-08-27 12:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/799731b1cd03 Merge - src/share/native/java/util/zip/zlib-1.1.3/ChangeLog - src/share/native/java/util/zip/zlib-1.1.3/README - src/share/native/java/util/zip/zlib-1.1.3/compress.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.h - src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc - src/share/native/java/util/zip/zlib-1.1.3/example.c - src/share/native/java/util/zip/zlib-1.1.3/gzio.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.h - src/share/native/java/util/zip/zlib-1.1.3/infcodes.c - src/share/native/java/util/zip/zlib-1.1.3/infcodes.h - src/share/native/java/util/zip/zlib-1.1.3/inffast.c - src/share/native/java/util/zip/zlib-1.1.3/inffast.h - src/share/native/java/util/zip/zlib-1.1.3/inffixed.h - src/share/native/java/util/zip/zlib-1.1.3/inflate.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.h - src/share/native/java/util/zip/zlib-1.1.3/infutil.c - src/share/native/java/util/zip/zlib-1.1.3/infutil.h - src/share/native/java/util/zip/zlib-1.1.3/minigzip.c - src/share/native/java/util/zip/zlib-1.1.3/trees.c - src/share/native/java/util/zip/zlib-1.1.3/trees.h - src/share/native/java/util/zip/zlib-1.1.3/uncompr.c - src/share/native/java/util/zip/zlib-1.1.3/zadler32.c - src/share/native/java/util/zip/zlib-1.1.3/zconf.h - src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.1.3/zlib.h - src/share/native/java/util/zip/zlib-1.1.3/zutil.c - src/share/native/java/util/zip/zlib-1.1.3/zutil.h - test/java/util/concurrent/LinkedBlockingQueue/LastElement.java - test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: dfb5cf81d8cd Author: mchung Date: 2009-09-03 16:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/dfb5cf81d8cd Merge Changeset: b9b7f56bdfa3 Author: mchung Date: 2009-09-04 15:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b9b7f56bdfa3 Merge Changeset: 466915134131 Author: mchung Date: 2009-09-08 12:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/466915134131 Merge Changeset: 0d50d40a4a39 Author: martin Date: 2009-09-08 14:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0d50d40a4a39 6850958: Honor -XX:OnOutOfMemoryError when array size exceeds VM limit Summary: Test hotspot/jvmti fix 6850957 using ProcessBuilder test infrastructure Reviewed-by: tbell, dholmes, alanb, ysr ! test/java/lang/ProcessBuilder/Basic.java Changeset: 8252729d51a3 Author: mullan Date: 2009-09-09 09:54 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8252729d51a3 6745437: Add option to only check revocation of end-entity certificate in a chain of certificates 6869739: Cannot check revocation of single certificate without validating the entire chain Reviewed-by: xuelei + src/share/classes/sun/security/action/GetBooleanSecurityPropertyAction.java ! src/share/classes/sun/security/provider/certpath/Builder.java ! src/share/classes/sun/security/provider/certpath/CertId.java ! src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java + src/share/classes/sun/security/provider/certpath/OCSP.java ! src/share/classes/sun/security/provider/certpath/OCSPChecker.java ! src/share/classes/sun/security/provider/certpath/OCSPRequest.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java ! src/share/classes/sun/security/x509/AccessDescription.java Changeset: 7b85ef3d752e Author: mullan Date: 2009-09-09 09:59 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7b85ef3d752e Merge Changeset: f1eb4c28b313 Author: lancea Date: 2009-09-09 20:15 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f1eb4c28b313 6737212: Fixed javadoc warning messages in RowSet classes Reviewed-by: darcy ! src/share/classes/com/sun/rowset/JdbcRowSetResourceBundle.java ! src/share/classes/com/sun/rowset/JoinRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/WebRowSetXmlReader.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java Changeset: 46406871599c Author: sherman Date: 2009-09-11 16:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/46406871599c 6881337: ZipEntry.setComment() was accidentally changed back to old spec/impl in jdk7-b64 Summary: restored the correct spec and implementation of setComment Reviewed-by: martin ! src/share/classes/java/util/zip/ZipEntry.java Changeset: 020a0fed38c9 Author: martin Date: 2009-09-12 15:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/020a0fed38c9 6881442: (reflect) Race condition in Class.getName() Summary: only read "name" field racily once Reviewed-by: darcy ! src/share/classes/java/lang/Class.java Changeset: 060c4c7082ef Author: alanb Date: 2009-09-14 15:29 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/060c4c7082ef 6529758: JVMTI Waiters demo crashes. Double free. Reviewed-by: ohair, tbell ! src/share/demo/jvmti/waiters/Agent.cpp ! src/share/demo/jvmti/waiters/Agent.hpp ! src/share/demo/jvmti/waiters/Monitor.cpp ! src/share/demo/jvmti/waiters/Monitor.hpp Changeset: aac01ec2cec4 Author: alanb Date: 2009-09-14 17:47 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/aac01ec2cec4 6876541: (file) Files.walkFileTree(...): no SecurityException if read access to the starting file is denied Reviewed-by: chegar ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/Files.java + test/java/nio/file/Files/WalkWithSecurity.java + test/java/nio/file/Files/denyAll.policy + test/java/nio/file/Files/grantAll.policy + test/java/nio/file/Files/grantTopOnly.policy Changeset: eb19c5dc52bf Author: kevinw Date: 2009-09-14 20:55 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/eb19c5dc52bf 6842838: 64-bit failure in handling invalid manifest in launcher. Summary: Don't compare with hard-coded 32-bit -1 when checking zip fields. Reviewed-by: ksrini ! src/share/bin/parse_manifest.c + test/tools/launcher/6842838/CreateBadJar.java + test/tools/launcher/6842838/Test6842838.sh Changeset: c7e469ae3edb Author: mchung Date: 2009-09-14 13:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c7e469ae3edb 6878481: Add performance counters in the JDK Summary: Added new performance counters in the JDK to track performance metrics Reviewed-by: alanb, dholmes, iris, forax, andrew ! make/java/java/FILES_java.gmk ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/net/URLClassLoader.java ! src/share/classes/java/util/zip/ZipFile.java + src/share/classes/sun/misc/PerfCounter.java ! src/windows/classes/sun/java2d/d3d/D3DGraphicsDevice.java Changeset: 0a3244fe7142 Author: mchung Date: 2009-09-14 13:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0a3244fe7142 Merge Changeset: f0182203084a Author: dcubed Date: 2009-09-14 18:45 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f0182203084a 6862295: JDWP threadid changes during debugging session (leading to ingored breakpoints) Summary: New test for the above fix. Reviewed-by: tbell + test/com/sun/jdi/BreakpointWithFullGC.sh Changeset: f78b7d9973b7 Author: dcubed Date: 2009-09-14 18:54 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f78b7d9973b7 Merge Changeset: e8c2dd4b8bac Author: dcubed Date: 2009-09-15 22:11 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e8c2dd4b8bac 6882363: 4/4 typos in java.util.logging javadocs Summary: Fix typos, some grammar and some inconsistencies in phrasing. Reviewed-by: tbell ! src/share/classes/java/util/logging/ErrorManager.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/Formatter.java ! src/share/classes/java/util/logging/Handler.java ! src/share/classes/java/util/logging/Level.java ! src/share/classes/java/util/logging/LogRecord.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/LoggingMXBean.java ! src/share/classes/java/util/logging/MemoryHandler.java ! src/share/classes/java/util/logging/StreamHandler.java Changeset: 81b85ea694f8 Author: tbell Date: 2009-09-16 09:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/81b85ea694f8 Merge Changeset: ee68feef41d2 Author: jccollet Date: 2009-09-18 10:51 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ee68feef41d2 6737819: sun.misc.net.DefaultProxySelector doesn't use proxy setting to localhost Summary: Move default nonProxyHosts from hardcoded to property default value Reviewed-by: chegar ! src/share/classes/java/net/doc-files/net-properties.html ! src/share/classes/sun/net/spi/DefaultProxySelector.java ! src/share/lib/net.properties + test/java/net/ProxySelector/B6737819.java Changeset: 39c15c0a71f7 Author: andrew Date: 2009-09-10 19:04 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/39c15c0a71f7 6882745: Add DISABLE_INTREE_EC option to make new EC provider optional. Summary: Don't build the ec subdirectory when DISABLE_INTREE_EC is defined. Reviewed-by: vinnie ! make/sun/security/Makefile Changeset: f119e21c0ca7 Author: tbell Date: 2009-09-18 08:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f119e21c0ca7 Merge Changeset: c9cbd2a09fd4 Author: chegar Date: 2009-09-18 16:24 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c9cbd2a09fd4 6882609: Move default InMemoryCookieStore to java.net Summary: remove static dependency on sun.net.www.protocol.http Reviewed-by: alanb, jccollet ! make/sun/net/FILES_java.gmk ! src/share/classes/java/net/CookieManager.java + src/share/classes/java/net/InMemoryCookieStore.java - src/share/classes/sun/net/www/protocol/http/InMemoryCookieStore.java Changeset: 9cd7133ea287 Author: chegar Date: 2009-09-18 22:18 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9cd7133ea287 6882594: Remove static dependancy on NTLM authentication Reviewed-by: alanb, weijun ! make/sun/net/FILES_java.gmk ! src/share/classes/sun/net/www/protocol/http/AuthCache.java ! src/share/classes/sun/net/www/protocol/http/AuthCacheValue.java + src/share/classes/sun/net/www/protocol/http/AuthScheme.java ! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java ! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java ! src/share/classes/sun/net/www/protocol/http/DigestAuthentication.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + src/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java ! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java ! src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java ! src/windows/classes/sun/net/www/protocol/http/NTLMAuthentication.java Changeset: 45a343706f73 Author: chegar Date: 2009-09-18 22:19 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/45a343706f73 Merge Changeset: d3281fa8e46c Author: mchung Date: 2009-09-17 14:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d3281fa8e46c 6882376: Add internal support for JRE implementation to eliminate the dependency on logging Summary: Added sun.util.logging.PlatformLogger for JRE implementation to log messages. Reviewed-by: alanb, naoto ! make/java/logging/Makefile ! src/share/classes/java/util/Currency.java ! src/share/classes/java/util/jar/Attributes.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/LogRecord.java ! src/share/classes/sun/util/LocaleServiceProviderPool.java + src/share/classes/sun/util/logging/PlatformLogger.java ! src/windows/classes/java/util/prefs/WindowsPreferences.java + test/sun/util/logging/PlatformLoggerTest.java Changeset: 7b4e73ca6fd7 Author: mchung Date: 2009-09-18 17:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7b4e73ca6fd7 Merge Changeset: 845fefff00a4 Author: vinnie Date: 2009-09-21 23:01 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/845fefff00a4 6884175: CR cleanup for 6840752: Provide out-of-the-box support for ECC algorithms Reviewed-by: wetmore ! make/sun/security/ec/Makefile ! make/sun/security/other/Makefile ! src/share/classes/sun/security/ec/ECDHKeyAgreement.java ! src/share/classes/sun/security/ec/ECDSASignature.java ! src/share/classes/sun/security/ec/ECKeyPairGenerator.java ! src/share/classes/sun/security/ec/SunEC.java ! src/share/classes/sun/security/ec/SunECEntries.java ! src/share/native/sun/security/ec/ECC_JNI.cpp - src/share/native/sun/security/ec/ec.c + src/share/native/sun/security/ec/impl/ec.c + src/share/native/sun/security/ec/impl/ec.h + src/share/native/sun/security/ec/impl/ec2.h + src/share/native/sun/security/ec/impl/ec2_163.c + src/share/native/sun/security/ec/impl/ec2_193.c + src/share/native/sun/security/ec/impl/ec2_233.c + src/share/native/sun/security/ec/impl/ec2_aff.c + src/share/native/sun/security/ec/impl/ec2_mont.c + src/share/native/sun/security/ec/impl/ec_naf.c + src/share/native/sun/security/ec/impl/ecc_impl.h + src/share/native/sun/security/ec/impl/ecdecode.c + src/share/native/sun/security/ec/impl/ecl-curve.h + src/share/native/sun/security/ec/impl/ecl-exp.h + src/share/native/sun/security/ec/impl/ecl-priv.h + src/share/native/sun/security/ec/impl/ecl.c + src/share/native/sun/security/ec/impl/ecl.h + src/share/native/sun/security/ec/impl/ecl_curve.c + src/share/native/sun/security/ec/impl/ecl_gf.c + src/share/native/sun/security/ec/impl/ecl_mult.c + src/share/native/sun/security/ec/impl/ecp.h + src/share/native/sun/security/ec/impl/ecp_192.c + src/share/native/sun/security/ec/impl/ecp_224.c + src/share/native/sun/security/ec/impl/ecp_256.c + src/share/native/sun/security/ec/impl/ecp_384.c + src/share/native/sun/security/ec/impl/ecp_521.c + src/share/native/sun/security/ec/impl/ecp_aff.c + src/share/native/sun/security/ec/impl/ecp_jac.c + src/share/native/sun/security/ec/impl/ecp_jm.c + src/share/native/sun/security/ec/impl/ecp_mont.c + src/share/native/sun/security/ec/impl/logtab.h + src/share/native/sun/security/ec/impl/mp_gf2m-priv.h + src/share/native/sun/security/ec/impl/mp_gf2m.c + src/share/native/sun/security/ec/impl/mp_gf2m.h + src/share/native/sun/security/ec/impl/mpi-config.h + src/share/native/sun/security/ec/impl/mpi-priv.h + src/share/native/sun/security/ec/impl/mpi.c + src/share/native/sun/security/ec/impl/mpi.h + src/share/native/sun/security/ec/impl/mplogic.c + src/share/native/sun/security/ec/impl/mplogic.h + src/share/native/sun/security/ec/impl/mpmontg.c + src/share/native/sun/security/ec/impl/mpprime.h + src/share/native/sun/security/ec/impl/oid.c + src/share/native/sun/security/ec/impl/secitem.c + src/share/native/sun/security/ec/impl/secoidt.h ! test/sun/security/ec/TestEC.java + test/sun/security/ec/certs/sunlabscerts.pem + test/sun/security/ec/keystore + test/sun/security/ec/truststore ! test/sun/security/pkcs11/ec/ReadCertificates.java ! test/sun/security/pkcs11/sslecc/CipherTest.java Changeset: 81dffe63c913 Author: weijun Date: 2009-09-22 10:01 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/81dffe63c913 6877357: IPv6 address does not work Reviewed-by: xuelei, alanb ! src/share/classes/sun/security/krb5/KrbKdcReq.java + test/sun/security/krb5/IPv6.java Changeset: 023063a403ed Author: chegar Date: 2009-09-22 14:42 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/023063a403ed 6882654: Remove dependency on java.util.concurrent from KeepAlive implementaion Reviewed-by: michaelm ! src/share/classes/sun/net/www/http/KeepAliveCache.java ! src/share/classes/sun/net/www/http/KeepAliveStream.java ! src/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java Changeset: 44ccaa4bb8a0 Author: chegar Date: 2009-09-22 14:49 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/44ccaa4bb8a0 6882384: Update http protocol handler to use PlatformLogger Reviewed-by: jccollet, alanb ! src/share/classes/sun/net/www/http/HttpCapture.java ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/http/HttpLogFormatter.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java ! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java ! src/share/classes/sun/util/logging/PlatformLogger.java Changeset: b8004f6f4812 Author: kevinw Date: 2009-09-22 17:01 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b8004f6f4812 6882768: (launcher) test for 6842838 is broken Summary: Testcase correction. Reviewed-by: ksrini ! test/tools/launcher/6842838/Test6842838.sh Changeset: f708138c9aca Author: kevinw Date: 2009-09-22 17:16 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f708138c9aca Merge Changeset: 59b45d636384 Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/59b45d636384 Added tag jdk7-b73 for changeset f708138c9aca ! .hgtags Changeset: 8e5d45fc8d1e Author: jgodinez Date: 2009-07-01 12:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8e5d45fc8d1e 6848799: Reg-test java/awt/print/PageFormat/PageFormatFromAttributes.java fails on Rhel_5 Reviewed-by: tdv, prr ! src/solaris/classes/sun/print/IPPPrintService.java + test/java/awt/print/PageFormat/PageFormatFromAttributes.java Changeset: 837bb8760bad Author: yan Date: 2009-07-13 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/837bb8760bad Merge - src/share/classes/java/nio/file/DirectoryStreamFilters.java - src/share/classes/java/nio/file/FileAction.java - src/share/classes/java/nio/file/spi/AbstractPath.java - src/share/classes/sun/io/ByteToCharMS932DB.java - src/share/classes/sun/io/CharToByteMS932DB.java - src/share/classes/sun/nio/cs/ext/EUC_CN.java - src/share/classes/sun/nio/cs/ext/EUC_KR.java - src/share/classes/sun/nio/cs/ext/GBK.java - src/share/classes/sun/nio/cs/ext/Johab.java - src/share/classes/sun/nio/cs/ext/MS932.java - src/share/classes/sun/nio/cs/ext/MS932DB.java - src/share/classes/sun/nio/cs/ext/MS936.java - src/share/classes/sun/nio/cs/ext/MS949.java - src/share/classes/sun/nio/cs/ext/MS950.java - src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java - src/share/classes/sun/nio/fs/MimeType.java - src/share/classes/sun/swing/AccessibleMethod.java - test/java/nio/file/DirectoryStream/Filters.java - test/java/nio/file/Files/content_type.sh - test/java/nio/file/Path/temporary_files.sh - test/java/nio/file/attribute/Attributes/Basic.java Changeset: a0b315ecdc78 Author: rkennke Date: 2009-07-22 15:52 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a0b315ecdc78 6857358: Two testcases are failing in jdk7 b64 pit build with java.security.AccessControlException Summary: Try to load GraphicsEnvironment with bootclassloader first, only then try app classloader. Reviewed-by: prr, tdv, igor ! src/share/classes/java/awt/GraphicsEnvironment.java Changeset: 9fa696ed1f38 Author: jgodinez Date: 2009-07-30 12:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9fa696ed1f38 Merge Changeset: 7fe0497ee5b5 Author: jgodinez Date: 2009-08-04 17:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7fe0497ee5b5 6829673: ThinLineTest: A line < 1 pixel disappears. Reviewed-by: igor, prr Contributed-by: rkennke ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java + test/sun/pisces/ThinLineTest.java Changeset: 64b0c953635d Author: rkennke Date: 2009-08-07 18:31 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/64b0c953635d 6795908: Refactor FontManager Reviewed-by: prr, igor ! make/sun/awt/FILES_export_windows.gmk ! make/sun/awt/make.depend ! make/sun/awt/mapfile-mawt-vers ! make/sun/awt/mapfile-vers-linux ! make/sun/font/mapfile-vers ! make/sun/font/mapfile-vers.openjdk ! make/sun/headless/mapfile-vers ! make/sun/xawt/mapfile-vers ! src/share/classes/com/sun/java/swing/plaf/gtk/PangoFonts.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Font.java ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/share/classes/javax/swing/plaf/nimbus/Defaults.template ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/sun/awt/FontConfiguration.java ! src/share/classes/sun/font/CMap.java ! src/share/classes/sun/font/CompositeFont.java ! src/share/classes/sun/font/CompositeGlyphMapper.java ! src/share/classes/sun/font/FileFont.java ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/FontDesignMetrics.java ! src/share/classes/sun/font/FontFamily.java ! src/share/classes/sun/font/FontManager.java ! src/share/classes/sun/font/FontManagerNativeLibrary.java ! src/share/classes/sun/font/FontResolver.java ! src/share/classes/sun/font/FontScaler.java ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/classes/sun/font/GlyphLayout.java ! src/share/classes/sun/font/PhysicalStrike.java ! src/share/classes/sun/font/StandardGlyphVector.java ! src/share/classes/sun/font/StrikeCache.java ! src/share/classes/sun/font/TrueTypeFont.java ! src/share/classes/sun/font/TrueTypeGlyphMapper.java ! src/share/classes/sun/font/Type1Font.java ! src/share/classes/sun/font/Type1GlyphMapper.java ! src/share/classes/sun/java2d/SunGraphics2D.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/share/classes/sun/print/PSPrinterJob.java ! src/share/classes/sun/print/PathGraphics.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/share/native/sun/font/sunFont.c ! src/share/native/sun/font/sunfontids.h ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/classes/sun/awt/motif/MFontConfiguration.java ! src/solaris/classes/sun/awt/motif/MToolkit.java ! src/solaris/classes/sun/font/FcFontConfiguration.java ! src/solaris/classes/sun/font/NativeFont.java ! src/solaris/classes/sun/font/NativeStrike.java ! src/solaris/native/sun/awt/fontpath.c ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java ! src/windows/classes/sun/awt/windows/WFontConfiguration.java ! src/windows/classes/sun/awt/windows/WPathGraphics.java ! src/windows/classes/sun/awt/windows/WPrinterJob.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/native/sun/font/fontpath.c ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp Changeset: 92607d652d7a Author: rkennke Date: 2009-08-07 19:36 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/92607d652d7a 6869705: Missing files of CR6795908, FontManager refactoring Reviewed-by: prr, igor + src/share/classes/sun/font/FontAccess.java + src/share/classes/sun/font/FontManagerFactory.java + src/share/classes/sun/font/FontManagerForSGE.java + src/share/classes/sun/font/FontUtilities.java + src/share/classes/sun/font/SunFontManager.java + src/solaris/classes/sun/awt/X11FontManager.java + src/solaris/classes/sun/font/FontConfigManager.java + src/windows/classes/sun/awt/Win32FontManager.java Changeset: 11b38980893c Author: rkennke Date: 2009-08-12 17:21 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/11b38980893c 6870238: Font2DTest fails on Debian after FontManager refactoring Summary: Use fontManager field instead of querying the FontManagerFactory Reviewed-by: igor, prr ! src/solaris/classes/sun/font/FcFontConfiguration.java Changeset: a389af17df10 Author: prr Date: 2009-08-14 14:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a389af17df10 6867603: sun.font.FontManager.getDefaultPlatformFont throws NPE in OpenJDK on Solaris 10 10/08 Reviewed-by: igor, jgodinez ! src/solaris/classes/sun/font/FontConfigManager.java ! src/solaris/native/sun/awt/fontpath.c Changeset: e90f58148115 Author: jgodinez Date: 2009-09-16 19:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e90f58148115 Merge - make/javax/swing/plaf/nimbus/Makefile - make/tools/swing-nimbus/Makefile - make/tools/swing-nimbus/classes/org/jdesktop/beans/AbstractBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BezierControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BlendingMode.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Canvas.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/ControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Designer.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/DoubleBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/EllipseShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/GraphicsHelper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Layer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/LayerContainer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PaintedShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PathShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/RectangleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/SimpleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/TemplateLayer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/DropShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/Effect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtilsTemp.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/OuterGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/ShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/font/Typeface.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/CanvasMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/ColorMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/DimensionMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/InsetsMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/AbstractGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Gradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/GradientStop.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Matte.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/PaintModel.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/RadialGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Texture.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasPath.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasResources.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasUIDefaults.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/Generator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/GeneratorUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/ObjectCodeConvertors.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/PainterGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/TemplateWriter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/CustomUIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/HasUIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/PainterBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIColor.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIComponent.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDimension.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIFont.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIcon.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIconRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIInsets.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIPaint.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIProperty.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIState.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStateType.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/BorderMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassConverter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/FontMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/UIPropertyMapper.java - src/share/classes/com/sun/crypto/provider/JarVerifier.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/java/awt/Component.java - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java ! src/share/classes/javax/swing/plaf/nimbus/Defaults.template - src/share/classes/sun/nio/ch/AbstractFuture.java - src/share/classes/sun/security/pkcs11/JarVerifier.java ! src/share/classes/sun/swing/SwingUtilities2.java - src/share/native/java/util/zip/zlib-1.1.3/ChangeLog - src/share/native/java/util/zip/zlib-1.1.3/README - src/share/native/java/util/zip/zlib-1.1.3/compress.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.h - src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc - src/share/native/java/util/zip/zlib-1.1.3/example.c - src/share/native/java/util/zip/zlib-1.1.3/gzio.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.h - src/share/native/java/util/zip/zlib-1.1.3/infcodes.c - src/share/native/java/util/zip/zlib-1.1.3/infcodes.h - src/share/native/java/util/zip/zlib-1.1.3/inffast.c - src/share/native/java/util/zip/zlib-1.1.3/inffast.h - src/share/native/java/util/zip/zlib-1.1.3/inffixed.h - src/share/native/java/util/zip/zlib-1.1.3/inflate.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.h - src/share/native/java/util/zip/zlib-1.1.3/infutil.c - src/share/native/java/util/zip/zlib-1.1.3/infutil.h - src/share/native/java/util/zip/zlib-1.1.3/minigzip.c - src/share/native/java/util/zip/zlib-1.1.3/trees.c - src/share/native/java/util/zip/zlib-1.1.3/trees.h - src/share/native/java/util/zip/zlib-1.1.3/uncompr.c - src/share/native/java/util/zip/zlib-1.1.3/zadler32.c - src/share/native/java/util/zip/zlib-1.1.3/zconf.h - src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.1.3/zlib.h - src/share/native/java/util/zip/zlib-1.1.3/zutil.c - src/share/native/java/util/zip/zlib-1.1.3/zutil.h ! src/solaris/classes/sun/awt/X11/XToolkit.java - src/windows/classes/sun/security/mscapi/JarVerifier.java - test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java - test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java - test/java/util/concurrent/LinkedBlockingQueue/LastElement.java - test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: 27d58a02bb9d Author: srl Date: 2009-09-28 11:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/27d58a02bb9d 6795060: VM crash on Linux in ICU layout library when processing \u0DDD (Sinhalese) Reviewed-by: igor, prr ! src/share/native/sun/font/layout/IndicClassTables.cpp + test/java/awt/font/TextLayout/TestSinhalaChar.java Changeset: e6ced7714609 Author: jgodinez Date: 2009-09-29 09:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e6ced7714609 Merge - src/share/classes/sun/net/www/protocol/http/InMemoryCookieStore.java - src/share/native/sun/security/ec/ec.c Changeset: c74d38ef118c Author: srl Date: 2009-09-29 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c74d38ef118c 6501644: sync LayoutEngine *code* structure to match ICU Reviewed-by: prr ! make/sun/font/Makefile ! src/share/native/sun/font/layout/AlternateSubstSubtables.cpp ! src/share/native/sun/font/layout/AlternateSubstSubtables.h ! src/share/native/sun/font/layout/AnchorTables.cpp ! src/share/native/sun/font/layout/AnchorTables.h ! src/share/native/sun/font/layout/ArabicLayoutEngine.cpp ! src/share/native/sun/font/layout/ArabicLayoutEngine.h ! src/share/native/sun/font/layout/ArabicShaping.cpp ! src/share/native/sun/font/layout/ArabicShaping.h ! src/share/native/sun/font/layout/AttachmentPosnSubtables.h ! src/share/native/sun/font/layout/CanonData.cpp ! src/share/native/sun/font/layout/CanonShaping.cpp ! src/share/native/sun/font/layout/CanonShaping.h ! src/share/native/sun/font/layout/CharSubstitutionFilter.h ! src/share/native/sun/font/layout/ClassDefinitionTables.cpp ! src/share/native/sun/font/layout/ClassDefinitionTables.h ! src/share/native/sun/font/layout/ContextualGlyphInsertion.h ! src/share/native/sun/font/layout/ContextualGlyphSubstProc.cpp ! src/share/native/sun/font/layout/ContextualGlyphSubstProc.h ! src/share/native/sun/font/layout/ContextualGlyphSubstitution.h ! src/share/native/sun/font/layout/ContextualSubstSubtables.cpp ! src/share/native/sun/font/layout/ContextualSubstSubtables.h ! src/share/native/sun/font/layout/CoverageTables.cpp ! src/share/native/sun/font/layout/CoverageTables.h ! src/share/native/sun/font/layout/CursiveAttachmentSubtables.cpp ! src/share/native/sun/font/layout/CursiveAttachmentSubtables.h ! src/share/native/sun/font/layout/DefaultCharMapper.h ! src/share/native/sun/font/layout/DeviceTables.cpp ! src/share/native/sun/font/layout/DeviceTables.h ! src/share/native/sun/font/layout/ExtensionSubtables.cpp ! src/share/native/sun/font/layout/ExtensionSubtables.h ! src/share/native/sun/font/layout/Features.cpp ! src/share/native/sun/font/layout/Features.h ! src/share/native/sun/font/layout/GDEFMarkFilter.cpp ! src/share/native/sun/font/layout/GDEFMarkFilter.h ! src/share/native/sun/font/layout/GXLayoutEngine.cpp ! src/share/native/sun/font/layout/GXLayoutEngine.h ! src/share/native/sun/font/layout/GlyphDefinitionTables.cpp ! src/share/native/sun/font/layout/GlyphDefinitionTables.h ! src/share/native/sun/font/layout/GlyphIterator.cpp ! src/share/native/sun/font/layout/GlyphIterator.h ! src/share/native/sun/font/layout/GlyphLookupTables.cpp ! src/share/native/sun/font/layout/GlyphLookupTables.h ! src/share/native/sun/font/layout/GlyphPositionAdjustments.cpp ! src/share/native/sun/font/layout/GlyphPositionAdjustments.h ! src/share/native/sun/font/layout/GlyphPositioningTables.cpp ! src/share/native/sun/font/layout/GlyphPositioningTables.h ! src/share/native/sun/font/layout/GlyphPosnLookupProc.cpp ! src/share/native/sun/font/layout/GlyphPosnLookupProc.h ! src/share/native/sun/font/layout/GlyphSubstLookupProc.cpp ! src/share/native/sun/font/layout/GlyphSubstLookupProc.h ! src/share/native/sun/font/layout/GlyphSubstitutionTables.cpp ! src/share/native/sun/font/layout/GlyphSubstitutionTables.h ! src/share/native/sun/font/layout/HanLayoutEngine.cpp ! src/share/native/sun/font/layout/HanLayoutEngine.h ! src/share/native/sun/font/layout/IndicClassTables.cpp ! src/share/native/sun/font/layout/IndicLayoutEngine.cpp ! src/share/native/sun/font/layout/IndicLayoutEngine.h ! src/share/native/sun/font/layout/IndicRearrangement.h ! src/share/native/sun/font/layout/IndicRearrangementProcessor.cpp ! src/share/native/sun/font/layout/IndicRearrangementProcessor.h ! src/share/native/sun/font/layout/IndicReordering.cpp ! src/share/native/sun/font/layout/IndicReordering.h ! src/share/native/sun/font/layout/KernTable.cpp ! src/share/native/sun/font/layout/KernTable.h ! src/share/native/sun/font/layout/KhmerLayoutEngine.cpp ! src/share/native/sun/font/layout/KhmerLayoutEngine.h ! src/share/native/sun/font/layout/KhmerReordering.cpp ! src/share/native/sun/font/layout/KhmerReordering.h ! src/share/native/sun/font/layout/LEFontInstance.cpp ! src/share/native/sun/font/layout/LEFontInstance.h ! src/share/native/sun/font/layout/LEGlyphFilter.h ! src/share/native/sun/font/layout/LEGlyphStorage.cpp ! src/share/native/sun/font/layout/LEGlyphStorage.h ! src/share/native/sun/font/layout/LEInsertionList.cpp ! src/share/native/sun/font/layout/LEInsertionList.h ! src/share/native/sun/font/layout/LELanguages.h ! src/share/native/sun/font/layout/LEScripts.h + src/share/native/sun/font/layout/LEStandalone.h ! src/share/native/sun/font/layout/LESwaps.h ! src/share/native/sun/font/layout/LETypes.h ! src/share/native/sun/font/layout/LayoutEngine.cpp ! src/share/native/sun/font/layout/LayoutEngine.h ! src/share/native/sun/font/layout/LayoutTables.h ! src/share/native/sun/font/layout/LigatureSubstProc.cpp ! src/share/native/sun/font/layout/LigatureSubstProc.h ! src/share/native/sun/font/layout/LigatureSubstSubtables.cpp ! src/share/native/sun/font/layout/LigatureSubstSubtables.h ! src/share/native/sun/font/layout/LigatureSubstitution.h ! src/share/native/sun/font/layout/LookupProcessor.cpp ! src/share/native/sun/font/layout/LookupProcessor.h ! src/share/native/sun/font/layout/LookupTables.cpp ! src/share/native/sun/font/layout/LookupTables.h ! src/share/native/sun/font/layout/Lookups.cpp ! src/share/native/sun/font/layout/Lookups.h ! src/share/native/sun/font/layout/MPreFixups.cpp ! src/share/native/sun/font/layout/MPreFixups.h ! src/share/native/sun/font/layout/MarkArrays.cpp ! src/share/native/sun/font/layout/MarkArrays.h ! src/share/native/sun/font/layout/MarkToBasePosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToBasePosnSubtables.h ! src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.h ! src/share/native/sun/font/layout/MarkToMarkPosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToMarkPosnSubtables.h ! src/share/native/sun/font/layout/MirroredCharData.cpp ! src/share/native/sun/font/layout/MorphStateTables.h ! src/share/native/sun/font/layout/MorphTables.cpp ! src/share/native/sun/font/layout/MorphTables.h ! src/share/native/sun/font/layout/MultipleSubstSubtables.cpp ! src/share/native/sun/font/layout/MultipleSubstSubtables.h ! src/share/native/sun/font/layout/NonContextualGlyphSubst.h ! src/share/native/sun/font/layout/NonContextualGlyphSubstProc.cpp ! src/share/native/sun/font/layout/NonContextualGlyphSubstProc.h ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.h ! src/share/native/sun/font/layout/OpenTypeTables.h ! src/share/native/sun/font/layout/OpenTypeUtilities.cpp ! src/share/native/sun/font/layout/OpenTypeUtilities.h ! src/share/native/sun/font/layout/PairPositioningSubtables.cpp ! src/share/native/sun/font/layout/PairPositioningSubtables.h ! src/share/native/sun/font/layout/ScriptAndLanguage.cpp ! src/share/native/sun/font/layout/ScriptAndLanguage.h ! src/share/native/sun/font/layout/ScriptAndLanguageTags.cpp ! src/share/native/sun/font/layout/ScriptAndLanguageTags.h ! src/share/native/sun/font/layout/SegmentArrayProcessor.cpp ! src/share/native/sun/font/layout/SegmentArrayProcessor.h ! src/share/native/sun/font/layout/SegmentSingleProcessor.cpp ! src/share/native/sun/font/layout/SegmentSingleProcessor.h ! src/share/native/sun/font/layout/ShapingTypeData.cpp ! src/share/native/sun/font/layout/SimpleArrayProcessor.cpp ! src/share/native/sun/font/layout/SimpleArrayProcessor.h ! src/share/native/sun/font/layout/SinglePositioningSubtables.cpp ! src/share/native/sun/font/layout/SinglePositioningSubtables.h ! src/share/native/sun/font/layout/SingleSubstitutionSubtables.cpp ! src/share/native/sun/font/layout/SingleSubstitutionSubtables.h ! src/share/native/sun/font/layout/SingleTableProcessor.cpp ! src/share/native/sun/font/layout/SingleTableProcessor.h ! src/share/native/sun/font/layout/StateTableProcessor.cpp ! src/share/native/sun/font/layout/StateTableProcessor.h ! src/share/native/sun/font/layout/StateTables.h ! src/share/native/sun/font/layout/SubstitutionLookups.cpp ! src/share/native/sun/font/layout/SubstitutionLookups.h ! src/share/native/sun/font/layout/SubtableProcessor.cpp ! src/share/native/sun/font/layout/SubtableProcessor.h ! src/share/native/sun/font/layout/ThaiLayoutEngine.cpp ! src/share/native/sun/font/layout/ThaiLayoutEngine.h ! src/share/native/sun/font/layout/ThaiShaping.cpp ! src/share/native/sun/font/layout/ThaiShaping.h ! src/share/native/sun/font/layout/ThaiStateTables.cpp ! src/share/native/sun/font/layout/TrimmedArrayProcessor.cpp ! src/share/native/sun/font/layout/TrimmedArrayProcessor.h ! src/share/native/sun/font/layout/ValueRecords.cpp ! src/share/native/sun/font/layout/ValueRecords.h Changeset: e8a764450aa7 Author: srl Date: 2009-09-29 15:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e8a764450aa7 Merge - src/share/classes/sun/net/www/protocol/http/InMemoryCookieStore.java - src/share/native/sun/security/ec/ec.c Changeset: e8b1b4c00e8a Author: srl Date: 2009-09-29 16:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e8b1b4c00e8a 6886718: missing license info Reviewed-by: igor, prr ! test/java/awt/font/TextLayout/TestSinhalaChar.java Changeset: ec67b240b727 Author: mchung Date: 2009-09-29 16:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ec67b240b727 6879044: Eliminate the dependency on logging from the AWT/2D/Swing classes Summary: Replace calls to Logger with sun.util.logging.PlatformLogger Reviewed-by: prr, art, alexp, dcherepanov, igor, dav, anthony ! src/share/classes/java/awt/AWTEvent.java ! src/share/classes/java/awt/AttributeValue.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java ! src/share/classes/java/awt/Cursor.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/EventDispatchThread.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/SplashScreen.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/javax/swing/BufferStrategyPaintManager.java ! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java ! src/share/classes/sun/awt/AWTAutoShutdown.java ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/awt/ComponentAccessor.java ! src/share/classes/sun/awt/DebugSettings.java ! src/share/classes/sun/awt/FontConfiguration.java ! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java ! src/share/classes/sun/awt/ScrollPaneWheelScroller.java ! src/share/classes/sun/awt/SunDisplayChanger.java ! src/share/classes/sun/awt/SunGraphicsCallback.java ! src/share/classes/sun/awt/SunToolkit.java ! src/share/classes/sun/awt/WindowAccessor.java ! src/share/classes/sun/awt/datatransfer/DataTransferer.java ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java ! src/share/classes/sun/awt/im/InputContext.java ! src/share/classes/sun/font/FontUtilities.java ! src/share/classes/sun/font/SunFontManager.java ! src/share/classes/sun/font/TrueTypeFont.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/solaris/classes/sun/awt/X11/InfoWindow.java ! src/solaris/classes/sun/awt/X11/ListHelper.java ! src/solaris/classes/sun/awt/X11/UnsafeXDisposerRecord.java ! src/solaris/classes/sun/awt/X11/XAWTXSettings.java ! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XCheckboxMenuItemPeer.java ! src/solaris/classes/sun/awt/X11/XCheckboxPeer.java ! src/solaris/classes/sun/awt/X11/XChoicePeer.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XContentWindow.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java ! src/solaris/classes/sun/awt/X11/XDnDDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/XDnDDropTargetProtocol.java ! src/solaris/classes/sun/awt/X11/XDragSourceContextPeer.java ! src/solaris/classes/sun/awt/X11/XDropTargetContextPeer.java ! src/solaris/classes/sun/awt/X11/XDropTargetProtocol.java ! src/solaris/classes/sun/awt/X11/XDropTargetRegistry.java ! src/solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedClientHelper.java ! src/solaris/classes/sun/awt/X11/XEmbedHelper.java ! src/solaris/classes/sun/awt/X11/XEmbedServerTester.java ! src/solaris/classes/sun/awt/X11/XEmbeddedFramePeer.java ! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java ! src/solaris/classes/sun/awt/X11/XFocusProxyWindow.java ! src/solaris/classes/sun/awt/X11/XFramePeer.java ! src/solaris/classes/sun/awt/X11/XIconWindow.java ! src/solaris/classes/sun/awt/X11/XInputMethod.java ! src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/XListPeer.java ! src/solaris/classes/sun/awt/X11/XMSelection.java ! src/solaris/classes/sun/awt/X11/XMenuBarPeer.java ! src/solaris/classes/sun/awt/X11/XMenuItemPeer.java ! src/solaris/classes/sun/awt/X11/XMenuPeer.java ! src/solaris/classes/sun/awt/X11/XMenuWindow.java ! src/solaris/classes/sun/awt/X11/XNETProtocol.java ! src/solaris/classes/sun/awt/X11/XPopupMenuPeer.java ! src/solaris/classes/sun/awt/X11/XProtocol.java ! src/solaris/classes/sun/awt/X11/XQueryTree.java ! src/solaris/classes/sun/awt/X11/XScrollbar.java ! src/solaris/classes/sun/awt/X11/XScrollbarPeer.java ! src/solaris/classes/sun/awt/X11/XSystemTrayPeer.java ! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XTrayIconPeer.java ! src/solaris/classes/sun/awt/X11/XWINProtocol.java ! src/solaris/classes/sun/awt/X11/XWM.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/classes/sun/awt/X11/XWrapperBase.java ! src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java ! src/solaris/classes/sun/awt/X11/keysym2ucs.h ! src/solaris/classes/sun/awt/X11FontManager.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/classes/sun/awt/X11InputMethod.java ! src/solaris/classes/sun/awt/motif/MFontConfiguration.java ! src/solaris/classes/sun/awt/motif/MToolkit.java ! src/solaris/classes/sun/font/FcFontConfiguration.java ! src/solaris/classes/sun/font/FontConfigManager.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WDesktopProperties.java ! src/windows/classes/sun/awt/windows/WMenuItemPeer.java ! src/windows/classes/sun/awt/windows/WPanelPeer.java ! src/windows/classes/sun/awt/windows/WScrollPanePeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java Changeset: 5b52851b0927 Author: mchung Date: 2009-09-29 22:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5b52851b0927 Merge Changeset: 633806cdab51 Author: jgodinez Date: 2009-10-05 18:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/633806cdab51 Merge Changeset: c715b68cdcaf Author: darcy Date: 2009-09-22 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c715b68cdcaf 6468534: (reflect) Exception types cannot be parameterized, rephrase getGenericExceptionTypes. Reviewed-by: alanb ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Method.java Changeset: bbb543254c63 Author: martin Date: 2009-09-22 18:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/bbb543254c63 4245470: algorithm of java.lang.Byte.hashCode() is not specified Summary: Specify some hashCode methods are equivalent to intValue Reviewed-by: darcy ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/Short.java + test/java/lang/HashCode.java Changeset: eb92c939b8a7 Author: martin Date: 2009-09-22 18:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/eb92c939b8a7 6582946: Add suite of compare(T, T) methods for ints, longs etc Reviewed-by: darcy Contributed-by: kevinb at google.com ! src/share/classes/java/lang/Boolean.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java + test/java/lang/Compare.java Changeset: bd928aefe692 Author: weijun Date: 2009-09-24 21:35 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/bd928aefe692 6885166: regression test for 6877357 (IPv6 address does not work) error (timed out) Reviewed-by: xuelei ! test/sun/security/krb5/IPv6.java Changeset: 5b1aaf2d7504 Author: ptisnovs Date: 2009-09-30 11:49 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5b1aaf2d7504 6884837: JTReg test SetOutgoingIf is not correct Summary: Added check of network interfaces status Reviewed-by: alanb, chegar ! test/java/net/MulticastSocket/SetOutgoingIf.java Changeset: dd724911c90a Author: michaelm Date: 2009-09-29 10:00 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/dd724911c90a 6886108: Test case B4933582 binding to fixed port number Reviewed-by: chegar ! test/java/net/Authenticator/B4933582.java ! test/sun/net/www/httptest/HttpTransaction.java ! test/sun/security/ssl/sun/net/www/httpstest/HttpTransaction.java Changeset: 896cbd9c91f4 Author: michaelm Date: 2009-10-01 11:25 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/896cbd9c91f4 Merge Changeset: 527ad9cbc9cf Author: weijun Date: 2009-10-02 18:44 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/527ad9cbc9cf 6324292: keytool -help is unhelpful Reviewed-by: xuelei, mullan ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/util/Resources.java + test/sun/security/tools/keytool/newhelp.sh Changeset: 56bad48e2810 Author: weijun Date: 2009-10-02 18:47 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/56bad48e2810 6862679: ESC: AD Authentication with user with umlauts fails Reviewed-by: valeriep, mullan ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/KrbAsReq.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/internal/ETypeInfo.java ! src/share/classes/sun/security/krb5/internal/ETypeInfo2.java ! src/share/classes/sun/security/krb5/internal/KRBError.java ! src/share/classes/sun/security/krb5/internal/crypto/Des.java + src/share/classes/sun/security/krb5/internal/util/KerberosString.java ! src/windows/classes/sun/security/krb5/internal/tools/Kinit.java + test/sun/security/krb5/RFC396xTest.java Changeset: a2d24418be6c Author: weijun Date: 2009-10-02 18:49 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a2d24418be6c 6874472: display address lists for tickets in klist tool Reviewed-by: valeriep ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java Changeset: a6046f6e720e Author: weijun Date: 2009-10-02 18:49 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a6046f6e720e 6868579: RFE: jarsigner to support reading password from environment variable Reviewed-by: xuelei, wetmore ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/util/Resources.java + test/sun/security/tools/jarsigner/passtype.sh Changeset: f0fdc4dd97d5 Author: michaelm Date: 2009-10-02 13:57 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f0fdc4dd97d5 6870935: DIGEST proxy authentication fails to connect to URLs with no trailing slash Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java ! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java ! src/share/classes/sun/net/www/protocol/http/DigestAuthentication.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java ! src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java ! src/windows/classes/sun/net/www/protocol/http/NTLMAuthentication.java + test/java/net/Authenticator/B6870935.java Changeset: e782a9564eae Author: michaelm Date: 2009-10-02 13:59 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e782a9564eae Merge Changeset: 9fcca0aae3da Author: tbell Date: 2009-10-02 08:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9fcca0aae3da 6787605: OpenSolaris doesn't have /usr/ucb/ps so ShellScaffold fails Reviewed-by: dcubed ! test/com/sun/jdi/ShellScaffold.sh Changeset: 97f17e6d0560 Author: alanb Date: 2009-10-04 15:42 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/97f17e6d0560 6884800: (file) Path.newInputStream does not usefully implement available() Reviewed-by: martin, chegar ! src/share/classes/sun/nio/ch/ChannelInputStream.java ! test/java/nio/channels/Channels/Basic.java Changeset: a4f31836660a Author: alanb Date: 2009-10-05 16:45 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a4f31836660a 6854954: Eliminate static dependency on java.awt.AWTPermission Reviewed-by: mullan, mchung, anthony ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/MouseInfo.java ! src/share/classes/java/awt/Robot.java ! src/share/classes/java/awt/SystemTray.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/javax/swing/JPopupMenu.java + src/share/classes/sun/awt/AWTPermissionFactory.java ! src/share/classes/sun/security/provider/PolicyFile.java + src/share/classes/sun/security/util/PermissionFactory.java ! src/share/classes/sun/security/util/SecurityConstants.java Changeset: 54118c8e0ebe Author: vinnie Date: 2009-10-05 23:42 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/54118c8e0ebe 6885204: JSSE should not require Kerberos to be present Reviewed-by: wetmore, alanb ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/DelegateHttpsURLConnection.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/JsseJce.java Changeset: c499401bc138 Author: mchung Date: 2009-10-05 18:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c499401bc138 6612680: Remove classloader dependency on jkernel Summary: Add a new sun.misc.BootClassLoaderHook that DownloadManager will implement Reviewed-by: alanb, forax, igor ! make/sun/jkernel/Makefile ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/util/zip/ZipEntry.java ! src/share/classes/sun/jkernel/DownloadManager.java + src/share/classes/sun/misc/BootClassLoaderHook.java ! src/share/classes/sun/misc/Launcher.java ! src/share/classes/sun/misc/VM.java ! src/share/native/sun/misc/VM.c Changeset: 572791538be5 Author: darcy Date: 2009-10-06 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/572791538be5 5062288: (reflect) Core reflection uses raw types when it could be using wildcards Reviewed-by: alanb ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/reflect/AccessibleObject.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/lang/reflect/ReflectAccess.java ! src/share/classes/sun/reflect/LangReflectAccess.java ! src/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java ! src/share/classes/sun/reflect/annotation/AnnotationType.java Changeset: 1b81fc851b20 Author: mchung Date: 2009-10-06 15:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1b81fc851b20 6888802: sun.misc.BootClassLoaderHook.getBootstrapPaths stack overflow Summary: Fixed sun.misc.BootClassLoaderHook.getBootstrapPaths calls hook.getAdditionalBootstrapPaths Reviewed-by: alanb, tbell ! src/share/classes/sun/misc/BootClassLoaderHook.java + test/sun/misc/BootClassLoaderHook/TestHook.java Changeset: f69b40e43bff Author: kamg Date: 2009-10-06 22:01 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f69b40e43bff 6885916: Memory leak in inferencing verifier (libverify.so) Summary: Use the memory management already present to track allocated memory Reviewed-by: coleenp, acorn ! src/share/native/common/check_code.c Changeset: f864c15f6779 Author: chegar Date: 2009-10-07 17:23 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f864c15f6779 6887364: SetOutgoingIf.java fails if run on multihomed machine without PIv6 on all interfaces Reviewed-by: alanb ! test/java/net/MulticastSocket/SetOutgoingIf.java Changeset: 777714bd992a Author: tbell Date: 2009-10-07 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/777714bd992a 6888888: new javah throws NullPointerException when building in jdk/make/java/nio Summary: Use the bootstrap javah during the build until bug-ID 6889255 is fixed Reviewed-by: jjg ! make/common/shared/Defs-java.gmk Changeset: e7ad502130ba Author: darcy Date: 2009-10-07 14:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e7ad502130ba 6480728: Byte.valueOf(byte) returns a cached value but Byte.valueOf(String) 6655735: Integer.toString() and String.valueOf(int) contain slow delegations Reviewed-by: lancea ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java ! src/share/classes/java/lang/String.java Changeset: 405fd587f13f Author: tbell Date: 2009-10-07 14:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/405fd587f13f Merge ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/Window.java Changeset: 317ac0bf2285 Author: anthony Date: 2009-09-15 16:15 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/317ac0bf2285 6868255: Requirements for correct operating of the HW/LW Mixing feature need to be specified Summary: The specification is updated Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java Changeset: 986ec552383f Author: yan Date: 2009-09-22 01:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/986ec552383f Merge - make/javax/swing/plaf/nimbus/Makefile - make/tools/swing-nimbus/Makefile - make/tools/swing-nimbus/classes/org/jdesktop/beans/AbstractBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BezierControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BlendingMode.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Canvas.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/ControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Designer.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/DoubleBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/EllipseShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/GraphicsHelper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Layer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/LayerContainer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PaintedShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PathShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/RectangleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/SimpleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/TemplateLayer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/DropShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/Effect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtilsTemp.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/OuterGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/ShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/font/Typeface.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/CanvasMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/ColorMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/DimensionMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/InsetsMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/AbstractGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Gradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/GradientStop.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Matte.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/PaintModel.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/RadialGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Texture.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasPath.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasResources.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasUIDefaults.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/Generator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/GeneratorUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/ObjectCodeConvertors.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/PainterGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/TemplateWriter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/CustomUIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/HasUIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/PainterBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIColor.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIComponent.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDimension.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIFont.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIcon.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIconRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIInsets.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIPaint.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIProperty.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIState.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStateType.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/BorderMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassConverter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/FontMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/UIPropertyMapper.java - src/share/classes/sun/nio/ch/AbstractFuture.java - src/share/native/java/util/zip/zlib-1.1.3/ChangeLog - src/share/native/java/util/zip/zlib-1.1.3/README - src/share/native/java/util/zip/zlib-1.1.3/compress.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.h - src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc - src/share/native/java/util/zip/zlib-1.1.3/example.c - src/share/native/java/util/zip/zlib-1.1.3/gzio.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.h - src/share/native/java/util/zip/zlib-1.1.3/infcodes.c - src/share/native/java/util/zip/zlib-1.1.3/infcodes.h - src/share/native/java/util/zip/zlib-1.1.3/inffast.c - src/share/native/java/util/zip/zlib-1.1.3/inffast.h - src/share/native/java/util/zip/zlib-1.1.3/inffixed.h - src/share/native/java/util/zip/zlib-1.1.3/inflate.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.h - src/share/native/java/util/zip/zlib-1.1.3/infutil.c - src/share/native/java/util/zip/zlib-1.1.3/infutil.h - src/share/native/java/util/zip/zlib-1.1.3/minigzip.c - src/share/native/java/util/zip/zlib-1.1.3/trees.c - src/share/native/java/util/zip/zlib-1.1.3/trees.h - src/share/native/java/util/zip/zlib-1.1.3/uncompr.c - src/share/native/java/util/zip/zlib-1.1.3/zadler32.c - src/share/native/java/util/zip/zlib-1.1.3/zconf.h - src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.1.3/zlib.h - src/share/native/java/util/zip/zlib-1.1.3/zutil.c - src/share/native/java/util/zip/zlib-1.1.3/zutil.h - test/java/util/concurrent/LinkedBlockingQueue/LastElement.java - test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: b6980b0d8440 Author: dcherepanov Date: 2009-09-30 13:21 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b6980b0d8440 6853592: VM test nsk.regression.b4261880 fails with "X Error of failed request: BadWindow" inconsistently. Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: a21d00087df9 Author: dcherepanov Date: 2009-09-30 15:48 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a21d00087df9 6878284: Sometimes test/javax/swing/system/6799345/TestShutdown.java "hangs" Reviewed-by: art, ant ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/sun/awt/AWTAutoShutdown.java Changeset: cf3f9c09ba1d Author: anthony Date: 2009-10-01 14:48 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/cf3f9c09ba1d 6886868: giflib has a memory leak in the MakeMapObject() function Summary: free() the object before returning NULL Reviewed-by: art, dcherepanov ! src/share/native/sun/awt/giflib/gifalloc.c Changeset: 80db944866a9 Author: anthony Date: 2009-10-01 15:06 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/80db944866a9 6862611: Reg testcase closed/java/awt/Component/NativeInLightShow/NativeInLightShow.html fails Summary: The recursiveShowHeavyweightChildren() must be invoked unconditionally in mixOnShowing() Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Container.java Changeset: 4358934555bc Author: yan Date: 2009-10-06 23:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4358934555bc Merge ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/sun/awt/AWTAutoShutdown.java ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: 6216604c05e2 Author: alexp Date: 2009-09-09 17:32 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6216604c05e2 6878792: Sample provided in javax.swing.JLayer class description is not usable Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.java Changeset: afd85f72784b Author: peterz Date: 2009-09-10 12:30 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/afd85f72784b 6827786: Mnemonic cycling for multiple equal mnemonic armed menu items stops when encountering a submenu Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java Changeset: 51ccbb892a1f Author: alexp Date: 2009-09-15 16:26 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/51ccbb892a1f 6875716: JLayer.remove((Component)null) should behave consistently in (not) throwing NPE Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.java + test/javax/swing/JLayer/6875716/bug6875716.java Changeset: a64dbe61a984 Author: gsm Date: 2009-09-16 16:15 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a64dbe61a984 4337267: Arabic Numeral Shaping Reviewed-by: peterz ! src/share/classes/javax/swing/text/TextLayoutStrategy.java ! src/share/classes/sun/swing/SwingUtilities2.java + test/javax/swing/JComponent/4337267/bug4337267.java Changeset: 481c01572c62 Author: alexp Date: 2009-09-17 19:08 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/481c01572c62 4833524: BasicTreeUI.isToggleSelectionEvent() does not properly handle popup triggers Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicComboPopup.java ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicGraphicsUtils.java ! src/share/classes/javax/swing/plaf/basic/BasicListUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTableUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java ! src/share/classes/javax/swing/text/DefaultCaret.java Changeset: 1c7abc800502 Author: rupashka Date: 2009-09-18 15:11 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1c7abc800502 6840086: JFileChooser lacks icons on top right when running on Windows 7 Reviewed-by: peterz, uta ! src/share/classes/sun/awt/shell/ShellFolderManager.java ! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java ! src/windows/native/sun/windows/ShellFolder2.cpp + test/javax/swing/JFileChooser/6840086/bug6840086.java Changeset: fa71ca7a3655 Author: yan Date: 2009-09-21 01:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/fa71ca7a3655 Merge - src/share/classes/sun/nio/ch/AbstractFuture.java - src/share/native/java/util/zip/zlib-1.1.3/ChangeLog - src/share/native/java/util/zip/zlib-1.1.3/README - src/share/native/java/util/zip/zlib-1.1.3/compress.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.h - src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc - src/share/native/java/util/zip/zlib-1.1.3/example.c - src/share/native/java/util/zip/zlib-1.1.3/gzio.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.h - src/share/native/java/util/zip/zlib-1.1.3/infcodes.c - src/share/native/java/util/zip/zlib-1.1.3/infcodes.h - src/share/native/java/util/zip/zlib-1.1.3/inffast.c - src/share/native/java/util/zip/zlib-1.1.3/inffast.h - src/share/native/java/util/zip/zlib-1.1.3/inffixed.h - src/share/native/java/util/zip/zlib-1.1.3/inflate.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.h - src/share/native/java/util/zip/zlib-1.1.3/infutil.c - src/share/native/java/util/zip/zlib-1.1.3/infutil.h - src/share/native/java/util/zip/zlib-1.1.3/minigzip.c - src/share/native/java/util/zip/zlib-1.1.3/trees.c - src/share/native/java/util/zip/zlib-1.1.3/trees.h - src/share/native/java/util/zip/zlib-1.1.3/uncompr.c - src/share/native/java/util/zip/zlib-1.1.3/zadler32.c - src/share/native/java/util/zip/zlib-1.1.3/zconf.h - src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.1.3/zlib.h - src/share/native/java/util/zip/zlib-1.1.3/zutil.c - src/share/native/java/util/zip/zlib-1.1.3/zutil.h - test/java/util/concurrent/LinkedBlockingQueue/LastElement.java - test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: 9d78c3d9def2 Author: alexp Date: 2009-09-21 17:58 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9d78c3d9def2 6883341: SWAT: jdk7-b72 swat build(2009-09-17) threw exceptions when running Java2D demo by clicking Paint ta Reviewed-by: peterz ! src/share/classes/sun/swing/SwingUtilities2.java + test/javax/swing/JMenuItem/6883341/bug6883341.java Changeset: 6115613a3386 Author: peterz Date: 2009-09-23 21:14 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6115613a3386 6857888: closed/javax/swing/JMenuItem/6458123/bug6458123.java fails with InvocationTargetException. Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/nimbus/skin.laf ! src/share/classes/javax/swing/plaf/synth/SynthGraphicsUtils.java Changeset: d5045dd60c29 Author: rupashka Date: 2009-10-06 17:01 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d5045dd60c29 6489130: FileChooserDemo hung by keeping pressing Enter key Reviewed-by: alexp ! src/share/classes/javax/swing/JFileChooser.java + test/javax/swing/JFileChooser/6489130/bug6489130.java Changeset: dca0ab1a1ac3 Author: yan Date: 2009-10-06 23:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/dca0ab1a1ac3 Merge ! src/share/classes/sun/swing/SwingUtilities2.java Changeset: 77f213891ce3 Author: lana Date: 2009-10-13 15:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/77f213891ce3 Merge Changeset: eacb36e30327 Author: vinnie Date: 2009-10-14 23:41 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/eacb36e30327 6891632: Remove duplicate ECC source files Reviewed-by: wetmore - src/share/native/sun/security/ec/ec.h - src/share/native/sun/security/ec/ec2.h - src/share/native/sun/security/ec/ec2_163.c - src/share/native/sun/security/ec/ec2_193.c - src/share/native/sun/security/ec/ec2_233.c - src/share/native/sun/security/ec/ec2_aff.c - src/share/native/sun/security/ec/ec2_mont.c - src/share/native/sun/security/ec/ec_naf.c - src/share/native/sun/security/ec/ecc_impl.h - src/share/native/sun/security/ec/ecdecode.c - src/share/native/sun/security/ec/ecl-curve.h - src/share/native/sun/security/ec/ecl-exp.h - src/share/native/sun/security/ec/ecl-priv.h - src/share/native/sun/security/ec/ecl.c - src/share/native/sun/security/ec/ecl.h - src/share/native/sun/security/ec/ecl_curve.c - src/share/native/sun/security/ec/ecl_gf.c - src/share/native/sun/security/ec/ecl_mult.c - src/share/native/sun/security/ec/ecp.h - src/share/native/sun/security/ec/ecp_192.c - src/share/native/sun/security/ec/ecp_224.c - src/share/native/sun/security/ec/ecp_256.c - src/share/native/sun/security/ec/ecp_384.c - src/share/native/sun/security/ec/ecp_521.c - src/share/native/sun/security/ec/ecp_aff.c - src/share/native/sun/security/ec/ecp_jac.c - src/share/native/sun/security/ec/ecp_jm.c - src/share/native/sun/security/ec/ecp_mont.c - src/share/native/sun/security/ec/logtab.h - src/share/native/sun/security/ec/mp_gf2m-priv.h - src/share/native/sun/security/ec/mp_gf2m.c - src/share/native/sun/security/ec/mp_gf2m.h - src/share/native/sun/security/ec/mpi-config.h - src/share/native/sun/security/ec/mpi-priv.h - src/share/native/sun/security/ec/mpi.c - src/share/native/sun/security/ec/mpi.h - src/share/native/sun/security/ec/mplogic.c - src/share/native/sun/security/ec/mplogic.h - src/share/native/sun/security/ec/mpmontg.c - src/share/native/sun/security/ec/mpprime.h - src/share/native/sun/security/ec/oid.c - src/share/native/sun/security/ec/secitem.c - src/share/native/sun/security/ec/secoidt.h Changeset: 99dfeece98e2 Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/99dfeece98e2 Added tag jdk7-b74 for changeset eacb36e30327 ! .hgtags From john.coomes at sun.com Fri Oct 16 02:19:40 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 16 Oct 2009 09:19:40 +0000 Subject: hg: jdk7/hotspot/langtools: 18 new changesets Message-ID: <20091016092017.48B1A4188F@hg.openjdk.java.net> Changeset: 14735c7932d7 Author: xdono Date: 2009-09-22 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/14735c7932d7 6884624: Update copyright year Summary: Update copyright for files that have been modified in 2009 through Septermber Reviewed-by: tbell, ohair ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/file/SymbolArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! test/com/sun/javadoc/lib/JavadocTester.java ! test/com/sun/javadoc/testCRLineSeparator/TestCRLineSeparator.java ! test/com/sun/javadoc/testCRLineSeparator/pkg/MyClass.java ! test/com/sun/javadoc/testNoPackagesFile/TestNoPackagesFile.java ! test/com/sun/javadoc/testOverridenMethods/TestMultiInheritence.java ! test/com/sun/javadoc/testTaglets/TestTaglets.java ! test/tools/apt/Basics/apt.sh ! test/tools/apt/Basics/print.sh ! test/tools/apt/Compile/compile.sh ! test/tools/javac/4846262/Test.sh ! test/tools/javac/6302184/T6302184.sh ! test/tools/javac/6627362/T6627362.java ! test/tools/javac/ClassPathTest/ClassPathTest.sh ! test/tools/javac/ExtDirs/ExtDirs.sh ! test/tools/javac/MissingInclude.sh ! test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh ! test/tools/javac/T5090006/compiler.sh ! test/tools/javac/api/6440333/T6440333.java ! test/tools/javac/api/Sibling.java ! test/tools/javac/code/ArrayClone.java ! test/tools/javac/constDebug/ConstDebug.sh ! test/tools/javac/fatalErrors/NoJavaLang.sh ! test/tools/javac/generics/inference/6302954/T6476073.java ! test/tools/javac/innerClassFile/Driver.sh ! test/tools/javac/javazip/Test.sh ! test/tools/javac/meth/MakeNegTests.sh ! test/tools/javac/newlines/Newlines.sh ! test/tools/javac/quid/MakeNegTests.sh ! test/tools/javac/quid/QuotedIdent.java ! test/tools/javac/quid/QuotedIdent2.java ! test/tools/javac/stackmap/T4955930.sh ! test/tools/javac/unicode/SupplementaryJavaID6.sh ! test/tools/javah/6257087/foo.sh ! test/tools/javah/ConstMacroTest.sh ! test/tools/javah/MissingParamClassTest.sh ! test/tools/javah/ReadOldClass.sh ! test/tools/javap/T4975569.java ! test/tools/javap/pathsep.sh ! test/tools/javap/stackmap/T6271292.sh Changeset: ebb6ad5a95bb Author: jjg Date: 2009-09-08 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/ebb6ad5a95bb 5093723: REGRESSION: ClassCastException in SingleIndexWriter Reviewed-by: jjg Contributed-by: ahe at google.com ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties + test/com/sun/javadoc/5093723/DocumentedClass.java + test/com/sun/javadoc/5093723/T5093723.java + test/com/sun/javadoc/5093723/UndocumentedClass.java Changeset: 071a4e36cd87 Author: jjg Date: 2009-09-08 14:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/071a4e36cd87 6709246: ClassCastException in javadoc Reviewed-by: jjg Contributed-by: ahe at google.com ! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java + test/tools/javadoc/annotations/missing/Main.java + test/tools/javadoc/annotations/missing/somepackage/MissingAnnotationClass.java Changeset: f8be8bf150c3 Author: jjg Date: 2009-09-14 17:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/f8be8bf150c3 6881317: regression: NPE in CloseableURLClassLoader Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/file/CloseableURLClassLoader.java Changeset: 9dd34ed62341 Author: jjg Date: 2009-09-15 12:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/9dd34ed62341 6882235: invalid exponent causes silent javac crash Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/T6882235.java + test/tools/javac/T6882235.out Changeset: 69eaccd3ea85 Author: jjg Date: 2009-09-15 18:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/69eaccd3ea85 6860965: Project Coin: binary literals 6860973: Project Coin: Underscores in literals Summary: [Portions contributed by Bruce Chapman] Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/enum/6384542/T6384542.out + test/tools/javac/literals/BadBinaryLiterals.6.out + test/tools/javac/literals/BadBinaryLiterals.7.out + test/tools/javac/literals/BadBinaryLiterals.java + test/tools/javac/literals/BadUnderscoreLiterals.6.out + test/tools/javac/literals/BadUnderscoreLiterals.7.out + test/tools/javac/literals/BadUnderscoreLiterals.java + test/tools/javac/literals/BinaryLiterals.java + test/tools/javac/literals/UnderscoreLiterals.java Changeset: 5dd400fd62d9 Author: tbell Date: 2009-09-18 08:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/5dd400fd62d9 Merge Changeset: 789ee1acf107 Author: darcy Date: 2009-09-21 21:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/789ee1acf107 6884227: Clarify ordering requirements of javax.lang.model.TypeElement.getEnclosedElements Reviewed-by: ahe ! src/share/classes/javax/lang/model/element/TypeElement.java Changeset: 9596dff46093 Author: tbell Date: 2009-09-25 14:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/9596dff46093 Merge Changeset: d498d6ef9c6c Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/d498d6ef9c6c Added tag jdk7-b73 for changeset 9596dff46093 ! .hgtags Changeset: e992e602788e Author: darcy Date: 2009-09-23 18:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/e992e602788e 6517779: javax.lang.model.util.Elements.getConstantExpression() doesn't throw any exception 6517907: javax.lang.model.util.Elements.getConstantExpression() with negative byte value fails Summary: Fix various problems with Elements.getConstantExpression() Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/util/Constants.java ! src/share/classes/com/sun/tools/javac/util/Convert.java + test/tools/javac/processing/model/util/elements/Foo.java + test/tools/javac/processing/model/util/elements/TestGetConstantExpression.java Changeset: 49359d0e6a9c Author: jjg Date: 2009-09-23 18:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/49359d0e6a9c 6410637: Make decision on deprecated methods in DefaultFileManager and BaseFileObject. 6747645: ZipFileObject.getName is incorrectly deprecated 6885123: JavaFileObject getName issues Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/mirror/util/SourcePositionImpl.java ! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java - src/share/classes/com/sun/tools/javac/file/Old199.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/file/SymbolArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/DiagnosticSource.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/SourcePositionImpl.java ! src/share/classes/javax/tools/SimpleJavaFileObject.java + test/tools/javac/4241573/T4241573.java ! test/tools/javac/6589361/T6589361.java ! test/tools/javac/Diagnostics/6769027/T6769027.java ! test/tools/javac/T6705935.java ! test/tools/javac/api/6411310/T6411310.java + test/tools/javac/api/6411310/Test.java ! test/tools/javac/api/6733837/T6733837.java Changeset: c287d51c57da Author: jjg Date: 2009-09-23 19:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/c287d51c57da 6572945: javah should be written as an annotation processor, not a doclet Reviewed-by: darcy ! make/build.xml ! src/share/classes/com/sun/tools/javah/Gen.java + src/share/classes/com/sun/tools/javah/InternalError.java ! src/share/classes/com/sun/tools/javah/JNI.java + src/share/classes/com/sun/tools/javah/JavahFileManager.java + src/share/classes/com/sun/tools/javah/JavahTask.java + src/share/classes/com/sun/tools/javah/JavahTool.java ! src/share/classes/com/sun/tools/javah/LLNI.java ! src/share/classes/com/sun/tools/javah/Main.java - src/share/classes/com/sun/tools/javah/MainDoclet.java ! src/share/classes/com/sun/tools/javah/Mangle.java + src/share/classes/com/sun/tools/javah/NativeHeaderTool.java ! src/share/classes/com/sun/tools/javah/TypeSignature.java ! src/share/classes/com/sun/tools/javah/Util.java - src/share/classes/com/sun/tools/javah/resources/Linux_ppc.properties - src/share/classes/com/sun/tools/javah/resources/Linux_sparc.properties - src/share/classes/com/sun/tools/javah/resources/SunOS_sparc.properties - src/share/classes/com/sun/tools/javah/resources/SunOS_sparcv9.properties ! src/share/classes/com/sun/tools/javah/resources/l10n.properties - src/share/classes/com/sun/tools/javah/resources/win32_x86.properties ! src/share/classes/com/sun/tools/javap/DisassemblerTool.java + test/tools/javah/6572945/T6572945.java + test/tools/javah/6572945/TestClass1.java + test/tools/javah/6572945/TestClass2.java + test/tools/javah/6572945/TestClass3.java + test/tools/javah/6572945/gold/jni.dir.1/TestClass1.h + test/tools/javah/6572945/gold/jni.dir.1/TestClass1_Inner1.h + test/tools/javah/6572945/gold/jni.dir.1/TestClass1_Inner2.h + test/tools/javah/6572945/gold/jni.dir.1/TestClass2.h + test/tools/javah/6572945/gold/jni.file.1 + test/tools/javah/6572945/gold/jni.file.2 + test/tools/javah/6572945/gold/jni.file.3 ! test/tools/javah/MissingParamClassTest.sh + test/tools/javah/compareTest/CompareTest.java + test/tools/javah/compareTest/CompareTest.sh + test/tools/javah/compareTest/FindNativeFiles.java + test/tools/javah/compareTest/README Changeset: d0f541480556 Author: darcy Date: 2009-09-24 16:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/d0f541480556 6337964: should ignore last comma in annotation array Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/annotations/pos/TrailingComma.java Changeset: 4776a869fdfa Author: tbell Date: 2009-09-25 22:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/4776a869fdfa Merge ! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java - src/share/classes/com/sun/tools/javac/file/Old199.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/file/SymbolArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java - src/share/classes/com/sun/tools/javah/MainDoclet.java - src/share/classes/com/sun/tools/javah/resources/Linux_ppc.properties - src/share/classes/com/sun/tools/javah/resources/Linux_sparc.properties - src/share/classes/com/sun/tools/javah/resources/SunOS_sparc.properties - src/share/classes/com/sun/tools/javah/resources/SunOS_sparcv9.properties - src/share/classes/com/sun/tools/javah/resources/win32_x86.properties ! test/tools/javah/MissingParamClassTest.sh Changeset: c6d0c55b1aba Author: jjg Date: 2009-09-28 16:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/c6d0c55b1aba 6886348: apt incorrectly uses Scope.table Reviewed-by: darcy ! src/share/classes/com/sun/tools/apt/comp/Apt.java Changeset: 1a66b08deed0 Author: tbell Date: 2009-10-07 14:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/1a66b08deed0 Merge - src/share/classes/com/sun/tools/javac/file/Old199.java - src/share/classes/com/sun/tools/javah/MainDoclet.java - src/share/classes/com/sun/tools/javah/resources/Linux_ppc.properties - src/share/classes/com/sun/tools/javah/resources/Linux_sparc.properties - src/share/classes/com/sun/tools/javah/resources/SunOS_sparc.properties - src/share/classes/com/sun/tools/javah/resources/SunOS_sparcv9.properties - src/share/classes/com/sun/tools/javah/resources/win32_x86.properties Changeset: 79c13af9217e Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/79c13af9217e Added tag jdk7-b74 for changeset 1a66b08deed0 ! .hgtags From Christian.Thalinger at Sun.COM Fri Oct 16 03:06:23 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 16 Oct 2009 12:06:23 +0200 Subject: debug ps(x) and psf(x) Message-ID: <1255687584.795.131.camel@macbook> During debugging of MethodHandle invokes, where some stacks were corrupted because of bugs, I found it very useful to print stacktraces of particular threads. As I couldn't find similar methods I added these (psx and psfx) myself: diff --git a/src/share/vm/utilities/debug.cpp b/src/share/vm/utilities/debug.cpp --- a/src/share/vm/utilities/debug.cpp +++ b/src/share/vm/utilities/debug.cpp @@ -396,12 +396,9 @@ extern "C" void pa(intptr_t p) { ((AllocatedObj*) p)->print(); } extern "C" void findpc(intptr_t x); -extern "C" void ps() { // print stack - Command c("ps"); - - - // Prints the stack of the current Java thread - JavaThread* p = JavaThread::active(); +extern "C" void psx(intptr_t x) { // print stack + Command c("psx"); + JavaThread* p = (JavaThread*) x; tty->print(" for thread: "); p->print(); tty->cr(); @@ -416,25 +413,34 @@ f = f.sender(®_map); tty->print("(guessing starting frame id=%#p based on current fp)\n", f.id()); p->trace_stack_from(vframe::new_vframe(&f, ®_map, p)); - pd_ps(f); + pd_ps(f); } - } +extern "C" void ps() { // print stack of current Java thread + Command c("ps"); + JavaThread* p = JavaThread::active(); + psx((intptr_t) p); +} -extern "C" void psf() { // print stack frames - { - Command c("psf"); - JavaThread* p = JavaThread::active(); - tty->print(" for thread: "); - p->print(); - tty->cr(); - if (p->has_last_Java_frame()) { - p->trace_frames(); - } + +extern "C" void psfx(intptr_t x) { // print stack frames + Command c("psfx"); + JavaThread* p = (JavaThread*) x; + tty->print(" for thread: "); + p->print(); + tty->cr(); + if (p->has_last_Java_frame()) { + p->trace_frames(); } } +extern "C" void psf() { // print stack frames of current Java thread + Command c("psf"); + JavaThread* p = JavaThread::active(); + psfx((intptr_t) p); +} + extern "C" void threads() { Command c("threads"); Could we add these or did I miss any methods which are exactly doing that? -- Christian From martin.strassburger at t-online.de Fri Oct 16 01:46:54 2009 From: martin.strassburger at t-online.de (martin.strassburger at t-online.de) Date: Fri, 16 Oct 2009 10:46:54 +0200 Subject: GPL license for Hotspot VM forbid non-GPL JNI coding? Message-ID: <1MyiSc-02t0q00@fwd09.aul.t-online.de> Hi team leads, I would like to address the following license issue in the case a non-GPL application wants to use the openjdk implementation. The openjdk project provides the Hotspot Java VM with GPL v2 license and the JDK with GPL v2 + Classpath exception, so that it is possible to run a Java program which is non-GPL licensed. see http://www.sun.com/software/opensource/java/faq.jsp#g6 (Why do you need the Classpath exception) The Java runtime can be started per 'java' executable or by Java native interface call JNI_CreateJavaVM(). http://java.sun.com/javase/6/docs/technotes/guides/jni/spec/invocation.html The Hotspot Java VM license is GPL v2 (not LGPL or extended with something like classpath exception). Hence is it intended that all programs starting the Hotspot Java runtime per JNI call must be released with GPL license? Does this also mean that JNI coding can not be used without GPL license? Because all this links the VM library dynamically? I assume, that the GPL license for the Hotspot VM was chosen because VM extensions should be available for everyone. I assume, that the intension is not to make the JNI interface unuseable for non-GPL applications. Could you please clarify? Best regards, Martin Strassburger From volker.simonis at gmail.com Fri Oct 16 09:44:39 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 16 Oct 2009 18:44:39 +0200 Subject: GPL license for Hotspot VM forbid non-GPL JNI coding? In-Reply-To: <1MyiSc-02t0q00@fwd09.aul.t-online.de> References: <1MyiSc-02t0q00@fwd09.aul.t-online.de> Message-ID: Hi Martin, this question pops up every now and then and there have been already quite some discussions on the list about this topic, most noticeably here: "OpenJDK and JNI -- licensing" (http://mail.openjdk.java.net/pipermail/discuss/2009-July/thread.html#1308) The bottom line so far is the following: - "jni.h" which is part of t he VM has the "classpath exception" (see http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/tip/src/share/vm/prims/jni.h) - if you want to start the VM trough JNI, you have to compile your program against "jni.h", but that's no problem (because of the classpath exception of "jni.h") Now there's only the question of if you can "dynamically" load/link the VM from your program and there are two contradictory positions here. Florian Weimer explained this nicely in the previously mentioned mail thread: "..There are two conflicting lines of thoughts regarding GPLed program loaders: The first one says that loaded programs are not subject to the loader's GPL license. This is the stance taken by the Linux folks for their kernel. The second one says that the loaded program has to be GPLed as well. This one is sometimes cited in the Emacs Lisp context (meaning that anything which runs on Emacs has to be GPLed)..." Sun has its own interpretation which was explained by Martin Buchholz: "..I imagine some lawyer at Sun thought as follows: Whether an API is a published standard influences whether or not a client of that API is considered a separate work or not. Most (but not all) of the interfaces to hotspot are specified by a JCP standard (and that includes jni), and this standard has multiple implementations, so it is reasonable to presume that linking with hotspot is not creating a separate program, when not using the non-standard interfaces (like sun.misc.Unsafe). One can further presume that one can use any interfaces for which the interface specification file (e.g. a C header file) has the Classpath exception..." The only real outcome of the mentioned discussions was that you won't get any more precise answer from Sun lawyers anytime soon. So feel free to choose your own interpretation:) Regards, Volker On 10/16/09, martin.strassburger at t-online.de wrote: > Hi team leads, > > I would like to address the following license issue in the case > a non-GPL application wants to use the openjdk implementation. > > The openjdk project provides the Hotspot Java VM with GPL v2 license > and the JDK with GPL v2 + Classpath exception, so that it is possible > to run a Java program which is non-GPL licensed. > see http://www.sun.com/software/opensource/java/faq.jsp#g6 > (Why do you need the Classpath exception) > > The Java runtime can be started per 'java' executable or by > Java native interface call JNI_CreateJavaVM(). > http://java.sun.com/javase/6/docs/technotes/guides/jni/spec/invocation.html > The Hotspot Java VM license is GPL v2 (not LGPL or extended with something like > classpath exception). > > Hence is it intended that all programs starting the Hotspot Java runtime > per JNI call must be released with GPL license? > Does this also mean that JNI coding can not be used without GPL license? > Because all this links the VM library dynamically? > > I assume, that the GPL license for the Hotspot VM was chosen because > VM extensions should be available for everyone. > > I assume, that the intension is not to make the JNI interface unuseable > for non-GPL applications. > > Could you please clarify? > > Best regards, > > Martin Strassburger > > > From changpeng.fang at sun.com Fri Oct 16 16:10:05 2009 From: changpeng.fang at sun.com (changpeng.fang at sun.com) Date: Fri, 16 Oct 2009 23:10:05 +0000 Subject: hg: jdk7/hotspot/hotspot: 12 new changesets Message-ID: <20091016231030.114AF4198A@hg.openjdk.java.net> Changeset: dcf03e02b020 Author: twisti Date: 2009-10-06 02:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/dcf03e02b020 6879902: CTW failure jdk6_18/hotspot/src/cpu/sparc/vm/assembler_sparc.hpp:845 Summary: For signatures with a large number of arguments the offset for the float store becomes too big and does not fit in 13-bit. Reviewed-by: kvn, never ! 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/sharedRuntime_sparc.cpp + test/compiler/6879902/Test6879902.java Changeset: 1ce3281a8e93 Author: kvn Date: 2009-10-06 10:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1ce3281a8e93 6880034: SIGBUS during deoptimisation at a safepoint on 64bit-SPARC Summary: Fix problem with the double register encodings in sparc.ad Reviewed-by: never, jrose Contributed-by: volker.simonis at gmail.com ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad + test/compiler/6880034/Test6880034.java Changeset: e90521d61f9a Author: kvn Date: 2009-10-07 12:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e90521d61f9a 6875959: CTW fails hotspot/src/share/vm/opto/reg_split.cpp:1087 Summary: To break spill ties choose bound live range over unbound to free register or one with smaller cost to spill. Reviewed-by: never, jrose ! src/share/vm/opto/chaitin.cpp Changeset: 03b336640699 Author: never Date: 2009-10-07 15:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/03b336640699 6885584: A particular class structure causes large allocation spike for jit Reviewed-by: kvn ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp + test/compiler/6885584/Test6885584.java Changeset: 354d3184f6b2 Author: never Date: 2009-10-13 12:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/354d3184f6b2 6890308: integrate zero assembler hotspot changes Reviewed-by: never Contributed-by: gbenson at redhat.com ! make/Makefile ! make/defs.make ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/sa.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/top.make ! make/linux/makefiles/vm.make + make/linux/makefiles/zero.make + make/linux/makefiles/zeroshark.make + make/linux/platform_zero.in + src/cpu/zero/vm/assembler_zero.cpp + src/cpu/zero/vm/assembler_zero.hpp + src/cpu/zero/vm/assembler_zero.inline.hpp + src/cpu/zero/vm/bytecodeInterpreter_zero.cpp + src/cpu/zero/vm/bytecodeInterpreter_zero.hpp + src/cpu/zero/vm/bytecodeInterpreter_zero.inline.hpp + src/cpu/zero/vm/bytecodes_zero.cpp + src/cpu/zero/vm/bytecodes_zero.hpp + src/cpu/zero/vm/bytes_zero.hpp + src/cpu/zero/vm/codeBuffer_zero.hpp + src/cpu/zero/vm/copy_zero.hpp + src/cpu/zero/vm/cppInterpreterGenerator_zero.hpp + src/cpu/zero/vm/cppInterpreter_zero.cpp + src/cpu/zero/vm/cppInterpreter_zero.hpp + src/cpu/zero/vm/debug_zero.cpp + src/cpu/zero/vm/depChecker_zero.cpp + src/cpu/zero/vm/depChecker_zero.hpp + src/cpu/zero/vm/disassembler_zero.cpp + src/cpu/zero/vm/disassembler_zero.hpp + src/cpu/zero/vm/dump_zero.cpp + src/cpu/zero/vm/entryFrame_zero.hpp + src/cpu/zero/vm/entry_zero.hpp + src/cpu/zero/vm/fakeStubFrame_zero.hpp + src/cpu/zero/vm/frame_zero.cpp + src/cpu/zero/vm/frame_zero.hpp + src/cpu/zero/vm/frame_zero.inline.hpp + src/cpu/zero/vm/globalDefinitions_zero.hpp + src/cpu/zero/vm/globals_zero.hpp + src/cpu/zero/vm/icBuffer_zero.cpp + src/cpu/zero/vm/icache_zero.cpp + src/cpu/zero/vm/icache_zero.hpp + src/cpu/zero/vm/interp_masm_zero.cpp + src/cpu/zero/vm/interp_masm_zero.hpp + src/cpu/zero/vm/interpreterFrame_zero.hpp + src/cpu/zero/vm/interpreterGenerator_zero.hpp + src/cpu/zero/vm/interpreterRT_zero.cpp + src/cpu/zero/vm/interpreterRT_zero.hpp + src/cpu/zero/vm/interpreter_zero.cpp + src/cpu/zero/vm/interpreter_zero.hpp + src/cpu/zero/vm/javaFrameAnchor_zero.hpp + src/cpu/zero/vm/jniFastGetField_zero.cpp + src/cpu/zero/vm/jniTypes_zero.hpp + src/cpu/zero/vm/jni_zero.h + src/cpu/zero/vm/methodHandles_zero.cpp + src/cpu/zero/vm/nativeInst_zero.cpp + src/cpu/zero/vm/nativeInst_zero.hpp + src/cpu/zero/vm/registerMap_zero.hpp + src/cpu/zero/vm/register_definitions_zero.cpp + src/cpu/zero/vm/register_zero.cpp + src/cpu/zero/vm/register_zero.hpp + src/cpu/zero/vm/relocInfo_zero.cpp + src/cpu/zero/vm/relocInfo_zero.hpp + src/cpu/zero/vm/sharedRuntime_zero.cpp + src/cpu/zero/vm/sharkFrame_zero.hpp + src/cpu/zero/vm/stack_zero.hpp + src/cpu/zero/vm/stubGenerator_zero.cpp + src/cpu/zero/vm/stubRoutines_zero.cpp + src/cpu/zero/vm/stubRoutines_zero.hpp + src/cpu/zero/vm/templateInterpreterGenerator_zero.hpp + src/cpu/zero/vm/templateInterpreter_zero.cpp + src/cpu/zero/vm/templateInterpreter_zero.hpp + src/cpu/zero/vm/templateTable_zero.cpp + src/cpu/zero/vm/templateTable_zero.hpp + src/cpu/zero/vm/vmStructs_zero.hpp + src/cpu/zero/vm/vm_version_zero.cpp + src/cpu/zero/vm/vm_version_zero.hpp + src/cpu/zero/vm/vmreg_zero.cpp + src/cpu/zero/vm/vmreg_zero.hpp + src/cpu/zero/vm/vmreg_zero.inline.hpp + src/cpu/zero/vm/vtableStubs_zero.cpp ! src/os/linux/vm/os_linux.cpp + src/os_cpu/linux_zero/vm/assembler_linux_zero.cpp + src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp + src/os_cpu/linux_zero/vm/bytes_linux_zero.inline.hpp + src/os_cpu/linux_zero/vm/globals_linux_zero.hpp + src/os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp + src/os_cpu/linux_zero/vm/os_linux_zero.cpp + src/os_cpu/linux_zero/vm/os_linux_zero.hpp + src/os_cpu/linux_zero/vm/prefetch_linux_zero.inline.hpp + src/os_cpu/linux_zero/vm/threadLS_linux_zero.cpp + src/os_cpu/linux_zero/vm/threadLS_linux_zero.hpp + src/os_cpu/linux_zero/vm/thread_linux_zero.cpp + src/os_cpu/linux_zero/vm/thread_linux_zero.hpp + src/os_cpu/linux_zero/vm/vmStructs_linux_zero.hpp + src/os_cpu/linux_zero/vm/vm_version_linux_zero.cpp + src/share/vm/includeDB_zero ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/oopMapCache.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/jniHandles.hpp ! src/share/vm/runtime/mutex.hpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/vmError.cpp Changeset: fcb148c6b605 Author: never Date: 2009-10-13 16:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fcb148c6b605 6889302: TraceExceptions output should include detail message Reviewed-by: twisti, jrose, kvn ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp Changeset: 5f29a958a545 Author: kvn Date: 2009-10-13 20:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5f29a958a545 6889656: assert(lo_lrg->lo_degree() || !lo_no_simplify,"Live range was lo-degree before coalesce Summary: Restore the original code: uint i = _hi_degree. Reviewed-by: never, jrose ! src/share/vm/opto/chaitin.cpp Changeset: ce590301ae2a Author: kvn Date: 2009-10-13 22:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ce590301ae2a 6889300: assert(i != k || is_new || i->outcnt() > 0, "don't return dead nodes") Summary: PhiNode::Ideal() should return TOP for Phi node with no users. Reviewed-by: never, jrose ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/ifnode.cpp Changeset: 8e954aedbb81 Author: never Date: 2009-10-14 10:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8e954aedbb81 6889869: assert(!Interpreter::bytecode_should_reexecute(code),"should not reexecute") Reviewed-by: jrose, kvn, cfang, twisti ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/pcDesc.hpp Changeset: 23862fc517bb Author: kvn Date: 2009-10-14 11:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/23862fc517bb 6722084: JPRT make file doesn't create required symbolic link to libjvm.so Summary: Use -y zip option to preserve symbolic links. Reviewed-by: never, jcoomes, kamg ! make/jprt.gmk ! make/linux/makefiles/defs.make ! make/solaris/makefiles/defs.make Changeset: d40f03b57795 Author: kvn Date: 2009-10-14 15:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d40f03b57795 6890984: Comparison of 2 arrays could cause VM crash Summary: Restore original null checks. Reviewed-by: never, cfang ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp Changeset: e715b51789d8 Author: cfang Date: 2009-10-16 14:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e715b51789d8 Merge ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/phaseX.cpp From mjw at redhat.com Mon Oct 19 12:12:55 2009 From: mjw at redhat.com (Mark Wielaard) Date: Mon, 19 Oct 2009 21:12:55 +0200 Subject: JNI GetObjectArrayElement mark probe ret value shadowed Message-ID: <1255979575.2612.32.camel@hermans.wildebeest.org> Hi, In jni.cpp the DT_RETURN_MARK for GetObjectArrayElement tries to capture the jobject ret value. But the actual ret value returned is a newly defined jobject ret in the local scope of the if (is_within_bounds) branch. This means when probing the return of GetObjectArrayElement the return value always comes as as NULL. The following trivial patch fixes the issue and makes the actual return value available to the return probe. diff -r 6ddec5389232 src/share/vm/prims/jni.cpp --- a/src/share/vm/prims/jni.cpp Fri Oct 02 11:26:25 2009 -0700 +++ b/src/share/vm/prims/jni.cpp Mon Oct 19 21:10:11 2009 +0200 @@ -2116,7 +2116,7 @@ DT_RETURN_MARK(GetObjectArrayElement, jobject, (const jobject&)ret); objArrayOop a = objArrayOop(JNIHandles::resolve_non_null(array)); if (a->is_within_bounds(index)) { - jobject ret = JNIHandles::make_local(env, a->obj_at(index)); + ret = JNIHandles::make_local(env, a->obj_at(index)); return ret; } else { char buf[jintAsStringSize]; Tested against Systemtap, but the same should work for DTrace also. I don't have access to a system with solaris/dtrace on it, so it would be nice of someone who does could double check the above on such a system. Please let me know if I should create a bug also on https://bugs.openjdk.java.net/ and/or if I should report/post this patch on some other mailing-list. Thanks, Mark From mjw at redhat.com Mon Oct 19 12:43:29 2009 From: mjw at redhat.com (Mark Wielaard) Date: Mon, 19 Oct 2009 21:43:29 +0200 Subject: JNI DEFINE_NEWSCALARARRAY uses DT_RETURN_MARK_DECL_FOR Message-ID: <1255981409.2612.44.camel@hermans.wildebeest.org> Hi, In jni.cpp the DEFINE_NEWSCALARARRAY macro uses DT_RETURN_MARK_DECL_FOR instead of the normal DT_RETURN_MARK_DECL. The DT_RETURN_MARK_DECL_FOR macro should only be used for mark probes that could return a primitive jfloat or jdouble. But DEFINE_NEWSCALARARRAY creates the functions for NewArray which return primitiveTypeArrays. This means that for NewFloatArray and NewDoubleArray you cannot get the return value in the return mark probe. According to hotspot_jni.d the intention is to return these values in those cases: probe NewDoubleArray__entry(void*, uintptr_t); probe NewDoubleArray__return(void*); probe NewFloatArray__entry(void*, uintptr_t); probe NewFloatArray__return(void*); The attached trivial patch fixes it and makes the actual return value in those cases available. Tested against Systemtap, but the same should work for DTrace also. I don't have access to a system with solaris/dtrace on it, so it would be nice of someone who does could double check the above on such a system. Please let me know if I should create a bug also on https://bugs.openjdk.java.net/ and/or if I should report/post this patch on some other mailing-list. Thanks, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: jni-newscalararry.patch Type: text/x-patch Size: 859 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20091019/b696263f/attachment.bin From David.Holmes at Sun.COM Mon Oct 19 17:10:21 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Tue, 20 Oct 2009 10:10:21 +1000 Subject: Request for reviews (update)(S): 6863420: os::javaTimeNanos() go backward on Solaris x86] In-Reply-To: <4A6A0DD5.4090508@sun.com> References: <4A69FB66.20405@sun.com> <4A6A0DD5.4090508@sun.com> Message-ID: <4ADCFFED.4090909@sun.com> Sorry for the blast from the past ... On 07/25/09 05:39, Paul Hohensee wrote: > Nice. :) > > Sometime we should update the other os platforms with their own > implementations. > Nop for now of course. So I missed this back in July ... why didn't we define this for the other OS as needed? I assume Linux x86 has exactly the same problem. I'm backporting this to JRTS and duplicating the caching code on Linux (for uniformity) and I need Atomic::load on Linux to do that :( David > Paul > > Vladimir Kozlov wrote: >> I updated the fix to use Atomic::load() always as David H. suggested. >> >> http://cr.openjdk.java.net/~kvn/6863420/webrev.01 >> >> Fixed 6863420: os::javaTimeNanos() go backward on Solaris x86 >> >> Problem: >> The problem is non atomic load from max_hrtime in getTimeNanos() >> on platforms where long is kept in 2 32-bit register. >> The loaded value could be invalid (> current time) since registers >> are loaded separately and store could happened in between. >> It could be returned as result if it is greater then current time. >> And if the next call getTimeNanos() returns the correct time >> it will be less then previous result. >> >> Solution: >> Use new atomic long load method Atomic::load() which uses >> FPU to move long value atomically on 32-bit x86 or >> simply returns *src in other cases. >> >> Added the regression test which shows the problem. >> >> Reviewed by: >> >> Fix verified (y/n): y, regression test >> >> Other testing: >> JPRT, ScaleHarness(6784100) >> From Keith.McGuigan at Sun.COM Tue Oct 20 07:20:36 2009 From: Keith.McGuigan at Sun.COM (Keith McGuigan) Date: Tue, 20 Oct 2009 10:20:36 -0400 Subject: JNI GetObjectArrayElement mark probe ret value shadowed In-Reply-To: <1255979575.2612.32.camel@hermans.wildebeest.org> References: <1255979575.2612.32.camel@hermans.wildebeest.org> Message-ID: <4ADDC734.8000206@sun.com> Hi Mark, I'll help you out with these fixes. Let's move the rest of this to hotspot-runtime-dev at openjdk.java.net so we don't spam too many people. -- - Keith Mark Wielaard wrote: > Hi, > > In jni.cpp the DT_RETURN_MARK for GetObjectArrayElement tries to capture > the jobject ret value. But the actual ret value returned is a newly > defined jobject ret in the local scope of the if (is_within_bounds) > branch. This means when probing the return of GetObjectArrayElement the > return value always comes as as NULL. > > The following trivial patch fixes the issue and makes the actual return > value available to the return probe. > > diff -r 6ddec5389232 src/share/vm/prims/jni.cpp > --- a/src/share/vm/prims/jni.cpp Fri Oct 02 11:26:25 2009 -0700 > +++ b/src/share/vm/prims/jni.cpp Mon Oct 19 21:10:11 2009 +0200 > @@ -2116,7 +2116,7 @@ > DT_RETURN_MARK(GetObjectArrayElement, jobject, (const jobject&)ret); > objArrayOop a = objArrayOop(JNIHandles::resolve_non_null(array)); > if (a->is_within_bounds(index)) { > - jobject ret = JNIHandles::make_local(env, a->obj_at(index)); > + ret = JNIHandles::make_local(env, a->obj_at(index)); > return ret; > } else { > char buf[jintAsStringSize]; > > Tested against Systemtap, but the same should work for DTrace also. > I don't have access to a system with solaris/dtrace on it, so it would > be nice of someone who does could double check the above on such a > system. > > Please let me know if I should create a bug also on > https://bugs.openjdk.java.net/ and/or if I should report/post this patch > on some other mailing-list. > > Thanks, > > Mark > From Vladimir.Kozlov at Sun.COM Tue Oct 20 10:02:59 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 20 Oct 2009 10:02:59 -0700 Subject: Request for reviews (update)(S): 6863420: os::javaTimeNanos() go backward on Solaris x86] In-Reply-To: <4ADCFFED.4090909@sun.com> References: <4A69FB66.20405@sun.com> <4A6A0DD5.4090508@sun.com> <4ADCFFED.4090909@sun.com> Message-ID: <4ADDED43.1060308@sun.com> David Holmes - Sun Microsystems wrote: > Sorry for the blast from the past ... > > On 07/25/09 05:39, Paul Hohensee wrote: >> Nice. :) >> >> Sometime we should update the other os platforms with their own >> implementations. >> Nop for now of course. > > So I missed this back in July ... why didn't we define this for the > other OS as needed? I assume Linux x86 has exactly the same problem. I am not Linux expert but based on comments in os_linux.cpp in os::Linux::clock_init() newest kernels support monotonic clock so we don't need to cache timer for them. Vladimir > backporting this to JRTS and duplicating the caching code on Linux (for > uniformity) and I need Atomic::load on Linux to do that :( > > David > >> Paul >> >> Vladimir Kozlov wrote: >>> I updated the fix to use Atomic::load() always as David H. suggested. >>> >>> http://cr.openjdk.java.net/~kvn/6863420/webrev.01 >>> >>> Fixed 6863420: os::javaTimeNanos() go backward on Solaris x86 >>> >>> Problem: >>> The problem is non atomic load from max_hrtime in getTimeNanos() >>> on platforms where long is kept in 2 32-bit register. >>> The loaded value could be invalid (> current time) since registers >>> are loaded separately and store could happened in between. >>> It could be returned as result if it is greater then current time. >>> And if the next call getTimeNanos() returns the correct time >>> it will be less then previous result. >>> >>> Solution: >>> Use new atomic long load method Atomic::load() which uses >>> FPU to move long value atomically on 32-bit x86 or >>> simply returns *src in other cases. >>> >>> Added the regression test which shows the problem. >>> >>> Reviewed by: >>> >>> Fix verified (y/n): y, regression test >>> >>> Other testing: >>> JPRT, ScaleHarness(6784100) >>> From David.Holmes at Sun.COM Tue Oct 20 10:22:24 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Wed, 21 Oct 2009 03:22:24 +1000 Subject: Request for reviews (update)(S): 6863420: os::javaTimeNanos() go backward on Solaris x86] In-Reply-To: <4ADDED43.1060308@sun.com> References: <4A69FB66.20405@sun.com> <4A6A0DD5.4090508@sun.com> <4ADCFFED.4090909@sun.com> <4ADDED43.1060308@sun.com> Message-ID: <4ADDF1D0.6090503@sun.com> On 10/21/09 03:02, Vladimir Kozlov wrote: > David Holmes - Sun Microsystems wrote: >> Sorry for the blast from the past ... >> >> On 07/25/09 05:39, Paul Hohensee wrote: >>> Nice. :) >>> >>> Sometime we should update the other os platforms with their own >>> implementations. >>> Nop for now of course. >> >> So I missed this back in July ... why didn't we define this for the >> other OS as needed? I assume Linux x86 has exactly the same problem. > > I am not Linux expert but based on comments in os_linux.cpp in > os::Linux::clock_init() newest kernels support monotonic clock > so we don't need to cache timer for them. Solaris gethrtime is also "guaranteed" to be monotonic - except there were bugs in that area and so we needed to enforce it ourselves. There's no reason to assume that the CLOCK_MONOTONIC clock might not also be non-monotonic on some platforms at some time - in fact we (Java RTS) have an open bug with RedHat MRG (real-time linux) precisely because on some systems we saw non-monotonic behaviour (which fortunately disappeared ...). But I was referring more to defining Atomic::load on all platforms, even if we didn't have a definite use for it at the time on Linux. (Aside: I still wonder whether we have other places where we might have this same word-tearing issue.) Cheers, David > Vladimir > >> backporting this to JRTS and duplicating the caching code on Linux >> (for uniformity) and I need Atomic::load on Linux to do that :( >> >> David >> >>> Paul >>> >>> Vladimir Kozlov wrote: >>>> I updated the fix to use Atomic::load() always as David H. suggested. >>>> >>>> http://cr.openjdk.java.net/~kvn/6863420/webrev.01 >>>> >>>> Fixed 6863420: os::javaTimeNanos() go backward on Solaris x86 >>>> >>>> Problem: >>>> The problem is non atomic load from max_hrtime in getTimeNanos() >>>> on platforms where long is kept in 2 32-bit register. >>>> The loaded value could be invalid (> current time) since registers >>>> are loaded separately and store could happened in between. >>>> It could be returned as result if it is greater then current time. >>>> And if the next call getTimeNanos() returns the correct time >>>> it will be less then previous result. >>>> >>>> Solution: >>>> Use new atomic long load method Atomic::load() which uses >>>> FPU to move long value atomically on 32-bit x86 or >>>> simply returns *src in other cases. >>>> >>>> Added the regression test which shows the problem. >>>> >>>> Reviewed by: >>>> >>>> Fix verified (y/n): y, regression test >>>> >>>> Other testing: >>>> JPRT, ScaleHarness(6784100) >>>> From antonios.printezis at sun.com Tue Oct 20 18:02:35 2009 From: antonios.printezis at sun.com (antonios.printezis at sun.com) Date: Wed, 21 Oct 2009 01:02:35 +0000 Subject: hg: jdk7/hotspot/hotspot: 9 new changesets Message-ID: <20091021010257.789AA41FB2@hg.openjdk.java.net> Changeset: 8afee153274a Author: jcoomes Date: 2009-10-05 05:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8afee153274a 6887948: test/gc/6845368/bigobj.java fails due to timeout Reviewed-by: iveresov ! test/gc/6845368/bigobj.java Changeset: 035d2e036a9b Author: tonyp Date: 2009-10-02 16:12 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/035d2e036a9b 6885041: G1: inconsistent thread dump Summary: When G1 is enabled, thread dumps are inconsistent as the info for some of the G1 threads is not formatted properly. Reviewed-by: ysr, johnc ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.cpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: ff2402f6a50b Author: tonyp Date: 2009-10-02 16:20 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ff2402f6a50b 6882730: G1: parallel heap verification messes up region dump Summary: It tidies up the G1 heap verification a bit. In particular, when the verification is done in parallel and there is a failure, this is propagated to the top level and the heap is dumped at the end, not by every thread that encounters a failure. Reviewed-by: johnc, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 1f19207eefc2 Author: tonyp Date: 2009-10-05 12:05 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1f19207eefc2 6847956: G1: crash in oopDesc*G1ParCopyHelper::copy_to_survivor_space(oopDesc*) Summary: When we copy objects to survivors during marking, we incorrectly set NTAMS to bottom, which causes marking to miss visiting some of those objects. Reviewed-by: apetrusenko, iveresov ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 4c3458a31e17 Author: tonyp Date: 2009-10-07 09:42 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4c3458a31e17 6888316: G1: has_aborted() || _cm->region_stack_empty() fails Summary: Remove incorrect guarantee. Reviewed-by: apetrusenko, iveresov ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 11d4857fe5e1 Author: tonyp Date: 2009-10-07 10:09 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/11d4857fe5e1 6888619: G1: too many guarantees in concurrent marking Summary: change more guarantees in concurrent marking into asserts. Reviewed-by: apetrusenko, iveresov ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: 2c03ce058f55 Author: bobv Date: 2009-10-07 09:48 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2c03ce058f55 6888847: TaskQueue needs release_store() for correctness on RMO machines Summary: See title. Reviewed-by: jmasa, ysr, jcoomes, iveresov, tonyp ! src/share/vm/utilities/taskqueue.hpp Changeset: 1ee412f7fec9 Author: tonyp Date: 2009-10-07 19:01 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1ee412f7fec9 6866190: Remove SIMPLE_STACK code from TaskQueue Summary: What the title says. We don't use SIMPLE_STACK any more. Reviewed-by: ysr ! src/share/vm/utilities/taskqueue.hpp Changeset: f99f695bb8ef Author: tonyp Date: 2009-10-19 17:02 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f99f695bb8ef Merge ! src/share/vm/gc_implementation/g1/concurrentZFThread.cpp From antonios.printezis at sun.com Tue Oct 20 22:54:58 2009 From: antonios.printezis at sun.com (antonios.printezis at sun.com) Date: Wed, 21 Oct 2009 05:54:58 +0000 Subject: hg: hsx/hsx16/baseline: 6893095: G1: bulk G1 backports to hs16 Message-ID: <20091021055500.DABAB412A7@hg.openjdk.java.net> Changeset: 6de2c9c36168 Author: tonyp Date: 2009-10-20 19:55 -0400 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/6de2c9c36168 6893095: G1: bulk G1 backports to hs16 Summary: Backports of CRs 6888619, 6888316, 6847956, 6882730, 6885041, 6887186, and 6861557. Reviewed-by: never, ysr, johnc, jmasa, apetrusenko, iveresov ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.cpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp From volker.simonis at gmail.com Wed Oct 21 08:00:39 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 21 Oct 2009 17:00:39 +0200 Subject: Combining changests considered harmfull? (Re: hg: hsx/hsx16/baseline: 6893095: G1: bulk G1 backports to hs16) Message-ID: Hi Tony, referring to your last change I just wanted to raise the question if there's a general policy in place with regard to combined changesets and if combined changesets should be considered harmful? I understand that combining several changesets into one big changeset as you did may considerably simplify the integration of changes from one repository into another one. But at which prize? If somebody is looking at the bug description of 6888619, he won't be able to see that 6888619 is fixed in hsx16. He won't even see that 6888619 is related to 6893095, although the fix for 6888619 is a part of the fix for 6893095. Even if somebody is just browsing hsx16, he won't see at a first glance that 6888619 was fixed in hsx16, because until now, the convention is that the bug ID is the first word of a change description, but in the case of 6893095, the bug ID of 6888619 only appears in the summary field the description for 6893095. I already noticed this kind of slackness in hsx14.1 when the fixes for the three bugs 6786503, 6787254 and 6821507 where submitted as a single changeset for 6786503. This is of course worse, because here there isn't even an umbrella changesets which describes which other changeset it contains. In general I would strongly vote against such mixing and combination of changesets from one repository into others even if this comes at the prize of a bigger merge overhead because it makes tracking of changes extremely difficult. I think Mercurial offers enough possibilities for the task of transferring changesets from one repository into another even if the repositories aren't related (e.g. import/export or transplant (http://mercurial.selenic.com/wiki/TransplantExtension)). What do you think? Has this issue been discussed previously? Regards, Volker On 10/21/09, antonios.printezis at sun.com wrote: > Changeset: 6de2c9c36168 > Author: tonyp > Date: 2009-10-20 19:55 -0400 > URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/6de2c9c36168 > > 6893095: G1: bulk G1 backports to hs16 > Summary: Backports of CRs 6888619, 6888316, 6847956, 6882730, 6885041, 6887186, and 6861557. > Reviewed-by: never, ysr, johnc, jmasa, apetrusenko, iveresov > > ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp > ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp > ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp > ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp > ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp > ! src/share/vm/gc_implementation/g1/concurrentMark.cpp > ! src/share/vm/gc_implementation/g1/concurrentMark.hpp > ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp > ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp > ! src/share/vm/gc_implementation/g1/concurrentZFThread.cpp > ! src/share/vm/gc_implementation/g1/concurrentZFThread.hpp > ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp > ! src/share/vm/gc_implementation/g1/heapRegion.cpp > ! src/share/vm/gc_implementation/g1/heapRegion.hpp > ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp > > From gnu_andrew at member.fsf.org Wed Oct 21 08:33:08 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 21 Oct 2009 16:33:08 +0100 Subject: Combining changests considered harmfull? (Re: hg: hsx/hsx16/baseline: 6893095: G1: bulk G1 backports to hs16) In-Reply-To: References: Message-ID: <17c6771e0910210833g312d60iccfe99303b755f03@mail.gmail.com> 2009/10/21 Volker Simonis : > Hi Tony, > > referring to your last change I just wanted to raise the question if > there's a general policy in place with regard to combined changesets > and if combined changesets should be considered harmful? > > I understand that combining several changesets into one big changeset > as you did may considerably simplify the integration of changes from > one repository into another one. But at which prize? > > If somebody is looking at the bug description of 6888619, he won't be > able to see that 6888619 is fixed in hsx16. He won't even see that > 6888619 is related to 6893095, although the fix for 6888619 is a part > of the fix for 6893095. Even if somebody is just browsing hsx16, he > won't see at a first glance that 6888619 was fixed in hsx16, because > until now, the convention is that the bug ID is the first word of a > change description, but in the case of 6893095, the bug ID of 6888619 > only appears in the summary field the description for 6893095. > > I already noticed this kind of slackness in hsx14.1 when the fixes for > the three bugs 6786503, 6787254 and 6821507 where submitted as a > single changeset for 6786503. This is of course worse, because here > there isn't even an umbrella changesets which describes which other > changeset it contains. > > In general I would strongly vote against such mixing and combination > of changesets from one repository into others even if this comes at > the prize of a bigger merge overhead because it makes tracking of > changes extremely difficult. I think Mercurial offers enough > possibilities for the task of transferring changesets from one > repository into another even if the repositories aren't related (e.g. > import/export or ?transplant > (http://mercurial.selenic.com/wiki/TransplantExtension)). > > What do you think? Has this issue been discussed previously? > > Regards, > Volker > > On 10/21/09, antonios.printezis at sun.com wrote: >> Changeset: 6de2c9c36168 >> ?Author: ? ?tonyp >> ?Date: ? ? ?2009-10-20 19:55 -0400 >> ?URL: ? ? ? http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/6de2c9c36168 >> >> ?6893095: G1: bulk G1 backports to hs16 >> ?Summary: Backports of CRs 6888619, 6888316, 6847956, 6882730, 6885041, 6887186, and 6861557. >> ?Reviewed-by: never, ysr, johnc, jmasa, apetrusenko, iveresov >> >> ?! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp >> ?! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp >> ?! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp >> ?! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp >> ?! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp >> ?! src/share/vm/gc_implementation/g1/concurrentMark.cpp >> ?! src/share/vm/gc_implementation/g1/concurrentMark.hpp >> ?! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp >> ?! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp >> ?! src/share/vm/gc_implementation/g1/concurrentZFThread.cpp >> ?! src/share/vm/gc_implementation/g1/concurrentZFThread.hpp >> ?! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp >> ?! src/share/vm/gc_implementation/g1/heapRegion.cpp >> ?! src/share/vm/gc_implementation/g1/heapRegion.hpp >> ?! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp >> >> > Hi Volker, I just saw this changeset too and was about to comment as well. I agree wholeheartedly with what you're saying. It's pretty trivial to transplant changesets with Mercurial; hg export | hg import - will do the job, and the transplant extension makes it simpler still. I do this regularly with JDK7->JDK6, IcedTea6->IcedTea7, etc. This bulk commit seems more trouble to be honest, as you have to allocate another bug ID for it, whereas porting the patches individually would just use the same ID per patch! -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From tony.printezis at sun.com Wed Oct 21 09:24:45 2009 From: tony.printezis at sun.com (Tony Printezis) Date: Wed, 21 Oct 2009 12:24:45 -0400 Subject: Combining changests considered harmfull? (Re: hg: hsx/hsx16/baseline: 6893095: G1: bulk G1 backports to hs16) In-Reply-To: References: Message-ID: <4ADF35CD.20309@sun.com> Volker, Hi. I understand your point and I'm with you. The reason I pushed one changeset, instead of many, was not convenience (in fact, it was a bit more work to create the single changeset, instead of using transplant as Andrew pointed out, to transfer the changesets I needed). I needed to get approval for the push to hs16 and I was told that it was easiest to create a blanket CR and file one approval request. Nothing more to say. Tony Volker Simonis wrote: > Hi Tony, > > referring to your last change I just wanted to raise the question if > there's a general policy in place with regard to combined changesets > and if combined changesets should be considered harmful? > > I understand that combining several changesets into one big changeset > as you did may considerably simplify the integration of changes from > one repository into another one. But at which prize? > > If somebody is looking at the bug description of 6888619, he won't be > able to see that 6888619 is fixed in hsx16. He won't even see that > 6888619 is related to 6893095, although the fix for 6888619 is a part > of the fix for 6893095. Even if somebody is just browsing hsx16, he > won't see at a first glance that 6888619 was fixed in hsx16, because > until now, the convention is that the bug ID is the first word of a > change description, but in the case of 6893095, the bug ID of 6888619 > only appears in the summary field the description for 6893095. > > I already noticed this kind of slackness in hsx14.1 when the fixes for > the three bugs 6786503, 6787254 and 6821507 where submitted as a > single changeset for 6786503. This is of course worse, because here > there isn't even an umbrella changesets which describes which other > changeset it contains. > > In general I would strongly vote against such mixing and combination > of changesets from one repository into others even if this comes at > the prize of a bigger merge overhead because it makes tracking of > changes extremely difficult. I think Mercurial offers enough > possibilities for the task of transferring changesets from one > repository into another even if the repositories aren't related (e.g. > import/export or transplant > (http://mercurial.selenic.com/wiki/TransplantExtension)). > > What do you think? Has this issue been discussed previously? > > Regards, > Volker > > On 10/21/09, antonios.printezis at sun.com wrote: > >> Changeset: 6de2c9c36168 >> Author: tonyp >> Date: 2009-10-20 19:55 -0400 >> URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/6de2c9c36168 >> >> 6893095: G1: bulk G1 backports to hs16 >> Summary: Backports of CRs 6888619, 6888316, 6847956, 6882730, 6885041, 6887186, and 6861557. >> Reviewed-by: never, ysr, johnc, jmasa, apetrusenko, iveresov >> >> ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp >> ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp >> ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp >> ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp >> ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp >> ! src/share/vm/gc_implementation/g1/concurrentMark.cpp >> ! src/share/vm/gc_implementation/g1/concurrentMark.hpp >> ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp >> ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp >> ! src/share/vm/gc_implementation/g1/concurrentZFThread.cpp >> ! src/share/vm/gc_implementation/g1/concurrentZFThread.hpp >> ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp >> ! src/share/vm/gc_implementation/g1/heapRegion.cpp >> ! src/share/vm/gc_implementation/g1/heapRegion.hpp >> ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp >> >> >> -- --------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS UBUR02-311 | | e-mail: tony.printezis at sun.com | 35 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA | --------------------------------------------------------------------- e-mail client: Thunderbird (Linux) From gnu_andrew at member.fsf.org Wed Oct 21 16:53:27 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 22 Oct 2009 00:53:27 +0100 Subject: Combining changests considered harmfull? (Re: hg: hsx/hsx16/baseline: 6893095: G1: bulk G1 backports to hs16) In-Reply-To: <4ADF35CD.20309@sun.com> References: <4ADF35CD.20309@sun.com> Message-ID: <17c6771e0910211653s3020376ch1ec447bc903fdbc0@mail.gmail.com> 2009/10/21 Tony Printezis : > Volker, > > Hi. I understand your point and I'm with you. The reason I pushed one > changeset, instead of many, was not convenience (in fact, it was a bit more > work to create the single changeset, instead of using transplant as Andrew > pointed out, to transfer the changesets I needed). I needed to get approval > for the push to hs16 and I was told that it was easiest to create a blanket > CR and file one approval request. Nothing more to say. > > Tony > > Volker Simonis wrote: >> >> Hi Tony, >> >> referring to your last change I just wanted to raise the question if >> there's a general policy in place with regard to combined changesets >> and if combined changesets should be considered harmful? >> >> I understand that combining several changesets into one big changeset >> as you did may considerably simplify the integration of changes from >> one repository into another one. But at which prize? >> >> If somebody is looking at the bug description of 6888619, he won't be >> able to see that 6888619 is fixed in hsx16. He won't even see that >> 6888619 is related to 6893095, although the fix for 6888619 is a part >> of the fix for 6893095. Even if somebody is just browsing hsx16, he >> won't see at a first glance that 6888619 was fixed in hsx16, because >> until now, the convention is that the bug ID is the first word of a >> change description, but in the case of 6893095, the bug ID of 6888619 >> only appears in the summary field the description for 6893095. >> >> I already noticed this kind of slackness in hsx14.1 when the fixes for >> the three bugs 6786503, 6787254 and 6821507 where submitted as a >> single changeset for 6786503. This is of course worse, because here >> there isn't even an umbrella changesets which describes which other >> changeset it contains. >> >> In general I would strongly vote against such mixing and combination >> of changesets from one repository into others even if this comes at >> the prize of a bigger merge overhead because it makes tracking of >> changes extremely difficult. I think Mercurial offers enough >> possibilities for the task of transferring changesets from one >> repository into another even if the repositories aren't related (e.g. >> import/export or ?transplant >> (http://mercurial.selenic.com/wiki/TransplantExtension)). >> >> What do you think? Has this issue been discussed previously? >> >> Regards, >> Volker >> >> On 10/21/09, antonios.printezis at sun.com >> wrote: >> >>> >>> Changeset: 6de2c9c36168 >>> ?Author: ? ?tonyp >>> ?Date: ? ? ?2009-10-20 19:55 -0400 >>> ?URL: >>> http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/6de2c9c36168 >>> >>> ?6893095: G1: bulk G1 backports to hs16 >>> ?Summary: Backports of CRs 6888619, 6888316, 6847956, 6882730, 6885041, >>> 6887186, and 6861557. >>> ?Reviewed-by: never, ysr, johnc, jmasa, apetrusenko, iveresov >>> >>> ?! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp >>> ?! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp >>> ?! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp >>> ?! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp >>> ?! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp >>> ?! src/share/vm/gc_implementation/g1/concurrentMark.cpp >>> ?! src/share/vm/gc_implementation/g1/concurrentMark.hpp >>> ?! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp >>> ?! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp >>> ?! src/share/vm/gc_implementation/g1/concurrentZFThread.cpp >>> ?! src/share/vm/gc_implementation/g1/concurrentZFThread.hpp >>> ?! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp >>> ?! src/share/vm/gc_implementation/g1/heapRegion.cpp >>> ?! src/share/vm/gc_implementation/g1/heapRegion.hpp >>> ?! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp >>> >>> >>> > > -- > --------------------------------------------------------------------- > | Tony Printezis, Staff Engineer ? | Sun Microsystems Inc. ? ? ? ? ?| > | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| MS UBUR02-311 ? ? ? ? ? ? ? ? ?| > | e-mail: tony.printezis at sun.com ? | 35 Network Drive ? ? ? ? ? ? ? | > | office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA | > --------------------------------------------------------------------- > e-mail client: Thunderbird (Linux) > > > You can roll multiple changesets into one webrev for review, so ease of approval isn't really an excuse either. Seems you've been misinformed somewhere along the line... :) I did just that for the merging of hs14 into OpenJDK6; 554 changesets, one webrev. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From abhijit.saha at sun.com Wed Oct 21 18:55:33 2009 From: abhijit.saha at sun.com (abhijit.saha at sun.com) Date: Thu, 22 Oct 2009 01:55:33 +0000 Subject: hg: hsx/hsx16/baseline: 6858208: jvm crash when specifying TypeProfileWidth=0 on jdk 6.0 Message-ID: <20091022015538.7F2C041494@hg.openjdk.java.net> Changeset: 47ca7aa20d97 Author: asaha Date: 2009-10-21 15:43 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/47ca7aa20d97 6858208: jvm crash when specifying TypeProfileWidth=0 on jdk 6.0 Reviewed-by: never ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp From y.s.ramakrishna at sun.com Wed Oct 21 19:14:25 2009 From: y.s.ramakrishna at sun.com (y.s.ramakrishna at sun.com) Date: Thu, 22 Oct 2009 02:14:25 +0000 Subject: hg: hsx/hsx16/baseline: 4 new changesets Message-ID: <20091022021438.168C24149A@hg.openjdk.java.net> Changeset: aa001a20bd61 Author: ysr Date: 2009-10-16 02:05 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/aa001a20bd61 6888898: CMS: ReduceInitialCardMarks unsafe in the presence of cms precleaning 6889757: G1: enable card mark elision for initializing writes from compiled code (ReduceInitialCardMarks) Summary: Defer the (compiler-elided) card-mark upon a slow-path allocation until after the store and before the next subsequent safepoint; G1 now answers yes to can_elide_tlab_write_barriers(). Reviewed-by: jcoomes, kvn, never ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.inline.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 164505f3849e Author: ysr Date: 2009-10-20 00:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/164505f3849e 6892749: assert(UseParNewGC || UseSerialGC || UseConcMarkSweepGC, "...") fails Summary: Removed the assert: UseSerialGC is not necessarily always set when serial gc is being used. Reviewed-by: jcoomes, jmasa, tonyp ! src/share/vm/memory/genCollectedHeap.hpp Changeset: d43a7bf86266 Author: ysr Date: 2009-10-21 12:35 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/d43a7bf86266 Merge Changeset: aa83c08db78c Author: ysr Date: 2009-10-21 19:13 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/aa83c08db78c Merge From y.s.ramakrishna at sun.com Wed Oct 21 21:06:37 2009 From: y.s.ramakrishna at sun.com (y.s.ramakrishna at sun.com) Date: Thu, 22 Oct 2009 04:06:37 +0000 Subject: hg: hsx/hsx16/baseline: 2 new changesets Message-ID: <20091022040643.DAC0F414B8@hg.openjdk.java.net> Changeset: b7e7fc226009 Author: ysr Date: 2009-10-21 18:57 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/b7e7fc226009 Merge Changeset: 0537635c7c16 Author: ysr Date: 2009-10-21 21:06 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/0537635c7c16 Merge From erik.trimble at sun.com Thu Oct 22 01:05:22 2009 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Thu, 22 Oct 2009 08:05:22 +0000 Subject: hg: hsx/hsx16/master: 10 new changesets Message-ID: <20091022080553.5D6694150D@hg.openjdk.java.net> Changeset: 6de2c9c36168 Author: tonyp Date: 2009-10-20 19:55 -0400 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/6de2c9c36168 6893095: G1: bulk G1 backports to hs16 Summary: Backports of CRs 6888619, 6888316, 6847956, 6882730, 6885041, 6887186, and 6861557. Reviewed-by: never, ysr, johnc, jmasa, apetrusenko, iveresov ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.cpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp Changeset: 47ca7aa20d97 Author: asaha Date: 2009-10-21 15:43 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/47ca7aa20d97 6858208: jvm crash when specifying TypeProfileWidth=0 on jdk 6.0 Reviewed-by: never ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp Changeset: aa001a20bd61 Author: ysr Date: 2009-10-16 02:05 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/aa001a20bd61 6888898: CMS: ReduceInitialCardMarks unsafe in the presence of cms precleaning 6889757: G1: enable card mark elision for initializing writes from compiled code (ReduceInitialCardMarks) Summary: Defer the (compiler-elided) card-mark upon a slow-path allocation until after the store and before the next subsequent safepoint; G1 now answers yes to can_elide_tlab_write_barriers(). Reviewed-by: jcoomes, kvn, never ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.inline.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 164505f3849e Author: ysr Date: 2009-10-20 00:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/164505f3849e 6892749: assert(UseParNewGC || UseSerialGC || UseConcMarkSweepGC, "...") fails Summary: Removed the assert: UseSerialGC is not necessarily always set when serial gc is being used. Reviewed-by: jcoomes, jmasa, tonyp ! src/share/vm/memory/genCollectedHeap.hpp Changeset: d43a7bf86266 Author: ysr Date: 2009-10-21 12:35 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/d43a7bf86266 Merge Changeset: aa83c08db78c Author: ysr Date: 2009-10-21 19:13 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/aa83c08db78c Merge Changeset: b7e7fc226009 Author: ysr Date: 2009-10-21 18:57 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/b7e7fc226009 Merge Changeset: 0537635c7c16 Author: ysr Date: 2009-10-21 21:06 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/0537635c7c16 Merge Changeset: 06264910ac5f Author: trims Date: 2009-10-21 21:31 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/06264910ac5f 6893995: Bump the HS16 build number to 11 Summary: Update the HS16 build number to 11 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 38b152ff0cac Author: trims Date: 2009-10-21 21:34 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/master/rev/38b152ff0cac 6893996: change default JPRT release target to be 6u18 Summary: the default -release target for hs16 should be jdk6u18 Reviewed-by: jcoomes ! make/jprt.properties From erik.trimble at sun.com Thu Oct 22 01:14:22 2009 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Thu, 22 Oct 2009 08:14:22 +0000 Subject: hg: hsx/hsx16/baseline: 2 new changesets Message-ID: <20091022081429.44DF54150F@hg.openjdk.java.net> Changeset: 06264910ac5f Author: trims Date: 2009-10-21 21:31 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/06264910ac5f 6893995: Bump the HS16 build number to 11 Summary: Update the HS16 build number to 11 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 38b152ff0cac Author: trims Date: 2009-10-21 21:34 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/38b152ff0cac 6893996: change default JPRT release target to be 6u18 Summary: the default -release target for hs16 should be jdk6u18 Reviewed-by: jcoomes ! make/jprt.properties From Keith.McGuigan at Sun.COM Thu Oct 22 08:17:33 2009 From: Keith.McGuigan at Sun.COM (Keith McGuigan) Date: Thu, 22 Oct 2009 11:17:33 -0400 Subject: JNI DEFINE_NEWSCALARARRAY uses DT_RETURN_MARK_DECL_FOR In-Reply-To: <1255981409.2612.44.camel@hermans.wildebeest.org> References: <1255981409.2612.44.camel@hermans.wildebeest.org> Message-ID: <4AE0778D.6030403@sun.com> Thank you for these fixes, Mark, I've integrated them into http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot and they'll bubble up to the other repos (hotspot/hotspot and jdk7/hotspot) soon. Please refer to CR 6893483 to track these fixes. -- - Keith Mark Wielaard wrote: > Hi, > > In jni.cpp the DEFINE_NEWSCALARARRAY macro uses DT_RETURN_MARK_DECL_FOR > instead of the normal DT_RETURN_MARK_DECL. The DT_RETURN_MARK_DECL_FOR > macro should only be used for mark probes that could return a primitive > jfloat or jdouble. But DEFINE_NEWSCALARARRAY creates the functions for > NewArray which return primitiveTypeArrays. This means that for > NewFloatArray and NewDoubleArray you cannot get the return value in the > return mark probe. > > According to hotspot_jni.d the intention is to return these values in > those cases: > > probe NewDoubleArray__entry(void*, uintptr_t); > probe NewDoubleArray__return(void*); > probe NewFloatArray__entry(void*, uintptr_t); > probe NewFloatArray__return(void*); > > The attached trivial patch fixes it and makes the actual return value in > those cases available. > > Tested against Systemtap, but the same should work for DTrace also. > I don't have access to a system with solaris/dtrace on it, so it would > be nice of someone who does could double check the above on such a > system. > > Please let me know if I should create a bug also on > https://bugs.openjdk.java.net/ and/or if I should report/post this patch > on some other mailing-list. > > Thanks, > > Mark > From antonios.printezis at sun.com Fri Oct 23 11:25:27 2009 From: antonios.printezis at sun.com (antonios.printezis at sun.com) Date: Fri, 23 Oct 2009 18:25:27 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20091023182539.F2D0041781@hg.openjdk.java.net> Changeset: 39b01ab7035a Author: ysr Date: 2009-10-16 02:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/39b01ab7035a 6888898: CMS: ReduceInitialCardMarks unsafe in the presence of cms precleaning 6889757: G1: enable card mark elision for initializing writes from compiled code (ReduceInitialCardMarks) Summary: Defer the (compiler-elided) card-mark upon a slow-path allocation until after the store and before the next subsequent safepoint; G1 now answers yes to can_elide_tlab_write_barriers(). Reviewed-by: jcoomes, kvn, never ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.inline.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 052a899eec3e Author: ysr Date: 2009-10-20 00:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/052a899eec3e 6892749: assert(UseParNewGC || UseSerialGC || UseConcMarkSweepGC, "...") fails Summary: Removed the assert: UseSerialGC is not necessarily always set when serial gc is being used. Reviewed-by: jcoomes, jmasa, tonyp ! src/share/vm/memory/genCollectedHeap.hpp Changeset: b0b36f0de97e Author: tonyp Date: 2009-10-20 11:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b0b36f0de97e Merge Changeset: dfdaf65c3423 Author: apetrusenko Date: 2009-10-22 07:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/dfdaf65c3423 6858886: G1: guarantee(_next_marked_bytes <= used(),"invariant") at heapRegion.hpp:359 Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp From erik.trimble at sun.com Fri Oct 23 17:53:49 2009 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Sat, 24 Oct 2009 00:53:49 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20091024005359.8775F417F0@hg.openjdk.java.net> Changeset: 67a9176de85c Author: trims Date: 2009-10-23 14:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/67a9176de85c 6894844: Bump the HS17 build number to 04 Summary: Update the HS17 build number to 04 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 411c9c4ca96a Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/411c9c4ca96a Added tag jdk7-b74 for changeset f4b900403d6e ! .hgtags Changeset: d8dd291a362a Author: trims Date: 2009-10-23 14:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d8dd291a362a Merge From Paul.Hohensee at Sun.COM Tue Oct 27 09:26:41 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Tue, 27 Oct 2009 12:26:41 -0400 Subject: Pls review 6887571 Message-ID: <4AE71F41.3030009@sun.com> 6887571: Increase default heap config sizes Webrev here http://cr.openjdk.java.net/~phh/6887571/webrev.01/ Some background: The default client vm heap config since 2000 for sparc32 has been the equivalent of -Xmx64m -XX:OldSize=4m -XX:NewSize=2m -XX:NewRatio=8 -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 and for 32-bit x86 -Xmx64m -XX:OldSize=4m -XX:NewSize=1m -XX:NewRatio=12 -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 OldSize and NewSize are the initial committed sizes of the old and young generations respectively. A minor gc is required to increase the committed size of the young gen, while a full gc is required to increase the committed size of the old gen. At the time, 64m was half of the 128m of memory typically available on high-end desktops, many client applications were satisfied with small heaps (hence the low -Xms value), and gc times were such that the young gen had to be small in order to minimize pause times. Since that time, low end desktops and laptops, as well as netbooks and smartbooks, typically come with 256m, client applications have become much more "server-like", and we've realized that a small young gen size increases the frequency of young gcs and the amount of transient data promoted to the old gen to levels that noticeably impact startup and steady-state performance, principally by provoking full gcs. This change extends server class heap sizing to the client with a few changes. Server heap sizing ergonomics should be unaffected. 1. NewRatio is set to 2 for all platforms to accomodate an increase in transient data size. 2. SurvivorRatio is set to 8 for all platforms. It was 8 for every platform except 64-bit x86 (where it was 6) in any case, so it isn't a big change. 3. MaxTenuringThreshold is left at 15 (the maximum). 4. I added MaxRAM, whose implemented definition matches the current comment for DefaultMaxRAM in globals.hpp. MaxRAM is the maximum physical memory size used to compute MaxHeapSize rather than the maximum possible value of MaxHeapSize set by ergonomics. I replaced DefaultMaxRAM with MaxErgoHeapSize for the latter purpose. I added support for a new argument type, uint64_t, and used it as the type of MaxRAM. uintx doesn't have the necessary range on 32-bit systems: a user might want to specify 4g for MaxRAM on a 32-bit system. 5. The other Default* switches have been stripped of the "Default" prefix, since to me their values are just as much "default" values as the values of any of other vm switch, and those don't have a "Default" prefix. I left DefaultMaxRAMFraction as a synonym for MaxRAMFraction for the moment because QA uses it. When they change to MaxRAMFraction, I intend to remove DefaultMaxRAMFraction. 6. In arguments.cpp, set_heap_size() replaces set_server_heap_size() and is used for everything except CMS. CMS has it's own, incompatible (I know: I tried it), heap sizing ergonomics. 7. The minimum committed size of the old gen (OldSize) remains at 4m and the minimum committed size of the young gen (NewSize) increases to 4m. Note that these are the minimum, not initial sizes. NewSize is made common to all platforms. 8. I added a switch InitialHeapSize that can be used to set the initial committed size of the heap. Absent specification by InitialHeapSize, the initial committed size is 1/64th of physical memory or OldSize + NewSize, whichever is larger. 9. I cleaned up some formatting, esp. in globals.hpp. 10. The default MaxHeapSize is raised from 64m to 96m. For systems with <= MaxHeapSize physical memory, the minimum heap size is 1/MinRAMFraction of physical memory. The default value of MinRAMFraction is 2. Thus, a 256m box gets a 96m heap, as does a 128m box, but a 96m box gets a 48m heap and a 64m box gets a 32m heap. The default values of MaxRAM and MaxRAMFraction bound the maximum heap size to 256m for the client vms, 1g for 32-bit server vms and 32g for 64-bit server vms. The values for the server vms are the same as before. I picked 256m for client because I wanted to bound resource utilization on client systems. Also, benchmarks runs showed no extra benefit from going to 512m heaps. 512m is the safe maximum for the serial collector. Thanks, Paul From Y.S.Ramakrishna at Sun.COM Tue Oct 27 12:22:54 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Tue, 27 Oct 2009 12:22:54 -0700 Subject: Pls review 6887571 In-Reply-To: <4AE71F41.3030009@sun.com> References: <4AE71F41.3030009@sun.com> Message-ID: <4AE7488E.2010408@Sun.COM> Hi Paul -- Did you forget to remove the commenting out of the second conjunct in arguments.cpp:1383 below:- 1383 if (PrintGCDetails/* && Verbose*/) { Could you do me a favour and change the following in arguments.cpp:1612 from:- 1612 if (UseSharedSpaces) { to:- 1612 if (UseSharedSpaces && Verbose) { The verbosity of the message at 1613:1615 has been bothering some of us for a while (mea culpa for adding it recentkly), but i didn't get around to removing it, and this looks like an good opportunity to do so with no new overhead :-) On 10/27/09 09:26, Paul Hohensee wrote: ... > 6. In arguments.cpp, set_heap_size() replaces set_server_heap_size() and > is used for everything > except CMS. CMS has it's own, incompatible (I know: I tried it), heap > sizing ergonomics. Could you provide the result of:- % java -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -version with the baseline VM and with the VM after yr changes? Rest looks good to me; thanks! -- ramki From Y.S.Ramakrishna at Sun.COM Tue Oct 27 12:27:17 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Tue, 27 Oct 2009 12:27:17 -0700 Subject: Pls review 6887571 In-Reply-To: <4AE7488E.2010408@Sun.COM> References: <4AE71F41.3030009@sun.com> <4AE7488E.2010408@Sun.COM> Message-ID: <4AE74995.2060208@Sun.COM> On 10/27/09 12:22, Y.S.Ramakrishna at Sun.COM wrote: ... > On 10/27/09 09:26, Paul Hohensee wrote: > ... >> 6. In arguments.cpp, set_heap_size() replaces set_server_heap_size() >> and is used for everything >> except CMS. CMS has it's own, incompatible (I know: I tried it), heap >> sizing ergonomics. > > Could you provide the result of:- > > % java -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -version > > with the baseline VM and with the VM after yr changes? I forgot to add: using the fastdebug build. thanks. -- ramki From Paul.Hohensee at Sun.COM Tue Oct 27 15:12:39 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Tue, 27 Oct 2009 18:12:39 -0400 Subject: Pls review 6887571 In-Reply-To: <4AE7488E.2010408@Sun.COM> References: <4AE71F41.3030009@sun.com> <4AE7488E.2010408@Sun.COM> Message-ID: <4AE77057.7050709@sun.com> Yes, I forgot to uncomment line 1383. Fixed. Fixed line 1612. It's a good thing you asked me to get cms dumps. Turned out I'd typo'ed and had an earlier version of arguments.cpp. The earlier version didn't separate cms ergo from everything-else ergo. New webrev here http://cr.openjdk.java.net/~phh/6887571/webrev.02/ With the new version, running java -client -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+Verbose -version I get VM option '+UseConcMarkSweepGC' VM option '+PrintGCDetails' VM option '+Verbose' Turning off use of shared archive because of choice of garbage collector or large pages Ergo set MaxNewSize: 134217728 CMS set min_heap_size: 0 initial_heap_size: 0 max_heap: 100663296 Ergo set NewSize: 16777216 Ergo set OldSize: 50331648 Minimum heap 67108864 Initial heap 67108864 Maximum heap 100663296 Minimum gen0 16777216 Initial gen0 16777216 Maximum gen0 16777216 Minimum gen1 50331648 Initial gen1 50331648 Maximum gen1 83886080 java version "1.7.0-ea" Java(TM) SE Runtime Environment (build 1.7.0-ea-b39) OpenJDK Client VM (build 17.0-b03-internal-jvmg, mixed mode) Heap par new generation total 14784K, used 527K [0xf1800000, 0xf2800000, 0xf2800000) eden space 13184K, 4% used [0xf1800000, 0xf1883de8, 0xf24e0000) from space 1600K, 0% used [0xf24e0000, 0xf24e0000, 0xf2670000) to space 1600K, 0% used [0xf2670000, 0xf2670000, 0xf2800000) concurrent mark-sweep generation total 49152K, used 0K [0xf2800000, 0xf5800000, 0xf7800000) concurrent-mark-sweep perm gen total 12288K, used 1497K [0xf7800000, 0xf8400000, 0xfb800000) With the unmodified vm, I get VM option '+UseConcMarkSweepGC' VM option '+PrintGCDetails' VM option '+Verbose' Turning off use of shared archive because of choice of garbage collector or large pages Ergo set MaxNewSize: 134217728 CMS set min_heap_size: 0 initial_heap_size: 0 max_heap: 67108864 Ergo set NewSize: 16777216 Ergo set OldSize: 50331648 Minimum heap 67108864 Initial heap 67108864 Maximum heap 67108864 Minimum gen0 16777216 Initial gen0 16777216 Maximum gen0 16777216 Minimum gen1 50331648 Initial gen1 50331648 Maximum gen1 50331648 java version "1.7.0-ea" Java(TM) SE Runtime Environment (build 1.7.0-ea-b39) OpenJDK Client VM (build 17.0-b03-internal-jvmg, mixed mode) Heap par new generation total 14784K, used 527K [0xf3800000, 0xf4800000, 0xf4800000) eden space 13184K, 4% used [0xf3800000, 0xf3883de8, 0xf44e0000) from space 1600K, 0% used [0xf44e0000, 0xf44e0000, 0xf4670000) to space 1600K, 0% used [0xf4670000, 0xf4670000, 0xf4800000) concurrent mark-sweep generation total 49152K, used 0K [0xf4800000, 0xf7800000, 0xf7800000) concurrent-mark-sweep perm gen total 12288K, used 1497K [0xf7800000, 0xf8400000, 0xfb800000) They're identical, except for the total heap size and ergo-computed old gen size, which are 96m and 80m respectively. That's because I increased the value of MaxNewSize from 64m to 96m. -server instead of -client produces the same result. Paul Y.S.Ramakrishna at Sun.COM wrote: > Hi Paul -- > > Did you forget to remove the commenting out of the second conjunct in > arguments.cpp:1383 below:- > > 1383 if (PrintGCDetails/* && Verbose*/) { Yes, fixed. > > Could you do me a favour and change the following in > arguments.cpp:1612 from:- > > 1612 if (UseSharedSpaces) { > > to:- > > 1612 if (UseSharedSpaces && Verbose) { > > The verbosity of the message at 1613:1615 has been > bothering some of us for a while (mea culpa for adding > it recentkly), but i didn't get around to removing it, and this > looks like an good opportunity to do so with no new overhead :-) Done. > > On 10/27/09 09:26, Paul Hohensee wrote: > ... >> 6. In arguments.cpp, set_heap_size() replaces set_server_heap_size() >> and is used for everything >> except CMS. CMS has it's own, incompatible (I know: I tried it), >> heap sizing ergonomics. > > Could you provide the result of:- > > % java -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -version > > with the baseline VM and with the VM after yr changes? > > > Rest looks good to me; thanks! > -- ramki > From Jon.Masamitsu at Sun.COM Tue Oct 27 15:52:27 2009 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Tue, 27 Oct 2009 15:52:27 -0700 Subject: Pls review 6887571 In-Reply-To: <4AE71F41.3030009@sun.com> References: <4AE71F41.3030009@sun.com> Message-ID: <4AE779AB.3040907@Sun.COM> Paul, Just a couple of comments from the .01 version of the webrev. I haven't started the .02 version yet so may have more comments after I do. Jon arguments.cpp 1105 InitialHeapSize = min_new + OldSize; Use FLAG_SET_ERGO() FLAG_SET_ERGO(uintx, InitialHeapSize, min_new + OldSize); Sometimes in the setting of the GC policies we like to know how the flag was set. I like ErgoHeapSizeLimit instead of MaxErgoHeapSize but just my preference. On 10/27/09 09:26, Paul Hohensee wrote: > 6887571: Increase default heap config sizes > > Webrev here > > http://cr.openjdk.java.net/~phh/6887571/webrev.01/ > > Some background: > > The default client vm heap config since 2000 for sparc32 has been the > equivalent of > > -Xmx64m -XX:OldSize=4m -XX:NewSize=2m -XX:NewRatio=8 > -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 > > and for 32-bit x86 > > -Xmx64m -XX:OldSize=4m -XX:NewSize=1m -XX:NewRatio=12 > -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 > > OldSize and NewSize are the initial committed sizes of the old and young > generations > respectively. A minor gc is required to increase the committed size of > the young gen, > while a full gc is required to increase the committed size of the old gen. > > At the time, 64m was half of the 128m of memory typically available on > high-end > desktops, many client applications were satisfied with small heaps > (hence the > low -Xms value), and gc times were such that the young gen had to be small > in order to minimize pause times. > > Since that time, low end desktops and laptops, as well as netbooks and > smartbooks, > typically come with 256m, client applications have become much more > "server-like", > and we've realized that a small young gen size increases the frequency > of young gcs > and the amount of transient data promoted to the old gen to levels that > noticeably > impact startup and steady-state performance, principally by provoking > full gcs. > > This change extends server class heap sizing to the client with a few > changes. > Server heap sizing ergonomics should be unaffected. > > 1. NewRatio is set to 2 for all platforms to accomodate an increase in > transient data size. > > 2. SurvivorRatio is set to 8 for all platforms. It was 8 for every > platform except > 64-bit x86 (where it was 6) in any case, so it isn't a big change. > > 3. MaxTenuringThreshold is left at 15 (the maximum). > > 4. I added MaxRAM, whose implemented definition matches the current > comment for DefaultMaxRAM > in globals.hpp. MaxRAM is the maximum physical memory size used to > compute MaxHeapSize > rather than the maximum possible value of MaxHeapSize set by > ergonomics. I replaced > DefaultMaxRAM with MaxErgoHeapSize for the latter purpose. I added > support for a new > argument type, uint64_t, and used it as the type of MaxRAM. uintx > doesn't have the necessary > range on 32-bit systems: a user might want to specify 4g for MaxRAM on a > 32-bit system. > > 5. The other Default* switches have been stripped of the "Default" > prefix, since to me their > values are just as much "default" values as the values of any of other > vm switch, and those don't > have a "Default" prefix. I left DefaultMaxRAMFraction as a synonym for > MaxRAMFraction for > the moment because QA uses it. When they change to MaxRAMFraction, I > intend to remove > DefaultMaxRAMFraction. > > 6. In arguments.cpp, set_heap_size() replaces set_server_heap_size() and > is used for everything > except CMS. CMS has it's own, incompatible (I know: I tried it), heap > sizing ergonomics. > > 7. The minimum committed size of the old gen (OldSize) remains at 4m and > the minimum > committed size of the young gen (NewSize) increases to 4m. Note that > these are the minimum, > not initial sizes. NewSize is made common to all platforms. > > 8. I added a switch InitialHeapSize that can be used to set the initial > committed size of the heap. > Absent specification by InitialHeapSize, the initial committed size is > 1/64th of physical memory > or OldSize + NewSize, whichever is larger. > > 9. I cleaned up some formatting, esp. in globals.hpp. > > 10. The default MaxHeapSize is raised from 64m to 96m. For systems with > <= MaxHeapSize > physical memory, the minimum heap size is 1/MinRAMFraction of physical > memory. The > default value of MinRAMFraction is 2. Thus, a 256m box gets a 96m heap, > as does a 128m > box, but a 96m box gets a 48m heap and a 64m box gets a 32m heap. The > default values of > MaxRAM and MaxRAMFraction bound the maximum heap size to 256m for the > client vms, > 1g for 32-bit server vms and 32g for 64-bit server vms. The values for > the server vms are > the same as before. I picked 256m for client because I wanted to bound > resource utilization > on client systems. Also, benchmarks runs showed no extra benefit from > going to 512m heaps. > 512m is the safe maximum for the serial collector. > > Thanks, > > Paul > > > > > From Paul.Hohensee at Sun.COM Tue Oct 27 16:01:49 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Tue, 27 Oct 2009 19:01:49 -0400 Subject: Pls review 6887571 In-Reply-To: <4AE779AB.3040907@Sun.COM> References: <4AE71F41.3030009@sun.com> <4AE779AB.3040907@Sun.COM> Message-ID: <4AE77BDD.7010603@sun.com> .02 has the fix for line 1105. I'll change MaxErgoHeapSize to ErgoHeapSizeLimit, unless someone else has another opinion. I'm not proud. :) Thanks for the review, and for reviewing interim versions. Paul Jon Masamitsu wrote: > Paul, > > Just a couple of comments from the .01 version > of the webrev. I haven't started the .02 version > yet so may have more comments after I do. > > Jon > > arguments.cpp > > 1105 InitialHeapSize = min_new + OldSize; > > Use FLAG_SET_ERGO() > > FLAG_SET_ERGO(uintx, InitialHeapSize, min_new + OldSize); > > Sometimes in the setting of the GC policies we like to > know how the flag was set. > > I like ErgoHeapSizeLimit instead of > MaxErgoHeapSize but just my preference. > > > > On 10/27/09 09:26, Paul Hohensee wrote: >> 6887571: Increase default heap config sizes >> >> Webrev here >> >> http://cr.openjdk.java.net/~phh/6887571/webrev.01/ >> >> Some background: >> >> The default client vm heap config since 2000 for sparc32 has been the >> equivalent of >> >> -Xmx64m -XX:OldSize=4m -XX:NewSize=2m -XX:NewRatio=8 >> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 >> >> and for 32-bit x86 >> >> -Xmx64m -XX:OldSize=4m -XX:NewSize=1m -XX:NewRatio=12 >> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 >> >> OldSize and NewSize are the initial committed sizes of the old and >> young generations >> respectively. A minor gc is required to increase the committed size >> of the young gen, >> while a full gc is required to increase the committed size of the old >> gen. >> >> At the time, 64m was half of the 128m of memory typically available >> on high-end >> desktops, many client applications were satisfied with small heaps >> (hence the >> low -Xms value), and gc times were such that the young gen had to be >> small >> in order to minimize pause times. >> >> Since that time, low end desktops and laptops, as well as netbooks >> and smartbooks, >> typically come with 256m, client applications have become much more >> "server-like", >> and we've realized that a small young gen size increases the >> frequency of young gcs >> and the amount of transient data promoted to the old gen to levels >> that noticeably >> impact startup and steady-state performance, principally by provoking >> full gcs. >> >> This change extends server class heap sizing to the client with a few >> changes. >> Server heap sizing ergonomics should be unaffected. >> >> 1. NewRatio is set to 2 for all platforms to accomodate an increase >> in transient data size. >> >> 2. SurvivorRatio is set to 8 for all platforms. It was 8 for every >> platform except >> 64-bit x86 (where it was 6) in any case, so it isn't a big change. >> >> 3. MaxTenuringThreshold is left at 15 (the maximum). >> >> 4. I added MaxRAM, whose implemented definition matches the current >> comment for DefaultMaxRAM >> in globals.hpp. MaxRAM is the maximum physical memory size used to >> compute MaxHeapSize >> rather than the maximum possible value of MaxHeapSize set by >> ergonomics. I replaced >> DefaultMaxRAM with MaxErgoHeapSize for the latter purpose. I added >> support for a new >> argument type, uint64_t, and used it as the type of MaxRAM. uintx >> doesn't have the necessary >> range on 32-bit systems: a user might want to specify 4g for MaxRAM >> on a 32-bit system. >> >> 5. The other Default* switches have been stripped of the "Default" >> prefix, since to me their >> values are just as much "default" values as the values of any of >> other vm switch, and those don't >> have a "Default" prefix. I left DefaultMaxRAMFraction as a synonym >> for MaxRAMFraction for >> the moment because QA uses it. When they change to MaxRAMFraction, I >> intend to remove >> DefaultMaxRAMFraction. >> >> 6. In arguments.cpp, set_heap_size() replaces set_server_heap_size() >> and is used for everything >> except CMS. CMS has it's own, incompatible (I know: I tried it), >> heap sizing ergonomics. >> >> 7. The minimum committed size of the old gen (OldSize) remains at 4m >> and the minimum >> committed size of the young gen (NewSize) increases to 4m. Note that >> these are the minimum, >> not initial sizes. NewSize is made common to all platforms. >> >> 8. I added a switch InitialHeapSize that can be used to set the >> initial committed size of the heap. >> Absent specification by InitialHeapSize, the initial committed size >> is 1/64th of physical memory >> or OldSize + NewSize, whichever is larger. >> >> 9. I cleaned up some formatting, esp. in globals.hpp. >> >> 10. The default MaxHeapSize is raised from 64m to 96m. For systems >> with <= MaxHeapSize >> physical memory, the minimum heap size is 1/MinRAMFraction of >> physical memory. The >> default value of MinRAMFraction is 2. Thus, a 256m box gets a 96m >> heap, as does a 128m >> box, but a 96m box gets a 48m heap and a 64m box gets a 32m heap. >> The default values of >> MaxRAM and MaxRAMFraction bound the maximum heap size to 256m for the >> client vms, >> 1g for 32-bit server vms and 32g for 64-bit server vms. The values >> for the server vms are >> the same as before. I picked 256m for client because I wanted to >> bound resource utilization >> on client systems. Also, benchmarks runs showed no extra benefit >> from going to 512m heaps. >> 512m is the safe maximum for the serial collector. >> >> Thanks, >> >> Paul >> >> >> >> >> From Jon.Masamitsu at Sun.COM Wed Oct 28 08:25:46 2009 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Wed, 28 Oct 2009 08:25:46 -0700 Subject: Pls review 6887571 In-Reply-To: <4AE77BDD.7010603@sun.com> References: <4AE71F41.3030009@sun.com> <4AE779AB.3040907@Sun.COM> <4AE77BDD.7010603@sun.com> Message-ID: <4AE8627A.6080706@Sun.COM> Comment should probably say "initial heap size" instead of "minimum heap size". 1357 if (!FLAG_IS_DEFAULT(InitialHeapSize)) { 1358 // A minimum heap size was specified on the command line, Instead of this, 2719 // Set heap size based on available physical memory. 2720 // CMS uses its own heap size ergo. 2721 if (!UseConcMarkSweepGC) { 2722 set_heap_size(); 2723 } 2724 2725 if (UseParallelGC || UseParallelOldGC) { 2726 // Set some flags for ParallelGC if needed. 2727 set_parallel_gc_flags(); 2728 } else if (UseConcMarkSweepGC) { 2729 // Set some flags for CMS 2730 set_cms_and_parnew_gc_flags(); 2731 } else if (UseParNewGC) { 2732 // Set some flags for ParNew 2733 set_parnew_gc_flags(); 2734 } else if (UseG1GC) { 2735 // Set some flags for garbage-first, if needed. 2736 set_g1_gc_flags(); 2737 } consider if (UseConcMarkSweepGC) { // Set some flags for cms and ParNew. If both // UseConcMarkSweepGC and UseParNewGC are set, // this is the call that should be done. set_cms_and_parnew_gc_flags(); } else { set_heap_size(); if (UseParallelGC || UseParallelOldGC) { // Set some flags for ParallelGC if needed. set_parallel_gc_flags(); } else if (UseParNewGC) { // Set some flags for ParNew set_parnew_gc_flags(); } else if (UseG1GC) { // Set some flags for garbage-first, if needed. set_g1_gc_flags(); } } I'd suggest adding the newly obsoleted flags (e.g., DefaultMaxRAM) to the obsolete_jvm_flags[] in arguments.cpp. For example { "DefaultMaxRAM)", JDK_Version::jdk_update(6,16), JDK_Version::jdk(8) } That's all. On 10/27/09 16:01, Paul Hohensee wrote: > .02 has the fix for line 1105. > > I'll change MaxErgoHeapSize to ErgoHeapSizeLimit, unless someone > else has another opinion. I'm not proud. :) > > Thanks for the review, and for reviewing interim versions. > > Paul > > Jon Masamitsu wrote: >> Paul, >> >> Just a couple of comments from the .01 version >> of the webrev. I haven't started the .02 version >> yet so may have more comments after I do. >> >> Jon >> >> arguments.cpp >> >> 1105 InitialHeapSize = min_new + OldSize; >> >> Use FLAG_SET_ERGO() >> >> FLAG_SET_ERGO(uintx, InitialHeapSize, min_new + OldSize); >> >> Sometimes in the setting of the GC policies we like to >> know how the flag was set. >> >> I like ErgoHeapSizeLimit instead of >> MaxErgoHeapSize but just my preference. >> >> >> >> On 10/27/09 09:26, Paul Hohensee wrote: >>> 6887571: Increase default heap config sizes >>> >>> Webrev here >>> >>> http://cr.openjdk.java.net/~phh/6887571/webrev.01/ >>> >>> Some background: >>> >>> The default client vm heap config since 2000 for sparc32 has been the >>> equivalent of >>> >>> -Xmx64m -XX:OldSize=4m -XX:NewSize=2m -XX:NewRatio=8 >>> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 >>> >>> and for 32-bit x86 >>> >>> -Xmx64m -XX:OldSize=4m -XX:NewSize=1m -XX:NewRatio=12 >>> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 >>> >>> OldSize and NewSize are the initial committed sizes of the old and >>> young generations >>> respectively. A minor gc is required to increase the committed size >>> of the young gen, >>> while a full gc is required to increase the committed size of the old >>> gen. >>> >>> At the time, 64m was half of the 128m of memory typically available >>> on high-end >>> desktops, many client applications were satisfied with small heaps >>> (hence the >>> low -Xms value), and gc times were such that the young gen had to be >>> small >>> in order to minimize pause times. >>> >>> Since that time, low end desktops and laptops, as well as netbooks >>> and smartbooks, >>> typically come with 256m, client applications have become much more >>> "server-like", >>> and we've realized that a small young gen size increases the >>> frequency of young gcs >>> and the amount of transient data promoted to the old gen to levels >>> that noticeably >>> impact startup and steady-state performance, principally by provoking >>> full gcs. >>> >>> This change extends server class heap sizing to the client with a few >>> changes. >>> Server heap sizing ergonomics should be unaffected. >>> >>> 1. NewRatio is set to 2 for all platforms to accomodate an increase >>> in transient data size. >>> >>> 2. SurvivorRatio is set to 8 for all platforms. It was 8 for every >>> platform except >>> 64-bit x86 (where it was 6) in any case, so it isn't a big change. >>> >>> 3. MaxTenuringThreshold is left at 15 (the maximum). >>> >>> 4. I added MaxRAM, whose implemented definition matches the current >>> comment for DefaultMaxRAM >>> in globals.hpp. MaxRAM is the maximum physical memory size used to >>> compute MaxHeapSize >>> rather than the maximum possible value of MaxHeapSize set by >>> ergonomics. I replaced >>> DefaultMaxRAM with MaxErgoHeapSize for the latter purpose. I added >>> support for a new >>> argument type, uint64_t, and used it as the type of MaxRAM. uintx >>> doesn't have the necessary >>> range on 32-bit systems: a user might want to specify 4g for MaxRAM >>> on a 32-bit system. >>> >>> 5. The other Default* switches have been stripped of the "Default" >>> prefix, since to me their >>> values are just as much "default" values as the values of any of >>> other vm switch, and those don't >>> have a "Default" prefix. I left DefaultMaxRAMFraction as a synonym >>> for MaxRAMFraction for >>> the moment because QA uses it. When they change to MaxRAMFraction, I >>> intend to remove >>> DefaultMaxRAMFraction. >>> >>> 6. In arguments.cpp, set_heap_size() replaces set_server_heap_size() >>> and is used for everything >>> except CMS. CMS has it's own, incompatible (I know: I tried it), >>> heap sizing ergonomics. >>> >>> 7. The minimum committed size of the old gen (OldSize) remains at 4m >>> and the minimum >>> committed size of the young gen (NewSize) increases to 4m. Note that >>> these are the minimum, >>> not initial sizes. NewSize is made common to all platforms. >>> >>> 8. I added a switch InitialHeapSize that can be used to set the >>> initial committed size of the heap. >>> Absent specification by InitialHeapSize, the initial committed size >>> is 1/64th of physical memory >>> or OldSize + NewSize, whichever is larger. >>> >>> 9. I cleaned up some formatting, esp. in globals.hpp. >>> >>> 10. The default MaxHeapSize is raised from 64m to 96m. For systems >>> with <= MaxHeapSize >>> physical memory, the minimum heap size is 1/MinRAMFraction of >>> physical memory. The >>> default value of MinRAMFraction is 2. Thus, a 256m box gets a 96m >>> heap, as does a 128m >>> box, but a 96m box gets a 48m heap and a 64m box gets a 32m heap. >>> The default values of >>> MaxRAM and MaxRAMFraction bound the maximum heap size to 256m for the >>> client vms, >>> 1g for 32-bit server vms and 32g for 64-bit server vms. The values >>> for the server vms are >>> the same as before. I picked 256m for client because I wanted to >>> bound resource utilization >>> on client systems. Also, benchmarks runs showed no extra benefit >>> from going to 512m heaps. >>> 512m is the safe maximum for the serial collector. >>> >>> Thanks, >>> >>> Paul >>> >>> >>> >>> >>> From Paul.Hohensee at Sun.COM Wed Oct 28 08:41:54 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Wed, 28 Oct 2009 11:41:54 -0400 Subject: Pls review 6887571 In-Reply-To: <4AE8627A.6080706@Sun.COM> References: <4AE71F41.3030009@sun.com> <4AE779AB.3040907@Sun.COM> <4AE77BDD.7010603@sun.com> <4AE8627A.6080706@Sun.COM> Message-ID: <4AE86642.8020302@sun.com> All suggestions taken. The obsolete flags are DefaultMaxRAM and DefaultInitialRAMFraction. DefaultMaxRAMFraction will go away later. Paul Jon Masamitsu wrote: > Comment should probably say "initial heap size" instead of "minimum > heap size". > > 1357 if (!FLAG_IS_DEFAULT(InitialHeapSize)) { > 1358 // A minimum heap size was specified on the command line, > > > Instead of this, > > 2719 // Set heap size based on available physical memory. > 2720 // CMS uses its own heap size ergo. > 2721 if (!UseConcMarkSweepGC) { > 2722 set_heap_size(); > 2723 } > 2724 > 2725 if (UseParallelGC || UseParallelOldGC) { > 2726 // Set some flags for ParallelGC if needed. > 2727 set_parallel_gc_flags(); > 2728 } else if (UseConcMarkSweepGC) { > 2729 // Set some flags for CMS > 2730 set_cms_and_parnew_gc_flags(); > 2731 } else if (UseParNewGC) { > 2732 // Set some flags for ParNew > 2733 set_parnew_gc_flags(); > 2734 } else if (UseG1GC) { > 2735 // Set some flags for garbage-first, if needed. > 2736 set_g1_gc_flags(); > 2737 } > > consider > > if (UseConcMarkSweepGC) { > // Set some flags for cms and ParNew. If both > // UseConcMarkSweepGC and UseParNewGC are set, > // this is the call that should be done. > set_cms_and_parnew_gc_flags(); > } else { > set_heap_size(); > if (UseParallelGC || UseParallelOldGC) { > // Set some flags for ParallelGC if needed. > set_parallel_gc_flags(); > } else if (UseParNewGC) { > // Set some flags for ParNew > set_parnew_gc_flags(); > } else if (UseG1GC) { > // Set some flags for garbage-first, if needed. > set_g1_gc_flags(); > } > } > > > I'd suggest adding the newly obsoleted flags (e.g., DefaultMaxRAM) > to the obsolete_jvm_flags[] in arguments.cpp. For example > > { "DefaultMaxRAM)", JDK_Version::jdk_update(6,16), > JDK_Version::jdk(8) } > > > That's all. > > > On 10/27/09 16:01, Paul Hohensee wrote: >> .02 has the fix for line 1105. >> >> I'll change MaxErgoHeapSize to ErgoHeapSizeLimit, unless someone >> else has another opinion. I'm not proud. :) >> >> Thanks for the review, and for reviewing interim versions. >> >> Paul >> >> Jon Masamitsu wrote: >>> Paul, >>> >>> Just a couple of comments from the .01 version >>> of the webrev. I haven't started the .02 version >>> yet so may have more comments after I do. >>> >>> Jon >>> >>> arguments.cpp >>> >>> 1105 InitialHeapSize = min_new + OldSize; >>> >>> Use FLAG_SET_ERGO() >>> >>> FLAG_SET_ERGO(uintx, InitialHeapSize, min_new + OldSize); >>> >>> Sometimes in the setting of the GC policies we like to >>> know how the flag was set. >>> >>> I like ErgoHeapSizeLimit instead of >>> MaxErgoHeapSize but just my preference. >>> >>> >>> >>> On 10/27/09 09:26, Paul Hohensee wrote: >>>> 6887571: Increase default heap config sizes >>>> >>>> Webrev here >>>> >>>> http://cr.openjdk.java.net/~phh/6887571/webrev.01/ >>>> >>>> Some background: >>>> >>>> The default client vm heap config since 2000 for sparc32 has been >>>> the equivalent of >>>> >>>> -Xmx64m -XX:OldSize=4m -XX:NewSize=2m -XX:NewRatio=8 >>>> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 >>>> >>>> and for 32-bit x86 >>>> >>>> -Xmx64m -XX:OldSize=4m -XX:NewSize=1m -XX:NewRatio=12 >>>> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 >>>> >>>> OldSize and NewSize are the initial committed sizes of the old and >>>> young generations >>>> respectively. A minor gc is required to increase the committed >>>> size of the young gen, >>>> while a full gc is required to increase the committed size of the >>>> old gen. >>>> >>>> At the time, 64m was half of the 128m of memory typically available >>>> on high-end >>>> desktops, many client applications were satisfied with small heaps >>>> (hence the >>>> low -Xms value), and gc times were such that the young gen had to >>>> be small >>>> in order to minimize pause times. >>>> >>>> Since that time, low end desktops and laptops, as well as netbooks >>>> and smartbooks, >>>> typically come with 256m, client applications have become much more >>>> "server-like", >>>> and we've realized that a small young gen size increases the >>>> frequency of young gcs >>>> and the amount of transient data promoted to the old gen to levels >>>> that noticeably >>>> impact startup and steady-state performance, principally by >>>> provoking full gcs. >>>> >>>> This change extends server class heap sizing to the client with a >>>> few changes. >>>> Server heap sizing ergonomics should be unaffected. >>>> >>>> 1. NewRatio is set to 2 for all platforms to accomodate an increase >>>> in transient data size. >>>> >>>> 2. SurvivorRatio is set to 8 for all platforms. It was 8 for every >>>> platform except >>>> 64-bit x86 (where it was 6) in any case, so it isn't a big change. >>>> >>>> 3. MaxTenuringThreshold is left at 15 (the maximum). >>>> >>>> 4. I added MaxRAM, whose implemented definition matches the current >>>> comment for DefaultMaxRAM >>>> in globals.hpp. MaxRAM is the maximum physical memory size used to >>>> compute MaxHeapSize >>>> rather than the maximum possible value of MaxHeapSize set by >>>> ergonomics. I replaced >>>> DefaultMaxRAM with MaxErgoHeapSize for the latter purpose. I added >>>> support for a new >>>> argument type, uint64_t, and used it as the type of MaxRAM. uintx >>>> doesn't have the necessary >>>> range on 32-bit systems: a user might want to specify 4g for MaxRAM >>>> on a 32-bit system. >>>> >>>> 5. The other Default* switches have been stripped of the "Default" >>>> prefix, since to me their >>>> values are just as much "default" values as the values of any of >>>> other vm switch, and those don't >>>> have a "Default" prefix. I left DefaultMaxRAMFraction as a synonym >>>> for MaxRAMFraction for >>>> the moment because QA uses it. When they change to MaxRAMFraction, >>>> I intend to remove >>>> DefaultMaxRAMFraction. >>>> >>>> 6. In arguments.cpp, set_heap_size() replaces >>>> set_server_heap_size() and is used for everything >>>> except CMS. CMS has it's own, incompatible (I know: I tried it), >>>> heap sizing ergonomics. >>>> >>>> 7. The minimum committed size of the old gen (OldSize) remains at >>>> 4m and the minimum >>>> committed size of the young gen (NewSize) increases to 4m. Note >>>> that these are the minimum, >>>> not initial sizes. NewSize is made common to all platforms. >>>> >>>> 8. I added a switch InitialHeapSize that can be used to set the >>>> initial committed size of the heap. >>>> Absent specification by InitialHeapSize, the initial committed size >>>> is 1/64th of physical memory >>>> or OldSize + NewSize, whichever is larger. >>>> >>>> 9. I cleaned up some formatting, esp. in globals.hpp. >>>> >>>> 10. The default MaxHeapSize is raised from 64m to 96m. For systems >>>> with <= MaxHeapSize >>>> physical memory, the minimum heap size is 1/MinRAMFraction of >>>> physical memory. The >>>> default value of MinRAMFraction is 2. Thus, a 256m box gets a 96m >>>> heap, as does a 128m >>>> box, but a 96m box gets a 48m heap and a 64m box gets a 32m heap. >>>> The default values of >>>> MaxRAM and MaxRAMFraction bound the maximum heap size to 256m for >>>> the client vms, >>>> 1g for 32-bit server vms and 32g for 64-bit server vms. The values >>>> for the server vms are >>>> the same as before. I picked 256m for client because I wanted to >>>> bound resource utilization >>>> on client systems. Also, benchmarks runs showed no extra benefit >>>> from going to 512m heaps. >>>> 512m is the safe maximum for the serial collector. >>>> >>>> Thanks, >>>> >>>> Paul >>>> >>>> >>>> >>>> >>>> From gnu_andrew at member.fsf.org Wed Oct 28 08:58:54 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 28 Oct 2009 15:58:54 +0000 Subject: JNI DEFINE_NEWSCALARARRAY uses DT_RETURN_MARK_DECL_FOR In-Reply-To: <4AE0778D.6030403@sun.com> References: <1255981409.2612.44.camel@hermans.wildebeest.org> <4AE0778D.6030403@sun.com> Message-ID: <17c6771e0910280858jfab5186l86fec9d4b4a594c1@mail.gmail.com> 2009/10/22 Keith McGuigan : > > Thank you for these fixes, Mark, I've integrated them into > http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot and they'll bubble up to > the other repos (hotspot/hotspot and jdk7/hotspot) soon. > > Please refer to CR 6893483 to track these fixes. > > -- > - Keith > > Mark Wielaard wrote: >> >> Hi, >> >> In jni.cpp the DEFINE_NEWSCALARARRAY macro uses DT_RETURN_MARK_DECL_FOR >> instead of the normal DT_RETURN_MARK_DECL. The DT_RETURN_MARK_DECL_FOR >> macro should only be used for mark probes that could return a primitive >> jfloat or jdouble. But DEFINE_NEWSCALARARRAY creates the functions for >> NewArray which return primitiveTypeArrays. This means that for >> NewFloatArray and NewDoubleArray you cannot get the return value in the >> return mark probe. >> >> According to hotspot_jni.d the intention is to return these values in >> those cases: >> >> ?probe NewDoubleArray__entry(void*, uintptr_t); >> ?probe NewDoubleArray__return(void*); >> ?probe NewFloatArray__entry(void*, uintptr_t); >> ?probe NewFloatArray__return(void*); >> >> The attached trivial patch fixes it and makes the actual return value in >> those cases available. >> >> Tested against Systemtap, but the same should work for DTrace also. >> I don't have access to a system with solaris/dtrace on it, so it would >> be nice of someone who does could double check the above on such a >> system. >> >> Please let me know if I should create a bug also on >> https://bugs.openjdk.java.net/ and/or if I should report/post this patch >> on some other mailing-list. >> >> Thanks, >> >> Mark >> > > Keith, Shouldn't Mark have at least received a 'Contributed-by' credit on this changeset? Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Keith.McGuigan at Sun.COM Wed Oct 28 09:10:21 2009 From: Keith.McGuigan at Sun.COM (Keith McGuigan) Date: Wed, 28 Oct 2009 12:10:21 -0400 Subject: JNI DEFINE_NEWSCALARARRAY uses DT_RETURN_MARK_DECL_FOR In-Reply-To: <17c6771e0910280858jfab5186l86fec9d4b4a594c1@mail.gmail.com> References: <1255981409.2612.44.camel@hermans.wildebeest.org> <4AE0778D.6030403@sun.com> <17c6771e0910280858jfab5186l86fec9d4b4a594c1@mail.gmail.com> Message-ID: <4AE86CED.90002@sun.com> Andrew John Hughes wrote: > Shouldn't Mark have at least received a 'Contributed-by' credit on > this changeset? Yes, he should have. But as a newbie sponser, I forgot to include that in the changeset and realized it only after the push occurred (and I apologized to Mark privately). -- - Keith From Paul.Hohensee at Sun.COM Wed Oct 28 09:29:46 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Wed, 28 Oct 2009 12:29:46 -0400 Subject: Final (hopefully) version of 6887571 Message-ID: <4AE8717A.1040007@sun.com> Webrev here http://cr.openjdk.java.net/~phh/6887571/webrev.04/ Thanks, Paul From Jon.Masamitsu at Sun.COM Wed Oct 28 10:24:01 2009 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Wed, 28 Oct 2009 10:24:01 -0700 Subject: Final (hopefully) version of 6887571 In-Reply-To: <4AE8717A.1040007@sun.com> References: <4AE8717A.1040007@sun.com> Message-ID: <4AE87E31.1020607@Sun.COM> I reviewed my suggested changes and that looks fine. On 10/28/09 09:29, Paul Hohensee wrote: > Webrev here > > http://cr.openjdk.java.net/~phh/6887571/webrev.04/ > > Thanks, > > Paul > From gnu_andrew at member.fsf.org Wed Oct 28 11:19:54 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 28 Oct 2009 18:19:54 +0000 Subject: JNI DEFINE_NEWSCALARARRAY uses DT_RETURN_MARK_DECL_FOR In-Reply-To: <4AE86CED.90002@sun.com> References: <1255981409.2612.44.camel@hermans.wildebeest.org> <4AE0778D.6030403@sun.com> <17c6771e0910280858jfab5186l86fec9d4b4a594c1@mail.gmail.com> <4AE86CED.90002@sun.com> Message-ID: <17c6771e0910281119h7822398fqfbfff9700a6cf1ae@mail.gmail.com> 2009/10/28 Keith McGuigan : > Andrew John Hughes wrote: >> >> Shouldn't Mark have at least received a 'Contributed-by' credit on >> this changeset? > > Yes, he should have. ?But as a newbie sponser, I forgot to include that in > the changeset and realized it only after the push occurred (and I apologized > to Mark privately). > > -- > - Keith > Thanks Keith. I thought it worth raising publicly not to condemn what was clearly accidental on your part, but to help others avoid making the same mistake with future contributions (it happened to me with another patch as well). -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Y.S.Ramakrishna at Sun.COM Wed Oct 28 12:18:33 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Wed, 28 Oct 2009 12:18:33 -0700 Subject: Pls review 6887571 In-Reply-To: <4AE77057.7050709@sun.com> References: <4AE71F41.3030009@sun.com> <4AE7488E.2010408@Sun.COM> <4AE77057.7050709@sun.com> Message-ID: <4AE89909.1000202@Sun.COM> On 10/27/09 15:12, Paul Hohensee wrote: > Yes, I forgot to uncomment line 1383. Fixed. > > Fixed line 1612. Thanks. > > It's a good thing you asked me to get cms dumps. Turned out I'd typo'ed > and > had an earlier version of arguments.cpp. The earlier version didn't > separate > cms ergo from everything-else ergo. New webrev here > > http://cr.openjdk.java.net/~phh/6887571/webrev.02/ I think I will need to discuss this further with you. I actually prefer the older version you had where the heap size is set ergonomically unless explicitly specified in the case of CMS as well. The CMS ergo will take that as a given and _shape_ the generations within those constraints. That would be my preferred model of CMS ergo -- basically, what you had in your earlier webrev. However, I understand if you and others feel leery about touching CMS ergo for other reasons and would prefer any such changes to be affected in a subsequent CR which does due diligence in measuring the performance delta of that change for CMS specifically. -- ramki > > With the new version, running > > java -client -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+Verbose > -version > > I get > > VM option '+UseConcMarkSweepGC' > VM option '+PrintGCDetails' > VM option '+Verbose' > Turning off use of shared archive because of choice of garbage collector > or large pages > Ergo set MaxNewSize: 134217728 > CMS set min_heap_size: 0 initial_heap_size: 0 max_heap: 100663296 > Ergo set NewSize: 16777216 > Ergo set OldSize: 50331648 > Minimum heap 67108864 Initial heap 67108864 Maximum heap 100663296 > Minimum gen0 16777216 Initial gen0 16777216 Maximum gen0 16777216 > Minimum gen1 50331648 Initial gen1 50331648 Maximum gen1 83886080 > > java version "1.7.0-ea" > Java(TM) SE Runtime Environment (build 1.7.0-ea-b39) > OpenJDK Client VM (build 17.0-b03-internal-jvmg, mixed mode) > Heap > par new generation total 14784K, used 527K [0xf1800000, 0xf2800000, > 0xf2800000) > eden space 13184K, 4% used [0xf1800000, 0xf1883de8, 0xf24e0000) > from space 1600K, 0% used [0xf24e0000, 0xf24e0000, 0xf2670000) > to space 1600K, 0% used [0xf2670000, 0xf2670000, 0xf2800000) > concurrent mark-sweep generation total 49152K, used 0K [0xf2800000, > 0xf5800000, 0xf7800000) > concurrent-mark-sweep perm gen total 12288K, used 1497K [0xf7800000, > 0xf8400000, 0xfb800000) > > With the unmodified vm, I get > > VM option '+UseConcMarkSweepGC' > VM option '+PrintGCDetails' > VM option '+Verbose' > Turning off use of shared archive because of choice of garbage collector > or large pages > Ergo set MaxNewSize: 134217728 > CMS set min_heap_size: 0 initial_heap_size: 0 max_heap: 67108864 > Ergo set NewSize: 16777216 > Ergo set OldSize: 50331648 > Minimum heap 67108864 Initial heap 67108864 Maximum heap 67108864 > Minimum gen0 16777216 Initial gen0 16777216 Maximum gen0 16777216 > Minimum gen1 50331648 Initial gen1 50331648 Maximum gen1 50331648 > > java version "1.7.0-ea" > Java(TM) SE Runtime Environment (build 1.7.0-ea-b39) > OpenJDK Client VM (build 17.0-b03-internal-jvmg, mixed mode) > Heap > par new generation total 14784K, used 527K [0xf3800000, 0xf4800000, > 0xf4800000) > eden space 13184K, 4% used [0xf3800000, 0xf3883de8, 0xf44e0000) > from space 1600K, 0% used [0xf44e0000, 0xf44e0000, 0xf4670000) > to space 1600K, 0% used [0xf4670000, 0xf4670000, 0xf4800000) > concurrent mark-sweep generation total 49152K, used 0K [0xf4800000, > 0xf7800000, 0xf7800000) > concurrent-mark-sweep perm gen total 12288K, used 1497K [0xf7800000, > 0xf8400000, 0xfb800000) > > They're identical, except for the total heap size and ergo-computed old gen > size, which are 96m and 80m respectively. That's because I increased the > value of MaxNewSize from 64m to 96m. > > -server instead of -client produces the same result. > > Paul > > Y.S.Ramakrishna at Sun.COM wrote: >> Hi Paul -- >> >> Did you forget to remove the commenting out of the second conjunct in >> arguments.cpp:1383 below:- >> >> 1383 if (PrintGCDetails/* && Verbose*/) { > Yes, fixed. >> >> Could you do me a favour and change the following in >> arguments.cpp:1612 from:- >> >> 1612 if (UseSharedSpaces) { >> >> to:- >> >> 1612 if (UseSharedSpaces && Verbose) { >> >> The verbosity of the message at 1613:1615 has been >> bothering some of us for a while (mea culpa for adding >> it recentkly), but i didn't get around to removing it, and this >> looks like an good opportunity to do so with no new overhead :-) > Done. >> >> On 10/27/09 09:26, Paul Hohensee wrote: >> ... >>> 6. In arguments.cpp, set_heap_size() replaces set_server_heap_size() >>> and is used for everything >>> except CMS. CMS has it's own, incompatible (I know: I tried it), >>> heap sizing ergonomics. >> >> Could you provide the result of:- >> >> % java -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -version >> >> with the baseline VM and with the VM after yr changes? >> >> >> Rest looks good to me; thanks! >> -- ramki >> From Y.S.Ramakrishna at Sun.COM Wed Oct 28 12:20:34 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Wed, 28 Oct 2009 12:20:34 -0700 Subject: Pls review 6887571 In-Reply-To: <4AE8627A.6080706@Sun.COM> References: <4AE71F41.3030009@sun.com> <4AE779AB.3040907@Sun.COM> <4AE77BDD.7010603@sun.com> <4AE8627A.6080706@Sun.COM> Message-ID: <4AE89982.3060606@Sun.COM> See my previous email re treatment of CMS wrt the ergo heap sizing affected here. I am find, though, with that happening is a separate CR. So I am fine with this going in in the current state (i.e. Paul's latest webrev as of this writing (webrev.04)). thanks. -- ramki On 10/28/09 08:25, Jon Masamitsu wrote: > Comment should probably say "initial heap size" instead of "minimum > heap size". > > 1357 if (!FLAG_IS_DEFAULT(InitialHeapSize)) { > 1358 // A minimum heap size was specified on the command line, > > > Instead of this, > > 2719 // Set heap size based on available physical memory. > 2720 // CMS uses its own heap size ergo. > 2721 if (!UseConcMarkSweepGC) { > 2722 set_heap_size(); > 2723 } > 2724 > 2725 if (UseParallelGC || UseParallelOldGC) { > 2726 // Set some flags for ParallelGC if needed. > 2727 set_parallel_gc_flags(); > 2728 } else if (UseConcMarkSweepGC) { > 2729 // Set some flags for CMS > 2730 set_cms_and_parnew_gc_flags(); > 2731 } else if (UseParNewGC) { > 2732 // Set some flags for ParNew > 2733 set_parnew_gc_flags(); > 2734 } else if (UseG1GC) { > 2735 // Set some flags for garbage-first, if needed. > 2736 set_g1_gc_flags(); > 2737 } > > consider > > if (UseConcMarkSweepGC) { > // Set some flags for cms and ParNew. If both > // UseConcMarkSweepGC and UseParNewGC are set, > // this is the call that should be done. > set_cms_and_parnew_gc_flags(); > } else { > set_heap_size(); > if (UseParallelGC || UseParallelOldGC) { > // Set some flags for ParallelGC if needed. > set_parallel_gc_flags(); > } else if (UseParNewGC) { > // Set some flags for ParNew > set_parnew_gc_flags(); > } else if (UseG1GC) { > // Set some flags for garbage-first, if needed. > set_g1_gc_flags(); > } > } > > > I'd suggest adding the newly obsoleted flags (e.g., DefaultMaxRAM) > to the obsolete_jvm_flags[] in arguments.cpp. For example > > { "DefaultMaxRAM)", JDK_Version::jdk_update(6,16), JDK_Version::jdk(8) } > > > That's all. > > > On 10/27/09 16:01, Paul Hohensee wrote: >> .02 has the fix for line 1105. >> >> I'll change MaxErgoHeapSize to ErgoHeapSizeLimit, unless someone >> else has another opinion. I'm not proud. :) >> >> Thanks for the review, and for reviewing interim versions. >> >> Paul >> >> Jon Masamitsu wrote: >>> Paul, >>> >>> Just a couple of comments from the .01 version >>> of the webrev. I haven't started the .02 version >>> yet so may have more comments after I do. >>> >>> Jon >>> >>> arguments.cpp >>> >>> 1105 InitialHeapSize = min_new + OldSize; >>> >>> Use FLAG_SET_ERGO() >>> >>> FLAG_SET_ERGO(uintx, InitialHeapSize, min_new + OldSize); >>> >>> Sometimes in the setting of the GC policies we like to >>> know how the flag was set. >>> >>> I like ErgoHeapSizeLimit instead of >>> MaxErgoHeapSize but just my preference. >>> >>> >>> >>> On 10/27/09 09:26, Paul Hohensee wrote: >>>> 6887571: Increase default heap config sizes >>>> >>>> Webrev here >>>> >>>> http://cr.openjdk.java.net/~phh/6887571/webrev.01/ >>>> >>>> Some background: >>>> >>>> The default client vm heap config since 2000 for sparc32 has been >>>> the equivalent of >>>> >>>> -Xmx64m -XX:OldSize=4m -XX:NewSize=2m -XX:NewRatio=8 >>>> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 >>>> >>>> and for 32-bit x86 >>>> >>>> -Xmx64m -XX:OldSize=4m -XX:NewSize=1m -XX:NewRatio=12 >>>> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 >>>> >>>> OldSize and NewSize are the initial committed sizes of the old and >>>> young generations >>>> respectively. A minor gc is required to increase the committed size >>>> of the young gen, >>>> while a full gc is required to increase the committed size of the >>>> old gen. >>>> >>>> At the time, 64m was half of the 128m of memory typically available >>>> on high-end >>>> desktops, many client applications were satisfied with small heaps >>>> (hence the >>>> low -Xms value), and gc times were such that the young gen had to be >>>> small >>>> in order to minimize pause times. >>>> >>>> Since that time, low end desktops and laptops, as well as netbooks >>>> and smartbooks, >>>> typically come with 256m, client applications have become much more >>>> "server-like", >>>> and we've realized that a small young gen size increases the >>>> frequency of young gcs >>>> and the amount of transient data promoted to the old gen to levels >>>> that noticeably >>>> impact startup and steady-state performance, principally by >>>> provoking full gcs. >>>> >>>> This change extends server class heap sizing to the client with a >>>> few changes. >>>> Server heap sizing ergonomics should be unaffected. >>>> >>>> 1. NewRatio is set to 2 for all platforms to accomodate an increase >>>> in transient data size. >>>> >>>> 2. SurvivorRatio is set to 8 for all platforms. It was 8 for every >>>> platform except >>>> 64-bit x86 (where it was 6) in any case, so it isn't a big change. >>>> >>>> 3. MaxTenuringThreshold is left at 15 (the maximum). >>>> >>>> 4. I added MaxRAM, whose implemented definition matches the current >>>> comment for DefaultMaxRAM >>>> in globals.hpp. MaxRAM is the maximum physical memory size used to >>>> compute MaxHeapSize >>>> rather than the maximum possible value of MaxHeapSize set by >>>> ergonomics. I replaced >>>> DefaultMaxRAM with MaxErgoHeapSize for the latter purpose. I added >>>> support for a new >>>> argument type, uint64_t, and used it as the type of MaxRAM. uintx >>>> doesn't have the necessary >>>> range on 32-bit systems: a user might want to specify 4g for MaxRAM >>>> on a 32-bit system. >>>> >>>> 5. The other Default* switches have been stripped of the "Default" >>>> prefix, since to me their >>>> values are just as much "default" values as the values of any of >>>> other vm switch, and those don't >>>> have a "Default" prefix. I left DefaultMaxRAMFraction as a synonym >>>> for MaxRAMFraction for >>>> the moment because QA uses it. When they change to MaxRAMFraction, >>>> I intend to remove >>>> DefaultMaxRAMFraction. >>>> >>>> 6. In arguments.cpp, set_heap_size() replaces set_server_heap_size() >>>> and is used for everything >>>> except CMS. CMS has it's own, incompatible (I know: I tried it), >>>> heap sizing ergonomics. >>>> >>>> 7. The minimum committed size of the old gen (OldSize) remains at 4m >>>> and the minimum >>>> committed size of the young gen (NewSize) increases to 4m. Note >>>> that these are the minimum, >>>> not initial sizes. NewSize is made common to all platforms. >>>> >>>> 8. I added a switch InitialHeapSize that can be used to set the >>>> initial committed size of the heap. >>>> Absent specification by InitialHeapSize, the initial committed size >>>> is 1/64th of physical memory >>>> or OldSize + NewSize, whichever is larger. >>>> >>>> 9. I cleaned up some formatting, esp. in globals.hpp. >>>> >>>> 10. The default MaxHeapSize is raised from 64m to 96m. For systems >>>> with <= MaxHeapSize >>>> physical memory, the minimum heap size is 1/MinRAMFraction of >>>> physical memory. The >>>> default value of MinRAMFraction is 2. Thus, a 256m box gets a 96m >>>> heap, as does a 128m >>>> box, but a 96m box gets a 48m heap and a 64m box gets a 32m heap. >>>> The default values of >>>> MaxRAM and MaxRAMFraction bound the maximum heap size to 256m for >>>> the client vms, >>>> 1g for 32-bit server vms and 32g for 64-bit server vms. The values >>>> for the server vms are >>>> the same as before. I picked 256m for client because I wanted to >>>> bound resource utilization >>>> on client systems. Also, benchmarks runs showed no extra benefit >>>> from going to 512m heaps. >>>> 512m is the safe maximum for the serial collector. >>>> >>>> Thanks, >>>> >>>> Paul >>>> >>>> >>>> >>>> >>>> From Paul.Hohensee at Sun.COM Wed Oct 28 12:25:31 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Wed, 28 Oct 2009 15:25:31 -0400 Subject: Pls review 6887571 In-Reply-To: <4AE89909.1000202@Sun.COM> References: <4AE71F41.3030009@sun.com> <4AE7488E.2010408@Sun.COM> <4AE77057.7050709@sun.com> <4AE89909.1000202@Sun.COM> Message-ID: <4AE89AAB.8070002@sun.com> Thanks for the review (and the previous one too). Yes, I feel queasy about changing CMS ergo. Using the code in set_heap_size() with cms produced some pretty weird results, such as initial gen1 sizes of 64kb. I investigated a bit and decided to leave well enough alone. I'll be happy to file an rfe to integrate cms and common heap ergo. Would that be acceptable? Paul Y.S.Ramakrishna at Sun.COM wrote: > On 10/27/09 15:12, Paul Hohensee wrote: >> Yes, I forgot to uncomment line 1383. Fixed. >> >> Fixed line 1612. > > Thanks. > >> >> It's a good thing you asked me to get cms dumps. Turned out I'd >> typo'ed and >> had an earlier version of arguments.cpp. The earlier version didn't >> separate >> cms ergo from everything-else ergo. New webrev here >> >> http://cr.openjdk.java.net/~phh/6887571/webrev.02/ > > I think I will need to discuss this further with you. I actually prefer > the older version you had where the heap size is set ergonomically unless > explicitly specified in the case of CMS as well. The CMS ergo will take > that as a given and _shape_ the generations within those constraints. > That would be > my preferred model of CMS ergo -- basically, what you had in your > earlier webrev. However, I understand if you and others feel leery about > touching CMS ergo for other reasons and would prefer any such changes > to be > affected in a subsequent CR which does due diligence in > measuring the performance delta of that change for CMS specifically. > > -- ramki > >> >> With the new version, running >> >> java -client -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+Verbose >> -version >> >> I get >> >> VM option '+UseConcMarkSweepGC' >> VM option '+PrintGCDetails' >> VM option '+Verbose' >> Turning off use of shared archive because of choice of garbage >> collector or large pages >> Ergo set MaxNewSize: 134217728 >> CMS set min_heap_size: 0 initial_heap_size: 0 max_heap: 100663296 >> Ergo set NewSize: 16777216 >> Ergo set OldSize: 50331648 >> Minimum heap 67108864 Initial heap 67108864 Maximum heap 100663296 >> Minimum gen0 16777216 Initial gen0 16777216 Maximum gen0 16777216 >> Minimum gen1 50331648 Initial gen1 50331648 Maximum gen1 83886080 >> >> java version "1.7.0-ea" >> Java(TM) SE Runtime Environment (build 1.7.0-ea-b39) >> OpenJDK Client VM (build 17.0-b03-internal-jvmg, mixed mode) >> Heap >> par new generation total 14784K, used 527K [0xf1800000, 0xf2800000, >> 0xf2800000) >> eden space 13184K, 4% used [0xf1800000, 0xf1883de8, 0xf24e0000) >> from space 1600K, 0% used [0xf24e0000, 0xf24e0000, 0xf2670000) >> to space 1600K, 0% used [0xf2670000, 0xf2670000, 0xf2800000) >> concurrent mark-sweep generation total 49152K, used 0K [0xf2800000, >> 0xf5800000, 0xf7800000) >> concurrent-mark-sweep perm gen total 12288K, used 1497K [0xf7800000, >> 0xf8400000, 0xfb800000) >> >> With the unmodified vm, I get >> >> VM option '+UseConcMarkSweepGC' >> VM option '+PrintGCDetails' >> VM option '+Verbose' >> Turning off use of shared archive because of choice of garbage >> collector or large pages >> Ergo set MaxNewSize: 134217728 >> CMS set min_heap_size: 0 initial_heap_size: 0 max_heap: 67108864 >> Ergo set NewSize: 16777216 >> Ergo set OldSize: 50331648 >> Minimum heap 67108864 Initial heap 67108864 Maximum heap 67108864 >> Minimum gen0 16777216 Initial gen0 16777216 Maximum gen0 16777216 >> Minimum gen1 50331648 Initial gen1 50331648 Maximum gen1 50331648 >> >> java version "1.7.0-ea" >> Java(TM) SE Runtime Environment (build 1.7.0-ea-b39) >> OpenJDK Client VM (build 17.0-b03-internal-jvmg, mixed mode) >> Heap >> par new generation total 14784K, used 527K [0xf3800000, 0xf4800000, >> 0xf4800000) >> eden space 13184K, 4% used [0xf3800000, 0xf3883de8, 0xf44e0000) >> from space 1600K, 0% used [0xf44e0000, 0xf44e0000, 0xf4670000) >> to space 1600K, 0% used [0xf4670000, 0xf4670000, 0xf4800000) >> concurrent mark-sweep generation total 49152K, used 0K [0xf4800000, >> 0xf7800000, 0xf7800000) >> concurrent-mark-sweep perm gen total 12288K, used 1497K [0xf7800000, >> 0xf8400000, 0xfb800000) >> >> They're identical, except for the total heap size and ergo-computed >> old gen >> size, which are 96m and 80m respectively. That's because I increased >> the >> value of MaxNewSize from 64m to 96m. >> >> -server instead of -client produces the same result. >> >> Paul >> >> Y.S.Ramakrishna at Sun.COM wrote: >>> Hi Paul -- >>> >>> Did you forget to remove the commenting out of the second conjunct in >>> arguments.cpp:1383 below:- >>> >>> 1383 if (PrintGCDetails/* && Verbose*/) { >> Yes, fixed. >>> >>> Could you do me a favour and change the following in >>> arguments.cpp:1612 from:- >>> >>> 1612 if (UseSharedSpaces) { >>> >>> to:- >>> >>> 1612 if (UseSharedSpaces && Verbose) { >>> >>> The verbosity of the message at 1613:1615 has been >>> bothering some of us for a while (mea culpa for adding >>> it recentkly), but i didn't get around to removing it, and this >>> looks like an good opportunity to do so with no new overhead :-) >> Done. >>> >>> On 10/27/09 09:26, Paul Hohensee wrote: >>> ... >>>> 6. In arguments.cpp, set_heap_size() replaces >>>> set_server_heap_size() and is used for everything >>>> except CMS. CMS has it's own, incompatible (I know: I tried it), >>>> heap sizing ergonomics. >>> >>> Could you provide the result of:- >>> >>> % java -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -version >>> >>> with the baseline VM and with the VM after yr changes? >>> >>> >>> Rest looks good to me; thanks! >>> -- ramki >>> > From Paul.Hohensee at Sun.COM Wed Oct 28 12:26:06 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Wed, 28 Oct 2009 15:26:06 -0400 Subject: Pls review 6887571 In-Reply-To: <4AE89982.3060606@Sun.COM> References: <4AE71F41.3030009@sun.com> <4AE779AB.3040907@Sun.COM> <4AE77BDD.7010603@sun.com> <4AE8627A.6080706@Sun.COM> <4AE89982.3060606@Sun.COM> Message-ID: <4AE89ACE.5090702@sun.com> Excellent. Thanks! Y.S.Ramakrishna at Sun.COM wrote: > See my previous email re treatment of CMS wrt the ergo heap sizing > affected here. I am find, though, with that happening is a separate CR. > So I am fine with this going in in the current state (i.e. Paul's > latest webrev as of this writing (webrev.04)). > > thanks. > -- ramki > > On 10/28/09 08:25, Jon Masamitsu wrote: >> Comment should probably say "initial heap size" instead of "minimum >> heap size". >> >> 1357 if (!FLAG_IS_DEFAULT(InitialHeapSize)) { >> 1358 // A minimum heap size was specified on the command line, >> >> >> Instead of this, >> >> 2719 // Set heap size based on available physical memory. >> 2720 // CMS uses its own heap size ergo. >> 2721 if (!UseConcMarkSweepGC) { >> 2722 set_heap_size(); >> 2723 } >> 2724 >> 2725 if (UseParallelGC || UseParallelOldGC) { >> 2726 // Set some flags for ParallelGC if needed. >> 2727 set_parallel_gc_flags(); >> 2728 } else if (UseConcMarkSweepGC) { >> 2729 // Set some flags for CMS >> 2730 set_cms_and_parnew_gc_flags(); >> 2731 } else if (UseParNewGC) { >> 2732 // Set some flags for ParNew >> 2733 set_parnew_gc_flags(); >> 2734 } else if (UseG1GC) { >> 2735 // Set some flags for garbage-first, if needed. >> 2736 set_g1_gc_flags(); >> 2737 } >> >> consider >> >> if (UseConcMarkSweepGC) { >> // Set some flags for cms and ParNew. If both >> // UseConcMarkSweepGC and UseParNewGC are set, >> // this is the call that should be done. >> set_cms_and_parnew_gc_flags(); >> } else { >> set_heap_size(); >> if (UseParallelGC || UseParallelOldGC) { >> // Set some flags for ParallelGC if needed. >> set_parallel_gc_flags(); >> } else if (UseParNewGC) { >> // Set some flags for ParNew >> set_parnew_gc_flags(); >> } else if (UseG1GC) { >> // Set some flags for garbage-first, if needed. >> set_g1_gc_flags(); >> } >> } >> >> >> I'd suggest adding the newly obsoleted flags (e.g., DefaultMaxRAM) >> to the obsolete_jvm_flags[] in arguments.cpp. For example >> >> { "DefaultMaxRAM)", JDK_Version::jdk_update(6,16), >> JDK_Version::jdk(8) } >> >> >> That's all. >> >> >> On 10/27/09 16:01, Paul Hohensee wrote: >>> .02 has the fix for line 1105. >>> >>> I'll change MaxErgoHeapSize to ErgoHeapSizeLimit, unless someone >>> else has another opinion. I'm not proud. :) >>> >>> Thanks for the review, and for reviewing interim versions. >>> >>> Paul >>> >>> Jon Masamitsu wrote: >>>> Paul, >>>> >>>> Just a couple of comments from the .01 version >>>> of the webrev. I haven't started the .02 version >>>> yet so may have more comments after I do. >>>> >>>> Jon >>>> >>>> arguments.cpp >>>> >>>> 1105 InitialHeapSize = min_new + OldSize; >>>> >>>> Use FLAG_SET_ERGO() >>>> >>>> FLAG_SET_ERGO(uintx, InitialHeapSize, min_new + OldSize); >>>> >>>> Sometimes in the setting of the GC policies we like to >>>> know how the flag was set. >>>> >>>> I like ErgoHeapSizeLimit instead of >>>> MaxErgoHeapSize but just my preference. >>>> >>>> >>>> >>>> On 10/27/09 09:26, Paul Hohensee wrote: >>>>> 6887571: Increase default heap config sizes >>>>> >>>>> Webrev here >>>>> >>>>> http://cr.openjdk.java.net/~phh/6887571/webrev.01/ >>>>> >>>>> Some background: >>>>> >>>>> The default client vm heap config since 2000 for sparc32 has been >>>>> the equivalent of >>>>> >>>>> -Xmx64m -XX:OldSize=4m -XX:NewSize=2m -XX:NewRatio=8 >>>>> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 >>>>> >>>>> and for 32-bit x86 >>>>> >>>>> -Xmx64m -XX:OldSize=4m -XX:NewSize=1m -XX:NewRatio=12 >>>>> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 >>>>> >>>>> OldSize and NewSize are the initial committed sizes of the old and >>>>> young generations >>>>> respectively. A minor gc is required to increase the committed >>>>> size of the young gen, >>>>> while a full gc is required to increase the committed size of the >>>>> old gen. >>>>> >>>>> At the time, 64m was half of the 128m of memory typically >>>>> available on high-end >>>>> desktops, many client applications were satisfied with small heaps >>>>> (hence the >>>>> low -Xms value), and gc times were such that the young gen had to >>>>> be small >>>>> in order to minimize pause times. >>>>> >>>>> Since that time, low end desktops and laptops, as well as netbooks >>>>> and smartbooks, >>>>> typically come with 256m, client applications have become much >>>>> more "server-like", >>>>> and we've realized that a small young gen size increases the >>>>> frequency of young gcs >>>>> and the amount of transient data promoted to the old gen to levels >>>>> that noticeably >>>>> impact startup and steady-state performance, principally by >>>>> provoking full gcs. >>>>> >>>>> This change extends server class heap sizing to the client with a >>>>> few changes. >>>>> Server heap sizing ergonomics should be unaffected. >>>>> >>>>> 1. NewRatio is set to 2 for all platforms to accomodate an >>>>> increase in transient data size. >>>>> >>>>> 2. SurvivorRatio is set to 8 for all platforms. It was 8 for >>>>> every platform except >>>>> 64-bit x86 (where it was 6) in any case, so it isn't a big change. >>>>> >>>>> 3. MaxTenuringThreshold is left at 15 (the maximum). >>>>> >>>>> 4. I added MaxRAM, whose implemented definition matches the >>>>> current comment for DefaultMaxRAM >>>>> in globals.hpp. MaxRAM is the maximum physical memory size used >>>>> to compute MaxHeapSize >>>>> rather than the maximum possible value of MaxHeapSize set by >>>>> ergonomics. I replaced >>>>> DefaultMaxRAM with MaxErgoHeapSize for the latter purpose. I >>>>> added support for a new >>>>> argument type, uint64_t, and used it as the type of MaxRAM. uintx >>>>> doesn't have the necessary >>>>> range on 32-bit systems: a user might want to specify 4g for >>>>> MaxRAM on a 32-bit system. >>>>> >>>>> 5. The other Default* switches have been stripped of the "Default" >>>>> prefix, since to me their >>>>> values are just as much "default" values as the values of any of >>>>> other vm switch, and those don't >>>>> have a "Default" prefix. I left DefaultMaxRAMFraction as a >>>>> synonym for MaxRAMFraction for >>>>> the moment because QA uses it. When they change to >>>>> MaxRAMFraction, I intend to remove >>>>> DefaultMaxRAMFraction. >>>>> >>>>> 6. In arguments.cpp, set_heap_size() replaces >>>>> set_server_heap_size() and is used for everything >>>>> except CMS. CMS has it's own, incompatible (I know: I tried it), >>>>> heap sizing ergonomics. >>>>> >>>>> 7. The minimum committed size of the old gen (OldSize) remains at >>>>> 4m and the minimum >>>>> committed size of the young gen (NewSize) increases to 4m. Note >>>>> that these are the minimum, >>>>> not initial sizes. NewSize is made common to all platforms. >>>>> >>>>> 8. I added a switch InitialHeapSize that can be used to set the >>>>> initial committed size of the heap. >>>>> Absent specification by InitialHeapSize, the initial committed >>>>> size is 1/64th of physical memory >>>>> or OldSize + NewSize, whichever is larger. >>>>> >>>>> 9. I cleaned up some formatting, esp. in globals.hpp. >>>>> >>>>> 10. The default MaxHeapSize is raised from 64m to 96m. For >>>>> systems with <= MaxHeapSize >>>>> physical memory, the minimum heap size is 1/MinRAMFraction of >>>>> physical memory. The >>>>> default value of MinRAMFraction is 2. Thus, a 256m box gets a 96m >>>>> heap, as does a 128m >>>>> box, but a 96m box gets a 48m heap and a 64m box gets a 32m heap. >>>>> The default values of >>>>> MaxRAM and MaxRAMFraction bound the maximum heap size to 256m for >>>>> the client vms, >>>>> 1g for 32-bit server vms and 32g for 64-bit server vms. The >>>>> values for the server vms are >>>>> the same as before. I picked 256m for client because I wanted to >>>>> bound resource utilization >>>>> on client systems. Also, benchmarks runs showed no extra benefit >>>>> from going to 512m heaps. >>>>> 512m is the safe maximum for the serial collector. >>>>> >>>>> Thanks, >>>>> >>>>> Paul >>>>> >>>>> >>>>> >>>>> >>>>> > From Paul.Hohensee at Sun.COM Wed Oct 28 12:59:35 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Wed, 28 Oct 2009 15:59:35 -0400 Subject: Pls review 6887571 In-Reply-To: <4AE89ACE.5090702@sun.com> References: <4AE71F41.3030009@sun.com> <4AE779AB.3040907@Sun.COM> <4AE77BDD.7010603@sun.com> <4AE8627A.6080706@Sun.COM> <4AE89982.3060606@Sun.COM> <4AE89ACE.5090702@sun.com> Message-ID: <4AE8A2A7.1080404@sun.com> I've filed 6896099 to track CMS and default ergo integration. Paul Hohensee wrote: > Excellent. Thanks! > > Y.S.Ramakrishna at Sun.COM wrote: >> See my previous email re treatment of CMS wrt the ergo heap sizing >> affected here. I am find, though, with that happening is a separate CR. >> So I am fine with this going in in the current state (i.e. Paul's >> latest webrev as of this writing (webrev.04)). >> >> thanks. >> -- ramki >> >> On 10/28/09 08:25, Jon Masamitsu wrote: >>> Comment should probably say "initial heap size" instead of "minimum >>> heap size". >>> >>> 1357 if (!FLAG_IS_DEFAULT(InitialHeapSize)) { >>> 1358 // A minimum heap size was specified on the command line, >>> >>> >>> Instead of this, >>> >>> 2719 // Set heap size based on available physical memory. >>> 2720 // CMS uses its own heap size ergo. >>> 2721 if (!UseConcMarkSweepGC) { >>> 2722 set_heap_size(); >>> 2723 } >>> 2724 >>> 2725 if (UseParallelGC || UseParallelOldGC) { >>> 2726 // Set some flags for ParallelGC if needed. >>> 2727 set_parallel_gc_flags(); >>> 2728 } else if (UseConcMarkSweepGC) { >>> 2729 // Set some flags for CMS >>> 2730 set_cms_and_parnew_gc_flags(); >>> 2731 } else if (UseParNewGC) { >>> 2732 // Set some flags for ParNew >>> 2733 set_parnew_gc_flags(); >>> 2734 } else if (UseG1GC) { >>> 2735 // Set some flags for garbage-first, if needed. >>> 2736 set_g1_gc_flags(); >>> 2737 } >>> >>> consider >>> >>> if (UseConcMarkSweepGC) { >>> // Set some flags for cms and ParNew. If both >>> // UseConcMarkSweepGC and UseParNewGC are set, >>> // this is the call that should be done. >>> set_cms_and_parnew_gc_flags(); >>> } else { >>> set_heap_size(); >>> if (UseParallelGC || UseParallelOldGC) { >>> // Set some flags for ParallelGC if needed. >>> set_parallel_gc_flags(); >>> } else if (UseParNewGC) { >>> // Set some flags for ParNew >>> set_parnew_gc_flags(); >>> } else if (UseG1GC) { >>> // Set some flags for garbage-first, if needed. >>> set_g1_gc_flags(); >>> } >>> } >>> >>> >>> I'd suggest adding the newly obsoleted flags (e.g., DefaultMaxRAM) >>> to the obsolete_jvm_flags[] in arguments.cpp. For example >>> >>> { "DefaultMaxRAM)", JDK_Version::jdk_update(6,16), >>> JDK_Version::jdk(8) } >>> >>> >>> That's all. >>> >>> >>> On 10/27/09 16:01, Paul Hohensee wrote: >>>> .02 has the fix for line 1105. >>>> >>>> I'll change MaxErgoHeapSize to ErgoHeapSizeLimit, unless someone >>>> else has another opinion. I'm not proud. :) >>>> >>>> Thanks for the review, and for reviewing interim versions. >>>> >>>> Paul >>>> >>>> Jon Masamitsu wrote: >>>>> Paul, >>>>> >>>>> Just a couple of comments from the .01 version >>>>> of the webrev. I haven't started the .02 version >>>>> yet so may have more comments after I do. >>>>> >>>>> Jon >>>>> >>>>> arguments.cpp >>>>> >>>>> 1105 InitialHeapSize = min_new + OldSize; >>>>> >>>>> Use FLAG_SET_ERGO() >>>>> >>>>> FLAG_SET_ERGO(uintx, InitialHeapSize, min_new + OldSize); >>>>> >>>>> Sometimes in the setting of the GC policies we like to >>>>> know how the flag was set. >>>>> >>>>> I like ErgoHeapSizeLimit instead of >>>>> MaxErgoHeapSize but just my preference. >>>>> >>>>> >>>>> >>>>> On 10/27/09 09:26, Paul Hohensee wrote: >>>>>> 6887571: Increase default heap config sizes >>>>>> >>>>>> Webrev here >>>>>> >>>>>> http://cr.openjdk.java.net/~phh/6887571/webrev.01/ >>>>>> >>>>>> Some background: >>>>>> >>>>>> The default client vm heap config since 2000 for sparc32 has been >>>>>> the equivalent of >>>>>> >>>>>> -Xmx64m -XX:OldSize=4m -XX:NewSize=2m -XX:NewRatio=8 >>>>>> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 >>>>>> >>>>>> and for 32-bit x86 >>>>>> >>>>>> -Xmx64m -XX:OldSize=4m -XX:NewSize=1m -XX:NewRatio=12 >>>>>> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 >>>>>> >>>>>> OldSize and NewSize are the initial committed sizes of the old >>>>>> and young generations >>>>>> respectively. A minor gc is required to increase the committed >>>>>> size of the young gen, >>>>>> while a full gc is required to increase the committed size of the >>>>>> old gen. >>>>>> >>>>>> At the time, 64m was half of the 128m of memory typically >>>>>> available on high-end >>>>>> desktops, many client applications were satisfied with small >>>>>> heaps (hence the >>>>>> low -Xms value), and gc times were such that the young gen had to >>>>>> be small >>>>>> in order to minimize pause times. >>>>>> >>>>>> Since that time, low end desktops and laptops, as well as >>>>>> netbooks and smartbooks, >>>>>> typically come with 256m, client applications have become much >>>>>> more "server-like", >>>>>> and we've realized that a small young gen size increases the >>>>>> frequency of young gcs >>>>>> and the amount of transient data promoted to the old gen to >>>>>> levels that noticeably >>>>>> impact startup and steady-state performance, principally by >>>>>> provoking full gcs. >>>>>> >>>>>> This change extends server class heap sizing to the client with a >>>>>> few changes. >>>>>> Server heap sizing ergonomics should be unaffected. >>>>>> >>>>>> 1. NewRatio is set to 2 for all platforms to accomodate an >>>>>> increase in transient data size. >>>>>> >>>>>> 2. SurvivorRatio is set to 8 for all platforms. It was 8 for >>>>>> every platform except >>>>>> 64-bit x86 (where it was 6) in any case, so it isn't a big change. >>>>>> >>>>>> 3. MaxTenuringThreshold is left at 15 (the maximum). >>>>>> >>>>>> 4. I added MaxRAM, whose implemented definition matches the >>>>>> current comment for DefaultMaxRAM >>>>>> in globals.hpp. MaxRAM is the maximum physical memory size used >>>>>> to compute MaxHeapSize >>>>>> rather than the maximum possible value of MaxHeapSize set by >>>>>> ergonomics. I replaced >>>>>> DefaultMaxRAM with MaxErgoHeapSize for the latter purpose. I >>>>>> added support for a new >>>>>> argument type, uint64_t, and used it as the type of MaxRAM. >>>>>> uintx doesn't have the necessary >>>>>> range on 32-bit systems: a user might want to specify 4g for >>>>>> MaxRAM on a 32-bit system. >>>>>> >>>>>> 5. The other Default* switches have been stripped of the >>>>>> "Default" prefix, since to me their >>>>>> values are just as much "default" values as the values of any of >>>>>> other vm switch, and those don't >>>>>> have a "Default" prefix. I left DefaultMaxRAMFraction as a >>>>>> synonym for MaxRAMFraction for >>>>>> the moment because QA uses it. When they change to >>>>>> MaxRAMFraction, I intend to remove >>>>>> DefaultMaxRAMFraction. >>>>>> >>>>>> 6. In arguments.cpp, set_heap_size() replaces >>>>>> set_server_heap_size() and is used for everything >>>>>> except CMS. CMS has it's own, incompatible (I know: I tried it), >>>>>> heap sizing ergonomics. >>>>>> >>>>>> 7. The minimum committed size of the old gen (OldSize) remains at >>>>>> 4m and the minimum >>>>>> committed size of the young gen (NewSize) increases to 4m. Note >>>>>> that these are the minimum, >>>>>> not initial sizes. NewSize is made common to all platforms. >>>>>> >>>>>> 8. I added a switch InitialHeapSize that can be used to set the >>>>>> initial committed size of the heap. >>>>>> Absent specification by InitialHeapSize, the initial committed >>>>>> size is 1/64th of physical memory >>>>>> or OldSize + NewSize, whichever is larger. >>>>>> >>>>>> 9. I cleaned up some formatting, esp. in globals.hpp. >>>>>> >>>>>> 10. The default MaxHeapSize is raised from 64m to 96m. For >>>>>> systems with <= MaxHeapSize >>>>>> physical memory, the minimum heap size is 1/MinRAMFraction of >>>>>> physical memory. The >>>>>> default value of MinRAMFraction is 2. Thus, a 256m box gets a >>>>>> 96m heap, as does a 128m >>>>>> box, but a 96m box gets a 48m heap and a 64m box gets a 32m >>>>>> heap. The default values of >>>>>> MaxRAM and MaxRAMFraction bound the maximum heap size to 256m for >>>>>> the client vms, >>>>>> 1g for 32-bit server vms and 32g for 64-bit server vms. The >>>>>> values for the server vms are >>>>>> the same as before. I picked 256m for client because I wanted to >>>>>> bound resource utilization >>>>>> on client systems. Also, benchmarks runs showed no extra benefit >>>>>> from going to 512m heaps. >>>>>> 512m is the safe maximum for the serial collector. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Paul >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >> From Y.S.Ramakrishna at Sun.COM Wed Oct 28 13:13:27 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Wed, 28 Oct 2009 13:13:27 -0700 Subject: Pls review 6887571 In-Reply-To: <4AE89AAB.8070002@sun.com> References: <4AE71F41.3030009@sun.com> <4AE7488E.2010408@Sun.COM> <4AE77057.7050709@sun.com> <4AE89909.1000202@Sun.COM> <4AE89AAB.8070002@sun.com> Message-ID: <4AE8A5E7.5080903@Sun.COM> On 10/28/09 12:25, Paul Hohensee wrote: > Thanks for the review (and the previous one too). > > Yes, I feel queasy about changing CMS ergo. Using the code in > set_heap_size() with cms produced some pretty weird results, such > as initial gen1 sizes of 64kb. I investigated a bit and decided to leave > well enough alone. I'll be happy to file an rfe to integrate cms and > common heap ergo. Would that be acceptable? Absolutely. Thanks for filing the rfe! -- ramki > > Paul > > Y.S.Ramakrishna at Sun.COM wrote: >> On 10/27/09 15:12, Paul Hohensee wrote: >>> Yes, I forgot to uncomment line 1383. Fixed. >>> >>> Fixed line 1612. >> >> Thanks. >> >>> >>> It's a good thing you asked me to get cms dumps. Turned out I'd >>> typo'ed and >>> had an earlier version of arguments.cpp. The earlier version didn't >>> separate >>> cms ergo from everything-else ergo. New webrev here >>> >>> http://cr.openjdk.java.net/~phh/6887571/webrev.02/ >> >> I think I will need to discuss this further with you. I actually prefer >> the older version you had where the heap size is set ergonomically unless >> explicitly specified in the case of CMS as well. The CMS ergo will take >> that as a given and _shape_ the generations within those constraints. >> That would be >> my preferred model of CMS ergo -- basically, what you had in your >> earlier webrev. However, I understand if you and others feel leery about >> touching CMS ergo for other reasons and would prefer any such changes >> to be >> affected in a subsequent CR which does due diligence in >> measuring the performance delta of that change for CMS specifically. >> >> -- ramki >> >>> >>> With the new version, running >>> >>> java -client -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+Verbose >>> -version >>> >>> I get >>> >>> VM option '+UseConcMarkSweepGC' >>> VM option '+PrintGCDetails' >>> VM option '+Verbose' >>> Turning off use of shared archive because of choice of garbage >>> collector or large pages >>> Ergo set MaxNewSize: 134217728 >>> CMS set min_heap_size: 0 initial_heap_size: 0 max_heap: 100663296 >>> Ergo set NewSize: 16777216 >>> Ergo set OldSize: 50331648 >>> Minimum heap 67108864 Initial heap 67108864 Maximum heap 100663296 >>> Minimum gen0 16777216 Initial gen0 16777216 Maximum gen0 16777216 >>> Minimum gen1 50331648 Initial gen1 50331648 Maximum gen1 83886080 >>> >>> java version "1.7.0-ea" >>> Java(TM) SE Runtime Environment (build 1.7.0-ea-b39) >>> OpenJDK Client VM (build 17.0-b03-internal-jvmg, mixed mode) >>> Heap >>> par new generation total 14784K, used 527K [0xf1800000, 0xf2800000, >>> 0xf2800000) >>> eden space 13184K, 4% used [0xf1800000, 0xf1883de8, 0xf24e0000) >>> from space 1600K, 0% used [0xf24e0000, 0xf24e0000, 0xf2670000) >>> to space 1600K, 0% used [0xf2670000, 0xf2670000, 0xf2800000) >>> concurrent mark-sweep generation total 49152K, used 0K [0xf2800000, >>> 0xf5800000, 0xf7800000) >>> concurrent-mark-sweep perm gen total 12288K, used 1497K [0xf7800000, >>> 0xf8400000, 0xfb800000) >>> >>> With the unmodified vm, I get >>> >>> VM option '+UseConcMarkSweepGC' >>> VM option '+PrintGCDetails' >>> VM option '+Verbose' >>> Turning off use of shared archive because of choice of garbage >>> collector or large pages >>> Ergo set MaxNewSize: 134217728 >>> CMS set min_heap_size: 0 initial_heap_size: 0 max_heap: 67108864 >>> Ergo set NewSize: 16777216 >>> Ergo set OldSize: 50331648 >>> Minimum heap 67108864 Initial heap 67108864 Maximum heap 67108864 >>> Minimum gen0 16777216 Initial gen0 16777216 Maximum gen0 16777216 >>> Minimum gen1 50331648 Initial gen1 50331648 Maximum gen1 50331648 >>> >>> java version "1.7.0-ea" >>> Java(TM) SE Runtime Environment (build 1.7.0-ea-b39) >>> OpenJDK Client VM (build 17.0-b03-internal-jvmg, mixed mode) >>> Heap >>> par new generation total 14784K, used 527K [0xf3800000, 0xf4800000, >>> 0xf4800000) >>> eden space 13184K, 4% used [0xf3800000, 0xf3883de8, 0xf44e0000) >>> from space 1600K, 0% used [0xf44e0000, 0xf44e0000, 0xf4670000) >>> to space 1600K, 0% used [0xf4670000, 0xf4670000, 0xf4800000) >>> concurrent mark-sweep generation total 49152K, used 0K [0xf4800000, >>> 0xf7800000, 0xf7800000) >>> concurrent-mark-sweep perm gen total 12288K, used 1497K [0xf7800000, >>> 0xf8400000, 0xfb800000) >>> >>> They're identical, except for the total heap size and ergo-computed >>> old gen >>> size, which are 96m and 80m respectively. That's because I increased >>> the >>> value of MaxNewSize from 64m to 96m. >>> >>> -server instead of -client produces the same result. >>> >>> Paul >>> >>> Y.S.Ramakrishna at Sun.COM wrote: >>>> Hi Paul -- >>>> >>>> Did you forget to remove the commenting out of the second conjunct in >>>> arguments.cpp:1383 below:- >>>> >>>> 1383 if (PrintGCDetails/* && Verbose*/) { >>> Yes, fixed. >>>> >>>> Could you do me a favour and change the following in >>>> arguments.cpp:1612 from:- >>>> >>>> 1612 if (UseSharedSpaces) { >>>> >>>> to:- >>>> >>>> 1612 if (UseSharedSpaces && Verbose) { >>>> >>>> The verbosity of the message at 1613:1615 has been >>>> bothering some of us for a while (mea culpa for adding >>>> it recentkly), but i didn't get around to removing it, and this >>>> looks like an good opportunity to do so with no new overhead :-) >>> Done. >>>> >>>> On 10/27/09 09:26, Paul Hohensee wrote: >>>> ... >>>>> 6. In arguments.cpp, set_heap_size() replaces >>>>> set_server_heap_size() and is used for everything >>>>> except CMS. CMS has it's own, incompatible (I know: I tried it), >>>>> heap sizing ergonomics. >>>> >>>> Could you provide the result of:- >>>> >>>> % java -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -version >>>> >>>> with the baseline VM and with the VM after yr changes? >>>> >>>> >>>> Rest looks good to me; thanks! >>>> -- ramki >>>> >> From xiaobin.lu at sun.com Wed Oct 28 14:10:30 2009 From: xiaobin.lu at sun.com (xiaobin.lu at sun.com) Date: Wed, 28 Oct 2009 21:10:30 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20091028211037.0298641627@hg.openjdk.java.net> Changeset: 08780c8a9f04 Author: kamg Date: 2009-10-20 16:34 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/08780c8a9f04 6893483: DTrace probe return values for a couple JNI methods are wrong Summary: Fix the shadowing and incorrect macro usages Reviewed-by: coleenp ! src/share/vm/prims/jni.cpp Changeset: a3b9e96881fe Author: xlu Date: 2009-10-23 18:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a3b9e96881fe Merge Changeset: d912f17c1ae4 Author: xlu Date: 2009-10-28 10:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d912f17c1ae4 Merge From guanxiaohua at gmail.com Wed Oct 28 20:54:21 2009 From: guanxiaohua at gmail.com (Tony Guan) Date: Wed, 28 Oct 2009 22:54:21 -0500 Subject: How to get the family tree of all the threads? Message-ID: <2fcb552b0910282054l7b7ba568md3b20101fea240b6@mail.gmail.com> Hi, I am working on a project where I need to identify the relations between parent threads and children threads. Especially, I want to do it inside the JVM, not in a java program. Looking at the code of hotspot, I can only find the thread list inside the Thread class, but it's not enough for my purpose. Is there some way that I can draw out a family tree of the threads within the hotspot? I know that from within a java program, we can draw a tree of all the ThreadGroups, but it again is not what I want. Or could you tell me how I could identify when a thread is created, and who is the parental thread that creates it? Thanks a lot! Tony Guan From Christian.Thalinger at Sun.COM Thu Oct 29 02:21:23 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 29 Oct 2009 10:21:23 +0100 Subject: How to get the family tree of all the threads? In-Reply-To: <2fcb552b0910282054l7b7ba568md3b20101fea240b6@mail.gmail.com> References: <2fcb552b0910282054l7b7ba568md3b20101fea240b6@mail.gmail.com> Message-ID: <1256808083.3638.30.camel@macbook> On Wed, 2009-10-28 at 22:54 -0500, Tony Guan wrote: > Hi, > > I am working on a project where I need to identify the relations > between parent threads and children threads. Especially, I want to do > it inside the JVM, not in a java program. > > Looking at the code of hotspot, I can only find the thread list inside > the Thread class, but it's not enough for my purpose. > > Is there some way that I can draw out a family tree of the threads > within the hotspot? I know that from within a java program, we can > draw a tree of all the ThreadGroups, but it again is not what I want. > > Or could you tell me how I could identify when a thread is created, > and who is the parental thread that creates it? I think the easiest solution would be to use JVMTI, but it seems you really want to do this in the VM. The method you are searching for is JVM_StartThread, this is where all Java threads are created. -- Christian From Alan.Bateman at Sun.COM Thu Oct 29 03:49:25 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 29 Oct 2009 10:49:25 +0000 Subject: How to get the family tree of all the threads? In-Reply-To: <1256808083.3638.30.camel@macbook> References: <2fcb552b0910282054l7b7ba568md3b20101fea240b6@mail.gmail.com> <1256808083.3638.30.camel@macbook> Message-ID: <4AE97335.9070705@sun.com> Christian Thalinger wrote: > : > I think the easiest solution would be to use JVMTI, but it seems you > really want to do this in the VM. The method you are searching for is > JVM_StartThread, this is where all Java threads are created. > > -- Christian > > I agree that an agent based solution is probably the easiest. The Thread constructors or start method could be instrumented (depending on if the parent is considered to be the thread that creates the Thread or the thread that invokes start). Should be doable with with a JVM TI or j.l.instrument agent. -Alan. From David.Holmes at Sun.COM Thu Oct 29 04:39:06 2009 From: David.Holmes at Sun.COM (David Holmes) Date: Thu, 29 Oct 2009 21:39:06 +1000 Subject: How to get the family tree of all the threads? In-Reply-To: <2fcb552b0910282054l7b7ba568md3b20101fea240b6@mail.gmail.com> References: <2fcb552b0910282054l7b7ba568md3b20101fea240b6@mail.gmail.com> Message-ID: <4AE97EDA.5030206@sun.com> Hi Tony, > I am working on a project where I need to identify the relations > between parent threads and children threads. Especially, I want to do > it inside the JVM, not in a java program. As others have said you need to do this yourself by monitoring thread construction and/or starting. In Java there is no parent/child relationship between threads - all threads are considered equal siblings. This is in contrast to other systems where "child" threads are an explicit notion where exceptions in a child can be caught in a parent; where joining a parent joins all children etc. But that's not Java. Cheers, David Holmes > Looking at the code of hotspot, I can only find the thread list inside > the Thread class, but it's not enough for my purpose. > > Is there some way that I can draw out a family tree of the threads > within the hotspot? I know that from within a java program, we can > draw a tree of all the ThreadGroups, but it again is not what I want. > > Or could you tell me how I could identify when a thread is created, > and who is the parental thread that creates it? > > Thanks a lot! > > Tony Guan From mr at sun.com Thu Oct 29 10:08:00 2009 From: mr at sun.com (Mark Reinhold) Date: Thu, 29 Oct 2009 10:08:00 -0700 Subject: JDK 7 linux/solaris build failures In-Reply-To: kelly.ohair@sun.com; Thu, 29 Oct 2009 10:00:57 PDT; <4AE9CA49.9060807@sun.com> Message-ID: <20091029170800.EB811384@eggemoggin.niobe.net> (moving to open lists) > Date: Thu, 29 Oct 2009 10:00:57 -0700 > From: kelly.ohair at sun.com > This hotspot change broke the jdk makefiles: > > 6722084: JPRT make file doesn't create required symbolic link to libjvm.so > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/23862fc517bb Thanks for the diagnosis. > In the meantime, I will need to try and fix this in the jdk makefiles. > Stay tuned ... Why fix this in the jdk makefiles if it's a HotSpot problem? - Mark From Kelly.Ohair at Sun.COM Thu Oct 29 10:31:29 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 29 Oct 2009 10:31:29 -0700 Subject: JDK 7 linux/solaris build failures In-Reply-To: <20091029170800.EB811384@eggemoggin.niobe.net> References: <20091029170800.EB811384@eggemoggin.niobe.net> Message-ID: <4AE9D171.40400@sun.com> Mark Reinhold wrote: > (moving to open lists) > >> Date: Thu, 29 Oct 2009 10:00:57 -0700 >> From: kelly.ohair at sun.com > >> This hotspot change broke the jdk makefiles: >> >> 6722084: JPRT make file doesn't create required symbolic link to libjvm.so >> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/23862fc517bb > > Thanks for the diagnosis. > >> In the meantime, I will need to try and fix this in the jdk makefiles. >> Stay tuned ... > > Why fix this in the jdk makefiles if it's a HotSpot problem? > Quickest path to getting us past this... File is jdk/make/java/redist/Makefile, maybe a one line change: 214c214 < $(LIB_LOCATION)/$(LIBJSIG_NAME): $(HOTSPOT_SERVER_PATH)/$(LIBJSIG_NAME) --- > $(LIB_LOCATION)/$(LIBJSIG_NAME): $(HOTSPOT_IMPORT_PATH)/lib/$(LIBARCH)/$(LIBJSIG_NAME) I'm testing this out now... Undoing all the hotspot changes seemed a bit drastic... -kto > - Mark From mr at sun.com Thu Oct 29 10:34:34 2009 From: mr at sun.com (Mark Reinhold) Date: Thu, 29 Oct 2009 10:34:34 -0700 Subject: JDK 7 linux/solaris build failures In-Reply-To: kelly.ohair@sun.com; Thu, 29 Oct 2009 10:31:29 PDT; <4AE9D171.40400@sun.com> Message-ID: <20091029173434.C615D384@eggemoggin.niobe.net> > Date: Thu, 29 Oct 2009 10:31:29 -0700 > From: kelly.ohair at sun.com > Quickest path to getting us past this... > > File is jdk/make/java/redist/Makefile, maybe a one line change: > > 214c214 > < $(LIB_LOCATION)/$(LIBJSIG_NAME): $(HOTSPOT_SERVER_PATH)/$(LIBJSIG_NAME) > --- >> $(LIB_LOCATION)/$(LIBJSIG_NAME): $(HOTSPOT_IMPORT_PATH)/lib/$(LIBARCH)/$(LIBJSIG_NAME) > > I'm testing this out now... Okay, thanks. > Undoing all the hotspot changes seemed a bit drastic... Agreed; I wouldn't have suggested that. - Mark From Kelly.Ohair at Sun.COM Thu Oct 29 10:57:05 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 29 Oct 2009 10:57:05 -0700 Subject: JDK 7 linux/solaris build failures In-Reply-To: <20091029173434.C615D384@eggemoggin.niobe.net> References: <20091029173434.C615D384@eggemoggin.niobe.net> Message-ID: <4AE9D771.4010308@sun.com> I think this is the fix... it is taking some time to completely verify it. Can someone review this change? And do I have approval to push directly into master? ------- diff --git a/make/java/redist/Makefile b/make/java/redist/Makefile --- a/make/java/redist/Makefile +++ b/make/java/redist/Makefile @@ -216,7 +216,7 @@ endif # PLATFORM $(LIB_LOCATION)/$(KERNEL_LOCATION)/$(JVM_NAME): $(HOTSPOT_KERNEL_PATH)/$(JVM_NAME) $(install-file) -$(LIB_LOCATION)/$(LIBJSIG_NAME): $(HOTSPOT_SERVER_PATH)/$(LIBJSIG_NAME) +$(LIB_LOCATION)/$(LIBJSIG_NAME): $(HOTSPOT_IMPORT_PATH)/jre/lib/$(LIBARCH)/$(LIBJSIG_NAME) $(install-import-file) $(LIB_LOCATION)/$(CLIENT_LOCATION)/$(LIBJSIG_NAME) \ ------- A little background, for the record (while I wait for this build to finish ): The files exported by the hotspot makefiles for import to the jdk come in the shape of a sparse jdk install image, and the jdk Makefile jdk/make/java/redist/Makefile is responsible for copying or importing these files from this hotspot exported area, into the final jdk image. This hotspot area is specified via the ALT_HOTSPOT_{IMPORT,SERVER,CLIENT}_PATH variables, or could be the ALT_JDK_IMPORT_PATH setting for partial builds. If the hotspot team changes what it exports, this jdk makefile may need to change, and if the hotspot team wants to impact the shape or layout of the final jdk image with regards to their files, they need to address this in the jdk/make/java/redist/Makefile. -kto From mr at sun.com Thu Oct 29 11:02:16 2009 From: mr at sun.com (Mark Reinhold) Date: Thu, 29 Oct 2009 11:02:16 -0700 Subject: JDK 7 linux/solaris build failures In-Reply-To: kelly.ohair@sun.com; Thu, 29 Oct 2009 10:57:05 PDT; <4AE9D771.4010308@sun.com> Message-ID: <20091029180216.83F67384@eggemoggin.niobe.net> > Date: Thu, 29 Oct 2009 10:57:05 -0700 > From: kelly.ohair at sun.com > I think this is the fix... it is taking some time to completely > verify it. > > Can someone review this change? > > And do I have approval to push directly into master? Yes. Michael -- Could you please re-start the RE builds after Kelly pushes his fix? Thanks. - Mark From Tim.Bell at Sun.COM Thu Oct 29 11:04:23 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Thu, 29 Oct 2009 11:04:23 -0700 Subject: JDK 7 linux/solaris build failures In-Reply-To: <4AE9D771.4010308@sun.com> References: <20091029173434.C615D384@eggemoggin.niobe.net> <4AE9D771.4010308@sun.com> Message-ID: <4AE9D927.30200@sun.com> Kelly O'Hair wrote: > I think this is the fix... it is taking some time to completely > verify it. > > Can someone review this change? See below > And do I have approval to push directly into master? > > ------- > > diff --git a/make/java/redist/Makefile b/make/java/redist/Makefile > --- a/make/java/redist/Makefile > +++ b/make/java/redist/Makefile > @@ -216,7 +216,7 @@ endif # PLATFORM > $(LIB_LOCATION)/$(KERNEL_LOCATION)/$(JVM_NAME): $(HOTSPOT_KERNEL_PATH)/$(JVM_NAME) > $(install-file) > > -$(LIB_LOCATION)/$(LIBJSIG_NAME): $(HOTSPOT_SERVER_PATH)/$(LIBJSIG_NAME) > +$(LIB_LOCATION)/$(LIBJSIG_NAME): $(HOTSPOT_IMPORT_PATH)/jre/lib/$(LIBARCH)/$(LIBJSIG_NAME) > $(install-import-file) How about: -$(LIB_LOCATION)/$(LIBJSIG_NAME): $(HOTSPOT_SERVER_PATH)/$(LIBJSIG_NAME) --- +$(LIB_LOCATION)/$(LIBJSIG_NAME): $(HOTSPOT_IMPORT_PATH)/$(ARCH_VM_SUBDIR)/$(LIBJSIG_NAME) This got me past the problem in my test build. I am re-running a full build from scratch now. Either way you go, feel free to use me as a reviewer. Tim > $(LIB_LOCATION)/$(CLIENT_LOCATION)/$(LIBJSIG_NAME) \ > > > ------- > > A little background, for the record (while I wait for this build to > finish ): > > The files exported by the hotspot makefiles for import to the jdk > come in the shape of a sparse jdk install image, and the jdk Makefile > jdk/make/java/redist/Makefile is responsible for copying or importing > these files from this hotspot exported area, into the final jdk image. > This hotspot area is specified via the > ALT_HOTSPOT_{IMPORT,SERVER,CLIENT}_PATH > variables, or could be the ALT_JDK_IMPORT_PATH setting for partial builds. > > If the hotspot team changes what it exports, this jdk makefile may need > to change, and if the hotspot team wants to impact the shape or layout > of the final jdk image with regards to their files, they need to address > this in the jdk/make/java/redist/Makefile. > > -kto From Paul.Hohensee at Sun.COM Thu Oct 29 11:04:47 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Thu, 29 Oct 2009 14:04:47 -0400 Subject: JDK 7 linux/solaris build failures In-Reply-To: <4AE9D771.4010308@sun.com> References: <20091029173434.C615D384@eggemoggin.niobe.net> <4AE9D771.4010308@sun.com> Message-ID: <4AE9D93F.6020600@sun.com> Looks good to me. Kelly O'Hair wrote: > > I think this is the fix... it is taking some time to completely > verify it. > > Can someone review this change? > > And do I have approval to push directly into master? > > ------- > > diff --git a/make/java/redist/Makefile b/make/java/redist/Makefile > --- a/make/java/redist/Makefile > +++ b/make/java/redist/Makefile > @@ -216,7 +216,7 @@ endif # PLATFORM > $(LIB_LOCATION)/$(KERNEL_LOCATION)/$(JVM_NAME): > $(HOTSPOT_KERNEL_PATH)/$(JVM_NAME) > $(install-file) > > -$(LIB_LOCATION)/$(LIBJSIG_NAME): $(HOTSPOT_SERVER_PATH)/$(LIBJSIG_NAME) > +$(LIB_LOCATION)/$(LIBJSIG_NAME): > $(HOTSPOT_IMPORT_PATH)/jre/lib/$(LIBARCH)/$(LIBJSIG_NAME) > $(install-import-file) > > $(LIB_LOCATION)/$(CLIENT_LOCATION)/$(LIBJSIG_NAME) \ > > > ------- > > A little background, for the record (while I wait for this build to > finish ): > > The files exported by the hotspot makefiles for import to the jdk > come in the shape of a sparse jdk install image, and the jdk Makefile > jdk/make/java/redist/Makefile is responsible for copying or importing > these files from this hotspot exported area, into the final jdk image. > This hotspot area is specified via the > ALT_HOTSPOT_{IMPORT,SERVER,CLIENT}_PATH > variables, or could be the ALT_JDK_IMPORT_PATH setting for partial > builds. > > If the hotspot team changes what it exports, this jdk makefile may need > to change, and if the hotspot team wants to impact the shape or layout > of the final jdk image with regards to their files, they need to address > this in the jdk/make/java/redist/Makefile. > > -kto From Vladimir.Kozlov at Sun.COM Thu Oct 29 11:07:28 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 29 Oct 2009 11:07:28 -0700 Subject: JDK 7 linux/solaris build failures In-Reply-To: <4AE9D927.30200@sun.com> References: <20091029173434.C615D384@eggemoggin.niobe.net> <4AE9D771.4010308@sun.com> <4AE9D927.30200@sun.com> Message-ID: <4AE9D9E0.1030201@sun.com> Kelly, I like Tim's fix. Vladimir Tim Bell wrote: > Kelly O'Hair wrote: >> I think this is the fix... it is taking some time to completely >> verify it. >> >> Can someone review this change? > > See below > >> And do I have approval to push directly into master? >> >> ------- >> >> diff --git a/make/java/redist/Makefile b/make/java/redist/Makefile >> --- a/make/java/redist/Makefile >> +++ b/make/java/redist/Makefile >> @@ -216,7 +216,7 @@ endif # PLATFORM >> $(LIB_LOCATION)/$(KERNEL_LOCATION)/$(JVM_NAME): $(HOTSPOT_KERNEL_PATH)/$(JVM_NAME) >> $(install-file) >> >> -$(LIB_LOCATION)/$(LIBJSIG_NAME): $(HOTSPOT_SERVER_PATH)/$(LIBJSIG_NAME) >> +$(LIB_LOCATION)/$(LIBJSIG_NAME): $(HOTSPOT_IMPORT_PATH)/jre/lib/$(LIBARCH)/$(LIBJSIG_NAME) >> $(install-import-file) > > How about: > > -$(LIB_LOCATION)/$(LIBJSIG_NAME): $(HOTSPOT_SERVER_PATH)/$(LIBJSIG_NAME) > --- > +$(LIB_LOCATION)/$(LIBJSIG_NAME): $(HOTSPOT_IMPORT_PATH)/$(ARCH_VM_SUBDIR)/$(LIBJSIG_NAME) > > > This got me past the problem in my test build. I am re-running a full build from > scratch now. > > Either way you go, feel free to use me as a reviewer. > > Tim > > >> $(LIB_LOCATION)/$(CLIENT_LOCATION)/$(LIBJSIG_NAME) \ >> >> >> ------- >> >> A little background, for the record (while I wait for this build to >> finish ): >> >> The files exported by the hotspot makefiles for import to the jdk >> come in the shape of a sparse jdk install image, and the jdk Makefile >> jdk/make/java/redist/Makefile is responsible for copying or importing >> these files from this hotspot exported area, into the final jdk image. >> This hotspot area is specified via the >> ALT_HOTSPOT_{IMPORT,SERVER,CLIENT}_PATH >> variables, or could be the ALT_JDK_IMPORT_PATH setting for partial builds. >> >> If the hotspot team changes what it exports, this jdk makefile may need >> to change, and if the hotspot team wants to impact the shape or layout >> of the final jdk image with regards to their files, they need to address >> this in the jdk/make/java/redist/Makefile. >> >> -kto > From Kelly.Ohair at Sun.COM Thu Oct 29 11:11:25 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 29 Oct 2009 11:11:25 -0700 Subject: JDK 7 linux/solaris build failures In-Reply-To: <4AE9D927.30200@sun.com> References: <20091029173434.C615D384@eggemoggin.niobe.net> <4AE9D771.4010308@sun.com> <4AE9D927.30200@sun.com> Message-ID: <4AE9DACD.4090703@sun.com> Thanks Tim, both changes do the same thing, I'll use yours. It's on it's way.... -kto Tim Bell wrote: > Kelly O'Hair wrote: >> I think this is the fix... it is taking some time to completely >> verify it. >> >> Can someone review this change? > > See below > >> And do I have approval to push directly into master? >> >> ------- >> >> diff --git a/make/java/redist/Makefile b/make/java/redist/Makefile >> --- a/make/java/redist/Makefile >> +++ b/make/java/redist/Makefile >> @@ -216,7 +216,7 @@ endif # PLATFORM >> $(LIB_LOCATION)/$(KERNEL_LOCATION)/$(JVM_NAME): $(HOTSPOT_KERNEL_PATH)/$(JVM_NAME) >> $(install-file) >> >> -$(LIB_LOCATION)/$(LIBJSIG_NAME): $(HOTSPOT_SERVER_PATH)/$(LIBJSIG_NAME) >> +$(LIB_LOCATION)/$(LIBJSIG_NAME): $(HOTSPOT_IMPORT_PATH)/jre/lib/$(LIBARCH)/$(LIBJSIG_NAME) >> $(install-import-file) > > How about: > > -$(LIB_LOCATION)/$(LIBJSIG_NAME): $(HOTSPOT_SERVER_PATH)/$(LIBJSIG_NAME) > --- > +$(LIB_LOCATION)/$(LIBJSIG_NAME): $(HOTSPOT_IMPORT_PATH)/$(ARCH_VM_SUBDIR)/$(LIBJSIG_NAME) > > > This got me past the problem in my test build. I am re-running a full build from > scratch now. > > Either way you go, feel free to use me as a reviewer. > > Tim > > >> $(LIB_LOCATION)/$(CLIENT_LOCATION)/$(LIBJSIG_NAME) \ >> >> >> ------- >> >> A little background, for the record (while I wait for this build to >> finish ): >> >> The files exported by the hotspot makefiles for import to the jdk >> come in the shape of a sparse jdk install image, and the jdk Makefile >> jdk/make/java/redist/Makefile is responsible for copying or importing >> these files from this hotspot exported area, into the final jdk image. >> This hotspot area is specified via the >> ALT_HOTSPOT_{IMPORT,SERVER,CLIENT}_PATH >> variables, or could be the ALT_JDK_IMPORT_PATH setting for partial builds. >> >> If the hotspot team changes what it exports, this jdk makefile may need >> to change, and if the hotspot team wants to impact the shape or layout >> of the final jdk image with regards to their files, they need to address >> this in the jdk/make/java/redist/Makefile. >> >> -kto > From Kelly.Ohair at Sun.COM Thu Oct 29 11:19:21 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 29 Oct 2009 11:19:21 -0700 Subject: JDK 7 linux/solaris build failures In-Reply-To: <4AE9DB66.7030704@sun.com> References: <20091029180216.83F67384@eggemoggin.niobe.net> <4AE9DB66.7030704@sun.com> Message-ID: <4AE9DCA9.3050204@sun.com> The deed is done. -kto Michael Wilkerson wrote: > Mark Reinhold wrote: >>> Date: Thu, 29 Oct 2009 10:57:05 -0700 >>> From: kelly.ohair at sun.com >>> >> >> >>> I think this is the fix... it is taking some time to completely >>> verify it. >>> >>> Can someone review this change? >>> >>> And do I have approval to push directly into master? >>> >> >> Yes. >> >> Michael -- Could you please re-start the RE builds after Kelly >> pushes his fix? Thanks. >> >> - Mark >> > Yes, will do. > > thanks, > --Michael > From Michael.Wilkerson at Sun.COM Thu Oct 29 11:13:58 2009 From: Michael.Wilkerson at Sun.COM (Michael Wilkerson) Date: Thu, 29 Oct 2009 11:13:58 -0700 Subject: JDK 7 linux/solaris build failures In-Reply-To: <20091029180216.83F67384@eggemoggin.niobe.net> References: <20091029180216.83F67384@eggemoggin.niobe.net> Message-ID: <4AE9DB66.7030704@sun.com> Mark Reinhold wrote: >> Date: Thu, 29 Oct 2009 10:57:05 -0700 >> From: kelly.ohair at sun.com >> > > >> I think this is the fix... it is taking some time to completely >> verify it. >> >> Can someone review this change? >> >> And do I have approval to push directly into master? >> > > Yes. > > Michael -- Could you please re-start the RE builds after Kelly > pushes his fix? Thanks. > > - Mark > Yes, will do. thanks, --Michael From Michael.Wilkerson at Sun.COM Thu Oct 29 11:23:47 2009 From: Michael.Wilkerson at Sun.COM (Michael Wilkerson) Date: Thu, 29 Oct 2009 11:23:47 -0700 Subject: JDK 7 linux/solaris build failures In-Reply-To: <4AE9DCA9.3050204@sun.com> References: <20091029180216.83F67384@eggemoggin.niobe.net> <4AE9DB66.7030704@sun.com> <4AE9DCA9.3050204@sun.com> Message-ID: <4AE9DDB3.40706@sun.com> OK, ....RE cleanup scripts are running right now, as soon as that's done I'll restart... --Michael Kelly O'Hair wrote: > The deed is done. > > -kto > > Michael Wilkerson wrote: >> Mark Reinhold wrote: >>>> Date: Thu, 29 Oct 2009 10:57:05 -0700 >>>> From: kelly.ohair at sun.com >>>> >>> >>> >>>> I think this is the fix... it is taking some time to completely >>>> verify it. >>>> >>>> Can someone review this change? >>>> >>>> And do I have approval to push directly into master? >>>> >>> >>> Yes. >>> >>> Michael -- Could you please re-start the RE builds after Kelly >>> pushes his fix? Thanks. >>> >>> - Mark >>> >> Yes, will do. >> >> thanks, >> --Michael >> From changpeng.fang at sun.com Thu Oct 29 12:21:42 2009 From: changpeng.fang at sun.com (changpeng.fang at sun.com) Date: Thu, 29 Oct 2009 19:21:42 +0000 Subject: hg: jdk7/hotspot/hotspot: 6 new changesets Message-ID: <20091029192159.B826741799@hg.openjdk.java.net> Changeset: 0a46d0c5dccb Author: never Date: 2009-10-15 11:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0a46d0c5dccb 6891750: deopt blob kills values in O5 Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp + test/compiler/6891750/Test6891750.java Changeset: 71fdc5052e49 Author: cfang Date: 2009-10-16 16:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/71fdc5052e49 Merge Changeset: 987e948ebbc8 Author: jrose Date: 2009-10-17 19:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/987e948ebbc8 6815692: method handle code needs some cleanup (post-6655638) Summary: correctly raise exceptions, support safe bitwise "raw" conversions, fix bugs revealed by VerifyMethodHandles, remove dead code, improve debugging support Reviewed-by: never, twisti ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/markOop.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: 873ec3787992 Author: kvn Date: 2009-10-21 09:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/873ec3787992 6892186: SA does not dump debug info for scalar replaced objects Summary: Implement scalar replaced objects debug info dump in SA. Reviewed-by: twisti ! agent/make/saenv.sh ! agent/make/saenv64.sh ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/code/PCDesc.java ! agent/src/share/classes/sun/jvm/hotspot/code/ScopeDesc.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js ! src/share/vm/opto/callnode.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f875b4f472f7 Author: twisti Date: 2009-10-27 03:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f875b4f472f7 6893554: SPECjvm2008 mpegaudio fails with SecurityException Summary: The problem occurs with negative numbers, as the 32-bit input values are sign extended into the 64-bit registers. Reviewed-by: kvn ! src/cpu/sparc/vm/sparc.ad Changeset: 4926bf2d292f Author: cfang Date: 2009-10-29 08:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4926bf2d292f Merge From guanxiaohua at gmail.com Thu Oct 29 13:15:57 2009 From: guanxiaohua at gmail.com (Tony Guan) Date: Thu, 29 Oct 2009 15:15:57 -0500 Subject: How to get the family tree of all the threads? In-Reply-To: <4AE97EDA.5030206@sun.com> References: <2fcb552b0910282054l7b7ba568md3b20101fea240b6@mail.gmail.com> <4AE97EDA.5030206@sun.com> Message-ID: <2fcb552b0910291315w70127f7bm70e72d0a4e7f2ee6@mail.gmail.com> Hi David & Alan & Christian, Thank you all for the prompt reply! I am currently using such an approach as the following, could you please take a look to see if something might be wrong? 1) added a Thread* field for the JavaThread: Thread* _parent; //to memorize the thread which creates this thread. 2) get the current thread running when a new JavaThread is created, this current thread should be the parent of the to-be created thread, in JavaThread::JavaThread(ThreadFunction entry_point, size_t stack_sz) : _parent=Thread::current(); //tony: we added it for convenience. 3)verify the _parent field in the run() method of the newly created thread, by this time, the current thread should be the child thread created. int ostid_parent=_parent->osthread()->thread_id(); Then if the child thread is ever running, I can get its parent thread. Thanks a lot! Tony On Thu, Oct 29, 2009 at 6:39 AM, David Holmes wrote: > Hi Tony, > >> I am working on a project where I need to identify the relations >> between parent threads and children threads. Especially, I want to do >> it inside the JVM, not in a java program. > > As others have said you need to do this yourself by monitoring thread > construction and/or starting. > > In Java there is no parent/child relationship between threads - all threads > are considered equal siblings. This is in contrast to other systems where > "child" threads are an explicit notion where exceptions in a child can be > caught in a parent; where joining a parent joins all children etc. But > that's not Java. > > Cheers, > David Holmes > >> Looking at the code of hotspot, I can only find the thread list inside >> the Thread class, but it's not enough for my purpose. >> >> Is there some way that I can draw out a family tree of the threads >> within the hotspot? I know that from within a java program, we can >> draw a tree of all the ThreadGroups, but it again is not what I want. >> >> Or could you tell me how I could identify when a thread is created, >> and who is the parental thread that creates it? >> >> Thanks a lot! >> >> Tony Guan > From David.Katleman at Sun.COM Thu Oct 29 13:34:12 2009 From: David.Katleman at Sun.COM (david katleman) Date: Thu, 29 Oct 2009 13:34:12 -0700 Subject: JDK 7 linux/solaris build failures In-Reply-To: <4AE9D771.4010308@sun.com> References: <20091029173434.C615D384@eggemoggin.niobe.net> <4AE9D771.4010308@sun.com> Message-ID: <4AE9FC44.3080609@sun.com> Kelly O'Hair wrote: > This hotspot area is specified via the > ALT_HOTSPOT_{IMPORT,SERVER,CLIENT}_PATH > variables, or could be the ALT_JDK_IMPORT_PATH setting for partial > builds. > > If the hotspot team changes what it exports, this jdk makefile may need > to change, and if the hotspot team wants to impact the shape or layout > of the final jdk image with regards to their files, they need to address > this in the jdk/make/java/redist/Makefile. And if hotspot does change what it exports, there really needs to be a build of jdk to confirm their modifications don't result in a broken build down the line. This shouldn't have gone back to the master without such testing, and especially not on the eve of a promotion. Dave From paul.hohensee at sun.com Thu Oct 29 16:26:16 2009 From: paul.hohensee at sun.com (paul.hohensee at sun.com) Date: Thu, 29 Oct 2009 23:26:16 +0000 Subject: hg: hsx/hsx16/baseline: 6887571: Increase default heap config sizes Message-ID: <20091029232618.DDC83417DD@hg.openjdk.java.net> Changeset: 0799687b7385 Author: phh Date: 2009-10-29 11:45 -0400 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/0799687b7385 6887571: Increase default heap config sizes Summary: Apply modification of existing server heap size ergo to all collectors except CMS. Reviewed-by: jmasa, ysr, xlu ! src/cpu/sparc/vm/c1_globals_sparc.hpp ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/c1_globals_x86.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/globals_windows_x86.hpp ! src/share/vm/gc_implementation/parallelScavenge/psGCAdaptivePolicyCounters.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/services/management.cpp From David.Holmes at Sun.COM Thu Oct 29 18:54:29 2009 From: David.Holmes at Sun.COM (David Holmes) Date: Fri, 30 Oct 2009 11:54:29 +1000 Subject: How to get the family tree of all the threads? In-Reply-To: <2fcb552b0910291315w70127f7bm70e72d0a4e7f2ee6@mail.gmail.com> References: <2fcb552b0910282054l7b7ba568md3b20101fea240b6@mail.gmail.com> <4AE97EDA.5030206@sun.com> <2fcb552b0910291315w70127f7bm70e72d0a4e7f2ee6@mail.gmail.com> Message-ID: <4AEA4755.4010400@sun.com> Tony, Just a note that there will be two cases where there is no currentThread: a) when the main thread is created b) when the main thread detaches (after executing main) and reattaches as the DestroyJavaVM thread. but this shouldn't affect your parent check in run() David Tony Guan wrote: > Hi David & Alan & Christian, > > Thank you all for the prompt reply! I am currently using such an > approach as the following, could you please take a look to see if > something might be wrong? > > 1) added a Thread* field for the JavaThread: > Thread* _parent; //to memorize the thread which creates this thread. > 2) get the current thread running when a new JavaThread is created, > this current thread should be the parent of the to-be created thread, > in JavaThread::JavaThread(ThreadFunction entry_point, size_t stack_sz) > : > _parent=Thread::current(); //tony: we added it for convenience. > 3)verify the _parent field in the run() method of the newly created > thread, by this time, the current thread should be the child thread > created. > int ostid_parent=_parent->osthread()->thread_id(); > > Then if the child thread is ever running, I can get its parent thread. > > Thanks a lot! > > Tony > > On Thu, Oct 29, 2009 at 6:39 AM, David Holmes wrote: >> Hi Tony, >> >>> I am working on a project where I need to identify the relations >>> between parent threads and children threads. Especially, I want to do >>> it inside the JVM, not in a java program. >> As others have said you need to do this yourself by monitoring thread >> construction and/or starting. >> >> In Java there is no parent/child relationship between threads - all threads >> are considered equal siblings. This is in contrast to other systems where >> "child" threads are an explicit notion where exceptions in a child can be >> caught in a parent; where joining a parent joins all children etc. But >> that's not Java. >> >> Cheers, >> David Holmes >> >>> Looking at the code of hotspot, I can only find the thread list inside >>> the Thread class, but it's not enough for my purpose. >>> >>> Is there some way that I can draw out a family tree of the threads >>> within the hotspot? I know that from within a java program, we can >>> draw a tree of all the ThreadGroups, but it again is not what I want. >>> >>> Or could you tell me how I could identify when a thread is created, >>> and who is the parental thread that creates it? >>> >>> Thanks a lot! >>> >>> Tony Guan From guanxiaohua at gmail.com Thu Oct 29 19:26:42 2009 From: guanxiaohua at gmail.com (Tony Guan) Date: Thu, 29 Oct 2009 21:26:42 -0500 Subject: How to get the family tree of all the threads? In-Reply-To: <4AEA4755.4010400@sun.com> References: <2fcb552b0910282054l7b7ba568md3b20101fea240b6@mail.gmail.com> <4AE97EDA.5030206@sun.com> <2fcb552b0910291315w70127f7bm70e72d0a4e7f2ee6@mail.gmail.com> <4AEA4755.4010400@sun.com> Message-ID: <2fcb552b0910291926n5c18feaflf539329931d87aa0@mail.gmail.com> Hi David, Absolutely, I have noticed that in the experiment. Thank you very much! Tony On Thu, Oct 29, 2009 at 8:54 PM, David Holmes wrote: > Tony, > > Just a note that there will be two cases where there is no currentThread: > > a) when the main thread is created > b) when the main thread detaches (after executing main) and reattaches as > the DestroyJavaVM thread. > > but this shouldn't affect your parent check in run() > > David > > Tony Guan wrote: >> >> Hi David & ?Alan & Christian, >> >> Thank you all for the prompt reply! I am currently using such an >> approach as the following, could you please take a look to see if >> something might be wrong? >> >> 1) added a Thread* field for the JavaThread: >> ?Thread* ?_parent; //to memorize the thread which creates this thread. >> 2) get the current thread running when a new JavaThread is created, >> this current thread should be the parent of the to-be created thread, >> in JavaThread::JavaThread(ThreadFunction entry_point, size_t stack_sz) >> : >> ? ?_parent=Thread::current(); //tony: we added it for convenience. >> 3)verify the _parent field in the run() method of the newly created >> thread, by this time, the current thread should be the child thread >> created. >> ? int ostid_parent=_parent->osthread()->thread_id(); >> >> Then if the child thread is ever running, I can get its parent thread. >> >> Thanks a lot! >> >> Tony >> >> On Thu, Oct 29, 2009 at 6:39 AM, David Holmes >> wrote: >>> >>> Hi Tony, >>> >>>> I am working on a project where I need to identify the relations >>>> between parent threads and children threads. Especially, I want to do >>>> it inside the JVM, not in a java program. >>> >>> As others have said you need to do this yourself by monitoring thread >>> construction and/or starting. >>> >>> In Java there is no parent/child relationship between threads - all >>> threads >>> are considered equal siblings. This is in contrast to other systems where >>> "child" threads are an explicit notion where exceptions in a child can be >>> caught in a parent; where joining a parent joins all children etc. But >>> that's not Java. >>> >>> Cheers, >>> David Holmes >>> >>>> Looking at the code of hotspot, I can only find the thread list inside >>>> the Thread class, but it's not enough for my purpose. >>>> >>>> Is there some way that I can draw out a family tree of the threads >>>> within the hotspot? I know that from within a java program, we can >>>> draw a tree of all the ThreadGroups, but it again is not what I want. >>>> >>>> Or could you tell me how I could identify when a thread is created, >>>> and who is the parental thread that creates it? >>>> >>>> Thanks a lot! >>>> >>>> Tony Guan > From doko at ubuntu.com Fri Oct 30 04:05:06 2009 From: doko at ubuntu.com (Matthias Klose) Date: Fri, 30 Oct 2009 12:05:06 +0100 Subject: [patch] add missing include in nativeInst_.cpp Message-ID: <4AEAC862.6050504@ubuntu.com> unsure if this is related to zero/shark, but at least that's in the upstream sources for OpenJDK6. These include failures are usually seen, when not using precompiled headers (which is a useful thing to track down compiler bugs). attached are two patches to fix the include problem, and one to disable the use of precompiled headers setting an envvar. This way release builds could be built with and without precompiled headers. Matthias -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea-no-precompiled.patch Type: text/x-diff Size: 1473 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20091030/303227e6/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: hotspot-include-fixes.patch Type: text/x-diff Size: 565 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20091030/303227e6/attachment-0001.bin From Christian.Thalinger at Sun.COM Fri Oct 30 06:10:11 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 30 Oct 2009 14:10:11 +0100 Subject: typo in TemplateInterpreterGenerator::set_short_entry_points? Message-ID: <1256908211.4267.27.camel@macbook> I'm currently trying to find a bug somewhere in the interpreter (JSR 292 related) and I stumbled across this code: void TemplateInterpreterGenerator::set_short_entry_points(Template* t, address& bep, address& cep, address& sep, address& aep, address& iep, address& lep, address& fep, address& dep, address& vep) { assert(t->is_valid(), "template must exist"); switch (t->tos_in()) { case btos: vep = __ pc(); __ pop(btos); bep = __ pc(); generate_and_dispatch(t); break; case ctos: vep = __ pc(); __ pop(ctos); sep = __ pc(); generate_and_dispatch(t); break; case stos: vep = __ pc(); __ pop(stos); sep = __ pc(); generate_and_dispatch(t); break; case atos: vep = __ pc(); __ pop(atos); aep = __ pc(); generate_and_dispatch(t); break; case itos: vep = __ pc(); __ pop(itos); iep = __ pc(); generate_and_dispatch(t); break; case ltos: vep = __ pc(); __ pop(ltos); lep = __ pc(); generate_and_dispatch(t); break; case ftos: vep = __ pc(); __ pop(ftos); fep = __ pc(); generate_and_dispatch(t); break; case dtos: vep = __ pc(); __ pop(dtos); dep = __ pc(); generate_and_dispatch(t); break; case vtos: set_vtos_entry_points(t, bep, cep, sep, aep, iep, lep, fep, dep, vep); break; default : ShouldNotReachHere(); break; } } I'm not exactly sure but it looks a little odd that for ctos the cep does not get set properly but sep instead. This means that cep always stays _illegal_bytecode_sequence. Does ctos always use sep by definition? -- Christian From Thomas.Rodriguez at Sun.COM Fri Oct 30 14:06:10 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 30 Oct 2009 14:06:10 -0700 Subject: typo in TemplateInterpreterGenerator::set_short_entry_points? In-Reply-To: <1256908211.4267.27.camel@macbook> References: <1256908211.4267.27.camel@macbook> Message-ID: <32767A7B-277A-4D74-95D4-3016703CFE12@sun.com> set_entry_point is only ever used with the tos states of bytecode templates in templateTable.cpp and none of those use the subword tos states like btos,ctos and stos. Those are all smeared into itos: def(Bytecodes::_i2c , ____|____|____|____, itos, itos, convert , _ ) The subword types don't really exist in the representation of the stack and locals. Probably btos,ctos and stos could be converted into ShouldNotReachHere in the switch below. tom On Oct 30, 2009, at 6:10 AM, Christian Thalinger wrote: > I'm currently trying to find a bug somewhere in the interpreter (JSR > 292 > related) and I stumbled across this code: > > void TemplateInterpreterGenerator::set_short_entry_points(Template* > t, address& bep, address& cep, address& sep, address& aep, address& > iep, address& lep, address& fep, address& dep, address& vep) { > assert(t->is_valid(), "template must exist"); > switch (t->tos_in()) { > case btos: vep = __ pc(); __ pop(btos); bep = __ pc(); > generate_and_dispatch(t); break; > case ctos: vep = __ pc(); __ pop(ctos); sep = __ pc(); > generate_and_dispatch(t); break; > case stos: vep = __ pc(); __ pop(stos); sep = __ pc(); > generate_and_dispatch(t); break; > case atos: vep = __ pc(); __ pop(atos); aep = __ pc(); > generate_and_dispatch(t); break; > case itos: vep = __ pc(); __ pop(itos); iep = __ pc(); > generate_and_dispatch(t); break; > case ltos: vep = __ pc(); __ pop(ltos); lep = __ pc(); > generate_and_dispatch(t); break; > case ftos: vep = __ pc(); __ pop(ftos); fep = __ pc(); > generate_and_dispatch(t); break; > case dtos: vep = __ pc(); __ pop(dtos); dep = __ pc(); > generate_and_dispatch(t); break; > case vtos: set_vtos_entry_points(t, bep, cep, sep, aep, iep, lep, > fep, dep, vep); break; > default : ShouldNotReachHere > (); break; > } > } > > I'm not exactly sure but it looks a little odd that for ctos the cep > does not get set properly but sep instead. This means that cep always > stays _illegal_bytecode_sequence. Does ctos always use sep by > definition? > > -- Christian > From antonios.printezis at sun.com Fri Oct 30 16:43:20 2009 From: antonios.printezis at sun.com (antonios.printezis at sun.com) Date: Fri, 30 Oct 2009 23:43:20 +0000 Subject: hg: jdk7/hotspot/hotspot: 6 new changesets Message-ID: <20091030234332.7620041975@hg.openjdk.java.net> Changeset: fc06cd9b42c7 Author: tonyp Date: 2009-10-23 14:34 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fc06cd9b42c7 6886024: G1: assert(recent_avg_pause_time_ratio() < 1.00,"All GC?") Summary: the assert is incorrect and can fire incorrectly due to floating point inaccuracy. Reviewed-by: apetrusenko, ysr, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: 6270f80a7331 Author: tonyp Date: 2009-09-30 14:50 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6270f80a7331 6890137: G1: revamp reachable object dump Summary: Revamp the reachable object dump debugging facility. Reviewed-by: jmasa, apetrusenko ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: fa2f65ebeb08 Author: apetrusenko Date: 2009-10-27 02:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fa2f65ebeb08 6870843: G1: G1 GC memory leak Summary: The fix addresses two memory leaks in G1 code: (1) _evac_failure_scan_stack - a resource object allocated on the C heap was not freed; (2) RSHashTable were linked into deleted list which was only cleared at full GC. Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp Changeset: 72a6752ac432 Author: ysr Date: 2009-10-28 11:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/72a6752ac432 6818264: Heap dumper unexpectedly adds .hprof suffix Summary: Restore old behaviour wrt HeapDumpPath; first dump goes to , th dump goes to ., with default value of the same as before. Reviewed-by: alanb, jcoomes, tonyp ! src/share/vm/services/heapDumper.cpp Changeset: beb8f45ee9f0 Author: johnc Date: 2009-10-29 09:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/beb8f45ee9f0 6889740: G1: OpenDS fails with "unhandled exception in compiled code" Summary: Incorrect code was being generated for the store operation in the null case of the aastore bytecode template. The bad code was generated by the store_heap_oop routine which takes a Register as its second argument. Passing NULL_WORD (0) as the second argument causes the value to be converted to Register(0), which is rax. Thus the generated store was "mov (dst), $rax" instead of "mov (dst), $0x0". Changed calls to store_heap_oop that pass NULL_WORD as the second argument to a new routine store_heap_oop_null. Reviewed-by: kvn, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/templateTable_x86_64.cpp Changeset: 29adffcb6a61 Author: tonyp Date: 2009-10-30 13:31 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/29adffcb6a61 Merge From y.s.ramakrishna at sun.com Fri Oct 30 17:18:06 2009 From: y.s.ramakrishna at sun.com (y.s.ramakrishna at sun.com) Date: Sat, 31 Oct 2009 00:18:06 +0000 Subject: hg: hsx/hsx16/baseline: 6818264: Heap dumper unexpectedly adds .hprof suffix Message-ID: <20091031001809.810724197F@hg.openjdk.java.net> Changeset: b0651468aff7 Author: ysr Date: 2009-10-28 11:16 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/b0651468aff7 6818264: Heap dumper unexpectedly adds .hprof suffix Summary: Restore old behaviour wrt HeapDumpPath; first dump goes to , th dump goes to ., with default value of the same as before. Reviewed-by: alanb, jcoomes, tonyp ! src/share/vm/services/heapDumper.cpp