From Antonios.Printezis at sun.com Mon Feb 2 07:34:25 2009 From: Antonios.Printezis at sun.com (Tony Printezis) Date: Mon, 02 Feb 2009 10:34:25 -0500 Subject: question regarding the java.lang.String design In-Reply-To: <4983EBF5.2070507@sun.com> References: <49834802.9070509@Sun.COM> <498348B3.4000302@Sun.COM> <49834A15.8080102@Sun.COM> <4983EBF5.2070507@sun.com> Message-ID: <49871281.6090509@sun.com> David Holmes - Sun Microsystems wrote: > Hi Xiaobin, > > As you've probably gleaned by now the count and offset fields are to > allow sharing of the underlying char[] - which is a safe thing to do > exactly because a string is immutable. I've often thought this > particular optimization was under-utilized. > > As others have said optimization of strings has been a recurring theme > for many years now - there was even a paper on it at last year's ACM > OOPSLA conference. IBM Research's Tokyo labs do a lot in this area - > see for example "RT0750 A Quantitative Analysis of Space Waste from > Java Strings and its Elimination at GC Time". FWIW, one of the optimizations they present in their paper is actually unsafe. If two strings (str1 and str2, say) are the same, a young collection might get rid of one (say str2) and replace it with the second one (all references that pointed to str2 now point to str1). So, two objects that have two distinct IDs (i.e., str1 == str2 would return false) might suddenly become the same object (i.e., str1 == str2 would now return true). I don't think this is allowed by the Java spec. Said string should have instead been modified to share the same char array, instead of having two different ones. Tony > I've occasionally thought that with all the duplicate strings that > readily occur in Java it might be an option to have a few large tables > of "text" containing all the characters, and then to define a String > as one or more pairs of indices into these tables. But that's as far > as I've thought about it :) > > Cheers, > David Holmes > > > Xiaobin Lu said the following on 01/31/09 04:42: >> Resend the email to hotspot-dev at openjdk.java.net. >> -Xiaobin >> >> Xiaobin Lu wrote: >>> Hi folks, >>> >>> While I am looking at the java.lang.String implementation, I noticed >>> that it has "offset" and "count" field in java.lang.String. For the >>> offset field, I only found two places which set that field, but I >>> believe they can be got rid of too. The two places are >>> String(StringBuffer buffer) & String(StringBuilder builder). >>> >>> My question is that if String is immutable, why do we need to carry >>> these two fields? String could be more compacted without these two >>> fields. The equals to method can be more efficiently implemented as >>> just calling java.util.Array.equals(v1, v2) which is intrinsified on >>> x86 at least. >>> >>> Another crazy thought is that we can compact the character array to >>> a byte array if we don't have any characters other than ASCII (which >>> we might use a boolean flag to indicate that). >>> >>> I'd appreciate your insight on this. >>> >>> -Xiaobin >>> >>> >>> >> -- --------------------------------------------------------------------- | 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 groundskeeperwiley at yahoo.com Mon Feb 2 09:27:56 2009 From: groundskeeperwiley at yahoo.com (James Walsh) Date: Mon, 2 Feb 2009 09:27:56 -0800 (PST) Subject: Superword - Aligning arrays References: <90121.96359.qm@web30002.mail.mud.yahoo.com> Message-ID: <15917.77377.qm@web30004.mail.mud.yahoo.com> I have the arrays aligned now and the SIMD ops run properly until I hit garbage collection. I have a couple questions about that. Where do I need to look to make sure the array payloads are aligned after collection? Also I think when garbage collction starts it checks to see that the array objects are aligned on 8byte boundaries. On the 32bit machine I'm working on the float array headers are 12bytes so those array objects are not going to be object aligned on 8bytes. Should I eliminate object alignment checks for arrays? Or is there a better way of getting around that problem? From John.Rose at Sun.COM Mon Feb 2 15:01:46 2009 From: John.Rose at Sun.COM (John Rose) Date: Mon, 02 Feb 2009 15:01:46 -0800 Subject: Superword - Aligning arrays In-Reply-To: <15917.77377.qm@web30004.mail.mud.yahoo.com> References: <90121.96359.qm@web30002.mail.mud.yahoo.com> <15917.77377.qm@web30004.mail.mud.yahoo.com> Message-ID: <3047CC55-F9D2-460E-AA14-D99290C9BB0E@Sun.COM> On Feb 2, 2009, at 9:27 AM, James Walsh wrote: > I have the arrays aligned now and the SIMD ops run properly until I > hit garbage collection. I have a couple questions about that. > Where do I need to look to make sure the array payloads are aligned > after collection? Look at the GC code which reallocates the arrays. It will have to insert dummy objects in order to make up the necessary alignment for the new (relocated) copy of the big array. > Also I think when garbage collction starts it checks to see that the > array objects are aligned on 8byte boundaries. On the 32bit machine > I'm working on the float array headers are 12bytes so those array > objects are not going to be object aligned on 8bytes. Should I > eliminate object alignment checks for arrays? Probably not, since somebody is likely to use the low 3 bits of pointers for tagging. > Or is there a better way of getting around that problem? Note that arrays of longs and doubles have an internal word (after the length field) to make up the base alignment. In the interest of compactness, other arrays do not have the padding word. As I see it, your choices are: 1. add the padding word to other arrays also (risking more fragmentation overhead even for small arrays) 2. confine your SIMD work to long and double arrays 3. arrange the loop logic for non-long/double arrays to deal with the odd leading word Last tine I touched the C2 arraycopy intrinsic, I took option 3 and it wasn't that bad. If you are going to vectorize loops, you have to deal with leading and trailing ("fore-n-aft") partial vectors, in any case. Constraining the alignment removes a different degree of freedom, and it makes the leading case easier, at any rate. So I'd recommend 3, or 2, or 1, in that order. Does that make sense? -- John From Christian.Thalinger at Sun.COM Tue Feb 3 08:02:11 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 03 Feb 2009 17:02:11 +0100 Subject: Request for review (XXS): 6799452: HotSpot tests Makefile should take care of ALT_SLASH_JAVA Message-ID: <1233676931.3982.91.camel@localhost.localdomain> http://webrev.invokedynamic.info/twisti/6799452/ From Christian.Thalinger at Sun.COM Tue Feb 3 08:59:06 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 03 Feb 2009 17:59:06 +0100 Subject: Request for review (XXS): 6799452: HotSpot tests Makefile should take care of ALT_SLASH_JAVA In-Reply-To: <1233676931.3982.91.camel@localhost.localdomain> References: <1233676931.3982.91.camel@localhost.localdomain> Message-ID: <1233680346.3982.120.camel@localhost.localdomain> On Tue, 2009-02-03 at 17:02 +0100, Christian Thalinger wrote: > http://webrev.invokedynamic.info/twisti/6799452/ Oops! I submitted it to the hotspot-comp-gate. Is that a problem? -- Christian From Paul.Hohensee at Sun.COM Tue Feb 3 09:02:18 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Tue, 03 Feb 2009 12:02:18 -0500 Subject: Request for review (XXS): 6799452: HotSpot tests Makefile should take care of ALT_SLASH_JAVA In-Reply-To: <1233680346.3982.120.camel@localhost.localdomain> References: <1233676931.3982.91.camel@localhost.localdomain> <1233680346.3982.120.camel@localhost.localdomain> Message-ID: <4988789A.10806@sun.com> It doesn't matter which group repository you use for a generic fix like this one. Paul Christian Thalinger wrote: > On Tue, 2009-02-03 at 17:02 +0100, Christian Thalinger wrote: > >> http://webrev.invokedynamic.info/twisti/6799452/ >> > > Oops! I submitted it to the hotspot-comp-gate. Is that a problem? > > -- Christian > > From Christian.Thalinger at Sun.COM Tue Feb 3 10:44:04 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 03 Feb 2009 19:44:04 +0100 Subject: Request for review (XXS): 6799452: HotSpot tests Makefile should take care of ALT_SLASH_JAVA In-Reply-To: <4988789A.10806@sun.com> References: <1233676931.3982.91.camel@localhost.localdomain> <1233680346.3982.120.camel@localhost.localdomain> <4988789A.10806@sun.com> Message-ID: <1233686644.3982.222.camel@localhost.localdomain> On Tue, 2009-02-03 at 12:02 -0500, Paul Hohensee wrote: > It doesn't matter which group repository you use for a generic fix like > this one. Okay, thank you. -- Christian From groundskeeperwiley at yahoo.com Tue Feb 3 11:19:38 2009 From: groundskeeperwiley at yahoo.com (James Walsh) Date: Tue, 3 Feb 2009 11:19:38 -0800 (PST) Subject: Superword - Aligning arrays References: <90121.96359.qm@web30002.mail.mud.yahoo.com> <15917.77377.qm@web30004.mail.mud.yahoo.com> <3047CC55-F9D2-460E-AA14-D99290C9BB0E@Sun.COM> Message-ID: <105522.89208.qm@web30004.mail.mud.yahoo.com> I must not be looking in the right files for the array reallocation code. Can you dumb it down and give me a file name and line number? I'm guessing that option 1 is a no go since it will explode memory usage with dead space and only doing SIMD on longs/doubles isn't going to work for me so I guess I'm going to give option 3 a try. Is the C2 arraycopy intrinsic you refer to LibraryCallKit::inline_arraycopy()? ----- Original Message ---- From: John Rose To: James Walsh Cc: hotspot-dev at openjdk.java.net Sent: Tuesday, February 3, 2009 5:01:46 PM Subject: Re: Superword - Aligning arrays On Feb 2, 2009, at 9:27 AM, James Walsh wrote: > I have the arrays aligned now and the SIMD ops run properly until I hit garbage collection. I have a couple questions about that. Where do I need to look to make sure the array payloads are aligned after collection? Look at the GC code which reallocates the arrays. It will have to insert dummy objects in order to make up the necessary alignment for the new (relocated) copy of the big array. > Also I think when garbage collction starts it checks to see that the array objects are aligned on 8byte boundaries. On the 32bit machine I'm working on the float array headers are 12bytes so those array objects are not going to be object aligned on 8bytes. Should I eliminate object alignment checks for arrays? Probably not, since somebody is likely to use the low 3 bits of pointers for tagging. > Or is there a better way of getting around that problem? Note that arrays of longs and doubles have an internal word (after the length field) to make up the base alignment. In the interest of compactness, other arrays do not have the padding word. As I see it, your choices are: 1. add the padding word to other arrays also (risking more fragmentation overhead even for small arrays) 2. confine your SIMD work to long and double arrays 3. arrange the loop logic for non-long/double arrays to deal with the odd leading word Last tine I touched the C2 arraycopy intrinsic, I took option 3 and it wasn't that bad. If you are going to vectorize loops, you have to deal with leading and trailing ("fore-n-aft") partial vectors, in any case. Constraining the alignment removes a different degree of freedom, and it makes the leading case easier, at any rate. So I'd recommend 3, or 2, or 1, in that order. Does that make sense? -- John From gnu_andrew at member.fsf.org Tue Feb 3 12:30:03 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 3 Feb 2009 20:30:03 +0000 Subject: Fix warnings occurring with gcc 4.3 Message-ID: <17c6771e0902031230h64de81a3o71fa5d332c046988@mail.gmail.com> A number of warnings are thrown when compiling the HotSpot code with gcc 4.3, all of which are related to the incorrect use of printf format specifiers. As HotSpot is built with -Werror, these cause the build to fail. The attached patch against OpenJDK7 fixes them. -- Andrew :-) IcedTea/OpenJDK 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea-format.patch Type: application/octet-stream Size: 2636 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090203/4897b885/attachment.obj From Xiaobin.Lu at Sun.COM Tue Feb 3 13:54:43 2009 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Tue, 03 Feb 2009 13:54:43 -0800 Subject: Fix warnings occurring with gcc 4.3 In-Reply-To: <17c6771e0902031230h64de81a3o71fa5d332c046988@mail.gmail.com> References: <17c6771e0902031230h64de81a3o71fa5d332c046988@mail.gmail.com> Message-ID: <4988BD23.2000303@Sun.COM> Did you check out the latest code? Those you pointed out have been already fixed. -Xiaobin On 02/03/09 12:30, Andrew John Hughes wrote: > A number of warnings are thrown when compiling the HotSpot code with > gcc 4.3, all of which are related to the incorrect use of printf > format specifiers. As HotSpot is built with -Werror, these cause the > build to fail. The attached patch against OpenJDK7 fixes them. > From gnu_andrew at member.fsf.org Tue Feb 3 14:24:38 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 3 Feb 2009 22:24:38 +0000 Subject: Fix warnings occurring with gcc 4.3 In-Reply-To: <4988BD23.2000303@Sun.COM> References: <17c6771e0902031230h64de81a3o71fa5d332c046988@mail.gmail.com> <4988BD23.2000303@Sun.COM> Message-ID: <17c6771e0902031424ga0ac7b4md15f99f4dcad1874@mail.gmail.com> 2009/2/3 Xiaobin Lu : > Did you check out the latest code? Those you pointed out have been already > fixed. > > -Xiaobin > > On 02/03/09 12:30, Andrew John Hughes wrote: >> >> A number of warnings are thrown when compiling the HotSpot code with >> gcc 4.3, all of which are related to the incorrect use of printf >> format specifiers. As HotSpot is built with -Werror, these cause the >> build to fail. The attached patch against OpenJDK7 fixes them. >> > > They are not fixed in b45. -- Andrew :-) IcedTea/OpenJDK 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 Xiaobin.Lu at Sun.COM Tue Feb 3 14:28:16 2009 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Tue, 03 Feb 2009 14:28:16 -0800 Subject: Fix warnings occurring with gcc 4.3 In-Reply-To: <17c6771e0902031424ga0ac7b4md15f99f4dcad1874@mail.gmail.com> References: <17c6771e0902031230h64de81a3o71fa5d332c046988@mail.gmail.com> <4988BD23.2000303@Sun.COM> <17c6771e0902031424ga0ac7b4md15f99f4dcad1874@mail.gmail.com> Message-ID: <4988C500.5070700@Sun.COM> On 02/03/09 14:24, Andrew John Hughes wrote: > 2009/2/3 Xiaobin Lu : > >> Did you check out the latest code? Those you pointed out have been already >> fixed. >> >> -Xiaobin >> >> On 02/03/09 12:30, Andrew John Hughes wrote: >> >>> A number of warnings are thrown when compiling the HotSpot code with >>> gcc 4.3, all of which are related to the incorrect use of printf >>> format specifiers. As HotSpot is built with -Werror, these cause the >>> build to fail. The attached patch against OpenJDK7 fixes them. >>> >>> >> > > They are not fixed in b45. > b45 is the latest promoted build. hg.openjdk.java.net/jdk7/hotspot should have those what you are trying to fix. Those will show up in the next promotion build. -Xiaobin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090203/8c815cdf/attachment.html From gnu_andrew at member.fsf.org Tue Feb 3 14:31:06 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 3 Feb 2009 22:31:06 +0000 Subject: Fix warnings occurring with gcc 4.3 In-Reply-To: <4988C500.5070700@Sun.COM> References: <17c6771e0902031230h64de81a3o71fa5d332c046988@mail.gmail.com> <4988BD23.2000303@Sun.COM> <17c6771e0902031424ga0ac7b4md15f99f4dcad1874@mail.gmail.com> <4988C500.5070700@Sun.COM> Message-ID: <17c6771e0902031431m70b87b23y72a7d773026018b3@mail.gmail.com> 2009/2/3 Xiaobin Lu : > On 02/03/09 14:24, Andrew John Hughes wrote: > > 2009/2/3 Xiaobin Lu : > > > Did you check out the latest code? Those you pointed out have been already > fixed. > > -Xiaobin > > On 02/03/09 12:30, Andrew John Hughes wrote: > > > A number of warnings are thrown when compiling the HotSpot code with > gcc 4.3, all of which are related to the incorrect use of printf > format specifiers. As HotSpot is built with -Werror, these cause the > build to fail. The attached patch against OpenJDK7 fixes them. > > > > > > They are not fixed in b45. > > > b45 is the latest promoted build. hg.openjdk.java.net/jdk7/hotspot should > have those what you are trying to fix. Those will show up in the next > promotion build. > > -Xiaobin > > Good. We obviously don't build directly from the forest and it isn't clear that such changes are in that tree; the commit list just shows the branch being tagged. -- Andrew :-) IcedTea/OpenJDK 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 Vladimir.Kozlov at Sun.COM Tue Feb 3 15:12:36 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 03 Feb 2009 15:12:36 -0800 Subject: Fix warnings occurring with gcc 4.3 In-Reply-To: <17c6771e0902031431m70b87b23y72a7d773026018b3@mail.gmail.com> References: <17c6771e0902031230h64de81a3o71fa5d332c046988@mail.gmail.com> <4988BD23.2000303@Sun.COM> <17c6771e0902031424ga0ac7b4md15f99f4dcad1874@mail.gmail.com> <4988C500.5070700@Sun.COM> <17c6771e0902031431m70b87b23y72a7d773026018b3@mail.gmail.com> Message-ID: <4988CF64.5010300@sun.com> 6778669. Still in Dispatched state. Vladimir Andrew John Hughes wrote: > 2009/2/3 Xiaobin Lu : >> On 02/03/09 14:24, Andrew John Hughes wrote: >> >> 2009/2/3 Xiaobin Lu : >> >> >> Did you check out the latest code? Those you pointed out have been already >> fixed. >> >> -Xiaobin >> >> On 02/03/09 12:30, Andrew John Hughes wrote: >> >> >> A number of warnings are thrown when compiling the HotSpot code with >> gcc 4.3, all of which are related to the incorrect use of printf >> format specifiers. As HotSpot is built with -Werror, these cause the >> build to fail. The attached patch against OpenJDK7 fixes them. >> >> >> >> >> >> They are not fixed in b45. >> >> >> b45 is the latest promoted build. hg.openjdk.java.net/jdk7/hotspot should >> have those what you are trying to fix. Those will show up in the next >> promotion build. >> >> -Xiaobin >> >> > > Good. We obviously don't build directly from the forest and it isn't > clear that such changes are in that tree; the commit list just shows > the branch being tagged. From John.Rose at Sun.COM Tue Feb 3 15:47:37 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 03 Feb 2009 15:47:37 -0800 Subject: Superword - Aligning arrays In-Reply-To: <105522.89208.qm@web30004.mail.mud.yahoo.com> References: <90121.96359.qm@web30002.mail.mud.yahoo.com> <15917.77377.qm@web30004.mail.mud.yahoo.com> <3047CC55-F9D2-460E-AA14-D99290C9BB0E@Sun.COM> <105522.89208.qm@web30004.mail.mud.yahoo.com> Message-ID: <0026A698-DC8F-44BC-97C4-77F2419F9330@Sun.COM> On Feb 3, 2009, at 11:19 AM, James Walsh wrote: > I must not be looking in the right files for the array reallocation > code. Can you dumb it down and give me a file name and line number? Look in space.hpp at Space::allocate and par_allocate. Those virtuals are both defined and called in very many places. At a minimum, each implementation would have to insert the alignment correction before affected objects. You know, it would probably simplify matters (deep down in the GC) to strongly align *all* objects bigger than a certain threshold, not just arrays. Then your alignment logic would simply compare the requested size against the threshold, rather than ask potentially expensive questions about exactly which kind of object were being allocated. Or (thinking out loud) the alignment request could be passed in as an additional boolean argument to [par_]allocate. > I'm guessing that option 1 is a no go since it will explode memory > usage with dead space and only doing SIMD on longs/doubles isn't > going to work for me so I guess I'm going to give option 3 a try. > Is the C2 arraycopy intrinsic you refer to > LibraryCallKit::inline_arraycopy()? Yes. Look for this comment in generate_block_arraycopy: // One more chance: Pick off an initial 32-bit word. There's similar logic in ClearArrayNode::clear_memory, too. You're making progress, I think, but it's not an easy problem. Good luck! -- John From Xiaobin.Lu at Sun.COM Tue Feb 3 15:56:43 2009 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Tue, 03 Feb 2009 15:56:43 -0800 Subject: Fix warnings occurring with gcc 4.3 In-Reply-To: <4988CF64.5010300@sun.com> References: <17c6771e0902031230h64de81a3o71fa5d332c046988@mail.gmail.com> <4988BD23.2000303@Sun.COM> <17c6771e0902031424ga0ac7b4md15f99f4dcad1874@mail.gmail.com> <4988C500.5070700@Sun.COM> <17c6771e0902031431m70b87b23y72a7d773026018b3@mail.gmail.com> <4988CF64.5010300@sun.com> Message-ID: <4988D9BB.4080307@Sun.COM> On 02/03/09 15:12, Vladimir Kozlov wrote: > 6778669. Still in Dispatched state. The problem mentioned in Andrew's patch has actually been fixed recently by Coleen and me. I don't have Redhat machine around, but I can build hotspot successfully with latest fedora 10 release. -Xiaobin > > Vladimir > > Andrew John Hughes wrote: >> 2009/2/3 Xiaobin Lu : >>> On 02/03/09 14:24, Andrew John Hughes wrote: >>> >>> 2009/2/3 Xiaobin Lu : >>> >>> >>> Did you check out the latest code? Those you pointed out have been >>> already >>> fixed. >>> >>> -Xiaobin >>> >>> On 02/03/09 12:30, Andrew John Hughes wrote: >>> >>> >>> A number of warnings are thrown when compiling the HotSpot code with >>> gcc 4.3, all of which are related to the incorrect use of printf >>> format specifiers. As HotSpot is built with -Werror, these cause the >>> build to fail. The attached patch against OpenJDK7 fixes them. >>> >>> >>> >>> >>> >>> They are not fixed in b45. >>> >>> >>> b45 is the latest promoted build. hg.openjdk.java.net/jdk7/hotspot >>> should >>> have those what you are trying to fix. Those will show up in the next >>> promotion build. >>> >>> -Xiaobin >>> >>> >> >> Good. We obviously don't build directly from the forest and it isn't >> clear that such changes are in that tree; the commit list just shows >> the branch being tagged. From David.Holmes at Sun.COM Tue Feb 3 16:41:23 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Wed, 04 Feb 2009 10:41:23 +1000 Subject: Fix warnings occurring with gcc 4.3 In-Reply-To: <4988D9BB.4080307@Sun.COM> References: <17c6771e0902031230h64de81a3o71fa5d332c046988@mail.gmail.com> <4988BD23.2000303@Sun.COM> <17c6771e0902031424ga0ac7b4md15f99f4dcad1874@mail.gmail.com> <4988C500.5070700@Sun.COM> <17c6771e0902031431m70b87b23y72a7d773026018b3@mail.gmail.com> <4988CF64.5010300@sun.com> <4988D9BB.4080307@Sun.COM> Message-ID: <4988E433.3050809@sun.com> Hi Xiaobin, I'm a bit confused about VMError because internally _lineno is now (not sure when it changed) defined as size_t but all the constructors that take a lineno argument take an int ?? So why bother with size_t? But if it is meant to be size_t then you also need to fix this at line 200: jio_snprintf(buf, buflen, "Internal Error at %s:%d, pid=%d, tid=" UINTX_FORMAT " \nError: %s", p ? p + 1 : _filename, _lineno, os::current_process_id(), os::current_thread_id(), _message ? _message : ""); Cheers, David Holmes Xiaobin Lu said the following on 02/04/09 09:56: > On 02/03/09 15:12, Vladimir Kozlov wrote: >> 6778669. Still in Dispatched state. > The problem mentioned in Andrew's patch has actually been fixed recently > by Coleen and me. I don't have Redhat machine around, but I can build > hotspot successfully with latest fedora 10 release. > > -Xiaobin >> >> Vladimir >> >> Andrew John Hughes wrote: >>> 2009/2/3 Xiaobin Lu : >>>> On 02/03/09 14:24, Andrew John Hughes wrote: >>>> >>>> 2009/2/3 Xiaobin Lu : >>>> >>>> >>>> Did you check out the latest code? Those you pointed out have been >>>> already >>>> fixed. >>>> >>>> -Xiaobin >>>> >>>> On 02/03/09 12:30, Andrew John Hughes wrote: >>>> >>>> >>>> A number of warnings are thrown when compiling the HotSpot code with >>>> gcc 4.3, all of which are related to the incorrect use of printf >>>> format specifiers. As HotSpot is built with -Werror, these cause the >>>> build to fail. The attached patch against OpenJDK7 fixes them. >>>> >>>> >>>> >>>> >>>> >>>> They are not fixed in b45. >>>> >>>> >>>> b45 is the latest promoted build. hg.openjdk.java.net/jdk7/hotspot >>>> should >>>> have those what you are trying to fix. Those will show up in the next >>>> promotion build. >>>> >>>> -Xiaobin >>>> >>>> >>> >>> Good. We obviously don't build directly from the forest and it isn't >>> clear that such changes are in that tree; the commit list just shows >>> the branch being tagged. > From Xiaobin.Lu at Sun.COM Tue Feb 3 17:20:54 2009 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Tue, 03 Feb 2009 17:20:54 -0800 Subject: Fix warnings occurring with gcc 4.3 In-Reply-To: <4988E433.3050809@sun.com> References: <17c6771e0902031230h64de81a3o71fa5d332c046988@mail.gmail.com> <4988BD23.2000303@Sun.COM> <17c6771e0902031424ga0ac7b4md15f99f4dcad1874@mail.gmail.com> <4988C500.5070700@Sun.COM> <17c6771e0902031431m70b87b23y72a7d773026018b3@mail.gmail.com> <4988CF64.5010300@sun.com> <4988D9BB.4080307@Sun.COM> <4988E433.3050809@sun.com> Message-ID: <4988ED76.3020202@Sun.COM> On 02/03/09 16:41, David Holmes - Sun Microsystems wrote: > Hi Xiaobin, > > I'm a bit confused about VMError because internally _lineno is now > (not sure when it changed) defined as size_t but all the constructors > that take a lineno argument take an int ?? So why bother with size_t? > > But if it is meant to be size_t then you also need to fix this at line > 200: > > jio_snprintf(buf, buflen, > "Internal Error at %s:%d, pid=%d, tid=" UINTX_FORMAT " > \nError: %s", > p ? p + 1 : _filename, _lineno, > os::current_process_id(), os::current_thread_id(), > _message ? _message : ""); I think the right way to fix this is to define _lineno as "int" and fix line 309 of vmError.cpp to use "%d" for _lineno instead of "SIZE_FORMAT" (which is why I thought to use size_t for _lineno). It is strange I didn't get error message for the above statement on 64 bit Linux. -Xiaobin > > Cheers, > David Holmes > > Xiaobin Lu said the following on 02/04/09 09:56: >> On 02/03/09 15:12, Vladimir Kozlov wrote: >>> 6778669. Still in Dispatched state. >> The problem mentioned in Andrew's patch has actually been fixed >> recently by Coleen and me. I don't have Redhat machine around, but I >> can build hotspot successfully with latest fedora 10 release. >> >> -Xiaobin >>> >>> Vladimir >>> >>> Andrew John Hughes wrote: >>>> 2009/2/3 Xiaobin Lu : >>>>> On 02/03/09 14:24, Andrew John Hughes wrote: >>>>> >>>>> 2009/2/3 Xiaobin Lu : >>>>> >>>>> >>>>> Did you check out the latest code? Those you pointed out have been >>>>> already >>>>> fixed. >>>>> >>>>> -Xiaobin >>>>> >>>>> On 02/03/09 12:30, Andrew John Hughes wrote: >>>>> >>>>> >>>>> A number of warnings are thrown when compiling the HotSpot code with >>>>> gcc 4.3, all of which are related to the incorrect use of printf >>>>> format specifiers. As HotSpot is built with -Werror, these cause the >>>>> build to fail. The attached patch against OpenJDK7 fixes them. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> They are not fixed in b45. >>>>> >>>>> >>>>> b45 is the latest promoted build. hg.openjdk.java.net/jdk7/hotspot >>>>> should >>>>> have those what you are trying to fix. Those will show up in the next >>>>> promotion build. >>>>> >>>>> -Xiaobin >>>>> >>>>> >>>> >>>> Good. We obviously don't build directly from the forest and it isn't >>>> clear that such changes are in that tree; the commit list just shows >>>> the branch being tagged. >> From David.Holmes at Sun.COM Tue Feb 3 17:45:23 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Wed, 04 Feb 2009 11:45:23 +1000 Subject: Fix warnings occurring with gcc 4.3 In-Reply-To: <4988ED76.3020202@Sun.COM> References: <17c6771e0902031230h64de81a3o71fa5d332c046988@mail.gmail.com> <4988BD23.2000303@Sun.COM> <17c6771e0902031424ga0ac7b4md15f99f4dcad1874@mail.gmail.com> <4988C500.5070700@Sun.COM> <17c6771e0902031431m70b87b23y72a7d773026018b3@mail.gmail.com> <4988CF64.5010300@sun.com> <4988D9BB.4080307@Sun.COM> <4988E433.3050809@sun.com> <4988ED76.3020202@Sun.COM> Message-ID: <4988F333.1010506@sun.com> Xiaobin Lu said the following on 02/04/09 11:20: > I think the right way to fix this is to define _lineno as "int" and fix > line 309 of vmError.cpp to use "%d" for _lineno instead of "SIZE_FORMAT" > (which is why I thought to use size_t for _lineno). I agree - revert to int and %d. > It is strange I > didn't get error message for the above statement on 64 bit Linux. I guess the compiler isn't that good at detecting problems with format specifiers. It also seems to have missed this at line 423: st->print(", free space=%dk", ((intptr_t)fr.sp() - (intptr_t)stack_bottom) >> 10); Cheers, David > -Xiaobin >> >> Cheers, >> David Holmes >> >> Xiaobin Lu said the following on 02/04/09 09:56: >>> On 02/03/09 15:12, Vladimir Kozlov wrote: >>>> 6778669. Still in Dispatched state. >>> The problem mentioned in Andrew's patch has actually been fixed >>> recently by Coleen and me. I don't have Redhat machine around, but I >>> can build hotspot successfully with latest fedora 10 release. >>> >>> -Xiaobin >>>> >>>> Vladimir >>>> >>>> Andrew John Hughes wrote: >>>>> 2009/2/3 Xiaobin Lu : >>>>>> On 02/03/09 14:24, Andrew John Hughes wrote: >>>>>> >>>>>> 2009/2/3 Xiaobin Lu : >>>>>> >>>>>> >>>>>> Did you check out the latest code? Those you pointed out have been >>>>>> already >>>>>> fixed. >>>>>> >>>>>> -Xiaobin >>>>>> >>>>>> On 02/03/09 12:30, Andrew John Hughes wrote: >>>>>> >>>>>> >>>>>> A number of warnings are thrown when compiling the HotSpot code with >>>>>> gcc 4.3, all of which are related to the incorrect use of printf >>>>>> format specifiers. As HotSpot is built with -Werror, these cause the >>>>>> build to fail. The attached patch against OpenJDK7 fixes them. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> They are not fixed in b45. >>>>>> >>>>>> >>>>>> b45 is the latest promoted build. hg.openjdk.java.net/jdk7/hotspot >>>>>> should >>>>>> have those what you are trying to fix. Those will show up in the next >>>>>> promotion build. >>>>>> >>>>>> -Xiaobin >>>>>> >>>>>> >>>>> >>>>> Good. We obviously don't build directly from the forest and it isn't >>>>> clear that such changes are in that tree; the commit list just shows >>>>> the branch being tagged. >>> > From gnu_andrew at member.fsf.org Tue Feb 3 18:43:12 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 4 Feb 2009 02:43:12 +0000 Subject: Fix warnings occurring with gcc 4.3 In-Reply-To: <4988ED76.3020202@Sun.COM> References: <17c6771e0902031230h64de81a3o71fa5d332c046988@mail.gmail.com> <4988BD23.2000303@Sun.COM> <17c6771e0902031424ga0ac7b4md15f99f4dcad1874@mail.gmail.com> <4988C500.5070700@Sun.COM> <17c6771e0902031431m70b87b23y72a7d773026018b3@mail.gmail.com> <4988CF64.5010300@sun.com> <4988D9BB.4080307@Sun.COM> <4988E433.3050809@sun.com> <4988ED76.3020202@Sun.COM> Message-ID: <17c6771e0902031843r21c16413gaef0af172eb7becd@mail.gmail.com> 009/2/4 Xiaobin Lu : > On 02/03/09 16:41, David Holmes - Sun Microsystems wrote: >> >> Hi Xiaobin, >> >> I'm a bit confused about VMError because internally _lineno is now (not >> sure when it changed) defined as size_t but all the constructors that take a >> lineno argument take an int ?? So why bother with size_t? >> >> But if it is meant to be size_t then you also need to fix this at line >> 200: >> >> jio_snprintf(buf, buflen, >> "Internal Error at %s:%d, pid=%d, tid=" UINTX_FORMAT " \nError: >> %s", >> p ? p + 1 : _filename, _lineno, >> os::current_process_id(), os::current_thread_id(), >> _message ? _message : ""); > > I think the right way to fix this is to define _lineno as "int" and fix line > 309 of vmError.cpp to use "%d" for _lineno instead of "SIZE_FORMAT" (which > is why I thought to use size_t for _lineno). It is strange I didn't get > error message for the above statement on 64 bit Linux. > > -Xiaobin >> >> Cheers, >> David Holmes >> >> Xiaobin Lu said the following on 02/04/09 09:56: >>> >>> On 02/03/09 15:12, Vladimir Kozlov wrote: >>>> >>>> 6778669. Still in Dispatched state. >>> >>> The problem mentioned in Andrew's patch has actually been fixed recently >>> by Coleen and me. I don't have Redhat machine around, but I can build >>> hotspot successfully with latest fedora 10 release. >>> >>> -Xiaobin >>>> >>>> Vladimir >>>> >>>> Andrew John Hughes wrote: >>>>> >>>>> 2009/2/3 Xiaobin Lu : >>>>>> >>>>>> On 02/03/09 14:24, Andrew John Hughes wrote: >>>>>> >>>>>> 2009/2/3 Xiaobin Lu : >>>>>> >>>>>> >>>>>> Did you check out the latest code? Those you pointed out have been >>>>>> already >>>>>> fixed. >>>>>> >>>>>> -Xiaobin >>>>>> >>>>>> On 02/03/09 12:30, Andrew John Hughes wrote: >>>>>> >>>>>> >>>>>> A number of warnings are thrown when compiling the HotSpot code with >>>>>> gcc 4.3, all of which are related to the incorrect use of printf >>>>>> format specifiers. As HotSpot is built with -Werror, these cause the >>>>>> build to fail. The attached patch against OpenJDK7 fixes them. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> They are not fixed in b45. >>>>>> >>>>>> >>>>>> b45 is the latest promoted build. hg.openjdk.java.net/jdk7/hotspot >>>>>> should >>>>>> have those what you are trying to fix. Those will show up in the next >>>>>> promotion build. >>>>>> >>>>>> -Xiaobin >>>>>> >>>>>> >>>>> >>>>> Good. We obviously don't build directly from the forest and it isn't >>>>> clear that such changes are in that tree; the commit list just shows >>>>> the branch being tagged. >>> > > This is how I fixed it in the patch I sent earlier (switching back to '%d'), given _lineno is declared everywhere as int. It does fail on x86_64 with gcc 4.3.3 and -Werror. It looked to me like it might have been meant to be SIZE_FORMAT_W to specify an integer of a certain width, but with no idea what that width should be, I reverted it back to %d. -- Andrew :-) IcedTea/OpenJDK 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 gnu_andrew at member.fsf.org Tue Feb 3 18:43:45 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 4 Feb 2009 02:43:45 +0000 Subject: Fix warnings occurring with gcc 4.3 In-Reply-To: <4988D9BB.4080307@Sun.COM> References: <17c6771e0902031230h64de81a3o71fa5d332c046988@mail.gmail.com> <4988BD23.2000303@Sun.COM> <17c6771e0902031424ga0ac7b4md15f99f4dcad1874@mail.gmail.com> <4988C500.5070700@Sun.COM> <17c6771e0902031431m70b87b23y72a7d773026018b3@mail.gmail.com> <4988CF64.5010300@sun.com> <4988D9BB.4080307@Sun.COM> Message-ID: <17c6771e0902031843w1c4692c5ma933b7be6af988b8@mail.gmail.com> 2009/2/3 Xiaobin Lu : > On 02/03/09 15:12, Vladimir Kozlov wrote: >> >> 6778669. Still in Dispatched state. > > The problem mentioned in Andrew's patch has actually been fixed recently by > Coleen and me. I don't have Redhat machine around, but I can build hotspot > successfully with latest fedora 10 release. > > -Xiaobin >> >> Vladimir >> >> Andrew John Hughes wrote: >>> >>> 2009/2/3 Xiaobin Lu : >>>> >>>> On 02/03/09 14:24, Andrew John Hughes wrote: >>>> >>>> 2009/2/3 Xiaobin Lu : >>>> >>>> >>>> Did you check out the latest code? Those you pointed out have been >>>> already >>>> fixed. >>>> >>>> -Xiaobin >>>> >>>> On 02/03/09 12:30, Andrew John Hughes wrote: >>>> >>>> >>>> A number of warnings are thrown when compiling the HotSpot code with >>>> gcc 4.3, all of which are related to the incorrect use of printf >>>> format specifiers. As HotSpot is built with -Werror, these cause the >>>> build to fail. The attached patch against OpenJDK7 fixes them. >>>> >>>> >>>> >>>> >>>> >>>> They are not fixed in b45. >>>> >>>> >>>> b45 is the latest promoted build. hg.openjdk.java.net/jdk7/hotspot >>>> should >>>> have those what you are trying to fix. Those will show up in the next >>>> promotion build. >>>> >>>> -Xiaobin >>>> >>>> >>> >>> Good. We obviously don't build directly from the forest and it isn't >>> clear that such changes are in that tree; the commit list just shows >>> the branch being tagged. > > I didn't say anything about Fedora 10 or a 'Red Hat machine'. -- Andrew :-) IcedTea/OpenJDK 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 Feb 4 02:16:23 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 04 Feb 2009 11:16:23 +0100 Subject: Fix warnings occurring with gcc 4.3 In-Reply-To: <4988CF64.5010300@sun.com> References: <17c6771e0902031230h64de81a3o71fa5d332c046988@mail.gmail.com> <4988BD23.2000303@Sun.COM> <17c6771e0902031424ga0ac7b4md15f99f4dcad1874@mail.gmail.com> <4988C500.5070700@Sun.COM> <17c6771e0902031431m70b87b23y72a7d773026018b3@mail.gmail.com> <4988CF64.5010300@sun.com> Message-ID: <1233742583.3982.240.camel@localhost.localdomain> On Tue, 2009-02-03 at 15:12 -0800, Vladimir Kozlov wrote: > 6778669. Still in Dispatched state. I'm taking care of it. -- Christian From Christian.Thalinger at Sun.COM Wed Feb 4 02:35:21 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 04 Feb 2009 11:35:21 +0100 Subject: Fix warnings occurring with gcc 4.3 In-Reply-To: <17c6771e0902031431m70b87b23y72a7d773026018b3@mail.gmail.com> References: <17c6771e0902031230h64de81a3o71fa5d332c046988@mail.gmail.com> <4988BD23.2000303@Sun.COM> <17c6771e0902031424ga0ac7b4md15f99f4dcad1874@mail.gmail.com> <4988C500.5070700@Sun.COM> <17c6771e0902031431m70b87b23y72a7d773026018b3@mail.gmail.com> Message-ID: <1233743721.3982.249.camel@localhost.localdomain> On Tue, 2009-02-03 at 22:31 +0000, Andrew John Hughes wrote: > Good. We obviously don't build directly from the forest and it isn't > clear that such changes are in that tree; the commit list just shows > the branch being tagged. The bug Xiaobin is talking about is 6781583. The pushed changeset is: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2328d1d3f8cf and it has already been promoted to the hotspot forest. -- Christian From gnu_andrew at member.fsf.org Wed Feb 4 04:27:01 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 4 Feb 2009 12:27:01 +0000 Subject: Fix warnings occurring with gcc 4.3 In-Reply-To: <1233743721.3982.249.camel@localhost.localdomain> References: <17c6771e0902031230h64de81a3o71fa5d332c046988@mail.gmail.com> <4988BD23.2000303@Sun.COM> <17c6771e0902031424ga0ac7b4md15f99f4dcad1874@mail.gmail.com> <4988C500.5070700@Sun.COM> <17c6771e0902031431m70b87b23y72a7d773026018b3@mail.gmail.com> <1233743721.3982.249.camel@localhost.localdomain> Message-ID: <17c6771e0902040427k56255fafw583938aa5a87d0b6@mail.gmail.com> 2009/2/4 Christian Thalinger : > On Tue, 2009-02-03 at 22:31 +0000, Andrew John Hughes wrote: >> Good. We obviously don't build directly from the forest and it isn't >> clear that such changes are in that tree; the commit list just shows >> the branch being tagged. > > The bug Xiaobin is talking about is 6781583. The pushed changeset is: > > http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2328d1d3f8cf > > and it has already been promoted to the hotspot forest. > > -- Christian > > Thanks. That was very informative. If this is in b46, we'll be able to drop about three of our own patches. -- Andrew :-) IcedTea/OpenJDK 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 groundskeeperwiley at yahoo.com Wed Feb 4 09:40:58 2009 From: groundskeeperwiley at yahoo.com (James Walsh) Date: Wed, 4 Feb 2009 09:40:58 -0800 (PST) Subject: Superword - Aligning arrays References: <90121.96359.qm@web30002.mail.mud.yahoo.com> <15917.77377.qm@web30004.mail.mud.yahoo.com> <3047CC55-F9D2-460E-AA14-D99290C9BB0E@Sun.COM> <105522.89208.qm@web30004.mail.mud.yahoo.com> <0026A698-DC8F-44BC-97C4-77F2419F9330@Sun.COM> Message-ID: <873610.44048.qm@web30008.mail.mud.yahoo.com> Thanks again for the help. I probably wouldn't be to where I am now for another couple months without it. While looking through the GC code it appeared to me that the heap is traversed by grabbing a pointer and then indexing through based on the size of the oop headers. If that is the case then how would I deal with arrays that don't end up on the object alignment boundary? I assume that if I alter the length of the array it will show up in the java code if someone is indexing through an array until array.length. Do I need to change how the size of the oop is computed to take into account the possibility of a extra alignment word? ----- Original Message ---- From: John Rose To: James Walsh Cc: hotspot-dev at openjdk.java.net Sent: Wednesday, February 4, 2009 5:47:37 PM Subject: Re: Superword - Aligning arrays On Feb 3, 2009, at 11:19 AM, James Walsh wrote: > I must not be looking in the right files for the array reallocation code. Can you dumb it down and give me a file name and line number? Look in space.hpp at Space::allocate and par_allocate. Those virtuals are both defined and called in very many places. At a minimum, each implementation would have to insert the alignment correction before affected objects. You know, it would probably simplify matters (deep down in the GC) to strongly align *all* objects bigger than a certain threshold, not just arrays. Then your alignment logic would simply compare the requested size against the threshold, rather than ask potentially expensive questions about exactly which kind of object were being allocated. Or (thinking out loud) the alignment request could be passed in as an additional boolean argument to [par_]allocate. > I'm guessing that option 1 is a no go since it will explode memory usage with dead space and only doing SIMD on longs/doubles isn't going to work for me so I guess I'm going to give option 3 a try. Is the C2 arraycopy intrinsic you refer to LibraryCallKit::inline_arraycopy()? Yes. Look for this comment in generate_block_arraycopy: // One more chance: Pick off an initial 32-bit word. There's similar logic in ClearArrayNode::clear_memory, too. You're making progress, I think, but it's not an easy problem. Good luck! -- John From John.Rose at Sun.COM Wed Feb 4 15:42:33 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 04 Feb 2009 15:42:33 -0800 Subject: Superword - Aligning arrays In-Reply-To: <873610.44048.qm@web30008.mail.mud.yahoo.com> References: <90121.96359.qm@web30002.mail.mud.yahoo.com> <15917.77377.qm@web30004.mail.mud.yahoo.com> <3047CC55-F9D2-460E-AA14-D99290C9BB0E@Sun.COM> <105522.89208.qm@web30004.mail.mud.yahoo.com> <0026A698-DC8F-44BC-97C4-77F2419F9330@Sun.COM> <873610.44048.qm@web30008.mail.mud.yahoo.com> Message-ID: <89FDB0BB-DE27-4C60-850F-156A29C43D0D@Sun.COM> On Feb 4, 2009, at 9:40 AM, James Walsh wrote: > Thanks again for the help. I probably wouldn't be to where I am now > for another couple months without it. My pleasure! > While looking through the GC code it appeared to me that the heap is > traversed by grabbing a pointer and then indexing through based on > the size of the oop headers. If that is the case then how would I > deal with arrays that don't end up on the object alignment boundary? In general, the heap must always be "parseable" into objects in this way. (There are exceptions; the tail-end of a TLAB and certain other unused areas can contain complete garbage. Also, concurrent marking requires extra semi-parseable intermediate states. As the GC guys for more info; that's about all I know.) So, in this case, if a big object must be aligned strongly, you have to insert a little half-sized filler object before it, to "bump it up". The filler object must be a valid object (or at least parseable as a heap block). So when the heap is scanned, the scan comes first to the filler, reads the header, and skips up to the next object, which is the big, aligned array. Make sense? > I assume that if I alter the length of the array it will show up in > the java code if someone is indexing through an array until > array.length. Do I need to change how the size of the oop is > computed to take into account the possibility of a extra alignment > word? There's no need to change array.length here. (I suppose you could consider changing oopDesc::size_given_klass for big objects to add extra round-ups to the size. Beware: That routine (along with its variations) is performance-critical. See also uses of align_object_size and MinObjAlignmentInBytes. Wherever those guys appear, if a large object is a possibility, you would have to put a conditional to apply the correct alignment.) But that's probably more trouble than it's worth. If you insert the filler objects to bump up the alignment, you can let the tail of the big array be as unaligned as any other object, as long as you never perform vector writes that cross the ragged end of the array. That's simpler. Inserting padding objects is much less risky than changing the object sizing or heap-parsing logic. -- John From groundskeeperwiley at yahoo.com Wed Feb 4 20:47:02 2009 From: groundskeeperwiley at yahoo.com (James Walsh) Date: Wed, 4 Feb 2009 20:47:02 -0800 (PST) Subject: Superword - Aligning arrays References: <90121.96359.qm@web30002.mail.mud.yahoo.com> <15917.77377.qm@web30004.mail.mud.yahoo.com> <3047CC55-F9D2-460E-AA14-D99290C9BB0E@Sun.COM> <105522.89208.qm@web30004.mail.mud.yahoo.com> <0026A698-DC8F-44BC-97C4-77F2419F9330@Sun.COM> <873610.44048.qm@web30008.mail.mud.yahoo.com> <89FDB0BB-DE27-4C60-850F-156A29C43D0D@Sun.COM> Message-ID: <481420.74580.qm@web30008.mail.mud.yahoo.com> Let's say the heap is at 0x1000. I have a 5 float array that I want strongly aligned. I create a dummy 20 byte array leaving the heap at 0x1014. I create the 5 float array with a 12 byte header. The data in the array oop is aligned on the 16byte boundary for SIMD and the whole oop is a nice round 32 bytes which is MinObjAlignment aligned. Unfortunately the heap is now at 0x1034 which will assert on the next allocation. I can detect this at the allocation of the second array and add an extra alignment word which will realign the heap and everything runs fine until GC. When GC hits the dummy array gets oop::size() called on it and says it's actually an MinObjAlignment aligned 24-bytes. The iterator will then index 4-bytes too far, read a bunch of garbage instead of a header resulting in the jvm crashing. I think this is the state of my code right now. Is there a way around this without touching oop::size_given_klass? If I create a new heap parseable class I would still need some way of knowing that I should not honor the heap alignment for this oop. What if I set the length of the dummy array to the negative of it's actual length? That way in oop::size_given_klass I would know if I see a negative length that it is a alignment array that should ignore MinObjAlignment. For the strongly aligned array I could just check and see if the oop ends on 0x4 or 0xC and adjust the size up 4 bytes. From John.Rose at Sun.COM Wed Feb 4 21:40:45 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 04 Feb 2009 21:40:45 -0800 Subject: Superword - Aligning arrays In-Reply-To: <481420.74580.qm@web30008.mail.mud.yahoo.com> References: <90121.96359.qm@web30002.mail.mud.yahoo.com> <15917.77377.qm@web30004.mail.mud.yahoo.com> <3047CC55-F9D2-460E-AA14-D99290C9BB0E@Sun.COM> <105522.89208.qm@web30004.mail.mud.yahoo.com> <0026A698-DC8F-44BC-97C4-77F2419F9330@Sun.COM> <873610.44048.qm@web30008.mail.mud.yahoo.com> <89FDB0BB-DE27-4C60-850F-156A29C43D0D@Sun.COM> <481420.74580.qm@web30008.mail.mud.yahoo.com> Message-ID: <833EE0B7-3090-4635-B3B8-48BB98796F2E@Sun.COM> On Feb 4, 2009, at 8:47 PM, James Walsh wrote: > Let's say the heap is at 0x1000. I have a 5 float array that I want > strongly aligned. I create a dummy 20 byte array leaving the heap > at 0x1014. I create the 5 float array with a 12 byte header. The > data in the array oop is aligned on the 16byte boundary for SIMD and > the whole oop is a nice round 32 bytes which is MinObjAlignment > aligned. Unfortunately the heap is now at 0x1034 which will assert > on the next allocation. Oh, I was forgetting the effect of aligning the array base; thanks for the clear example. This gets back to our exchange on Monday about option #3, which is allowing array bases to be (relatively) unaligned, and just requiring SIMD code (incl. optimized loops) to know about the oddity. It's easier than fixing arrays so that their bases are more strongly aligned. I think that would require lots of changes in lots of places, more places than the relatively simple hack of inserting dummy objects. Let me try some examples with a new float or double array, where you want to align the first possible element (0 or 1) mod 16.... Since the JVM alignment is always 8 but your vector alignment is 16, your decision is always between doing nothing and inserting an 8-byte dummy object (new Object() would do it nicely). On a 64-bit JVM, there is no such thing as an 8-byte object, so you are stuck with inserting a 24-byte dummy object (new Object[0] works great). Case #0F: heap HWM is 0 mod 16 0x1000: array mark, klass 0x1008: array length, array[0] (fixed odd leading element) 0x1010: array[1..2] 0x1018: array[3..4] Case #1F: heap HWM is 8 mod 16 (need a dummy) 0x1008: dummy mark, klass 0x1010: array mark, klass 0x1018: array length, array[0] (fixed odd leading element) 0x1020: array[1..2] 0x1028: array[3..4] In both cases, a[1..4] is a strongly aligned f4 vector, and a[0] is a fixed odd leading element. (Option #3.) Although it is annoying for loops to deal with the odd leading element, the logic almost certainly folds into more general logic which deals with vector operations that start at non-zero offsets from the array base. In the case of a long array, there is no odd leading element: Case #0D: heap HWM is 0 mod 16 0x1000: array mark, klass 0x1008: array length, padding 0x1010: array[0] 0x1018: array[1] Case #1D: heap HWM is 8 mod 16 (need a dummy) 0x1008: dummy mark, klass 0x1010: array mark, klass 0x1018: array length, padding 0x1020: array[0] 0x1028: array[1] In the case of a 64-bit JVM with compressed oops, the array header is 16 bytes and the base is always 64-bit aligned: Case #0F/C: heap HWM is 0 mod 16 0x1000: array mark (64 bits) 0x1008: array klass, length 0x1010: array[0..1] 0x1018: array[2..3] Case #1F/C: heap HWM is 8 mod 16 (need a dummy) 0x1008: dummy mark, klass 0x1010: array mark (64 bits) 0x1018: array klass, length 0x1020: array[0..1] 0x1028: array[2..3] In the case of a 64-bit JVM with a full-sized oops, the array header is 24 bytes and the base is always 64-bit aligned. Case #0F/X: heap HWM is 0 mod 16 (need a dummy) 0x1000: dummy mark 0x1008: dummy klass 0x1010: dummy body (e.g., array of length zero) 0x1018: array mark 0x1020: array klass 0x1028: array length, padding 0x1030: array[0..1] 0x1038: array[2..3] Case #1F/X: heap HWM is 8 mod 16 0x1008: array mark 0x1010: array klass 0x1018: array length, padding 0x1020: array[0..1] 0x1028: array[2..3] See arrayOopDesc::base_offset_in_bytes for all the grody details about array layout. It is worthwhile scrounging up a a one-word, 8-byte pseudo-object in case #0F/X, if it already exists. There might already be such a thing somewhere in the GC code. -- John From Christian.Thalinger at Sun.COM Thu Feb 5 01:41:40 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 05 Feb 2009 10:41:40 +0100 Subject: Fix warnings occurring with gcc 4.3 In-Reply-To: <4988F333.1010506@sun.com> References: <17c6771e0902031230h64de81a3o71fa5d332c046988@mail.gmail.com> <4988BD23.2000303@Sun.COM> <17c6771e0902031424ga0ac7b4md15f99f4dcad1874@mail.gmail.com> <4988C500.5070700@Sun.COM> <17c6771e0902031431m70b87b23y72a7d773026018b3@mail.gmail.com> <4988CF64.5010300@sun.com> <4988D9BB.4080307@Sun.COM> <4988E433.3050809@sun.com> <4988ED76.3020202@Sun.COM> <4988F333.1010506@sun.com> Message-ID: <1233826900.1536.60.camel@localhost.localdomain> On Wed, 2009-02-04 at 11:45 +1000, David Holmes - Sun Microsystems wrote: > Xiaobin Lu said the following on 02/04/09 11:20: > > I think the right way to fix this is to define _lineno as "int" and fix > > line 309 of vmError.cpp to use "%d" for _lineno instead of "SIZE_FORMAT" > > (which is why I thought to use size_t for _lineno). > > I agree - revert to int and %d. I will fix this as of 6778669 if that's okay. > I guess the compiler isn't that good at detecting problems with format > specifiers. It also seems to have missed this at line 423: > > st->print(", free space=%dk", > ((intptr_t)fr.sp() - (intptr_t)stack_bottom) >> 10); And this one too. -- Christian From gnu_andrew at member.fsf.org Thu Feb 5 03:41:55 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 5 Feb 2009 11:41:55 +0000 Subject: Fix warnings occurring with gcc 4.3 In-Reply-To: <1233743721.3982.249.camel@localhost.localdomain> References: <17c6771e0902031230h64de81a3o71fa5d332c046988@mail.gmail.com> <4988BD23.2000303@Sun.COM> <17c6771e0902031424ga0ac7b4md15f99f4dcad1874@mail.gmail.com> <4988C500.5070700@Sun.COM> <17c6771e0902031431m70b87b23y72a7d773026018b3@mail.gmail.com> <1233743721.3982.249.camel@localhost.localdomain> Message-ID: <17c6771e0902050341h39c1be25ub0804322fc87779c@mail.gmail.com> 2009/2/4 Christian Thalinger : > On Tue, 2009-02-03 at 22:31 +0000, Andrew John Hughes wrote: >> Good. We obviously don't build directly from the forest and it isn't >> clear that such changes are in that tree; the commit list just shows >> the branch being tagged. > > The bug Xiaobin is talking about is 6781583. The pushed changeset is: > > http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2328d1d3f8cf > > and it has already been promoted to the hotspot forest. > > -- Christian > > This patch actually contains 4 IcedTea patches: patches/icedtea-fortify-source.patch (2008/12/03) patches/icedtea-format-warnings.patch (2008/12/03) patches/icedtea-no-bcopy.patch (2008/06/10) all by Matthias Klose, in addition to the one I posted, now in IcedTea as patches/hotspot/14.0b08/icedtea-format.patch In future, it would be preferable if work wasn't duplicated in this manner. -- Andrew :-) IcedTea/OpenJDK 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 Thu Feb 5 04:03:05 2009 From: y.s.ramakrishna at sun.com (y.s.ramakrishna at sun.com) Date: Thu, 05 Feb 2009 12:03:05 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20090205120313.2710712B69@hg.openjdk.java.net> Changeset: 23673011938d Author: ysr Date: 2009-01-30 14:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/23673011938d 6787254: Work queue capacity can be increased substantially on some platforms Summary: Increased the default and maximum size of the CMS marking stack and the size of the parallel workers' work queues in 64-bit mode. The latter was accomplished by an increase in the width of the Taskqueue's Age struct and its Tag field in 64-bit mode. Reviewed-by: jmasa, tonyp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 9a25e0c45327 Author: jmasa Date: 2009-01-31 00:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9a25e0c45327 6792421: assert(_bitMap->isMarked(addr+size-1),inconsistent Printezis mark) Summary: The CMS concurrent precleaning and concurrent marking phases should work around classes that are undergoing redefinition. Reviewed-by: ysr, tonyp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/oops/cpCacheKlass.hpp ! src/share/vm/oops/cpCacheOop.hpp Changeset: a268411445d9 Author: ysr Date: 2009-02-04 15:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a268411445d9 Merge From Christian.Thalinger at Sun.COM Thu Feb 5 04:30:36 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 05 Feb 2009 13:30:36 +0100 Subject: Fix warnings occurring with gcc 4.3 In-Reply-To: <17c6771e0902050341h39c1be25ub0804322fc87779c@mail.gmail.com> References: <17c6771e0902031230h64de81a3o71fa5d332c046988@mail.gmail.com> <4988BD23.2000303@Sun.COM> <17c6771e0902031424ga0ac7b4md15f99f4dcad1874@mail.gmail.com> <4988C500.5070700@Sun.COM> <17c6771e0902031431m70b87b23y72a7d773026018b3@mail.gmail.com> <1233743721.3982.249.camel@localhost.localdomain> <17c6771e0902050341h39c1be25ub0804322fc87779c@mail.gmail.com> Message-ID: <1233837036.1536.168.camel@localhost.localdomain> On Thu, 2009-02-05 at 11:41 +0000, Andrew John Hughes wrote: > This patch actually contains 4 IcedTea patches: > > patches/icedtea-fortify-source.patch (2008/12/03) > patches/icedtea-format-warnings.patch (2008/12/03) > patches/icedtea-no-bcopy.patch (2008/06/10) > > all by Matthias Klose, in addition to the one I posted, now in IcedTea > as patches/hotspot/14.0b08/icedtea-format.patch Thanks for looking that up. > > In future, it would be preferable if work wasn't duplicated in this manner. Indeed. Probably such patches should be filed with a CR, so we can include them right away. Given a SCA is in place, which is not the case for the three patches above by Matthias Klose. -- Christian From Christian.Thalinger at Sun.COM Thu Feb 5 10:07:15 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 05 Feb 2009 19:07:15 +0100 Subject: parallel debug builds on solaris-sparc Message-ID: <1233857235.1536.229.camel@localhost.localdomain> Hi! Is there a reason why I cannot do parallel debug builds with more than two jobs on a T1000 running Solaris? When I do: $ export HOTSPOT_BUILD_JOBS=32 $ make jvmg I get errors like: gnumake[4]: *** No rule to make target `_loopUnswitch.cpp.incl', needed by `loopUnswitch.o'. Stop. It works for product builds and it works with HOTSPOT_BUILD_JOBS=2 for debug builds. Is there a difference in pre-compiling headers for debug and non-debug? -- Christian From Christian.Thalinger at Sun.COM Thu Feb 5 11:10:34 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 05 Feb 2009 20:10:34 +0100 Subject: parallel debug builds on solaris-sparc In-Reply-To: <498B33C7.2090004@sun.com> References: <1233857235.1536.229.camel@localhost.localdomain> <498B33C7.2090004@sun.com> Message-ID: <1233861034.1536.233.camel@localhost.localdomain> On Thu, 2009-02-05 at 13:45 -0500, Tony Printezis wrote: > Try restarting the job. This happens to me every now and then when I use > many parallel make tasks. It eventually completes. Yes, it's a pain... I already tried that and sometimes it works. But right now it doesn't anymore and I wonder why it does work for product builds without any problems. -- Christian From Thomas.Rodriguez at Sun.COM Thu Feb 5 11:26:30 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 05 Feb 2009 11:26:30 -0800 Subject: parallel debug builds on solaris-sparc In-Reply-To: <1233861034.1536.233.camel@localhost.localdomain> References: <1233857235.1536.229.camel@localhost.localdomain> <498B33C7.2090004@sun.com> <1233861034.1536.233.camel@localhost.localdomain> Message-ID: <7F97F20B-1863-427C-BAFE-76A3428D0FC7@sun.com> Make sure you are using a good version of GNU make. The default build of make has support for something called a build server and there's a problem in how it handles signals and restartable system calls which causes failures like you're seeing. Have you tried /java/devtools/ sparc/bin/gnumake? tom On Feb 5, 2009, at 11:10 AM, Christian Thalinger wrote: > On Thu, 2009-02-05 at 13:45 -0500, Tony Printezis wrote: >> Try restarting the job. This happens to me every now and then when >> I use >> many parallel make tasks. It eventually completes. Yes, it's a >> pain... > > I already tried that and sometimes it works. But right now it doesn't > anymore and I wonder why it does work for product builds without any > problems. > > -- Christian > From groundskeeperwiley at yahoo.com Thu Feb 5 12:56:14 2009 From: groundskeeperwiley at yahoo.com (James Walsh) Date: Thu, 5 Feb 2009 12:56:14 -0800 (PST) Subject: Superword - Aligning arrays References: <90121.96359.qm@web30002.mail.mud.yahoo.com> <15917.77377.qm@web30004.mail.mud.yahoo.com> <3047CC55-F9D2-460E-AA14-D99290C9BB0E@Sun.COM> <105522.89208.qm@web30004.mail.mud.yahoo.com> <0026A698-DC8F-44BC-97C4-77F2419F9330@Sun.COM> <873610.44048.qm@web30008.mail.mud.yahoo.com> <89FDB0BB-DE27-4C60-850F-156A29C43D0D@Sun.COM> <481420.74580.qm@web30008.mail.mud.yahoo.com> <833EE0B7-3090-4635-B3B8-48BB98796F2E@Sun.COM> Message-ID: <633394.44908.qm@web30003.mail.mud.yahoo.com> It's never easy is it? I'll see what I can do. I appreciate your patience. From Christian.Thalinger at Sun.COM Thu Feb 5 13:39:56 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 05 Feb 2009 22:39:56 +0100 Subject: parallel debug builds on solaris-sparc In-Reply-To: <7F97F20B-1863-427C-BAFE-76A3428D0FC7@sun.com> References: <1233857235.1536.229.camel@localhost.localdomain> <498B33C7.2090004@sun.com> <1233861034.1536.233.camel@localhost.localdomain> <7F97F20B-1863-427C-BAFE-76A3428D0FC7@sun.com> Message-ID: <1233869996.1536.236.camel@localhost.localdomain> On Thu, 2009-02-05 at 11:26 -0800, Tom Rodriguez wrote: > Make sure you are using a good version of GNU make. The default build > of make has support for something called a build server and there's a > problem in how it handles signals and restartable system calls which > causes failures like you're seeing. Have you tried /java/devtools/ > sparc/bin/gnumake? That's the one I use: $ type gnumake gnumake is hashed (/java/devtools/sparc/bin/gnumake) -- Christian From Vladimir.Kozlov at Sun.COM Thu Feb 5 13:53:13 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 05 Feb 2009 13:53:13 -0800 Subject: parallel debug builds on solaris-sparc In-Reply-To: <1233869996.1536.236.camel@localhost.localdomain> References: <1233857235.1536.229.camel@localhost.localdomain> <498B33C7.2090004@sun.com> <1233861034.1536.233.camel@localhost.localdomain> <7F97F20B-1863-427C-BAFE-76A3428D0FC7@sun.com> <1233869996.1536.236.camel@localhost.localdomain> Message-ID: <498B5FC9.6080400@sun.com> Reduce HOTSPOT_BUILD_JOBS to 20 (I use it). I think, with 32 there is no "free" threads for OS. Vladimir Christian Thalinger wrote: > On Thu, 2009-02-05 at 11:26 -0800, Tom Rodriguez wrote: >> Make sure you are using a good version of GNU make. The default build >> of make has support for something called a build server and there's a >> problem in how it handles signals and restartable system calls which >> causes failures like you're seeing. Have you tried /java/devtools/ >> sparc/bin/gnumake? > > That's the one I use: > > $ type gnumake > gnumake is hashed (/java/devtools/sparc/bin/gnumake) > > -- Christian > From Jon.Masamitsu at Sun.COM Thu Feb 5 14:58:53 2009 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Thu, 05 Feb 2009 14:58:53 -0800 Subject: parallel debug builds on solaris-sparc In-Reply-To: <1233869996.1536.236.camel@localhost.localdomain> References: <1233857235.1536.229.camel@localhost.localdomain> <498B33C7.2090004@sun.com> <1233861034.1536.233.camel@localhost.localdomain> <7F97F20B-1863-427C-BAFE-76A3428D0FC7@sun.com> <1233869996.1536.236.camel@localhost.localdomain> Message-ID: <498B6F2D.2030808@Sun.COM> I use the same gnumake that jprt uses. I switched to it because (I think) of the problem you're seeing. /net/prt-web.sfbay/prt/prt-solaris-sparc-bin/gnumake On 02/05/09 13:39, Christian Thalinger wrote: > On Thu, 2009-02-05 at 11:26 -0800, Tom Rodriguez wrote: >> Make sure you are using a good version of GNU make. The default build >> of make has support for something called a build server and there's a >> problem in how it handles signals and restartable system calls which >> causes failures like you're seeing. Have you tried /java/devtools/ >> sparc/bin/gnumake? > > That's the one I use: > > $ type gnumake > gnumake is hashed (/java/devtools/sparc/bin/gnumake) > > -- Christian > From Christian.Thalinger at Sun.COM Fri Feb 6 00:57:52 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 06 Feb 2009 09:57:52 +0100 Subject: parallel debug builds on solaris-sparc In-Reply-To: <498B5FC9.6080400@sun.com> References: <1233857235.1536.229.camel@localhost.localdomain> <498B33C7.2090004@sun.com> <1233861034.1536.233.camel@localhost.localdomain> <7F97F20B-1863-427C-BAFE-76A3428D0FC7@sun.com> <1233869996.1536.236.camel@localhost.localdomain> <498B5FC9.6080400@sun.com> Message-ID: <1233910672.1536.241.camel@localhost.localdomain> On Thu, 2009-02-05 at 13:53 -0800, Vladimir Kozlov wrote: > Reduce HOTSPOT_BUILD_JOBS to 20 (I use it). > I think, with 32 there is no "free" threads for OS. Thing is, 3 or 4 does not work too. -- Christian From john.coomes at sun.com Fri Feb 6 11:03:21 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 06 Feb 2009 19:03:21 +0000 Subject: hg: jdk7/hotspot: Added tag jdk7-b46 for changeset e8a2a4d18777 Message-ID: <20090206190321.431CC12C86@hg.openjdk.java.net> Changeset: d7744e86dedc Author: xdono Date: 2009-02-05 16:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/d7744e86dedc Added tag jdk7-b46 for changeset e8a2a4d18777 ! .hgtags From john.coomes at sun.com Fri Feb 6 11:06:02 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 06 Feb 2009 19:06:02 +0000 Subject: hg: jdk7/hotspot/corba: Added tag jdk7-b46 for changeset 1691dbfc08f8 Message-ID: <20090206190603.DA45312C8B@hg.openjdk.java.net> Changeset: 167ad0164301 Author: xdono Date: 2009-02-05 16:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/167ad0164301 Added tag jdk7-b46 for changeset 1691dbfc08f8 ! .hgtags From john.coomes at sun.com Fri Feb 6 11:11:14 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 06 Feb 2009 19:11:14 +0000 Subject: hg: jdk7/hotspot/jaxp: Added tag jdk7-b46 for changeset b2271877894a Message-ID: <20090206191116.5947612ECC@hg.openjdk.java.net> Changeset: d711ad1954b2 Author: xdono Date: 2009-02-05 16:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/d711ad1954b2 Added tag jdk7-b46 for changeset b2271877894a ! .hgtags From john.coomes at sun.com Fri Feb 6 11:13:55 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 06 Feb 2009 19:13:55 +0000 Subject: hg: jdk7/hotspot/jaxws: Added tag jdk7-b46 for changeset af4a3eeb7812 Message-ID: <20090206191357.6F18A12FDA@hg.openjdk.java.net> Changeset: 223011570edb Author: xdono Date: 2009-02-05 16:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/223011570edb Added tag jdk7-b46 for changeset af4a3eeb7812 ! .hgtags From john.coomes at sun.com Fri Feb 6 11:18:03 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 06 Feb 2009 19:18:03 +0000 Subject: hg: jdk7/hotspot/jdk: 40 new changesets Message-ID: <20090206192603.0F0C612FE6@hg.openjdk.java.net> Changeset: 13d7e2477737 Author: sherman Date: 2009-01-13 09:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/13d7e2477737 6332094: "jar t" and "jar x" should use ZipFile, not ZipInputStream Summary: To use ZipFile for jar "t" and "x" to boost performance Reviewed-by: martin, alanb ! src/share/classes/sun/tools/jar/Main.java Changeset: 8c1c6e11204b Author: chegar Date: 2009-01-14 17:17 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8c1c6e11204b 6755782: It is not clear how DatagramSocket deals with broadcast enabling/disabling Reviewed-by: jccollet ! src/share/classes/java/net/DatagramSocket.java Changeset: 7f6969c09075 Author: darcy Date: 2009-01-14 16:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7f6969c09075 6792545: Typo in java.util.Collection JavaDoc 6655123: Incorrect ref to The Art of Computer Programming in doc for java.util.Random Summary: Fix a pair of typos. Reviewed-by: jjg ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Random.java Changeset: 9260d9bd0843 Author: weijun Date: 2009-01-19 18:49 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9260d9bd0843 6793475: krb5.ini not found on some Windows Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/Config.java ! src/windows/native/sun/security/krb5/WindowsDirectory.c Changeset: 1f751a9f7052 Author: mchung Date: 2009-01-20 13:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1f751a9f7052 6793429: Use compiled properties instead of plain properties for resource file Summary: Rename the variables in Resources.gmk to make compiled properties more explicit Reviewed-by: naoto, yhuang ! make/com/sun/org/apache/xml/Makefile ! make/com/sun/rowset/Makefile ! make/common/internal/Resources.gmk ! make/sun/launcher/Makefile ! make/sun/rmi/oldtools/Makefile ! make/sun/rmi/registry/Makefile ! make/sun/rmi/rmic/Makefile ! make/sun/rmi/rmid/Makefile ! make/sun/serialver/Makefile Changeset: 42f8dea1b865 Author: mchung Date: 2009-01-20 13:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/42f8dea1b865 6769976: (fc) FileChannelImpl.isAMappedBufferField not used Summary: Remove the FileChannelImpl.isAMappedBufferField field Reviewed-by: alanb ! src/share/classes/sun/nio/ch/FileChannelImpl.java Changeset: 7fa0a7a3c080 Author: mchung Date: 2009-01-20 16:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7fa0a7a3c080 Merge Changeset: 63f8707112be Author: sherman Date: 2009-01-22 20:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/63f8707112be 6476425: (fmt)java.util.Formatter.print() throws IllegalArgumentException on large BigDecima Summary: Correct the wrong calculation of "precision" in certain circumstances. Reviewed-by: darcy, alanb ! src/share/classes/java/util/Formatter.java ! test/java/util/Formatter/Basic-X.java ! test/java/util/Formatter/Basic.java ! test/java/util/Formatter/BasicBigDecimal.java ! test/java/util/Formatter/BasicBigInteger.java ! test/java/util/Formatter/BasicBoolean.java ! test/java/util/Formatter/BasicBooleanObject.java ! test/java/util/Formatter/BasicByte.java ! test/java/util/Formatter/BasicByteObject.java ! test/java/util/Formatter/BasicChar.java ! test/java/util/Formatter/BasicCharObject.java ! test/java/util/Formatter/BasicDateTime.java ! test/java/util/Formatter/BasicDouble.java ! test/java/util/Formatter/BasicDoubleObject.java ! test/java/util/Formatter/BasicFloat.java ! test/java/util/Formatter/BasicFloatObject.java ! test/java/util/Formatter/BasicInt.java ! test/java/util/Formatter/BasicIntObject.java ! test/java/util/Formatter/BasicLong.java ! test/java/util/Formatter/BasicLongObject.java ! test/java/util/Formatter/BasicShort.java ! test/java/util/Formatter/BasicShortObject.java ! test/java/util/Formatter/genBasic.sh Changeset: cb641d17bbb3 Author: darcy Date: 2009-01-23 10:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/cb641d17bbb3 6604864: Double.valueOf(String) does not specify behaviour for overflow and underflow Reviewed-by: emcmanus ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java Changeset: 175b6adf65b3 Author: tbell Date: 2009-01-24 16:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/175b6adf65b3 Merge Changeset: f3ad2ee4600b Author: darcy Date: 2009-01-26 19:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f3ad2ee4600b 6601457: Move wrapper class tests from closed to open 6601458: Move java.math tests from closed to open 6740185: Move java/lang/annotations tests to open 6759433: Move Math and StrictMath regression tests from closed to open Summary: Move some more regression tests to the open Reviewed-by: jjg + test/java/lang/Boolean/Factory.java + test/java/lang/Boolean/GetBoolean.java + test/java/lang/Boolean/MakeBooleanComparable.java + test/java/lang/Boolean/ParseBoolean.java + test/java/lang/Byte/Decode.java + test/java/lang/Double/BitwiseConversion.java + test/java/lang/Double/Constants.java + test/java/lang/Double/Extrema.java + test/java/lang/Double/NaNInfinityParsing.java + test/java/lang/Double/ParseDouble.java + test/java/lang/Double/ParseHexFloatingPoint.java + test/java/lang/Double/ToHexString.java + test/java/lang/Float/BitwiseConversion.java + test/java/lang/Float/Constants.java + test/java/lang/Float/Extrema.java + test/java/lang/Float/NaNInfinityParsing.java + test/java/lang/Float/ParseFloat.java + test/java/lang/Integer/BitTwiddle.java + test/java/lang/Integer/Decode.java + test/java/lang/Integer/GetInteger.java + test/java/lang/Integer/ParsingTest.java + test/java/lang/Long/BitTwiddle.java + test/java/lang/Long/Decode.java + test/java/lang/Long/GetLong.java + test/java/lang/Long/ParsingTest.java + test/java/lang/Math/AbsPositiveZero.java + test/java/lang/Math/Atan2Tests.java + test/java/lang/Math/CubeRootTests.java + test/java/lang/Math/Expm1Tests.java + test/java/lang/Math/HyperbolicTests.java + test/java/lang/Math/HypotTests.java + test/java/lang/Math/IeeeRecommendedTests.java + test/java/lang/Math/Log10Tests.java + test/java/lang/Math/Log1pTests.java + test/java/lang/Math/MinMax.java + test/java/lang/Math/PowTests.java + test/java/lang/Math/Rint.java + test/java/lang/Math/TanTests.java + test/java/lang/Math/Tests.java + test/java/lang/Short/ByteSwap.java + test/java/lang/Short/Decode.java + test/java/lang/StrictMath/CubeRootTests.java + test/java/lang/StrictMath/Expm1Tests.java + test/java/lang/StrictMath/HyperbolicTests.java + test/java/lang/StrictMath/HypotTests.java + test/java/lang/StrictMath/Log10Tests.java + test/java/lang/StrictMath/Log1pTests.java + test/java/lang/StrictMath/Tests.java + test/java/lang/ToString.java + test/java/lang/annotation/AnnotationTypeMismatchException/FoundType.java + test/java/lang/annotation/Missing/A.java + test/java/lang/annotation/Missing/B.java + test/java/lang/annotation/Missing/C.java + test/java/lang/annotation/Missing/D.java + test/java/lang/annotation/Missing/Marker.java + test/java/lang/annotation/Missing/Missing.java + test/java/lang/annotation/Missing/MissingTest.java + test/java/lang/annotation/Missing/MissingWrapper.java + test/java/lang/annotation/PackageMain.java + test/java/lang/annotation/RecursiveAnnotation.java + test/java/lang/annotation/UnitTest.java + test/java/lang/annotation/loaderLeak/A.java + test/java/lang/annotation/loaderLeak/B.java + test/java/lang/annotation/loaderLeak/C.java + test/java/lang/annotation/loaderLeak/LoaderLeak.sh + test/java/lang/annotation/loaderLeak/Main.java + test/java/lang/annotation/package-info.java + test/java/math/BigDecimal/AddTests.java + test/java/math/BigDecimal/CompareToTests.java + test/java/math/BigDecimal/Constructor.java + test/java/math/BigDecimal/DivideTests.java + test/java/math/BigDecimal/FloatDoubleValueTests.java + test/java/math/BigDecimal/IntegralDivisionTests.java + test/java/math/BigDecimal/NegateTests.java + test/java/math/BigDecimal/PowTests.java + test/java/math/BigDecimal/RoundingTests.java + test/java/math/BigDecimal/ScaleByPowerOfTenTests.java + test/java/math/BigDecimal/SerializationTests.java + test/java/math/BigDecimal/StringConstructor.java + test/java/math/BigDecimal/StrippingZerosTest.java + test/java/math/BigDecimal/ToPlainStringTests.java + test/java/math/BigDecimal/ZeroScalingTests.java + test/java/math/BigInteger/BigIntegerTest.java + test/java/math/BigInteger/ModPow.java + test/java/math/BigInteger/ModPow65537.java + test/java/math/BigInteger/ModPowPowersof2.java + test/java/math/BigInteger/OperatorNpeTests.java + test/java/math/BigInteger/ProbablePrime.java + test/java/math/BigInteger/StringConstructor.java + test/java/math/BigInteger/UnicodeConstructor.java + test/java/math/RoundingMode/RoundingModeTests.java Changeset: 2113813eda62 Author: tbell Date: 2009-01-29 21:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2113813eda62 Merge Changeset: 443db0030323 Author: peytoia Date: 2008-10-02 15:54 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/443db0030323 6645263: (cal) Calendar throw java.lang.IllegalArgumentException: WEEK_OF_MONTH Reviewed-by: okutsu ! src/share/classes/java/util/Calendar.java + test/java/util/Calendar/Bug6645263.java Changeset: 7f4488e9ba24 Author: peytoia Date: 2008-10-03 15:54 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7f4488e9ba24 6683975: [fmt-da] Regression: Java 6 returns English DateFormatPatterns for Thai locale Reviewed-by: okutsu ! src/share/classes/sun/text/resources/FormatData_th.java + test/java/text/Format/DateFormat/Bug6683975.java Changeset: f71879c0999f Author: naoto Date: 2008-10-06 17:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f71879c0999f 6706382: jdk/test/java/util/Locale/data/deflocale.sol10 has incorrect legal notice Reviewed-by: okutsu ! test/java/util/Locale/data/deflocale.sol10 Changeset: a9be64f0ad3e Author: peytoia Date: 2008-10-07 18:25 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a9be64f0ad3e 6756569: (tz) Support tzdata2008g Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/southamerica Changeset: 7560426ed283 Author: rkennke Date: 2008-10-15 15:55 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7560426ed283 6759311: RepaintManager casts Tookit to SunToolkit without instanceof check Summary: Check type of Toolkit before casting. Reviewed-by: alexp ! src/share/classes/javax/swing/RepaintManager.java Changeset: 244f62312fec Author: peytoia Date: 2008-10-16 14:00 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/244f62312fec 6758988: (tz) Support tzdata2008h Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab Changeset: 8ea49fa4c2f7 Author: peytoia Date: 2008-10-17 13:34 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8ea49fa4c2f7 6759521: Move Bidi test programs from closed to open. Reviewed-by: okutsu + test/java/text/Bidi/BidiBug.java + test/java/text/Bidi/BidiEmbeddingTest.java + test/java/text/Bidi/BidiSurrogateTest.java Changeset: 3bc97f84a8aa Author: lana Date: 2008-10-17 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3bc97f84a8aa Merge - make/ASSEMBLY_EXCEPTION - make/LICENSE - make/README - make/README-builds.html - make/README.html - make/THIRD_PARTY_README - src/share/classes/java/nio/channels/package.html - src/share/classes/sun/nio/ch/OptionAdaptor.java - src/share/classes/sun/nio/ch/SocketOpts.java - src/share/classes/sun/nio/ch/SocketOptsImpl.java - src/share/classes/sun/nio/ch/exceptions - src/share/javavm/include/opcodes.h - src/share/javavm/include/opcodes.length - src/share/javavm/include/opcodes.list - src/share/javavm/include/opcodes.weight - src/share/javavm/include/opcodes.wide - src/share/javavm/include/sys_api.h - src/share/javavm/include/typedefs.h - src/solaris/classes/sun/awt/motif/MButtonPeer.java - src/solaris/classes/sun/awt/motif/MCanvasPeer.java - src/solaris/classes/sun/awt/motif/MCheckboxMenuItemPeer.java - src/solaris/classes/sun/awt/motif/MCheckboxPeer.java - src/solaris/classes/sun/awt/motif/MChoicePeer.java - src/solaris/classes/sun/awt/motif/MComponentPeer.java - src/solaris/classes/sun/awt/motif/MCustomCursor.java - src/solaris/classes/sun/awt/motif/MDataTransferer.java - src/solaris/classes/sun/awt/motif/MDialogPeer.java - src/solaris/classes/sun/awt/motif/MDragSourceContextPeer.java - src/solaris/classes/sun/awt/motif/MDropTargetContextPeer.java - src/solaris/classes/sun/awt/motif/MEmbedCanvasPeer.java - src/solaris/classes/sun/awt/motif/MEmbeddedFrame.java - src/solaris/classes/sun/awt/motif/MEmbeddedFramePeer.java - src/solaris/classes/sun/awt/motif/MFileDialogPeer.java - src/solaris/classes/sun/awt/motif/MFramePeer.java - src/solaris/classes/sun/awt/motif/MGlobalCursorManager.java - src/solaris/classes/sun/awt/motif/MInputMethod.java - src/solaris/classes/sun/awt/motif/MInputMethodControl.java - src/solaris/classes/sun/awt/motif/MInputMethodDescriptor.java - src/solaris/classes/sun/awt/motif/MLabelPeer.java - src/solaris/classes/sun/awt/motif/MListPeer.java - src/solaris/classes/sun/awt/motif/MMenuBarPeer.java - src/solaris/classes/sun/awt/motif/MMenuItemPeer.java - src/solaris/classes/sun/awt/motif/MMenuPeer.java - src/solaris/classes/sun/awt/motif/MMouseDragGestureRecognizer.java - src/solaris/classes/sun/awt/motif/MPanelPeer.java - src/solaris/classes/sun/awt/motif/MPopupMenuPeer.java - src/solaris/classes/sun/awt/motif/MRobotPeer.java - src/solaris/classes/sun/awt/motif/MScrollPanePeer.java - src/solaris/classes/sun/awt/motif/MScrollbarPeer.java - src/solaris/classes/sun/awt/motif/MTextAreaPeer.java - src/solaris/classes/sun/awt/motif/MTextFieldPeer.java - src/solaris/classes/sun/awt/motif/MWindowPeer.java - src/solaris/classes/sun/awt/motif/X11Clipboard.java - src/solaris/classes/sun/awt/motif/X11DragSourceContextPeer.java - src/solaris/classes/sun/awt/motif/X11DropTargetContextPeer.java - src/solaris/classes/sun/awt/motif/X11Selection.java - src/solaris/classes/sun/awt/motif/X11SelectionHolder.java - src/solaris/javavm/include/typedefs_md.h - src/solaris/native/sun/awt/awt_Button.c - src/solaris/native/sun/awt/awt_Canvas.c - src/solaris/native/sun/awt/awt_Checkbox.c - src/solaris/native/sun/awt/awt_Choice12.c - src/solaris/native/sun/awt/awt_Choice21.c - src/solaris/native/sun/awt/awt_Component.c - src/solaris/native/sun/awt/awt_Cursor.c - src/solaris/native/sun/awt/awt_DataTransferer.c - src/solaris/native/sun/awt/awt_DataTransferer.h - src/solaris/native/sun/awt/awt_FileDialog.c - src/solaris/native/sun/awt/awt_GlobalCursorManager.c - src/solaris/native/sun/awt/awt_KeyboardFocusManager.c - src/solaris/native/sun/awt/awt_Label.c - src/solaris/native/sun/awt/awt_List.c - src/solaris/native/sun/awt/awt_Menu.c - src/solaris/native/sun/awt/awt_Menu.h - src/solaris/native/sun/awt/awt_MenuBar.c - src/solaris/native/sun/awt/awt_MenuBar.h - src/solaris/native/sun/awt/awt_MenuComponent.c - src/solaris/native/sun/awt/awt_MenuItem.c - src/solaris/native/sun/awt/awt_PopupMenu.c - src/solaris/native/sun/awt/awt_ScrollPane.c - src/solaris/native/sun/awt/awt_Scrollbar.c - src/solaris/native/sun/awt/awt_Selection.c - src/solaris/native/sun/awt/awt_TextArea.c - src/solaris/native/sun/awt/awt_TextArea.h - src/solaris/native/sun/awt/awt_TextField.c - src/solaris/native/sun/awt/awt_TextField.h - src/solaris/native/sun/awt/awt_TopLevel.c - src/solaris/native/sun/awt/awt_XmDnD.c - src/solaris/native/sun/awt/awt_XmDnD.h - src/solaris/native/sun/awt/awt_dnd.c - src/solaris/native/sun/awt/awt_dnd.h - src/solaris/native/sun/awt/awt_dnd_ds.c - src/solaris/native/sun/awt/awt_dnd_dt.c - src/solaris/native/sun/awt/awt_motif.c - src/solaris/native/sun/awt/awt_motif12.c - src/solaris/native/sun/awt/awt_motif21.c - src/solaris/native/sun/awt/awt_xembed.c - src/solaris/native/sun/awt/canvas.c - src/solaris/native/sun/awt/cursor.c - src/windows/javavm/include/typedefs_md.h Changeset: f67599e0ee33 Author: peytoia Date: 2008-10-30 13:12 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f67599e0ee33 6764308: (tz) Support tzdata2008i Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: f8461a705330 Author: rupashka Date: 2008-11-17 17:36 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f8461a705330 6771030: Code improvement and warnings removing from the com.sun.java.swing.plaf.gtk package Summary: Removed unnecessary castings and other warnings Reviewed-by: malenkov ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKEngine.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java ! src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java Changeset: 6c5781fc3818 Author: peytoia Date: 2008-11-18 13:58 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6c5781fc3818 6769873: Regression test java/text/Date/DateFormat/Bug6683975.java started failing after DST ended. Reviewed-by: okutsu ! test/java/text/Format/DateFormat/Bug6683975.java Changeset: bdfe33408ed8 Author: peytoia Date: 2008-11-18 15:59 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/bdfe33408ed8 6772646: Regression test java/text/Date/DateFormat/Bug4823811.java started failing after DST ended. Reviewed-by: okutsu ! test/java/text/Format/DateFormat/Bug4823811.java Changeset: 63e684c4ed2f Author: rupashka Date: 2008-11-25 16:42 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/63e684c4ed2f 6698013: JFileChooser can no longer navigate non-local file systems. Summary: ShellFolder is used only if possible Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/share/classes/sun/swing/FilePane.java + test/javax/swing/JFileChooser/6698013/bug6698013.html + test/javax/swing/JFileChooser/6698013/bug6698013.java Changeset: be2b6b030a79 Author: rupashka Date: 2008-11-26 19:08 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/be2b6b030a79 6560349: REGRESSION :folder having ".lnk" in the name can not be opened by 5.0 and later versions Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java Changeset: 8b842701af50 Author: rupashka Date: 2008-11-26 19:38 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8b842701af50 6776856: Code with useShellFolder field shuold be simplify Reviewed-by: peterz ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/share/classes/sun/swing/FilePane.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java Changeset: 5784f5dfe3ac Author: rupashka Date: 2008-11-27 17:55 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5784f5dfe3ac 6776095: Code improvement and warnings removing from swing packages Reviewed-by: malenkov Contributed-by: Florian Brunner ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/share/classes/javax/swing/ImageIcon.java ! src/share/classes/javax/swing/ProgressMonitor.java ! src/share/classes/javax/swing/SwingWorker.java ! src/share/classes/javax/swing/colorchooser/DefaultColorSelectionModel.java ! src/share/classes/javax/swing/table/DefaultTableColumnModel.java ! src/share/classes/javax/swing/tree/DefaultMutableTreeNode.java ! src/share/classes/javax/swing/undo/CompoundEdit.java Changeset: 50a9a4db3500 Author: malenkov Date: 2008-12-22 17:42 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/50a9a4db3500 4864117: RFE: Make XMLDecoder API more reusable Reviewed-by: peterz, loneid - src/share/classes/com/sun/beans/ObjectHandler.java + src/share/classes/com/sun/beans/decoder/AccessorElementHandler.java + src/share/classes/com/sun/beans/decoder/ArrayElementHandler.java + src/share/classes/com/sun/beans/decoder/BooleanElementHandler.java + src/share/classes/com/sun/beans/decoder/ByteElementHandler.java + src/share/classes/com/sun/beans/decoder/CharElementHandler.java + src/share/classes/com/sun/beans/decoder/ClassElementHandler.java + src/share/classes/com/sun/beans/decoder/DocumentHandler.java + src/share/classes/com/sun/beans/decoder/DoubleElementHandler.java + src/share/classes/com/sun/beans/decoder/ElementHandler.java + src/share/classes/com/sun/beans/decoder/FalseElementHandler.java + src/share/classes/com/sun/beans/decoder/FieldElementHandler.java + src/share/classes/com/sun/beans/decoder/FloatElementHandler.java + src/share/classes/com/sun/beans/decoder/IntElementHandler.java + src/share/classes/com/sun/beans/decoder/JavaElementHandler.java + src/share/classes/com/sun/beans/decoder/LongElementHandler.java + src/share/classes/com/sun/beans/decoder/MethodElementHandler.java + src/share/classes/com/sun/beans/decoder/NewElementHandler.java + src/share/classes/com/sun/beans/decoder/NullElementHandler.java + src/share/classes/com/sun/beans/decoder/ObjectElementHandler.java + src/share/classes/com/sun/beans/decoder/PropertyElementHandler.java + src/share/classes/com/sun/beans/decoder/ShortElementHandler.java + src/share/classes/com/sun/beans/decoder/StringElementHandler.java + src/share/classes/com/sun/beans/decoder/TrueElementHandler.java + src/share/classes/com/sun/beans/decoder/ValueObject.java + src/share/classes/com/sun/beans/decoder/ValueObjectImpl.java + src/share/classes/com/sun/beans/decoder/VarElementHandler.java + src/share/classes/com/sun/beans/decoder/VoidElementHandler.java + src/share/classes/com/sun/beans/finder/AbstractFinder.java ! src/share/classes/com/sun/beans/finder/ClassFinder.java + src/share/classes/com/sun/beans/finder/ConstructorFinder.java + src/share/classes/com/sun/beans/finder/FieldFinder.java + src/share/classes/com/sun/beans/finder/MethodFinder.java ! src/share/classes/com/sun/beans/finder/PrimitiveTypeMap.java + src/share/classes/com/sun/beans/finder/PrimitiveWrapperMap.java + src/share/classes/com/sun/beans/finder/Signature.java ! src/share/classes/java/beans/MetaData.java ! src/share/classes/java/beans/ReflectionUtils.java ! src/share/classes/java/beans/XMLDecoder.java ! src/share/classes/javax/swing/plaf/synth/SynthParser.java + test/java/beans/XMLDecoder/Test4864117.java ! test/java/beans/XMLDecoder/Test6341798.java + test/java/beans/XMLDecoder/spec/AbstractTest.java + test/java/beans/XMLDecoder/spec/TestArray.java + test/java/beans/XMLDecoder/spec/TestBoolean.java + test/java/beans/XMLDecoder/spec/TestByte.java + test/java/beans/XMLDecoder/spec/TestChar.java + test/java/beans/XMLDecoder/spec/TestClass.java + test/java/beans/XMLDecoder/spec/TestDouble.java + test/java/beans/XMLDecoder/spec/TestFalse.java + test/java/beans/XMLDecoder/spec/TestField.java + test/java/beans/XMLDecoder/spec/TestFloat.java + test/java/beans/XMLDecoder/spec/TestInt.java + test/java/beans/XMLDecoder/spec/TestJava.java + test/java/beans/XMLDecoder/spec/TestLong.java + test/java/beans/XMLDecoder/spec/TestMethod.java + test/java/beans/XMLDecoder/spec/TestNew.java + test/java/beans/XMLDecoder/spec/TestNull.java + test/java/beans/XMLDecoder/spec/TestObject.java + test/java/beans/XMLDecoder/spec/TestProperty.java + test/java/beans/XMLDecoder/spec/TestShort.java + test/java/beans/XMLDecoder/spec/TestString.java + test/java/beans/XMLDecoder/spec/TestTrue.java + test/java/beans/XMLDecoder/spec/TestVar.java Changeset: 2b8a0d8b5cbb Author: malenkov Date: 2008-12-25 20:43 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2b8a0d8b5cbb 6736248: EnumEditor bug. Class check incorrect Reviewed-by: rupashka, alexp ! src/share/classes/sun/beans/editors/EnumEditor.java + test/java/beans/PropertyEditor/TestEnumSubclass.java + test/java/beans/PropertyEditor/TestEnumSubclassJava.java + test/java/beans/PropertyEditor/TestEnumSubclassNull.java + test/java/beans/PropertyEditor/TestEnumSubclassValue.java Changeset: b06c29386f63 Author: amenkov Date: 2009-01-19 20:11 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b06c29386f63 6702956: OpenJDK: replace encumbered code (software synthesizer) 6717691: Update Gervill with post 1.0 fixes 6740210: Update Gervill with more post 1.0 fixes 6748247: Further update Gervill with still more post 1.0 fixes 6748251: Apply IcedTea midi sound patch 6758986: Gervill: Turn SoftJitterCorrector, SoftAudioPusher threads into a daemon threads Reviewed-by: ohair, darcy ! make/common/Release.gmk ! make/common/internal/BinaryPlugs.gmk ! make/javax/sound/Makefile - make/javax/sound/jsoundhs/FILES.gmk - make/javax/sound/jsoundhs/Makefile - make/javax/sound/jsoundhs/mapfile-vers ! src/share/classes/com/sun/media/sound/AbstractMidiDevice.java + src/share/classes/com/sun/media/sound/AudioFileSoundbankReader.java + src/share/classes/com/sun/media/sound/AudioFloatConverter.java + src/share/classes/com/sun/media/sound/AudioFloatFormatConverter.java + src/share/classes/com/sun/media/sound/AudioFloatInputStream.java + src/share/classes/com/sun/media/sound/AudioSynthesizer.java + src/share/classes/com/sun/media/sound/AudioSynthesizerPropertyInfo.java + src/share/classes/com/sun/media/sound/DLSInfo.java + src/share/classes/com/sun/media/sound/DLSInstrument.java + src/share/classes/com/sun/media/sound/DLSModulator.java + src/share/classes/com/sun/media/sound/DLSRegion.java + src/share/classes/com/sun/media/sound/DLSSample.java + src/share/classes/com/sun/media/sound/DLSSampleLoop.java + src/share/classes/com/sun/media/sound/DLSSampleOptions.java + src/share/classes/com/sun/media/sound/DLSSoundbank.java + src/share/classes/com/sun/media/sound/DLSSoundbankReader.java ! src/share/classes/com/sun/media/sound/DirectAudioDevice.java + src/share/classes/com/sun/media/sound/EmergencySoundbank.java + src/share/classes/com/sun/media/sound/FFT.java + src/share/classes/com/sun/media/sound/InvalidDataException.java + src/share/classes/com/sun/media/sound/InvalidFormatException.java + src/share/classes/com/sun/media/sound/JARSoundbankReader.java + src/share/classes/com/sun/media/sound/ModelAbstractChannelMixer.java + src/share/classes/com/sun/media/sound/ModelAbstractOscillator.java + src/share/classes/com/sun/media/sound/ModelByteBuffer.java + src/share/classes/com/sun/media/sound/ModelByteBufferWavetable.java + src/share/classes/com/sun/media/sound/ModelChannelMixer.java + src/share/classes/com/sun/media/sound/ModelConnectionBlock.java + src/share/classes/com/sun/media/sound/ModelDestination.java + src/share/classes/com/sun/media/sound/ModelDirectedPlayer.java + src/share/classes/com/sun/media/sound/ModelDirector.java + src/share/classes/com/sun/media/sound/ModelIdentifier.java + src/share/classes/com/sun/media/sound/ModelInstrument.java + src/share/classes/com/sun/media/sound/ModelInstrumentComparator.java + src/share/classes/com/sun/media/sound/ModelMappedInstrument.java + src/share/classes/com/sun/media/sound/ModelOscillator.java + src/share/classes/com/sun/media/sound/ModelOscillatorStream.java + src/share/classes/com/sun/media/sound/ModelPatch.java + src/share/classes/com/sun/media/sound/ModelPerformer.java + src/share/classes/com/sun/media/sound/ModelSource.java + src/share/classes/com/sun/media/sound/ModelStandardDirector.java + src/share/classes/com/sun/media/sound/ModelStandardTransform.java + src/share/classes/com/sun/media/sound/ModelTransform.java + src/share/classes/com/sun/media/sound/ModelWavetable.java ! src/share/classes/com/sun/media/sound/Platform.java + src/share/classes/com/sun/media/sound/RIFFInvalidDataException.java + src/share/classes/com/sun/media/sound/RIFFInvalidFormatException.java + src/share/classes/com/sun/media/sound/RIFFReader.java + src/share/classes/com/sun/media/sound/RIFFWriter.java ! src/share/classes/com/sun/media/sound/RealTimeSequencer.java + src/share/classes/com/sun/media/sound/SF2GlobalRegion.java + src/share/classes/com/sun/media/sound/SF2Instrument.java + src/share/classes/com/sun/media/sound/SF2InstrumentRegion.java + src/share/classes/com/sun/media/sound/SF2Layer.java + src/share/classes/com/sun/media/sound/SF2LayerRegion.java + src/share/classes/com/sun/media/sound/SF2Modulator.java + src/share/classes/com/sun/media/sound/SF2Region.java + src/share/classes/com/sun/media/sound/SF2Sample.java + src/share/classes/com/sun/media/sound/SF2Soundbank.java + src/share/classes/com/sun/media/sound/SF2SoundbankReader.java + src/share/classes/com/sun/media/sound/SimpleInstrument.java + src/share/classes/com/sun/media/sound/SimpleSoundbank.java + src/share/classes/com/sun/media/sound/SoftAbstractResampler.java + src/share/classes/com/sun/media/sound/SoftAudioBuffer.java + src/share/classes/com/sun/media/sound/SoftAudioProcessor.java + src/share/classes/com/sun/media/sound/SoftAudioPusher.java + src/share/classes/com/sun/media/sound/SoftChannel.java + src/share/classes/com/sun/media/sound/SoftChannelProxy.java + src/share/classes/com/sun/media/sound/SoftChorus.java + src/share/classes/com/sun/media/sound/SoftControl.java + src/share/classes/com/sun/media/sound/SoftCubicResampler.java + src/share/classes/com/sun/media/sound/SoftEnvelopeGenerator.java + src/share/classes/com/sun/media/sound/SoftFilter.java + src/share/classes/com/sun/media/sound/SoftInstrument.java + src/share/classes/com/sun/media/sound/SoftJitterCorrector.java + src/share/classes/com/sun/media/sound/SoftLanczosResampler.java + src/share/classes/com/sun/media/sound/SoftLimiter.java + src/share/classes/com/sun/media/sound/SoftLinearResampler.java + src/share/classes/com/sun/media/sound/SoftLinearResampler2.java + src/share/classes/com/sun/media/sound/SoftLowFrequencyOscillator.java + src/share/classes/com/sun/media/sound/SoftMainMixer.java + src/share/classes/com/sun/media/sound/SoftMidiAudioFileReader.java + src/share/classes/com/sun/media/sound/SoftMixingClip.java + src/share/classes/com/sun/media/sound/SoftMixingDataLine.java + src/share/classes/com/sun/media/sound/SoftMixingMainMixer.java + src/share/classes/com/sun/media/sound/SoftMixingMixer.java + src/share/classes/com/sun/media/sound/SoftMixingMixerProvider.java + src/share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java + src/share/classes/com/sun/media/sound/SoftPerformer.java + src/share/classes/com/sun/media/sound/SoftPointResampler.java + src/share/classes/com/sun/media/sound/SoftProcess.java + src/share/classes/com/sun/media/sound/SoftProvider.java + src/share/classes/com/sun/media/sound/SoftReceiver.java + src/share/classes/com/sun/media/sound/SoftResampler.java + src/share/classes/com/sun/media/sound/SoftResamplerStreamer.java + src/share/classes/com/sun/media/sound/SoftReverb.java + src/share/classes/com/sun/media/sound/SoftShortMessage.java + src/share/classes/com/sun/media/sound/SoftSincResampler.java + src/share/classes/com/sun/media/sound/SoftSynthesizer.java + src/share/classes/com/sun/media/sound/SoftTuning.java + src/share/classes/com/sun/media/sound/SoftVoice.java + src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java + src/share/classes/com/sun/media/sound/WaveFloatFileReader.java + src/share/classes/com/sun/media/sound/WaveFloatFileWriter.java ! src/share/classes/com/sun/media/sound/services/javax.sound.midi.spi.MidiDeviceProvider ! src/share/classes/com/sun/media/sound/services/javax.sound.midi.spi.MidiFileReader ! src/share/classes/com/sun/media/sound/services/javax.sound.midi.spi.SoundbankReader ! src/share/classes/com/sun/media/sound/services/javax.sound.sampled.spi.AudioFileReader ! src/share/classes/com/sun/media/sound/services/javax.sound.sampled.spi.FormatConversionProvider ! src/share/classes/com/sun/media/sound/services/javax.sound.sampled.spi.MixerProvider - src/share/lib/audio/soundbank.gm + test/javax/sound/midi/Gervill/AudioFloatConverter/GetFormat.java + test/javax/sound/midi/Gervill/AudioFloatConverter/ToFloatArray.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Available.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Close.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/GetFormat.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/GetFrameLength.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/MarkSupported.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Read.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/ReadFloatArray.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/ReadFloatArrayIntInt.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Reset.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Skip.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankFile.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankInputStream.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankInputStream2.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankUrl.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/ding.dls + test/javax/sound/midi/Gervill/EmergencySoundbank/TestCreateSoundbank.java + test/javax/sound/midi/Gervill/ModelByteBuffer/GetInputStream.java + test/javax/sound/midi/Gervill/ModelByteBuffer/GetRoot.java + test/javax/sound/midi/Gervill/ModelByteBuffer/Load.java + test/javax/sound/midi/Gervill/ModelByteBuffer/LoadAll.java + test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArray.java + test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArrayIntInt.java + test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFile.java + test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFileLongLong.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Available.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Close.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkReset.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkSupported.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Read.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByte.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByteIntInt.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Skip.java + test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLong.java + test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLong.java + test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLongBoolean.java + test/javax/sound/midi/Gervill/ModelByteBuffer/Unload.java + test/javax/sound/midi/Gervill/ModelByteBuffer/WriteTo.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetAttenuation.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetChannels.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetLoopLength.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetLoopStart.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetPitchCorrection.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBuffer.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferAudioFormat.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferAudioFormatFloat.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferFloat.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/Open.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/Set8BitExtensionBuffer.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/SetLoopType.java + test/javax/sound/midi/Gervill/ModelDestination/NewModelDestination.java + test/javax/sound/midi/Gervill/ModelDestination/NewModelDestinationModelIdentifier.java + test/javax/sound/midi/Gervill/ModelDestination/SetIdentifier.java + test/javax/sound/midi/Gervill/ModelDestination/SetTransform.java + test/javax/sound/midi/Gervill/ModelIdentifier/EqualsObject.java + test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierString.java + test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringInt.java + test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringString.java + test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringStringInt.java + test/javax/sound/midi/Gervill/ModelIdentifier/SetInstance.java + test/javax/sound/midi/Gervill/ModelIdentifier/SetObject.java + test/javax/sound/midi/Gervill/ModelIdentifier/SetVariable.java + test/javax/sound/midi/Gervill/ModelPerformer/GetOscillators.java + test/javax/sound/midi/Gervill/ModelPerformer/SetConnectionBlocks.java + test/javax/sound/midi/Gervill/ModelPerformer/SetDefaultConnectionsEnabled.java + test/javax/sound/midi/Gervill/ModelPerformer/SetExclusiveClass.java + test/javax/sound/midi/Gervill/ModelPerformer/SetKeyFrom.java + test/javax/sound/midi/Gervill/ModelPerformer/SetKeyTo.java + test/javax/sound/midi/Gervill/ModelPerformer/SetName.java + test/javax/sound/midi/Gervill/ModelPerformer/SetSelfNonExclusive.java + test/javax/sound/midi/Gervill/ModelPerformer/SetVelFrom.java + test/javax/sound/midi/Gervill/ModelPerformer/SetVelTo.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSource.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifier.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBoolean.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBooleanBoolean.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBooleanBooleanInt.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierModelTransform.java + test/javax/sound/midi/Gervill/ModelSource/SetIdentifier.java + test/javax/sound/midi/Gervill/ModelSource/SetTransform.java + test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransform.java + test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBoolean.java + test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBooleanBoolean.java + test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBooleanBooleanInt.java + test/javax/sound/midi/Gervill/ModelStandardTransform/SetDirection.java + test/javax/sound/midi/Gervill/ModelStandardTransform/SetPolarity.java + test/javax/sound/midi/Gervill/ModelStandardTransform/SetTransform.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformAbsolute.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformConcave.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformConvex.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformLinear.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformSwitch.java + test/javax/sound/midi/Gervill/RiffReaderWriter/Available.java + test/javax/sound/midi/Gervill/RiffReaderWriter/Close.java + test/javax/sound/midi/Gervill/RiffReaderWriter/GetFilePointer.java + test/javax/sound/midi/Gervill/RiffReaderWriter/GetSize.java + test/javax/sound/midi/Gervill/RiffReaderWriter/HasNextChunk.java + test/javax/sound/midi/Gervill/RiffReaderWriter/Read.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByte.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByteArrayIntInt.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadInt.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadLong.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadShort.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadString.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedByte.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedInt.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedShort.java + test/javax/sound/midi/Gervill/RiffReaderWriter/Skip.java + test/javax/sound/midi/Gervill/RiffReaderWriter/WriteOutputStream.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankFile.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankInputStream.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankInputStream2.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankUrl.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/ding.sf2 + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrument.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformer.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArray.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/Clear.java + test/javax/sound/midi/Gervill/SimpleInstrument/SetName.java + test/javax/sound/midi/Gervill/SimpleInstrument/SetPatch.java + test/javax/sound/midi/Gervill/SimpleSoundbank/AddInstrument.java + test/javax/sound/midi/Gervill/SimpleSoundbank/AddResource.java + test/javax/sound/midi/Gervill/SimpleSoundbank/GetInstrument.java + test/javax/sound/midi/Gervill/SimpleSoundbank/RemoveInstrument.java + test/javax/sound/midi/Gervill/SimpleSoundbank/SetDescription.java + test/javax/sound/midi/Gervill/SimpleSoundbank/SetName.java + test/javax/sound/midi/Gervill/SimpleSoundbank/SetVendor.java + test/javax/sound/midi/Gervill/SimpleSoundbank/SetVersion.java + test/javax/sound/midi/Gervill/SoftAudioBuffer/Array.java + test/javax/sound/midi/Gervill/SoftAudioBuffer/Clear.java + test/javax/sound/midi/Gervill/SoftAudioBuffer/Get.java + test/javax/sound/midi/Gervill/SoftAudioBuffer/NewSoftAudioBuffer.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/DummySourceDataLine.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/GetFormat.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/GetPropertyInfo.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/Open.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/OpenStream.java + test/javax/sound/midi/Gervill/SoftChannel/AllNotesOff.java + test/javax/sound/midi/Gervill/SoftChannel/AllSoundOff.java + test/javax/sound/midi/Gervill/SoftChannel/ChannelPressure.java + test/javax/sound/midi/Gervill/SoftChannel/Controller.java + test/javax/sound/midi/Gervill/SoftChannel/LocalControl.java + test/javax/sound/midi/Gervill/SoftChannel/Mono.java + test/javax/sound/midi/Gervill/SoftChannel/Mute.java + test/javax/sound/midi/Gervill/SoftChannel/NoteOff.java + test/javax/sound/midi/Gervill/SoftChannel/NoteOff2.java + test/javax/sound/midi/Gervill/SoftChannel/NoteOn.java + test/javax/sound/midi/Gervill/SoftChannel/Omni.java + test/javax/sound/midi/Gervill/SoftChannel/PitchBend.java + test/javax/sound/midi/Gervill/SoftChannel/PolyPressure.java + test/javax/sound/midi/Gervill/SoftChannel/ProgramChange.java + test/javax/sound/midi/Gervill/SoftChannel/ResetAllControllers.java + test/javax/sound/midi/Gervill/SoftChannel/SoftTestUtils.java + test/javax/sound/midi/Gervill/SoftChannel/Solo.java + test/javax/sound/midi/Gervill/SoftCubicResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftLanczosResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_mono.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_mono_overdrive.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_overdrive.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_normal.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_normal_mono.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_overdrive.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_overdrive_mono.java + test/javax/sound/midi/Gervill/SoftLinearResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftLinearResampler2/Interpolate.java + test/javax/sound/midi/Gervill/SoftPointResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftProvider/GetDevice.java + test/javax/sound/midi/Gervill/SoftReceiver/Close.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_ActiveSense.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_AllNotesOff.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_AllSoundOff.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_ChannelPressure.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_Controller.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_Mono.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOff.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_AllChannels.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_Delayed.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_Multiple.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_Omni.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_PitchBend.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_PolyPressure.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_ProgramChange.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_ResetAllControllers.java + test/javax/sound/midi/Gervill/SoftReceiver/SoftTestUtils.java + test/javax/sound/midi/Gervill/SoftSincResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftSynthesizer/Close.java + test/javax/sound/midi/Gervill/SoftSynthesizer/DummySourceDataLine.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetChannels.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetDefaultSoundbank.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetDeviceInfo.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetLatency.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxPolyphony.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxReceivers.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxTransmitters.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetMicrosecondPosition.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceiver.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceiver2.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceivers.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetTransmitter.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetTransmitters.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetVoiceStatus.java + test/javax/sound/midi/Gervill/SoftSynthesizer/ImplicitOpenClose.java + test/javax/sound/midi/Gervill/SoftSynthesizer/IsOpen.java + test/javax/sound/midi/Gervill/SoftSynthesizer/IsSoundbankSupported.java + test/javax/sound/midi/Gervill/SoftSynthesizer/LoadAllInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstrument.java + test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/Open.java + test/javax/sound/midi/Gervill/SoftSynthesizer/OpenStream.java + test/javax/sound/midi/Gervill/SoftSynthesizer/RemapInstrument.java + test/javax/sound/midi/Gervill/SoftSynthesizer/TestRender1.java + test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadAllInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstrument.java + test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/ding.sf2 + test/javax/sound/midi/Gervill/SoftSynthesizer/expresso.mid + test/javax/sound/midi/Gervill/SoftTuning/GetName.java + test/javax/sound/midi/Gervill/SoftTuning/GetTuning.java + test/javax/sound/midi/Gervill/SoftTuning/GetTuningInt.java + test/javax/sound/midi/Gervill/SoftTuning/Load1.java + test/javax/sound/midi/Gervill/SoftTuning/Load2.java + test/javax/sound/midi/Gervill/SoftTuning/Load4.java + test/javax/sound/midi/Gervill/SoftTuning/Load5.java + test/javax/sound/midi/Gervill/SoftTuning/Load6.java + test/javax/sound/midi/Gervill/SoftTuning/Load7.java + test/javax/sound/midi/Gervill/SoftTuning/Load8.java + test/javax/sound/midi/Gervill/SoftTuning/Load9.java + test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuning.java + test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningByteArray.java + test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningPatch.java + test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningPatchByteArray.java Changeset: cda097df492f Author: peterz Date: 2009-01-21 21:30 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/cda097df492f 6792401: Windows LAF: ActiveWindowsIcon should not be greedy with fallback icon Summary: Fallback mechanism changed to use symbolic name instead of icon. Reviewed-by: igor, rupashka ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java Changeset: cf591ddc3456 Author: naoto Date: 2009-01-21 13:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/cf591ddc3456 6627549: ISO 3166 code addition: Saint Barthelemy and Saint Martin 6786276: Locale.getISOCountries() still contains country code "CS" Reviewed-by: okutsu ! src/share/classes/java/util/CurrencyData.properties ! src/share/classes/java/util/LocaleISOData.java ! src/share/classes/sun/util/resources/LocaleNames.properties ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Locale/LocaleTest.java ! test/sun/text/resources/LocaleData Changeset: f650e6e22c16 Author: malenkov Date: 2009-01-23 18:31 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f650e6e22c16 4222508: JColorChooser ignores setEnabled() function call Reviewed-by: peterz, rupashka ! src/share/classes/javax/swing/colorchooser/AbstractColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/ColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/DefaultSwatchChooserPanel.java + test/javax/swing/JColorChooser/Test4222508.html + test/javax/swing/JColorChooser/Test4222508.java Changeset: d75ae3f11e01 Author: peytoia Date: 2009-01-26 09:19 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d75ae3f11e01 6796489: (tz) Support tzdata2009a Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/backward ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: e02f2d591cd5 Author: malenkov Date: 2009-01-29 15:34 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e02f2d591cd5 6788531: java.beans.Statement imposes excessive access control Reviewed-by: peterz, rupashka ! src/share/classes/com/sun/beans/finder/MethodFinder.java ! src/share/classes/java/beans/EventHandler.java ! src/share/classes/java/beans/ReflectionUtils.java ! src/share/classes/java/beans/Statement.java + test/java/beans/EventHandler/Test6788531.java + test/java/beans/Statement/Test6788531.java Changeset: ff6633279632 Author: rupashka Date: 2009-01-29 19:06 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ff6633279632 6794836: BasicSliderUI throws NullPointerExc when JSlider maximum is Integer.MAX_VALUE Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java + test/javax/swing/JSlider/6794836/bug6794836.java Changeset: 1f6ff90d9692 Author: lana Date: 2009-01-29 09:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1f6ff90d9692 Merge - make/javax/sound/jsoundhs/FILES.gmk - make/javax/sound/jsoundhs/Makefile - make/javax/sound/jsoundhs/mapfile-vers - src/share/classes/com/sun/beans/ObjectHandler.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/share/classes/javax/swing/plaf/synth/SynthParser.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java - src/share/lib/audio/soundbank.gm Changeset: 4b03e27a4409 Author: lana Date: 2009-02-03 22:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4b03e27a4409 Merge - make/javax/sound/jsoundhs/FILES.gmk - make/javax/sound/jsoundhs/Makefile - make/javax/sound/jsoundhs/mapfile-vers - src/share/classes/com/sun/beans/ObjectHandler.java - src/share/lib/audio/soundbank.gm Changeset: b4ac413b1f12 Author: xdono Date: 2009-02-05 16:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b4ac413b1f12 Added tag jdk7-b46 for changeset 4b03e27a4409 ! .hgtags From john.coomes at sun.com Fri Feb 6 11:36:48 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 06 Feb 2009 19:36:48 +0000 Subject: hg: jdk7/hotspot/langtools: 16 new changesets Message-ID: <20090206193715.08A52D003@hg.openjdk.java.net> Changeset: d79ad96ce47c Author: bpatel Date: 2009-01-15 17:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/d79ad96ce47c 6786682: Javadoc HTML WCAG 2.0 accessibility issues in standard doclet - HTML tag should have lang attribute Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java + test/com/sun/javadoc/testHtmlTag/TestHtmlTag.java + test/com/sun/javadoc/testHtmlTag/pkg1/C1.java + test/com/sun/javadoc/testHtmlTag/pkg2/C2.java Changeset: 42f9d392159d Author: jjg Date: 2009-01-15 18:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/42f9d392159d 6794520: MessageRetriever should be upgraded to use varargs Object... Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MessageRetriever.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java Changeset: 18c433be7aa7 Author: darcy Date: 2009-01-16 14:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/18c433be7aa7 6583626: Improve serialization support in javax.lang.model.type exception classes Reviewed-by: jjg ! src/share/classes/javax/lang/model/type/MirroredTypeException.java ! src/share/classes/javax/lang/model/type/MirroredTypesException.java Changeset: d0b33fe8e710 Author: jjg Date: 2009-01-19 19:36 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/d0b33fe8e710 6794959: add new switch -XDexpectKeys=key,key.... Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/util/Log.java + test/tools/javac/T6794959.java Changeset: 83c59a9d4b94 Author: mcimadamore Date: 2009-01-20 17:49 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/83c59a9d4b94 6795580: parser confused by square brackets in qualified generic cast Summary: Parser rejects cast with qualified generic array types Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/cast/6795580/T6795580.java + test/tools/javac/cast/6795580/T6795580.out Changeset: 1ca2dc8584e1 Author: mcimadamore Date: 2009-01-20 17:49 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/1ca2dc8584e1 6557199: Fails to reject bad override of generic method Summary: Javac does not correctly implement JLS3 8.4.5 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/rawOverride/6557199/T6557199.java + test/tools/javac/generics/rawOverride/6557199/T6557199.out Changeset: 1bf037016426 Author: jjg Date: 2009-01-20 15:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/1bf037016426 6794582: javadoc should read files using a FileManager Reviewed-by: darcy, bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java ! src/share/classes/com/sun/tools/javadoc/SourcePositionImpl.java Changeset: b4b1f7732289 Author: jjg Date: 2009-01-20 18:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/b4b1f7732289 6795903: fix latent build warnings in langtools repository Reviewed-by: darcy ! make/build.properties ! src/share/classes/com/sun/tools/apt/comp/AnnotationProcessingError.java ! src/share/classes/com/sun/tools/apt/comp/Apt.java ! src/share/classes/com/sun/tools/apt/comp/UsageMessageNeededException.java ! src/share/classes/com/sun/tools/apt/main/JavaCompiler.java ! src/share/classes/com/sun/tools/apt/mirror/apt/RoundCompleteEventImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/apt/mirror/type/TypeVariableImpl.java ! src/share/classes/com/sun/tools/classfile/Annotation.java ! src/share/classes/com/sun/tools/classfile/AttributeException.java ! src/share/classes/com/sun/tools/classfile/Code_attribute.java ! src/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/share/classes/com/sun/tools/classfile/ConstantPoolException.java ! src/share/classes/com/sun/tools/classfile/Descriptor.java ! src/share/classes/com/sun/tools/classfile/DescriptorException.java ! src/share/classes/com/sun/tools/classfile/StackMapTable_attribute.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletAbortException.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/Comment.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javah/Gen.java ! src/share/classes/com/sun/tools/javap/InternalError.java ! src/share/classes/sun/tools/javap/JavapPrinter.java Changeset: d486ac6389d7 Author: jjg Date: 2009-01-21 08:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/d486ac6389d7 6795030: Files in langtools build can be compiled ignoring java.home settings Reviewed-by: mcimadamore ! make/build.xml Changeset: e6dafbf35355 Author: jjg Date: 2009-01-22 15:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/e6dafbf35355 6796965: dev-time wrapper script for javac broken Reviewed-by: ksrini ! make/build.xml Changeset: e3930187199c Author: jjg Date: 2009-01-23 11:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/e3930187199c 6795365: NetBeans projects in langtools repository are not NB6.5-friendly Reviewed-by: mcimadamore ! make/README ! make/build.xml ! make/netbeans/README - make/netbeans/apt/README - make/netbeans/apt/build.xml - make/netbeans/apt/nbproject/project.xml - make/netbeans/common/shared.xml - make/netbeans/common/standard-context-menu-items-no-javadoc.ent - make/netbeans/common/standard-context-menu-items.ent - make/netbeans/common/standard-ide-actions-no-javadoc.ent - make/netbeans/common/standard-ide-actions.ent - make/netbeans/compiler/README - make/netbeans/compiler/build.xml - make/netbeans/compiler/nbproject/project.xml - make/netbeans/doclets/README - make/netbeans/doclets/build.xml - make/netbeans/doclets/nbproject/project.xml - make/netbeans/javadoc/README - make/netbeans/javadoc/build.xml - make/netbeans/javadoc/nbproject/project.xml - make/netbeans/javah/README - make/netbeans/javah/build.xml - make/netbeans/javah/nbproject/project.xml - make/netbeans/javap/README - make/netbeans/javap/build.xml - make/netbeans/javap/nbproject/project.xml + make/netbeans/langtools/build.xml + make/netbeans/langtools/nbproject/project.xml + make/netbeans/langtools/nbproject/standard-context-menu-items.ent + make/netbeans/langtools/nbproject/standard-ide-actions.ent + make/tools/SelectTool/SelectToolTask.java Changeset: 3b2c55b7bd01 Author: tbell Date: 2009-01-24 11:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/3b2c55b7bd01 6797463: 6557199 breaks the jax-ws workspace Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java Changeset: 40fd14d94c3c Author: tbell Date: 2009-01-24 16:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/40fd14d94c3c Merge - make/netbeans/apt/README - make/netbeans/apt/build.xml - make/netbeans/apt/nbproject/project.xml - make/netbeans/common/shared.xml - make/netbeans/common/standard-context-menu-items-no-javadoc.ent - make/netbeans/common/standard-context-menu-items.ent - make/netbeans/common/standard-ide-actions-no-javadoc.ent - make/netbeans/common/standard-ide-actions.ent - make/netbeans/compiler/README - make/netbeans/compiler/build.xml - make/netbeans/compiler/nbproject/project.xml - make/netbeans/doclets/README - make/netbeans/doclets/build.xml - make/netbeans/doclets/nbproject/project.xml - make/netbeans/javadoc/README - make/netbeans/javadoc/build.xml - make/netbeans/javadoc/nbproject/project.xml - make/netbeans/javah/README - make/netbeans/javah/build.xml - make/netbeans/javah/nbproject/project.xml - make/netbeans/javap/README - make/netbeans/javap/build.xml - make/netbeans/javap/nbproject/project.xml Changeset: 0f922ff6968f Author: tbell Date: 2009-01-26 15:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/0f922ff6968f 6797871: Fix for 6797463 did not remove the jtreg tests, and it should have Reviewed-by: jjg - test/tools/javac/generics/rawOverride/6557199/T6557199.java - test/tools/javac/generics/rawOverride/6557199/T6557199.out Changeset: be546a6c08e3 Author: tbell Date: 2009-01-29 21:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/be546a6c08e3 Merge Changeset: 2b8f6bab2392 Author: xdono Date: 2009-02-05 16:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/2b8f6bab2392 Added tag jdk7-b46 for changeset be546a6c08e3 ! .hgtags From dawn2004 at gmail.com Fri Feb 6 13:19:28 2009 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Fri, 6 Feb 2009 13:19:28 -0800 (PST) Subject: Question about MemoryService class. Message-ID: <21880830.post@talk.nabble.com> Hi, guys. Could you give me some information about MemoryService in hotspot. It seems like a tool to monitor the memory usage, right? But it only support 2 generations. I wanna divide the heap into three generations, so it gives me error information. Can I turn it off? Will it cause problems if I turn it off. How can I turn it off without side effect? Thanks a lot! Colin(Du Li) -- View this message in context: http://www.nabble.com/Question-about-MemoryService-class.-tp21880830p21880830.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From Thomas.Rodriguez at Sun.COM Fri Feb 6 14:07:48 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 06 Feb 2009 14:07:48 -0800 Subject: Question about MemoryService class. In-Reply-To: <21880830.post@talk.nabble.com> References: <21880830.post@talk.nabble.com> Message-ID: Can't you just fix MemoryService to handle more than 2 generations? It doesn't look that complicated. tom On Feb 6, 2009, at 1:19 PM, Colin(Du Li) wrote: > > Hi, guys. > > Could you give me some information about MemoryService in hotspot. > It seems > like a tool to monitor the memory usage, right? But it only support 2 > generations. I wanna divide the heap into three generations, so it > gives me > error information. Can I turn it off? Will it cause problems if I > turn it > off. How can I turn it off without side effect? > Thanks a lot! > > Colin(Du Li) > -- > View this message in context: http://www.nabble.com/Question-about-MemoryService-class.-tp21880830p21880830.html > Sent from the OpenJDK Hotspot Virtual Machine mailing list archive > at Nabble.com. > From Mandy.Chung at Sun.COM Fri Feb 6 14:15:08 2009 From: Mandy.Chung at Sun.COM (Mandy Chung) Date: Fri, 06 Feb 2009 14:15:08 -0800 Subject: Question about MemoryService class. In-Reply-To: <21880830.post@talk.nabble.com> References: <21880830.post@talk.nabble.com> Message-ID: <498CB66C.7040604@sun.com> Colin(Du Li) wrote: >Hi, guys. > >Could you give me some information about MemoryService in hotspot. It seems >like a tool to monitor the memory usage, right? But it only support 2 >generations. I wanna divide the heap into three generations, so it gives me >error information. Can I turn it off? Will it cause problems if I turn it >off. How can I turn it off without side effect? > > The memoryService and memory pool implementation is the VM support for the java.lang.management API. You need to change the current implementation to support 3 generations. The memory pool/service implementation is not limited to 2 generations. Mandy >Thanks a lot! > >Colin(Du Li) > > From dawn2004 at gmail.com Sat Feb 7 11:07:55 2009 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Sat, 7 Feb 2009 11:07:55 -0800 (PST) Subject: Question about MemoryService class. In-Reply-To: <498CB66C.7040604@sun.com> References: <21880830.post@talk.nabble.com> <498CB66C.7040604@sun.com> Message-ID: <21891770.post@talk.nabble.com> Thanks a lot? I have fixed it. To constrain the two-generation collector makes the system less extensible. I wonder this part will be improve the the future. mandy.chung wrote: > > Colin(Du Li) wrote: > >>Hi, guys. >> >>Could you give me some information about MemoryService in hotspot. It seems >>like a tool to monitor the memory usage, right? But it only support 2 >>generations. I wanna divide the heap into three generations, so it gives me >>error information. Can I turn it off? Will it cause problems if I turn it >>off. How can I turn it off without side effect? >> >> > The memoryService and memory pool implementation is the VM support for > the java.lang.management API. > > You need to change the current implementation to support 3 generations. > The memory pool/service implementation is not limited to 2 generations. > > Mandy > >>Thanks a lot! >> >>Colin(Du Li) >> >> > > > -- View this message in context: http://www.nabble.com/Question-about-MemoryService-class.-tp21880830p21891770.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From Y.S.Ramakrishna at Sun.COM Sat Feb 7 13:09:19 2009 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Sat, 07 Feb 2009 13:09:19 -0800 Subject: Question about MemoryService class. In-Reply-To: <21891770.post@talk.nabble.com> References: <21880830.post@talk.nabble.com> <498CB66C.7040604@sun.com> <21891770.post@talk.nabble.com> Message-ID: <6c00d5ea3009.498d87ff@sun.com> Hi Colin -- If you have a use case where 3 or more generations will provide distinct advantages, please feel free to propose an OpenJDK project for this and we'll be happy to help you navigate around in the relevant parts of the source code so you can get this done. The basic functionality will likely be quite straightforward, if tedious in some of the details, and in limiting the performance impact upon the basic 2 generation system. -- ramki ----- Original Message ----- From: "Colin(Du Li)" Date: Saturday, February 7, 2009 11:08 am Subject: Re: Question about MemoryService class. To: hotspot-dev at openjdk.java.net > Thanks a lot? > I have fixed it. > To constrain the two-generation collector makes the system less extensible. > I wonder this part will be improve the the future. > > > mandy.chung wrote: > > > > Colin(Du Li) wrote: > > > >>Hi, guys. > >> > >>Could you give me some information about MemoryService in hotspot. It > seems > >>like a tool to monitor the memory usage, right? But it only support > 2 > >>generations. I wanna divide the heap into three generations, so it gives > me > >>error information. Can I turn it off? Will it cause problems if I > turn it > >>off. How can I turn it off without side effect? > >> > >> > > The memoryService and memory pool implementation is the VM support > for > > the java.lang.management API. > > > > You need to change the current implementation to support 3 > generations. > > The memory pool/service implementation is not limited to 2 generations. > > > > Mandy > > > >>Thanks a lot! > >> > >>Colin(Du Li) > >> > >> > > > > > > > > -- > View this message in context: http://www.nabble.com/Question-about-MemoryService-class.-tp21880830p21891770.html > Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at > Nabble.com. > From Y.S.Ramakrishna at Sun.COM Sat Feb 7 13:17:07 2009 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Sat, 07 Feb 2009 13:17:07 -0800 Subject: Question about MemoryService class. In-Reply-To: <6c00d5ea3009.498d87ff@sun.com> References: <21880830.post@talk.nabble.com> <498CB66C.7040604@sun.com> <21891770.post@talk.nabble.com> <6c00d5ea3009.498d87ff@sun.com> Message-ID: <6de091e77f96.498d89d3@sun.com> of course, G1 and the possibilities/flexibility it allows probably makes something like this somewhat moot (at least as far as my intuition goes here). -- ramki ----- Original Message ----- From: Y Srinivas Ramakrishna Date: Saturday, February 7, 2009 1:09 pm Subject: Re: Question about MemoryService class. To: "Colin(Du Li)" Cc: hotspot-dev at openjdk.java.net > Hi Colin -- > > If you have a use case where 3 or more generations will > provide distinct advantages, please feel free to > propose an OpenJDK project for this and we'll be > happy to help you navigate around in the relevant parts of > the source code so you can get this done. The basic > functionality will likely be quite straightforward, > if tedious in some of the details, and in limiting > the performance impact upon the basic 2 generation system. > > -- ramki > > ----- Original Message ----- > From: "Colin(Du Li)" > Date: Saturday, February 7, 2009 11:08 am > Subject: Re: Question about MemoryService class. > To: hotspot-dev at openjdk.java.net > > > > Thanks a lot? > > I have fixed it. > > To constrain the two-generation collector makes the system less extensible. > > I wonder this part will be improve the the future. > > > > > > mandy.chung wrote: > > > > > > Colin(Du Li) wrote: > > > > > >>Hi, guys. > > >> > > >>Could you give me some information about MemoryService in hotspot. > It > > seems > > >>like a tool to monitor the memory usage, right? But it only > support > > 2 > > >>generations. I wanna divide the heap into three generations, so it > gives > > me > > >>error information. Can I turn it off? Will it cause problems if I > > > turn it > > >>off. How can I turn it off without side effect? > > >> > > >> > > > The memoryService and memory pool implementation is the VM support > > > for > > > the java.lang.management API. > > > > > > You need to change the current implementation to support 3 > > generations. > > > The memory pool/service implementation is not limited to 2 generations. > > > > > > Mandy > > > > > >>Thanks a lot! > > >> > > >>Colin(Du Li) > > >> > > >> > > > > > > > > > > > > > -- > > View this message in context: http://www.nabble.com/Question-about-MemoryService-class.-tp21880830p21891770.html > > Sent from the OpenJDK Hotspot Virtual Machine mailing list archive > at > > Nabble.com. > > From dawn2004 at gmail.com Sat Feb 7 13:23:25 2009 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Sat, 7 Feb 2009 13:23:25 -0800 (PST) Subject: Question about MemoryService class. In-Reply-To: <6de091e77f96.498d89d3@sun.com> References: <21880830.post@talk.nabble.com> <498CB66C.7040604@sun.com> <21891770.post@talk.nabble.com> <6c00d5ea3009.498d87ff@sun.com> <6de091e77f96.498d89d3@sun.com> Message-ID: <21892968.post@talk.nabble.com> Hi, ramki, Thanks you for your reply. Does G1 mean the "generation 1" in generational GC? Why do you think it might be moot? I wonder if you can give more explanations. Thanks. Colin. y.s.ramakrishna wrote: > > > of course, G1 and the possibilities/flexibility it allows > probably makes something like this somewhat moot (at least as > far as my intuition goes here). > > -- ramki > > ----- Original Message ----- > From: Y Srinivas Ramakrishna > Date: Saturday, February 7, 2009 1:09 pm > Subject: Re: Question about MemoryService class. > To: "Colin(Du Li)" > Cc: hotspot-dev at openjdk.java.net > > >> Hi Colin -- >> >> If you have a use case where 3 or more generations will >> provide distinct advantages, please feel free to >> propose an OpenJDK project for this and we'll be >> happy to help you navigate around in the relevant parts of >> the source code so you can get this done. The basic >> functionality will likely be quite straightforward, >> if tedious in some of the details, and in limiting >> the performance impact upon the basic 2 generation system. >> >> -- ramki >> >> ----- Original Message ----- >> From: "Colin(Du Li)" >> Date: Saturday, February 7, 2009 11:08 am >> Subject: Re: Question about MemoryService class. >> To: hotspot-dev at openjdk.java.net >> >> >> > Thanks a lot? >> > I have fixed it. >> > To constrain the two-generation collector makes the system less >> extensible. >> > I wonder this part will be improve the the future. >> > >> > >> > mandy.chung wrote: >> > > >> > > Colin(Du Li) wrote: >> > > >> > >>Hi, guys. >> > >> >> > >>Could you give me some information about MemoryService in hotspot. >> It >> > seems >> > >>like a tool to monitor the memory usage, right? But it only >> support >> > 2 >> > >>generations. I wanna divide the heap into three generations, so it >> gives >> > me >> > >>error information. Can I turn it off? Will it cause problems if I >> >> > turn it >> > >>off. How can I turn it off without side effect? >> > >> >> > >> >> > > The memoryService and memory pool implementation is the VM support >> >> > for >> > > the java.lang.management API. >> > > >> > > You need to change the current implementation to support 3 >> > generations. >> > > The memory pool/service implementation is not limited to 2 >> generations. >> > > >> > > Mandy >> > > >> > >>Thanks a lot! >> > >> >> > >>Colin(Du Li) >> > >> >> > >> >> > > >> > > >> > > >> > >> > -- >> > View this message in context: >> http://www.nabble.com/Question-about-MemoryService-class.-tp21880830p21891770.html >> > Sent from the OpenJDK Hotspot Virtual Machine mailing list archive >> at >> > Nabble.com. >> > > > -- View this message in context: http://www.nabble.com/Question-about-MemoryService-class.-tp21880830p21892968.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From Tomas.Hurka at Sun.COM Sun Feb 8 01:24:04 2009 From: Tomas.Hurka at Sun.COM (Tomas Hurka) Date: Sun, 08 Feb 2009 10:24:04 +0100 Subject: Question about MemoryService class. In-Reply-To: <21892968.post@talk.nabble.com> References: <21880830.post@talk.nabble.com> <498CB66C.7040604@sun.com> <21891770.post@talk.nabble.com> <6c00d5ea3009.498d87ff@sun.com> <6de091e77f96.498d89d3@sun.com> <21892968.post@talk.nabble.com> Message-ID: Hi Colin, On 7 Feb 2009, at 22:23, Colin(Du Li) wrote: > > Thanks you for your reply. > Does G1 mean the "generation 1" in generational GC? G1 is a short name for Garbage-First garbage collector developed by HotSpot team. For more details see Bye, -- Tomas Hurka NetBeans Profiler http://profiler.netbeans.org VisualVM http://visualvm.dev.java.net Software Engineer, Developer Platforms Group Sun Microsystems, Praha Czech Republic From Y.S.Ramakrishna at Sun.COM Sat Feb 7 16:11:17 2009 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Sat, 07 Feb 2009 16:11:17 -0800 Subject: Question about MemoryService class. In-Reply-To: <21892968.post@talk.nabble.com> References: <21880830.post@talk.nabble.com> <498CB66C.7040604@sun.com> <21891770.post@talk.nabble.com> <6c00d5ea3009.498d87ff@sun.com> <6de091e77f96.498d89d3@sun.com> <21892968.post@talk.nabble.com> Message-ID: <7240ee4e6734.498db2a5@sun.com> [I am cross-posting on to the hotspot-gc-dev list, since that's likely where this discussion belongs; i'll bcc the hotspot-dev list on this response, so interested folk can follow the discussion on the former list.] Sorry about the cryptic note. G1 is short-hand (within HotSpot circles) of the "Garbage-First Garbage Collector" which was checked into the open jdk repos a few months ago. For related background, see:- http://portal.acm.org/citation.cfm?id=1029879 @inproceedings{1029879, author = {Detlefs,, David and Flood,, Christine and Heller,, Steve and Printezis,, Tony}, title = {Garbage-first garbage collection}, booktitle = {ISMM '04: Proceedings of the 4th international symposium on Memory management}, year = {2004}, isbn = {1-58113-945-4}, pages = {37--48}, location = {Vancouver, BC, Canada}, doi = {http://doi.acm.org/10.1145/1029873.1029879}, publisher = {ACM}, address = {New York, NY, USA}, } I am thinking that the latitude allowed by the basic collection set mechanism and the ability to collect an arbitrary collection set at specific points, should, in principle, allow a range of policies for the choice of specific collection sets at specific times, allowing one to simulate, in effect, an arbitrary n-generation system by means of segregating objects into collection sets by age. Much handwaving here; and, as usual, the devil's in the details... so consider this loud thinking about possible approaches, rather than concrete direction. over and out. -- ramki ----- Original Message ----- From: "Colin(Du Li)" Date: Saturday, February 7, 2009 1:25 pm Subject: Re: Question about MemoryService class. To: hotspot-dev at openjdk.java.net > Hi, ramki, > > Thanks you for your reply. > Does G1 mean the "generation 1" in generational GC? > Why do you think it might be moot? I wonder if you can give more > explanations. > Thanks. > > Colin. > > y.s.ramakrishna wrote: > > > > > > of course, G1 and the possibilities/flexibility it allows > > probably makes something like this somewhat moot (at least as > > far as my intuition goes here). > > > > -- ramki > > > > ----- Original Message ----- > > From: Y Srinivas Ramakrishna > > Date: Saturday, February 7, 2009 1:09 pm > > Subject: Re: Question about MemoryService class. > > To: "Colin(Du Li)" > > Cc: hotspot-dev at openjdk.java.net > > > > > >> Hi Colin -- > >> > >> If you have a use case where 3 or more generations will > >> provide distinct advantages, please feel free to > >> propose an OpenJDK project for this and we'll be > >> happy to help you navigate around in the relevant parts of > >> the source code so you can get this done. The basic > >> functionality will likely be quite straightforward, > >> if tedious in some of the details, and in limiting > >> the performance impact upon the basic 2 generation system. > >> > >> -- ramki > >> > >> ----- Original Message ----- > >> From: "Colin(Du Li)" > >> Date: Saturday, February 7, 2009 11:08 am > >> Subject: Re: Question about MemoryService class. > >> To: hotspot-dev at openjdk.java.net > >> > >> > >> > Thanks a lot? > >> > I have fixed it. > >> > To constrain the two-generation collector makes the system less > >> extensible. > >> > I wonder this part will be improve the the future. > >> > > >> > > >> > mandy.chung wrote: > >> > > > >> > > Colin(Du Li) wrote: > >> > > > >> > >>Hi, guys. > >> > >> > >> > >>Could you give me some information about MemoryService in > hotspot. > >> It > >> > seems > >> > >>like a tool to monitor the memory usage, right? But it only > >> support > >> > 2 > >> > >>generations. I wanna divide the heap into three generations, so > it > >> gives > >> > me > >> > >>error information. Can I turn it off? Will it cause problems if > I > >> > >> > turn it > >> > >>off. How can I turn it off without side effect? > >> > >> > >> > >> > >> > > The memoryService and memory pool implementation is the VM > support > >> > >> > for > >> > > the java.lang.management API. > >> > > > >> > > You need to change the current implementation to support 3 > >> > generations. > >> > > The memory pool/service implementation is not limited to 2 > >> generations. > >> > > > >> > > Mandy > >> > > > >> > >>Thanks a lot! > >> > >> > >> > >>Colin(Du Li) > >> > >> > >> > >> > >> > > > >> > > > >> > > > >> > > >> > -- > >> > View this message in context: > >> http://www.nabble.com/Question-about-MemoryService-class.-tp21880830p21891770.html > >> > Sent from the OpenJDK Hotspot Virtual Machine mailing list > archive > >> at > >> > Nabble.com. > >> > > > > > > > -- > View this message in context: http://www.nabble.com/Question-about-MemoryService-class.-tp21880830p21892968.html > Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at > Nabble.com. > From imdupeng at gmail.com Mon Feb 9 10:57:24 2009 From: imdupeng at gmail.com (Peng Du) Date: Mon, 9 Feb 2009 12:57:24 -0600 Subject: Valgrind problems on Hotspot Message-ID: Hello, guys Recently, I tried to use Valgrind --tool=lackey to do some analysis on Hotspot. However, I ran into some troubles. It seems nothing can be printed out except the startup messages listed below. But I am sure the instrumentation code was indeed executed up to some point (not sure where). ==9919== Lackey, an example Valgrind tool. ==9919== Copyright (C) 2002-2008, and GNU GPL'd, by Nicholas Nethercote. ==9919== Using LibVEX rev 1878, a library for dynamic binary translation. ==9919== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. ==9919== Using valgrind-3.4.0, a dynamic binary instrumentation framework. ==9919== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. ==9919== For more details, rerun with: -v ==9919== ==9919== My PID = 9919, parent PID = 9916. Prog and args are: ==9919== /work/openjdk7/openjdk-dev/j2sdk-image/java ==9919== -XX:+UseParallelOldGC ==9919== -Xms256m ==9919== -Xmx256m ==9919== spec.jbb.JBBmain ==9919== -propfile ==9919== SPECjbb.props Which means the finalization function "static void lk_fini(Int exitcode)" of valgrind (lackey), which prints out the result, can't be invoked. However, if I use the "gamma' launcher on "Hello World" program, I could get the results printed out properly. That being said, only "Hello World" program. If I ran programs like SPEC JBB, it was inhibitively slow such that, from my point of view, it almost "hanged". Therefore, the problem with "gamma" is I can't get meaningful results out of REAL applications. By the way, when using the official SPEC JBB, Hotspot will crash on "JVM_handle_linux_signal(int sig, siginfo_t* info, void* ucVoid, int abort_if_unrecognized)" in os_linux_x86.cpp (351). It turned out, to verify the validity of the JVM, JBB deliberately does a Divide-by-Zero exception test, which is supposed to be handled by the JVM. So, I commented out the PepTest code and the JBB can be run under my Hotspot. However, under the same circumstance, my local SUN JDK v6u11 did not crash on the check. Don't know why. >From somewhere, I learned that the "java" launcher uses "execv()", whereas "gamma" does not. Is "execv()" the one that makes Valgrind not happy? How can I work around this issue? What causes the significant slow down of gamma comparing to java launcher? ps. lackey is a simple program instrumentation tool in valgrind. Nonetheless, same problems exist with more sophisticated tools, like Memcheck, etc. Thanks! Peng Du Feb 9, 2009 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090209/77912b5a/attachment.html From njriley at uiuc.edu Mon Feb 9 11:01:22 2009 From: njriley at uiuc.edu (Nicholas Riley) Date: Mon, 09 Feb 2009 13:01:22 -0600 Subject: Valgrind problems on Hotspot References: Message-ID: In article , Peng Du wrote: > >From somewhere, I learned that the "java" launcher uses "execv()", whereas > "gamma" does not. Is "execv()" the one that makes Valgrind not happy? How > can I work around this issue? What causes the significant slow down of gamma > comparing to java launcher? You're actually instrumenting the Java VM when you use gamma, rather than just the launcher. You should be able to use --trace-children=yes on Valgrind with java, if you wish. -- Nicholas Riley From imdupeng at gmail.com Mon Feb 9 11:11:26 2009 From: imdupeng at gmail.com (Peng Du) Date: Mon, 9 Feb 2009 13:11:26 -0600 Subject: Valgrind problems on Hotspot In-Reply-To: References: Message-ID: Thank you for pointing out the --trace-children option, Nicholas! Then, like gamma, it too becomes really slow. Is there any way to improve the speed? Thanks On Mon, Feb 9, 2009 at 1:01 PM, Nicholas Riley wrote: > In article , > Peng Du wrote: > > > >From somewhere, I learned that the "java" launcher uses "execv()", > whereas > > "gamma" does not. Is "execv()" the one that makes Valgrind not happy? How > > can I work around this issue? What causes the significant slow down of > gamma > > comparing to java launcher? > > You're actually instrumenting the Java VM when you use gamma, rather > than just the launcher. You should be able to use --trace-children=yes > on Valgrind with java, if you wish. > -- > Nicholas Riley > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090209/4887e59b/attachment.html From njriley at uiuc.edu Mon Feb 9 12:21:01 2009 From: njriley at uiuc.edu (Nicholas Riley) Date: Mon, 09 Feb 2009 14:21:01 -0600 Subject: Valgrind problems on Hotspot References: Message-ID: In article , Peng Du wrote: > Thank you for pointing out the --trace-children option, Nicholas! > > Then, like gamma, it too becomes really slow. Is there any way to improve > the speed? Do less? :-) If you're running a benchmark you can try to reduce the size. I don't use Valgrind but do use Pin with HotSpot and it's manageable if you keep the code size down. -- Nicholas Riley From imdupeng at gmail.com Mon Feb 9 21:31:31 2009 From: imdupeng at gmail.com (Peng Du) Date: Mon, 9 Feb 2009 23:31:31 -0600 Subject: Valgrind problems on Hotspot In-Reply-To: References: Message-ID: Hi, Nicholas Just tried out Pin. It seemed to be even slower than Valgrind. Besides, if I am not wrong, Pin is closed source. However, its API is much cleaner and easier than Valgrind I think. Thanks! Peng Du On Mon, Feb 9, 2009 at 2:21 PM, Nicholas Riley wrote: > In article , > Peng Du wrote: > > > Thank you for pointing out the --trace-children option, Nicholas! > > > > Then, like gamma, it too becomes really slow. Is there any way to improve > > the speed? > > Do less? :-) If you're running a benchmark you can try to reduce the > size. I don't use Valgrind but do use Pin with HotSpot and it's > manageable if you keep the code size down. > -- > Nicholas Riley > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090209/f0f950c8/attachment.html From groundskeeperwiley at yahoo.com Tue Feb 10 16:26:12 2009 From: groundskeeperwiley at yahoo.com (James Walsh) Date: Tue, 10 Feb 2009 16:26:12 -0800 (PST) Subject: Superword - Aligning arrays In-Reply-To: <833EE0B7-3090-4635-B3B8-48BB98796F2E@Sun.COM> References: <90121.96359.qm@web30002.mail.mud.yahoo.com> <15917.77377.qm@web30004.mail.mud.yahoo.com> <3047CC55-F9D2-460E-AA14-D99290C9BB0E@Sun.COM> <105522.89208.qm@web30004.mail.mud.yahoo.com> <0026A698-DC8F-44BC-97C4-77F2419F9330@Sun.COM> <873610.44048.qm@web30008.mail.mud.yahoo.com> <89FDB0BB-DE27-4C60-850F-156A29C43D0D@Sun.COM> <481420.74580.qm@web30008.mail.mud.yahoo.com> <833EE0B7-3090-4635-B3B8-48BB98796F2E@Sun.COM> Message-ID: <18224.15501.qm@web30004.mail.mud.yahoo.com> I've been using a really simple test program while working on this. I tried a test program that was a little more complex this weekend and ran into a new problem. It looks like PhaseChaitin::gather_lrg_masks is trying to use the same XMM virtual register for a Op_RegF and a Op_RegQ which causes a assert when lrg.set_num_regs(4) is called. I noticed that another virtual register was assigned Op_RegQ twice but since the registers are teh same size it didn't assert. Obviously since double and floats coexist nicely I must be missing something. I went through looking at any code that checked the size of the register via LRG::num_regs() and the bug wasn't readily apparent to me. Any idea where I should look to fix this? From John.Rose at Sun.COM Tue Feb 10 19:21:36 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 10 Feb 2009 19:21:36 -0800 Subject: Superword - Aligning arrays In-Reply-To: <18224.15501.qm@web30004.mail.mud.yahoo.com> References: <90121.96359.qm@web30002.mail.mud.yahoo.com> <15917.77377.qm@web30004.mail.mud.yahoo.com> <3047CC55-F9D2-460E-AA14-D99290C9BB0E@Sun.COM> <105522.89208.qm@web30004.mail.mud.yahoo.com> <0026A698-DC8F-44BC-97C4-77F2419F9330@Sun.COM> <873610.44048.qm@web30008.mail.mud.yahoo.com> <89FDB0BB-DE27-4C60-850F-156A29C43D0D@Sun.COM> <481420.74580.qm@web30008.mail.mud.yahoo.com> <833EE0B7-3090-4635-B3B8-48BB98796F2E@Sun.COM> <18224.15501.qm@web30004.mail.mud.yahoo.com> Message-ID: It's been a while since I lasted worked on the register allocator. My advice to you is mainly a warning: The allocator handles single 32- bit registers (of course) and is also special-cased for one additional thing, an adjacent aligned pair (even/odd) of 32-bit registers allocated as a unit. Look for names like "bound2" in the system, and for pairs of registers in various APIs. Some deep and cautious generalization may be required in order to support (let me guess) adjacent mod-4 aligned quadruples of registers allocated as unit. -- John On Feb 10, 2009, at 4:26 PM, James Walsh wrote: > I've been using a really simple test program while working on this. > I tried a test program that was a little more complex this weekend > and ran into a new problem. It looks like > PhaseChaitin::gather_lrg_masks is trying to use the same XMM virtual > register for a Op_RegF and a Op_RegQ which causes a assert when > lrg.set_num_regs(4) is called. I noticed that another virtual > register was assigned Op_RegQ twice but since the registers are teh > same size it didn't assert. Obviously since double and floats > coexist nicely I must be missing something. I went through looking > at any code that checked the size of the register via > LRG::num_regs() and the bug wasn't readily apparent to me. Any idea > where I should look to fix this? From nagy.mostafa at gmail.com Wed Feb 11 21:26:56 2009 From: nagy.mostafa at gmail.com (Nagy Mostafa) Date: Wed, 11 Feb 2009 21:26:56 -0800 Subject: C++ Interpreter on amd64 Message-ID: Hi, I just want to know if it is possible to compile openjdk with the C++ interpreter (CC_INTERP = true) on an amd64. I used to compile it successfully on a 32-bit machine but since moving to a 64-bit, it fails to compile with the following error: ... In file included from ../generated/incls/_precompiled.incl:246: /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp: In member function 'void InterpreterMacroAssembler::save_bcp()': /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp:58: error: 'interpreter_frame_bcx_offset' is not a member of 'frame' /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp: In member function 'void InterpreterMacroAssembler::restore_bcp()': /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp:63: error: 'interpreter_frame_bcx_offset' is not a member of 'frame' /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp: In member function 'void InterpreterMacroAssembler::restore_locals()': /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp:68: error: 'interpreter_frame_locals_offset' is not a member of 'frame' /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp: In member function 'void InterpreterMacroAssembler::get_method(RegisterImpl*)': /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp:74: error: 'interpreter_frame_method_offset' is not a member of 'frame' /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp: In member function 'void InterpreterMacroAssembler::empty_expression_stack()': /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp:138: error: 'interpreter_frame_monitor_block_top_offset' is not a member of 'frame' /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp:141: error: 'interpreter_frame_last_sp_offset' is not a member of 'frame' ... thanks, Nagy Mostafa UCSB From y.s.ramakrishna at sun.com Thu Feb 12 04:15:05 2009 From: y.s.ramakrishna at sun.com (y.s.ramakrishna at sun.com) Date: Thu, 12 Feb 2009 12:15:05 +0000 Subject: hg: jdk7/hotspot/hotspot: 6 new changesets Message-ID: <20090212121516.AB00FD57E@hg.openjdk.java.net> Changeset: 82a980778b92 Author: never Date: 2009-02-05 11:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/82a980778b92 6793828: G1: invariant: queues are empty when activated Reviewed-by: jrose, kvn ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/memnode.cpp Changeset: 58054a18d735 Author: apetrusenko Date: 2009-02-06 01:38 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/58054a18d735 6484959: G1: introduce survivor spaces 6797754: G1: combined bugfix Summary: Implemented a policy to control G1 survivor space parameters. Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/survRateGroup.cpp ! src/share/vm/gc_implementation/g1/survRateGroup.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/shared/ageTable.cpp ! src/share/vm/gc_implementation/shared/ageTable.hpp Changeset: 05c6d52fa7a9 Author: jmasa Date: 2009-02-08 13:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/05c6d52fa7a9 6690928: Use spinning in combination with yields for workstealing termination. Summary: Substitute a spin loop for most calls to yield() to reduce the stress on the system. Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 1e458753107d Author: apetrusenko Date: 2009-02-09 17:33 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1e458753107d 6802413: G1: G1FixedSurvivorSpaceSize should be converted into regions in calculate_survivors_policy() Reviewed-by: tonyp, jmasa ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: 773234c55e8c Author: ysr Date: 2009-02-09 12:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/773234c55e8c 6800586: -XX:+PrintGCDateStamps is using mt-unsafe localtime function Summary: replaced localtime() with localtime_r() on Solaris and Linux. Reviewed-by: apetrusenko, dholmes, jmasa ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp Changeset: fe3d7c11b4b7 Author: apetrusenko Date: 2009-02-10 18:39 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fe3d7c11b4b7 6700941: G1: allocation spec missing for some G1 classes Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/utilities/workgroup.hpp From Coleen.Phillimore at Sun.COM Thu Feb 12 07:47:04 2009 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore - Sun Microsystems) Date: Thu, 12 Feb 2009 10:47:04 -0500 Subject: C++ Interpreter on amd64 In-Reply-To: References: Message-ID: <49944478.6030101@sun.com> There should be fixes in the latest mercurial repository to build CC_INTERP=1 LP64=1 (amd64) with at least one version of gcc. There are bugs in the C++ interpreter in OSR or deoptimization that make it crash. It's not one of our supported configurations so we haven't found or fixed them yet. The function InterpreterMacroAssembler::save_bcp() isn't compiled when you make with CC_INTERP=1 so you might have something wrong with your make commands. Coleen On 02/12/09 00:26, Nagy Mostafa wrote: > Hi, > I just want to know if it is possible to compile openjdk with the C++ > interpreter (CC_INTERP = true) on an amd64. I used to compile it > successfully on a 32-bit machine but since moving to a 64-bit, it > fails to compile with the following error: > > ... > In file included from ../generated/incls/_precompiled.incl:246: > /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp: > In member function 'void InterpreterMacroAssembler::save_bcp()': > /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp:58: > error: 'interpreter_frame_bcx_offset' is not a member of 'frame' > /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp: > In member function 'void InterpreterMacroAssembler::restore_bcp()': > /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp:63: > error: 'interpreter_frame_bcx_offset' is not a member of 'frame' > /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp: > In member function 'void InterpreterMacroAssembler::restore_locals()': > /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp:68: > error: 'interpreter_frame_locals_offset' is not a member of 'frame' > /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp: > In member function 'void > InterpreterMacroAssembler::get_method(RegisterImpl*)': > /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp:74: > error: 'interpreter_frame_method_offset' is not a member of 'frame' > /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp: > In member function 'void > InterpreterMacroAssembler::empty_expression_stack()': > /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp:138: > error: 'interpreter_frame_monitor_block_top_offset' is not a member of > 'frame' > /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp:141: > error: 'interpreter_frame_last_sp_offset' is not a member of 'frame' > ... > > thanks, > Nagy Mostafa > UCSB > From Christian.Thalinger at Sun.COM Thu Feb 12 07:56:24 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 12 Feb 2009 16:56:24 +0100 Subject: C++ Interpreter on amd64 In-Reply-To: <49944478.6030101@sun.com> References: <49944478.6030101@sun.com> Message-ID: <1234454184.24951.330.camel@localhost.localdomain> On Thu, 2009-02-12 at 10:47 -0500, Coleen Phillimore - Sun Microsystems wrote: > There should be fixes in the latest mercurial repository to build > CC_INTERP=1 LP64=1 (amd64) with at least one version of gcc. There are > bugs in the C++ interpreter in OSR or deoptimization that make it > crash. It's not one of our supported configurations so we haven't found > or fixed them yet. Are there still some patches in IcedTea that are not upstream yet? -- Christian From Coleen.Phillimore at Sun.COM Thu Feb 12 08:13:50 2009 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore - Sun Microsystems) Date: Thu, 12 Feb 2009 11:13:50 -0500 Subject: C++ Interpreter on amd64 In-Reply-To: <1234454184.24951.330.camel@localhost.localdomain> References: <49944478.6030101@sun.com> <1234454184.24951.330.camel@localhost.localdomain> Message-ID: <49944ABE.6060908@sun.com> I didn't have the latest IceTea patches when I got this to compile. The gcc version was 4.1.3. Maybe they want to wait a week for the next set of patches for whatever version of gcc or configuration that they're using. It should compile and the errors that they saw did not match the current sources. After compiling though, some debugging will be needed to make the C++ interpreter on x86 not crash. Coleen On 02/12/09 10:56, Christian Thalinger wrote: > On Thu, 2009-02-12 at 10:47 -0500, Coleen Phillimore - Sun Microsystems > wrote: > >> There should be fixes in the latest mercurial repository to build >> CC_INTERP=1 LP64=1 (amd64) with at least one version of gcc. There are >> bugs in the C++ interpreter in OSR or deoptimization that make it >> crash. It's not one of our supported configurations so we haven't found >> or fixed them yet. >> > > Are there still some patches in IcedTea that are not upstream yet? > > -- Christian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090212/5b1fa745/attachment.html From volker.simonis at gmail.com Thu Feb 12 09:38:27 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 12 Feb 2009 18:38:27 +0100 Subject: C++ Interpreter on amd64 In-Reply-To: References: Message-ID: Hi, a while ago I managed to build the C++ Interpreter on 64-bit Sparc. I had to apply some patches though, and I'm not sure if all of them have been integrated into the OpenJDK, so you may want to have a look: http://weblogs.java.net/blog/simonis/archive/2007/11/template_vs_cin_1.html The SPARC patches may also give you an idea what you may have to change for x64. I would also recommand you read Gary Bensons blog (http://gbenson.net/) about Zero, his C++Interpreter port. I think you should be able to build Zero on all platforms, but I never tried it. Regards, Volker On 2/12/09, Nagy Mostafa wrote: > Hi, > I just want to know if it is possible to compile openjdk with the C++ > interpreter (CC_INTERP = true) on an amd64. I used to compile it > successfully on a 32-bit machine but since moving to a 64-bit, it > fails to compile with the following error: > > ... > In file included from ../generated/incls/_precompiled.incl:246: > /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp: > In member function 'void InterpreterMacroAssembler::save_bcp()': > /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp:58: > error: 'interpreter_frame_bcx_offset' is not a member of 'frame' > /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp: > In member function 'void InterpreterMacroAssembler::restore_bcp()': > /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp:63: > error: 'interpreter_frame_bcx_offset' is not a member of 'frame' > /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp: > In member function 'void InterpreterMacroAssembler::restore_locals()': > /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp:68: > error: 'interpreter_frame_locals_offset' is not a member of 'frame' > /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp: > In member function 'void > InterpreterMacroAssembler::get_method(RegisterImpl*)': > /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp:74: > error: 'interpreter_frame_method_offset' is not a member of 'frame' > /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp: > In member function 'void > InterpreterMacroAssembler::empty_expression_stack()': > /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp:138: > error: 'interpreter_frame_monitor_block_top_offset' is not a member of > 'frame' > /home/nagy/research/hotspot/openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.hpp:141: > error: 'interpreter_frame_last_sp_offset' is not a member of 'frame' > ... > > thanks, > > Nagy Mostafa > UCSB > From gbenson at redhat.com Fri Feb 13 02:54:53 2009 From: gbenson at redhat.com (Gary Benson) Date: Fri, 13 Feb 2009 10:54:53 +0000 Subject: C++ Interpreter on amd64 In-Reply-To: References: Message-ID: <20090213105453.GB3297@redhat.com> Volker Simonis wrote: > a while ago I managed to build the C++ Interpreter on 64-bit > Sparc. I had to apply some patches though, and I'm not sure if all > of them have been integrated into the OpenJDK, so you may want to > have a look: > http://weblogs.java.net/blog/simonis/archive/2007/11/template_vs_cin_1.html > The SPARC patches may also give you an idea what you may have to > change for x64. I think they're already in OpenJDK, at least for the latest versions of HotSpot. IcedTea with Zero wouldn't work on 64-bit without them. Cheers, Gary -- http://gbenson.net/ From john.coomes at sun.com Mon Feb 16 03:03:34 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Mon, 16 Feb 2009 11:03:34 +0000 Subject: hg: jdk7/hotspot: Added tag jdk7-b47 for changeset d7744e86dedc Message-ID: <20090216110334.25EBFD8E4@hg.openjdk.java.net> Changeset: 4ae9f4bfdb98 Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/4ae9f4bfdb98 Added tag jdk7-b47 for changeset d7744e86dedc ! .hgtags From john.coomes at sun.com Mon Feb 16 03:06:09 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Mon, 16 Feb 2009 11:06:09 +0000 Subject: hg: jdk7/hotspot/corba: Added tag jdk7-b47 for changeset 167ad0164301 Message-ID: <20090216110611.7259AD8E9@hg.openjdk.java.net> Changeset: 0be222241fd4 Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/0be222241fd4 Added tag jdk7-b47 for changeset 167ad0164301 ! .hgtags From john.coomes at sun.com Mon Feb 16 03:13:12 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Mon, 16 Feb 2009 11:13:12 +0000 Subject: hg: jdk7/hotspot/jaxp: Added tag jdk7-b47 for changeset d711ad1954b2 Message-ID: <20090216111314.72B73D8EE@hg.openjdk.java.net> Changeset: 39de90eb4822 Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/39de90eb4822 Added tag jdk7-b47 for changeset d711ad1954b2 ! .hgtags From john.coomes at sun.com Mon Feb 16 03:15:45 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Mon, 16 Feb 2009 11:15:45 +0000 Subject: hg: jdk7/hotspot/jaxws: Added tag jdk7-b47 for changeset 223011570edb Message-ID: <20090216111547.B8DB6D8F3@hg.openjdk.java.net> Changeset: 01e5dd31d0c1 Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/01e5dd31d0c1 Added tag jdk7-b47 for changeset 223011570edb ! .hgtags From john.coomes at sun.com Mon Feb 16 03:18:17 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Mon, 16 Feb 2009 11:18:17 +0000 Subject: hg: jdk7/hotspot/jdk: Added tag jdk7-b47 for changeset b4ac413b1f12 Message-ID: <20090216111846.5B193D8F8@hg.openjdk.java.net> Changeset: 2ab03c2f814b Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2ab03c2f814b Added tag jdk7-b47 for changeset b4ac413b1f12 ! .hgtags From john.coomes at sun.com Mon Feb 16 03:27:57 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Mon, 16 Feb 2009 11:27:57 +0000 Subject: hg: jdk7/hotspot/langtools: Added tag jdk7-b47 for changeset 2b8f6bab2392 Message-ID: <20090216112801.62654D903@hg.openjdk.java.net> Changeset: fedc96614330 Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/fedc96614330 Added tag jdk7-b47 for changeset 2b8f6bab2392 ! .hgtags From dawn2004 at gmail.com Mon Feb 16 08:21:04 2009 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Mon, 16 Feb 2009 08:21:04 -0800 (PST) Subject: A wield hotspot make error Message-ID: <22040391.post@talk.nabble.com> Hi, guys, Now I encounter a wield error when I make hotspot. When I make Hotspot, it will run test_gamma at the end of making process? then there is a error. But after that, if I manually run test_gamma at directory ../jvmg, there is no error. Why? Thanks a lot! Colin -- View this message in context: http://www.nabble.com/A-wield-hotspot-make-error-tp22040391p22040391.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From Christian.Thalinger at Sun.COM Mon Feb 16 08:28:09 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 16 Feb 2009 17:28:09 +0100 Subject: A wield hotspot make error In-Reply-To: <22040391.post@talk.nabble.com> References: <22040391.post@talk.nabble.com> Message-ID: <1234801689.11228.11.camel@localhost.localdomain> On Mon, 2009-02-16 at 08:21 -0800, Colin(Du Li) wrote: > Hi, guys, > > Now I encounter a wield error when I make hotspot. > When I make Hotspot, it will run test_gamma at the end of making process? > then there is a error. > But after that, if I manually run test_gamma at directory ../jvmg, there is > no error. > Why? Could you post the error? -- Christian From dawn2004 at gmail.com Mon Feb 16 13:10:14 2009 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Mon, 16 Feb 2009 13:10:14 -0800 (PST) Subject: A wield hotspot make error In-Reply-To: <1234801689.11228.11.camel@localhost.localdomain> References: <22040391.post@talk.nabble.com> <1234801689.11228.11.camel@localhost.localdomain> Message-ID: <22045945.post@talk.nabble.com> Sure. The error message follows: # # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x06357924, pid=20401, tid=3086755536 # # Java VM: OpenJDK Server VM (12.0-b01-internal-jvmg interpreted mode linux-x86) # Problematic frame: # V [libjvm.so+0x357924] The log follows: Stack: [0xbf885000,0xbf8d5000], sp=0xbf8d1d90, free space=307k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x357924] V [libjvm.so+0x50e3a9] C [libzip.so+0x2716] Java_java_util_zip_Inflater_inflateBytes+0xe6 j java.util.zip.Inflater.inflateBytes([BII)I+0 j java.util.zip.Inflater.inflate([BII)I+40 j java.util.zip.InflaterInputStream.read([BII)I+53 j java.io.DataInputStream.readFully([BII)V+34 j java.util.jar.JarFile.hasClassPathAttribute()Z+59 j java.util.jar.JavaUtilJarAccessImpl.jarFileHasClassPathAttribute(Ljava/util/jar/JarFile;)Z+1 j sun.misc.URLClassPath$JarLoader.getClassPath()[Ljava/net/URL;+33 j sun.misc.URLClassPath.getLoader(I)Lsun/misc/URLClassPath$Loader;+78 j sun.misc.URLClassPath.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+42 j java.net.URLClassLoader$1.run()Ljava/lang/Object;+26 v ~StubRoutines::call_stub V [libjvm.so+0x4fb11a] V [libjvm.so+0x6a9c57] V [libjvm.so+0x4f9f97] V [libjvm.so+0x5755bc] C [libjava.so+0x9eea] Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedExceptionAction_2Ljava_security_AccessControlContext_2+0x3a j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+0 j java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+13 j java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+43 j java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+23 j sun.misc.Launcher$AppClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+36 j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3 j java.lang.ClassLoader.loadClassInternal(Ljava/lang/String;)Ljava/lang/Class;+2 v ~StubRoutines::call_stub V [libjvm.so+0x4fb11a] V [libjvm.so+0x6a9c57] V [libjvm.so+0x4f9f97] V [libjvm.so+0x4fa232] V [libjvm.so+0x4fa311] V [libjvm.so+0x78b3be] V [libjvm.so+0x78bf2a] V [libjvm.so+0x78c7a3] V [libjvm.so+0x78c805] V [libjvm.so+0x557eff] V [libjvm.so+0x52eb67] C [gamma+0x2b22] C [gamma+0x15e0] main+0x68c C [libc.so.6+0x16390] __libc_start_main+0xe0 Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j java.util.zip.Inflater.inflateBytes([BII)I+0 j java.util.zip.Inflater.inflate([BII)I+40 j java.util.zip.InflaterInputStream.read([BII)I+53 j java.io.DataInputStream.readFully([BII)V+34 j java.util.jar.JarFile.hasClassPathAttribute()Z+59 j java.util.jar.JavaUtilJarAccessImpl.jarFileHasClassPathAttribute(Ljava/util/jar/JarFile;)Z+1 j sun.misc.URLClassPath$JarLoader.getClassPath()[Ljava/net/URL;+33 j sun.misc.URLClassPath.getLoader(I)Lsun/misc/URLClassPath$Loader;+78 j sun.misc.URLClassPath.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+42 j java.net.URLClassLoader$1.run()Ljava/lang/Object;+26 v ~StubRoutines::call_stub j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+0 j java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+13 j java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+43 j java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+23 j sun.misc.Launcher$AppClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+36 j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3 j java.lang.ClassLoader.loadClassInternal(Ljava/lang/String;)Ljava/lang/Class;+2 v ~StubRoutines::call_stub Christian.Thalinger wrote: > > On Mon, 2009-02-16 at 08:21 -0800, Colin(Du Li) wrote: >> Hi, guys, >> >> Now I encounter a wield error when I make hotspot. >> When I make Hotspot, it will run test_gamma at the end of making process? >> then there is a error. >> But after that, if I manually run test_gamma at directory ../jvmg, there >> is >> no error. >> Why? > > Could you post the error? > > -- Christian > > > -- View this message in context: http://www.nabble.com/A-wield-hotspot-make-error-tp22040391p22045945.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From dawn2004 at gmail.com Mon Feb 16 13:12:23 2009 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Mon, 16 Feb 2009 13:12:23 -0800 (PST) Subject: A wield hotspot make error In-Reply-To: <22045945.post@talk.nabble.com> References: <22040391.post@talk.nabble.com> <1234801689.11228.11.camel@localhost.localdomain> <22045945.post@talk.nabble.com> Message-ID: <22046005.post@talk.nabble.com> I know this error probably caused by some modification I made in JNI part, but I'm just wondering why it occurs when making. Colin(Du Li) wrote: > > Sure. > The error message follows: > make[3]: Leaving directory > `/home/dli/Hotspot/openjdk_b24/jdk7/build/openjdk7_full_debug/linux_i486_compiler2/jvmg' > cd linux_i486_compiler2/jvmg && ./test_gamma > java version "1.7.0" > IcedTea Runtime Environment (build 1.7.0-b21) > OpenJDK Server VM (build 12.0-b01-internal-jvmg, interpreted mode) > > # > # > # An unexpected error has been detected by Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x06357924, pid=20401, tid=3086755536 > # > # Java VM: OpenJDK Server VM (12.0-b01-internal-jvmg interpreted mode > linux-x86) > # Problematic frame: > # V [libjvm.so+0x357924] > > The log follows: > Stack: [0xbf885000,0xbf8d5000], sp=0xbf8d1d90, free space=307k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native > code) > V [libjvm.so+0x357924] > V [libjvm.so+0x50e3a9] > C [libzip.so+0x2716] Java_java_util_zip_Inflater_inflateBytes+0xe6 > j java.util.zip.Inflater.inflateBytes([BII)I+0 > j java.util.zip.Inflater.inflate([BII)I+40 > j java.util.zip.InflaterInputStream.read([BII)I+53 > j java.io.DataInputStream.readFully([BII)V+34 > j java.util.jar.JarFile.hasClassPathAttribute()Z+59 > j > java.util.jar.JavaUtilJarAccessImpl.jarFileHasClassPathAttribute(Ljava/util/jar/JarFile;)Z+1 > j sun.misc.URLClassPath$JarLoader.getClassPath()[Ljava/net/URL;+33 > j sun.misc.URLClassPath.getLoader(I)Lsun/misc/URLClassPath$Loader;+78 > j > sun.misc.URLClassPath.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+42 > j java.net.URLClassLoader$1.run()Ljava/lang/Object;+26 > v ~StubRoutines::call_stub > V [libjvm.so+0x4fb11a] > V [libjvm.so+0x6a9c57] > V [libjvm.so+0x4f9f97] > V [libjvm.so+0x5755bc] > C [libjava.so+0x9eea] > Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedExceptionAction_2Ljava_security_AccessControlContext_2+0x3a > j > java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+0 > j > java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+13 > j > java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+43 > j > java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+23 > j > sun.misc.Launcher$AppClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+36 > j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3 > j > java.lang.ClassLoader.loadClassInternal(Ljava/lang/String;)Ljava/lang/Class;+2 > v ~StubRoutines::call_stub > V [libjvm.so+0x4fb11a] > V [libjvm.so+0x6a9c57] > V [libjvm.so+0x4f9f97] > V [libjvm.so+0x4fa232] > V [libjvm.so+0x4fa311] > V [libjvm.so+0x78b3be] > V [libjvm.so+0x78bf2a] > V [libjvm.so+0x78c7a3] > V [libjvm.so+0x78c805] > V [libjvm.so+0x557eff] > V [libjvm.so+0x52eb67] > C [gamma+0x2b22] > C [gamma+0x15e0] main+0x68c > C [libc.so.6+0x16390] __libc_start_main+0xe0 > > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > j java.util.zip.Inflater.inflateBytes([BII)I+0 > j java.util.zip.Inflater.inflate([BII)I+40 > j java.util.zip.InflaterInputStream.read([BII)I+53 > j java.io.DataInputStream.readFully([BII)V+34 > j java.util.jar.JarFile.hasClassPathAttribute()Z+59 > j > java.util.jar.JavaUtilJarAccessImpl.jarFileHasClassPathAttribute(Ljava/util/jar/JarFile;)Z+1 > j sun.misc.URLClassPath$JarLoader.getClassPath()[Ljava/net/URL;+33 > j sun.misc.URLClassPath.getLoader(I)Lsun/misc/URLClassPath$Loader;+78 > j > sun.misc.URLClassPath.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+42 > j java.net.URLClassLoader$1.run()Ljava/lang/Object;+26 > v ~StubRoutines::call_stub > j > java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+0 > j > java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+13 > j > java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+43 > j > java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+23 > j > sun.misc.Launcher$AppClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+36 > j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3 > j > java.lang.ClassLoader.loadClassInternal(Ljava/lang/String;)Ljava/lang/Class;+2 > v ~StubRoutines::call_stub > > > > Christian.Thalinger wrote: >> >> On Mon, 2009-02-16 at 08:21 -0800, Colin(Du Li) wrote: >>> Hi, guys, >>> >>> Now I encounter a wield error when I make hotspot. >>> When I make Hotspot, it will run test_gamma at the end of making >>> process? >>> then there is a error. >>> But after that, if I manually run test_gamma at directory ../jvmg, there >>> is >>> no error. >>> Why? >> >> Could you post the error? >> >> -- Christian >> >> >> > > -- View this message in context: http://www.nabble.com/A-wield-hotspot-make-error-tp22040391p22046005.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From Christian.Thalinger at Sun.COM Mon Feb 16 13:12:57 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 16 Feb 2009 22:12:57 +0100 Subject: A wield hotspot make error In-Reply-To: <22045945.post@talk.nabble.com> References: <22040391.post@talk.nabble.com> <1234801689.11228.11.camel@localhost.localdomain> <22045945.post@talk.nabble.com> Message-ID: <1234818777.11228.14.camel@localhost.localdomain> On Mon, 2009-02-16 at 13:10 -0800, Colin(Du Li) wrote: > Sure. > The error message follows: > # > # An unexpected error has been detected by Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x06357924, pid=20401, tid=3086755536 > # > # Java VM: OpenJDK Server VM (12.0-b01-internal-jvmg interpreted mode > linux-x86) > # Problematic frame: > # V [libjvm.so+0x357924] What version of HotSpot (what repository) are you trying to build? -- Christian From dawn2004 at gmail.com Mon Feb 16 13:18:55 2009 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Mon, 16 Feb 2009 13:18:55 -0800 (PST) Subject: A wield hotspot make error In-Reply-To: <1234818777.11228.14.camel@localhost.localdomain> References: <22040391.post@talk.nabble.com> <1234801689.11228.11.camel@localhost.localdomain> <22045945.post@talk.nabble.com> <1234818777.11228.14.camel@localhost.localdomain> Message-ID: <22046133.post@talk.nabble.com> openjdk 12.0-b01 Christian.Thalinger wrote: > > On Mon, 2009-02-16 at 13:10 -0800, Colin(Du Li) wrote: >> Sure. >> The error message follows: >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x06357924, pid=20401, tid=3086755536 >> # >> # Java VM: OpenJDK Server VM (12.0-b01-internal-jvmg interpreted mode >> linux-x86) >> # Problematic frame: >> # V [libjvm.so+0x357924] > > What version of HotSpot (what repository) are you trying to build? > > -- Christian > > > -- View this message in context: http://www.nabble.com/A-wield-hotspot-make-error-tp22040391p22046133.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From Xiaobin.Lu at Sun.COM Mon Feb 16 13:26:36 2009 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Mon, 16 Feb 2009 13:26:36 -0800 Subject: A wield hotspot make error In-Reply-To: <22046005.post@talk.nabble.com> References: <22040391.post@talk.nabble.com> <1234801689.11228.11.camel@localhost.localdomain> <22045945.post@talk.nabble.com> <22046005.post@talk.nabble.com> Message-ID: <4999DA0C.8030706@Sun.COM> "gamma" is an internal launcher to test the VM after the build is done. It is similar to java but statically linked to libjvm.so. It locates rt.jar and other jar files from JAVA_HOME environment variable as part of the start up. And the crash you saw is occurring when VM tries to load classes out of jar files and the JDK zip code tries to call back to VM, most likely calling some JVM_XXX methods. So your JNI modification might affect the correctness of the JNI call from zip code to VM code. -Xiaobin On 02/16/09 13:12, Colin(Du Li) wrote: > I know this error probably caused by some modification I made in JNI part, > but I'm just wondering why it occurs when making. > > > Colin(Du Li) wrote: > >> Sure. >> The error message follows: >> make[3]: Leaving directory >> `/home/dli/Hotspot/openjdk_b24/jdk7/build/openjdk7_full_debug/linux_i486_compiler2/jvmg' >> cd linux_i486_compiler2/jvmg && ./test_gamma >> java version "1.7.0" >> IcedTea Runtime Environment (build 1.7.0-b21) >> OpenJDK Server VM (build 12.0-b01-internal-jvmg, interpreted mode) >> >> # >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x06357924, pid=20401, tid=3086755536 >> # >> # Java VM: OpenJDK Server VM (12.0-b01-internal-jvmg interpreted mode >> linux-x86) >> # Problematic frame: >> # V [libjvm.so+0x357924] >> >> The log follows: >> Stack: [0xbf885000,0xbf8d5000], sp=0xbf8d1d90, free space=307k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native >> code) >> V [libjvm.so+0x357924] >> V [libjvm.so+0x50e3a9] >> C [libzip.so+0x2716] Java_java_util_zip_Inflater_inflateBytes+0xe6 >> j java.util.zip.Inflater.inflateBytes([BII)I+0 >> j java.util.zip.Inflater.inflate([BII)I+40 >> j java.util.zip.InflaterInputStream.read([BII)I+53 >> j java.io.DataInputStream.readFully([BII)V+34 >> j java.util.jar.JarFile.hasClassPathAttribute()Z+59 >> j >> java.util.jar.JavaUtilJarAccessImpl.jarFileHasClassPathAttribute(Ljava/util/jar/JarFile;)Z+1 >> j sun.misc.URLClassPath$JarLoader.getClassPath()[Ljava/net/URL;+33 >> j sun.misc.URLClassPath.getLoader(I)Lsun/misc/URLClassPath$Loader;+78 >> j >> sun.misc.URLClassPath.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+42 >> j java.net.URLClassLoader$1.run()Ljava/lang/Object;+26 >> v ~StubRoutines::call_stub >> V [libjvm.so+0x4fb11a] >> V [libjvm.so+0x6a9c57] >> V [libjvm.so+0x4f9f97] >> V [libjvm.so+0x5755bc] >> C [libjava.so+0x9eea] >> Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedExceptionAction_2Ljava_security_AccessControlContext_2+0x3a >> j >> java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+0 >> j >> java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+13 >> j >> java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+43 >> j >> java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+23 >> j >> sun.misc.Launcher$AppClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+36 >> j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3 >> j >> java.lang.ClassLoader.loadClassInternal(Ljava/lang/String;)Ljava/lang/Class;+2 >> v ~StubRoutines::call_stub >> V [libjvm.so+0x4fb11a] >> V [libjvm.so+0x6a9c57] >> V [libjvm.so+0x4f9f97] >> V [libjvm.so+0x4fa232] >> V [libjvm.so+0x4fa311] >> V [libjvm.so+0x78b3be] >> V [libjvm.so+0x78bf2a] >> V [libjvm.so+0x78c7a3] >> V [libjvm.so+0x78c805] >> V [libjvm.so+0x557eff] >> V [libjvm.so+0x52eb67] >> C [gamma+0x2b22] >> C [gamma+0x15e0] main+0x68c >> C [libc.so.6+0x16390] __libc_start_main+0xe0 >> >> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) >> j java.util.zip.Inflater.inflateBytes([BII)I+0 >> j java.util.zip.Inflater.inflate([BII)I+40 >> j java.util.zip.InflaterInputStream.read([BII)I+53 >> j java.io.DataInputStream.readFully([BII)V+34 >> j java.util.jar.JarFile.hasClassPathAttribute()Z+59 >> j >> java.util.jar.JavaUtilJarAccessImpl.jarFileHasClassPathAttribute(Ljava/util/jar/JarFile;)Z+1 >> j sun.misc.URLClassPath$JarLoader.getClassPath()[Ljava/net/URL;+33 >> j sun.misc.URLClassPath.getLoader(I)Lsun/misc/URLClassPath$Loader;+78 >> j >> sun.misc.URLClassPath.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+42 >> j java.net.URLClassLoader$1.run()Ljava/lang/Object;+26 >> v ~StubRoutines::call_stub >> j >> java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+0 >> j >> java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+13 >> j >> java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+43 >> j >> java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+23 >> j >> sun.misc.Launcher$AppClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+36 >> j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3 >> j >> java.lang.ClassLoader.loadClassInternal(Ljava/lang/String;)Ljava/lang/Class;+2 >> v ~StubRoutines::call_stub >> >> >> >> Christian.Thalinger wrote: >> >>> On Mon, 2009-02-16 at 08:21 -0800, Colin(Du Li) wrote: >>> >>>> Hi, guys, >>>> >>>> Now I encounter a wield error when I make hotspot. >>>> When I make Hotspot, it will run test_gamma at the end of making >>>> process? >>>> then there is a error. >>>> But after that, if I manually run test_gamma at directory ../jvmg, there >>>> is >>>> no error. >>>> Why? >>>> >>> Could you post the error? >>> >>> -- Christian >>> >>> >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090216/c8f4341a/attachment.html From Xiaobin.Lu at Sun.COM Mon Feb 16 14:33:42 2009 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Mon, 16 Feb 2009 14:33:42 -0800 Subject: review request for 6622432 Message-ID: <4999E9C6.9000004@Sun.COM> Webrev: http://webrev.invokedynamic.info/xiaobin.lu/6622432/ 6622432: RFE: Performance improvements to java.math.BigDecimal Details: This work is targeted to improve the performance of BigDecimal and related classes. Along with the performance improvement, the implementation of many methods has been simplified or complicated for reasons described below. Before delving into details of the webrev, here is the summary of the improvement, for derby benchmark inside SPECjvm2008, we saw about 84.65% improvement measured on a 2 socket 2.8GHz, 12G RAM Nehalem machine. Similarly, we saw about 6.57% improvement on SPECjbb2005. The usage of BigDecimal is quite different for derby and SPECjbb2005, the former benchmark emphasizes more on inflated cases and the later is mostly using small numbers (i.e. non-inflated case), so we are trying our best to take care of both in the whole optimization, as a result, the optimization putting in the webrev is made as general as possible. The change is quite significant and I can only try to highlight some general ideas of the optimization. First is some background of the current implementation of BigDecimal. Among all the fields of BigDecimal classes, the two most interesting fields are intCompact which is long type and intVal which is BigInteger type. When the unscaled value of BigDecimal falls into (Long.MIN_VALUE, Long.MAX_VALUE], its intCompact field is set and intVal is set to null most of time until it is used to perform operations with another BigInteger. This is a good thing to do since it will reduce the object allocation significantly and make the operation faster since obviously adding two primitive numbers for example just needs one instruction while adding two BigInteger object requires a method call, get the magnitude array out of the object, a for loop and so on. So one of the big idea of optimization made in the webrev is to take a further step from this idea and try to make some of the hot methods aware of the non-inflated and inflated cases. For example, the constructor of BigDecimal(char[] in, int offset, int len), when the number is not inflated, we came up with some code to make the constructor as efficient as possible. Another example is the multiply(BigDecimal multiplicand) method, when one of the objects is not inflated, we came up with a internal multiply method in BigInteger to accept long parameter. The second big change to BigDecimal is its divide method. In the inflated case, the current implementation calls divide method in BigInteger which makes MutableBigInteger objects for both operators, then perform the division. Our change made to divide method directly makes MutableBigInteger object out of the magnitude array of the intVal and calls divide method directly. When we get rid of the middle man, we again can reduce the object allocation significantly when divide is a hot method. The third change to BigDecimal is the improvement of calculating the precision of a given BigDecimal object. The current implementation actually uses a static tens power array for incoming number to compare with. And when the number is inflated, it keeps dividing itself by 1 billion until it becomes very small, every division adds 9 digits to the precision. As you know, the division operation is expensive and the algorithm to compare with the ten's power array can be made more efficiently by correlating the bit length of the number with the index to the array so that the time to compute the precision is O(1) rather than being O(n) (where n is the length of the array). And that is exactly what we are doing in the webrev. First, we get the bit length of the number and then multiply it with log2 (10 base), use the result to index to a dynamically expanded ten's power array so that division operation can be avoided completely. Last but not least, the optimization we've made in layoutChars implementation significantly reduces the array allocation rate by making a thread local StringBuilder object. As a result, the buffer to hold the temporary characters is the same for every thread to call the method. Further using the idea I mentioned, we also make it intCompact aware. When the number is not inflated, we use a thread local character array to hold that number in char(s). This reduces the burden for every method call to allocate that character array. Reviewed by: Verified by: JCK regression tests in JDK workspace Also contributed by: Doug Lea (thanks so much for a lot of tedious code clean up work you've done, and of course, many fantastic ideas. ) Joe Darcy contributed most of the tests Regards, -Xiaobin From mark at klomp.org Tue Feb 17 01:15:05 2009 From: mark at klomp.org (Mark Wielaard) Date: Tue, 17 Feb 2009 10:15:05 +0100 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: <1234774554.11228.3.camel@localhost.localdomain> References: <20090212150029.GA1121@rivendell.middle-earth.co.uk> <1234731237.3562.6.camel@hermans.wildebeest.org> <17c6771e0902151453t523b15derfc243ffaa201264f@mail.gmail.com> <1234768690.24153.28.camel@localhost.localdomain> <1234772748.3612.3.camel@hermans.wildebeest.org> <1234774554.11228.3.camel@localhost.localdomain> Message-ID: <1234862105.4062.8.camel@fedora.wildebeest.org> Hi Christian (CCed hotspot-dev for advice) On Mon, 2009-02-16 at 09:55 +0100, Christian Thalinger wrote: > On Mon, 2009-02-16 at 09:25 +0100, Mark Wielaard wrote: > > Great. I was surprised if it was otherwise. > > I was just confused which tree to track to make sure to get the latest > > HS14 since we are trying to keep all branches (zero/shark/default) of > > IcedTea6 at a stable Hotspot release. Is this in the default > > jdk7/jdk7/hotspot tree or in some other one? > > The jdk7 repository contains HS15 and therefore not a stable one. I > just looked into the jdk6 repository but it only contains HS11. I don't > know of any open HS14 repository off the top of my head. So it would be good to have an open repo that hosts the HS14 stable build so that people interested in a stable, but modern, hotspot could base their work on that. Since IcedTea6 is trying to standardize on HS14 for the default hotspot and the one that Zero and Shark are based on I could create a icedtea/hotspot repo branched from the latest HS14 code in the jdk7/jdk7/hotspot repo. Would that be interesting to others? How do we coordinate backporting fixes to it? Any other suggestions for hosting an open hotspot HS14 repo (maybe as subtree of one of the other 6 hotspot repos under jdk7/hostspot-* (I admit to not know what they are all for currently). Thanks, Mark From Christian.Thalinger at Sun.COM Tue Feb 17 02:36:35 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 17 Feb 2009 11:36:35 +0100 Subject: A wield hotspot make error In-Reply-To: <4999DA0C.8030706@Sun.COM> References: <22040391.post@talk.nabble.com> <1234801689.11228.11.camel@localhost.localdomain> <22045945.post@talk.nabble.com> <22046005.post@talk.nabble.com> <4999DA0C.8030706@Sun.COM> Message-ID: <1234866995.11228.34.camel@localhost.localdomain> On Mon, 2009-02-16 at 13:26 -0800, Xiaobin Lu wrote: > "gamma" is an internal launcher to test the VM after the build is > done. It is similar to java but statically linked to libjvm.so. It > locates rt.jar and other jar files from JAVA_HOME environment variable > as part of the start up. This is not quite correct. gamma is, as java, dynamically linked with libjvm.so and it uses LD_LIBRARY_PATH to find it. Anyway, what confuses me is this: > But after that, if I manually run test_gamma at directory ../jvmg, there is > no error. -- Christian From volker.simonis at gmail.com Tue Feb 17 02:50:10 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 17 Feb 2009 11:50:10 +0100 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: <1234862105.4062.8.camel@fedora.wildebeest.org> References: <20090212150029.GA1121@rivendell.middle-earth.co.uk> <1234731237.3562.6.camel@hermans.wildebeest.org> <17c6771e0902151453t523b15derfc243ffaa201264f@mail.gmail.com> <1234768690.24153.28.camel@localhost.localdomain> <1234772748.3612.3.camel@hermans.wildebeest.org> <1234774554.11228.3.camel@localhost.localdomain> <1234862105.4062.8.camel@fedora.wildebeest.org> Message-ID: As far as I understand the procedure, the HS14 has been branched at some time in the past and is now "stabilized" in an Sun-internal repository in order to become the next, officially released "Express" VM for JDK6. A good starting point for what you want (i.e. an open, stable HS14 repository) would be to know the exact point at which the HS14 was branched for the next JDK 6 express release. I'm not sure this was right before the HS number was bumped to 15. If it would then also be possible to track the fixes for Sun's "stabilization" branch, you could easily maintain an open, stabilized HS14 branch yourself. By the way, the bugs which are identified for Sun's "stabilization" branch are already visible in the bug database today, although they are not easy to find. The problem is, that some of the bugs are reported and fixed against the JDK 7 head revisions and only back ported to the "stabilization" branch if they are regarded critical. Consider for example bug 6661247. It was fixed in hs12(b02) which was the development code line at that time. But there's another bug ID for the same bug (2160622) and it states the bug was also fixed in hs11(b12) which was a "stabilization" branch at that time. Unfortunately there's no link from 6661247 to 2160622. A nicer example id probably 6599425. It lists all the parallel bug IDs and releases where the bug has been fixed ( hs12(b02), hs10(b22) (Bug ID:2158279) , hs11(b12) (Bug ID:2158280) , 6-open(b11) (Bug ID:2164154)). I think this is exactly the kind of information, that is required - and it should be browsable and searchable release-wise (i.e. by the HS release number). Regards, Volker On 2/17/09, Mark Wielaard wrote: > Hi Christian (CCed hotspot-dev for advice) > > On Mon, 2009-02-16 at 09:55 +0100, Christian Thalinger wrote: > > On Mon, 2009-02-16 at 09:25 +0100, Mark Wielaard wrote: > > > Great. I was surprised if it was otherwise. > > > I was just confused which tree to track to make sure to get the latest > > > HS14 since we are trying to keep all branches (zero/shark/default) of > > > IcedTea6 at a stable Hotspot release. Is this in the default > > > jdk7/jdk7/hotspot tree or in some other one? > > > > The jdk7 repository contains HS15 and therefore not a stable one. I > > just looked into the jdk6 repository but it only contains HS11. I don't > > know of any open HS14 repository off the top of my head. > > So it would be good to have an open repo that hosts the HS14 stable > build so that people interested in a stable, but modern, hotspot could > base their work on that. Since IcedTea6 is trying to standardize on HS14 > for the default hotspot and the one that Zero and Shark are based on I > could create a icedtea/hotspot repo branched from the latest HS14 code > in the jdk7/jdk7/hotspot repo. Would that be interesting to others? How > do we coordinate backporting fixes to it? Any other suggestions for > hosting an open hotspot HS14 repo (maybe as subtree of one of the other > 6 hotspot repos under jdk7/hostspot-* (I admit to not know what they are > all for currently). > > Thanks, > > > Mark > > From Christian.Thalinger at Sun.COM Tue Feb 17 03:15:15 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 17 Feb 2009 12:15:15 +0100 Subject: review request for 6622432 In-Reply-To: <4999E9C6.9000004@Sun.COM> References: <4999E9C6.9000004@Sun.COM> Message-ID: <1234869315.11228.56.camel@localhost.localdomain> On Mon, 2009-02-16 at 14:33 -0800, Xiaobin Lu wrote: > Webrev: http://webrev.invokedynamic.info/xiaobin.lu/6622432/ > > 6622432: RFE: Performance improvements to java.math.BigDecimal > As you know, the division operation is expensive and the > algorithm to compare with the ten's power array can be made more > efficiently by correlating the bit length of the number with the index > to the array so that the time to compute the precision is O(1) rather > than being O(n) (where n is the length of the array). And that is > exactly what we are doing in the webrev. First, we get the bit length of > the number and then multiply it with log2 (10 base), use the result to > index to a dynamically expanded ten's power array so that division > operation can be avoided completely. Actually I'm not reviewing the webrev but I have some questions. 1. Is bitCount() called often and performance critical? There is a RFE (6378821) to intrinsify it and I am thinking about to implement it. 2. Why is BigInteger using it's own implementation of bit-count (bitCnt()) instead of using Integer.bitCount()? -- Christian From Christian.Thalinger at Sun.COM Tue Feb 17 05:51:53 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 17 Feb 2009 14:51:53 +0100 Subject: review request for 6622432 In-Reply-To: <499AB98C.4020604@univ-mlv.fr> References: <4999E9C6.9000004@Sun.COM> <1234869315.11228.56.camel@localhost.localdomain> <499AB98C.4020604@univ-mlv.fr> Message-ID: <1234878713.11228.64.camel@localhost.localdomain> On Tue, 2009-02-17 at 14:20 +0100, R?mi Forax wrote: > > 1. Is bitCount() called often and performance critical? There is a RFE > > (6378821) to intrinsify it and I am thinking about to implement it. > > > It's not related to BigInteger but the fastest multi-dispatch algorithm > that I know relies heavily on > bitCount too (on Long.bitCount). > So you have my vote :) Interesting, do you have a pointer to an example algorithm? > > 2. Why is BigInteger using it's own implementation of bit-count > > (bitCnt()) instead of using Integer.bitCount()? > > > because Integer.bitCount() was introduced in 1.5 and BigInteger in 1.4. > BigInteger was not retrofited. Ohh, I missed that. Could someone fix that or should I propose a patch? -- Christian From Keith.McGuigan at Sun.COM Tue Feb 17 07:43:55 2009 From: Keith.McGuigan at Sun.COM (Keith McGuigan) Date: Tue, 17 Feb 2009 10:43:55 -0500 Subject: Interesting tidbit from the dtrace world Message-ID: <499ADB3B.4050802@sun.com> It looks like the newest versions of Solaris has tied dtrace into the CPU performance counters. With the existing dtrace probes we have in hotspot (and the user-level ones in JDK7), this might be able to generate some interesting performance data: http://blogs.sun.com/jonh/entry/finally_dtrace_meets_the_cpu (just an In-case-you're-interested announcement) -- - Keith From forax at univ-mlv.fr Tue Feb 17 05:20:12 2009 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Tue, 17 Feb 2009 14:20:12 +0100 Subject: review request for 6622432 In-Reply-To: <1234869315.11228.56.camel@localhost.localdomain> References: <4999E9C6.9000004@Sun.COM> <1234869315.11228.56.camel@localhost.localdomain> Message-ID: <499AB98C.4020604@univ-mlv.fr> Hi Christian, Christian Thalinger a ?crit : > On Mon, 2009-02-16 at 14:33 -0800, Xiaobin Lu wrote: > >> Webrev: http://webrev.invokedynamic.info/xiaobin.lu/6622432/ >> >> 6622432: RFE: Performance improvements to java.math.BigDecimal >> > > > > >> As you know, the division operation is expensive and the >> algorithm to compare with the ten's power array can be made more >> efficiently by correlating the bit length of the number with the index >> to the array so that the time to compute the precision is O(1) rather >> than being O(n) (where n is the length of the array). And that is >> exactly what we are doing in the webrev. First, we get the bit length of >> the number and then multiply it with log2 (10 base), use the result to >> index to a dynamically expanded ten's power array so that division >> operation can be avoided completely. >> > > Actually I'm not reviewing the webrev but I have some questions. > > 1. Is bitCount() called often and performance critical? There is a RFE > (6378821) to intrinsify it and I am thinking about to implement it. > It's not related to BigInteger but the fastest multi-dispatch algorithm that I know relies heavily on bitCount too (on Long.bitCount). So you have my vote :) > 2. Why is BigInteger using it's own implementation of bit-count > (bitCnt()) instead of using Integer.bitCount()? > because Integer.bitCount() was introduced in 1.5 and BigInteger in 1.4. BigInteger was not retrofited. > -- Christian > R?mi From Xiaobin.Lu at Sun.COM Tue Feb 17 10:29:43 2009 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Tue, 17 Feb 2009 10:29:43 -0800 Subject: review request for 6622432 In-Reply-To: <1234869315.11228.56.camel@localhost.localdomain> References: <4999E9C6.9000004@Sun.COM> <1234869315.11228.56.camel@localhost.localdomain> Message-ID: <499B0217.8080500@Sun.COM> On 02/17/09 03:15, Christian Thalinger wrote: > On Mon, 2009-02-16 at 14:33 -0800, Xiaobin Lu wrote: > >> Webrev: http://webrev.invokedynamic.info/xiaobin.lu/6622432/ >> >> 6622432: RFE: Performance improvements to java.math.BigDecimal >> > > > > >> As you know, the division operation is expensive and the >> algorithm to compare with the ten's power array can be made more >> efficiently by correlating the bit length of the number with the index >> to the array so that the time to compute the precision is O(1) rather >> than being O(n) (where n is the length of the array). And that is >> exactly what we are doing in the webrev. First, we get the bit length of >> the number and then multiply it with log2 (10 base), use the result to >> index to a dynamically expanded ten's power array so that division >> operation can be avoided completely. >> > > Actually I'm not reviewing the webrev but I have some questions. > > 1. Is bitCount() called often and performance critical? There is a RFE > (6378821) to intrinsify it and I am thinking about to implement it. > No, I don't think it is a hot method in both derby and SPECjbb2005 based on the profiling information from Analyzer. I might be wrong, but you can verify it easily. > 2. Why is BigInteger using it's own implementation of bit-count > (bitCnt()) instead of using Integer.bitCount()? > That is a good catch. I will fix it. -Xiaobin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090217/b72cf4eb/attachment.html From vladimir.kozlov at sun.com Tue Feb 17 17:51:58 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 18 Feb 2009 01:51:58 +0000 Subject: hg: jdk7/hotspot/hotspot: 21 new changesets Message-ID: <20090218015258.C4D07DAE8@hg.openjdk.java.net> Changeset: 96964ebdb154 Author: kvn Date: 2009-01-07 11:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/96964ebdb154 6782232: assert("CreateEx must be first instruction in block" ) Summary: Add the missing check for CreateEx. Add new notproduct flag VerifyRegisterAllocator. Reviewed-by: never ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/reg_split.cpp Changeset: 6c4cda924d2e Author: kvn Date: 2009-01-07 11:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6c4cda924d2e 6790182: matcher.cpp:1375: assert(false,"bad AD file") Summary: Add a match rule for regD_low in regD definition. Reviewed-by: never ! src/cpu/sparc/vm/sparc.ad Changeset: 011517bbcd7b Author: kvn Date: 2009-01-13 11:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/011517bbcd7b 6784930: server jvm fails with assert(!n->is_SpillCopy(),"") Summary: Set minimum block frequency MIN_BLOCK_FREQUENCY 1.e-35f. Reviewed-by: never, rasbold ! src/share/vm/opto/gcm.cpp Changeset: 041fe019d769 Author: never Date: 2009-01-13 11:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/041fe019d769 6791132: bad control in autobox split code Reviewed-by: kvn ! src/share/vm/opto/memnode.cpp Changeset: 78144dc3db03 Author: never Date: 2009-01-13 14:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/78144dc3db03 Merge Changeset: 35ae4dd6c27c Author: never Date: 2009-01-14 14:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/35ae4dd6c27c 6788347: C2Compiler crash 6u7 Reviewed-by: kvn ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: 48bb4a49b7ac Author: kvn Date: 2009-01-16 11:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/48bb4a49b7ac 6790209: server VM fails with assert(will_link,"_new: typeflow responsibility") Summary: Add missing code for reflection class loader in SystemDictionary::find(). Reviewed-by: never, jrose ! src/share/vm/classfile/systemDictionary.cpp Changeset: 465813e0303a Author: kvn Date: 2009-01-21 11:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/465813e0303a 6794939: assert(_base == OopPtr,"subclass must override cast_to_ptr_type") Summary: Fix the assert in TypeKlassPtr::cast_to_ptr_type(). Reviewed-by: never ! src/share/vm/opto/type.cpp Changeset: 3b5ac9e7e6ea Author: twisti Date: 2009-01-26 16:22 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3b5ac9e7e6ea 6796746: rename LoadC (char) opcode class to LoadUS (unsigned short) Summary: Renaming LoadC to LoadUS would round up the planned introduction of LoadUB and LoadUI. Reviewed-by: phh, kvn ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp Changeset: 7628781568e1 Author: twisti Date: 2009-02-03 01:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7628781568e1 6795362: 32bit server compiler leads to wrong results on solaris-x86 Summary: The C2 compiler leads to wrong results on solaris-i486 (32-bit) for a testcase given in the CR. Reviewed-by: never, rasbold ! src/share/vm/opto/mulnode.cpp ! src/share/vm/utilities/globalDefinitions.hpp + test/compiler/6795362/Test6795362.java Changeset: b79faa366fbd Author: twisti Date: 2009-02-03 08:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b79faa366fbd 6799452: HotSpot tests Makefile should take care of ALT_SLASH_JAVA Summary: The HotSpot tests Makefile has a hardcoded SLASH_JAVA which makes it difficult to run the tests on non-Sun build machines which do not have a /java infrastructure. Reviewed-by: kamg ! test/Makefile Changeset: 5bfdb08ea692 Author: never Date: 2009-02-03 18:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5bfdb08ea692 6782260: Memory leak in CodeBuffer::create_patch_overflow Reviewed-by: phh, kvn ! src/share/vm/asm/codeBuffer.cpp Changeset: 1580954e694c Author: never Date: 2009-02-04 11:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1580954e694c 6798785: Crash in OopFlow::build_oop_map: incorrect comparison of 64bit pointers Reviewed-by: phh, kvn ! src/share/vm/adlc/dict2.cpp ! src/share/vm/libadt/dict.cpp Changeset: 1b9fc6e3171b Author: never Date: 2009-02-04 23:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1b9fc6e3171b 6442502: assert(bits,"Use TypePtr for NULL") on linux-x86 Reviewed-by: kvn ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp Changeset: 323728917cf4 Author: kvn Date: 2009-02-05 13:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/323728917cf4 6788376: allow to ignore unrecognized VM options Summary: Add new product flag -XX:+IgnoreUnrecognizedVMOptions Reviewed-by: ysr, xlu ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! test/compiler/6775880/Test.java Changeset: 7fe62bb75bf4 Author: kvn Date: 2009-02-05 14:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7fe62bb75bf4 6799693: Server compiler leads to data corruption when expression throws an Exception Summary: Use merged memory state for an allocation's slow path. Reviewed-by: never ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/macro.cpp + test/compiler/6795161/Test.java + test/compiler/6799693/Test.java Changeset: 91263420e1c6 Author: kvn Date: 2009-02-06 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/91263420e1c6 6791852: assert(b->_nodes[insidx] == n,"got insidx set incorrectly") Summary: Move the CreateEx up before each round of IFG construction Reviewed-by: never, phh ! src/share/vm/opto/block.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/reg_split.cpp Changeset: bbef4344adb2 Author: twisti Date: 2009-02-13 09:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/bbef4344adb2 6800154: Add comments to long_by_long_mulhi() for better understandability Summary: This patch adds a comment pointing to the Hacker's Delight version of the algorithm plus a verbatim copy of it. Furthermore it adds inline comments. Reviewed-by: kvn, jrose ! src/share/vm/opto/divnode.cpp + test/compiler/6603011/Test.java + test/compiler/6800154/Test6800154.java Changeset: 30663ca5e8f4 Author: twisti Date: 2009-02-16 07:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/30663ca5e8f4 6805724: ModLNode::Ideal() generates functionally incorrect graph when divisor is any (2^k-1) constant. Summary: C2, ModLNode::Ideal() generates functionally incorrect graph when divisor is any (2^k-1) constant. Reviewed-by: rasbold ! src/share/vm/opto/divnode.cpp ! src/share/vm/utilities/globalDefinitions.hpp + test/compiler/6805724/Test6805724.java Changeset: 2cacccded90f Author: twisti Date: 2009-02-17 11:19 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2cacccded90f 6805950: Typos in andL_rReg_imm instructions in x86_64.ad Summary: There are two typos in andL_rReg_imm instructions in x86_64.ad. Reviewed-by: kvn ! src/cpu/x86/vm/x86_64.ad Changeset: dca06e7f503d Author: kvn Date: 2009-02-17 14:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/dca06e7f503d Merge ! src/cpu/x86/vm/x86_32.ad ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/globalDefinitions.hpp From Joe.Darcy at Sun.COM Tue Feb 17 18:29:17 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Tue, 17 Feb 2009 18:29:17 -0800 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: <1234862105.4062.8.camel@fedora.wildebeest.org> References: <20090212150029.GA1121@rivendell.middle-earth.co.uk> <1234731237.3562.6.camel@hermans.wildebeest.org> <17c6771e0902151453t523b15derfc243ffaa201264f@mail.gmail.com> <1234768690.24153.28.camel@localhost.localdomain> <1234772748.3612.3.camel@hermans.wildebeest.org> <1234774554.11228.3.camel@localhost.localdomain> <1234862105.4062.8.camel@fedora.wildebeest.org> Message-ID: <499B727D.6060901@sun.com> On 02/17/09 01:15 AM, Mark Wielaard wrote: > Hi Christian (CCed hotspot-dev for advice) > > On Mon, 2009-02-16 at 09:55 +0100, Christian Thalinger wrote: > >> On Mon, 2009-02-16 at 09:25 +0100, Mark Wielaard wrote: >> >>> Great. I was surprised if it was otherwise. >>> I was just confused which tree to track to make sure to get the latest >>> HS14 since we are trying to keep all branches (zero/shark/default) of >>> IcedTea6 at a stable Hotspot release. Is this in the default >>> jdk7/jdk7/hotspot tree or in some other one? >>> >> The jdk7 repository contains HS15 and therefore not a stable one. I >> just looked into the jdk6 repository but it only contains HS11. I don't >> know of any open HS14 repository off the top of my head. >> > > So it would be good to have an open repo that hosts the HS14 stable > build so that people interested in a stable, but modern, hotspot could > base their work on that. Since IcedTea6 is trying to standardize on HS14 > for the default hotspot and the one that Zero and Shark are based on I > could create a icedtea/hotspot repo branched from the latest HS14 code > in the jdk7/jdk7/hotspot repo. Would that be interesting to others? How > do we coordinate backporting fixes to it? Any other suggestions for > hosting an open hotspot HS14 repo (maybe as subtree of one of the other > 6 hotspot repos under jdk7/hostspot-* (I admit to not know what they are > all for currently). > > Hello. I have been talking with the HotSpot team inside Sun about the logistics needed to support a public HotSpot Mercurial repository usable by both OpenJDK 6 and the 6 update release, which would mean the stabilized HotSpot 14 at this point. We should have something figured out relatively soon; I'll post when we do. -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090217/1cc600b5/attachment.html From mark at klomp.org Wed Feb 18 01:47:42 2009 From: mark at klomp.org (Mark Wielaard) Date: Wed, 18 Feb 2009 10:47:42 +0100 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: References: <20090212150029.GA1121@rivendell.middle-earth.co.uk> <1234731237.3562.6.camel@hermans.wildebeest.org> <17c6771e0902151453t523b15derfc243ffaa201264f@mail.gmail.com> <1234768690.24153.28.camel@localhost.localdomain> <1234772748.3612.3.camel@hermans.wildebeest.org> <1234774554.11228.3.camel@localhost.localdomain> <1234862105.4062.8.camel@fedora.wildebeest.org> Message-ID: <1234950462.2322.9.camel@fedora.wildebeest.org> Hi Volker, Thanks for the informative reply. On Tue, 2009-02-17 at 11:50 +0100, Volker Simonis wrote: > As far as I understand the procedure, the HS14 has been branched at > some time in the past and is now "stabilized" in an Sun-internal > repository in order to become the next, officially released "Express" > VM for JDK6. That would be good, then we are all pushing at the same code base for stabilization. What does "Express" stand for? > A good starting point for what you want (i.e. an open, stable HS14 > repository) would be to know the exact point at which the HS14 was > branched for the next JDK 6 express release. I'm not sure this was > right before the HS number was bumped to 15. Yes, my plan was to branch at the commit just before the HS15 tag in jdk7/jdk7/hotspot appeared. But it would be good to get confirmation that is the right branch point. > If it would then also be possible to track the fixes for Sun's > "stabilization" branch, you could easily maintain an open, stabilized > HS14 branch yourself. By the way, the bugs which are identified for > Sun's "stabilization" branch are already visible in the bug database > today, although they are not easy to find. The problem is, that some > of the bugs are reported and fixed against the JDK 7 head revisions > and only back ported to the "stabilization" branch if they are > regarded critical. We already backported fixes from the hotspot trees for common crashers in important applications before the HS14 adoption, including test cases. Which reminds me to add some of those test cases back that were recently lost for old crasher bugs. > Consider for example bug 6661247. It was fixed in hs12(b02) which was > the development code line at that time. But there's another bug ID for > the same bug (2160622) and it states the bug was also fixed in > hs11(b12) which was a "stabilization" branch at that time. > Unfortunately there's no link from 6661247 to 2160622. A nicer example > id probably 6599425. It lists all the parallel bug IDs and releases > where the bug has been fixed ( hs12(b02), hs10(b22) (Bug ID:2158279) , > hs11(b12) (Bug ID:2158280) , 6-open(b11) (Bug ID:2164154)). I think > this is exactly the kind of information, that is required - and it > should be browsable and searchable release-wise (i.e. by the HS > release number). Thanks, that is interesting. We could create a bug screen scrapper that tries to collect all bugs that have relevant tags. But it would be better to have a more open publicly visible way of coordinating fixes around shared trees. I found bugs.sun.com not ideal for coordinating bugs and patches, if only because I haven't found any way to search for specific tags like hs14. I might be missing some advanced search page, but it does look like you can only search for a general keyword/bug-id, not on any specifics (except for the component and state). In general watching the commit lists has been more productive, but often misses any discussion about the bug being fixed. Cheers, Mark From mark at klomp.org Wed Feb 18 01:58:27 2009 From: mark at klomp.org (Mark Wielaard) Date: Wed, 18 Feb 2009 10:58:27 +0100 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: <499B727D.6060901@sun.com> References: <20090212150029.GA1121@rivendell.middle-earth.co.uk> <1234731237.3562.6.camel@hermans.wildebeest.org> <17c6771e0902151453t523b15derfc243ffaa201264f@mail.gmail.com> <1234768690.24153.28.camel@localhost.localdomain> <1234772748.3612.3.camel@hermans.wildebeest.org> <1234774554.11228.3.camel@localhost.localdomain> <1234862105.4062.8.camel@fedora.wildebeest.org> <499B727D.6060901@sun.com> Message-ID: <1234951107.2322.20.camel@fedora.wildebeest.org> Hi Joe, On Tue, 2009-02-17 at 18:29 -0800, Joe Darcy wrote: > I have been talking with the HotSpot team inside Sun about the > logistics needed to support a public HotSpot Mercurial repository > usable by both OpenJDK 6 and the 6 update release, which would mean > the stabilized HotSpot 14 at this point. > > We should have something figured out relatively soon; I'll post when > we do. That would be ideal, then we will all be pushing against the same code base, making it rock solid! Let me know if you need any help with hosting it anywhere or how to facilitate pushing to it. Cheers, Mark From Christian.Thalinger at Sun.COM Wed Feb 18 02:09:43 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 18 Feb 2009 11:09:43 +0100 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: <1234950462.2322.9.camel@fedora.wildebeest.org> References: <20090212150029.GA1121@rivendell.middle-earth.co.uk> <1234731237.3562.6.camel@hermans.wildebeest.org> <17c6771e0902151453t523b15derfc243ffaa201264f@mail.gmail.com> <1234768690.24153.28.camel@localhost.localdomain> <1234772748.3612.3.camel@hermans.wildebeest.org> <1234774554.11228.3.camel@localhost.localdomain> <1234862105.4062.8.camel@fedora.wildebeest.org> <1234950462.2322.9.camel@fedora.wildebeest.org> Message-ID: <1234951783.5094.17.camel@localhost.localdomain> On Wed, 2009-02-18 at 10:47 +0100, Mark Wielaard wrote: > That would be good, then we are all pushing at the same code base for > stabilization. What does "Express" stand for? The release cycle for HotSpot has been decoupled from the JDK release cycle and that's what Express means. > Yes, my plan was to branch at the commit just before the HS15 tag in > jdk7/jdk7/hotspot appeared. But it would be good to get confirmation > that is the right branch point. I can look that up again... The changeset right before the fork is: fc6a5ae3fef5 which bumps the HotSpot version to 14.0-b10. In the HotSpot team meeting yesterday we talked about that problem and, as Joe Darcy already stated, there will be a HS14 repository in the near future. But I was also told that 14 isn't stable yet, it's just in the stabilization phase. When you really want something rock solid you should go with HS11. -- Christian From volker.simonis at gmail.com Wed Feb 18 02:11:18 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 18 Feb 2009 11:11:18 +0100 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: <1234950462.2322.9.camel@fedora.wildebeest.org> References: <20090212150029.GA1121@rivendell.middle-earth.co.uk> <1234731237.3562.6.camel@hermans.wildebeest.org> <17c6771e0902151453t523b15derfc243ffaa201264f@mail.gmail.com> <1234768690.24153.28.camel@localhost.localdomain> <1234772748.3612.3.camel@hermans.wildebeest.org> <1234774554.11228.3.camel@localhost.localdomain> <1234862105.4062.8.camel@fedora.wildebeest.org> <1234950462.2322.9.camel@fedora.wildebeest.org> Message-ID: > That would be good, then we are all pushing at the same code base for > stabilization. What does "Express" stand for? > It's just the code name for the fact that a specific JDK (JDK 6 in this case) contains a HotSpot from a newer JDK (JDK 7, which you are not allowed to call JDK7 until now:). This didn't happend in the past (i.e. in Java releases before 6) and was started with JDK 6u4 which contained HS10 from JDK7. From dawn2004 at gmail.com Wed Feb 18 08:06:22 2009 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Wed, 18 Feb 2009 08:06:22 -0800 (PST) Subject: Question about the mapping of oopDesc and KlassOop Message-ID: <22081975.post@talk.nabble.com> Hello, I have a question about the java object layout in Hotspot. In hotspot, a oopDesc respesents a java object, oopDesc contains a pointer to a klassOop instance. Is the relation between the instance of oopDesc and the instance of klassOop one to one mapping ? Or multiple oopDesc instances can share one klassOop? Thanks a lot! Du Li -- View this message in context: http://www.nabble.com/Question-about-the-mapping-of-oopDesc-and-KlassOop-tp22081975p22081975.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From Keith.McGuigan at Sun.COM Wed Feb 18 08:25:41 2009 From: Keith.McGuigan at Sun.COM (Keith McGuigan) Date: Wed, 18 Feb 2009 11:25:41 -0500 Subject: Question about the mapping of oopDesc and KlassOop In-Reply-To: <22081975.post@talk.nabble.com> References: <22081975.post@talk.nabble.com> Message-ID: <499C3685.6030508@sun.com> Colin(Du Li) wrote: > Hello, > > I have a question about the java object layout in Hotspot. > In hotspot, a oopDesc respesents a java object, oopDesc contains a pointer > to a klassOop instance. Is the relation between the instance of oopDesc and > the instance of klassOop one to one mapping ? Or multiple oopDesc instances > can share one klassOop? > Thanks a lot! The latter. An oopDesc* is a pointer to an object in the java heap. Every oop in the heap has a pointer to it's type (the klassOop) as it's second field. -- - Keith From dawn2004 at gmail.com Wed Feb 18 08:27:16 2009 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Wed, 18 Feb 2009 08:27:16 -0800 (PST) Subject: Question about the mapping of oopDesc and KlassOop In-Reply-To: <499C3685.6030508@sun.com> References: <22081975.post@talk.nabble.com> <499C3685.6030508@sun.com> Message-ID: <22082449.post@talk.nabble.com> Thanks. Then, every java class has only one klassOop object in the heap, or it can have more one klassOop instance? Du Li Keith McGuigan wrote: > > Colin(Du Li) wrote: >> Hello, >> >> I have a question about the java object layout in Hotspot. >> In hotspot, a oopDesc respesents a java object, oopDesc contains a >> pointer >> to a klassOop instance. Is the relation between the instance of oopDesc >> and >> the instance of klassOop one to one mapping ? Or multiple oopDesc >> instances >> can share one klassOop? >> Thanks a lot! > > The latter. An oopDesc* is a pointer to an object in the java heap. > Every oop in the heap has a pointer to it's type (the klassOop) as it's > second field. > > -- > - Keith > > -- View this message in context: http://www.nabble.com/Question-about-the-mapping-of-oopDesc-and-KlassOop-tp22081975p22082449.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From Keith.McGuigan at Sun.COM Wed Feb 18 08:56:08 2009 From: Keith.McGuigan at Sun.COM (Keith McGuigan) Date: Wed, 18 Feb 2009 11:56:08 -0500 Subject: Question about the mapping of oopDesc and KlassOop In-Reply-To: <22082449.post@talk.nabble.com> References: <22081975.post@talk.nabble.com> <499C3685.6030508@sun.com> <22082449.post@talk.nabble.com> Message-ID: <499C3DA8.2060002@sun.com> Colin(Du Li) wrote: > Thanks. > Then, every java class has only one klassOop object in the heap, or it can > have more one klassOop instance? There are a couple of data structures that correspond to a "java class", one of them is an instanceKlassOop, which is what the VM uses to hold most of the class information. Another is the java-level mirror (which is a normal Java instance object (instanceOop), and what you get when you call getClass() or use X.class in Java). But yes, there is only one instanceKlass and mirror object per "Java class". -- - Keith From dawn2004 at gmail.com Wed Feb 18 09:56:14 2009 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Wed, 18 Feb 2009 09:56:14 -0800 (PST) Subject: Question about the mapping of oopDesc and KlassOop In-Reply-To: <499C3DA8.2060002@sun.com> References: <22081975.post@talk.nabble.com> <499C3685.6030508@sun.com> <22082449.post@talk.nabble.com> <499C3DA8.2060002@sun.com> Message-ID: <22084443.post@talk.nabble.com> Make sense. Thanks a lot! Du Li Keith McGuigan wrote: > > Colin(Du Li) wrote: >> Thanks. >> Then, every java class has only one klassOop object in the heap, or it >> can >> have more one klassOop instance? > > There are a couple of data structures that correspond to a "java class", > one of them is an instanceKlassOop, which is what the VM uses to hold > most of the class information. Another is the java-level mirror (which > is a normal Java instance object (instanceOop), and what you get when > you call getClass() or use X.class in Java). But yes, there is only > one instanceKlass and mirror object per "Java class". > > -- > - Keith > > -- View this message in context: http://www.nabble.com/Question-about-the-mapping-of-oopDesc-and-KlassOop-tp22081975p22084443.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From sits at nuix.com Wed Feb 18 16:29:13 2009 From: sits at nuix.com (David Sitsky) Date: Thu, 19 Feb 2009 11:29:13 +1100 Subject: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application Message-ID: <499CA7D9.9040903@nuix.com> I apologise in advance if this is a "breach of protocol". I have submitted a bug through the usual channels, but my experience with this approach unfortunately has usually been a dead-end. I have a very intensive data application (I/O + CPU + memory) on the Windows platform that reliably causes a 100% CPU lockup, but only for the x64 distribution (jdk 1.6.0_07, 1.6.0_10 and 1.6.0_12). When using the x32 distribution on the same machines it works fine. It is not machine-specific - I have seen this across 7 different machines, and it seems to occur after a few to several hours of processing. The JVM is still responsive, but extremely slow. Using process explorer, I was able to find the thread in the process consuming all the CPU. The stack traces from procexp have the same thread ID as the "VM Thread" from jstack. The stacks are usually something like the following: ntoskrnl.exe!ExpInterlockedFlushSList+0x126f ntoskrnl.exe!RtlNumberOfClearBits+0x5cc ntoskrnl.exe!ExpInterlockedFlushSList+0x134d ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 jvm.dll!AsyncGetCallTrace+0x3ac7f jvm.dll!JVM_FindSignal+0xe4533 jvm.dll!JVM_FindSignal+0x10fa2e jvm.dll!JVM_FindSignal+0xe3eef jvm.dll!JVM_FindSignal+0x14d61d jvm.dll!JVM_FindSignal+0x14dabc jvm.dll!JVM_FindSignal+0x1593e0 jvm.dll!JVM_FindSignal+0x12a374 jvm.dll!JVM_FindSignal+0x2167d3 jvm.dll!JVM_FindSignal+0x2193e8 jvm.dll!JVM_FindSignal+0x218274 jvm.dll!JVM_FindSignal+0x2186ca jvm.dll!JVM_FindSignal+0x218cd2 jvm.dll!JVM_FindSignal+0x11d7f9 msvcrt.dll!free_dbg+0x147 msvcrt.dll!beginthreadex+0x131 kernel32.dll!BaseThreadInitThunk+0xd ntdll.dll!RtlUserThreadStart+0x21 or ntoskrnl.exe!ExpInterlockedFlushSList+0x126f ntoskrnl.exe!KeWaitForMultipleObjects+0xcca ntoskrnl.exe!KeWaitForMutexObject+0x2da ntoskrnl.exe!_misaligned_access+0x35 ntoskrnl.exe!MmUnlockPages+0x1160 ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 jvm.dll!AsyncGetCallTrace+0x3ac7f jvm.dll!JVM_FindSignal+0xe3eef jvm.dll!JVM_FindSignal+0x14d61d jvm.dll!JVM_FindSignal+0x14dabc jvm.dll!JVM_FindSignal+0x1593e0 jvm.dll!JVM_FindSignal+0x12a374 jvm.dll!JVM_FindSignal+0x2167d3 jvm.dll!JVM_FindSignal+0x2193e8 jvm.dll!JVM_FindSignal+0x218274 jvm.dll!JVM_FindSignal+0x2186ca jvm.dll!JVM_FindSignal+0x218cd2 jvm.dll!JVM_FindSignal+0x11d7f9 msvcrt.dll!free_dbg+0x147 msvcrt.dll!beginthreadex+0x131 kernel32.dll!BaseThreadInitThunk+0xd ntdll.dll!RtlUserThreadStart+0x21 or (without AsyncGetCallTrace): ntoskrnl.exe!ExpInterlockedFlushSList+0x14a0 ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 jvm.dll!JVM_EnqueueOperation+0xb19f4 jvm.dll!JVM_FindSignal+0x1b7fcc jvm.dll!JVM_FindSignal+0x14dcca jvm.dll!JVM_FindSignal+0x14e17c jvm.dll!JVM_FindSignal+0x159b80 jvm.dll!JVM_FindSignal+0x12a5e4 jvm.dll!JVM_FindSignal+0x216e53 jvm.dll!JVM_FindSignal+0x219a38 jvm.dll!JVM_FindSignal+0x2188d4 jvm.dll!JVM_FindSignal+0x218d2a jvm.dll!JVM_FindSignal+0x219332 jvm.dll!JVM_FindSignal+0x11da99 msvcrt.dll!free_dbg+0x147 msvcrt.dll!beginthreadex+0x131 kernel32.dll!BaseThreadInitThunk+0xd ntdll.dll!RtlUserThreadStart+0x21 I am more than happy to run test/debug versions in order to assist in tracking this down. I wish I could say, here is a unit test, but its a very complex application with complex data processing. The only good news is it seems to be quite reproduceable on our systems. Apologies again in advance if this was an inappropriate place to post. But given the severity of this issue, I am hoping somebody here will be interested in it.. -- Cheers, David Nuix Pty Ltd Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 0699 Web: http://www.nuix.com Fax: +61 2 9212 6902 From dawn2004 at gmail.com Wed Feb 18 16:46:42 2009 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Wed, 18 Feb 2009 16:46:42 -0800 (PST) Subject: How to trace the hotspot bytecode interpreter Message-ID: <22091780.post@talk.nabble.com> I know the byte interpreter implementation is mainly in bytecodeInterpreter.cpp, but it doesn't allow me set break point in this file. I wanna trace the bytecode interpreter. Where can I put break pointer? Where is the entrance to bytecodeInterpreter.cpp, that is, in Hotpot, which classes will call the methods in bytecodeInterpreter.cpp? Thanks. -- View this message in context: http://www.nabble.com/How-to-trace-the-hotspot-bytecode-interpreter-tp22091780p22091780.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From Daniel.Daugherty at Sun.COM Wed Feb 18 16:54:52 2009 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Wed, 18 Feb 2009 17:54:52 -0700 Subject: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application In-Reply-To: <499CA7D9.9040903@nuix.com> References: <499CA7D9.9040903@nuix.com> Message-ID: <499CADDC.2010409@sun.com> David, I'm not sure about the rest of your problem, but the mentions of "AsyncGetCallTrace" in your stacks don't mean anything on Windows. It happens to be the nearest named function that the stack trace stuff found. The AsyncGetCallTrace() API isn't supported on Windows and there isn't any code in Sun's JDK that calls AsyncGetCallTrace() on Windows. Hopefully someone else will have more information on what is really happening here. Dan David Sitsky wrote: > I apologise in advance if this is a "breach of protocol". I have > submitted a bug through the usual channels, but my experience with > this approach unfortunately has usually been a dead-end. > > I have a very intensive data application (I/O + CPU + memory) on the > Windows platform that reliably causes a 100% CPU lockup, but only for > the x64 distribution (jdk 1.6.0_07, 1.6.0_10 and 1.6.0_12). When > using the x32 distribution on the same machines it works fine. It is > not machine-specific - I have seen this across 7 different machines, > and it seems to occur after a few to several hours of processing. The > JVM is still responsive, but extremely slow. > > Using process explorer, I was able to find the thread in the process > consuming all the CPU. The stack traces from procexp have the same > thread ID as the "VM Thread" from jstack. The stacks are usually > something like the following: > > ntoskrnl.exe!ExpInterlockedFlushSList+0x126f > ntoskrnl.exe!RtlNumberOfClearBits+0x5cc > ntoskrnl.exe!ExpInterlockedFlushSList+0x134d > ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 > jvm.dll!AsyncGetCallTrace+0x3ac7f > jvm.dll!JVM_FindSignal+0xe4533 > jvm.dll!JVM_FindSignal+0x10fa2e > jvm.dll!JVM_FindSignal+0xe3eef > jvm.dll!JVM_FindSignal+0x14d61d > jvm.dll!JVM_FindSignal+0x14dabc > jvm.dll!JVM_FindSignal+0x1593e0 > jvm.dll!JVM_FindSignal+0x12a374 > jvm.dll!JVM_FindSignal+0x2167d3 > jvm.dll!JVM_FindSignal+0x2193e8 > jvm.dll!JVM_FindSignal+0x218274 > jvm.dll!JVM_FindSignal+0x2186ca > jvm.dll!JVM_FindSignal+0x218cd2 > jvm.dll!JVM_FindSignal+0x11d7f9 > msvcrt.dll!free_dbg+0x147 > msvcrt.dll!beginthreadex+0x131 > kernel32.dll!BaseThreadInitThunk+0xd > ntdll.dll!RtlUserThreadStart+0x21 > > or > > ntoskrnl.exe!ExpInterlockedFlushSList+0x126f > ntoskrnl.exe!KeWaitForMultipleObjects+0xcca > ntoskrnl.exe!KeWaitForMutexObject+0x2da > ntoskrnl.exe!_misaligned_access+0x35 > ntoskrnl.exe!MmUnlockPages+0x1160 > ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 > jvm.dll!AsyncGetCallTrace+0x3ac7f > jvm.dll!JVM_FindSignal+0xe3eef > jvm.dll!JVM_FindSignal+0x14d61d > jvm.dll!JVM_FindSignal+0x14dabc > jvm.dll!JVM_FindSignal+0x1593e0 > jvm.dll!JVM_FindSignal+0x12a374 > jvm.dll!JVM_FindSignal+0x2167d3 > jvm.dll!JVM_FindSignal+0x2193e8 > jvm.dll!JVM_FindSignal+0x218274 > jvm.dll!JVM_FindSignal+0x2186ca > jvm.dll!JVM_FindSignal+0x218cd2 > jvm.dll!JVM_FindSignal+0x11d7f9 > msvcrt.dll!free_dbg+0x147 > msvcrt.dll!beginthreadex+0x131 > kernel32.dll!BaseThreadInitThunk+0xd > ntdll.dll!RtlUserThreadStart+0x21 > > or (without AsyncGetCallTrace): > > ntoskrnl.exe!ExpInterlockedFlushSList+0x14a0 > ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 > jvm.dll!JVM_EnqueueOperation+0xb19f4 > jvm.dll!JVM_FindSignal+0x1b7fcc > jvm.dll!JVM_FindSignal+0x14dcca > jvm.dll!JVM_FindSignal+0x14e17c > jvm.dll!JVM_FindSignal+0x159b80 > jvm.dll!JVM_FindSignal+0x12a5e4 > jvm.dll!JVM_FindSignal+0x216e53 > jvm.dll!JVM_FindSignal+0x219a38 > jvm.dll!JVM_FindSignal+0x2188d4 > jvm.dll!JVM_FindSignal+0x218d2a > jvm.dll!JVM_FindSignal+0x219332 > jvm.dll!JVM_FindSignal+0x11da99 > msvcrt.dll!free_dbg+0x147 > msvcrt.dll!beginthreadex+0x131 > kernel32.dll!BaseThreadInitThunk+0xd > ntdll.dll!RtlUserThreadStart+0x21 > > I am more than happy to run test/debug versions in order to assist in > tracking this down. I wish I could say, here is a unit test, but its > a very complex application with complex data processing. The only > good news is it seems to be quite reproduceable on our systems. > > Apologies again in advance if this was an inappropriate place to post. > But given the severity of this issue, I am hoping somebody here will > be interested in it.. > From sits at nuix.com Wed Feb 18 20:42:03 2009 From: sits at nuix.com (David Sitsky) Date: Thu, 19 Feb 2009 15:42:03 +1100 Subject: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application In-Reply-To: <499CADDC.2010409@sun.com> References: <499CA7D9.9040903@nuix.com> <499CADDC.2010409@sun.com> Message-ID: <499CE31B.3040905@nuix.com> Hi Daniel, Thanks for your reply. FWIW, a number of stacks I have don't mention AsyncGetCallTrace, so perhaps procexp has done a bit of mis-reporting there. However, all stacks seem to have this kind of pattern: ntoskrnl.exe!ExpInterlockedFlushSList+0x126f ntoskrnl.exe!KeWaitForMultipleObjects+0xcca ntoskrnl.exe!KeWaitForMutexObject+0x2da ntoskrnl.exe!_misaligned_access+0x35 ntoskrnl.exe!MmUnlockPages+0x1160 ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 [a bunch of jvm.dll calls] msvcrt.dll!free_dbg+0x147 msvcrt.dll!beginthreadex+0x131 kernel32.dll!BaseThreadInitThunk+0xd ntdll.dll!RtlUserThreadStart+0x21 or a slight variant: ntoskrnl.exe!ExpInterlockedFlushSList+0x126f ntoskrnl.exe!RtlNumberOfClearBits+0x5cc ntoskrnl.exe!ExpInterlockedFlushSList+0x134d ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 [a bunch of jvm.dll calls] msvcrt.dll!free_dbg+0x147 msvcrt.dll!beginthreadex+0x131 kernel32.dll!BaseThreadInitThunk+0xd ntdll.dll!RtlUserThreadStart+0x21 Any ideas anyone? The call to IoAcquireCancelSpinLock seems to be always the first call outside for jvm.dll in all these stack traces.. Cheers, David Daniel D. Daugherty wrote: > David, > > I'm not sure about the rest of your problem, but the > mentions of "AsyncGetCallTrace" in your stacks don't > mean anything on Windows. It happens to be the nearest > named function that the stack trace stuff found. > > The AsyncGetCallTrace() API isn't supported on Windows > and there isn't any code in Sun's JDK that calls > AsyncGetCallTrace() on Windows. > > Hopefully someone else will have more information on > what is really happening here. > > Dan > > > David Sitsky wrote: >> I apologise in advance if this is a "breach of protocol". I have >> submitted a bug through the usual channels, but my experience with >> this approach unfortunately has usually been a dead-end. >> >> I have a very intensive data application (I/O + CPU + memory) on the >> Windows platform that reliably causes a 100% CPU lockup, but only for >> the x64 distribution (jdk 1.6.0_07, 1.6.0_10 and 1.6.0_12). When >> using the x32 distribution on the same machines it works fine. It is >> not machine-specific - I have seen this across 7 different machines, >> and it seems to occur after a few to several hours of processing. The >> JVM is still responsive, but extremely slow. >> >> Using process explorer, I was able to find the thread in the process >> consuming all the CPU. The stack traces from procexp have the same >> thread ID as the "VM Thread" from jstack. The stacks are usually >> something like the following: >> >> ntoskrnl.exe!ExpInterlockedFlushSList+0x126f >> ntoskrnl.exe!RtlNumberOfClearBits+0x5cc >> ntoskrnl.exe!ExpInterlockedFlushSList+0x134d >> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >> jvm.dll!AsyncGetCallTrace+0x3ac7f >> jvm.dll!JVM_FindSignal+0xe4533 >> jvm.dll!JVM_FindSignal+0x10fa2e >> jvm.dll!JVM_FindSignal+0xe3eef >> jvm.dll!JVM_FindSignal+0x14d61d >> jvm.dll!JVM_FindSignal+0x14dabc >> jvm.dll!JVM_FindSignal+0x1593e0 >> jvm.dll!JVM_FindSignal+0x12a374 >> jvm.dll!JVM_FindSignal+0x2167d3 >> jvm.dll!JVM_FindSignal+0x2193e8 >> jvm.dll!JVM_FindSignal+0x218274 >> jvm.dll!JVM_FindSignal+0x2186ca >> jvm.dll!JVM_FindSignal+0x218cd2 >> jvm.dll!JVM_FindSignal+0x11d7f9 >> msvcrt.dll!free_dbg+0x147 >> msvcrt.dll!beginthreadex+0x131 >> kernel32.dll!BaseThreadInitThunk+0xd >> ntdll.dll!RtlUserThreadStart+0x21 >> >> or >> >> ntoskrnl.exe!ExpInterlockedFlushSList+0x126f >> ntoskrnl.exe!KeWaitForMultipleObjects+0xcca >> ntoskrnl.exe!KeWaitForMutexObject+0x2da >> ntoskrnl.exe!_misaligned_access+0x35 >> ntoskrnl.exe!MmUnlockPages+0x1160 >> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >> jvm.dll!AsyncGetCallTrace+0x3ac7f >> jvm.dll!JVM_FindSignal+0xe3eef >> jvm.dll!JVM_FindSignal+0x14d61d >> jvm.dll!JVM_FindSignal+0x14dabc >> jvm.dll!JVM_FindSignal+0x1593e0 >> jvm.dll!JVM_FindSignal+0x12a374 >> jvm.dll!JVM_FindSignal+0x2167d3 >> jvm.dll!JVM_FindSignal+0x2193e8 >> jvm.dll!JVM_FindSignal+0x218274 >> jvm.dll!JVM_FindSignal+0x2186ca >> jvm.dll!JVM_FindSignal+0x218cd2 >> jvm.dll!JVM_FindSignal+0x11d7f9 >> msvcrt.dll!free_dbg+0x147 >> msvcrt.dll!beginthreadex+0x131 >> kernel32.dll!BaseThreadInitThunk+0xd >> ntdll.dll!RtlUserThreadStart+0x21 >> >> or (without AsyncGetCallTrace): >> >> ntoskrnl.exe!ExpInterlockedFlushSList+0x14a0 >> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >> jvm.dll!JVM_EnqueueOperation+0xb19f4 >> jvm.dll!JVM_FindSignal+0x1b7fcc >> jvm.dll!JVM_FindSignal+0x14dcca >> jvm.dll!JVM_FindSignal+0x14e17c >> jvm.dll!JVM_FindSignal+0x159b80 >> jvm.dll!JVM_FindSignal+0x12a5e4 >> jvm.dll!JVM_FindSignal+0x216e53 >> jvm.dll!JVM_FindSignal+0x219a38 >> jvm.dll!JVM_FindSignal+0x2188d4 >> jvm.dll!JVM_FindSignal+0x218d2a >> jvm.dll!JVM_FindSignal+0x219332 >> jvm.dll!JVM_FindSignal+0x11da99 >> msvcrt.dll!free_dbg+0x147 >> msvcrt.dll!beginthreadex+0x131 >> kernel32.dll!BaseThreadInitThunk+0xd >> ntdll.dll!RtlUserThreadStart+0x21 >> >> I am more than happy to run test/debug versions in order to assist in >> tracking this down. I wish I could say, here is a unit test, but its >> a very complex application with complex data processing. The only >> good news is it seems to be quite reproduceable on our systems. >> >> Apologies again in advance if this was an inappropriate place to post. >> But given the severity of this issue, I am hoping somebody here will >> be interested in it.. >> -- Cheers, David Nuix Pty Ltd Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 0699 Web: http://www.nuix.com Fax: +61 2 9212 6902 From David.Holmes at Sun.COM Thu Feb 19 00:42:18 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Thu, 19 Feb 2009 18:42:18 +1000 Subject: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application In-Reply-To: <499CE31B.3040905@nuix.com> References: <499CA7D9.9040903@nuix.com> <499CADDC.2010409@sun.com> <499CE31B.3040905@nuix.com> Message-ID: <499D1B6A.7000500@sun.com> David, Those stacks seem weird to me too. The JVM_FindSignal calls don't make any sense like that - it's not a recursive function and shouldn't be being called from msvcrt.dll!free_dbg+0x147. My guess is that the JVM part of the stacks are not reliable. Sorry, I know that's not really any help. If I had to take a wild guess I'd say an exception is occurring during thread startup ... the VM signal handlers are probably already in place but the thread doesn't have enough VM context to be processed by the error handling code ... which is eerily similar to something I've seen on linux on rare occasions ... David Holmes David Sitsky said the following on 02/19/09 14:42: > Hi Daniel, > > Thanks for your reply. FWIW, a number of stacks I have don't mention > AsyncGetCallTrace, so perhaps procexp has done a bit of mis-reporting > there. However, all stacks seem to have this kind of pattern: > > ntoskrnl.exe!ExpInterlockedFlushSList+0x126f > ntoskrnl.exe!KeWaitForMultipleObjects+0xcca > ntoskrnl.exe!KeWaitForMutexObject+0x2da > ntoskrnl.exe!_misaligned_access+0x35 > ntoskrnl.exe!MmUnlockPages+0x1160 > ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 > > [a bunch of jvm.dll calls] > > msvcrt.dll!free_dbg+0x147 > msvcrt.dll!beginthreadex+0x131 > kernel32.dll!BaseThreadInitThunk+0xd > ntdll.dll!RtlUserThreadStart+0x21 > > or a slight variant: > > ntoskrnl.exe!ExpInterlockedFlushSList+0x126f > ntoskrnl.exe!RtlNumberOfClearBits+0x5cc > ntoskrnl.exe!ExpInterlockedFlushSList+0x134d > ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 > > [a bunch of jvm.dll calls] > > msvcrt.dll!free_dbg+0x147 > msvcrt.dll!beginthreadex+0x131 > kernel32.dll!BaseThreadInitThunk+0xd > ntdll.dll!RtlUserThreadStart+0x21 > > Any ideas anyone? > > The call to IoAcquireCancelSpinLock seems to be always the first call > outside for jvm.dll in all these stack traces.. > > Cheers, > David > > Daniel D. Daugherty wrote: >> David, >> >> I'm not sure about the rest of your problem, but the >> mentions of "AsyncGetCallTrace" in your stacks don't >> mean anything on Windows. It happens to be the nearest >> named function that the stack trace stuff found. >> >> The AsyncGetCallTrace() API isn't supported on Windows >> and there isn't any code in Sun's JDK that calls >> AsyncGetCallTrace() on Windows. >> >> Hopefully someone else will have more information on >> what is really happening here. >> >> Dan >> >> >> David Sitsky wrote: >>> I apologise in advance if this is a "breach of protocol". I have >>> submitted a bug through the usual channels, but my experience with >>> this approach unfortunately has usually been a dead-end. >>> >>> I have a very intensive data application (I/O + CPU + memory) on the >>> Windows platform that reliably causes a 100% CPU lockup, but only for >>> the x64 distribution (jdk 1.6.0_07, 1.6.0_10 and 1.6.0_12). When >>> using the x32 distribution on the same machines it works fine. It is >>> not machine-specific - I have seen this across 7 different machines, >>> and it seems to occur after a few to several hours of processing. >>> The JVM is still responsive, but extremely slow. >>> >>> Using process explorer, I was able to find the thread in the process >>> consuming all the CPU. The stack traces from procexp have the same >>> thread ID as the "VM Thread" from jstack. The stacks are usually >>> something like the following: >>> >>> ntoskrnl.exe!ExpInterlockedFlushSList+0x126f >>> ntoskrnl.exe!RtlNumberOfClearBits+0x5cc >>> ntoskrnl.exe!ExpInterlockedFlushSList+0x134d >>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>> jvm.dll!AsyncGetCallTrace+0x3ac7f >>> jvm.dll!JVM_FindSignal+0xe4533 >>> jvm.dll!JVM_FindSignal+0x10fa2e >>> jvm.dll!JVM_FindSignal+0xe3eef >>> jvm.dll!JVM_FindSignal+0x14d61d >>> jvm.dll!JVM_FindSignal+0x14dabc >>> jvm.dll!JVM_FindSignal+0x1593e0 >>> jvm.dll!JVM_FindSignal+0x12a374 >>> jvm.dll!JVM_FindSignal+0x2167d3 >>> jvm.dll!JVM_FindSignal+0x2193e8 >>> jvm.dll!JVM_FindSignal+0x218274 >>> jvm.dll!JVM_FindSignal+0x2186ca >>> jvm.dll!JVM_FindSignal+0x218cd2 >>> jvm.dll!JVM_FindSignal+0x11d7f9 >>> msvcrt.dll!free_dbg+0x147 >>> msvcrt.dll!beginthreadex+0x131 >>> kernel32.dll!BaseThreadInitThunk+0xd >>> ntdll.dll!RtlUserThreadStart+0x21 >>> >>> or >>> >>> ntoskrnl.exe!ExpInterlockedFlushSList+0x126f >>> ntoskrnl.exe!KeWaitForMultipleObjects+0xcca >>> ntoskrnl.exe!KeWaitForMutexObject+0x2da >>> ntoskrnl.exe!_misaligned_access+0x35 >>> ntoskrnl.exe!MmUnlockPages+0x1160 >>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>> jvm.dll!AsyncGetCallTrace+0x3ac7f >>> jvm.dll!JVM_FindSignal+0xe3eef >>> jvm.dll!JVM_FindSignal+0x14d61d >>> jvm.dll!JVM_FindSignal+0x14dabc >>> jvm.dll!JVM_FindSignal+0x1593e0 >>> jvm.dll!JVM_FindSignal+0x12a374 >>> jvm.dll!JVM_FindSignal+0x2167d3 >>> jvm.dll!JVM_FindSignal+0x2193e8 >>> jvm.dll!JVM_FindSignal+0x218274 >>> jvm.dll!JVM_FindSignal+0x2186ca >>> jvm.dll!JVM_FindSignal+0x218cd2 >>> jvm.dll!JVM_FindSignal+0x11d7f9 >>> msvcrt.dll!free_dbg+0x147 >>> msvcrt.dll!beginthreadex+0x131 >>> kernel32.dll!BaseThreadInitThunk+0xd >>> ntdll.dll!RtlUserThreadStart+0x21 >>> >>> or (without AsyncGetCallTrace): >>> >>> ntoskrnl.exe!ExpInterlockedFlushSList+0x14a0 >>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>> jvm.dll!JVM_EnqueueOperation+0xb19f4 >>> jvm.dll!JVM_FindSignal+0x1b7fcc >>> jvm.dll!JVM_FindSignal+0x14dcca >>> jvm.dll!JVM_FindSignal+0x14e17c >>> jvm.dll!JVM_FindSignal+0x159b80 >>> jvm.dll!JVM_FindSignal+0x12a5e4 >>> jvm.dll!JVM_FindSignal+0x216e53 >>> jvm.dll!JVM_FindSignal+0x219a38 >>> jvm.dll!JVM_FindSignal+0x2188d4 >>> jvm.dll!JVM_FindSignal+0x218d2a >>> jvm.dll!JVM_FindSignal+0x219332 >>> jvm.dll!JVM_FindSignal+0x11da99 >>> msvcrt.dll!free_dbg+0x147 >>> msvcrt.dll!beginthreadex+0x131 >>> kernel32.dll!BaseThreadInitThunk+0xd >>> ntdll.dll!RtlUserThreadStart+0x21 >>> >>> I am more than happy to run test/debug versions in order to assist in >>> tracking this down. I wish I could say, here is a unit test, but its >>> a very complex application with complex data processing. The only >>> good news is it seems to be quite reproduceable on our systems. >>> >>> Apologies again in advance if this was an inappropriate place to >>> post. But given the severity of this issue, I am hoping somebody here >>> will be interested in it.. >>> > > From mark at klomp.org Thu Feb 19 01:23:50 2009 From: mark at klomp.org (Mark Wielaard) Date: Thu, 19 Feb 2009 10:23:50 +0100 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: <1234951783.5094.17.camel@localhost.localdomain> References: <20090212150029.GA1121@rivendell.middle-earth.co.uk> <1234731237.3562.6.camel@hermans.wildebeest.org> <17c6771e0902151453t523b15derfc243ffaa201264f@mail.gmail.com> <1234768690.24153.28.camel@localhost.localdomain> <1234772748.3612.3.camel@hermans.wildebeest.org> <1234774554.11228.3.camel@localhost.localdomain> <1234862105.4062.8.camel@fedora.wildebeest.org> <1234950462.2322.9.camel@fedora.wildebeest.org> <1234951783.5094.17.camel@localhost.localdomain> Message-ID: <1235035430.3597.14.camel@hermans.wildebeest.org> Hi Christian, On Wed, 2009-02-18 at 11:09 +0100, Christian Thalinger wrote: > On Wed, 2009-02-18 at 10:47 +0100, Mark Wielaard wrote: > > Yes, my plan was to branch at the commit just before the HS15 tag in > > jdk7/jdk7/hotspot appeared. But it would be good to get confirmation > > that is the right branch point. > > I can look that up again... The changeset right before the fork is: > > fc6a5ae3fef5 > > which bumps the HotSpot version to 14.0-b10. Thanks. I am waiting for Joe to reveal the open hs14 repo that he wants to base openjdk6 on first though before creating another one for now. Unless that takes too long of course, then we can always start tracking from that revision. > But I was also told that 14 isn't stable yet, it's just in the > stabilization phase. When you really want something rock solid you > should go with HS11. Yes, you can even get this with icedtea configure --with-hotspot-build=original but that needs more patches (e.g for sparc support) and for zero/shark it is too old, so it needs too much backporting to keep current in the long run. Cheers, Mark From Ivan.Krylov at Sun.COM Thu Feb 19 03:56:54 2009 From: Ivan.Krylov at Sun.COM (Ivan Krylov) Date: Thu, 19 Feb 2009 14:56:54 +0300 Subject: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application In-Reply-To: <499D1B6A.7000500@sun.com> References: <499CA7D9.9040903@nuix.com> <499CADDC.2010409@sun.com> <499CE31B.3040905@nuix.com> <499D1B6A.7000500@sun.com> Message-ID: <499D4906.1070009@Sun.COM> David Holmes - Sun Microsystems wrote: > David, > > Those stacks seem weird to me too. The JVM_FindSignal calls don't make > any sense like that - it's not a recursive function and shouldn't be > being called from msvcrt.dll!free_dbg+0x147. My guess is that the JVM > part of the stacks are not reliable. You typically get jvm.dll!JVM_FindSignal when pdb files aren't available, right? If we new exact version/build number we should be able to tell function names behind jvm.dll!JVM_FindSignal Ivan > > Sorry, I know that's not really any help. > > If I had to take a wild guess I'd say an exception is occurring during > thread startup ... the VM signal handlers are probably already in place > but the thread doesn't have enough VM context to be processed by the > error handling code ... which is eerily similar to something I've seen > on linux on rare occasions ... > > David Holmes > > > > David Sitsky said the following on 02/19/09 14:42: >> Hi Daniel, >> >> Thanks for your reply. FWIW, a number of stacks I have don't mention >> AsyncGetCallTrace, so perhaps procexp has done a bit of mis-reporting >> there. However, all stacks seem to have this kind of pattern: >> >> ntoskrnl.exe!ExpInterlockedFlushSList+0x126f >> ntoskrnl.exe!KeWaitForMultipleObjects+0xcca >> ntoskrnl.exe!KeWaitForMutexObject+0x2da >> ntoskrnl.exe!_misaligned_access+0x35 >> ntoskrnl.exe!MmUnlockPages+0x1160 >> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >> >> [a bunch of jvm.dll calls] >> >> msvcrt.dll!free_dbg+0x147 >> msvcrt.dll!beginthreadex+0x131 >> kernel32.dll!BaseThreadInitThunk+0xd >> ntdll.dll!RtlUserThreadStart+0x21 >> >> or a slight variant: >> >> ntoskrnl.exe!ExpInterlockedFlushSList+0x126f >> ntoskrnl.exe!RtlNumberOfClearBits+0x5cc >> ntoskrnl.exe!ExpInterlockedFlushSList+0x134d >> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >> >> [a bunch of jvm.dll calls] >> >> msvcrt.dll!free_dbg+0x147 >> msvcrt.dll!beginthreadex+0x131 >> kernel32.dll!BaseThreadInitThunk+0xd >> ntdll.dll!RtlUserThreadStart+0x21 >> >> Any ideas anyone? >> >> The call to IoAcquireCancelSpinLock seems to be always the first call >> outside for jvm.dll in all these stack traces.. >> >> Cheers, >> David >> >> Daniel D. Daugherty wrote: >>> David, >>> >>> I'm not sure about the rest of your problem, but the >>> mentions of "AsyncGetCallTrace" in your stacks don't >>> mean anything on Windows. It happens to be the nearest >>> named function that the stack trace stuff found. >>> >>> The AsyncGetCallTrace() API isn't supported on Windows >>> and there isn't any code in Sun's JDK that calls >>> AsyncGetCallTrace() on Windows. >>> >>> Hopefully someone else will have more information on >>> what is really happening here. >>> >>> Dan >>> >>> >>> David Sitsky wrote: >>>> I apologise in advance if this is a "breach of protocol". I have >>>> submitted a bug through the usual channels, but my experience with >>>> this approach unfortunately has usually been a dead-end. >>>> >>>> I have a very intensive data application (I/O + CPU + memory) on the >>>> Windows platform that reliably causes a 100% CPU lockup, but only >>>> for the x64 distribution (jdk 1.6.0_07, 1.6.0_10 and 1.6.0_12). >>>> When using the x32 distribution on the same machines it works fine. >>>> It is not machine-specific - I have seen this across 7 different >>>> machines, and it seems to occur after a few to several hours of >>>> processing. The JVM is still responsive, but extremely slow. >>>> >>>> Using process explorer, I was able to find the thread in the process >>>> consuming all the CPU. The stack traces from procexp have the same >>>> thread ID as the "VM Thread" from jstack. The stacks are usually >>>> something like the following: >>>> >>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x126f >>>> ntoskrnl.exe!RtlNumberOfClearBits+0x5cc >>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x134d >>>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>>> jvm.dll!AsyncGetCallTrace+0x3ac7f >>>> jvm.dll!JVM_FindSignal+0xe4533 >>>> jvm.dll!JVM_FindSignal+0x10fa2e >>>> jvm.dll!JVM_FindSignal+0xe3eef >>>> jvm.dll!JVM_FindSignal+0x14d61d >>>> jvm.dll!JVM_FindSignal+0x14dabc >>>> jvm.dll!JVM_FindSignal+0x1593e0 >>>> jvm.dll!JVM_FindSignal+0x12a374 >>>> jvm.dll!JVM_FindSignal+0x2167d3 >>>> jvm.dll!JVM_FindSignal+0x2193e8 >>>> jvm.dll!JVM_FindSignal+0x218274 >>>> jvm.dll!JVM_FindSignal+0x2186ca >>>> jvm.dll!JVM_FindSignal+0x218cd2 >>>> jvm.dll!JVM_FindSignal+0x11d7f9 >>>> msvcrt.dll!free_dbg+0x147 >>>> msvcrt.dll!beginthreadex+0x131 >>>> kernel32.dll!BaseThreadInitThunk+0xd >>>> ntdll.dll!RtlUserThreadStart+0x21 >>>> >>>> or >>>> >>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x126f >>>> ntoskrnl.exe!KeWaitForMultipleObjects+0xcca >>>> ntoskrnl.exe!KeWaitForMutexObject+0x2da >>>> ntoskrnl.exe!_misaligned_access+0x35 >>>> ntoskrnl.exe!MmUnlockPages+0x1160 >>>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>>> jvm.dll!AsyncGetCallTrace+0x3ac7f >>>> jvm.dll!JVM_FindSignal+0xe3eef >>>> jvm.dll!JVM_FindSignal+0x14d61d >>>> jvm.dll!JVM_FindSignal+0x14dabc >>>> jvm.dll!JVM_FindSignal+0x1593e0 >>>> jvm.dll!JVM_FindSignal+0x12a374 >>>> jvm.dll!JVM_FindSignal+0x2167d3 >>>> jvm.dll!JVM_FindSignal+0x2193e8 >>>> jvm.dll!JVM_FindSignal+0x218274 >>>> jvm.dll!JVM_FindSignal+0x2186ca >>>> jvm.dll!JVM_FindSignal+0x218cd2 >>>> jvm.dll!JVM_FindSignal+0x11d7f9 >>>> msvcrt.dll!free_dbg+0x147 >>>> msvcrt.dll!beginthreadex+0x131 >>>> kernel32.dll!BaseThreadInitThunk+0xd >>>> ntdll.dll!RtlUserThreadStart+0x21 >>>> >>>> or (without AsyncGetCallTrace): >>>> >>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x14a0 >>>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>>> jvm.dll!JVM_EnqueueOperation+0xb19f4 >>>> jvm.dll!JVM_FindSignal+0x1b7fcc >>>> jvm.dll!JVM_FindSignal+0x14dcca >>>> jvm.dll!JVM_FindSignal+0x14e17c >>>> jvm.dll!JVM_FindSignal+0x159b80 >>>> jvm.dll!JVM_FindSignal+0x12a5e4 >>>> jvm.dll!JVM_FindSignal+0x216e53 >>>> jvm.dll!JVM_FindSignal+0x219a38 >>>> jvm.dll!JVM_FindSignal+0x2188d4 >>>> jvm.dll!JVM_FindSignal+0x218d2a >>>> jvm.dll!JVM_FindSignal+0x219332 >>>> jvm.dll!JVM_FindSignal+0x11da99 >>>> msvcrt.dll!free_dbg+0x147 >>>> msvcrt.dll!beginthreadex+0x131 >>>> kernel32.dll!BaseThreadInitThunk+0xd >>>> ntdll.dll!RtlUserThreadStart+0x21 >>>> >>>> I am more than happy to run test/debug versions in order to assist >>>> in tracking this down. I wish I could say, here is a unit test, but >>>> its a very complex application with complex data processing. The >>>> only good news is it seems to be quite reproduceable on our systems. >>>> >>>> Apologies again in advance if this was an inappropriate place to >>>> post. But given the severity of this issue, I am hoping somebody >>>> here will be interested in it.. >>>> >> >> From gbenson at redhat.com Thu Feb 19 04:51:42 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 19 Feb 2009 12:51:42 +0000 Subject: How to trace the hotspot bytecode interpreter In-Reply-To: <22091780.post@talk.nabble.com> References: <22091780.post@talk.nabble.com> Message-ID: <20090219125142.GB970@redhat.com> Hi Colin, What platform are you using? If you are on x86, x86_64 or sparc (and you haven't messed with the build to enable the C++ interpreter) then nothing in bytecodeInterpreter.cpp is ever used. Cheers, Gary Colin(Du Li) wrote: > I know the byte interpreter implementation is mainly in > bytecodeInterpreter.cpp, but it doesn't allow me set break point in > this file. I wanna trace the bytecode interpreter. Where can I put > break pointer? Where is the entrance to bytecodeInterpreter.cpp, > that is, in Hotpot, which classes will call the methods in > bytecodeInterpreter.cpp? > Thanks. -- http://gbenson.net/ From dawn2004 at gmail.com Thu Feb 19 07:35:24 2009 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Thu, 19 Feb 2009 07:35:24 -0800 (PST) Subject: How to trace the hotspot bytecode interpreter In-Reply-To: <20090219125142.GB970@redhat.com> References: <22091780.post@talk.nabble.com> <20090219125142.GB970@redhat.com> Message-ID: <22103043.post@talk.nabble.com> Hi Gary, I use x86. You mean bytecodeInterpreter is useless? Then where is the bytecode interpreter codes in Hotspot? e.g. where is the instruction, such as "getField", been interpreted and executed? Thanks a lot! Colin Gary Benson wrote: > > Hi Colin, > > What platform are you using? If you are on x86, x86_64 or sparc (and > you haven't messed with the build to enable the C++ interpreter) then > nothing in bytecodeInterpreter.cpp is ever used. > > Cheers, > Gary > > Colin(Du Li) wrote: >> I know the byte interpreter implementation is mainly in >> bytecodeInterpreter.cpp, but it doesn't allow me set break point in >> this file. I wanna trace the bytecode interpreter. Where can I put >> break pointer? Where is the entrance to bytecodeInterpreter.cpp, >> that is, in Hotpot, which classes will call the methods in >> bytecodeInterpreter.cpp? >> Thanks. > > -- > http://gbenson.net/ > > -- View this message in context: http://www.nabble.com/How-to-trace-the-hotspot-bytecode-interpreter-tp22091780p22103043.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From gbenson at redhat.com Thu Feb 19 07:52:50 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 19 Feb 2009 15:52:50 +0000 Subject: How to trace the hotspot bytecode interpreter In-Reply-To: <22103043.post@talk.nabble.com> References: <22091780.post@talk.nabble.com> <20090219125142.GB970@redhat.com> <22103043.post@talk.nabble.com> Message-ID: <20090219155250.GE31986@redhat.com> For x86 you need the template interpreter. The code that executes bytecodes exists as fragments of assembly language, generated by code in hotspot/src/cpu/x86/vm/templateInterpreter_x86_32.cpp or hotspot/src/cpu/x86/vm/templateInterpreter_x86_64.cpp. Cheers, Gary Colin(Du Li) wrote: > Hi Gary, > > I use x86. You mean bytecodeInterpreter is useless? > Then where is the bytecode interpreter codes in Hotspot? > e.g. where is the instruction, such as "getField", been interpreted > and executed? > > Thanks a lot! > > Colin > > Gary Benson wrote: > > Hi Colin, > > > > What platform are you using? If you are on x86, x86_64 or sparc (and > > you haven't messed with the build to enable the C++ interpreter) then > > nothing in bytecodeInterpreter.cpp is ever used. > > > > Cheers, > > Gary > > > > Colin(Du Li) wrote: > > > I know the byte interpreter implementation is mainly in > > > bytecodeInterpreter.cpp, but it doesn't allow me set break point in > > > this file. I wanna trace the bytecode interpreter. Where can I put > > > break pointer? Where is the entrance to bytecodeInterpreter.cpp, > > > that is, in Hotpot, which classes will call the methods in > > > bytecodeInterpreter.cpp? > > > Thanks. -- http://gbenson.net/ From dawn2004 at gmail.com Thu Feb 19 08:24:45 2009 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Thu, 19 Feb 2009 08:24:45 -0800 (PST) Subject: How to trace the hotspot bytecode interpreter In-Reply-To: <20090219155250.GE31986@redhat.com> References: <22091780.post@talk.nabble.com> <20090219125142.GB970@redhat.com> <22103043.post@talk.nabble.com> <20090219155250.GE31986@redhat.com> Message-ID: <22104126.post@talk.nabble.com> Hi, Gary, Thank you very much for your explanation! I still have two questions. 1. If I wanna add a read barrier to bytecode interpreter, which will trap all the object access in bytecode, where should I put this read barrier? 2. What is the bytecodeInterpreter.cpp used for? It seems to have a lot of bytecode interpreter thing as follows: CASE(_aload): SET_STACK_OBJECT(LOCALS_OBJECT(pc[1]), 0); UPDATE_PC_AND_TOS_AND_CONTINUE(2, 1); Thanks again! Colin Gary Benson wrote: > > For x86 you need the template interpreter. The code that executes > bytecodes exists as fragments of assembly language, generated by code > in hotspot/src/cpu/x86/vm/templateInterpreter_x86_32.cpp or > hotspot/src/cpu/x86/vm/templateInterpreter_x86_64.cpp. > > Cheers, > Gary > > Colin(Du Li) wrote: >> Hi Gary, >> >> I use x86. You mean bytecodeInterpreter is useless? >> Then where is the bytecode interpreter codes in Hotspot? >> e.g. where is the instruction, such as "getField", been interpreted >> and executed? >> >> Thanks a lot! >> >> Colin >> >> Gary Benson wrote: >> > Hi Colin, >> > >> > What platform are you using? If you are on x86, x86_64 or sparc (and >> > you haven't messed with the build to enable the C++ interpreter) then >> > nothing in bytecodeInterpreter.cpp is ever used. >> > >> > Cheers, >> > Gary >> > >> > Colin(Du Li) wrote: >> > > I know the byte interpreter implementation is mainly in >> > > bytecodeInterpreter.cpp, but it doesn't allow me set break point in >> > > this file. I wanna trace the bytecode interpreter. Where can I put >> > > break pointer? Where is the entrance to bytecodeInterpreter.cpp, >> > > that is, in Hotpot, which classes will call the methods in >> > > bytecodeInterpreter.cpp? >> > > Thanks. > > -- > http://gbenson.net/ > > -- View this message in context: http://www.nabble.com/How-to-trace-the-hotspot-bytecode-interpreter-tp22091780p22104126.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From gbenson at redhat.com Thu Feb 19 08:40:29 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 19 Feb 2009 16:40:29 +0000 Subject: How to trace the hotspot bytecode interpreter In-Reply-To: <22104126.post@talk.nabble.com> References: <22091780.post@talk.nabble.com> <20090219125142.GB970@redhat.com> <22103043.post@talk.nabble.com> <20090219155250.GE31986@redhat.com> <22104126.post@talk.nabble.com> Message-ID: <20090219164029.GB30223@redhat.com> Colin(Du Li) wrote: > Thank you very much for your explanation! No problem :) > I still have two questions. > 1. If I wanna add a read barrier to bytecode interpreter, which will > trap all the object access in bytecode, where should I put this read > barrier? I don't know, I'm not familiar with the template interpreter. > 2. What is the bytecodeInterpreter.cpp used for? It seems to have a > lot of bytecode interpreter thing as follows: > CASE(_aload): > SET_STACK_OBJECT(LOCALS_OBJECT(pc[1]), 0); > UPDATE_PC_AND_TOS_AND_CONTINUE(2, 1); The stuff in bytecodeInterpreter.cpp is used for platforms other than X86 and Sparc. At Red Hat we use it on PowerPC, ARM, zSeries, IA-64, and probably others I forgot. Cheers, Gary -- http://gbenson.net/ From Thomas.Rodriguez at Sun.COM Thu Feb 19 14:06:36 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 19 Feb 2009 14:06:36 -0800 Subject: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application In-Reply-To: <499CA7D9.9040903@nuix.com> References: <499CA7D9.9040903@nuix.com> Message-ID: <4E0D3F42-021A-4D48-888E-594A5980D0E1@sun.com> Have you tried using jconsole or -verbose:gc to watch your app? Maybe it's running low on heap and spending too much time in GC. tom On Feb 18, 2009, at 4:29 PM, David Sitsky wrote: > I apologise in advance if this is a "breach of protocol". I have > submitted a bug through the usual channels, but my experience with > this approach unfortunately has usually been a dead-end. > > I have a very intensive data application (I/O + CPU + memory) on the > Windows platform that reliably causes a 100% CPU lockup, but only > for the x64 distribution (jdk 1.6.0_07, 1.6.0_10 and 1.6.0_12). > When using the x32 distribution on the same machines it works fine. > It is not machine-specific - I have seen this across 7 different > machines, and it seems to occur after a few to several hours of > processing. The JVM is still responsive, but extremely slow. > > Using process explorer, I was able to find the thread in the process > consuming all the CPU. The stack traces from procexp have the same > thread ID as the "VM Thread" from jstack. The stacks are usually > something like the following: > > ntoskrnl.exe!ExpInterlockedFlushSList+0x126f > ntoskrnl.exe!RtlNumberOfClearBits+0x5cc > ntoskrnl.exe!ExpInterlockedFlushSList+0x134d > ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 > jvm.dll!AsyncGetCallTrace+0x3ac7f > jvm.dll!JVM_FindSignal+0xe4533 > jvm.dll!JVM_FindSignal+0x10fa2e > jvm.dll!JVM_FindSignal+0xe3eef > jvm.dll!JVM_FindSignal+0x14d61d > jvm.dll!JVM_FindSignal+0x14dabc > jvm.dll!JVM_FindSignal+0x1593e0 > jvm.dll!JVM_FindSignal+0x12a374 > jvm.dll!JVM_FindSignal+0x2167d3 > jvm.dll!JVM_FindSignal+0x2193e8 > jvm.dll!JVM_FindSignal+0x218274 > jvm.dll!JVM_FindSignal+0x2186ca > jvm.dll!JVM_FindSignal+0x218cd2 > jvm.dll!JVM_FindSignal+0x11d7f9 > msvcrt.dll!free_dbg+0x147 > msvcrt.dll!beginthreadex+0x131 > kernel32.dll!BaseThreadInitThunk+0xd > ntdll.dll!RtlUserThreadStart+0x21 > > or > > ntoskrnl.exe!ExpInterlockedFlushSList+0x126f > ntoskrnl.exe!KeWaitForMultipleObjects+0xcca > ntoskrnl.exe!KeWaitForMutexObject+0x2da > ntoskrnl.exe!_misaligned_access+0x35 > ntoskrnl.exe!MmUnlockPages+0x1160 > ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 > jvm.dll!AsyncGetCallTrace+0x3ac7f > jvm.dll!JVM_FindSignal+0xe3eef > jvm.dll!JVM_FindSignal+0x14d61d > jvm.dll!JVM_FindSignal+0x14dabc > jvm.dll!JVM_FindSignal+0x1593e0 > jvm.dll!JVM_FindSignal+0x12a374 > jvm.dll!JVM_FindSignal+0x2167d3 > jvm.dll!JVM_FindSignal+0x2193e8 > jvm.dll!JVM_FindSignal+0x218274 > jvm.dll!JVM_FindSignal+0x2186ca > jvm.dll!JVM_FindSignal+0x218cd2 > jvm.dll!JVM_FindSignal+0x11d7f9 > msvcrt.dll!free_dbg+0x147 > msvcrt.dll!beginthreadex+0x131 > kernel32.dll!BaseThreadInitThunk+0xd > ntdll.dll!RtlUserThreadStart+0x21 > > or (without AsyncGetCallTrace): > > ntoskrnl.exe!ExpInterlockedFlushSList+0x14a0 > ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 > jvm.dll!JVM_EnqueueOperation+0xb19f4 > jvm.dll!JVM_FindSignal+0x1b7fcc > jvm.dll!JVM_FindSignal+0x14dcca > jvm.dll!JVM_FindSignal+0x14e17c > jvm.dll!JVM_FindSignal+0x159b80 > jvm.dll!JVM_FindSignal+0x12a5e4 > jvm.dll!JVM_FindSignal+0x216e53 > jvm.dll!JVM_FindSignal+0x219a38 > jvm.dll!JVM_FindSignal+0x2188d4 > jvm.dll!JVM_FindSignal+0x218d2a > jvm.dll!JVM_FindSignal+0x219332 > jvm.dll!JVM_FindSignal+0x11da99 > msvcrt.dll!free_dbg+0x147 > msvcrt.dll!beginthreadex+0x131 > kernel32.dll!BaseThreadInitThunk+0xd > ntdll.dll!RtlUserThreadStart+0x21 > > I am more than happy to run test/debug versions in order to assist > in tracking this down. I wish I could say, here is a unit test, but > its a very complex application with complex data processing. The > only good news is it seems to be quite reproduceable on our systems. > > Apologies again in advance if this was an inappropriate place to > post. But given the severity of this issue, I am hoping somebody > here will be interested in it.. > > -- > Cheers, > David > > Nuix Pty Ltd > Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 > 0699 > Web: http://www.nuix.com Fax: +61 2 9212 > 6902 From Christian.Thalinger at Sun.COM Fri Feb 20 01:58:57 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 20 Feb 2009 10:58:57 +0100 Subject: merge vm_version_x86_{32,64}.hpp Message-ID: <1235123937.11128.10.camel@localhost.localdomain> Hi! While adding some code to vm_version_x86_{32,64}.hpp, I wonder if it would be worth to merge these two into a single vm_version_x86.hpp and leave the (very small) differences in their own files? Would make things a bit easier... Maybe this could also be done for the .cpp part. -- Christian From heiko.wagner at apis.de Fri Feb 20 02:23:56 2009 From: heiko.wagner at apis.de (Heiko Wagner) Date: Fri, 20 Feb 2009 11:23:56 +0100 Subject: Unicode support in Java VM on Windows Message-ID: Hi, I am currently investigating on a problem of the Java VM on Windows. The VM is started using the JNI invocation api. This works unless the path contains non-ansi characters. So I hacked the classpath with addURLToAppClassLoader() in sun.misc.Launcher. I at least could make a shared JRE installation, started from a ansi path, find my JARs. Since one of my JARs does use native code I then got stuck at the System.loadLibrary() call. Hacking the correct path into the 'usr_paths' field into the ClassLoader did not help, because the actual Windows API call LoadLibrary() seems to be ansi flavour instead of wide char api. Would it be possible to make this two enhancements without hurting the Java VM spec?: 1) fill the property java.class.path from the env variable CLASSPATH with a call to GetEnvironmentVariableW instead of GetEnvironmentVariableA to enable setting the classpath with unicode characters 2) fill the property java.library.path and issue the actual LoadLibrary with appropriate wide char api >From a quick look at the VM source I found out, that most string operations use the ANSI C string functions. Maybe it would be possible to use UTF-8 encoding to transfer the path strings throu the Java VM routines to the final Windows API calls, to avoid large changes in the code base. Regards Heiko Wagner From Paul.Hohensee at Sun.COM Fri Feb 20 08:35:44 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Fri, 20 Feb 2009 11:35:44 -0500 Subject: merge vm_version_x86_{32,64}.hpp In-Reply-To: <1235123937.11128.10.camel@localhost.localdomain> References: <1235123937.11128.10.camel@localhost.localdomain> Message-ID: <499EDBE0.1000504@sun.com> Feel free. :) In general, if you're changing things somewhere, feel free to refactor. Paul Christian Thalinger wrote: > Hi! > > While adding some code to vm_version_x86_{32,64}.hpp, I wonder if it > would be worth to merge these two into a single vm_version_x86.hpp and > leave the (very small) differences in their own files? Would make > things a bit easier... > > Maybe this could also be done for the .cpp part. > > -- Christian > > From gnu_andrew at member.fsf.org Fri Feb 20 08:42:06 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 20 Feb 2009 16:42:06 +0000 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: <1235035430.3597.14.camel@hermans.wildebeest.org> References: <20090212150029.GA1121@rivendell.middle-earth.co.uk> <17c6771e0902151453t523b15derfc243ffaa201264f@mail.gmail.com> <1234768690.24153.28.camel@localhost.localdomain> <1234772748.3612.3.camel@hermans.wildebeest.org> <1234774554.11228.3.camel@localhost.localdomain> <1234862105.4062.8.camel@fedora.wildebeest.org> <1234950462.2322.9.camel@fedora.wildebeest.org> <1234951783.5094.17.camel@localhost.localdomain> <1235035430.3597.14.camel@hermans.wildebeest.org> Message-ID: <17c6771e0902200842l15c7b892rcd352de3286aafbd@mail.gmail.com> 2009/2/19 Mark Wielaard : > Hi Christian, > > On Wed, 2009-02-18 at 11:09 +0100, Christian Thalinger wrote: >> On Wed, 2009-02-18 at 10:47 +0100, Mark Wielaard wrote: >> > Yes, my plan was to branch at the commit just before the HS15 tag in >> > jdk7/jdk7/hotspot appeared. But it would be good to get confirmation >> > that is the right branch point. >> >> I can look that up again... ?The changeset right before the fork is: >> >> fc6a5ae3fef5 >> >> which bumps the HotSpot version to 14.0-b10. > > Thanks. I am waiting for Joe to reveal the open hs14 repo that he wants > to base openjdk6 on first though before creating another one for now. > Unless that takes too long of course, then we can always start tracking > from that revision. > We can bump IcedTea6 to that revision now with a one-line change, then wait for post-14 changes from a backported HotSpot tree. >> But I was also told that 14 isn't stable yet, it's just in the >> stabilization phase. ?When you really want something rock solid you >> should go with HS11. > > Yes, you can even get this with icedtea configure > --with-hotspot-build=original but that needs more patches (e.g for sparc > support) and for zero/shark it is too old, so it needs too much > backporting to keep current in the long run. > Now we are post 1.4, the plan is to drop support for that, unless someone is interested in maintaining it. Anyone? > Cheers, > > Mark > > -- 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 gnu_andrew at member.fsf.org Fri Feb 20 08:44:39 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 20 Feb 2009 16:44:39 +0000 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: References: <20090212150029.GA1121@rivendell.middle-earth.co.uk> <1234731237.3562.6.camel@hermans.wildebeest.org> <17c6771e0902151453t523b15derfc243ffaa201264f@mail.gmail.com> <1234768690.24153.28.camel@localhost.localdomain> <1234772748.3612.3.camel@hermans.wildebeest.org> <1234774554.11228.3.camel@localhost.localdomain> <1234862105.4062.8.camel@fedora.wildebeest.org> Message-ID: <17c6771e0902200844r2b1033a2xf614a8ae1edefe64@mail.gmail.com> 2009/2/17 Volker Simonis : > As far as I understand the procedure, the HS14 has been branched at > some time in the past and is now "stabilized" in an Sun-internal > repository in order to become the next, officially released "Express" > VM for JDK6. It's quite sad that, here we are, nearly two years after OpenJDK was released (and more than two years for HotSpot), yet no-one thought that this should have been done in an open and transparent way. What exactly is special about this internal tree that this couldn't just have been done on hg.openjdk.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 aph at redhat.com Fri Feb 20 09:35:04 2009 From: aph at redhat.com (Andrew Haley) Date: Fri, 20 Feb 2009 17:35:04 +0000 Subject: Template interpreter::notice_safepoints() Message-ID: <499EE9C8.7090609@redhat.com> I'm having a little difficulty understanding how the template interpreter is safe on SMP machines. notice_safepoints() looks like this: void TemplateInterpreter::notice_safepoints() { if (!_notice_safepoints) { // switch to safepoint dispatch table _notice_safepoints = true; copy_table((address*)&_safept_table, (address*)&_active_table, sizeof(_active_table) / sizeof(address)); } } So, the dispatch table is rewritten. But on an SMP machine with weak cache coherency, how does this work? A thread could be executing bytecodes in a loop but never see the change to _active_table because there's nothing to cause its cache to be updated. Is it simply that this code doesn't work on such architectures? Andrew. From James.Melvin at Sun.COM Fri Feb 20 09:42:01 2009 From: James.Melvin at Sun.COM (James Melvin) Date: Fri, 20 Feb 2009 12:42:01 -0500 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: <17c6771e0902200844r2b1033a2xf614a8ae1edefe64@mail.gmail.com> References: <20090212150029.GA1121@rivendell.middle-earth.co.uk> <1234731237.3562.6.camel@hermans.wildebeest.org> <17c6771e0902151453t523b15derfc243ffaa201264f@mail.gmail.com> <1234768690.24153.28.camel@localhost.localdomain> <1234772748.3612.3.camel@hermans.wildebeest.org> <1234774554.11228.3.camel@localhost.localdomain> <1234862105.4062.8.camel@fedora.wildebeest.org> <17c6771e0902200844r2b1033a2xf614a8ae1edefe64@mail.gmail.com> Message-ID: <499EEB69.1060605@sun.com> Hi Andrew, The basic reasoning behind the HS14 fork is two-fold... 1) Lock down HS14 for extensive product-level testing and stabilization 2) Open HS15 for new work, some of which may require extended bake time Work on the HS14 internal repository is also pushed to the OpenJDK repository (now HS15). So, this is just a means to isolate one of many moving parts in Java SE for productization and delivery. - Jim Andrew John Hughes wrote: > 2009/2/17 Volker Simonis : >> As far as I understand the procedure, the HS14 has been branched at >> some time in the past and is now "stabilized" in an Sun-internal >> repository in order to become the next, officially released "Express" >> VM for JDK6. > > It's quite sad that, here we are, nearly two years after OpenJDK was > released (and more than two years for HotSpot), yet no-one thought > that this should have been done in an open and transparent way. What > exactly is special about this internal tree that this couldn't just > have been done on hg.openjdk.net? From Thomas.Rodriguez at Sun.COM Fri Feb 20 10:05:07 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 20 Feb 2009 10:05:07 -0800 Subject: Template interpreter::notice_safepoints() In-Reply-To: <499EE9C8.7090609@redhat.com> References: <499EE9C8.7090609@redhat.com> Message-ID: <20F9DFB3-CF58-4390-A423-50E41F6E7A7F@sun.com> All the ia64 ports currently use the C++ interpreter so I wouldn't be surprised if there are weak cache consistency problems in the template interpreter. In practice though you can't run forever in the interpreter without going into the runtime at least for a backward branch overflow. copy_table probably needs to use release_store_ptr and the reads from the table may need to use a load acquire but I'd suspect there would be other issues as well. tom On Feb 20, 2009, at 9:35 AM, Andrew Haley wrote: > I'm having a little difficulty understanding how the template > interpreter > is safe on SMP machines. > > notice_safepoints() looks like this: > > void TemplateInterpreter::notice_safepoints() { > if (!_notice_safepoints) { > // switch to safepoint dispatch table > _notice_safepoints = true; > copy_table((address*)&_safept_table, (address*)&_active_table, > sizeof(_active_table) / sizeof(address)); > } > } > > So, the dispatch table is rewritten. But on an SMP machine with > weak cache coherency, how does this work? A thread could be > executing bytecodes in a loop but never see the change to > _active_table > because there's nothing to cause its cache to be updated. Is it > simply that this code doesn't work on such architectures? > > Andrew. From gnu_andrew at member.fsf.org Fri Feb 20 10:17:27 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 20 Feb 2009 18:17:27 +0000 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: <499EEB69.1060605@sun.com> References: <20090212150029.GA1121@rivendell.middle-earth.co.uk> <1234731237.3562.6.camel@hermans.wildebeest.org> <17c6771e0902151453t523b15derfc243ffaa201264f@mail.gmail.com> <1234768690.24153.28.camel@localhost.localdomain> <1234772748.3612.3.camel@hermans.wildebeest.org> <1234774554.11228.3.camel@localhost.localdomain> <1234862105.4062.8.camel@fedora.wildebeest.org> <17c6771e0902200844r2b1033a2xf614a8ae1edefe64@mail.gmail.com> <499EEB69.1060605@sun.com> Message-ID: <17c6771e0902201017h79c40662xd9423813306e2f7f@mail.gmail.com> 2009/2/20 James Melvin : > Hi Andrew, > > The basic reasoning behind the HS14 fork is two-fold... > > 1) Lock down HS14 for extensive product-level testing and stabilization > 2) Open HS15 for new work, some of which may require extended bake time > > Work on the HS14 internal repository is also pushed to the OpenJDK > repository (now HS15). So, this is just a means to isolate one of many > moving parts in Java SE for productization and delivery. > > - Jim > > > > > > > > Andrew John Hughes wrote: >> >> 2009/2/17 Volker Simonis : >>> >>> As far as I understand the procedure, the HS14 has been branched at >>> some time in the past and is now "stabilized" in an Sun-internal >>> repository in order to become the next, officially released "Express" >>> VM for JDK6. >> >> It's quite sad that, here we are, nearly two years after OpenJDK was >> released (and more than two years for HotSpot), yet no-one thought >> that this should have been done in an open and transparent way. ?What >> exactly is special about this internal tree that this couldn't just >> have been done on hg.openjdk.net? > Hi Jim, I quite agree with the reasons for the branch, that in itself is a very sensible approach. My issue was with why the stable branch, when created, was not simply done publicly. It's not like anyone can just commit anything they want to it anyway, and a stable HotSpot is valuable for others outside Sun. -- 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 Paul.Hohensee at Sun.COM Fri Feb 20 10:47:51 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Fri, 20 Feb 2009 13:47:51 -0500 Subject: Template interpreter::notice_safepoints() In-Reply-To: <20F9DFB3-CF58-4390-A423-50E41F6E7A7F@sun.com> References: <499EE9C8.7090609@redhat.com> <20F9DFB3-CF58-4390-A423-50E41F6E7A7F@sun.com> Message-ID: <499EFAD7.4090708@sun.com> I believe the safepoint code (safepoint.cpp) switches the interpreter dispatch table, then protects the polling page via mprotect(). mprotect() has the effect of a system-wide memory barrier (because it requires the OS to issue a global TLB shootdown), so the new dispatch table address will be flushed to memory in a timely fashion. I think this is a case of "the sum of the bugs is zero", because I don't think we ever really thought about it. All that aside, I don't know of any SMP that requires programmatic intervention to synchronize a write across all caches. As long as the write happens "eventually", which means in a short enough time to make safepoints "short", I don't think there's a problem Paul Tom Rodriguez wrote: > All the ia64 ports currently use the C++ interpreter so I wouldn't be > surprised if there are weak cache consistency problems in the template > interpreter. In practice though you can't run forever in the > interpreter without going into the runtime at least for a backward > branch overflow. copy_table probably needs to use release_store_ptr > and the reads from the table may need to use a load acquire but I'd > suspect there would be other issues as well. > > tom > > On Feb 20, 2009, at 9:35 AM, Andrew Haley wrote: > >> I'm having a little difficulty understanding how the template >> interpreter >> is safe on SMP machines. >> >> notice_safepoints() looks like this: >> >> void TemplateInterpreter::notice_safepoints() { >> if (!_notice_safepoints) { >> // switch to safepoint dispatch table >> _notice_safepoints = true; >> copy_table((address*)&_safept_table, (address*)&_active_table, >> sizeof(_active_table) / sizeof(address)); >> } >> } >> >> So, the dispatch table is rewritten. But on an SMP machine with >> weak cache coherency, how does this work? A thread could be >> executing bytecodes in a loop but never see the change to _active_table >> because there's nothing to cause its cache to be updated. Is it >> simply that this code doesn't work on such architectures? >> >> Andrew. > From mr at sun.com Fri Feb 20 12:22:51 2009 From: mr at sun.com (Mark Reinhold) Date: Fri, 20 Feb 2009 12:22:51 -0800 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: gnu_andrew@member.fsf.org; Fri, 20 Feb 2009 18:17:27 GMT; <17c6771e0902201017h79c40662xd9423813306e2f7f@mail.gmail.com> Message-ID: <20090220202251.C6173291845@eggemoggin.niobe.net> > Date: Fri, 20 Feb 2009 18:17:27 +0000 > From: Andrew John Hughes > 2009/2/20 james.melvin at sun.com: >> The basic reasoning behind the HS14 fork is two-fold... >> >> ... > > I quite agree with the reasons for the branch, that in itself is a > very sensible approach. My issue was with why the stable branch, when > created, was not simply done publicly. It's not like anyone can just > commit anything they want to it anyway, and a stable HotSpot is > valuable for others outside Sun. As I understand it, the real reason the fork of HS14 wasn't done in the open is fairly prosaic: Sun's proprietary 6uX update releases are still based on TeamWare, our old internal SCM, rather than Mercurial. When a HotSpot "Express" snapshot is taken from JDK 7 it's first converted into TeamWare, and that's where the stabilization work is done. Joe Darcy has been working with the HotSpot team to revise this practice so that such work can take place in the open. Hopefully he'll have some news on that soon. - Mark From James.Melvin at Sun.COM Fri Feb 20 12:58:23 2009 From: James.Melvin at Sun.COM (James Melvin) Date: Fri, 20 Feb 2009 15:58:23 -0500 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: <20090220202251.C6173291845@eggemoggin.niobe.net> References: <20090220202251.C6173291845@eggemoggin.niobe.net> Message-ID: <499F196F.4030002@sun.com> Hi Mark, Actually, the Hotspot engineering work is all done in Mercurial. For the JDK6 RE build, we lazily create a disposable Teamware workspace from the Mercurial repository... hotspot.gpl - Mercurial (read-write) hotspot - Teamware (read-only, regenerated for builds) This mitigates the Mercurial <--> Teamware SCM nightmares. - Jim Mark Reinhold wrote: >> Date: Fri, 20 Feb 2009 18:17:27 +0000 >> From: Andrew John Hughes > >> 2009/2/20 james.melvin at sun.com: >>> The basic reasoning behind the HS14 fork is two-fold... >>> >>> ... >> I quite agree with the reasons for the branch, that in itself is a >> very sensible approach. My issue was with why the stable branch, when >> created, was not simply done publicly. It's not like anyone can just >> commit anything they want to it anyway, and a stable HotSpot is >> valuable for others outside Sun. > > As I understand it, the real reason the fork of HS14 wasn't done in the > open is fairly prosaic: Sun's proprietary 6uX update releases are still > based on TeamWare, our old internal SCM, rather than Mercurial. When a > HotSpot "Express" snapshot is taken from JDK 7 it's first converted into > TeamWare, and that's where the stabilization work is done. > > Joe Darcy has been working with the HotSpot team to revise this practice > so that such work can take place in the open. Hopefully he'll have some > news on that soon. > > - Mark From mr at sun.com Fri Feb 20 13:01:40 2009 From: mr at sun.com (Mark Reinhold) Date: Fri, 20 Feb 2009 13:01:40 -0800 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: james.melvin@sun.com; Fri, 20 Feb 2009 15:58:23 EST; <499F196F.4030002@sun.com> Message-ID: <20090220210140.993B3291846@eggemoggin.niobe.net> > Date: Fri, 20 Feb 2009 15:58:23 -0500 > From: james.melvin at sun.com > Actually, the Hotspot engineering work is all done in Mercurial. Ah, good; it seems that I was misinformed. > For the JDK6 RE build, we lazily create a disposable Teamware > workspace from the Mercurial repository... > > hotspot.gpl - Mercurial (read-write) > hotspot - Teamware (read-only, regenerated for builds) > > This mitigates the Mercurial <--> Teamware SCM nightmares. It also makes it all the easier for the stabilization work to be done in the open. - Mark From dawn2004 at gmail.com Fri Feb 20 13:50:02 2009 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Fri, 20 Feb 2009 13:50:02 -0800 (PST) Subject: Is there any special process in Hotspot to adapt 64 bit address? Message-ID: <22129185.post@talk.nabble.com> Hi, guys, Because hotspot is developed for 32 bits address, I wonder if there is something, which might be a read barrier, to convert a 64 bit address to 32 bits address. If so, where is it? Thanks a lot! Du Li -- View this message in context: http://www.nabble.com/Is-there-any-special-process-in-Hotspot-to-adapt-64-bit-address--tp22129185p22129185.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From john.coomes at sun.com Fri Feb 20 15:51:53 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 20 Feb 2009 23:51:53 +0000 Subject: hg: jdk7/hotspot: Added tag jdk7-b48 for changeset 4ae9f4bfdb98 Message-ID: <20090220235153.E9AB1DC8F@hg.openjdk.java.net> Changeset: aee93a8992d2 Author: xdono Date: 2009-02-19 14:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/aee93a8992d2 Added tag jdk7-b48 for changeset 4ae9f4bfdb98 ! .hgtags From john.coomes at sun.com Fri Feb 20 15:54:28 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 20 Feb 2009 23:54:28 +0000 Subject: hg: jdk7/hotspot/corba: Added tag jdk7-b48 for changeset 0be222241fd4 Message-ID: <20090220235429.E99EDDC95@hg.openjdk.java.net> Changeset: d70978bc64bc Author: xdono Date: 2009-02-19 14:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/d70978bc64bc Added tag jdk7-b48 for changeset 0be222241fd4 ! .hgtags From john.coomes at sun.com Fri Feb 20 16:00:21 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 21 Feb 2009 00:00:21 +0000 Subject: hg: jdk7/hotspot/jaxp: Added tag jdk7-b48 for changeset 39de90eb4822 Message-ID: <20090221000023.351B0DC9C@hg.openjdk.java.net> Changeset: 5c1f24531903 Author: xdono Date: 2009-02-19 14:08 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/5c1f24531903 Added tag jdk7-b48 for changeset 39de90eb4822 ! .hgtags From john.coomes at sun.com Fri Feb 20 16:03:28 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 21 Feb 2009 00:03:28 +0000 Subject: hg: jdk7/hotspot/jaxws: Added tag jdk7-b48 for changeset 01e5dd31d0c1 Message-ID: <20090221000330.ED907DCA5@hg.openjdk.java.net> Changeset: 18ca864890f3 Author: xdono Date: 2009-02-19 14:08 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/18ca864890f3 Added tag jdk7-b48 for changeset 01e5dd31d0c1 ! .hgtags From john.coomes at sun.com Fri Feb 20 16:09:21 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 21 Feb 2009 00:09:21 +0000 Subject: hg: jdk7/hotspot/jdk: 50 new changesets Message-ID: <20090221002006.B9D80DCAD@hg.openjdk.java.net> Changeset: 53d9259661c3 Author: jccollet Date: 2009-01-27 11:36 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/53d9259661c3 6790677: java.net.HttpCookie.parse(String) should ignore unrecognized attributes, RFC2965 Summary: Changed code not to throw an exception on unknown attributes Reviewed-by: chegar ! src/share/classes/java/net/HttpCookie.java ! test/java/net/CookieHandler/TestHttpCookie.java Changeset: 6eac3829cb41 Author: martin Date: 2009-01-27 15:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6eac3829cb41 6797480: Remove synchronization bottleneck in logger Reviewed-by: swamyv Contributed-by: jeremymanson at google.com ! src/share/classes/java/util/logging/Logger.java Changeset: c2d2185a79dd Author: darcy Date: 2009-01-28 10:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c2d2185a79dd 6704655: Test test/java/lang/reflect/Generics/Probe.java fails under OpenJDK Reviewed-by: ksrini ! test/java/lang/reflect/Generics/Probe.java Changeset: 1ebbc958f06a Author: darcy Date: 2009-01-28 12:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1ebbc958f06a 6719182: update legal notice in java/lang/instrument/package.html Reviewed-by: jjh ! src/share/classes/java/lang/instrument/package.html Changeset: 6607850bd7fc Author: martin Date: 2009-01-28 14:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6607850bd7fc 6798822: (process) Non-portable use of isdigit in src/solaris/native/java/lang/UNIXProcess_md.c Reviewed-by: alanb Contributed-by: christos at zoulas.com ! src/solaris/native/java/lang/UNIXProcess_md.c Changeset: 7241bd422542 Author: darcy Date: 2009-01-29 09:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7241bd422542 6239194: Object.hashCode() should reference System.identityHashCode() Reviewed-by: emcmanus ! src/share/classes/java/lang/Object.java Changeset: ff9ad99b63cc Author: darcy Date: 2009-01-29 13:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ff9ad99b63cc 6327048: Enum javadoc could link to JLS 6653154: Exception message for bad Enum.valueOf has spurious "class" Reviewed-by: emcmanus ! src/share/classes/java/lang/Enum.java ! src/share/classes/java/lang/annotation/Annotation.java + test/java/lang/Enum/ValueOf.java Changeset: 483e5c97d438 Author: darcy Date: 2009-01-30 12:40 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/483e5c97d438 6799343: (fmt) java.util.Formatter uses plainlink instead of linkplain Reviewed-by: alanb ! src/share/classes/java/util/Formatter.java Changeset: d6881542bfef Author: michaelm Date: 2009-01-30 22:05 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d6881542bfef 4167874: URL-downloaded jar files can consume all available file descriptors Summary: added close method to URLClassLoader Reviewed-by: alanb ! src/share/classes/java/lang/RuntimePermission.java ! src/share/classes/java/net/URLClassLoader.java ! src/share/classes/sun/misc/URLClassPath.java + test/java/net/URLClassLoader/closetest/CloseTest.java + test/java/net/URLClassLoader/closetest/README + test/java/net/URLClassLoader/closetest/build.sh + test/java/net/URLClassLoader/closetest/serverRoot/Test.java + test/java/net/URLClassLoader/closetest/test1/com/foo/Resource1 + test/java/net/URLClassLoader/closetest/test1/com/foo/Resource2 + test/java/net/URLClassLoader/closetest/test1/com/foo/TestClass.java + test/java/net/URLClassLoader/closetest/test1/com/foo/TestClass1.java + test/java/net/URLClassLoader/closetest/test2/com/foo/Resource1 + test/java/net/URLClassLoader/closetest/test2/com/foo/Resource2 + test/java/net/URLClassLoader/closetest/test2/com/foo/TestClass.java + test/java/net/URLClassLoader/closetest/test2/com/foo/TestClass1.java Changeset: 0a05a2632a81 Author: michaelm Date: 2009-01-30 22:27 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0a05a2632a81 Merge Changeset: 948c504d6ef7 Author: darcy Date: 2009-01-30 15:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/948c504d6ef7 6799462: Minor typo (wrong word) in JavaDoc for InputStream.read(byte[] b) method Reviewed-by: sherman, martin ! src/share/classes/java/io/InputStream.java Changeset: f9cf49b7b248 Author: tbell Date: 2009-01-30 23:27 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f9cf49b7b248 Merge Changeset: 886a56291f1c Author: tbell Date: 2009-02-05 09:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/886a56291f1c Merge - make/javax/sound/jsoundhs/FILES.gmk - make/javax/sound/jsoundhs/Makefile - make/javax/sound/jsoundhs/mapfile-vers - src/share/classes/com/sun/beans/ObjectHandler.java - src/share/lib/audio/soundbank.gm Changeset: 6c5d04d1eff4 Author: jccollet Date: 2009-02-02 16:50 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6c5d04d1eff4 6791927: Wrong Locale in HttpCookie::expiryDate2DeltaSeconds Summary: Force Locale.US when parsing the cookie expiration date. Reviewed-by: chegar ! src/share/classes/java/net/HttpCookie.java + test/java/net/CookieHandler/B6791927.java Changeset: dbb82636df41 Author: weijun Date: 2009-02-03 09:38 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/dbb82636df41 6552334: Enable DNS in Kerberos by default Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/KrbServiceLocator.java ! test/sun/security/krb5/DnsFallback.java Changeset: ca32af4c0ea5 Author: weijun Date: 2009-02-03 09:38 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ca32af4c0ea5 6785456: Read Kerberos setting from Windows environment variables Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/Config.java Changeset: 050da121df16 Author: darcy Date: 2009-02-03 16:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/050da121df16 6548433: (enum spec) java.lang.Enum docs should explain about values() and valueOf(String) Reviewed-by: martin ! src/share/classes/java/lang/Enum.java Changeset: a96a1f0edeeb Author: xuelei Date: 2009-02-04 19:10 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a96a1f0edeeb 6782783: regtest HttpsURLConnection/B6216082.java throws ClosedByInterruptException Summary: make the test robust Reviewed-by: weijun ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java Changeset: 61ee91f965ac Author: jccollet Date: 2009-02-04 14:15 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/61ee91f965ac 6585546: Please update API doc for java.net.CookieManager Summary: Trivial doc updates Reviewed-by: chegar ! src/share/classes/java/net/CookieManager.java Changeset: c87205c0e215 Author: tbell Date: 2009-02-05 09:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c87205c0e215 Merge Changeset: 2753acfbf013 Author: tbell Date: 2009-02-06 09:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2753acfbf013 Merge Changeset: 14681728d6af Author: tbell Date: 2009-02-17 09:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/14681728d6af Merge Changeset: 75755e92430c Author: art Date: 2008-08-26 13:09 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/75755e92430c 6585765: RFE: Remove Unicows-related code from AWT 6733976: VS2008 errors compiling AWT files - explicit casts need to be added 6728735: VS2008 errors compiling UnicowsLoader.h and fatal error in awtmsg.h Summary: Unicows-related and Win95/98/Me-related code is removed Reviewed-by: uta, tdv ! make/sun/awt/FILES_c_windows.gmk ! make/sun/awt/Makefile ! make/sun/awt/make.depend ! make/sun/jawt/make.depend ! make/sun/splashscreen/Makefile ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/native/sun/awt/splashscreen/splashscreen_sys.c ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/java2d/d3d/D3DRenderQueue.cpp ! src/windows/native/sun/java2d/d3d/D3DRenderer.cpp ! src/windows/native/sun/java2d/d3d/D3DSurfaceData.cpp ! src/windows/native/sun/java2d/windows/GDIBlitLoops.cpp ! src/windows/native/sun/java2d/windows/GDIRenderer.cpp ! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp ! src/windows/native/sun/java2d/windows/WindowsFlags.cpp ! src/windows/native/sun/windows/ComCtl32Util.cpp ! src/windows/native/sun/windows/ComCtl32Util.h ! src/windows/native/sun/windows/Devices.cpp ! src/windows/native/sun/windows/Devices.h ! src/windows/native/sun/windows/GDIHashtable.cpp ! src/windows/native/sun/windows/GDIHashtable.h ! src/windows/native/sun/windows/ShellFolder2.cpp - src/windows/native/sun/windows/UnicowsLoader.cpp - src/windows/native/sun/windows/UnicowsLoader.h ! src/windows/native/sun/windows/WPrinterJob.cpp ! src/windows/native/sun/windows/awt.h ! src/windows/native/sun/windows/awt_Button.cpp ! src/windows/native/sun/windows/awt_Checkbox.cpp ! src/windows/native/sun/windows/awt_Choice.cpp ! src/windows/native/sun/windows/awt_Color.cpp ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_Cursor.cpp ! src/windows/native/sun/windows/awt_Cursor.h ! src/windows/native/sun/windows/awt_DataTransferer.cpp ! src/windows/native/sun/windows/awt_Desktop.cpp ! src/windows/native/sun/windows/awt_DesktopProperties.cpp ! src/windows/native/sun/windows/awt_Dialog.cpp ! src/windows/native/sun/windows/awt_DnDDS.cpp ! src/windows/native/sun/windows/awt_DnDDT.cpp ! src/windows/native/sun/windows/awt_DrawingSurface.cpp ! src/windows/native/sun/windows/awt_FileDialog.cpp ! src/windows/native/sun/windows/awt_FileDialog.h ! src/windows/native/sun/windows/awt_Font.cpp ! src/windows/native/sun/windows/awt_Font.h ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_InputMethod.cpp ! src/windows/native/sun/windows/awt_InputTextInfor.cpp ! src/windows/native/sun/windows/awt_InputTextInfor.h ! src/windows/native/sun/windows/awt_List.cpp - src/windows/native/sun/windows/awt_MMStub.cpp - src/windows/native/sun/windows/awt_MMStub.h ! src/windows/native/sun/windows/awt_MenuItem.cpp - src/windows/native/sun/windows/awt_Multimon.h ! src/windows/native/sun/windows/awt_Object.cpp ! src/windows/native/sun/windows/awt_Palette.cpp ! src/windows/native/sun/windows/awt_PopupMenu.cpp ! src/windows/native/sun/windows/awt_PrintControl.cpp ! src/windows/native/sun/windows/awt_PrintDialog.cpp ! src/windows/native/sun/windows/awt_PrintJob.cpp ! src/windows/native/sun/windows/awt_Robot.cpp ! src/windows/native/sun/windows/awt_ScrollPane.cpp ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TextArea.h ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextComponent.h ! src/windows/native/sun/windows/awt_TextField.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h ! src/windows/native/sun/windows/awt_TrayIcon.cpp ! src/windows/native/sun/windows/awt_TrayIcon.h - src/windows/native/sun/windows/awt_Unicode.cpp - src/windows/native/sun/windows/awt_Unicode.h ! src/windows/native/sun/windows/awt_Win32GraphicsConfig.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsDevice.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsDevice.h ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp ! src/windows/native/sun/windows/awt_Window.cpp - src/windows/native/sun/windows/awt_dlls.cpp - src/windows/native/sun/windows/awt_dlls.h ! src/windows/native/sun/windows/awtmsg.h ! src/windows/native/sun/windows/jawt.cpp Changeset: 95a618c79382 Author: art Date: 2008-08-26 16:31 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/95a618c79382 6741364: Some input method problems after the fix for 6585765 Summary: the fix for 6585765 is corrected Reviewed-by: uta ! src/windows/native/sun/windows/awt_InputTextInfor.cpp ! src/windows/native/sun/windows/awt_InputTextInfor.h Changeset: 39c8e06919a9 Author: art Date: 2008-09-01 17:41 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/39c8e06919a9 6707023: Chenese Characters in JTextPane Cause Pane to Hang Summary: input method events are dispatched to correct AppContext Reviewed-by: naoto, yan ! src/windows/classes/sun/awt/windows/WInputMethod.java Changeset: b942efbc1c72 Author: dav Date: 2008-09-04 17:20 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b942efbc1c72 6738181: api/java_awt/Toolkit/index.html#GetAWTEventListeners Fails with:empty array returned unexpectedly Summary: redirect getAWTEventListeners(long l) from Headless to underlying toolkit. Reviewed-by: art ! src/share/classes/sun/awt/HeadlessToolkit.java + test/java/awt/Toolkit/Headless/AWTEventListener/AWTListener.java Changeset: f0ce5b54bd90 Author: dav Date: 2008-09-04 17:24 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f0ce5b54bd90 Merge - src/windows/native/sun/windows/UnicowsLoader.cpp - src/windows/native/sun/windows/UnicowsLoader.h - src/windows/native/sun/windows/awt_MMStub.cpp - src/windows/native/sun/windows/awt_MMStub.h - src/windows/native/sun/windows/awt_Multimon.h - src/windows/native/sun/windows/awt_Unicode.cpp - src/windows/native/sun/windows/awt_Unicode.h - src/windows/native/sun/windows/awt_dlls.cpp - src/windows/native/sun/windows/awt_dlls.h Changeset: 31a7769b5fd1 Author: martin Date: 2008-09-08 17:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/31a7769b5fd1 6744609: Disable MMX support when building libpng library Summary: Define -DPNG_NO_MMX_CODE unconditionally, not just on 64-bit Linux Reviewed-by: anthony, art ! make/sun/splashscreen/Makefile Changeset: fd13d8cce933 Author: dcherepanov Date: 2008-09-10 15:02 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/fd13d8cce933 6743433: IM candidate window is not shown until window is deactivated and reactivated again Summary: OpenCandidateWindow procedure should directly call ::DefWindowProc Reviewed-by: art ! src/windows/native/sun/windows/awt_Component.cpp Changeset: b0c557c745e8 Author: art Date: 2008-09-11 10:38 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b0c557c745e8 6727884: Some Uncaught Exceptions are no longer getting sent to the Uncaught Exception Handlers Reviewed-by: anthony, dav ! src/share/classes/java/awt/EventDispatchThread.java + test/java/awt/EventDispatchThread/HandleExceptionOnEDT/HandleExceptionOnEDT.java Changeset: 3b9a288d7ddb Author: dav Date: 2008-09-16 12:17 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3b9a288d7ddb 6315717: Support for mouse with multiple scroll wheels and 4 or more buttons Summary: implementation of the more mouse buttons support Reviewed-by: art, dcherepanov ! make/sun/xawt/mapfile-vers ! src/share/classes/java/awt/Robot.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/doc-files/DesktopProperties.html ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/java/awt/event/MouseEvent.java ! src/share/classes/java/awt/peer/RobotPeer.java ! src/share/classes/sun/awt/HeadlessToolkit.java ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XConstants.java ! src/solaris/classes/sun/awt/X11/XDragSourceContextPeer.java ! src/solaris/classes/sun/awt/X11/XRobotPeer.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/native/sun/awt/awt_Robot.c ! src/windows/classes/sun/awt/windows/WRobotPeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_Robot.cpp ! src/windows/native/sun/windows/awt_Robot.h ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h ! src/windows/native/sun/windows/awt_TrayIcon.cpp + test/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java + test/java/awt/Mouse/MouseModifiersUnitTest/ModifierPermutation.java + test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java + test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Standard.java + test/java/awt/Robot/AcceptExtraMouseButtons/AcceptExtraMouseButtons.java + test/java/awt/Robot/ManualInstructions/ManualInstructions.java + test/java/awt/Robot/RobotExtraButton/RobotExtraButton.java + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_1.java + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_2.java + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_3.java + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_4.java + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_5.java + test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Disable.java + test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Enable.java + test/java/awt/event/InputEvent/ButtonArraysEquality/ButtonArraysEquality.java + test/java/awt/event/MouseEvent/AcceptExtraButton/AcceptExtraButton.java + test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions.java + test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions_Disable.java + test/java/awt/event/MouseEvent/CheckGetMaskForButton/CheckGetMaskForButton.java Changeset: 7e0533679ea1 Author: dav Date: 2008-09-29 14:54 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7e0533679ea1 6746212: Broken MouseEvents for TrayIcon Reviewed-by: dcherepanov, art ! src/windows/native/sun/windows/awt_TrayIcon.cpp Changeset: 672290c883fd Author: rkennke Date: 2008-09-29 20:16 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/672290c883fd 6749920: Cleanup AWT peer interfaces Summary: Remove duplicate and obsolete methods in the AWT peer interfaces. Reviewed-by: art, dav ! src/share/classes/java/awt/Choice.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/List.java ! src/share/classes/java/awt/MenuItem.java ! src/share/classes/java/awt/TextArea.java ! src/share/classes/java/awt/TextField.java ! src/share/classes/java/awt/peer/ChoicePeer.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/java/awt/peer/ContainerPeer.java ! src/share/classes/java/awt/peer/ListPeer.java ! src/share/classes/java/awt/peer/MenuItemPeer.java ! src/share/classes/java/awt/peer/TextAreaPeer.java ! src/share/classes/java/awt/peer/TextComponentPeer.java ! src/share/classes/java/awt/peer/TextFieldPeer.java ! src/share/classes/java/awt/peer/WindowPeer.java Changeset: 485e803c2d5a Author: dav Date: 2008-10-03 10:33 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/485e803c2d5a 6755110: Solaris build has corrupted with extra mouse buttons RFE Reviewed-by: yan ! src/solaris/native/sun/awt/awt_Robot.c Changeset: 5482ef16fe78 Author: yan Date: 2008-10-06 16:45 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5482ef16fe78 5100701: Toolkit.getLockingKeyState() does not work on XToolkit, but works on Motif Summary: Does not work on Motif but works on XToolkit now; implemented using XQueryPointer. Reviewed-by: anthony ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XlibWrapper.java ! src/solaris/classes/sun/awt/X11/keysym2ucs.h ! src/solaris/native/sun/xawt/XlibWrapper.c Changeset: ce224a356eb8 Author: dav Date: 2008-10-07 16:34 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ce224a356eb8 6750288: Regression after 6315717. ArrayIndexOutOfBoundsException. Reviewed-by: dcherepanov, denis ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: 724eb9cbd3bb Author: dav Date: 2008-10-07 16:43 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/724eb9cbd3bb Merge ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: aed796ac3788 Author: dav Date: 2008-10-08 12:50 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/aed796ac3788 5076635: Double click speed is not honored in KDE linux Reviewed-by: art, dcherepanov ! src/solaris/classes/sun/awt/X11/XToolkit.java + test/java/awt/Mouse/MaximizedFrameTest/MaximizedFrameTest.html + test/java/awt/Mouse/MaximizedFrameTest/MaximizedFrameTest.java Changeset: 346127532313 Author: dav Date: 2008-10-08 13:01 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/346127532313 Merge - make/java/nio/spp.sh - make/tools/winver/Makefile - make/tools/winver/bin/winver.exe - make/tools/winver/src/StdAfx.cpp - make/tools/winver/src/StdAfx.h - make/tools/winver/src/winver.cpp - src/share/classes/com/sun/jmx/mbeanserver/OpenConverter.java - src/share/classes/javax/management/ToQueryString.java ! src/solaris/classes/sun/awt/X11/XToolkit.java - src/windows/classes/sun/java2d/d3d/D3DBackBufferSurfaceData.java - src/windows/classes/sun/java2d/windows/DDBlitLoops.java - src/windows/classes/sun/java2d/windows/DDRenderer.java - src/windows/classes/sun/java2d/windows/DDScaleLoops.java - src/windows/classes/sun/java2d/windows/Win32OffScreenSurfaceData.java - src/windows/classes/sun/java2d/windows/Win32SurfaceData.java - src/windows/classes/sun/java2d/windows/Win32SurfaceDataProxy.java - src/windows/classes/sun/java2d/windows/WinBackBuffer.java - src/windows/classes/sun/java2d/windows/WinBackBufferSurfaceData.java - src/windows/classes/sun/java2d/windows/WinVolatileSurfaceManager.java - src/windows/native/sun/java2d/d3d/D3DRuntimeTest.cpp - src/windows/native/sun/java2d/d3d/D3DRuntimeTest.h - src/windows/native/sun/java2d/d3d/D3DTestRaster.h - src/windows/native/sun/java2d/d3d/D3DTextRenderer_md.cpp - src/windows/native/sun/java2d/d3d/D3DUtils.cpp - src/windows/native/sun/java2d/d3d/D3DUtils.h - src/windows/native/sun/java2d/windows/DDBlitLoops.cpp - src/windows/native/sun/java2d/windows/DDRenderer.cpp - src/windows/native/sun/java2d/windows/RegistryKey.cpp - src/windows/native/sun/java2d/windows/RegistryKey.h - src/windows/native/sun/java2d/windows/Win32OffScreenSurfaceData.cpp - src/windows/native/sun/java2d/windows/Win32SurfaceData.cpp - src/windows/native/sun/java2d/windows/Win32SurfaceData.h - src/windows/native/sun/java2d/windows/WinBackBufferSurfaceData.cpp - src/windows/native/sun/java2d/windows/ddrawObject.cpp - src/windows/native/sun/java2d/windows/ddrawObject.h - src/windows/native/sun/java2d/windows/ddrawUtils.cpp - src/windows/native/sun/java2d/windows/ddrawUtils.h - src/windows/native/sun/java2d/windows/dxCapabilities.cpp - src/windows/native/sun/java2d/windows/dxCapabilities.h - src/windows/native/sun/java2d/windows/dxInit.cpp - src/windows/native/sun/java2d/windows/dxInit.h - src/windows/native/sun/windows/UnicowsLoader.cpp - src/windows/native/sun/windows/UnicowsLoader.h - src/windows/native/sun/windows/awt_MMStub.cpp - src/windows/native/sun/windows/awt_MMStub.h - src/windows/native/sun/windows/awt_Multimon.h - src/windows/native/sun/windows/awt_Unicode.cpp - src/windows/native/sun/windows/awt_Unicode.h - src/windows/native/sun/windows/awt_dlls.cpp - src/windows/native/sun/windows/awt_dlls.h Changeset: 0c515369b48b Author: lana Date: 2008-10-20 19:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0c515369b48b Merge - make/ASSEMBLY_EXCEPTION - make/LICENSE - make/README - make/README-builds.html - make/README.html - make/THIRD_PARTY_README ! make/sun/awt/Makefile - make/tools/auto_multi/Makefile - make/tools/src/build/tools/automulti/AutoMulti.java - make/tools/src/build/tools/automulti/README.txt - make/tools/src/build/tools/automulti/TestALFGenerator.java - make/tools/src/build/tools/automulti/TestALFLookAndFeel.java ! src/share/classes/java/awt/EventDispatchThread.java - src/share/classes/java/nio/channels/package.html - src/share/classes/javax/swing/colorchooser/DefaultHSBChooserPanel.java - src/share/classes/javax/swing/colorchooser/DefaultRGBChooserPanel.java - src/share/classes/javax/swing/colorchooser/SyntheticImage.java - src/share/classes/org/jcp/xml/dsig/internal/package.html - src/share/classes/sun/launcher/LauncherHelp.java - src/share/classes/sun/nio/ch/OptionAdaptor.java - src/share/classes/sun/nio/ch/SocketOpts.java - src/share/classes/sun/nio/ch/SocketOptsImpl.java - src/share/classes/sun/nio/ch/exceptions - src/share/javavm/include/opcodes.h - src/share/javavm/include/opcodes.length - src/share/javavm/include/opcodes.list - src/share/javavm/include/opcodes.weight - src/share/javavm/include/opcodes.wide - src/share/javavm/include/sys_api.h - src/share/javavm/include/typedefs.h - src/solaris/javavm/include/typedefs_md.h - src/windows/javavm/include/typedefs_md.h ! src/windows/native/sun/windows/ComCtl32Util.cpp ! src/windows/native/sun/windows/ComCtl32Util.h ! src/windows/native/sun/windows/awt_TextArea.cpp - test/javax/swing/JFileChooser/4252173/bug4252173.java - test/javax/swing/JFileChooser/6524424/bug6524424.html - test/javax/swing/JFileChooser/6524424/bug6524424.java - test/sun/net/www/http/ChunkedInputStream/test.txt - test/tools/launcher/Arrrghs.sh Changeset: 7406833af6e4 Author: art Date: 2008-10-28 17:06 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7406833af6e4 6758673: WeakReference leak in Window.ownedWindowList Summary: WindowDisposerRecord parent field is correctly initialized Reviewed-by: dav, ant ! src/share/classes/java/awt/Window.java + test/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java Changeset: 9daa41eca0d9 Author: art Date: 2008-11-26 16:25 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9daa41eca0d9 6699589: java/awt/EventQueue/PostEventOrderingTest.java fails Reviewed-by: dav, anthony ! src/share/classes/sun/awt/SunToolkit.java Changeset: d5bf2dd61ed5 Author: art Date: 2008-12-19 16:04 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d5bf2dd61ed5 6773985: OutOfMemory (PermGen space) under Linux / Firefox when switching bw. applets Summary: XEmbedClientHelper is uninstalled when its embedded frame is disposed. Reviewed-by: dcherepanov, ant ! src/solaris/classes/sun/awt/X11/XEmbedClientHelper.java ! src/solaris/classes/sun/awt/X11/XEmbeddedFramePeer.java Changeset: 63d087cacbf9 Author: rkennke Date: 2009-01-13 20:04 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/63d087cacbf9 6792515: Specify awt peer's API Summary: Document AWT peer API. Reviewed-by: art, dav ! src/share/classes/java/awt/peer/ButtonPeer.java ! src/share/classes/java/awt/peer/CanvasPeer.java ! src/share/classes/java/awt/peer/CheckboxMenuItemPeer.java ! src/share/classes/java/awt/peer/CheckboxPeer.java ! src/share/classes/java/awt/peer/ChoicePeer.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/java/awt/peer/ContainerPeer.java ! src/share/classes/java/awt/peer/DesktopPeer.java ! src/share/classes/java/awt/peer/DialogPeer.java ! src/share/classes/java/awt/peer/FileDialogPeer.java ! src/share/classes/java/awt/peer/FontPeer.java ! src/share/classes/java/awt/peer/FramePeer.java ! src/share/classes/java/awt/peer/KeyboardFocusManagerPeer.java ! src/share/classes/java/awt/peer/LabelPeer.java ! src/share/classes/java/awt/peer/ListPeer.java ! src/share/classes/java/awt/peer/MenuBarPeer.java ! src/share/classes/java/awt/peer/MenuComponentPeer.java ! src/share/classes/java/awt/peer/MenuItemPeer.java ! src/share/classes/java/awt/peer/MenuPeer.java ! src/share/classes/java/awt/peer/MouseInfoPeer.java ! src/share/classes/java/awt/peer/PanelPeer.java ! src/share/classes/java/awt/peer/PopupMenuPeer.java ! src/share/classes/java/awt/peer/RobotPeer.java ! src/share/classes/java/awt/peer/ScrollPanePeer.java ! src/share/classes/java/awt/peer/ScrollbarPeer.java ! src/share/classes/java/awt/peer/SystemTrayPeer.java ! src/share/classes/java/awt/peer/TextAreaPeer.java ! src/share/classes/java/awt/peer/TextComponentPeer.java ! src/share/classes/java/awt/peer/TextFieldPeer.java ! src/share/classes/java/awt/peer/TrayIconPeer.java ! src/share/classes/java/awt/peer/WindowPeer.java Changeset: 127e3269ee1f Author: bae Date: 2009-01-20 19:51 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/127e3269ee1f 6551075: screenshot image taken through clipboard on W2K terminal server is shifted Reviewed-by: dav, uta ! src/windows/native/sun/windows/awt_DataTransferer.cpp Changeset: 9fa2e56c8a30 Author: art Date: 2009-01-29 14:58 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9fa2e56c8a30 6721088: Bad window size calculation after using pack() Reviewed-by: anthony Contributed-by: Omair Majid ! src/solaris/classes/sun/awt/X11/WindowDimensions.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java + test/java/awt/Frame/FrameSize/TestFrameSize.java Changeset: f36e9200cb85 Author: anthony Date: 2009-02-04 11:58 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f36e9200cb85 6797195: Forward-port enhancements for hw/lw mixing from 6u12 to 7 Reviewed-by: art, dcherepanov ! make/sun/awt/Makefile ! make/tools/sharing/classlist.linux ! make/tools/sharing/classlist.solaris ! make/tools/sharing/classlist.windows + src/share/classes/com/sun/awt/AWTUtilities.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/javax/swing/JRootPane.java + src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/SunToolkit.java ! src/share/classes/sun/java2d/pipe/Region.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/native/sun/xawt/XlibWrapper.c ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/native/sun/windows/awt_Component.cpp + test/java/awt/Mixing/HWDisappear.java + test/java/awt/Mixing/JButtonInGlassPane.java + test/java/awt/Mixing/LWComboBox.java + test/java/awt/Mixing/MixingOnShrinkingHWButton.java + test/java/awt/Mixing/NonOpaqueInternalFrame.java ! test/java/awt/Mixing/OpaqueTest.java ! test/java/awt/Mixing/OverlappingButtons.java Changeset: 8b96fb2d0c3a Author: lana Date: 2009-02-10 12:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8b96fb2d0c3a Merge ! make/sun/xawt/mapfile-vers ! src/share/classes/java/awt/EventDispatchThread.java - src/windows/native/sun/windows/UnicowsLoader.cpp - src/windows/native/sun/windows/UnicowsLoader.h - src/windows/native/sun/windows/awt_MMStub.cpp - src/windows/native/sun/windows/awt_MMStub.h - src/windows/native/sun/windows/awt_Multimon.h - src/windows/native/sun/windows/awt_Unicode.cpp - src/windows/native/sun/windows/awt_Unicode.h - src/windows/native/sun/windows/awt_dlls.cpp - src/windows/native/sun/windows/awt_dlls.h Changeset: 5fbd9ea7def1 Author: lana Date: 2009-02-18 10:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5fbd9ea7def1 Merge - src/windows/native/sun/windows/UnicowsLoader.cpp - src/windows/native/sun/windows/UnicowsLoader.h - src/windows/native/sun/windows/awt_MMStub.cpp - src/windows/native/sun/windows/awt_MMStub.h - src/windows/native/sun/windows/awt_Multimon.h - src/windows/native/sun/windows/awt_Unicode.cpp - src/windows/native/sun/windows/awt_Unicode.h - src/windows/native/sun/windows/awt_dlls.cpp - src/windows/native/sun/windows/awt_dlls.h Changeset: 8311105ea7a3 Author: xdono Date: 2009-02-19 14:08 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8311105ea7a3 Added tag jdk7-b48 for changeset 5fbd9ea7def1 ! .hgtags From john.coomes at sun.com Fri Feb 20 16:32:03 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 21 Feb 2009 00:32:03 +0000 Subject: hg: jdk7/hotspot/langtools: 12 new changesets Message-ID: <20090221003223.BFFE1DCB2@hg.openjdk.java.net> Changeset: edb8d7985cfd Author: darcy Date: 2009-01-27 17:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/edb8d7985cfd 6707027: langtools/test/tools/javac/processing/model/testgetallmember/Main.java fails Reviewed-by: jjg ! test/tools/javac/processing/model/testgetallmembers/Main.java Changeset: 9199b9092f73 Author: jjg Date: 2009-01-27 18:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/9199b9092f73 6176978: current Javadoc's invocation and extension (Doclet) mechanisms are problematic Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java + test/tools/javadoc/6176978/T6176978.java + test/tools/javadoc/6176978/X.java Changeset: 1aa81917016a Author: mcimadamore Date: 2009-01-29 12:17 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/1aa81917016a 6315770: javac inference allows creation of strange types: Integer & Runnable Summary: Javac does not apply glb correctly as per JLS3 15.12.2.8 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/6315770/T6315770.java + test/tools/javac/generics/inference/6315770/T6315770.out Changeset: 4542977c959e Author: mcimadamore Date: 2009-01-29 12:18 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/4542977c959e 6557182: Unchecked warning *and* inconvertible types Summary: Redundant warnings are generated when casting from intersection types Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/cast/6557182/T6557182.java + test/tools/javac/cast/6557182/T6557182.out Changeset: 79f2f2c7d846 Author: mcimadamore Date: 2009-01-29 12:19 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/79f2f2c7d846 6729401: Compiler error when using F-bounded generics with free type variables Summary: Javac applies wrong substitution to recursive type-variable bounds Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/generics/6729401/T6729401.java Changeset: 49281ea88125 Author: tbell Date: 2009-01-30 23:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/49281ea88125 Merge Changeset: 638d5fbf5e78 Author: tbell Date: 2009-02-06 09:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/638d5fbf5e78 Merge Changeset: 9d541fd2916b Author: jjg Date: 2009-02-06 10:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/9d541fd2916b 6595666: fix -Werror Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/resources/javac.properties ! test/tools/javac/6304921/T6304921.out ! test/tools/javac/6758789/T6758789b.out ! test/tools/javac/T6241723.out + test/tools/javac/T6595666.java ! test/tools/javac/depDocComment/DeprecatedDocComment.out Changeset: 58fcba61a77d Author: darcy Date: 2009-02-06 12:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/58fcba61a77d 6794071: Provide exception superclass for UnknownFooExceptions Reviewed-by: jjg + src/share/classes/javax/lang/model/UnknownEntityException.java ! src/share/classes/javax/lang/model/element/UnknownAnnotationValueException.java ! src/share/classes/javax/lang/model/element/UnknownElementException.java ! src/share/classes/javax/lang/model/type/UnknownTypeException.java + test/tools/javac/processing/model/TestExceptions.java Changeset: 000d1e518bc5 Author: tbell Date: 2009-02-06 17:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/000d1e518bc5 Merge Changeset: c53007f34195 Author: tbell Date: 2009-02-17 09:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/c53007f34195 Merge Changeset: d17d927ad9bd Author: xdono Date: 2009-02-19 14:08 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/d17d927ad9bd Added tag jdk7-b48 for changeset c53007f34195 ! .hgtags From y.s.ramakrishna at sun.com Fri Feb 20 18:31:00 2009 From: y.s.ramakrishna at sun.com (y.s.ramakrishna at sun.com) Date: Sat, 21 Feb 2009 02:31:00 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20090221023108.65986DD37@hg.openjdk.java.net> Changeset: 9e5a6ed08fc9 Author: jmasa Date: 2009-02-17 15:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9e5a6ed08fc9 6786346: intermittent Internal Error (src/share/vm/memory/cardTableModRefBS.cpp:226) Summary: Two assertions were incorrectly composed. Reviewed-by: tonyp ! src/share/vm/memory/cardTableModRefBS.cpp Changeset: a0576ae7045f Author: ysr Date: 2009-02-20 11:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a0576ae7045f Merge From Paul.Hohensee at Sun.COM Fri Feb 20 18:59:19 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Fri, 20 Feb 2009 21:59:19 -0500 Subject: Is there any special process in Hotspot to adapt 64 bit address? In-Reply-To: <22129185.post@talk.nabble.com> References: <22129185.post@talk.nabble.com> Message-ID: <499F6E07.9010201@sun.com> Hotspot has supported 64-bit platforms since 2000. Currently, Sun supports sparc64 and x64, Intel and Oracle support ia64, and various licensees support other 64-bit architectures. I'm not sure I understand what you're asking. 64-bit jvms use either full width 64-bit addresses to reference objects in the heap, or they use 32-bit offsets from the heap base (so-called "narrow" addresses) and convert them to full width addresses as necessary. In the latter case, heap sizes in current 64-bit jvms are restricted to up to 32gb, depending on the implementation. So there's no conversion from 64-bit to 32-bit addresses in a 64-bit jvm. I suppose a 64-bit emulator running in 32-bit mode (i.e., the emulator itself is a 32-bit program emulating a 64-bit program) might want to do something like that, but it would be restricted to "small" 64-bit programs, for some value of "small". There's also the special case of a 64-bit jvm running with < 4gb heap with a heap base address of zero. In that case, narrow addresses are the same as wide addresses and no conversion is necessary. Paul Colin(Du Li) wrote: > Hi, guys, > > Because hotspot is developed for 32 bits address, I wonder if there is > something, which might be a read barrier, to convert a 64 bit address to 32 > bits address. If so, where is it? > > Thanks a lot! > > Du Li > From Y.S.Ramakrishna at Sun.COM Sat Feb 21 16:46:24 2009 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Sat, 21 Feb 2009 16:46:24 -0800 Subject: OpenJDK/hotspot browsable current source? Message-ID: <72b0bae542d9.49a02fe0@sun.com> It seems that both the links to browsable source from this page:- http://openjdk.java.net/groups/hotspot/ viz. :- https://openjdk.dev.java.net/source/browse/openjdk/jdk/trunk/ and http://opengrok.neojava.org/hotspot are now obsolete, with the first not pointing to source that is apparently more than a year old, and the second a broken link. Does anyone know if there's an open "current" browsable source of (some suitable master forest repo of) OpenJDK 7 somewhere that we can link to above? -- ramki From Peter.Kessler at Sun.COM Sat Feb 21 17:36:32 2009 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Sat, 21 Feb 2009 17:36:32 -0800 Subject: OpenJDK/hotspot browsable current source? In-Reply-To: <72b0bae542d9.49a02fe0@sun.com> References: <72b0bae542d9.49a02fe0@sun.com> Message-ID: <49A0AC20.10901@Sun.COM> When I want to browse the current sources in the HotSpot tree, I start from http://openjdk.java.net/ click on the (tiny) "7" in "Source code / Mercurial (6, 7)" from the left-hand navigation panel. That gets me to the JDK Master forest. I add "/hotspot" to that URL to get to the root of the HotSpot tree. Then I click on the "manifest" for the change (or tag, or branch). That gets me to a page where I can rummage around in what I think of as "the HotSpot sources. E.g., the current one is http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/d61c7c22b25c and from there you can click down to, for example, http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/d61c7c22b25c/src/share/vm/runtime/globals.hpp (which I see you changed 3 weeks ago). A bit of history: the OpenGrok instance was running on a private web site registered by Tom Marble. I assume he's let it expire. The plan was always to run an OpenGrok instance on openjdk.java.net, but I don't think that's moved beyond the "plan" stage, and the plan may have changed. ... peter Y Srinivas Ramakrishna wrote: > It seems that both the links to browsable source from > this page:- > > http://openjdk.java.net/groups/hotspot/ > > viz. :- > > https://openjdk.dev.java.net/source/browse/openjdk/jdk/trunk/ > > and > > http://opengrok.neojava.org/hotspot > > are now obsolete, with the first not pointing to > source that is apparently more than a year old, > and the second a broken link. > > Does anyone know if there's an open > "current" browsable source of (some suitable master > forest repo of) OpenJDK 7 somewhere that we can > link to above? > > -- ramki From Christian.Thalinger at Sun.COM Sun Feb 22 07:18:46 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Sun, 22 Feb 2009 16:18:46 +0100 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors Message-ID: <1235315926.11128.34.camel@localhost.localdomain> http://cr.openjdk.java.net/~twisti/6778669/webrev.00/ Finally the changeset I was waiting for was promoted into our forest. It would be a good idea if someone from e.g. RedHat or Ubuntu (Andrew or Matthias: hint! hint!) could try that patch before I push it. -- Christian From Christian.Thalinger at Sun.COM Sun Feb 22 10:28:59 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Sun, 22 Feb 2009 19:28:59 +0100 Subject: merge vm_version_x86_{32,64}.hpp In-Reply-To: <499EDBE0.1000504@sun.com> References: <1235123937.11128.10.camel@localhost.localdomain> <499EDBE0.1000504@sun.com> Message-ID: <1235327339.11128.42.camel@localhost.localdomain> On Fri, 2009-02-20 at 11:35 -0500, Paul Hohensee wrote: > Feel free. :) In general, if you're changing things somewhere, feel > free to refactor. Great :-) Should I merge them into a common vm_version_x86.{cpp,hpp} plus specific vm_version_x86_{32,64}.{cpp,hpp} files or just a single vm_version_x86.{cpp,hpp} with #ifdef's? There would be very few #ifdef's but I would prefer the former approach. -- Christian From Vladimir.Kozlov at Sun.COM Sun Feb 22 12:18:20 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Sun, 22 Feb 2009 12:18:20 -0800 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <1235315926.11128.34.camel@localhost.localdomain> References: <1235315926.11128.34.camel@localhost.localdomain> Message-ID: <49A1B30C.5060501@sun.com> Christian, Your changes looks good. Could you also look on and possibly include fixes for hsdis build on linux. Thanks, Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6778669/webrev.00/ > > Finally the changeset I was waiting for was promoted into our forest. > > It would be a good idea if someone from e.g. RedHat or Ubuntu (Andrew or > Matthias: hint! hint!) could try that patch before I push it. > > -- Christian > Edward Lee wrote: > I was trying to compile hsdis on Linux 2.6.18-53.el5 x86_64 and ran > into a few issues. > > The first couple was fixed by a patch [1] to address various things > being undefined: > > hsdis.c:50: error: expected specifier-qualifier-list before'uintptr_t' > hsdis-demo.c:(.text+0x96): undefined reference to `dlsym' > hsdis-demo.c:(.text+0xcc): undefined reference to `dlopen' > hsdis-demo.c:(.text+0x1fa): undefined reference to `dlerror' > > The next issue was that the disassembler couldn't use hsdis-i386.so. I > found out with +WizardMode that the problem was "wrong ELF class: > ELFCLASS64". So I had to recompile both binutils and hsdis with the > -m32 option. > > bin/linux/hsdis-i386.so: ELF 64-bit LSB shared object, Intel 80386, > version 1 (SYSV), not stripped > .. instead of .. > bin/linux/hsdis-i386.so: ELF 32-bit LSB shared object, Intel 80386, > version 1 (SYSV), not stripped > > I've updated the original patch [1] to have changes to Makefile and > README about using -m32. > > Ed > > [1] http://groups.google.com/group/jvm-languages/msg/4b7b6f19ab719cb7 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hsdis.patch Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090222/28554452/attachment.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hsdis.m32.patch Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090222/28554452/attachment-0001.ksh From Christian.Thalinger at Sun.COM Sun Feb 22 12:21:22 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Sun, 22 Feb 2009 21:21:22 +0100 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <49A1B30C.5060501@sun.com> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> Message-ID: <1235334082.11128.44.camel@localhost.localdomain> On Sun, 2009-02-22 at 12:18 -0800, Vladimir Kozlov wrote: > Christian, > > Your changes looks good. > Could you also look on and possibly include fixes for hsdis build on linux. Ahh, right! There was an issue on Linux. I will include the attached patches. Andrew tested the patch and there seem to be a ton of warnings... sigh. We try to fix them. -- Christian From Vladimir.Kozlov at Sun.COM Sun Feb 22 12:21:45 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Sun, 22 Feb 2009 12:21:45 -0800 Subject: merge vm_version_x86_{32,64}.hpp In-Reply-To: <1235327339.11128.42.camel@localhost.localdomain> References: <1235123937.11128.10.camel@localhost.localdomain> <499EDBE0.1000504@sun.com> <1235327339.11128.42.camel@localhost.localdomain> Message-ID: <49A1B3D9.3060508@sun.com> Common vm_version_x86.{cpp,hpp} with #ifdef as we did for assembler_x86.?pp Vladimir Christian Thalinger wrote: > On Fri, 2009-02-20 at 11:35 -0500, Paul Hohensee wrote: >> Feel free. :) In general, if you're changing things somewhere, feel >> free to refactor. > > Great :-) Should I merge them into a common vm_version_x86.{cpp,hpp} > plus specific vm_version_x86_{32,64}.{cpp,hpp} files or just a single > vm_version_x86.{cpp,hpp} with #ifdef's? > > There would be very few #ifdef's but I would prefer the former approach. > > -- Christian > From Christian.Thalinger at Sun.COM Sun Feb 22 12:24:58 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Sun, 22 Feb 2009 21:24:58 +0100 Subject: merge vm_version_x86_{32,64}.hpp In-Reply-To: <49A1B3D9.3060508@sun.com> References: <1235123937.11128.10.camel@localhost.localdomain> <499EDBE0.1000504@sun.com> <1235327339.11128.42.camel@localhost.localdomain> <49A1B3D9.3060508@sun.com> Message-ID: <1235334298.11128.45.camel@localhost.localdomain> On Sun, 2009-02-22 at 12:21 -0800, Vladimir Kozlov wrote: > Common vm_version_x86.{cpp,hpp} with #ifdef as we did for assembler_x86.?pp Okay, will do that. -- Christian From gnu_andrew at member.fsf.org Sun Feb 22 12:35:37 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Sun, 22 Feb 2009 20:35:37 +0000 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <1235334082.11128.44.camel@localhost.localdomain> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> Message-ID: <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> 2009/2/22 Christian Thalinger : > On Sun, 2009-02-22 at 12:18 -0800, Vladimir Kozlov wrote: >> Christian, >> >> Your changes looks good. >> Could you also look on and possibly include fixes for hsdis build on linux. > > Ahh, right! ?There was an issue on Linux. ?I will include the attached > patches. > > Andrew tested the patch and there seem to be a ton of warnings... sigh. > We try to fix them. > > -- Christian > > Even with this patch, there seem to be major issues in the ADLC parser with GCC 4.3.3 on x86_64. I assume IcedTea gets round them with the patch to turn off -Werror. Attached is an extended version of twisti's patch which starts to fix some of the issues in adlc. I've also included the build log with this applied. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: warnings.patch Type: application/octet-stream Size: 15203 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090222/b3cd79ae/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: build.log Type: application/octet-stream Size: 75802 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090222/b3cd79ae/attachment-0001.obj From David.Holmes at Sun.COM Sun Feb 22 15:25:08 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Mon, 23 Feb 2009 09:25:08 +1000 Subject: merge vm_version_x86_{32,64}.hpp In-Reply-To: <49A1B3D9.3060508@sun.com> References: <1235123937.11128.10.camel@localhost.localdomain> <499EDBE0.1000504@sun.com> <1235327339.11128.42.camel@localhost.localdomain> <49A1B3D9.3060508@sun.com> Message-ID: <49A1DED4.7040805@sun.com> Looking at the HS sources the tendency has been to separate files rather #ifdefs. I know it's not 100% consistent but I'd rather not help swing the pendulum back the other way unless there's a really good reason for doing so. David Holmes Vladimir Kozlov said the following on 02/23/09 06:21: > Common vm_version_x86.{cpp,hpp} with #ifdef as we did for assembler_x86.?pp > > Vladimir > > Christian Thalinger wrote: >> On Fri, 2009-02-20 at 11:35 -0500, Paul Hohensee wrote: >>> Feel free. :) In general, if you're changing things somewhere, feel >>> free to refactor. >> >> Great :-) Should I merge them into a common vm_version_x86.{cpp,hpp} >> plus specific vm_version_x86_{32,64}.{cpp,hpp} files or just a single >> vm_version_x86.{cpp,hpp} with #ifdef's? >> >> There would be very few #ifdef's but I would prefer the former approach. >> >> -- Christian >> From Vladimir.Kozlov at Sun.COM Sun Feb 22 15:38:01 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Sun, 22 Feb 2009 15:38:01 -0800 Subject: merge vm_version_x86_{32,64}.hpp In-Reply-To: <49A1DED4.7040805@sun.com> References: <1235123937.11128.10.camel@localhost.localdomain> <499EDBE0.1000504@sun.com> <1235327339.11128.42.camel@localhost.localdomain> <49A1B3D9.3060508@sun.com> <49A1DED4.7040805@sun.com> Message-ID: <49A1E1D9.7040902@sun.com> Actually we are merging x86 source as much as possible to avoid duplicated changes for 32- and 64-bits. Steve Goldman started this work and Tom did additional changes. So Christian's suggestion is in the line with this work. It is better to have 2 files with few #ifdef then 4 separate file which have 80% (or more) of the same duplicated code. Thanks, Vladimir David Holmes - Sun Microsystems wrote: > Looking at the HS sources the tendency has been to separate files rather > #ifdefs. I know it's not 100% consistent but I'd rather not help swing > the pendulum back the other way unless there's a really good reason for > doing so. > > David Holmes > > Vladimir Kozlov said the following on 02/23/09 06:21: >> Common vm_version_x86.{cpp,hpp} with #ifdef as we did for >> assembler_x86.?pp >> >> Vladimir >> >> Christian Thalinger wrote: >>> On Fri, 2009-02-20 at 11:35 -0500, Paul Hohensee wrote: >>>> Feel free. :) In general, if you're changing things somewhere, feel >>>> free to refactor. >>> >>> Great :-) Should I merge them into a common vm_version_x86.{cpp,hpp} >>> plus specific vm_version_x86_{32,64}.{cpp,hpp} files or just a single >>> vm_version_x86.{cpp,hpp} with #ifdef's? >>> >>> There would be very few #ifdef's but I would prefer the former approach. >>> >>> -- Christian >>> From David.Holmes at Sun.COM Sun Feb 22 15:42:40 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Mon, 23 Feb 2009 09:42:40 +1000 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> Message-ID: <49A1E2F0.7050700@sun.com> Andrew, I think some of these need to be looked at more closely: // Print out the dictionary contents as key-value pairs -static void dumpekey(const void* key) { fprintf(stdout, "%s", key); } +static void dumpekey(const void* key) { fprintf(stdout, "%p", key); } As far as I can see an ExprDict key is always a char*, hence %s is what we want not %p. So the right fix would be to cast key to char* . David Holmes Andrew John Hughes said the following on 02/23/09 06:35: > 2009/2/22 Christian Thalinger : >> On Sun, 2009-02-22 at 12:18 -0800, Vladimir Kozlov wrote: >>> Christian, >>> >>> Your changes looks good. >>> Could you also look on and possibly include fixes for hsdis build on linux. >> Ahh, right! There was an issue on Linux. I will include the attached >> patches. >> >> Andrew tested the patch and there seem to be a ton of warnings... sigh. >> We try to fix them. >> >> -- Christian >> >> > > Even with this patch, there seem to be major issues in the ADLC parser > with GCC 4.3.3 on x86_64. I assume IcedTea gets round them with the > patch to turn off -Werror. > > Attached is an extended version of twisti's patch which starts to fix > some of the issues in adlc. I've also included the build log with > this applied. > From David.Holmes at Sun.COM Sun Feb 22 15:48:07 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Mon, 23 Feb 2009 09:48:07 +1000 Subject: merge vm_version_x86_{32,64}.hpp In-Reply-To: <49A1E1D9.7040902@sun.com> References: <1235123937.11128.10.camel@localhost.localdomain> <499EDBE0.1000504@sun.com> <1235327339.11128.42.camel@localhost.localdomain> <49A1B3D9.3060508@sun.com> <49A1DED4.7040805@sun.com> <49A1E1D9.7040902@sun.com> Message-ID: <49A1E437.7050102@sun.com> Vladimir Kozlov said the following on 02/23/09 09:38: > Actually we are merging x86 source as much as possible > to avoid duplicated changes for 32- and 64-bits. > Steve Goldman started this work and Tom did additional changes. > So Christian's suggestion is in the line with this work. > > It is better to have 2 files with few #ifdef then 4 separate file > which have 80% (or more) of the same duplicated code. But what Christian is doing is factoring out that 80% into 1 file and then we have two files with the 20% that is different. I'd rather see that than a single file with 20% of the code ifdef'd. Just my 2c. David > Thanks, > Vladimir > > David Holmes - Sun Microsystems wrote: >> Looking at the HS sources the tendency has been to separate files >> rather #ifdefs. I know it's not 100% consistent but I'd rather not >> help swing the pendulum back the other way unless there's a really >> good reason for doing so. >> >> David Holmes >> >> Vladimir Kozlov said the following on 02/23/09 06:21: >>> Common vm_version_x86.{cpp,hpp} with #ifdef as we did for >>> assembler_x86.?pp >>> >>> Vladimir >>> >>> Christian Thalinger wrote: >>>> On Fri, 2009-02-20 at 11:35 -0500, Paul Hohensee wrote: >>>>> Feel free. :) In general, if you're changing things somewhere, >>>>> feel free to refactor. >>>> >>>> Great :-) Should I merge them into a common vm_version_x86.{cpp,hpp} >>>> plus specific vm_version_x86_{32,64}.{cpp,hpp} files or just a single >>>> vm_version_x86.{cpp,hpp} with #ifdef's? >>>> >>>> There would be very few #ifdef's but I would prefer the former >>>> approach. >>>> >>>> -- Christian >>>> From Vladimir.Kozlov at Sun.COM Sun Feb 22 16:00:51 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Sun, 22 Feb 2009 16:00:51 -0800 Subject: merge vm_version_x86_{32,64}.hpp In-Reply-To: <49A1E437.7050102@sun.com> References: <1235123937.11128.10.camel@localhost.localdomain> <499EDBE0.1000504@sun.com> <1235327339.11128.42.camel@localhost.localdomain> <49A1B3D9.3060508@sun.com> <49A1DED4.7040805@sun.com> <49A1E1D9.7040902@sun.com> <49A1E437.7050102@sun.com> Message-ID: <49A1E733.8010402@sun.com> Sorry, It could be small misunderstanding. I should not be using 'common' word in my replay to Christian. What Christian asked, I suggested to him and he agreed is to have 2 files with #ifdef: vm_version_x86.cpp and vm_version_x86.hpp instead of current 4 files: vm_version_x86_32.cpp, vm_version_x86_32.hpp, vm_version_x86_64.cpp, vm_version_x86_64.hpp That is all. Thanks, Vladimir David Holmes - Sun Microsystems wrote: > Vladimir Kozlov said the following on 02/23/09 09:38: >> Actually we are merging x86 source as much as possible >> to avoid duplicated changes for 32- and 64-bits. >> Steve Goldman started this work and Tom did additional changes. >> So Christian's suggestion is in the line with this work. >> >> It is better to have 2 files with few #ifdef then 4 separate file >> which have 80% (or more) of the same duplicated code. > > But what Christian is doing is factoring out that 80% into 1 file and > then we have two files with the 20% that is different. I'd rather see > that than a single file with 20% of the code ifdef'd. > > Just my 2c. > > David > >> Thanks, >> Vladimir >> >> David Holmes - Sun Microsystems wrote: >>> Looking at the HS sources the tendency has been to separate files >>> rather #ifdefs. I know it's not 100% consistent but I'd rather not >>> help swing the pendulum back the other way unless there's a really >>> good reason for doing so. >>> >>> David Holmes >>> >>> Vladimir Kozlov said the following on 02/23/09 06:21: >>>> Common vm_version_x86.{cpp,hpp} with #ifdef as we did for >>>> assembler_x86.?pp >>>> >>>> Vladimir >>>> >>>> Christian Thalinger wrote: >>>>> On Fri, 2009-02-20 at 11:35 -0500, Paul Hohensee wrote: >>>>>> Feel free. :) In general, if you're changing things somewhere, >>>>>> feel free to refactor. >>>>> >>>>> Great :-) Should I merge them into a common vm_version_x86.{cpp,hpp} >>>>> plus specific vm_version_x86_{32,64}.{cpp,hpp} files or just a single >>>>> vm_version_x86.{cpp,hpp} with #ifdef's? >>>>> >>>>> There would be very few #ifdef's but I would prefer the former >>>>> approach. >>>>> >>>>> -- Christian >>>>> From David.Holmes at Sun.COM Sun Feb 22 16:10:08 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Mon, 23 Feb 2009 10:10:08 +1000 Subject: merge vm_version_x86_{32,64}.hpp In-Reply-To: <49A1E733.8010402@sun.com> References: <1235123937.11128.10.camel@localhost.localdomain> <499EDBE0.1000504@sun.com> <1235327339.11128.42.camel@localhost.localdomain> <49A1B3D9.3060508@sun.com> <49A1DED4.7040805@sun.com> <49A1E1D9.7040902@sun.com> <49A1E437.7050102@sun.com> <49A1E733.8010402@sun.com> Message-ID: <49A1E960.6080608@sun.com> Hi Vladimir, Christian's proposal was to take the existing four files: > vm_version_x86_32.cpp, vm_version_x86_32.hpp, > vm_version_x86_64.cpp, vm_version_x86_64.hpp and to factor out the common code into: > vm_version_x86.cpp and vm_version_x86.hpp the question asked was then whether to deal with the platform specific code by: a) keeping the existing 4 files in addition to the 2 new ones (assuming all four are still needed); or b) use ifdef's in the new files and discard the 4 old ones I responded that the tendency in HS has been to use separate files rather than ifdef's - hence I would vote for (a) with a view to maintaining consistency. But that's just my view. Cheers, David Vladimir Kozlov said the following on 02/23/09 10:00: > Sorry, > > It could be small misunderstanding. I should not be using > 'common' word in my replay to Christian. > > What Christian asked, I suggested to him and he agreed > is to have 2 files with #ifdef: > > vm_version_x86.cpp and vm_version_x86.hpp > > instead of current 4 files: > > vm_version_x86_32.cpp, vm_version_x86_32.hpp, > vm_version_x86_64.cpp, vm_version_x86_64.hpp > > That is all. > > Thanks, > Vladimir > > David Holmes - Sun Microsystems wrote: >> Vladimir Kozlov said the following on 02/23/09 09:38: >>> Actually we are merging x86 source as much as possible >>> to avoid duplicated changes for 32- and 64-bits. >>> Steve Goldman started this work and Tom did additional changes. >>> So Christian's suggestion is in the line with this work. >>> >>> It is better to have 2 files with few #ifdef then 4 separate file >>> which have 80% (or more) of the same duplicated code. >> >> But what Christian is doing is factoring out that 80% into 1 file and >> then we have two files with the 20% that is different. I'd rather see >> that than a single file with 20% of the code ifdef'd. >> >> Just my 2c. >> >> David >> >>> Thanks, >>> Vladimir >>> >>> David Holmes - Sun Microsystems wrote: >>>> Looking at the HS sources the tendency has been to separate files >>>> rather #ifdefs. I know it's not 100% consistent but I'd rather not >>>> help swing the pendulum back the other way unless there's a really >>>> good reason for doing so. >>>> >>>> David Holmes >>>> >>>> Vladimir Kozlov said the following on 02/23/09 06:21: >>>>> Common vm_version_x86.{cpp,hpp} with #ifdef as we did for >>>>> assembler_x86.?pp >>>>> >>>>> Vladimir >>>>> >>>>> Christian Thalinger wrote: >>>>>> On Fri, 2009-02-20 at 11:35 -0500, Paul Hohensee wrote: >>>>>>> Feel free. :) In general, if you're changing things somewhere, >>>>>>> feel free to refactor. >>>>>> >>>>>> Great :-) Should I merge them into a common vm_version_x86.{cpp,hpp} >>>>>> plus specific vm_version_x86_{32,64}.{cpp,hpp} files or just a single >>>>>> vm_version_x86.{cpp,hpp} with #ifdef's? >>>>>> >>>>>> There would be very few #ifdef's but I would prefer the former >>>>>> approach. >>>>>> >>>>>> -- Christian >>>>>> From Y.S.Ramakrishna at Sun.COM Sun Feb 22 22:18:15 2009 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Sun, 22 Feb 2009 22:18:15 -0800 Subject: OpenJDK/hotspot browsable current source? In-Reply-To: <49A0AC20.10901@Sun.COM> References: <72b0bae542d9.49a02fe0@sun.com> <49A0AC20.10901@Sun.COM> Message-ID: <6b30bc7b25d8.49a1cf27@sun.com> Thanks for the intsructions, Peter! Hopefully that should get SR going. Yes, a cross-linked source in the manner of OpenGrok's would be most desirable for those who want to efficiently browse the source without cloning and maintaining their child repo. -- ramki ----- Original Message ----- From: "Peter B. Kessler" Date: Saturday, February 21, 2009 5:37 pm Subject: Re: OpenJDK/hotspot browsable current source? To: Y Srinivas Ramakrishna Cc: sr at computer.org, hotspot-dev at openjdk.java.net > When I want to browse the current sources in the HotSpot tree, I start > from > > http://openjdk.java.net/ > > click on the (tiny) "7" in "Source code / Mercurial (6, 7)" from the > left-hand navigation panel. That gets me to the JDK Master forest. I > add "/hotspot" to that URL to get to the root of the HotSpot tree. > Then I click on the "manifest" for the change (or tag, or branch). > That gets me to a page where I can rummage around in what I think of > as "the HotSpot sources. E.g., the current one is > > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/d61c7c22b25c > > and from there you can click down to, for example, > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/d61c7c22b25c/src/share/vm/runtime/globals.hpp > > (which I see you changed 3 weeks ago). > > A bit of history: the OpenGrok instance was running on a private web > site registered by Tom Marble. I assume he's let it expire. The plan > was always to run an OpenGrok instance on openjdk.java.net, but I > don't think that's moved beyond the "plan" stage, and the plan may > have changed. > > ... peter > > Y Srinivas Ramakrishna wrote: > >It seems that both the links to browsable source from > >this page:- > > > >http://openjdk.java.net/groups/hotspot/ > > > >viz. :- > > > >https://openjdk.dev.java.net/source/browse/openjdk/jdk/trunk/ > > > >and > > > >http://opengrok.neojava.org/hotspot > > > >are now obsolete, with the first not pointing to > >source that is apparently more than a year old, > >and the second a broken link. > > > >Does anyone know if there's an open > >"current" browsable source of (some suitable master > >forest repo of) OpenJDK 7 somewhere that we can > >link to above? > > > >-- ramki > From Christian.Thalinger at Sun.COM Sun Feb 22 23:49:31 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 23 Feb 2009 08:49:31 +0100 Subject: merge vm_version_x86_{32,64}.hpp In-Reply-To: <49A1E960.6080608@sun.com> References: <1235123937.11128.10.camel@localhost.localdomain> <499EDBE0.1000504@sun.com> <1235327339.11128.42.camel@localhost.localdomain> <49A1B3D9.3060508@sun.com> <49A1DED4.7040805@sun.com> <49A1E1D9.7040902@sun.com> <49A1E437.7050102@sun.com> <49A1E733.8010402@sun.com> <49A1E960.6080608@sun.com> Message-ID: <1235375371.11128.47.camel@localhost.localdomain> On Mon, 2009-02-23 at 10:10 +1000, David Holmes - Sun Microsystems wrote: > Hi Vladimir, > > Christian's proposal was to take the existing four files: > > > vm_version_x86_32.cpp, vm_version_x86_32.hpp, > > vm_version_x86_64.cpp, vm_version_x86_64.hpp > > and to factor out the common code into: > > > vm_version_x86.cpp and vm_version_x86.hpp > > the question asked was then whether to deal with the platform specific > code by: > > a) keeping the existing 4 files in addition to the 2 new ones (assuming > all four are still needed); or > > b) use ifdef's in the new files and discard the 4 old ones Right, that is what I was trying to ask. Sorry if that wasn't clear enough. -- Christian From Christian.Thalinger at Sun.COM Sun Feb 22 23:50:58 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 23 Feb 2009 08:50:58 +0100 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <49A1E2F0.7050700@sun.com> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> <49A1E2F0.7050700@sun.com> Message-ID: <1235375458.11128.49.camel@localhost.localdomain> On Mon, 2009-02-23 at 09:42 +1000, David Holmes - Sun Microsystems wrote: > Andrew, > > I think some of these need to be looked at more closely: > > // Print out the dictionary contents as key-value pairs > -static void dumpekey(const void* key) { fprintf(stdout, "%s", key); } > +static void dumpekey(const void* key) { fprintf(stdout, "%p", key); } > > As far as I can see an ExprDict key is always a char*, hence %s is what > we want not %p. So the right fix would be to cast key to char* . Right, I also saw that one and fill fix that before the second review round. -- Christian From Christian.Thalinger at Sun.COM Mon Feb 23 03:46:07 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 23 Feb 2009 12:46:07 +0100 Subject: merge vm_version_x86_{32,64}.hpp In-Reply-To: <1235375371.11128.47.camel@localhost.localdomain> References: <1235123937.11128.10.camel@localhost.localdomain> <499EDBE0.1000504@sun.com> <1235327339.11128.42.camel@localhost.localdomain> <49A1B3D9.3060508@sun.com> <49A1DED4.7040805@sun.com> <49A1E1D9.7040902@sun.com> <49A1E437.7050102@sun.com> <49A1E733.8010402@sun.com> <49A1E960.6080608@sun.com> <1235375371.11128.47.camel@localhost.localdomain> Message-ID: <1235389567.11128.65.camel@localhost.localdomain> On Mon, 2009-02-23 at 08:49 +0100, Christian Thalinger wrote: > On Mon, 2009-02-23 at 10:10 +1000, David Holmes - Sun Microsystems > wrote: > > Hi Vladimir, > > > > Christian's proposal was to take the existing four files: > > > > > vm_version_x86_32.cpp, vm_version_x86_32.hpp, > > > vm_version_x86_64.cpp, vm_version_x86_64.hpp > > > > and to factor out the common code into: > > > > > vm_version_x86.cpp and vm_version_x86.hpp > > > > the question asked was then whether to deal with the platform specific > > code by: > > > > a) keeping the existing 4 files in addition to the 2 new ones (assuming > > all four are still needed); or > > > > b) use ifdef's in the new files and discard the 4 old ones Okay, there are way too less differences to keep the old specific files around. There are only two differences I'm not sure about: @@ -418,31 +355,32 @@ if( AllocatePrefetchStyle == 2 && is_intel() && cpu_family() == 6 && supports_sse3() ) { // watermark prefetching on Core - AllocatePrefetchDistance = 320; + AllocatePrefetchDistance = 384; } assert(AllocatePrefetchDistance % AllocatePrefetchStepSize == 0, "invalid value"); + // Prefetch settings + PrefetchCopyIntervalInBytes = prefetch_copy_interval_in_bytes(); + PrefetchScanIntervalInBytes = prefetch_scan_interval_in_bytes(); + PrefetchFieldsAhead = prefetch_fields_ahead(); + For the first one, I'm not sure which value to choose or if they should be different on 32 and 64-bit? And the second, I'm not sure I can set them on 32-bit. Per default these are -1. Besides that, there's only one real difference: + // OS should support SSE for x64 and hardware should support at least SSE2. + if (!VM_Version::supports_sse2()) { + vm_exit_during_initialization("Unknown x64 processor: SSE2 not supported"); } Is that check really necessary on x64? If so, I simply put it inside an #ifdef. -- Christian From Paul.Hohensee at Sun.COM Mon Feb 23 04:29:02 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Mon, 23 Feb 2009 07:29:02 -0500 Subject: merge vm_version_x86_{32,64}.hpp In-Reply-To: <1235389567.11128.65.camel@localhost.localdomain> References: <1235123937.11128.10.camel@localhost.localdomain> <499EDBE0.1000504@sun.com> <1235327339.11128.42.camel@localhost.localdomain> <49A1B3D9.3060508@sun.com> <49A1DED4.7040805@sun.com> <49A1E1D9.7040902@sun.com> <49A1E437.7050102@sun.com> <49A1E733.8010402@sun.com> <49A1E960.6080608@sun.com> <1235375371.11128.47.camel@localhost.localdomain> <1235389567.11128.65.camel@localhost.localdomain> Message-ID: <49A2968E.9080509@sun.com> Imo, the #ifdef's are ok in this case because they're quite limited. Vladimir set prefetch distances based on experiment. The difference between 320 and 384 is a single cache line. It seems to me that 32 and 64-bit would be the same because it's the same hardware, except that it may be that 64-bit code is faster than 32-bit code, thus would require a slightly greater prefetch distance. 32-bit doesn't use the Prefetchxxx switches because there's no common prefetch instruction for 32-bit that can be used in C++ code. #ifdef is ok here. Paul Christian Thalinger wrote: > On Mon, 2009-02-23 at 08:49 +0100, Christian Thalinger wrote: > >> On Mon, 2009-02-23 at 10:10 +1000, David Holmes - Sun Microsystems >> wrote: >> >>> Hi Vladimir, >>> >>> Christian's proposal was to take the existing four files: >>> >>> > vm_version_x86_32.cpp, vm_version_x86_32.hpp, >>> > vm_version_x86_64.cpp, vm_version_x86_64.hpp >>> >>> and to factor out the common code into: >>> >>> > vm_version_x86.cpp and vm_version_x86.hpp >>> >>> the question asked was then whether to deal with the platform specific >>> code by: >>> >>> a) keeping the existing 4 files in addition to the 2 new ones (assuming >>> all four are still needed); or >>> >>> b) use ifdef's in the new files and discard the 4 old ones >>> > > Okay, there are way too less differences to keep the old specific files > around. There are only two differences I'm not sure about: > > @@ -418,31 +355,32 @@ > > if( AllocatePrefetchStyle == 2 && is_intel() && > cpu_family() == 6 && supports_sse3() ) { // watermark prefetching on Core > - AllocatePrefetchDistance = 320; > + AllocatePrefetchDistance = 384; > } > assert(AllocatePrefetchDistance % AllocatePrefetchStepSize == 0, "invalid value"); > > + // Prefetch settings > + PrefetchCopyIntervalInBytes = prefetch_copy_interval_in_bytes(); > + PrefetchScanIntervalInBytes = prefetch_scan_interval_in_bytes(); > + PrefetchFieldsAhead = prefetch_fields_ahead(); > + > > For the first one, I'm not sure which value to choose or if they should > be different on 32 and 64-bit? > > And the second, I'm not sure I can set them on 32-bit. Per default > these are -1. > > Besides that, there's only one real difference: > > + // OS should support SSE for x64 and hardware should support at least SSE2. > + if (!VM_Version::supports_sse2()) { > + vm_exit_during_initialization("Unknown x64 processor: SSE2 not supported"); > } > > Is that check really necessary on x64? If so, I simply put it inside an > #ifdef. > > -- Christian > > From Christian.Thalinger at Sun.COM Mon Feb 23 05:05:18 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 23 Feb 2009 14:05:18 +0100 Subject: merge vm_version_x86_{32,64}.hpp In-Reply-To: <49A2968E.9080509@sun.com> References: <1235123937.11128.10.camel@localhost.localdomain> <499EDBE0.1000504@sun.com> <1235327339.11128.42.camel@localhost.localdomain> <49A1B3D9.3060508@sun.com> <49A1DED4.7040805@sun.com> <49A1E1D9.7040902@sun.com> <49A1E437.7050102@sun.com> <49A1E733.8010402@sun.com> <49A1E960.6080608@sun.com> <1235375371.11128.47.camel@localhost.localdomain> <1235389567.11128.65.camel@localhost.localdomain> <49A2968E.9080509@sun.com> Message-ID: <1235394318.11128.69.camel@localhost.localdomain> On Mon, 2009-02-23 at 07:29 -0500, Paul Hohensee wrote: > Imo, the #ifdef's are ok in this case because they're quite limited. > > Vladimir set prefetch distances based on experiment. The difference > between 320 and 384 is a single cache line. It seems to me that 32 > and 64-bit would be the same because it's the same hardware, except > that it may be that 64-bit code is faster than 32-bit code, thus would > require a slightly greater prefetch distance. > > 32-bit doesn't use the Prefetchxxx switches because there's no common > prefetch instruction for 32-bit that can be used in C++ code. #ifdef is > ok here. Paul, thank you for the explanation. Last question: should I use the _LP64 or AMD64 define? -- Christian From Vladimir.Kozlov at Sun.COM Mon Feb 23 05:39:42 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 23 Feb 2009 05:39:42 -0800 Subject: merge vm_version_x86_{32,64}.hpp In-Reply-To: <1235394318.11128.69.camel@localhost.localdomain> References: <1235123937.11128.10.camel@localhost.localdomain> <499EDBE0.1000504@sun.com> <1235327339.11128.42.camel@localhost.localdomain> <49A1B3D9.3060508@sun.com> <49A1DED4.7040805@sun.com> <49A1E1D9.7040902@sun.com> <49A1E437.7050102@sun.com> <49A1E733.8010402@sun.com> <49A1E960.6080608@sun.com> <1235375371.11128.47.camel@localhost.localdomain> <1235389567.11128.65.camel@localhost.localdomain> <49A2968E.9080509@sun.com> <1235394318.11128.69.camel@localhost.localdomain> Message-ID: <49A2A71E.5030909@sun.com> Christian Thalinger wrote: > On Mon, 2009-02-23 at 07:29 -0500, Paul Hohensee wrote: >> Imo, the #ifdef's are ok in this case because they're quite limited. >> >> Vladimir set prefetch distances based on experiment. The difference >> between 320 and 384 is a single cache line. It seems to me that 32 >> and 64-bit would be the same because it's the same hardware, except >> that it may be that 64-bit code is faster than 32-bit code, thus would >> require a slightly greater prefetch distance. No, it is because different average allocation object's size (different oop size). >> >> 32-bit doesn't use the Prefetchxxx switches because there's no common >> prefetch instruction for 32-bit that can be used in C++ code. #ifdef is >> ok here. That is correct. > > Paul, thank you for the explanation. Last question: should I use the > _LP64 or AMD64 define? > > -- Christian > Vladimir From Vladimir.Kozlov at Sun.COM Mon Feb 23 05:47:00 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 23 Feb 2009 05:47:00 -0800 Subject: merge vm_version_x86_{32,64}.hpp In-Reply-To: <49A2A71E.5030909@sun.com> References: <1235123937.11128.10.camel@localhost.localdomain> <499EDBE0.1000504@sun.com> <1235327339.11128.42.camel@localhost.localdomain> <49A1B3D9.3060508@sun.com> <49A1DED4.7040805@sun.com> <49A1E1D9.7040902@sun.com> <49A1E437.7050102@sun.com> <49A1E733.8010402@sun.com> <49A1E960.6080608@sun.com> <1235375371.11128.47.camel@localhost.localdomain> <1235389567.11128.65.camel@localhost.localdomain> <49A2968E.9080509@sun.com> <1235394318.11128.69.camel@localhost.localdomain> <49A2A71E.5030909@sun.com> Message-ID: <49A2A8D4.3020202@sun.com> Use _LP64 define Vladimir Vladimir Kozlov wrote: > > > Christian Thalinger wrote: >> On Mon, 2009-02-23 at 07:29 -0500, Paul Hohensee wrote: >>> Imo, the #ifdef's are ok in this case because they're quite limited. >>> >>> Vladimir set prefetch distances based on experiment. The difference >>> between 320 and 384 is a single cache line. It seems to me that 32 >>> and 64-bit would be the same because it's the same hardware, except >>> that it may be that 64-bit code is faster than 32-bit code, thus would >>> require a slightly greater prefetch distance. > > No, it is because different average allocation object's size (different > oop size). > >>> >>> 32-bit doesn't use the Prefetchxxx switches because there's no common >>> prefetch instruction for 32-bit that can be used in C++ code. #ifdef is >>> ok here. > > That is correct. > > >> >> Paul, thank you for the explanation. Last question: should I use the >> _LP64 or AMD64 define? >> >> -- Christian >> > > Vladimir From Christian.Thalinger at Sun.COM Mon Feb 23 06:21:16 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 23 Feb 2009 15:21:16 +0100 Subject: Request for review (M): 6808589: Merge vm_version_x86_{32, 64}.{cpp, hpp} Message-ID: <1235398876.11128.74.camel@localhost.localdomain> http://cr.openjdk.java.net/~twisti/6808589/webrev.00/ From Vladimir.Kozlov at Sun.COM Mon Feb 23 06:45:32 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 23 Feb 2009 06:45:32 -0800 Subject: Request for review (M): 6808589: Merge vm_version_x86_{32, 64}.{cpp, hpp} In-Reply-To: <1235398876.11128.74.camel@localhost.localdomain> References: <1235398876.11128.74.camel@localhost.localdomain> Message-ID: <49A2B68C.3090002@sun.com> Looks good Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6808589/webrev.00/ > From aph at redhat.com Mon Feb 23 07:03:28 2009 From: aph at redhat.com (Andrew Haley) Date: Mon, 23 Feb 2009 15:03:28 +0000 Subject: Template interpreter::notice_safepoints() In-Reply-To: <499EFAD7.4090708@sun.com> References: <499EE9C8.7090609@redhat.com> <20F9DFB3-CF58-4390-A423-50E41F6E7A7F@sun.com> <499EFAD7.4090708@sun.com> Message-ID: <49A2BAC0.1000504@redhat.com> Sure, that makes sense. When I'm writing concurrent code I have in mind "Hell's Computer", which is the worst possible machine that honours the guarantees of POSIX threads and the WG14 work on the semantics of multithreaded programs in C++. (As an example of WG14's thinking, "Our current approach largely follows Pthreads and leaves the semantics undefined if there is a data race, i.e. if a program modifies a location while another thread is accessing it.") But as you say, no real machine is quite as bad as Hell's Computer, for which we perhaps should be grateful. I'm interested in this issue because Ed Nevill of ARM suggested a modification to the C++ interpreter that implements notice_safepoints() in the same way as the template interpreter. It seems that, as long as we use the polling page, we might be able to do this. However, Tom Rodriguez' suggestion requires fewer assumptions. load_ptr_acquire() does nothing except the load on x86/GNU/Linux and SPARC/Solaris: inline intptr_t OrderAccess::load_ptr_acquire(volatile intptr_t* p) { return *p; } So, if we implemented instruction dispatch as #define DISPATCH(opcode) goto load_ptr_acquire(dispatch_table[opcode]) instead of #define DISPATCH(opcode) goto *dispatch_table[opcode] there would be no performance difference on most processors. The same argument applies to using release_store_ptr() in copy_table(). Andrew. [1] Hans Boehm. Threads cannot be implemented as a library. In Proceedings of the ACM SIGPLAN 2005 Conference on Programming Language Design and Implementation, pages 26?37, 2005. Paul Hohensee wrote: > I believe the safepoint code (safepoint.cpp) switches the > interpreter dispatch table, then protects the polling page via > mprotect(). mprotect() has the effect of a system-wide memory > barrier (because it requires the OS to issue a global TLB > shootdown), so the new dispatch table address will be flushed to > memory in a timely fashion. I think this is a case of "the sum of > the bugs is zero", because I don't think we ever really thought > about it. > > All that aside, I don't know of any SMP that requires programmatic > intervention to synchronize a write across all caches. As long as > the write happens "eventually", which means in a short enough time > to make safepoints "short", I don't think there's a problem > > Tom Rodriguez wrote: >> All the ia64 ports currently use the C++ interpreter so I wouldn't be >> surprised if there are weak cache consistency problems in the template >> interpreter. In practice though you can't run forever in the >> interpreter without going into the runtime at least for a backward >> branch overflow. copy_table probably needs to use release_store_ptr >> and the reads from the table may need to use a load acquire but I'd >> suspect there would be other issues as well. >> >> tom >> >> On Feb 20, 2009, at 9:35 AM, Andrew Haley wrote: >> >>> I'm having a little difficulty understanding how the template >>> interpreter >>> is safe on SMP machines. >>> >>> notice_safepoints() looks like this: >>> >>> void TemplateInterpreter::notice_safepoints() { >>> if (!_notice_safepoints) { >>> // switch to safepoint dispatch table >>> _notice_safepoints = true; >>> copy_table((address*)&_safept_table, (address*)&_active_table, >>> sizeof(_active_table) / sizeof(address)); >>> } >>> } >>> >>> So, the dispatch table is rewritten. But on an SMP machine with >>> weak cache coherency, how does this work? A thread could be >>> executing bytecodes in a loop but never see the change to _active_table >>> because there's nothing to cause its cache to be updated. Is it >>> simply that this code doesn't work on such architectures? >>> >>> Andrew. >> From Paul.Hohensee at Sun.COM Mon Feb 23 07:26:47 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Mon, 23 Feb 2009 10:26:47 -0500 Subject: merge vm_version_x86_{32,64}.hpp In-Reply-To: <1235394318.11128.69.camel@localhost.localdomain> References: <1235123937.11128.10.camel@localhost.localdomain> <499EDBE0.1000504@sun.com> <1235327339.11128.42.camel@localhost.localdomain> <49A1B3D9.3060508@sun.com> <49A1DED4.7040805@sun.com> <49A1E1D9.7040902@sun.com> <49A1E437.7050102@sun.com> <49A1E733.8010402@sun.com> <49A1E960.6080608@sun.com> <1235375371.11128.47.camel@localhost.localdomain> <1235389567.11128.65.camel@localhost.localdomain> <49A2968E.9080509@sun.com> <1235394318.11128.69.camel@localhost.localdomain> Message-ID: <49A2C037.6000704@sun.com> Use _LP64. AMD64 is amd processor-specific, while _LP64 is generic 64-bit. Paul Christian Thalinger wrote: > On Mon, 2009-02-23 at 07:29 -0500, Paul Hohensee wrote: > >> Imo, the #ifdef's are ok in this case because they're quite limited. >> >> Vladimir set prefetch distances based on experiment. The difference >> between 320 and 384 is a single cache line. It seems to me that 32 >> and 64-bit would be the same because it's the same hardware, except >> that it may be that 64-bit code is faster than 32-bit code, thus would >> require a slightly greater prefetch distance. >> >> 32-bit doesn't use the Prefetchxxx switches because there's no common >> prefetch instruction for 32-bit that can be used in C++ code. #ifdef is >> ok here. >> > > Paul, thank you for the explanation. Last question: should I use the > _LP64 or AMD64 define? > > -- Christian > > From Christian.Thalinger at Sun.COM Mon Feb 23 07:37:34 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 23 Feb 2009 16:37:34 +0100 Subject: merge vm_version_x86_{32,64}.hpp In-Reply-To: <49A2C037.6000704@sun.com> References: <1235123937.11128.10.camel@localhost.localdomain> <499EDBE0.1000504@sun.com> <1235327339.11128.42.camel@localhost.localdomain> <49A1B3D9.3060508@sun.com> <49A1DED4.7040805@sun.com> <49A1E1D9.7040902@sun.com> <49A1E437.7050102@sun.com> <49A1E733.8010402@sun.com> <49A1E960.6080608@sun.com> <1235375371.11128.47.camel@localhost.localdomain> <1235389567.11128.65.camel@localhost.localdomain> <49A2968E.9080509@sun.com> <1235394318.11128.69.camel@localhost.localdomain> <49A2C037.6000704@sun.com> Message-ID: <1235403454.11128.80.camel@localhost.localdomain> On Mon, 2009-02-23 at 10:26 -0500, Paul Hohensee wrote: > Use _LP64. AMD64 is amd processor-specific, while _LP64 is generic 64-bit. Interesting. Didn't know that. -- Christian From volker.simonis at gmail.com Mon Feb 23 07:52:43 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 23 Feb 2009 16:52:43 +0100 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: <499F196F.4030002@sun.com> References: <20090220202251.C6173291845@eggemoggin.niobe.net> <499F196F.4030002@sun.com> Message-ID: Just to name a current issue and demonstrate how compilcated it may be to follow the development process, lets consider Bug ID: 6622432 (RFE: Performance improvements to java.math.BigDecimal): On the mailing lists, there was a Request for review: http://www.mail-archive.com/core-libs-dev at openjdk.java.net/msg01095.html http://webrev.invokedynamic.info/xiaobin.lu/6622432/ But I couldn't see a changeset for the bug. So apparently it is not in any of the OpenJDK 7 repositories (at least I couldn't find it). On the other hand, the Bug says "State, 8-Fix Available". Brad Wetmores writes in another thread on this list (http://www.nabble.com/forum/ViewPost.jtp?post=22140212&framed=y): "When the fix is put into one of the gates, the fix goes to "fix available" in bugtraq. It's the gatekeepers who mark as Fix Delivered." So apparently, the change went into a closed "gate". I would guess it could be the "JDK6 RE build" Mercurial repository you mention. Because the list of fixed bugs for JDK 6u14 b01 (http://download.java.net/jdk6/6u14/promoted/b01/changes/JDK6u14.list.html) lists 6622432 as fixed. But this is in contradiction to the status of the bug which is "State, 8-Fix Available". So I assume there must be another Bug Id for the same problem, but neither could I find it in the bug database, nor is there a link from Bug 6622432 to this other bug. If I just want to get the patch for this fix, this is quite confusing - at least for me... Regards, Volker On 2/20/09, James Melvin wrote: > Hi Mark, > > Actually, the Hotspot engineering work is all done in Mercurial. > For the JDK6 RE build, we lazily create a disposable Teamware > workspace from the Mercurial repository... > > hotspot.gpl - Mercurial (read-write) > hotspot - Teamware (read-only, regenerated for builds) > > This mitigates the Mercurial <--> Teamware SCM nightmares. > > - Jim > > > > Mark Reinhold wrote: > > > > > > Date: Fri, 20 Feb 2009 18:17:27 +0000 > > > From: Andrew John Hughes > > > > > > > > > > 2009/2/20 james.melvin at sun.com: > > > > > > > The basic reasoning behind the HS14 fork is two-fold... > > > > > > > > ... > > > > > > > I quite agree with the reasons for the branch, that in itself is a > > > very sensible approach. My issue was with why the stable branch, when > > > created, was not simply done publicly. It's not like anyone can just > > > commit anything they want to it anyway, and a stable HotSpot is > > > valuable for others outside Sun. > > > > > > > As I understand it, the real reason the fork of HS14 wasn't done in the > > open is fairly prosaic: Sun's proprietary 6uX update releases are still > > based on TeamWare, our old internal SCM, rather than Mercurial. When a > > HotSpot "Express" snapshot is taken from JDK 7 it's first converted into > > TeamWare, and that's where the stabilization work is done. > > > > Joe Darcy has been working with the HotSpot team to revise this practice > > so that such work can take place in the open. Hopefully he'll have some > > news on that soon. > > > > - Mark > > > From Christian.Thalinger at Sun.COM Mon Feb 23 08:47:21 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 23 Feb 2009 17:47:21 +0100 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> Message-ID: <1235407641.11128.98.camel@localhost.localdomain> On Sun, 2009-02-22 at 20:35 +0000, Andrew John Hughes wrote: > /tmp/hotspot-comp/hotspot/src/share/vm/adlc/output_c.cpp:1251: error: format '%d' expects type 'int', but argument 3 has type 'intptr_t' > /tmp/hotspot-comp/hotspot/src/share/vm/adlc/output_c.cpp:1256: error: format '%d' expects type 'int', but argument 3 has type 'intptr_t' > /tmp/hotspot-comp/hotspot/src/share/vm/adlc/output_c.cpp:1256: error: format '%d' expects type 'int', but argument 5 has type 'intptr_t' I was looking more closely at these and it seems it's not really necessary that the type is an intptr_t. There is even an assert in output_c.cpp (left_index is one of the warnings): assert( (left_index <= 9999) && (left_op_index <= 9999), "exceed string size"); Digging further into the code and changing the intptr_t's to int's revealed that in some classes a NameList is used to store these integers, e.g.: class PeepMatch : public Form { private: char *_rule; // NameList _depth; // Depth of this instruction NameList _parent; NameList _position; The integers are stored like: void PeepMatch::add_instruction(intptr_t parent, intptr_t position, const char *name, intptr_t input) { if( position > _max_position ) _max_position = position; _parent.addName((char *)parent); _position.addName((char *)position); (Note: _max_position is an int) And retrieved with: void PeepMatch::next_instruction(intptr_t &parent, intptr_t &position, const char* &name, intptr_t &input) { parent = (intptr_t) _parent.iter(); position = (intptr_t) _position.iter(); Would it be possible to use std::vector or std::list instead of a NameList for these integers? -- Christian From Christian.Thalinger at Sun.COM Mon Feb 23 09:30:37 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 23 Feb 2009 18:30:37 +0100 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <1235407641.11128.98.camel@localhost.localdomain> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> <1235407641.11128.98.camel@localhost.localdomain> Message-ID: <1235410237.11128.103.camel@localhost.localdomain> On Mon, 2009-02-23 at 17:47 +0100, Christian Thalinger wrote: > void PeepMatch::next_instruction(intptr_t &parent, intptr_t &position, const char* &name, intptr_t &input) { > parent = (intptr_t) _parent.iter(); > position = (intptr_t) _position.iter(); > > Would it be possible to use std::vector or std::list instead > of a NameList for these integers? Ohh, right, and the hackish solution would be: +void PeepMatch::next_instruction(int &parent, int &position, const char* &name, int &input) { + parent = (int) (intptr_t) _parent.iter(); + position = (int) (intptr_t) _position.iter(); -- Christian From gnu_andrew at member.fsf.org Mon Feb 23 10:11:32 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 23 Feb 2009 18:11:32 +0000 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <49A1E2F0.7050700@sun.com> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> <49A1E2F0.7050700@sun.com> Message-ID: <17c6771e0902231011l7f9bef6fjdfd03591b928be05@mail.gmail.com> 2009/2/22 David Holmes - Sun Microsystems : > Andrew, > > I think some of these need to be looked at more closely: > > ?// Print out the dictionary contents as key-value pairs > -static void dumpekey(const void* key) ?{ fprintf(stdout, "%s", key); } > +static void dumpekey(const void* key) ?{ fprintf(stdout, "%p", key); } > > As far as I can see an ExprDict key is always a char*, hence %s is what we > want not %p. So the right fix would be to cast key to char* . > > David Holmes > > Andrew John Hughes said the following on 02/23/09 06:35: >> >> 2009/2/22 Christian Thalinger : >>> >>> On Sun, 2009-02-22 at 12:18 -0800, Vladimir Kozlov wrote: >>>> >>>> Christian, >>>> >>>> Your changes looks good. >>>> Could you also look on and possibly include fixes for hsdis build on >>>> linux. >>> >>> Ahh, right! ?There was an issue on Linux. ?I will include the attached >>> patches. >>> >>> Andrew tested the patch and there seem to be a ton of warnings... sigh. >>> We try to fix them. >>> >>> -- Christian >>> >>> >> >> Even with this patch, there seem to be major issues in the ADLC parser >> with GCC 4.3.3 on x86_64. ?I assume IcedTea gets round them with the >> patch to turn off -Werror. >> >> Attached is an extended version of twisti's patch which starts to fix >> some of the issues in adlc. ?I've also included the build log with >> this applied. >> > Yes, I wasn't suggesting a solution, just something to make it build :) I thought it likely that it should be a char*, but, given the function takes a void *, %p seemed the safest choice for the printf format specifier. -- 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 Thomas.Rodriguez at Sun.COM Mon Feb 23 10:36:58 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 23 Feb 2009 10:36:58 -0800 Subject: Request for review (M): 6808589: Merge vm_version_x86_{32, 64}.{cpp, hpp} In-Reply-To: <1235398876.11128.74.camel@localhost.localdomain> References: <1235398876.11128.74.camel@localhost.localdomain> Message-ID: <67B88A44-B695-4D56-82F6-2245E078D92B@sun.com> Looks good. Thanks for doing this. Steve had merged all the important files but there are still a few left like this one. tom On Feb 23, 2009, at 6:21 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6808589/webrev.00/ > From sr at computer.org Mon Feb 23 07:19:41 2009 From: sr at computer.org (S.R. Venkatramanan) Date: Mon, 23 Feb 2009 07:19:41 -0800 Subject: OpenJDK/hotspot browsable current source? In-Reply-To: <49A0AC20.10901@Sun.COM> References: <72b0bae542d9.49a02fe0@sun.com> <49A0AC20.10901@Sun.COM> Message-ID: <49A2BE8D.30700@computer.org> Peter, Thanks for the detailed instructions. I got a browsable tree now! Ramki, thanks to you too. S.R. Peter B. Kessler wrote: > When I want to browse the current sources in the HotSpot tree, I start > from > > http://openjdk.java.net/ > > click on the (tiny) "7" in "Source code / Mercurial (6, 7)" from the > left-hand navigation panel. That gets me to the JDK Master forest. I > add "/hotspot" to that URL to get to the root of the HotSpot tree. > Then I click on the "manifest" for the change (or tag, or branch). > That gets me to a page where I can rummage around in what I think of > as "the HotSpot sources. E.g., the current one is > > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/d61c7c22b25c > > and from there you can click down to, for example, > > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/d61c7c22b25c/src/share/vm/runtime/globals.hpp > > > (which I see you changed 3 weeks ago). > > A bit of history: the OpenGrok instance was running on a private web > site registered by Tom Marble. I assume he's let it expire. The plan > was always to run an OpenGrok instance on openjdk.java.net, but I > don't think that's moved beyond the "plan" stage, and the plan may > have changed. > > ... peter > > Y Srinivas Ramakrishna wrote: > >> It seems that both the links to browsable source from >> this page:- >> >> http://openjdk.java.net/groups/hotspot/ >> >> viz. :- >> >> https://openjdk.dev.java.net/source/browse/openjdk/jdk/trunk/ >> >> and >> >> http://opengrok.neojava.org/hotspot >> >> are now obsolete, with the first not pointing to >> source that is apparently more than a year old, >> and the second a broken link. >> >> Does anyone know if there's an open >> "current" browsable source of (some suitable master >> forest repo of) OpenJDK 7 somewhere that we can >> link to above? >> >> -- ramki > > > From James.Melvin at Sun.COM Mon Feb 23 11:26:55 2009 From: James.Melvin at Sun.COM (James Melvin) Date: Mon, 23 Feb 2009 14:26:55 -0500 Subject: How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default') In-Reply-To: References: <20090220202251.C6173291845@eggemoggin.niobe.net> <499F196F.4030002@sun.com> Message-ID: <49A2F87F.2060702@sun.com> Hi Volker, The SCM for class libraries is different between JDK 6 and JDK 7... JDK 6 Hotspot - Mercurial Libraries - Teamware JDK7 Hotspot - Mercurial Libraries - Mercurial So, you will not find any 'changeset' in JDK 6 for this particular libraries enhancement. Thanks, Jim Volker Simonis wrote: > Just to name a current issue and demonstrate how compilcated it may be > to follow the development process, lets consider Bug ID: 6622432 (RFE: > Performance improvements to java.math.BigDecimal): > > On the mailing lists, there was a Request for review: > > http://www.mail-archive.com/core-libs-dev at openjdk.java.net/msg01095.html > http://webrev.invokedynamic.info/xiaobin.lu/6622432/ > > But I couldn't see a changeset for the bug. So apparently it is not in > any of the OpenJDK 7 repositories (at least I couldn't find it). > > On the other hand, the Bug says "State, 8-Fix Available". Brad > Wetmores writes in another thread on this list > (http://www.nabble.com/forum/ViewPost.jtp?post=22140212&framed=y): > "When the fix is put into one of the gates, the fix goes to "fix > available" in bugtraq. It's the gatekeepers who mark as Fix > Delivered." So apparently, the change went into a closed "gate". > > I would guess it could be the "JDK6 RE build" Mercurial repository you > mention. Because the list of fixed bugs for JDK 6u14 b01 > (http://download.java.net/jdk6/6u14/promoted/b01/changes/JDK6u14.list.html) > lists 6622432 as fixed. But this is in contradiction to the status of > the bug which is "State, 8-Fix Available". > > So I assume there must be another Bug Id for the same problem, but > neither could I find it in the bug database, nor is there a link from > Bug 6622432 to this other bug. > > If I just want to get the patch for this fix, this is quite confusing > - at least for me... > > Regards, > Volker > > On 2/20/09, James Melvin wrote: >> Hi Mark, >> >> Actually, the Hotspot engineering work is all done in Mercurial. >> For the JDK6 RE build, we lazily create a disposable Teamware >> workspace from the Mercurial repository... >> >> hotspot.gpl - Mercurial (read-write) >> hotspot - Teamware (read-only, regenerated for builds) >> >> This mitigates the Mercurial <--> Teamware SCM nightmares. >> >> - Jim >> >> >> >> Mark Reinhold wrote: >> >>>> Date: Fri, 20 Feb 2009 18:17:27 +0000 >>>> From: Andrew John Hughes >>>> >>> >>>> 2009/2/20 james.melvin at sun.com: >>>> >>>>> The basic reasoning behind the HS14 fork is two-fold... >>>>> >>>>> ... >>>>> >>>> I quite agree with the reasons for the branch, that in itself is a >>>> very sensible approach. My issue was with why the stable branch, when >>>> created, was not simply done publicly. It's not like anyone can just >>>> commit anything they want to it anyway, and a stable HotSpot is >>>> valuable for others outside Sun. >>>> >>> As I understand it, the real reason the fork of HS14 wasn't done in the >>> open is fairly prosaic: Sun's proprietary 6uX update releases are still >>> based on TeamWare, our old internal SCM, rather than Mercurial. When a >>> HotSpot "Express" snapshot is taken from JDK 7 it's first converted into >>> TeamWare, and that's where the stabilization work is done. >>> >>> Joe Darcy has been working with the HotSpot team to revise this practice >>> so that such work can take place in the open. Hopefully he'll have some >>> news on that soon. >>> >>> - Mark >>> From Thomas.Rodriguez at Sun.COM Mon Feb 23 11:43:38 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 23 Feb 2009 11:43:38 -0800 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <1235410237.11128.103.camel@localhost.localdomain> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> <1235407641.11128.98.camel@localhost.localdomain> <1235410237.11128.103.camel@localhost.localdomain> Message-ID: <8B73CF14-A44D-4460-870F-B4D65E204312@sun.com> Given the way that NameList is being abused in the code, I think (int) (intptr_t) preserves the intent of storing ints so I think I prefer your patch below. tom On Feb 23, 2009, at 9:30 AM, Christian Thalinger wrote: > On Mon, 2009-02-23 at 17:47 +0100, Christian Thalinger wrote: >> void PeepMatch::next_instruction(intptr_t &parent, intptr_t >> &position, const char* &name, intptr_t &input) { >> parent = (intptr_t) _parent.iter(); >> position = (intptr_t) _position.iter(); >> >> Would it be possible to use std::vector or std::list >> instead >> of a NameList for these integers? > > Ohh, right, and the hackish solution would be: > > +void PeepMatch::next_instruction(int &parent, int &position, const > char* &name, int &input) { > + parent = (int) (intptr_t) _parent.iter(); > + position = (int) (intptr_t) _position.iter(); > > -- Christian > From Christian.Thalinger at Sun.COM Mon Feb 23 11:53:10 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 23 Feb 2009 20:53:10 +0100 Subject: Request for review (M): 6808589: Merge vm_version_x86_{32, 64}.{cpp, hpp} In-Reply-To: <67B88A44-B695-4D56-82F6-2245E078D92B@sun.com> References: <1235398876.11128.74.camel@localhost.localdomain> <67B88A44-B695-4D56-82F6-2245E078D92B@sun.com> Message-ID: <1235418790.11128.119.camel@localhost.localdomain> On Mon, 2009-02-23 at 10:36 -0800, Tom Rodriguez wrote: > Looks good. Thanks for doing this. Steve had merged all the > important files but there are still a few left like this one. No problem. I will fix the missing ones too if you have some specific pointers. Btw. can someone look at CR 6808665 and tell me if that's still used/supported? -- Christian From Thomas.Rodriguez at Sun.COM Mon Feb 23 12:15:01 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 23 Feb 2009 12:15:01 -0800 Subject: Request for review (M): 6808589: Merge vm_version_x86_{32, 64}.{cpp, hpp} In-Reply-To: <1235418790.11128.119.camel@localhost.localdomain> References: <1235398876.11128.74.camel@localhost.localdomain> <67B88A44-B695-4D56-82F6-2245E078D92B@sun.com> <1235418790.11128.119.camel@localhost.localdomain> Message-ID: <95E24FCB-CF1E-4D1D-ADA3-9CE3C613DDB2@Sun.COM> On Feb 23, 2009, at 11:53 AM, Christian Thalinger wrote: > On Mon, 2009-02-23 at 10:36 -0800, Tom Rodriguez wrote: >> Looks good. Thanks for doing this. Steve had merged all the >> important files but there are still a few left like this one. > > No problem. I will fix the missing ones too if you have some specific > pointers. vm_version was easy and it's a file we modify relatively often so it was time well spent to my thinking. The others are mostly harder because of things like ABI differences or larger implementation differences, like the interpreter and many of the stubs. I don't see any others that are both important and amenable to merging. > Btw. can someone look at CR 6808665 and tell me if that's still > used/supported? It looks like a dead flag to me though I think it could be made to work again if anyone cared. I suspect since no one has complained before now that it's dead and could be removed. tom > > > -- Christian > From Vladimir.Kozlov at Sun.COM Mon Feb 23 12:34:17 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 23 Feb 2009 12:34:17 -0800 Subject: Request for review (M): 6808589: Merge vm_version_x86_{32, 64}.{cpp, hpp} In-Reply-To: <1235418790.11128.119.camel@localhost.localdomain> References: <1235398876.11128.74.camel@localhost.localdomain> <67B88A44-B695-4D56-82F6-2245E078D92B@sun.com> <1235418790.11128.119.camel@localhost.localdomain> Message-ID: <49A30849.5030000@sun.com> About 6808665. There is (still) other company besides Intel and AMD who produce x86 cpus. I surprise we don't hear anything from it since our current implementation looks for the features of Intel and AMD cpus only. The code was added for 4395702 bug. Anyway, I think, you can avoid the assert if you set std_cpuid1_rax.bits.family value: void VM_Version::get_processor_features() { _cpu = 4; // 486 by default + _cpuid_info.std_cpuid1_rax.bits.family = 4; _model = 0; _stepping = 0; _cpuFeatures = 0; _logical_processors_per_package = 1; if (!Use486InstrsOnly) { Vladimir Christian Thalinger wrote: > On Mon, 2009-02-23 at 10:36 -0800, Tom Rodriguez wrote: >> Looks good. Thanks for doing this. Steve had merged all the >> important files but there are still a few left like this one. > > No problem. I will fix the missing ones too if you have some specific > pointers. > > Btw. can someone look at CR 6808665 and tell me if that's still > used/supported? > > -- Christian > From dawn2004 at gmail.com Mon Feb 23 12:55:01 2009 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Mon, 23 Feb 2009 12:55:01 -0800 (PST) Subject: Question about fast path and slow path Message-ID: <22169919.post@talk.nabble.com> Hello, I have some questions about jvm slow path to ask you: 1. How can we force jvm to go slow path? Is there any jvm options? 2. What's the difference between slow path and fast path? 3. During slow path, will the interpreter translate the bytecode into assembly codes? Thanks a lot! Colin -- View this message in context: http://www.nabble.com/Question-about-fast-path-and-slow-path-tp22169919p22169919.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From Karen.Kinnear at Sun.COM Mon Feb 23 13:14:11 2009 From: Karen.Kinnear at Sun.COM (Karen Kinnear) Date: Mon, 23 Feb 2009 16:14:11 -0500 Subject: Unicode support in Java JRE on Windows In-Reply-To: References: Message-ID: <49A311A3.1070904@sun.com> Heiko, I'm copying this to the core-libs-dev at openjdk.java.net alias, since I think the APIs you are referring to are more familiar to that team. And I've retitled it "Java JRE" so folks see the bigger picture. hope this helps, Karen Heiko Wagner wrote: > Hi, > > I am currently investigating on a problem of the Java VM on Windows. The VM > is started using the JNI invocation api. This works unless the path contains > non-ansi characters. So I hacked the classpath with addURLToAppClassLoader() > in sun.misc.Launcher. I at least could make a shared JRE installation, > started from a ansi path, find my JARs. Since one of my JARs does use native > code I then got stuck at the System.loadLibrary() call. Hacking the correct > path into the 'usr_paths' field into the ClassLoader did not help, because > the actual Windows API call LoadLibrary() seems to be ansi flavour instead > of wide char api. Would it be possible to make this two enhancements without > hurting the Java VM spec?: > > 1) fill the property java.class.path from the env variable CLASSPATH with a > call to GetEnvironmentVariableW instead of GetEnvironmentVariableA to enable > setting the classpath with unicode characters > > 2) fill the property java.library.path and issue the actual LoadLibrary with > appropriate wide char api > >>From a quick look at the VM source I found out, that most string operations > use the ANSI C string functions. > Maybe it would be possible to use UTF-8 encoding to transfer the path > strings throu the Java VM routines to the final Windows API calls, to avoid > large changes in the code base. > > Regards > Heiko Wagner > From sits at nuix.com Mon Feb 23 15:49:20 2009 From: sits at nuix.com (David Sitsky) Date: Tue, 24 Feb 2009 10:49:20 +1100 Subject: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application In-Reply-To: <4E0D3F42-021A-4D48-888E-594A5980D0E1@sun.com> References: <499CA7D9.9040903@nuix.com> <4E0D3F42-021A-4D48-888E-594A5980D0E1@sun.com> Message-ID: <49A33600.7000004@nuix.com> Hi Tom, Apologies for the delay in my reply. I have downloaded the Window kernel symbols so that the stacks from procexp are more reliable. I don't know where I can obtain the pdb files for jvm.dll. Are they available anywhere? Here is another example stack, using 1.6.0_12, jvm.dll is 11.02.0000.0001 Java Hotspot (TM) 64-Bit Server VM: ntoskrnl.exe!KiSwapContext+0x7f ntoskrnl.exe!KiSwapThread+0x2fa ntoskrnl.exe!KeWaitForSingleObject+0x2da ntoskrnl.exe!KiSuspendThread+0x29 ntoskrnl.exe!KiDeliverApc+0x420 ntoskrnl.exe!KiApcInterrupt+0x103 jvm.dll!JVM_FindSignal+0xe3f45 jvm.dll!JVM_FindSignal+0x14dcdd jvm.dll!JVM_FindSignal+0x14e17c jvm.dll!JVM_FindSignal+0x159b80 jvm.dll!JVM_FindSignal+0x12a5e4 jvm.dll!JVM_FindSignal+0x216e53 jvm.dll!JVM_FindSignal+0x219a38 jvm.dll!JVM_FindSignal+0x2188d4 jvm.dll!JVM_FindSignal+0x218d2a jvm.dll!JVM_FindSignal+0x219332 jvm.dll!JVM_FindSignal+0x11da99 msvcrt.dll!endthreadex+0x47 msvcrt.dll!endthreadex+0x100 kernel32.dll!BaseThreadInitThunk+0xd ntdll.dll!RtlUserThreadStart+0x1d I expect it is somehow related to GC, as the application is extremely memory intensive. However, I have found the 32-bit VM seems to cope, where as the 64-bit version seems to end up in these CPU loops in the VM thread. I can run jstack, but I have waited over 30 minutes for jconsole, and it has still not come up.. Any ideas? I am hoping now that I have specified the exact version of jvm.dll.. we can at least see what the offsets refer to? Cheers, David Tom Rodriguez wrote: > Have you tried using jconsole or -verbose:gc to watch your app? Maybe > it's running low on heap and spending too much time in GC. > > tom > > On Feb 18, 2009, at 4:29 PM, David Sitsky wrote: > >> I apologise in advance if this is a "breach of protocol". I have >> submitted a bug through the usual channels, but my experience with >> this approach unfortunately has usually been a dead-end. >> >> I have a very intensive data application (I/O + CPU + memory) on the >> Windows platform that reliably causes a 100% CPU lockup, but only for >> the x64 distribution (jdk 1.6.0_07, 1.6.0_10 and 1.6.0_12). When >> using the x32 distribution on the same machines it works fine. It is >> not machine-specific - I have seen this across 7 different machines, >> and it seems to occur after a few to several hours of processing. The >> JVM is still responsive, but extremely slow. >> >> Using process explorer, I was able to find the thread in the process >> consuming all the CPU. The stack traces from procexp have the same >> thread ID as the "VM Thread" from jstack. The stacks are usually >> something like the following: >> >> ntoskrnl.exe!ExpInterlockedFlushSList+0x126f >> ntoskrnl.exe!RtlNumberOfClearBits+0x5cc >> ntoskrnl.exe!ExpInterlockedFlushSList+0x134d >> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >> jvm.dll!AsyncGetCallTrace+0x3ac7f >> jvm.dll!JVM_FindSignal+0xe4533 >> jvm.dll!JVM_FindSignal+0x10fa2e >> jvm.dll!JVM_FindSignal+0xe3eef >> jvm.dll!JVM_FindSignal+0x14d61d >> jvm.dll!JVM_FindSignal+0x14dabc >> jvm.dll!JVM_FindSignal+0x1593e0 >> jvm.dll!JVM_FindSignal+0x12a374 >> jvm.dll!JVM_FindSignal+0x2167d3 >> jvm.dll!JVM_FindSignal+0x2193e8 >> jvm.dll!JVM_FindSignal+0x218274 >> jvm.dll!JVM_FindSignal+0x2186ca >> jvm.dll!JVM_FindSignal+0x218cd2 >> jvm.dll!JVM_FindSignal+0x11d7f9 >> msvcrt.dll!free_dbg+0x147 >> msvcrt.dll!beginthreadex+0x131 >> kernel32.dll!BaseThreadInitThunk+0xd >> ntdll.dll!RtlUserThreadStart+0x21 >> >> or >> >> ntoskrnl.exe!ExpInterlockedFlushSList+0x126f >> ntoskrnl.exe!KeWaitForMultipleObjects+0xcca >> ntoskrnl.exe!KeWaitForMutexObject+0x2da >> ntoskrnl.exe!_misaligned_access+0x35 >> ntoskrnl.exe!MmUnlockPages+0x1160 >> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >> jvm.dll!AsyncGetCallTrace+0x3ac7f >> jvm.dll!JVM_FindSignal+0xe3eef >> jvm.dll!JVM_FindSignal+0x14d61d >> jvm.dll!JVM_FindSignal+0x14dabc >> jvm.dll!JVM_FindSignal+0x1593e0 >> jvm.dll!JVM_FindSignal+0x12a374 >> jvm.dll!JVM_FindSignal+0x2167d3 >> jvm.dll!JVM_FindSignal+0x2193e8 >> jvm.dll!JVM_FindSignal+0x218274 >> jvm.dll!JVM_FindSignal+0x2186ca >> jvm.dll!JVM_FindSignal+0x218cd2 >> jvm.dll!JVM_FindSignal+0x11d7f9 >> msvcrt.dll!free_dbg+0x147 >> msvcrt.dll!beginthreadex+0x131 >> kernel32.dll!BaseThreadInitThunk+0xd >> ntdll.dll!RtlUserThreadStart+0x21 >> >> or (without AsyncGetCallTrace): >> >> ntoskrnl.exe!ExpInterlockedFlushSList+0x14a0 >> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >> jvm.dll!JVM_EnqueueOperation+0xb19f4 >> jvm.dll!JVM_FindSignal+0x1b7fcc >> jvm.dll!JVM_FindSignal+0x14dcca >> jvm.dll!JVM_FindSignal+0x14e17c >> jvm.dll!JVM_FindSignal+0x159b80 >> jvm.dll!JVM_FindSignal+0x12a5e4 >> jvm.dll!JVM_FindSignal+0x216e53 >> jvm.dll!JVM_FindSignal+0x219a38 >> jvm.dll!JVM_FindSignal+0x2188d4 >> jvm.dll!JVM_FindSignal+0x218d2a >> jvm.dll!JVM_FindSignal+0x219332 >> jvm.dll!JVM_FindSignal+0x11da99 >> msvcrt.dll!free_dbg+0x147 >> msvcrt.dll!beginthreadex+0x131 >> kernel32.dll!BaseThreadInitThunk+0xd >> ntdll.dll!RtlUserThreadStart+0x21 >> >> I am more than happy to run test/debug versions in order to assist in >> tracking this down. I wish I could say, here is a unit test, but its >> a very complex application with complex data processing. The only >> good news is it seems to be quite reproduceable on our systems. >> >> Apologies again in advance if this was an inappropriate place to post. >> But given the severity of this issue, I am hoping somebody here will >> be interested in it.. >> >> -- >> Cheers, >> David >> >> Nuix Pty Ltd >> Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 0699 >> Web: http://www.nuix.com Fax: +61 2 9212 6902 -- Cheers, David Nuix Pty Ltd Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 0699 Web: http://www.nuix.com Fax: +61 2 9212 6902 From Thomas.Rodriguez at Sun.COM Mon Feb 23 16:07:07 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 23 Feb 2009 16:07:07 -0800 Subject: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application In-Reply-To: <49A33600.7000004@nuix.com> References: <499CA7D9.9040903@nuix.com> <4E0D3F42-021A-4D48-888E-594A5980D0E1@sun.com> <49A33600.7000004@nuix.com> Message-ID: We keep pdb files from all our builds but don't normally distribute them. That's an address in MarkSweep::follow_stack and I believe that all the other address you were seeing were also in the GC. If jconsole doesn't work then try -verbose:gc which will just spew out the information directly. The fact that jconsole wouldn't start is pretty odd. Is your machine heavily loaded? You aren't doing something silly like specifying heap sizes that are greater than or too close to your actual amount of RAM? 64 bit apps usually require more heap for the same problem. tom On Feb 23, 2009, at 3:49 PM, David Sitsky wrote: > Hi Tom, > > Apologies for the delay in my reply. I have downloaded the Window > kernel symbols so that the stacks from procexp are more reliable. I > don't know where I can obtain the pdb files for jvm.dll. Are they > available anywhere? > > Here is another example stack, using 1.6.0_12, jvm.dll is > 11.02.0000.0001 Java Hotspot (TM) 64-Bit Server VM: > > ntoskrnl.exe!KiSwapContext+0x7f > ntoskrnl.exe!KiSwapThread+0x2fa > ntoskrnl.exe!KeWaitForSingleObject+0x2da > ntoskrnl.exe!KiSuspendThread+0x29 > ntoskrnl.exe!KiDeliverApc+0x420 > ntoskrnl.exe!KiApcInterrupt+0x103 > jvm.dll!JVM_FindSignal+0xe3f45 > jvm.dll!JVM_FindSignal+0x14dcdd > jvm.dll!JVM_FindSignal+0x14e17c > jvm.dll!JVM_FindSignal+0x159b80 > jvm.dll!JVM_FindSignal+0x12a5e4 > jvm.dll!JVM_FindSignal+0x216e53 > jvm.dll!JVM_FindSignal+0x219a38 > jvm.dll!JVM_FindSignal+0x2188d4 > jvm.dll!JVM_FindSignal+0x218d2a > jvm.dll!JVM_FindSignal+0x219332 > jvm.dll!JVM_FindSignal+0x11da99 > msvcrt.dll!endthreadex+0x47 > msvcrt.dll!endthreadex+0x100 > kernel32.dll!BaseThreadInitThunk+0xd > ntdll.dll!RtlUserThreadStart+0x1d > > I expect it is somehow related to GC, as the application is > extremely memory intensive. However, I have found the 32-bit VM > seems to cope, where as the 64-bit version seems to end up in these > CPU loops in the VM thread. > > I can run jstack, but I have waited over 30 minutes for jconsole, > and it has still not come up.. > > Any ideas? I am hoping now that I have specified the exact version > of jvm.dll.. we can at least see what the offsets refer to? > > Cheers, > David > > Tom Rodriguez wrote: >> Have you tried using jconsole or -verbose:gc to watch your app? >> Maybe it's running low on heap and spending too much time in GC. >> tom >> On Feb 18, 2009, at 4:29 PM, David Sitsky wrote: >>> I apologise in advance if this is a "breach of protocol". I have >>> submitted a bug through the usual channels, but my experience with >>> this approach unfortunately has usually been a dead-end. >>> >>> I have a very intensive data application (I/O + CPU + memory) on >>> the Windows platform that reliably causes a 100% CPU lockup, but >>> only for the x64 distribution (jdk 1.6.0_07, 1.6.0_10 and >>> 1.6.0_12). When using the x32 distribution on the same machines >>> it works fine. It is not machine-specific - I have seen this >>> across 7 different machines, and it seems to occur after a few to >>> several hours of processing. The JVM is still responsive, but >>> extremely slow. >>> >>> Using process explorer, I was able to find the thread in the >>> process consuming all the CPU. The stack traces from procexp have >>> the same thread ID as the "VM Thread" from jstack. The stacks are >>> usually something like the following: >>> >>> ntoskrnl.exe!ExpInterlockedFlushSList+0x126f >>> ntoskrnl.exe!RtlNumberOfClearBits+0x5cc >>> ntoskrnl.exe!ExpInterlockedFlushSList+0x134d >>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>> jvm.dll!AsyncGetCallTrace+0x3ac7f >>> jvm.dll!JVM_FindSignal+0xe4533 >>> jvm.dll!JVM_FindSignal+0x10fa2e >>> jvm.dll!JVM_FindSignal+0xe3eef >>> jvm.dll!JVM_FindSignal+0x14d61d >>> jvm.dll!JVM_FindSignal+0x14dabc >>> jvm.dll!JVM_FindSignal+0x1593e0 >>> jvm.dll!JVM_FindSignal+0x12a374 >>> jvm.dll!JVM_FindSignal+0x2167d3 >>> jvm.dll!JVM_FindSignal+0x2193e8 >>> jvm.dll!JVM_FindSignal+0x218274 >>> jvm.dll!JVM_FindSignal+0x2186ca >>> jvm.dll!JVM_FindSignal+0x218cd2 >>> jvm.dll!JVM_FindSignal+0x11d7f9 >>> msvcrt.dll!free_dbg+0x147 >>> msvcrt.dll!beginthreadex+0x131 >>> kernel32.dll!BaseThreadInitThunk+0xd >>> ntdll.dll!RtlUserThreadStart+0x21 >>> >>> or >>> >>> ntoskrnl.exe!ExpInterlockedFlushSList+0x126f >>> ntoskrnl.exe!KeWaitForMultipleObjects+0xcca >>> ntoskrnl.exe!KeWaitForMutexObject+0x2da >>> ntoskrnl.exe!_misaligned_access+0x35 >>> ntoskrnl.exe!MmUnlockPages+0x1160 >>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>> jvm.dll!AsyncGetCallTrace+0x3ac7f >>> jvm.dll!JVM_FindSignal+0xe3eef >>> jvm.dll!JVM_FindSignal+0x14d61d >>> jvm.dll!JVM_FindSignal+0x14dabc >>> jvm.dll!JVM_FindSignal+0x1593e0 >>> jvm.dll!JVM_FindSignal+0x12a374 >>> jvm.dll!JVM_FindSignal+0x2167d3 >>> jvm.dll!JVM_FindSignal+0x2193e8 >>> jvm.dll!JVM_FindSignal+0x218274 >>> jvm.dll!JVM_FindSignal+0x2186ca >>> jvm.dll!JVM_FindSignal+0x218cd2 >>> jvm.dll!JVM_FindSignal+0x11d7f9 >>> msvcrt.dll!free_dbg+0x147 >>> msvcrt.dll!beginthreadex+0x131 >>> kernel32.dll!BaseThreadInitThunk+0xd >>> ntdll.dll!RtlUserThreadStart+0x21 >>> >>> or (without AsyncGetCallTrace): >>> >>> ntoskrnl.exe!ExpInterlockedFlushSList+0x14a0 >>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>> jvm.dll!JVM_EnqueueOperation+0xb19f4 >>> jvm.dll!JVM_FindSignal+0x1b7fcc >>> jvm.dll!JVM_FindSignal+0x14dcca >>> jvm.dll!JVM_FindSignal+0x14e17c >>> jvm.dll!JVM_FindSignal+0x159b80 >>> jvm.dll!JVM_FindSignal+0x12a5e4 >>> jvm.dll!JVM_FindSignal+0x216e53 >>> jvm.dll!JVM_FindSignal+0x219a38 >>> jvm.dll!JVM_FindSignal+0x2188d4 >>> jvm.dll!JVM_FindSignal+0x218d2a >>> jvm.dll!JVM_FindSignal+0x219332 >>> jvm.dll!JVM_FindSignal+0x11da99 >>> msvcrt.dll!free_dbg+0x147 >>> msvcrt.dll!beginthreadex+0x131 >>> kernel32.dll!BaseThreadInitThunk+0xd >>> ntdll.dll!RtlUserThreadStart+0x21 >>> >>> I am more than happy to run test/debug versions in order to assist >>> in tracking this down. I wish I could say, here is a unit test, >>> but its a very complex application with complex data processing. >>> The only good news is it seems to be quite reproduceable on our >>> systems. >>> >>> Apologies again in advance if this was an inappropriate place to >>> post. But given the severity of this issue, I am hoping somebody >>> here will be interested in it.. >>> >>> -- >>> Cheers, >>> David >>> >>> Nuix Pty Ltd >>> Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 >>> 9280 0699 >>> Web: http://www.nuix.com Fax: +61 2 >>> 9212 6902 > > > -- > Cheers, > David > > Nuix Pty Ltd > Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 > 0699 > Web: http://www.nuix.com Fax: +61 2 9212 > 6902 From sits at nuix.com Mon Feb 23 16:54:34 2009 From: sits at nuix.com (David Sitsky) Date: Tue, 24 Feb 2009 11:54:34 +1100 Subject: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application In-Reply-To: References: <499CA7D9.9040903@nuix.com> <4E0D3F42-021A-4D48-888E-594A5980D0E1@sun.com> <49A33600.7000004@nuix.com> Message-ID: <49A3454A.4010507@nuix.com> The machine is heavily loaded. Its a quad-core machine with 8 gigs of memory, however each Java process has a 1g heap size set. I can see from the task manager I still have free/unused memory on my system, but of course that is not really relevant for the 4 individual JVMs which are running. When I say jconsole won't start - this is when I specify the specific process ID. I can still run other applications on the machine, albeit slowly. If I set a 1 gig heap size for a 32-bit process, what would be a very rough rule of thumb that I should set for a 64-bit process? Another 200 megs or so? I'll try it again with more memory, and also set the -verbose:gc flag. Cheers, David Tom Rodriguez wrote: > We keep pdb files from all our builds but don't normally distribute > them. That's an address in MarkSweep::follow_stack and I believe that > all the other address you were seeing were also in the GC. If jconsole > doesn't work then try -verbose:gc which will just spew out the > information directly. The fact that jconsole wouldn't start is pretty > odd. Is your machine heavily loaded? You aren't doing something silly > like specifying heap sizes that are greater than or too close to your > actual amount of RAM? 64 bit apps usually require more heap for the > same problem. > > tom > > On Feb 23, 2009, at 3:49 PM, David Sitsky wrote: > >> Hi Tom, >> >> Apologies for the delay in my reply. I have downloaded the Window >> kernel symbols so that the stacks from procexp are more reliable. I >> don't know where I can obtain the pdb files for jvm.dll. Are they >> available anywhere? >> >> Here is another example stack, using 1.6.0_12, jvm.dll is >> 11.02.0000.0001 Java Hotspot (TM) 64-Bit Server VM: >> >> ntoskrnl.exe!KiSwapContext+0x7f >> ntoskrnl.exe!KiSwapThread+0x2fa >> ntoskrnl.exe!KeWaitForSingleObject+0x2da >> ntoskrnl.exe!KiSuspendThread+0x29 >> ntoskrnl.exe!KiDeliverApc+0x420 >> ntoskrnl.exe!KiApcInterrupt+0x103 >> jvm.dll!JVM_FindSignal+0xe3f45 >> jvm.dll!JVM_FindSignal+0x14dcdd >> jvm.dll!JVM_FindSignal+0x14e17c >> jvm.dll!JVM_FindSignal+0x159b80 >> jvm.dll!JVM_FindSignal+0x12a5e4 >> jvm.dll!JVM_FindSignal+0x216e53 >> jvm.dll!JVM_FindSignal+0x219a38 >> jvm.dll!JVM_FindSignal+0x2188d4 >> jvm.dll!JVM_FindSignal+0x218d2a >> jvm.dll!JVM_FindSignal+0x219332 >> jvm.dll!JVM_FindSignal+0x11da99 >> msvcrt.dll!endthreadex+0x47 >> msvcrt.dll!endthreadex+0x100 >> kernel32.dll!BaseThreadInitThunk+0xd >> ntdll.dll!RtlUserThreadStart+0x1d >> >> I expect it is somehow related to GC, as the application is extremely >> memory intensive. However, I have found the 32-bit VM seems to cope, >> where as the 64-bit version seems to end up in these CPU loops in the >> VM thread. >> >> I can run jstack, but I have waited over 30 minutes for jconsole, and >> it has still not come up.. >> >> Any ideas? I am hoping now that I have specified the exact version of >> jvm.dll.. we can at least see what the offsets refer to? >> >> Cheers, >> David >> >> Tom Rodriguez wrote: >>> Have you tried using jconsole or -verbose:gc to watch your app? >>> Maybe it's running low on heap and spending too much time in GC. >>> tom >>> On Feb 18, 2009, at 4:29 PM, David Sitsky wrote: >>>> I apologise in advance if this is a "breach of protocol". I have >>>> submitted a bug through the usual channels, but my experience with >>>> this approach unfortunately has usually been a dead-end. >>>> >>>> I have a very intensive data application (I/O + CPU + memory) on the >>>> Windows platform that reliably causes a 100% CPU lockup, but only >>>> for the x64 distribution (jdk 1.6.0_07, 1.6.0_10 and 1.6.0_12). >>>> When using the x32 distribution on the same machines it works fine. >>>> It is not machine-specific - I have seen this across 7 different >>>> machines, and it seems to occur after a few to several hours of >>>> processing. The JVM is still responsive, but extremely slow. >>>> >>>> Using process explorer, I was able to find the thread in the process >>>> consuming all the CPU. The stack traces from procexp have the same >>>> thread ID as the "VM Thread" from jstack. The stacks are usually >>>> something like the following: >>>> >>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x126f >>>> ntoskrnl.exe!RtlNumberOfClearBits+0x5cc >>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x134d >>>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>>> jvm.dll!AsyncGetCallTrace+0x3ac7f >>>> jvm.dll!JVM_FindSignal+0xe4533 >>>> jvm.dll!JVM_FindSignal+0x10fa2e >>>> jvm.dll!JVM_FindSignal+0xe3eef >>>> jvm.dll!JVM_FindSignal+0x14d61d >>>> jvm.dll!JVM_FindSignal+0x14dabc >>>> jvm.dll!JVM_FindSignal+0x1593e0 >>>> jvm.dll!JVM_FindSignal+0x12a374 >>>> jvm.dll!JVM_FindSignal+0x2167d3 >>>> jvm.dll!JVM_FindSignal+0x2193e8 >>>> jvm.dll!JVM_FindSignal+0x218274 >>>> jvm.dll!JVM_FindSignal+0x2186ca >>>> jvm.dll!JVM_FindSignal+0x218cd2 >>>> jvm.dll!JVM_FindSignal+0x11d7f9 >>>> msvcrt.dll!free_dbg+0x147 >>>> msvcrt.dll!beginthreadex+0x131 >>>> kernel32.dll!BaseThreadInitThunk+0xd >>>> ntdll.dll!RtlUserThreadStart+0x21 >>>> >>>> or >>>> >>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x126f >>>> ntoskrnl.exe!KeWaitForMultipleObjects+0xcca >>>> ntoskrnl.exe!KeWaitForMutexObject+0x2da >>>> ntoskrnl.exe!_misaligned_access+0x35 >>>> ntoskrnl.exe!MmUnlockPages+0x1160 >>>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>>> jvm.dll!AsyncGetCallTrace+0x3ac7f >>>> jvm.dll!JVM_FindSignal+0xe3eef >>>> jvm.dll!JVM_FindSignal+0x14d61d >>>> jvm.dll!JVM_FindSignal+0x14dabc >>>> jvm.dll!JVM_FindSignal+0x1593e0 >>>> jvm.dll!JVM_FindSignal+0x12a374 >>>> jvm.dll!JVM_FindSignal+0x2167d3 >>>> jvm.dll!JVM_FindSignal+0x2193e8 >>>> jvm.dll!JVM_FindSignal+0x218274 >>>> jvm.dll!JVM_FindSignal+0x2186ca >>>> jvm.dll!JVM_FindSignal+0x218cd2 >>>> jvm.dll!JVM_FindSignal+0x11d7f9 >>>> msvcrt.dll!free_dbg+0x147 >>>> msvcrt.dll!beginthreadex+0x131 >>>> kernel32.dll!BaseThreadInitThunk+0xd >>>> ntdll.dll!RtlUserThreadStart+0x21 >>>> >>>> or (without AsyncGetCallTrace): >>>> >>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x14a0 >>>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>>> jvm.dll!JVM_EnqueueOperation+0xb19f4 >>>> jvm.dll!JVM_FindSignal+0x1b7fcc >>>> jvm.dll!JVM_FindSignal+0x14dcca >>>> jvm.dll!JVM_FindSignal+0x14e17c >>>> jvm.dll!JVM_FindSignal+0x159b80 >>>> jvm.dll!JVM_FindSignal+0x12a5e4 >>>> jvm.dll!JVM_FindSignal+0x216e53 >>>> jvm.dll!JVM_FindSignal+0x219a38 >>>> jvm.dll!JVM_FindSignal+0x2188d4 >>>> jvm.dll!JVM_FindSignal+0x218d2a >>>> jvm.dll!JVM_FindSignal+0x219332 >>>> jvm.dll!JVM_FindSignal+0x11da99 >>>> msvcrt.dll!free_dbg+0x147 >>>> msvcrt.dll!beginthreadex+0x131 >>>> kernel32.dll!BaseThreadInitThunk+0xd >>>> ntdll.dll!RtlUserThreadStart+0x21 >>>> >>>> I am more than happy to run test/debug versions in order to assist >>>> in tracking this down. I wish I could say, here is a unit test, but >>>> its a very complex application with complex data processing. The >>>> only good news is it seems to be quite reproduceable on our systems. >>>> >>>> Apologies again in advance if this was an inappropriate place to >>>> post. But given the severity of this issue, I am hoping somebody >>>> here will be interested in it.. >>>> >>>> -- >>>> Cheers, >>>> David -- Cheers, David Nuix Pty Ltd Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 0699 Web: http://www.nuix.com Fax: +61 2 9212 6902 From David.Holmes at Sun.COM Mon Feb 23 16:57:08 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Tue, 24 Feb 2009 10:57:08 +1000 Subject: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application In-Reply-To: <49A3454A.4010507@nuix.com> References: <499CA7D9.9040903@nuix.com> <4E0D3F42-021A-4D48-888E-594A5980D0E1@sun.com> <49A33600.7000004@nuix.com> <49A3454A.4010507@nuix.com> Message-ID: <49A345E4.3020209@sun.com> David, If GC is active and it's the VMThread that is having the problem then jconsole won't be able to attach to the VM until the current safepoint is over. David Holmes David Sitsky said the following on 02/24/09 10:54: > The machine is heavily loaded. Its a quad-core machine with 8 gigs of > memory, however each Java process has a 1g heap size set. I can see > from the task manager I still have free/unused memory on my system, but > of course that is not really relevant for the 4 individual JVMs which > are running. > > When I say jconsole won't start - this is when I specify the specific > process ID. I can still run other applications on the machine, albeit > slowly. > > If I set a 1 gig heap size for a 32-bit process, what would be a very > rough rule of thumb that I should set for a 64-bit process? Another 200 > megs or so? > > I'll try it again with more memory, and also set the -verbose:gc flag. > > Cheers, > David > > Tom Rodriguez wrote: >> We keep pdb files from all our builds but don't normally distribute >> them. That's an address in MarkSweep::follow_stack and I believe that >> all the other address you were seeing were also in the GC. If >> jconsole doesn't work then try -verbose:gc which will just spew out >> the information directly. The fact that jconsole wouldn't start is >> pretty odd. Is your machine heavily loaded? You aren't doing >> something silly like specifying heap sizes that are greater than or >> too close to your actual amount of RAM? 64 bit apps usually require >> more heap for the same problem. >> >> tom >> >> On Feb 23, 2009, at 3:49 PM, David Sitsky wrote: >> >>> Hi Tom, >>> >>> Apologies for the delay in my reply. I have downloaded the Window >>> kernel symbols so that the stacks from procexp are more reliable. I >>> don't know where I can obtain the pdb files for jvm.dll. Are they >>> available anywhere? >>> >>> Here is another example stack, using 1.6.0_12, jvm.dll is >>> 11.02.0000.0001 Java Hotspot (TM) 64-Bit Server VM: >>> >>> ntoskrnl.exe!KiSwapContext+0x7f >>> ntoskrnl.exe!KiSwapThread+0x2fa >>> ntoskrnl.exe!KeWaitForSingleObject+0x2da >>> ntoskrnl.exe!KiSuspendThread+0x29 >>> ntoskrnl.exe!KiDeliverApc+0x420 >>> ntoskrnl.exe!KiApcInterrupt+0x103 >>> jvm.dll!JVM_FindSignal+0xe3f45 >>> jvm.dll!JVM_FindSignal+0x14dcdd >>> jvm.dll!JVM_FindSignal+0x14e17c >>> jvm.dll!JVM_FindSignal+0x159b80 >>> jvm.dll!JVM_FindSignal+0x12a5e4 >>> jvm.dll!JVM_FindSignal+0x216e53 >>> jvm.dll!JVM_FindSignal+0x219a38 >>> jvm.dll!JVM_FindSignal+0x2188d4 >>> jvm.dll!JVM_FindSignal+0x218d2a >>> jvm.dll!JVM_FindSignal+0x219332 >>> jvm.dll!JVM_FindSignal+0x11da99 >>> msvcrt.dll!endthreadex+0x47 >>> msvcrt.dll!endthreadex+0x100 >>> kernel32.dll!BaseThreadInitThunk+0xd >>> ntdll.dll!RtlUserThreadStart+0x1d >>> >>> I expect it is somehow related to GC, as the application is extremely >>> memory intensive. However, I have found the 32-bit VM seems to cope, >>> where as the 64-bit version seems to end up in these CPU loops in the >>> VM thread. >>> >>> I can run jstack, but I have waited over 30 minutes for jconsole, and >>> it has still not come up.. >>> >>> Any ideas? I am hoping now that I have specified the exact version >>> of jvm.dll.. we can at least see what the offsets refer to? >>> >>> Cheers, >>> David >>> >>> Tom Rodriguez wrote: >>>> Have you tried using jconsole or -verbose:gc to watch your app? >>>> Maybe it's running low on heap and spending too much time in GC. >>>> tom >>>> On Feb 18, 2009, at 4:29 PM, David Sitsky wrote: >>>>> I apologise in advance if this is a "breach of protocol". I have >>>>> submitted a bug through the usual channels, but my experience with >>>>> this approach unfortunately has usually been a dead-end. >>>>> >>>>> I have a very intensive data application (I/O + CPU + memory) on >>>>> the Windows platform that reliably causes a 100% CPU lockup, but >>>>> only for the x64 distribution (jdk 1.6.0_07, 1.6.0_10 and >>>>> 1.6.0_12). When using the x32 distribution on the same machines it >>>>> works fine. It is not machine-specific - I have seen this across 7 >>>>> different machines, and it seems to occur after a few to several >>>>> hours of processing. The JVM is still responsive, but extremely slow. >>>>> >>>>> Using process explorer, I was able to find the thread in the >>>>> process consuming all the CPU. The stack traces from procexp have >>>>> the same thread ID as the "VM Thread" from jstack. The stacks are >>>>> usually something like the following: >>>>> >>>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x126f >>>>> ntoskrnl.exe!RtlNumberOfClearBits+0x5cc >>>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x134d >>>>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>>>> jvm.dll!AsyncGetCallTrace+0x3ac7f >>>>> jvm.dll!JVM_FindSignal+0xe4533 >>>>> jvm.dll!JVM_FindSignal+0x10fa2e >>>>> jvm.dll!JVM_FindSignal+0xe3eef >>>>> jvm.dll!JVM_FindSignal+0x14d61d >>>>> jvm.dll!JVM_FindSignal+0x14dabc >>>>> jvm.dll!JVM_FindSignal+0x1593e0 >>>>> jvm.dll!JVM_FindSignal+0x12a374 >>>>> jvm.dll!JVM_FindSignal+0x2167d3 >>>>> jvm.dll!JVM_FindSignal+0x2193e8 >>>>> jvm.dll!JVM_FindSignal+0x218274 >>>>> jvm.dll!JVM_FindSignal+0x2186ca >>>>> jvm.dll!JVM_FindSignal+0x218cd2 >>>>> jvm.dll!JVM_FindSignal+0x11d7f9 >>>>> msvcrt.dll!free_dbg+0x147 >>>>> msvcrt.dll!beginthreadex+0x131 >>>>> kernel32.dll!BaseThreadInitThunk+0xd >>>>> ntdll.dll!RtlUserThreadStart+0x21 >>>>> >>>>> or >>>>> >>>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x126f >>>>> ntoskrnl.exe!KeWaitForMultipleObjects+0xcca >>>>> ntoskrnl.exe!KeWaitForMutexObject+0x2da >>>>> ntoskrnl.exe!_misaligned_access+0x35 >>>>> ntoskrnl.exe!MmUnlockPages+0x1160 >>>>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>>>> jvm.dll!AsyncGetCallTrace+0x3ac7f >>>>> jvm.dll!JVM_FindSignal+0xe3eef >>>>> jvm.dll!JVM_FindSignal+0x14d61d >>>>> jvm.dll!JVM_FindSignal+0x14dabc >>>>> jvm.dll!JVM_FindSignal+0x1593e0 >>>>> jvm.dll!JVM_FindSignal+0x12a374 >>>>> jvm.dll!JVM_FindSignal+0x2167d3 >>>>> jvm.dll!JVM_FindSignal+0x2193e8 >>>>> jvm.dll!JVM_FindSignal+0x218274 >>>>> jvm.dll!JVM_FindSignal+0x2186ca >>>>> jvm.dll!JVM_FindSignal+0x218cd2 >>>>> jvm.dll!JVM_FindSignal+0x11d7f9 >>>>> msvcrt.dll!free_dbg+0x147 >>>>> msvcrt.dll!beginthreadex+0x131 >>>>> kernel32.dll!BaseThreadInitThunk+0xd >>>>> ntdll.dll!RtlUserThreadStart+0x21 >>>>> >>>>> or (without AsyncGetCallTrace): >>>>> >>>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x14a0 >>>>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>>>> jvm.dll!JVM_EnqueueOperation+0xb19f4 >>>>> jvm.dll!JVM_FindSignal+0x1b7fcc >>>>> jvm.dll!JVM_FindSignal+0x14dcca >>>>> jvm.dll!JVM_FindSignal+0x14e17c >>>>> jvm.dll!JVM_FindSignal+0x159b80 >>>>> jvm.dll!JVM_FindSignal+0x12a5e4 >>>>> jvm.dll!JVM_FindSignal+0x216e53 >>>>> jvm.dll!JVM_FindSignal+0x219a38 >>>>> jvm.dll!JVM_FindSignal+0x2188d4 >>>>> jvm.dll!JVM_FindSignal+0x218d2a >>>>> jvm.dll!JVM_FindSignal+0x219332 >>>>> jvm.dll!JVM_FindSignal+0x11da99 >>>>> msvcrt.dll!free_dbg+0x147 >>>>> msvcrt.dll!beginthreadex+0x131 >>>>> kernel32.dll!BaseThreadInitThunk+0xd >>>>> ntdll.dll!RtlUserThreadStart+0x21 >>>>> >>>>> I am more than happy to run test/debug versions in order to assist >>>>> in tracking this down. I wish I could say, here is a unit test, >>>>> but its a very complex application with complex data processing. >>>>> The only good news is it seems to be quite reproduceable on our >>>>> systems. >>>>> >>>>> Apologies again in advance if this was an inappropriate place to >>>>> post. But given the severity of this issue, I am hoping somebody >>>>> here will be interested in it.. >>>>> >>>>> -- >>>>> Cheers, >>>>> David > > From sits at nuix.com Mon Feb 23 17:09:31 2009 From: sits at nuix.com (David Sitsky) Date: Tue, 24 Feb 2009 12:09:31 +1100 Subject: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application In-Reply-To: <49A345E4.3020209@sun.com> References: <499CA7D9.9040903@nuix.com> <4E0D3F42-021A-4D48-888E-594A5980D0E1@sun.com> <49A33600.7000004@nuix.com> <49A3454A.4010507@nuix.com> <49A345E4.3020209@sun.com> Message-ID: <49A348CB.1040804@nuix.com> Hi David, What is interesting is in this situation where the VM is really not making any progress with collecting memory, I thought an OutOfMemoryException would be thrown, but I am not seeing that, at least on the 64-bit VM. My application just appears to be stalled.. Cheers, David David Holmes - Sun Microsystems wrote: > David, > > If GC is active and it's the VMThread that is having the problem then > jconsole won't be able to attach to the VM until the current safepoint > is over. > > David Holmes > > David Sitsky said the following on 02/24/09 10:54: >> The machine is heavily loaded. Its a quad-core machine with 8 gigs of >> memory, however each Java process has a 1g heap size set. I can see >> from the task manager I still have free/unused memory on my system, >> but of course that is not really relevant for the 4 individual JVMs >> which are running. >> >> When I say jconsole won't start - this is when I specify the specific >> process ID. I can still run other applications on the machine, albeit >> slowly. >> >> If I set a 1 gig heap size for a 32-bit process, what would be a very >> rough rule of thumb that I should set for a 64-bit process? Another >> 200 megs or so? >> >> I'll try it again with more memory, and also set the -verbose:gc flag. >> >> Cheers, >> David >> >> Tom Rodriguez wrote: >>> We keep pdb files from all our builds but don't normally distribute >>> them. That's an address in MarkSweep::follow_stack and I believe >>> that all the other address you were seeing were also in the GC. If >>> jconsole doesn't work then try -verbose:gc which will just spew out >>> the information directly. The fact that jconsole wouldn't start is >>> pretty odd. Is your machine heavily loaded? You aren't doing >>> something silly like specifying heap sizes that are greater than or >>> too close to your actual amount of RAM? 64 bit apps usually require >>> more heap for the same problem. >>> >>> tom >>> >>> On Feb 23, 2009, at 3:49 PM, David Sitsky wrote: >>> >>>> Hi Tom, >>>> >>>> Apologies for the delay in my reply. I have downloaded the Window >>>> kernel symbols so that the stacks from procexp are more reliable. I >>>> don't know where I can obtain the pdb files for jvm.dll. Are they >>>> available anywhere? >>>> >>>> Here is another example stack, using 1.6.0_12, jvm.dll is >>>> 11.02.0000.0001 Java Hotspot (TM) 64-Bit Server VM: >>>> >>>> ntoskrnl.exe!KiSwapContext+0x7f >>>> ntoskrnl.exe!KiSwapThread+0x2fa >>>> ntoskrnl.exe!KeWaitForSingleObject+0x2da >>>> ntoskrnl.exe!KiSuspendThread+0x29 >>>> ntoskrnl.exe!KiDeliverApc+0x420 >>>> ntoskrnl.exe!KiApcInterrupt+0x103 >>>> jvm.dll!JVM_FindSignal+0xe3f45 >>>> jvm.dll!JVM_FindSignal+0x14dcdd >>>> jvm.dll!JVM_FindSignal+0x14e17c >>>> jvm.dll!JVM_FindSignal+0x159b80 >>>> jvm.dll!JVM_FindSignal+0x12a5e4 >>>> jvm.dll!JVM_FindSignal+0x216e53 >>>> jvm.dll!JVM_FindSignal+0x219a38 >>>> jvm.dll!JVM_FindSignal+0x2188d4 >>>> jvm.dll!JVM_FindSignal+0x218d2a >>>> jvm.dll!JVM_FindSignal+0x219332 >>>> jvm.dll!JVM_FindSignal+0x11da99 >>>> msvcrt.dll!endthreadex+0x47 >>>> msvcrt.dll!endthreadex+0x100 >>>> kernel32.dll!BaseThreadInitThunk+0xd >>>> ntdll.dll!RtlUserThreadStart+0x1d >>>> >>>> I expect it is somehow related to GC, as the application is >>>> extremely memory intensive. However, I have found the 32-bit VM >>>> seems to cope, where as the 64-bit version seems to end up in these >>>> CPU loops in the VM thread. >>>> >>>> I can run jstack, but I have waited over 30 minutes for jconsole, >>>> and it has still not come up.. >>>> >>>> Any ideas? I am hoping now that I have specified the exact version >>>> of jvm.dll.. we can at least see what the offsets refer to? >>>> >>>> Cheers, >>>> David >>>> >>>> Tom Rodriguez wrote: >>>>> Have you tried using jconsole or -verbose:gc to watch your app? >>>>> Maybe it's running low on heap and spending too much time in GC. >>>>> tom >>>>> On Feb 18, 2009, at 4:29 PM, David Sitsky wrote: >>>>>> I apologise in advance if this is a "breach of protocol". I have >>>>>> submitted a bug through the usual channels, but my experience with >>>>>> this approach unfortunately has usually been a dead-end. >>>>>> >>>>>> I have a very intensive data application (I/O + CPU + memory) on >>>>>> the Windows platform that reliably causes a 100% CPU lockup, but >>>>>> only for the x64 distribution (jdk 1.6.0_07, 1.6.0_10 and >>>>>> 1.6.0_12). When using the x32 distribution on the same machines >>>>>> it works fine. It is not machine-specific - I have seen this >>>>>> across 7 different machines, and it seems to occur after a few to >>>>>> several hours of processing. The JVM is still responsive, but >>>>>> extremely slow. >>>>>> >>>>>> Using process explorer, I was able to find the thread in the >>>>>> process consuming all the CPU. The stack traces from procexp have >>>>>> the same thread ID as the "VM Thread" from jstack. The stacks are >>>>>> usually something like the following: >>>>>> >>>>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x126f >>>>>> ntoskrnl.exe!RtlNumberOfClearBits+0x5cc >>>>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x134d >>>>>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>>>>> jvm.dll!AsyncGetCallTrace+0x3ac7f >>>>>> jvm.dll!JVM_FindSignal+0xe4533 >>>>>> jvm.dll!JVM_FindSignal+0x10fa2e >>>>>> jvm.dll!JVM_FindSignal+0xe3eef >>>>>> jvm.dll!JVM_FindSignal+0x14d61d >>>>>> jvm.dll!JVM_FindSignal+0x14dabc >>>>>> jvm.dll!JVM_FindSignal+0x1593e0 >>>>>> jvm.dll!JVM_FindSignal+0x12a374 >>>>>> jvm.dll!JVM_FindSignal+0x2167d3 >>>>>> jvm.dll!JVM_FindSignal+0x2193e8 >>>>>> jvm.dll!JVM_FindSignal+0x218274 >>>>>> jvm.dll!JVM_FindSignal+0x2186ca >>>>>> jvm.dll!JVM_FindSignal+0x218cd2 >>>>>> jvm.dll!JVM_FindSignal+0x11d7f9 >>>>>> msvcrt.dll!free_dbg+0x147 >>>>>> msvcrt.dll!beginthreadex+0x131 >>>>>> kernel32.dll!BaseThreadInitThunk+0xd >>>>>> ntdll.dll!RtlUserThreadStart+0x21 >>>>>> >>>>>> or >>>>>> >>>>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x126f >>>>>> ntoskrnl.exe!KeWaitForMultipleObjects+0xcca >>>>>> ntoskrnl.exe!KeWaitForMutexObject+0x2da >>>>>> ntoskrnl.exe!_misaligned_access+0x35 >>>>>> ntoskrnl.exe!MmUnlockPages+0x1160 >>>>>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>>>>> jvm.dll!AsyncGetCallTrace+0x3ac7f >>>>>> jvm.dll!JVM_FindSignal+0xe3eef >>>>>> jvm.dll!JVM_FindSignal+0x14d61d >>>>>> jvm.dll!JVM_FindSignal+0x14dabc >>>>>> jvm.dll!JVM_FindSignal+0x1593e0 >>>>>> jvm.dll!JVM_FindSignal+0x12a374 >>>>>> jvm.dll!JVM_FindSignal+0x2167d3 >>>>>> jvm.dll!JVM_FindSignal+0x2193e8 >>>>>> jvm.dll!JVM_FindSignal+0x218274 >>>>>> jvm.dll!JVM_FindSignal+0x2186ca >>>>>> jvm.dll!JVM_FindSignal+0x218cd2 >>>>>> jvm.dll!JVM_FindSignal+0x11d7f9 >>>>>> msvcrt.dll!free_dbg+0x147 >>>>>> msvcrt.dll!beginthreadex+0x131 >>>>>> kernel32.dll!BaseThreadInitThunk+0xd >>>>>> ntdll.dll!RtlUserThreadStart+0x21 >>>>>> >>>>>> or (without AsyncGetCallTrace): >>>>>> >>>>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x14a0 >>>>>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>>>>> jvm.dll!JVM_EnqueueOperation+0xb19f4 >>>>>> jvm.dll!JVM_FindSignal+0x1b7fcc >>>>>> jvm.dll!JVM_FindSignal+0x14dcca >>>>>> jvm.dll!JVM_FindSignal+0x14e17c >>>>>> jvm.dll!JVM_FindSignal+0x159b80 >>>>>> jvm.dll!JVM_FindSignal+0x12a5e4 >>>>>> jvm.dll!JVM_FindSignal+0x216e53 >>>>>> jvm.dll!JVM_FindSignal+0x219a38 >>>>>> jvm.dll!JVM_FindSignal+0x2188d4 >>>>>> jvm.dll!JVM_FindSignal+0x218d2a >>>>>> jvm.dll!JVM_FindSignal+0x219332 >>>>>> jvm.dll!JVM_FindSignal+0x11da99 >>>>>> msvcrt.dll!free_dbg+0x147 >>>>>> msvcrt.dll!beginthreadex+0x131 >>>>>> kernel32.dll!BaseThreadInitThunk+0xd >>>>>> ntdll.dll!RtlUserThreadStart+0x21 >>>>>> >>>>>> I am more than happy to run test/debug versions in order to assist >>>>>> in tracking this down. I wish I could say, here is a unit test, >>>>>> but its a very complex application with complex data processing. >>>>>> The only good news is it seems to be quite reproduceable on our >>>>>> systems. >>>>>> >>>>>> Apologies again in advance if this was an inappropriate place to >>>>>> post. But given the severity of this issue, I am hoping somebody >>>>>> here will be interested in it.. >>>>>> >>>>>> -- >>>>>> Cheers, >>>>>> David >> >> -- Cheers, David Nuix Pty Ltd Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 0699 Web: http://www.nuix.com Fax: +61 2 9212 6902 From Thomas.Rodriguez at Sun.COM Mon Feb 23 17:15:59 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 23 Feb 2009 17:15:59 -0800 Subject: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application In-Reply-To: <49A348CB.1040804@nuix.com> References: <499CA7D9.9040903@nuix.com> <4E0D3F42-021A-4D48-888E-594A5980D0E1@sun.com> <49A33600.7000004@nuix.com> <49A3454A.4010507@nuix.com> <49A345E4.3020209@sun.com> <49A348CB.1040804@nuix.com> Message-ID: There is a GCTimeLimit which should give up if we're spending too much time in GC but maybe you're on the edge or it's not enabled for your collector. tom On Feb 23, 2009, at 5:09 PM, David Sitsky wrote: > Hi David, > > What is interesting is in this situation where the VM is really not > making any progress with collecting memory, I thought an > OutOfMemoryException would be thrown, but I am not seeing that, at > least on the 64-bit VM. > > My application just appears to be stalled.. > > Cheers, > David > > David Holmes - Sun Microsystems wrote: >> David, >> If GC is active and it's the VMThread that is having the problem >> then jconsole won't be able to attach to the VM until the current >> safepoint is over. >> David Holmes >> David Sitsky said the following on 02/24/09 10:54: >>> The machine is heavily loaded. Its a quad-core machine with 8 >>> gigs of memory, however each Java process has a 1g heap size set. >>> I can see from the task manager I still have free/unused memory on >>> my system, but of course that is not really relevant for the 4 >>> individual JVMs which are running. >>> >>> When I say jconsole won't start - this is when I specify the >>> specific process ID. I can still run other applications on the >>> machine, albeit slowly. >>> >>> If I set a 1 gig heap size for a 32-bit process, what would be a >>> very rough rule of thumb that I should set for a 64-bit process? >>> Another 200 megs or so? >>> >>> I'll try it again with more memory, and also set the -verbose:gc >>> flag. >>> >>> Cheers, >>> David >>> >>> Tom Rodriguez wrote: >>>> We keep pdb files from all our builds but don't normally >>>> distribute them. That's an address in MarkSweep::follow_stack >>>> and I believe that all the other address you were seeing were >>>> also in the GC. If jconsole doesn't work then try -verbose:gc >>>> which will just spew out the information directly. The fact that >>>> jconsole wouldn't start is pretty odd. Is your machine heavily >>>> loaded? You aren't doing something silly like specifying heap >>>> sizes that are greater than or too close to your actual amount of >>>> RAM? 64 bit apps usually require more heap for the same problem. >>>> >>>> tom >>>> >>>> On Feb 23, 2009, at 3:49 PM, David Sitsky wrote: >>>> >>>>> Hi Tom, >>>>> >>>>> Apologies for the delay in my reply. I have downloaded the >>>>> Window kernel symbols so that the stacks from procexp are more >>>>> reliable. I don't know where I can obtain the pdb files for >>>>> jvm.dll. Are they available anywhere? >>>>> >>>>> Here is another example stack, using 1.6.0_12, jvm.dll is >>>>> 11.02.0000.0001 Java Hotspot (TM) 64-Bit Server VM: >>>>> >>>>> ntoskrnl.exe!KiSwapContext+0x7f >>>>> ntoskrnl.exe!KiSwapThread+0x2fa >>>>> ntoskrnl.exe!KeWaitForSingleObject+0x2da >>>>> ntoskrnl.exe!KiSuspendThread+0x29 >>>>> ntoskrnl.exe!KiDeliverApc+0x420 >>>>> ntoskrnl.exe!KiApcInterrupt+0x103 >>>>> jvm.dll!JVM_FindSignal+0xe3f45 >>>>> jvm.dll!JVM_FindSignal+0x14dcdd >>>>> jvm.dll!JVM_FindSignal+0x14e17c >>>>> jvm.dll!JVM_FindSignal+0x159b80 >>>>> jvm.dll!JVM_FindSignal+0x12a5e4 >>>>> jvm.dll!JVM_FindSignal+0x216e53 >>>>> jvm.dll!JVM_FindSignal+0x219a38 >>>>> jvm.dll!JVM_FindSignal+0x2188d4 >>>>> jvm.dll!JVM_FindSignal+0x218d2a >>>>> jvm.dll!JVM_FindSignal+0x219332 >>>>> jvm.dll!JVM_FindSignal+0x11da99 >>>>> msvcrt.dll!endthreadex+0x47 >>>>> msvcrt.dll!endthreadex+0x100 >>>>> kernel32.dll!BaseThreadInitThunk+0xd >>>>> ntdll.dll!RtlUserThreadStart+0x1d >>>>> >>>>> I expect it is somehow related to GC, as the application is >>>>> extremely memory intensive. However, I have found the 32-bit VM >>>>> seems to cope, where as the 64-bit version seems to end up in >>>>> these CPU loops in the VM thread. >>>>> >>>>> I can run jstack, but I have waited over 30 minutes for >>>>> jconsole, and it has still not come up.. >>>>> >>>>> Any ideas? I am hoping now that I have specified the exact >>>>> version of jvm.dll.. we can at least see what the offsets refer >>>>> to? >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>> Tom Rodriguez wrote: >>>>>> Have you tried using jconsole or -verbose:gc to watch your >>>>>> app? Maybe it's running low on heap and spending too much time >>>>>> in GC. >>>>>> tom >>>>>> On Feb 18, 2009, at 4:29 PM, David Sitsky wrote: >>>>>>> I apologise in advance if this is a "breach of protocol". I >>>>>>> have submitted a bug through the usual channels, but my >>>>>>> experience with this approach unfortunately has usually been a >>>>>>> dead-end. >>>>>>> >>>>>>> I have a very intensive data application (I/O + CPU + memory) >>>>>>> on the Windows platform that reliably causes a 100% CPU >>>>>>> lockup, but only for the x64 distribution (jdk 1.6.0_07, >>>>>>> 1.6.0_10 and 1.6.0_12). When using the x32 distribution on >>>>>>> the same machines it works fine. It is not machine-specific - >>>>>>> I have seen this across 7 different machines, and it seems to >>>>>>> occur after a few to several hours of processing. The JVM is >>>>>>> still responsive, but extremely slow. >>>>>>> >>>>>>> Using process explorer, I was able to find the thread in the >>>>>>> process consuming all the CPU. The stack traces from procexp >>>>>>> have the same thread ID as the "VM Thread" from jstack. The >>>>>>> stacks are usually something like the following: >>>>>>> >>>>>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x126f >>>>>>> ntoskrnl.exe!RtlNumberOfClearBits+0x5cc >>>>>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x134d >>>>>>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>>>>>> jvm.dll!AsyncGetCallTrace+0x3ac7f >>>>>>> jvm.dll!JVM_FindSignal+0xe4533 >>>>>>> jvm.dll!JVM_FindSignal+0x10fa2e >>>>>>> jvm.dll!JVM_FindSignal+0xe3eef >>>>>>> jvm.dll!JVM_FindSignal+0x14d61d >>>>>>> jvm.dll!JVM_FindSignal+0x14dabc >>>>>>> jvm.dll!JVM_FindSignal+0x1593e0 >>>>>>> jvm.dll!JVM_FindSignal+0x12a374 >>>>>>> jvm.dll!JVM_FindSignal+0x2167d3 >>>>>>> jvm.dll!JVM_FindSignal+0x2193e8 >>>>>>> jvm.dll!JVM_FindSignal+0x218274 >>>>>>> jvm.dll!JVM_FindSignal+0x2186ca >>>>>>> jvm.dll!JVM_FindSignal+0x218cd2 >>>>>>> jvm.dll!JVM_FindSignal+0x11d7f9 >>>>>>> msvcrt.dll!free_dbg+0x147 >>>>>>> msvcrt.dll!beginthreadex+0x131 >>>>>>> kernel32.dll!BaseThreadInitThunk+0xd >>>>>>> ntdll.dll!RtlUserThreadStart+0x21 >>>>>>> >>>>>>> or >>>>>>> >>>>>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x126f >>>>>>> ntoskrnl.exe!KeWaitForMultipleObjects+0xcca >>>>>>> ntoskrnl.exe!KeWaitForMutexObject+0x2da >>>>>>> ntoskrnl.exe!_misaligned_access+0x35 >>>>>>> ntoskrnl.exe!MmUnlockPages+0x1160 >>>>>>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>>>>>> jvm.dll!AsyncGetCallTrace+0x3ac7f >>>>>>> jvm.dll!JVM_FindSignal+0xe3eef >>>>>>> jvm.dll!JVM_FindSignal+0x14d61d >>>>>>> jvm.dll!JVM_FindSignal+0x14dabc >>>>>>> jvm.dll!JVM_FindSignal+0x1593e0 >>>>>>> jvm.dll!JVM_FindSignal+0x12a374 >>>>>>> jvm.dll!JVM_FindSignal+0x2167d3 >>>>>>> jvm.dll!JVM_FindSignal+0x2193e8 >>>>>>> jvm.dll!JVM_FindSignal+0x218274 >>>>>>> jvm.dll!JVM_FindSignal+0x2186ca >>>>>>> jvm.dll!JVM_FindSignal+0x218cd2 >>>>>>> jvm.dll!JVM_FindSignal+0x11d7f9 >>>>>>> msvcrt.dll!free_dbg+0x147 >>>>>>> msvcrt.dll!beginthreadex+0x131 >>>>>>> kernel32.dll!BaseThreadInitThunk+0xd >>>>>>> ntdll.dll!RtlUserThreadStart+0x21 >>>>>>> >>>>>>> or (without AsyncGetCallTrace): >>>>>>> >>>>>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x14a0 >>>>>>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>>>>>> jvm.dll!JVM_EnqueueOperation+0xb19f4 >>>>>>> jvm.dll!JVM_FindSignal+0x1b7fcc >>>>>>> jvm.dll!JVM_FindSignal+0x14dcca >>>>>>> jvm.dll!JVM_FindSignal+0x14e17c >>>>>>> jvm.dll!JVM_FindSignal+0x159b80 >>>>>>> jvm.dll!JVM_FindSignal+0x12a5e4 >>>>>>> jvm.dll!JVM_FindSignal+0x216e53 >>>>>>> jvm.dll!JVM_FindSignal+0x219a38 >>>>>>> jvm.dll!JVM_FindSignal+0x2188d4 >>>>>>> jvm.dll!JVM_FindSignal+0x218d2a >>>>>>> jvm.dll!JVM_FindSignal+0x219332 >>>>>>> jvm.dll!JVM_FindSignal+0x11da99 >>>>>>> msvcrt.dll!free_dbg+0x147 >>>>>>> msvcrt.dll!beginthreadex+0x131 >>>>>>> kernel32.dll!BaseThreadInitThunk+0xd >>>>>>> ntdll.dll!RtlUserThreadStart+0x21 >>>>>>> >>>>>>> I am more than happy to run test/debug versions in order to >>>>>>> assist in tracking this down. I wish I could say, here is a >>>>>>> unit test, but its a very complex application with complex >>>>>>> data processing. The only good news is it seems to be quite >>>>>>> reproduceable on our systems. >>>>>>> >>>>>>> Apologies again in advance if this was an inappropriate place >>>>>>> to post. But given the severity of this issue, I am hoping >>>>>>> somebody here will be interested in it.. >>>>>>> >>>>>>> -- >>>>>>> Cheers, >>>>>>> David >>> >>> > > > -- > Cheers, > David > > Nuix Pty Ltd > Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 > 0699 > Web: http://www.nuix.com Fax: +61 2 9212 > 6902 From David.Holmes at Sun.COM Mon Feb 23 17:16:24 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Tue, 24 Feb 2009 11:16:24 +1000 Subject: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application In-Reply-To: <49A348CB.1040804@nuix.com> References: <499CA7D9.9040903@nuix.com> <4E0D3F42-021A-4D48-888E-594A5980D0E1@sun.com> <49A33600.7000004@nuix.com> <49A3454A.4010507@nuix.com> <49A345E4.3020209@sun.com> <49A348CB.1040804@nuix.com> Message-ID: <49A34A68.5000108@sun.com> There have been (perhaps still are) GC "bugs" where the collector thinks it's reclaiming memory - and so no OOME is thrown - but no forward progress is really made (or is made extremely slowly). But one of the GC folk would have to chime in with the details of which collector under what circumstances. And the first thing they will need are detailed GC logs. Cheers, David Holmes David Sitsky said the following on 02/24/09 11:09: > Hi David, > > What is interesting is in this situation where the VM is really not > making any progress with collecting memory, I thought an > OutOfMemoryException would be thrown, but I am not seeing that, at least > on the 64-bit VM. > > My application just appears to be stalled.. > > Cheers, > David > > David Holmes - Sun Microsystems wrote: >> David, >> >> If GC is active and it's the VMThread that is having the problem then >> jconsole won't be able to attach to the VM until the current safepoint >> is over. >> >> David Holmes >> >> David Sitsky said the following on 02/24/09 10:54: >>> The machine is heavily loaded. Its a quad-core machine with 8 gigs >>> of memory, however each Java process has a 1g heap size set. I can >>> see from the task manager I still have free/unused memory on my >>> system, but of course that is not really relevant for the 4 >>> individual JVMs which are running. >>> >>> When I say jconsole won't start - this is when I specify the specific >>> process ID. I can still run other applications on the machine, >>> albeit slowly. >>> >>> If I set a 1 gig heap size for a 32-bit process, what would be a very >>> rough rule of thumb that I should set for a 64-bit process? Another >>> 200 megs or so? >>> >>> I'll try it again with more memory, and also set the -verbose:gc flag. >>> >>> Cheers, >>> David >>> >>> Tom Rodriguez wrote: >>>> We keep pdb files from all our builds but don't normally distribute >>>> them. That's an address in MarkSweep::follow_stack and I believe >>>> that all the other address you were seeing were also in the GC. If >>>> jconsole doesn't work then try -verbose:gc which will just spew out >>>> the information directly. The fact that jconsole wouldn't start is >>>> pretty odd. Is your machine heavily loaded? You aren't doing >>>> something silly like specifying heap sizes that are greater than or >>>> too close to your actual amount of RAM? 64 bit apps usually require >>>> more heap for the same problem. >>>> >>>> tom >>>> >>>> On Feb 23, 2009, at 3:49 PM, David Sitsky wrote: >>>> >>>>> Hi Tom, >>>>> >>>>> Apologies for the delay in my reply. I have downloaded the Window >>>>> kernel symbols so that the stacks from procexp are more reliable. >>>>> I don't know where I can obtain the pdb files for jvm.dll. Are >>>>> they available anywhere? >>>>> >>>>> Here is another example stack, using 1.6.0_12, jvm.dll is >>>>> 11.02.0000.0001 Java Hotspot (TM) 64-Bit Server VM: >>>>> >>>>> ntoskrnl.exe!KiSwapContext+0x7f >>>>> ntoskrnl.exe!KiSwapThread+0x2fa >>>>> ntoskrnl.exe!KeWaitForSingleObject+0x2da >>>>> ntoskrnl.exe!KiSuspendThread+0x29 >>>>> ntoskrnl.exe!KiDeliverApc+0x420 >>>>> ntoskrnl.exe!KiApcInterrupt+0x103 >>>>> jvm.dll!JVM_FindSignal+0xe3f45 >>>>> jvm.dll!JVM_FindSignal+0x14dcdd >>>>> jvm.dll!JVM_FindSignal+0x14e17c >>>>> jvm.dll!JVM_FindSignal+0x159b80 >>>>> jvm.dll!JVM_FindSignal+0x12a5e4 >>>>> jvm.dll!JVM_FindSignal+0x216e53 >>>>> jvm.dll!JVM_FindSignal+0x219a38 >>>>> jvm.dll!JVM_FindSignal+0x2188d4 >>>>> jvm.dll!JVM_FindSignal+0x218d2a >>>>> jvm.dll!JVM_FindSignal+0x219332 >>>>> jvm.dll!JVM_FindSignal+0x11da99 >>>>> msvcrt.dll!endthreadex+0x47 >>>>> msvcrt.dll!endthreadex+0x100 >>>>> kernel32.dll!BaseThreadInitThunk+0xd >>>>> ntdll.dll!RtlUserThreadStart+0x1d >>>>> >>>>> I expect it is somehow related to GC, as the application is >>>>> extremely memory intensive. However, I have found the 32-bit VM >>>>> seems to cope, where as the 64-bit version seems to end up in these >>>>> CPU loops in the VM thread. >>>>> >>>>> I can run jstack, but I have waited over 30 minutes for jconsole, >>>>> and it has still not come up.. >>>>> >>>>> Any ideas? I am hoping now that I have specified the exact version >>>>> of jvm.dll.. we can at least see what the offsets refer to? >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>> Tom Rodriguez wrote: >>>>>> Have you tried using jconsole or -verbose:gc to watch your app? >>>>>> Maybe it's running low on heap and spending too much time in GC. >>>>>> tom >>>>>> On Feb 18, 2009, at 4:29 PM, David Sitsky wrote: >>>>>>> I apologise in advance if this is a "breach of protocol". I have >>>>>>> submitted a bug through the usual channels, but my experience >>>>>>> with this approach unfortunately has usually been a dead-end. >>>>>>> >>>>>>> I have a very intensive data application (I/O + CPU + memory) on >>>>>>> the Windows platform that reliably causes a 100% CPU lockup, but >>>>>>> only for the x64 distribution (jdk 1.6.0_07, 1.6.0_10 and >>>>>>> 1.6.0_12). When using the x32 distribution on the same machines >>>>>>> it works fine. It is not machine-specific - I have seen this >>>>>>> across 7 different machines, and it seems to occur after a few to >>>>>>> several hours of processing. The JVM is still responsive, but >>>>>>> extremely slow. >>>>>>> >>>>>>> Using process explorer, I was able to find the thread in the >>>>>>> process consuming all the CPU. The stack traces from procexp >>>>>>> have the same thread ID as the "VM Thread" from jstack. The >>>>>>> stacks are usually something like the following: >>>>>>> >>>>>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x126f >>>>>>> ntoskrnl.exe!RtlNumberOfClearBits+0x5cc >>>>>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x134d >>>>>>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>>>>>> jvm.dll!AsyncGetCallTrace+0x3ac7f >>>>>>> jvm.dll!JVM_FindSignal+0xe4533 >>>>>>> jvm.dll!JVM_FindSignal+0x10fa2e >>>>>>> jvm.dll!JVM_FindSignal+0xe3eef >>>>>>> jvm.dll!JVM_FindSignal+0x14d61d >>>>>>> jvm.dll!JVM_FindSignal+0x14dabc >>>>>>> jvm.dll!JVM_FindSignal+0x1593e0 >>>>>>> jvm.dll!JVM_FindSignal+0x12a374 >>>>>>> jvm.dll!JVM_FindSignal+0x2167d3 >>>>>>> jvm.dll!JVM_FindSignal+0x2193e8 >>>>>>> jvm.dll!JVM_FindSignal+0x218274 >>>>>>> jvm.dll!JVM_FindSignal+0x2186ca >>>>>>> jvm.dll!JVM_FindSignal+0x218cd2 >>>>>>> jvm.dll!JVM_FindSignal+0x11d7f9 >>>>>>> msvcrt.dll!free_dbg+0x147 >>>>>>> msvcrt.dll!beginthreadex+0x131 >>>>>>> kernel32.dll!BaseThreadInitThunk+0xd >>>>>>> ntdll.dll!RtlUserThreadStart+0x21 >>>>>>> >>>>>>> or >>>>>>> >>>>>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x126f >>>>>>> ntoskrnl.exe!KeWaitForMultipleObjects+0xcca >>>>>>> ntoskrnl.exe!KeWaitForMutexObject+0x2da >>>>>>> ntoskrnl.exe!_misaligned_access+0x35 >>>>>>> ntoskrnl.exe!MmUnlockPages+0x1160 >>>>>>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>>>>>> jvm.dll!AsyncGetCallTrace+0x3ac7f >>>>>>> jvm.dll!JVM_FindSignal+0xe3eef >>>>>>> jvm.dll!JVM_FindSignal+0x14d61d >>>>>>> jvm.dll!JVM_FindSignal+0x14dabc >>>>>>> jvm.dll!JVM_FindSignal+0x1593e0 >>>>>>> jvm.dll!JVM_FindSignal+0x12a374 >>>>>>> jvm.dll!JVM_FindSignal+0x2167d3 >>>>>>> jvm.dll!JVM_FindSignal+0x2193e8 >>>>>>> jvm.dll!JVM_FindSignal+0x218274 >>>>>>> jvm.dll!JVM_FindSignal+0x2186ca >>>>>>> jvm.dll!JVM_FindSignal+0x218cd2 >>>>>>> jvm.dll!JVM_FindSignal+0x11d7f9 >>>>>>> msvcrt.dll!free_dbg+0x147 >>>>>>> msvcrt.dll!beginthreadex+0x131 >>>>>>> kernel32.dll!BaseThreadInitThunk+0xd >>>>>>> ntdll.dll!RtlUserThreadStart+0x21 >>>>>>> >>>>>>> or (without AsyncGetCallTrace): >>>>>>> >>>>>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x14a0 >>>>>>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>>>>>> jvm.dll!JVM_EnqueueOperation+0xb19f4 >>>>>>> jvm.dll!JVM_FindSignal+0x1b7fcc >>>>>>> jvm.dll!JVM_FindSignal+0x14dcca >>>>>>> jvm.dll!JVM_FindSignal+0x14e17c >>>>>>> jvm.dll!JVM_FindSignal+0x159b80 >>>>>>> jvm.dll!JVM_FindSignal+0x12a5e4 >>>>>>> jvm.dll!JVM_FindSignal+0x216e53 >>>>>>> jvm.dll!JVM_FindSignal+0x219a38 >>>>>>> jvm.dll!JVM_FindSignal+0x2188d4 >>>>>>> jvm.dll!JVM_FindSignal+0x218d2a >>>>>>> jvm.dll!JVM_FindSignal+0x219332 >>>>>>> jvm.dll!JVM_FindSignal+0x11da99 >>>>>>> msvcrt.dll!free_dbg+0x147 >>>>>>> msvcrt.dll!beginthreadex+0x131 >>>>>>> kernel32.dll!BaseThreadInitThunk+0xd >>>>>>> ntdll.dll!RtlUserThreadStart+0x21 >>>>>>> >>>>>>> I am more than happy to run test/debug versions in order to >>>>>>> assist in tracking this down. I wish I could say, here is a unit >>>>>>> test, but its a very complex application with complex data >>>>>>> processing. The only good news is it seems to be quite >>>>>>> reproduceable on our systems. >>>>>>> >>>>>>> Apologies again in advance if this was an inappropriate place to >>>>>>> post. But given the severity of this issue, I am hoping somebody >>>>>>> here will be interested in it.. >>>>>>> >>>>>>> -- >>>>>>> Cheers, >>>>>>> David >>> >>> > > From Thomas.Rodriguez at Sun.COM Mon Feb 23 17:17:46 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 23 Feb 2009 17:17:46 -0800 Subject: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application In-Reply-To: <49A3454A.4010507@nuix.com> References: <499CA7D9.9040903@nuix.com> <4E0D3F42-021A-4D48-888E-594A5980D0E1@sun.com> <49A33600.7000004@nuix.com> <49A3454A.4010507@nuix.com> Message-ID: <6E9B68B5-1FE1-4CF8-8C59-82921E2121D0@Sun.COM> On Feb 23, 2009, at 4:54 PM, David Sitsky wrote: > The machine is heavily loaded. Its a quad-core machine with 8 gigs > of memory, however each Java process has a 1g heap size set. I can > see from the task manager I still have free/unused memory on my > system, but of course that is not really relevant for the 4 > individual JVMs which are running. > > When I say jconsole won't start - this is when I specify the > specific process ID. I can still run other applications on the > machine, albeit slowly. > > If I set a 1 gig heap size for a 32-bit process, what would be a > very rough rule of thumb that I should set for a 64-bit process? > Another 200 megs or so? It's very data dependent but 20% probably isn't a bad starting place. jmap -histo could give you a more detailed picture. tom > > > I'll try it again with more memory, and also set the -verbose:gc flag. > > Cheers, > David > > Tom Rodriguez wrote: >> We keep pdb files from all our builds but don't normally distribute >> them. That's an address in MarkSweep::follow_stack and I believe >> that all the other address you were seeing were also in the GC. If >> jconsole doesn't work then try -verbose:gc which will just spew out >> the information directly. The fact that jconsole wouldn't start is >> pretty odd. Is your machine heavily loaded? You aren't doing >> something silly like specifying heap sizes that are greater than or >> too close to your actual amount of RAM? 64 bit apps usually >> require more heap for the same problem. >> tom >> On Feb 23, 2009, at 3:49 PM, David Sitsky wrote: >>> Hi Tom, >>> >>> Apologies for the delay in my reply. I have downloaded the Window >>> kernel symbols so that the stacks from procexp are more reliable. >>> I don't know where I can obtain the pdb files for jvm.dll. Are >>> they available anywhere? >>> >>> Here is another example stack, using 1.6.0_12, jvm.dll is >>> 11.02.0000.0001 Java Hotspot (TM) 64-Bit Server VM: >>> >>> ntoskrnl.exe!KiSwapContext+0x7f >>> ntoskrnl.exe!KiSwapThread+0x2fa >>> ntoskrnl.exe!KeWaitForSingleObject+0x2da >>> ntoskrnl.exe!KiSuspendThread+0x29 >>> ntoskrnl.exe!KiDeliverApc+0x420 >>> ntoskrnl.exe!KiApcInterrupt+0x103 >>> jvm.dll!JVM_FindSignal+0xe3f45 >>> jvm.dll!JVM_FindSignal+0x14dcdd >>> jvm.dll!JVM_FindSignal+0x14e17c >>> jvm.dll!JVM_FindSignal+0x159b80 >>> jvm.dll!JVM_FindSignal+0x12a5e4 >>> jvm.dll!JVM_FindSignal+0x216e53 >>> jvm.dll!JVM_FindSignal+0x219a38 >>> jvm.dll!JVM_FindSignal+0x2188d4 >>> jvm.dll!JVM_FindSignal+0x218d2a >>> jvm.dll!JVM_FindSignal+0x219332 >>> jvm.dll!JVM_FindSignal+0x11da99 >>> msvcrt.dll!endthreadex+0x47 >>> msvcrt.dll!endthreadex+0x100 >>> kernel32.dll!BaseThreadInitThunk+0xd >>> ntdll.dll!RtlUserThreadStart+0x1d >>> >>> I expect it is somehow related to GC, as the application is >>> extremely memory intensive. However, I have found the 32-bit VM >>> seems to cope, where as the 64-bit version seems to end up in >>> these CPU loops in the VM thread. >>> >>> I can run jstack, but I have waited over 30 minutes for jconsole, >>> and it has still not come up.. >>> >>> Any ideas? I am hoping now that I have specified the exact >>> version of jvm.dll.. we can at least see what the offsets refer to? >>> >>> Cheers, >>> David >>> >>> Tom Rodriguez wrote: >>>> Have you tried using jconsole or -verbose:gc to watch your app? >>>> Maybe it's running low on heap and spending too much time in GC. >>>> tom >>>> On Feb 18, 2009, at 4:29 PM, David Sitsky wrote: >>>>> I apologise in advance if this is a "breach of protocol". I >>>>> have submitted a bug through the usual channels, but my >>>>> experience with this approach unfortunately has usually been a >>>>> dead-end. >>>>> >>>>> I have a very intensive data application (I/O + CPU + memory) on >>>>> the Windows platform that reliably causes a 100% CPU lockup, but >>>>> only for the x64 distribution (jdk 1.6.0_07, 1.6.0_10 and >>>>> 1.6.0_12). When using the x32 distribution on the same machines >>>>> it works fine. It is not machine-specific - I have seen this >>>>> across 7 different machines, and it seems to occur after a few >>>>> to several hours of processing. The JVM is still responsive, >>>>> but extremely slow. >>>>> >>>>> Using process explorer, I was able to find the thread in the >>>>> process consuming all the CPU. The stack traces from procexp >>>>> have the same thread ID as the "VM Thread" from jstack. The >>>>> stacks are usually something like the following: >>>>> >>>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x126f >>>>> ntoskrnl.exe!RtlNumberOfClearBits+0x5cc >>>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x134d >>>>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>>>> jvm.dll!AsyncGetCallTrace+0x3ac7f >>>>> jvm.dll!JVM_FindSignal+0xe4533 >>>>> jvm.dll!JVM_FindSignal+0x10fa2e >>>>> jvm.dll!JVM_FindSignal+0xe3eef >>>>> jvm.dll!JVM_FindSignal+0x14d61d >>>>> jvm.dll!JVM_FindSignal+0x14dabc >>>>> jvm.dll!JVM_FindSignal+0x1593e0 >>>>> jvm.dll!JVM_FindSignal+0x12a374 >>>>> jvm.dll!JVM_FindSignal+0x2167d3 >>>>> jvm.dll!JVM_FindSignal+0x2193e8 >>>>> jvm.dll!JVM_FindSignal+0x218274 >>>>> jvm.dll!JVM_FindSignal+0x2186ca >>>>> jvm.dll!JVM_FindSignal+0x218cd2 >>>>> jvm.dll!JVM_FindSignal+0x11d7f9 >>>>> msvcrt.dll!free_dbg+0x147 >>>>> msvcrt.dll!beginthreadex+0x131 >>>>> kernel32.dll!BaseThreadInitThunk+0xd >>>>> ntdll.dll!RtlUserThreadStart+0x21 >>>>> >>>>> or >>>>> >>>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x126f >>>>> ntoskrnl.exe!KeWaitForMultipleObjects+0xcca >>>>> ntoskrnl.exe!KeWaitForMutexObject+0x2da >>>>> ntoskrnl.exe!_misaligned_access+0x35 >>>>> ntoskrnl.exe!MmUnlockPages+0x1160 >>>>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>>>> jvm.dll!AsyncGetCallTrace+0x3ac7f >>>>> jvm.dll!JVM_FindSignal+0xe3eef >>>>> jvm.dll!JVM_FindSignal+0x14d61d >>>>> jvm.dll!JVM_FindSignal+0x14dabc >>>>> jvm.dll!JVM_FindSignal+0x1593e0 >>>>> jvm.dll!JVM_FindSignal+0x12a374 >>>>> jvm.dll!JVM_FindSignal+0x2167d3 >>>>> jvm.dll!JVM_FindSignal+0x2193e8 >>>>> jvm.dll!JVM_FindSignal+0x218274 >>>>> jvm.dll!JVM_FindSignal+0x2186ca >>>>> jvm.dll!JVM_FindSignal+0x218cd2 >>>>> jvm.dll!JVM_FindSignal+0x11d7f9 >>>>> msvcrt.dll!free_dbg+0x147 >>>>> msvcrt.dll!beginthreadex+0x131 >>>>> kernel32.dll!BaseThreadInitThunk+0xd >>>>> ntdll.dll!RtlUserThreadStart+0x21 >>>>> >>>>> or (without AsyncGetCallTrace): >>>>> >>>>> ntoskrnl.exe!ExpInterlockedFlushSList+0x14a0 >>>>> ntoskrnl.exe!IoAcquireCancelSpinLock+0x163 >>>>> jvm.dll!JVM_EnqueueOperation+0xb19f4 >>>>> jvm.dll!JVM_FindSignal+0x1b7fcc >>>>> jvm.dll!JVM_FindSignal+0x14dcca >>>>> jvm.dll!JVM_FindSignal+0x14e17c >>>>> jvm.dll!JVM_FindSignal+0x159b80 >>>>> jvm.dll!JVM_FindSignal+0x12a5e4 >>>>> jvm.dll!JVM_FindSignal+0x216e53 >>>>> jvm.dll!JVM_FindSignal+0x219a38 >>>>> jvm.dll!JVM_FindSignal+0x2188d4 >>>>> jvm.dll!JVM_FindSignal+0x218d2a >>>>> jvm.dll!JVM_FindSignal+0x219332 >>>>> jvm.dll!JVM_FindSignal+0x11da99 >>>>> msvcrt.dll!free_dbg+0x147 >>>>> msvcrt.dll!beginthreadex+0x131 >>>>> kernel32.dll!BaseThreadInitThunk+0xd >>>>> ntdll.dll!RtlUserThreadStart+0x21 >>>>> >>>>> I am more than happy to run test/debug versions in order to >>>>> assist in tracking this down. I wish I could say, here is a >>>>> unit test, but its a very complex application with complex data >>>>> processing. The only good news is it seems to be quite >>>>> reproduceable on our systems. >>>>> >>>>> Apologies again in advance if this was an inappropriate place to >>>>> post. But given the severity of this issue, I am hoping somebody >>>>> here will be interested in it.. >>>>> >>>>> -- >>>>> Cheers, >>>>> David > > > -- > Cheers, > David > > Nuix Pty Ltd > Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 > 0699 > Web: http://www.nuix.com Fax: +61 2 9212 > 6902 From Jon.Masamitsu at Sun.COM Mon Feb 23 17:20:41 2009 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Mon, 23 Feb 2009 17:20:41 -0800 Subject: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application In-Reply-To: <49A3454A.4010507@nuix.com> References: <499CA7D9.9040903@nuix.com> <4E0D3F42-021A-4D48-888E-594A5980D0E1@sun.com> <49A33600.7000004@nuix.com> <49A3454A.4010507@nuix.com> Message-ID: <49A34B69.2000608@sun.com> David Sitsky wrote On 02/23/09 16:54,: >The machine is heavily loaded. Its a quad-core machine with 8 gigs of >memory, however each Java process has a 1g heap size set. I can see >from the task manager I still have free/unused memory on my system, but >of course that is not really relevant for the 4 individual JVMs which >are running. > >When I say jconsole won't start - this is when I specify the specific >process ID. I can still run other applications on the machine, albeit >slowly. > >If I set a 1 gig heap size for a 32-bit process, what would be a very >rough rule of thumb that I should set for a 64-bit process? Another 200 >megs or so? > > Increase the heap by 30%. Also increase the the perm gen size (-XX:MaxPermSize=). Please use -XX:+PrintGCDetails -XX:+PrintGCTimeStamps when gathering the GC logs. If you've already gathering some, send those but in future runs, use the above. > > From Jon.Masamitsu at Sun.COM Mon Feb 23 17:31:30 2009 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Mon, 23 Feb 2009 17:31:30 -0800 Subject: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application In-Reply-To: <49A34B69.2000608@sun.com> References: <499CA7D9.9040903@nuix.com> <4E0D3F42-021A-4D48-888E-594A5980D0E1@sun.com> <49A33600.7000004@nuix.com> <49A3454A.4010507@nuix.com> <49A34B69.2000608@sun.com> Message-ID: <49A34DF2.2010800@sun.com> Jon Masamitsu wrote On 02/23/09 17:20,: > ... > >Increase the heap by 30%. Also increase the the perm gen size >(-XX:MaxPermSize=). > >Please use -XX:+PrintGCDetails -XX:+PrintGCTimeStamps when gathering the >GC logs. >If you've already gathering some, send those but in future runs, use the >above. > > Please also send an example of a 32bit run where it's working well. From Jon.Masamitsu at Sun.COM Mon Feb 23 17:36:23 2009 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Mon, 23 Feb 2009 17:36:23 -0800 Subject: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application In-Reply-To: References: <499CA7D9.9040903@nuix.com> <4E0D3F42-021A-4D48-888E-594A5980D0E1@sun.com> <49A33600.7000004@nuix.com> <49A3454A.4010507@nuix.com> <49A345E4.3020209@sun.com> <49A348CB.1040804@nuix.com> Message-ID: <49A34F17.9010108@sun.com> Tom Rodriguez wrote On 02/23/09 17:15,: >There is a GCTimeLimit which should give up if we're spending too much >time in GC but maybe you're on the edge or it's not enabled for your >collector. > > > Only collectors with ergonomics currently have the GCTimeLimit feature (need the feature to measure the GC times). Currently that's only UseParallelGC (or UseParallelOldGC). Well, CMS has an implementation if it's spending all its time doing full GC's but it has to be turned on. From imdupeng at gmail.com Mon Feb 23 18:06:49 2009 From: imdupeng at gmail.com (Peng Du) Date: Mon, 23 Feb 2009 20:06:49 -0600 Subject: Stack and local variables in bytecode tracing Message-ID: Hello, everyone I know there is a BytecodeTracer class which is only enabled in DEBUG build, which is used to spit out bytecodes when the TraceBytecodes option is turned on. What I am interested in are the addresses to java heap being accessed (read/write) when the opcodes, e.g. aload, astore, putfield, etc, are executed. However, by default this method does not print out those kind of information even in verbose mode AFAIK. So, I want to modify the class by adding a new method whose solely purpose is when a memory access code is in execution, extract the memory addresses, either from the expression stack (for xxstore), or from the local variable pool (for xxload). I know tos, tos2 are passed directly to the BytecodeTracer::trace() method. But for array opcodes, e.g. aastore, there are three elements on stack, i.e*. *arrayref, index, value*. *If "value" is tos, how can I get arrayref? Furthermore, what are the correct ways to peek on the expression stack and in local variable pool? My another question is: in bytecodes.hpp, there are two groups of bytecodes, ie. Java bytecodes and JVM bytecodes. I understand what Java bytecodes are. But what are JVM bytecodes (_fast_XX)? Thanks in advance. Peng Du -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090223/7ca44134/attachment.html From sits at nuix.com Mon Feb 23 18:23:23 2009 From: sits at nuix.com (David Sitsky) Date: Tue, 24 Feb 2009 13:23:23 +1100 Subject: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application In-Reply-To: <49A34F17.9010108@sun.com> References: <499CA7D9.9040903@nuix.com> <4E0D3F42-021A-4D48-888E-594A5980D0E1@sun.com> <49A33600.7000004@nuix.com> <49A3454A.4010507@nuix.com> <49A345E4.3020209@sun.com> <49A348CB.1040804@nuix.com> <49A34F17.9010108@sun.com> Message-ID: <49A35A1B.4040303@nuix.com> Jon Masamitsu wrote: > Tom Rodriguez wrote On 02/23/09 17:15,: > >> There is a GCTimeLimit which should give up if we're spending too much >> time in GC but maybe you're on the edge or it's not enabled for your >> collector. >> > Only collectors with ergonomics currently have the GCTimeLimit feature > (need the feature to measure the GC times). Currently that's only > UseParallelGC (or UseParallelOldGC). Well, CMS has an implementation > if it's spending all its time doing full GC's but it has to be turned on. I am using the default GC on my 64-bit quad-core, so jstack reveals it is the ParallelGC implementation. This will take me some time, but I will do the run again with: -XX:+PrintGCDetails -XX:+PrintGCTimeStamps with the same memory settings, and will try to do it again with 30% more memory allocated, and potentially with the 32-bit version as well. Thanks to everyone for their helpful responses. -- Cheers, David Nuix Pty Ltd Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 0699 Web: http://www.nuix.com Fax: +61 2 9212 6902 From Vikram.Aroskar at Sun.COM Mon Feb 23 19:33:44 2009 From: Vikram.Aroskar at Sun.COM (Vikram Aroskar) Date: Tue, 24 Feb 2009 09:03:44 +0530 Subject: Question about fast path and slow path In-Reply-To: <22169919.post@talk.nabble.com> References: <22169919.post@talk.nabble.com> Message-ID: <49A36A98.5010505@sun.com> Hello, I can try to answer #2 partially. Fast path is basically lock free allocation. This is mostly related to TLAB allocation where the allocating thread (is allocating in large contiguous free memory) need not worry about synchronisation. It can just allocate by incrementing the pointer. Slow path is mainly synchronised allocation. This mostly happens in the old generation, for eg in cases like a large object being allocated directly in the Old gen due to lack of space in the young gen. rgds, Vikram. On 02/24/09 02:25, Colin(Du Li) wrote: > Hello, > > I have some questions about jvm slow path to ask you: > 1. How can we force jvm to go slow path? Is there any jvm options? > 2. What's the difference between slow path and fast path? > 3. During slow path, will the interpreter translate the bytecode into > assembly codes? > > Thanks a lot! > > Colin > From Jon.Masamitsu at Sun.COM Mon Feb 23 20:55:11 2009 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Mon, 23 Feb 2009 20:55:11 -0800 Subject: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application In-Reply-To: <49A35A1B.4040303@nuix.com> References: <499CA7D9.9040903@nuix.com> <4E0D3F42-021A-4D48-888E-594A5980D0E1@sun.com> <49A33600.7000004@nuix.com> <49A3454A.4010507@nuix.com> <49A345E4.3020209@sun.com> <49A348CB.1040804@nuix.com> <49A34F17.9010108@sun.com> <49A35A1B.4040303@nuix.com> Message-ID: <49A37DAF.5040605@sun.com> David Sitsky wrote On 02/23/09 18:23,: > ... > > >I am using the default GC on my 64-bit quad-core, so jstack reveals it >is the ParallelGC implementation. > > > Be aware that on windows 32bit the default is the UseSerialGC collector unless you specify otherwise on the command line. Similarly you'll get the client VM (-client) and will get a 64m maximum heap (again unless you specify differently). From sits at nuix.com Mon Feb 23 22:03:17 2009 From: sits at nuix.com (David Sitsky) Date: Tue, 24 Feb 2009 17:03:17 +1100 Subject: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application In-Reply-To: <49A37DAF.5040605@sun.com> References: <499CA7D9.9040903@nuix.com> <4E0D3F42-021A-4D48-888E-594A5980D0E1@sun.com> <49A33600.7000004@nuix.com> <49A3454A.4010507@nuix.com> <49A345E4.3020209@sun.com> <49A348CB.1040804@nuix.com> <49A34F17.9010108@sun.com> <49A35A1B.4040303@nuix.com> <49A37DAF.5040605@sun.com> Message-ID: <49A38DA5.9040608@nuix.com> Jon Masamitsu wrote: > David Sitsky wrote On 02/23/09 18:23,: > >> ... >> >> >> I am using the default GC on my 64-bit quad-core, so jstack reveals it >> is the ParallelGC implementation. >> > > Be aware that on windows 32bit the default is the UseSerialGC collector > unless you specify otherwise on the command line. Similarly you'll get > the client VM (-client) and will get a 64m maximum heap (again unless > you specify differently). We use the server VM explicitly for 32-bit so we still get the parallel GC.. I just checked it with jstack. -- Cheers, David Nuix Pty Ltd Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 0699 Web: http://www.nuix.com Fax: +61 2 9212 6902 From Christian.Thalinger at Sun.COM Tue Feb 24 01:58:25 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 24 Feb 2009 10:58:25 +0100 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <8B73CF14-A44D-4460-870F-B4D65E204312@sun.com> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> <1235407641.11128.98.camel@localhost.localdomain> <1235410237.11128.103.camel@localhost.localdomain> <8B73CF14-A44D-4460-870F-B4D65E204312@sun.com> Message-ID: <1235469506.11128.166.camel@localhost.localdomain> On Mon, 2009-02-23 at 11:43 -0800, Tom Rodriguez wrote: > Given the way that NameList is being abused in the code, I think (int) > (intptr_t) preserves the intent of storing ints so I think I prefer > your patch below. Here is the second version of the patch: http://cr.openjdk.java.net/~twisti/6778669/webrev.01/ I added +w to the SunCC compiler flags to find all bugs that GCC could probably complain about. I will remove that flag before commit unless I can fix the remaining warnings like these: "/export/home/twisti/hotspot-comp/6778669/src/share/vm/adlc/formssel.hpp", line 1017: Warning: MatchRule::append_components hides the function MatchNode::append_components(FormDict&, ComponentList&, bool) const. "/export/home/twisti/hotspot-comp/6778669/src/share/vm/adlc/formssel.hpp", line 1017: Warning: MatchRule::cisc_spill_match hides the function MatchNode::cisc_spill_match(FormDict&, RegisterForm*, MatchNode*, const char*&, const char*&). "/export/home/twisti/hotspot-comp/6778669/src/share/vm/adlc/formssel.hpp", line 1017: Warning: MatchRule::equivalent hides the function MatchNode::equivalent(FormDict&, MatchNode*). "/export/home/twisti/hotspot-comp/6778669/src/share/vm/adlc/formssel.hpp", line 1017: Warning: MatchRule::swap_commutative_op hides the function MatchNode::swap_commutative_op(bool, int). Unfortunately I don't know how to fix them properly. But it would be nice to have the +w flag in there as it found a lot of "bugs", like the printf ones. -- Christian From dawn2004 at gmail.com Tue Feb 24 09:25:04 2009 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Tue, 24 Feb 2009 09:25:04 -0800 (PST) Subject: Stack and local variables in bytecode tracing In-Reply-To: References: Message-ID: <22186328.post@talk.nabble.com> Peng Du wrote: > > Hello, everyone > > I know there is a BytecodeTracer class which is only enabled in DEBUG > build, > which is used to spit out bytecodes when the TraceBytecodes option is > turned > on. What I am interested in are the addresses to java heap being accessed > (read/write) when the opcodes, e.g. aload, astore, putfield, etc, are > executed. > > However, by default this method does not print out those kind of > information even in verbose mode AFAIK. So, I want to modify the class by > adding a new method whose solely purpose is when a memory access code is > in > execution, extract the memory addresses, either from the expression stack > (for xxstore), or from the local variable pool (for xxload). > > I know tos, tos2 are passed directly to the BytecodeTracer::trace() > method. > But for array opcodes, e.g. aastore, there are three elements on stack, > i.e*. > *arrayref, index, value*. *If "value" is tos, how can I get arrayref? > Value is on tos, the next two element in the stack is "arrayOff".You can > take a look at micro bytecodeInterpreter::ARRAY_INTRO, you can get some > insight about how to access the array with "arrayOff", that is, how get > arrayRef and index. > Furthermore, what are the correct ways to peek on the expression stack and > in local variable pool? > > > My another question is: in bytecodes.hpp, there are two groups of > bytecodes, > ie. Java bytecodes and JVM bytecodes. I understand what Java bytecodes > are. > But what are JVM bytecodes (_fast_XX)? > > > Thanks in advance. > > > > > > Peng Du > > -- View this message in context: http://www.nabble.com/Stack-and-local-variables-in-bytecode-tracing-tp22174382p22186328.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From Thomas.Rodriguez at Sun.COM Tue Feb 24 10:47:13 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 24 Feb 2009 10:47:13 -0800 Subject: Stack and local variables in bytecode tracing In-Reply-To: References: Message-ID: There are some helpers in frame.hpp for looking at interpreter frames though I don't know if they work correctly inside the bytecode tracer. The extra bytecodes are used internally to either implement faster special case versions of existing bytecodes or to implement other pieces of Java semantics. Our internal bytecode iterator normally hides their existence. tom On Feb 23, 2009, at 6:06 PM, Peng Du wrote: > Hello, everyone > > I know there is a BytecodeTracer class which is only enabled in > DEBUG build, which is used to spit out bytecodes when the > TraceBytecodes option is turned on. What I am interested in are the > addresses to java heap being accessed (read/write) when the opcodes, > e.g. aload, astore, putfield, etc, are executed. > > However, by default this method does not print out those kind of > information even in verbose mode AFAIK. So, I want to modify the > class by adding a new method whose solely purpose is when a memory > access code is in execution, extract the memory addresses, either > from the expression stack (for xxstore), or from the local variable > pool (for xxload). > > I know tos, tos2 are passed directly to the BytecodeTracer::trace() > method. But for array opcodes, e.g. aastore, there are three > elements on stack, i.e. arrayref, index, value. If "value" is tos, > how can I get arrayref? > > Furthermore, what are the correct ways to peek on the expression > stack and in local variable pool? > > > My another question is: in bytecodes.hpp, there are two groups of > bytecodes, ie. Java bytecodes and JVM bytecodes. I understand what > Java bytecodes are. But what are JVM bytecodes (_fast_XX)? > > > Thanks in advance. > > > > > > Peng Du > From gnu_andrew at member.fsf.org Tue Feb 24 12:24:28 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 24 Feb 2009 20:24:28 +0000 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <1235469506.11128.166.camel@localhost.localdomain> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> <1235407641.11128.98.camel@localhost.localdomain> <1235410237.11128.103.camel@localhost.localdomain> <8B73CF14-A44D-4460-870F-B4D65E204312@sun.com> <1235469506.11128.166.camel@localhost.localdomain> Message-ID: <17c6771e0902241224h57190218gfc7632de04cc610d@mail.gmail.com> 2009/2/24 Christian Thalinger : > On Mon, 2009-02-23 at 11:43 -0800, Tom Rodriguez wrote: >> Given the way that NameList is being abused in the code, I think (int) >> (intptr_t) preserves the intent of storing ints so I think I prefer >> your patch below. > > Here is the second version of the patch: > > http://cr.openjdk.java.net/~twisti/6778669/webrev.01/ > > I added +w to the SunCC compiler flags to find all bugs that GCC could > probably complain about. ?I will remove that flag before commit unless I > can fix the remaining warnings like these: > > "/export/home/twisti/hotspot-comp/6778669/src/share/vm/adlc/formssel.hpp", line 1017: Warning: MatchRule::append_components hides the function MatchNode::append_components(FormDict&, ComponentList&, bool) const. > "/export/home/twisti/hotspot-comp/6778669/src/share/vm/adlc/formssel.hpp", line 1017: Warning: MatchRule::cisc_spill_match hides the function MatchNode::cisc_spill_match(FormDict&, RegisterForm*, MatchNode*, const char*&, const char*&). > "/export/home/twisti/hotspot-comp/6778669/src/share/vm/adlc/formssel.hpp", line 1017: Warning: MatchRule::equivalent hides the function MatchNode::equivalent(FormDict&, MatchNode*). > "/export/home/twisti/hotspot-comp/6778669/src/share/vm/adlc/formssel.hpp", line 1017: Warning: MatchRule::swap_commutative_op hides the function MatchNode::swap_commutative_op(bool, int). > > Unfortunately I don't know how to fix them properly. ?But it would be > nice to have the +w flag in there as it found a lot of "bugs", like the > printf ones. > > -- Christian > > Works for me with GCC 4.3.3 on GNU/Linux x86_64. -- 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 Tue Feb 24 12:25:44 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 24 Feb 2009 21:25:44 +0100 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <17c6771e0902241224h57190218gfc7632de04cc610d@mail.gmail.com> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> <1235407641.11128.98.camel@localhost.localdomain> <1235410237.11128.103.camel@localhost.localdomain> <8B73CF14-A44D-4460-870F-B4D65E204312@sun.com> <1235469506.11128.166.camel@localhost.localdomain> <17c6771e0902241224h57190218gfc7632de04cc610d@mail.gmail.com> Message-ID: <1235507144.11128.198.camel@localhost.localdomain> On Tue, 2009-02-24 at 20:24 +0000, Andrew John Hughes wrote: > Works for me with GCC 4.3.3 on GNU/Linux x86_64. Very good! Just some reviews left and I can push it. -- Christian From Vladimir.Kozlov at Sun.COM Tue Feb 24 12:37:22 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 24 Feb 2009 12:37:22 -0800 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <1235469506.11128.166.camel@localhost.localdomain> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> <1235407641.11128.98.camel@localhost.localdomain> <1235410237.11128.103.camel@localhost.localdomain> <8B73CF14-A44D-4460-870F-B4D65E204312@sun.com> <1235469506.11128.166.camel@localhost.localdomain> Message-ID: <49A45A82.8040503@sun.com> Changes looks good. Can you just rename (add prefix/suffix) methods defined in MatchRule to avoid the warnings? Vladimir Christian Thalinger wrote: > On Mon, 2009-02-23 at 11:43 -0800, Tom Rodriguez wrote: >> Given the way that NameList is being abused in the code, I think (int) >> (intptr_t) preserves the intent of storing ints so I think I prefer >> your patch below. > > Here is the second version of the patch: > > http://cr.openjdk.java.net/~twisti/6778669/webrev.01/ > > I added +w to the SunCC compiler flags to find all bugs that GCC could > probably complain about. I will remove that flag before commit unless I > can fix the remaining warnings like these: > > "/export/home/twisti/hotspot-comp/6778669/src/share/vm/adlc/formssel.hpp", line 1017: Warning: MatchRule::append_components hides the function MatchNode::append_components(FormDict&, ComponentList&, bool) const. > "/export/home/twisti/hotspot-comp/6778669/src/share/vm/adlc/formssel.hpp", line 1017: Warning: MatchRule::cisc_spill_match hides the function MatchNode::cisc_spill_match(FormDict&, RegisterForm*, MatchNode*, const char*&, const char*&). > "/export/home/twisti/hotspot-comp/6778669/src/share/vm/adlc/formssel.hpp", line 1017: Warning: MatchRule::equivalent hides the function MatchNode::equivalent(FormDict&, MatchNode*). > "/export/home/twisti/hotspot-comp/6778669/src/share/vm/adlc/formssel.hpp", line 1017: Warning: MatchRule::swap_commutative_op hides the function MatchNode::swap_commutative_op(bool, int). > > Unfortunately I don't know how to fix them properly. But it would be > nice to have the +w flag in there as it found a lot of "bugs", like the > printf ones. > > -- Christian > From Thomas.Rodriguez at Sun.COM Tue Feb 24 12:42:00 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 24 Feb 2009 12:42:00 -0800 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <1235469506.11128.166.camel@localhost.localdomain> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> <1235407641.11128.98.camel@localhost.localdomain> <1235410237.11128.103.camel@localhost.localdomain> <8B73CF14-A44D-4460-870F-B4D65E204312@sun.com> <1235469506.11128.166.camel@localhost.localdomain> Message-ID: On Feb 24, 2009, at 1:58 AM, Christian Thalinger wrote: > On Mon, 2009-02-23 at 11:43 -0800, Tom Rodriguez wrote: >> Given the way that NameList is being abused in the code, I think >> (int) >> (intptr_t) preserves the intent of storing ints so I think I prefer >> your patch below. > > Here is the second version of the patch: > > http://cr.openjdk.java.net/~twisti/6778669/webrev.01/ This looks good to me. > > > I added +w to the SunCC compiler flags to find all bugs that GCC could > probably complain about. I will remove that flag before commit > unless I > can fix the remaining warnings like these: Some of these look like they should be virtual in MatchNode but I suspect most would need to be renamed to make them unique. tom > > > "/export/home/twisti/hotspot-comp/6778669/src/share/vm/adlc/ > formssel.hpp", line 1017: Warning: MatchRule::append_components > hides the function MatchNode::append_components(FormDict&, > ComponentList&, bool) const. > "/export/home/twisti/hotspot-comp/6778669/src/share/vm/adlc/ > formssel.hpp", line 1017: Warning: MatchRule::cisc_spill_match hides > the function MatchNode::cisc_spill_match(FormDict&, RegisterForm*, > MatchNode*, const char*&, const char*&). > "/export/home/twisti/hotspot-comp/6778669/src/share/vm/adlc/ > formssel.hpp", line 1017: Warning: MatchRule::equivalent hides the > function MatchNode::equivalent(FormDict&, MatchNode*). > "/export/home/twisti/hotspot-comp/6778669/src/share/vm/adlc/ > formssel.hpp", line 1017: Warning: MatchRule::swap_commutative_op > hides the function MatchNode::swap_commutative_op(bool, int). > > Unfortunately I don't know how to fix them properly. But it would be > nice to have the +w flag in there as it found a lot of "bugs", like > the > printf ones. > > -- Christian > From Christian.Thalinger at Sun.COM Tue Feb 24 12:59:05 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 24 Feb 2009 21:59:05 +0100 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <49A45A82.8040503@sun.com> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> <1235407641.11128.98.camel@localhost.localdomain> <1235410237.11128.103.camel@localhost.localdomain> <8B73CF14-A44D-4460-870F-B4D65E204312@sun.com> <1235469506.11128.166.camel@localhost.localdomain> <49A45A82.8040503@sun.com> Message-ID: <1235509145.11128.200.camel@localhost.localdomain> On Tue, 2009-02-24 at 12:37 -0800, Vladimir Kozlov wrote: > Changes looks good. > Can you just rename (add prefix/suffix) methods defined in MatchRule > to avoid the warnings? Sure. As Tom also said, I already tried to make some of them virtual but it didn't work, so renaming sounds like the better idea. I will do that tomorrow. -- Christian From vladimir.kozlov at sun.com Tue Feb 24 13:46:58 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Tue, 24 Feb 2009 21:46:58 +0000 Subject: hg: jdk7/hotspot/hotspot: 5 new changesets Message-ID: <20090224214708.23F13E0B0@hg.openjdk.java.net> Changeset: 5d75ab5f6698 Author: kvn Date: 2009-02-18 13:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5d75ab5f6698 6807084: AutoBox elimination is broken with compressed oops Summary: Add checks for DecodeN nodes into AutoBox elimination code. Reviewed-by: never ! src/share/vm/opto/memnode.cpp Changeset: 49a36a80b0c7 Author: kvn Date: 2009-02-19 17:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/49a36a80b0c7 6802499: EA: assert(false,"unknown node on this path") Summary: Add missing checks for SCMemProj node in Escape analysis code. Reviewed-by: never ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/macro.cpp Changeset: 22e09c0f4b47 Author: twisti Date: 2009-02-23 12:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/22e09c0f4b47 6808589: Merge vm_version_x86_{32,64}.{cpp,hpp} Summary: There is very much duplicated code in vm_version_x86_{32,64}.{cpp,hpp}. Refactoring these would help maintainability. Reviewed-by: kvn, never + src/cpu/x86/vm/vm_version_x86.cpp + src/cpu/x86/vm/vm_version_x86.hpp - src/cpu/x86/vm/vm_version_x86_32.cpp - src/cpu/x86/vm/vm_version_x86_32.hpp - src/cpu/x86/vm/vm_version_x86_64.cpp - src/cpu/x86/vm/vm_version_x86_64.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.hpp ! src/share/vm/includeDB_core Changeset: 6bea93606c11 Author: kvn Date: 2009-02-23 16:03 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6bea93606c11 6791572: assert("duplicating node that's already been matched") Summary: Mark inputs for an address expression as shared if there are other uses besides address expressions. Reviewed-by: never ! src/share/vm/opto/matcher.cpp Changeset: e57b6f22d1f3 Author: kvn Date: 2009-02-24 09:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e57b6f22d1f3 Merge - src/cpu/x86/vm/vm_version_x86_32.cpp - src/cpu/x86/vm/vm_version_x86_32.hpp - src/cpu/x86/vm/vm_version_x86_64.cpp - src/cpu/x86/vm/vm_version_x86_64.hpp From sits at nuix.com Tue Feb 24 16:04:36 2009 From: sits at nuix.com (David Sitsky) Date: Wed, 25 Feb 2009 11:04:36 +1100 Subject: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application In-Reply-To: <49A34DF2.2010800@sun.com> References: <499CA7D9.9040903@nuix.com> <4E0D3F42-021A-4D48-888E-594A5980D0E1@sun.com> <49A33600.7000004@nuix.com> <49A3454A.4010507@nuix.com> <49A34B69.2000608@sun.com> <49A34DF2.2010800@sun.com> Message-ID: <49A48B14.8070307@nuix.com> Jon Masamitsu wrote: > Jon Masamitsu wrote On 02/23/09 17:20,: > >> ... >> >> Increase the heap by 30%. Also increase the the perm gen size >> (-XX:MaxPermSize=). >> >> Please use -XX:+PrintGCDetails -XX:+PrintGCTimeStamps when gathering the >> GC logs. >> If you've already gathering some, send those but in future runs, use the >> above. Here is a sample of output from a stuck process. You can see its doing a full GC about every 3 seconds, and it seems as if there is little progress.. Please let me know if you need more information. Cheers, David 62402.320: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8063178 secs] [Times: user=2.81 sys=0.00, real=2.81 secs] 62405.128: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8029997 secs] [Times: user=2.79 sys=0.00, real=2.81 secs] 62407.932: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.7917325 secs] [Times: user=2.79 sys=0.00, real=2.79 secs] 62410.725: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.7891387 secs] [Times: user=2.79 sys=0.00, real=2.79 secs] 62413.515: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.7649110 secs] [Times: user=2.76 sys=0.00, real=2.76 secs] 62416.281: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.7803983 secs] [Times: user=2.78 sys=0.00, real=2.78 secs] 62419.063: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.7643979 secs] [Times: user=2.76 sys=0.00, real=2.76 secs] 62421.828: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8114336 secs] [Times: user=2.81 sys=0.00, real=2.81 secs] 62424.640: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.7964912 secs] [Times: user=2.79 sys=0.00, real=2.79 secs] 62427.438: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8107278 secs] [Times: user=2.81 sys=0.00, real=2.81 secs] 62430.249: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: 49694K->49694K(49984K)], 3.2345212 secs] [Times: user=2.84 sys=0.00, real=3.24 secs] 62433.484: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8341520 secs] [Times: user=2.82 sys=0.00, real=2.82 secs] 62436.319: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8698768 secs] [Times: user=2.87 sys=0.00, real=2.87 secs] 62439.190: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9323230 secs] [Times: user=2.90 sys=0.00, real=2.92 secs] 62442.124: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9644960 secs] [Times: user=2.96 sys=0.00, real=2.96 secs] 62445.089: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: 49694K->49694K(49984K)], 3.0059221 secs] [Times: user=3.00 sys=0.00, real=3.00 secs] 62448.095: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9832815 secs] [Times: user=3.00 sys=0.00, real=2.99 secs] 62451.079: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9587156 secs] [Times: user=2.93 sys=0.00, real=2.95 secs] 62454.039: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9488345 secs] [Times: user=2.92 sys=0.00, real=2.95 secs] 62456.988: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8969788 secs] [Times: user=2.90 sys=0.00, real=2.90 secs] 62459.886: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8794991 secs] [Times: user=2.89 sys=0.00, real=2.89 secs] 62462.766: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8842411 secs] [Times: user=2.87 sys=0.00, real=2.89 secs] 62465.651: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683675K(699072K)] 781916K->781915K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8669173 secs] [Times: user=2.85 sys=0.00, real=2.85 secs] 62468.519: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8664429 secs] [Times: user=2.85 sys=0.00, real=2.86 secs] 62471.386: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8844494 secs] [Times: user=2.87 sys=0.00, real=2.89 secs] 62474.271: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8648398 secs] [Times: user=2.87 sys=0.00, real=2.87 secs] 62477.137: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8971068 secs] [Times: user=2.87 sys=0.00, real=2.90 secs] 62480.034: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8655618 secs] [Times: user=2.86 sys=0.00, real=2.86 secs] 62482.901: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 3.0366140 secs] [Times: user=2.78 sys=0.00, real=3.04 secs] 62485.939: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8541753 secs] [Times: user=2.85 sys=0.00, real=2.85 secs] 62488.794: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8582816 secs] [Times: user=2.86 sys=0.00, real=2.86 secs] 62491.653: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8673218 secs] [Times: user=2.85 sys=0.00, real=2.86 secs] 62494.521: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9014120 secs] [Times: user=2.87 sys=0.00, real=2.90 secs] 62497.424: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8805843 secs] [Times: user=2.89 sys=0.00, real=2.89 secs] 62500.305: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8905128 secs] [Times: user=2.89 sys=0.00, real=2.89 secs] 62503.196: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9052007 secs] [Times: user=2.90 sys=0.00, real=2.92 secs] 62506.102: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9004575 secs] [Times: user=2.89 sys=0.00, real=2.90 secs] 62509.003: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9160655 secs] [Times: user=2.90 sys=0.00, real=2.92 secs] 62511.920: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9013277 secs] [Times: user=2.90 sys=0.00, real=2.90 secs] 62514.822: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8982061 secs] [Times: user=2.89 sys=0.00, real=2.89 secs] 62517.721: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8922437 secs] [Times: user=2.89 sys=0.00, real=2.89 secs] 62520.614: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8873520 secs] [Times: user=2.87 sys=0.00, real=2.89 secs] 62523.502: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8805296 secs] [Times: user=2.89 sys=0.00, real=2.89 secs] 62526.383: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8958714 secs] [Times: user=2.85 sys=0.00, real=2.89 secs] 62529.279: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8735384 secs] [Times: user=2.89 sys=0.00, real=2.89 secs] 62532.154: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8705676 secs] [Times: user=2.87 sys=0.00, real=2.87 secs] 62535.025: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8723947 secs] [Times: user=2.85 sys=0.00, real=2.87 secs] 62537.898: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8624400 secs] [Times: user=2.86 sys=0.00, real=2.86 secs] 62540.761: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8245748 secs] [Times: user=2.84 sys=0.00, real=2.84 secs] 62543.587: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8432269 secs] [Times: user=2.84 sys=0.00, real=2.84 secs] 62546.432: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8394157 secs] [Times: user=2.84 sys=0.00, real=2.84 secs] 62549.272: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8471951 secs] [Times: user=2.85 sys=0.00, real=2.85 secs] 62552.121: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8584107 secs] [Times: user=2.85 sys=0.00, real=2.86 secs] 62554.981: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8376807 secs] [Times: user=2.84 sys=0.00, real=2.84 secs] 62557.820: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8402486 secs] [Times: user=2.84 sys=0.00, real=2.84 secs] 62560.661: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8482704 secs] [Times: user=2.86 sys=0.00, real=2.85 secs] 62563.511: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8115973 secs] [Times: user=2.81 sys=0.00, real=2.81 secs] 62566.324: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8523278 secs] [Times: user=2.85 sys=0.00, real=2.86 secs] 62569.177: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8128563 secs] [Times: user=2.81 sys=0.00, real=2.81 secs] 62571.990: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.7830644 secs] [Times: user=2.79 sys=0.00, real=2.79 secs] 62574.774: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8065106 secs] [Times: user=2.79 sys=0.00, real=2.81 secs] 62577.582: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.7892171 secs] [Times: user=2.79 sys=0.00, real=2.79 secs] 62580.372: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8059306 secs] [Times: user=2.79 sys=0.00, real=2.79 secs] 62583.179: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8641470 secs] [Times: user=2.82 sys=0.00, real=2.86 secs] 62586.044: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8421364 secs] [Times: user=2.84 sys=0.00, real=2.84 secs] 62588.887: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8852699 secs] [Times: user=2.89 sys=0.00, real=2.89 secs] 62591.773: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9164279 secs] [Times: user=2.90 sys=0.00, real=2.92 secs] 62594.690: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9450010 secs] [Times: user=2.95 sys=0.00, real=2.95 secs] 62597.636: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9744636 secs] [Times: user=2.98 sys=0.00, real=2.98 secs] 62600.611: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9900849 secs] [Times: user=2.99 sys=0.00, real=3.00 secs] 62603.602: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.6332370 secs] [Times: user=2.62 sys=0.00, real=2.62 secs] 62606.236: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9801260 secs] [Times: user=2.95 sys=0.00, real=2.98 secs] 62609.226: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9166374 secs] [Times: user=2.89 sys=0.00, real=2.92 secs] 62612.150: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9475729 secs] [Times: user=2.95 sys=0.00, real=2.95 secs] 62615.098: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9328670 secs] [Times: user=2.90 sys=0.00, real=2.93 secs] 62618.040: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8963825 secs] [Times: user=2.89 sys=0.00, real=2.90 secs] 62620.937: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8834715 secs] [Times: user=2.89 sys=0.00, real=2.89 secs] 62623.821: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8800691 secs] [Times: user=2.86 sys=0.00, real=2.87 secs] 62626.701: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683677K(699072K)] 781918K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8642587 secs] [Times: user=2.87 sys=0.00, real=2.87 secs] 62629.566: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8574615 secs] [Times: user=2.84 sys=0.00, real=2.86 secs] 62632.424: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8383412 secs] [Times: user=2.84 sys=0.00, real=2.84 secs] 62635.264: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8409891 secs] [Times: user=2.82 sys=0.00, real=2.84 secs] 62638.106: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.7906216 secs] [Times: user=2.79 sys=0.00, real=2.79 secs] 62640.898: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.7891730 secs] [Times: user=2.79 sys=0.00, real=2.79 secs] 62643.688: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.7892940 secs] [Times: user=2.79 sys=0.00, real=2.79 secs] 62646.479: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.7766807 secs] [Times: user=2.78 sys=0.00, real=2.78 secs] 62649.257: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.7796531 secs] [Times: user=2.78 sys=0.00, real=2.78 secs] 62652.037: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.7687240 secs] [Times: user=2.76 sys=0.00, real=2.76 secs] 62654.807: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.7613769 secs] [Times: user=2.76 sys=0.00, real=2.76 secs] 62657.570: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.7712254 secs] [Times: user=2.78 sys=0.00, real=2.78 secs] 62660.342: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.7968108 secs] [Times: user=2.79 sys=0.00, real=2.79 secs] 62663.139: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.7924173 secs] [Times: user=2.79 sys=0.00, real=2.79 secs] 62665.933: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8002912 secs] [Times: user=2.79 sys=0.00, real=2.81 secs] 62668.736: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8291434 secs] [Times: user=2.82 sys=0.00, real=2.82 secs] 62671.566: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8527186 secs] [Times: user=2.86 sys=0.00, real=2.85 secs] 62674.419: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8982825 secs] [Times: user=2.90 sys=0.00, real=2.90 secs] 62677.318: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9254483 secs] [Times: user=2.93 sys=0.00, real=2.93 secs] 62680.244: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9707015 secs] [Times: user=2.95 sys=0.00, real=2.96 secs] 62683.216: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9894145 secs] [Times: user=3.00 sys=0.00, real=3.00 secs] 62686.206: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9870305 secs] [Times: user=2.98 sys=0.00, real=2.98 secs] 62689.193: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9884647 secs] [Times: user=2.98 sys=0.00, real=3.00 secs] 62692.183: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9635276 secs] [Times: user=2.96 sys=0.00, real=2.96 secs] 62695.147: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9407559 secs] [Times: user=2.93 sys=0.00, real=2.93 secs] 62698.088: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9299386 secs] [Times: user=2.93 sys=0.00, real=2.93 secs] 62701.019: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8994903 secs] [Times: user=2.90 sys=0.00, real=2.90 secs] 62703.919: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9163417 secs] [Times: user=2.92 sys=0.00, real=2.92 secs] 62706.836: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9216473 secs] [Times: user=2.93 sys=0.00, real=2.93 secs] 62709.758: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.9052547 secs] [Times: user=2.89 sys=0.00, real=2.90 secs] 62712.664: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8902824 secs] [Times: user=2.85 sys=0.00, real=2.89 secs] 62715.555: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8865932 secs] [Times: user=2.87 sys=0.00, real=2.89 secs] 62718.442: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8605445 secs] [Times: user=2.87 sys=0.00, real=2.87 secs] 62721.304: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8662771 secs] [Times: user=2.84 sys=0.00, real=2.86 secs] 62724.171: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: 683679K->683679K(699072K)] 781919K->781919K(913792K) [PSPermGen: 49694K->49694K(49984K)], 2.8369076 secs] [Times: user=2.84 sys=0.00, real=2.84 secs] -- Cheers, David Nuix Pty Ltd Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 0699 Web: http://www.nuix.com Fax: +61 2 9212 6902 From martinrb at google.com Tue Feb 24 18:22:49 2009 From: martinrb at google.com (Martin Buchholz) Date: Tue, 24 Feb 2009 18:22:49 -0800 Subject: [Fwd: Re: Unicode support in Java JRE on Windows] In-Reply-To: <49A4A4E2.7010503@Sun.COM> References: <49A4997E.9030900@sun.com> <49A4A4E2.7010503@Sun.COM> Message-ID: <1ccfd1c10902241822w39ccced3y62cdd12d89c22516@mail.gmail.com> Part of the history here is that the JDK used to continue supporting windows 98 for many years, longer than Microsoft itself! With that support having been dropped, it is much easier to make changes like this (switch from "A" to "W" interfaces consistently) but it's hard to find the enthusiasm. Fighting with the win32 API is no fun. Many distinct jdk teams own affected interfaces, making a thorough fix organizationally difficult. Martin On Tue, Feb 24, 2009 at 17:54, Naoto Sato wrote: > 4519026: (process) Process should support Unicode on Win NT > > This is a long standing known limitation, which has never been addressed > because it would require fairly big effort. > > Thanks, > Naoto > >> Subject: Re: Unicode support in Java JRE on Windows >> Date: Mon, 23 Feb 2009 16:14:11 -0500 >> From: Karen Kinnear >> To: Heiko Wagner >> CC: hotspot-dev at openjdk.java.net, core-libs-dev at openjdk.java.net >> References: >> >> Heiko, >> >> I'm copying this to the core-libs-dev at openjdk.java.net alias, since >> I think the APIs you are referring to are more familiar to that team. >> And I've retitled it "Java JRE" so folks see the bigger picture. >> >> hope this helps, >> Karen >> >> Heiko Wagner wrote: >>> >>> Hi, >>> >>> I am currently investigating on a problem of the Java VM on Windows. The >>> VM >>> is started using the JNI invocation api. This works unless the path >>> contains >>> non-ansi characters. So I hacked the classpath with >>> addURLToAppClassLoader() >>> in sun.misc.Launcher. I at least could make a shared JRE installation, >>> started from a ansi path, find my JARs. Since one of my JARs does use >>> native >>> code I then got stuck at the System.loadLibrary() call. Hacking the >>> correct >>> path into the 'usr_paths' field into the ClassLoader did not help, >>> because >>> the actual Windows API call LoadLibrary() seems to be ansi flavour >>> instead >>> of wide char api. Would it be possible to make this two enhancements >>> without >>> hurting the Java VM spec?: >>> >>> 1) fill the property java.class.path from the env variable CLASSPATH with >>> a >>> call to GetEnvironmentVariableW instead of GetEnvironmentVariableA to >>> enable >>> setting the classpath with unicode characters >>> >>> 2) fill the property java.library.path and issue the actual LoadLibrary >>> with >>> appropriate wide char api >>> >>>> From a quick look at the VM source I found out, that most string >>>> operations >>> >>> use the ANSI C string functions. >>> Maybe it would be possible to use UTF-8 encoding to transfer the path >>> strings throu the Java VM routines to the final Windows API calls, to >>> avoid >>> large changes in the code base. >>> >>> Regards >>> Heiko Wagner >>> >> > > > -- > Naoto Sato > From Jon.Masamitsu at Sun.COM Tue Feb 24 22:00:03 2009 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Tue, 24 Feb 2009 22:00:03 -0800 Subject: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application In-Reply-To: <49A48B14.8070307@nuix.com> References: <499CA7D9.9040903@nuix.com> <4E0D3F42-021A-4D48-888E-594A5980D0E1@sun.com> <49A33600.7000004@nuix.com> <49A3454A.4010507@nuix.com> <49A34B69.2000608@sun.com> <49A34DF2.2010800@sun.com> <49A48B14.8070307@nuix.com> Message-ID: <49A4DE63.5030704@sun.com> David, Can you also send a GC log from a run where there is not a problem? As I understand it, that would be a 32bit run. Jon David Sitsky wrote On 02/24/09 16:04,: >Jon Masamitsu wrote: > > >>Jon Masamitsu wrote On 02/23/09 17:20,: >> >> >> >>>... >>> >>>Increase the heap by 30%. Also increase the the perm gen size >>>(-XX:MaxPermSize=). >>> >>>Please use -XX:+PrintGCDetails -XX:+PrintGCTimeStamps when gathering the >>>GC logs. >>>If you've already gathering some, send those but in future runs, use the >>>above. >>> >>> > >Here is a sample of output from a stuck process. You can see its doing >a full GC about every 3 seconds, and it seems as if there is little >progress.. > >Please let me know if you need more information. > >Cheers, >David > >62402.320: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8063178 secs] [Times: user=2.81 sys=0.00, >real=2.81 secs] >62405.128: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8029997 secs] [Times: user=2.79 sys=0.00, >real=2.81 secs] >62407.932: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.7917325 secs] [Times: user=2.79 sys=0.00, >real=2.79 secs] >62410.725: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.7891387 secs] [Times: user=2.79 sys=0.00, >real=2.79 secs] >62413.515: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.7649110 secs] [Times: user=2.76 sys=0.00, >real=2.76 secs] >62416.281: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.7803983 secs] [Times: user=2.78 sys=0.00, >real=2.78 secs] >62419.063: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.7643979 secs] [Times: user=2.76 sys=0.00, >real=2.76 secs] >62421.828: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8114336 secs] [Times: user=2.81 sys=0.00, >real=2.81 secs] >62424.640: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.7964912 secs] [Times: user=2.79 sys=0.00, >real=2.79 secs] >62427.438: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8107278 secs] [Times: user=2.81 sys=0.00, >real=2.81 secs] >62430.249: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >49694K->49694K(49984K)], 3.2345212 secs] [Times: user=2.84 sys=0.00, >real=3.24 secs] >62433.484: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8341520 secs] [Times: user=2.82 sys=0.00, >real=2.82 secs] >62436.319: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8698768 secs] [Times: user=2.87 sys=0.00, >real=2.87 secs] >62439.190: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9323230 secs] [Times: user=2.90 sys=0.00, >real=2.92 secs] >62442.124: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9644960 secs] [Times: user=2.96 sys=0.00, >real=2.96 secs] >62445.089: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >49694K->49694K(49984K)], 3.0059221 secs] [Times: user=3.00 sys=0.00, >real=3.00 secs] >62448.095: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9832815 secs] [Times: user=3.00 sys=0.00, >real=2.99 secs] >62451.079: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9587156 secs] [Times: user=2.93 sys=0.00, >real=2.95 secs] >62454.039: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9488345 secs] [Times: user=2.92 sys=0.00, >real=2.95 secs] >62456.988: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8969788 secs] [Times: user=2.90 sys=0.00, >real=2.90 secs] >62459.886: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8794991 secs] [Times: user=2.89 sys=0.00, >real=2.89 secs] >62462.766: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8842411 secs] [Times: user=2.87 sys=0.00, >real=2.89 secs] >62465.651: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683675K(699072K)] 781916K->781915K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8669173 secs] [Times: user=2.85 sys=0.00, >real=2.85 secs] >62468.519: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8664429 secs] [Times: user=2.85 sys=0.00, >real=2.86 secs] >62471.386: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8844494 secs] [Times: user=2.87 sys=0.00, >real=2.89 secs] >62474.271: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8648398 secs] [Times: user=2.87 sys=0.00, >real=2.87 secs] >62477.137: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8971068 secs] [Times: user=2.87 sys=0.00, >real=2.90 secs] >62480.034: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8655618 secs] [Times: user=2.86 sys=0.00, >real=2.86 secs] >62482.901: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 3.0366140 secs] [Times: user=2.78 sys=0.00, >real=3.04 secs] >62485.939: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8541753 secs] [Times: user=2.85 sys=0.00, >real=2.85 secs] >62488.794: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8582816 secs] [Times: user=2.86 sys=0.00, >real=2.86 secs] >62491.653: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8673218 secs] [Times: user=2.85 sys=0.00, >real=2.86 secs] >62494.521: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9014120 secs] [Times: user=2.87 sys=0.00, >real=2.90 secs] >62497.424: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8805843 secs] [Times: user=2.89 sys=0.00, >real=2.89 secs] >62500.305: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8905128 secs] [Times: user=2.89 sys=0.00, >real=2.89 secs] >62503.196: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9052007 secs] [Times: user=2.90 sys=0.00, >real=2.92 secs] >62506.102: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9004575 secs] [Times: user=2.89 sys=0.00, >real=2.90 secs] >62509.003: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9160655 secs] [Times: user=2.90 sys=0.00, >real=2.92 secs] >62511.920: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9013277 secs] [Times: user=2.90 sys=0.00, >real=2.90 secs] >62514.822: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8982061 secs] [Times: user=2.89 sys=0.00, >real=2.89 secs] >62517.721: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8922437 secs] [Times: user=2.89 sys=0.00, >real=2.89 secs] >62520.614: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8873520 secs] [Times: user=2.87 sys=0.00, >real=2.89 secs] >62523.502: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8805296 secs] [Times: user=2.89 sys=0.00, >real=2.89 secs] >62526.383: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8958714 secs] [Times: user=2.85 sys=0.00, >real=2.89 secs] >62529.279: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8735384 secs] [Times: user=2.89 sys=0.00, >real=2.89 secs] >62532.154: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8705676 secs] [Times: user=2.87 sys=0.00, >real=2.87 secs] >62535.025: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8723947 secs] [Times: user=2.85 sys=0.00, >real=2.87 secs] >62537.898: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8624400 secs] [Times: user=2.86 sys=0.00, >real=2.86 secs] >62540.761: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8245748 secs] [Times: user=2.84 sys=0.00, >real=2.84 secs] >62543.587: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8432269 secs] [Times: user=2.84 sys=0.00, >real=2.84 secs] >62546.432: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8394157 secs] [Times: user=2.84 sys=0.00, >real=2.84 secs] >62549.272: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8471951 secs] [Times: user=2.85 sys=0.00, >real=2.85 secs] >62552.121: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8584107 secs] [Times: user=2.85 sys=0.00, >real=2.86 secs] >62554.981: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8376807 secs] [Times: user=2.84 sys=0.00, >real=2.84 secs] >62557.820: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8402486 secs] [Times: user=2.84 sys=0.00, >real=2.84 secs] >62560.661: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8482704 secs] [Times: user=2.86 sys=0.00, >real=2.85 secs] >62563.511: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8115973 secs] [Times: user=2.81 sys=0.00, >real=2.81 secs] >62566.324: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8523278 secs] [Times: user=2.85 sys=0.00, >real=2.86 secs] >62569.177: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8128563 secs] [Times: user=2.81 sys=0.00, >real=2.81 secs] >62571.990: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.7830644 secs] [Times: user=2.79 sys=0.00, >real=2.79 secs] >62574.774: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8065106 secs] [Times: user=2.79 sys=0.00, >real=2.81 secs] >62577.582: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.7892171 secs] [Times: user=2.79 sys=0.00, >real=2.79 secs] >62580.372: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8059306 secs] [Times: user=2.79 sys=0.00, >real=2.79 secs] >62583.179: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8641470 secs] [Times: user=2.82 sys=0.00, >real=2.86 secs] >62586.044: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8421364 secs] [Times: user=2.84 sys=0.00, >real=2.84 secs] >62588.887: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8852699 secs] [Times: user=2.89 sys=0.00, >real=2.89 secs] >62591.773: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9164279 secs] [Times: user=2.90 sys=0.00, >real=2.92 secs] >62594.690: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9450010 secs] [Times: user=2.95 sys=0.00, >real=2.95 secs] >62597.636: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9744636 secs] [Times: user=2.98 sys=0.00, >real=2.98 secs] >62600.611: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9900849 secs] [Times: user=2.99 sys=0.00, >real=3.00 secs] >62603.602: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.6332370 secs] [Times: user=2.62 sys=0.00, >real=2.62 secs] >62606.236: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9801260 secs] [Times: user=2.95 sys=0.00, >real=2.98 secs] >62609.226: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9166374 secs] [Times: user=2.89 sys=0.00, >real=2.92 secs] >62612.150: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9475729 secs] [Times: user=2.95 sys=0.00, >real=2.95 secs] >62615.098: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9328670 secs] [Times: user=2.90 sys=0.00, >real=2.93 secs] >62618.040: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8963825 secs] [Times: user=2.89 sys=0.00, >real=2.90 secs] >62620.937: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8834715 secs] [Times: user=2.89 sys=0.00, >real=2.89 secs] >62623.821: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8800691 secs] [Times: user=2.86 sys=0.00, >real=2.87 secs] >62626.701: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683677K(699072K)] 781918K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8642587 secs] [Times: user=2.87 sys=0.00, >real=2.87 secs] >62629.566: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8574615 secs] [Times: user=2.84 sys=0.00, >real=2.86 secs] >62632.424: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8383412 secs] [Times: user=2.84 sys=0.00, >real=2.84 secs] >62635.264: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8409891 secs] [Times: user=2.82 sys=0.00, >real=2.84 secs] >62638.106: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.7906216 secs] [Times: user=2.79 sys=0.00, >real=2.79 secs] >62640.898: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.7891730 secs] [Times: user=2.79 sys=0.00, >real=2.79 secs] >62643.688: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.7892940 secs] [Times: user=2.79 sys=0.00, >real=2.79 secs] >62646.479: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.7766807 secs] [Times: user=2.78 sys=0.00, >real=2.78 secs] >62649.257: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.7796531 secs] [Times: user=2.78 sys=0.00, >real=2.78 secs] >62652.037: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.7687240 secs] [Times: user=2.76 sys=0.00, >real=2.76 secs] >62654.807: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.7613769 secs] [Times: user=2.76 sys=0.00, >real=2.76 secs] >62657.570: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.7712254 secs] [Times: user=2.78 sys=0.00, >real=2.78 secs] >62660.342: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.7968108 secs] [Times: user=2.79 sys=0.00, >real=2.79 secs] >62663.139: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.7924173 secs] [Times: user=2.79 sys=0.00, >real=2.79 secs] >62665.933: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8002912 secs] [Times: user=2.79 sys=0.00, >real=2.81 secs] >62668.736: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8291434 secs] [Times: user=2.82 sys=0.00, >real=2.82 secs] >62671.566: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8527186 secs] [Times: user=2.86 sys=0.00, >real=2.85 secs] >62674.419: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8982825 secs] [Times: user=2.90 sys=0.00, >real=2.90 secs] >62677.318: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9254483 secs] [Times: user=2.93 sys=0.00, >real=2.93 secs] >62680.244: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9707015 secs] [Times: user=2.95 sys=0.00, >real=2.96 secs] >62683.216: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9894145 secs] [Times: user=3.00 sys=0.00, >real=3.00 secs] >62686.206: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9870305 secs] [Times: user=2.98 sys=0.00, >real=2.98 secs] >62689.193: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9884647 secs] [Times: user=2.98 sys=0.00, >real=3.00 secs] >62692.183: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9635276 secs] [Times: user=2.96 sys=0.00, >real=2.96 secs] >62695.147: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9407559 secs] [Times: user=2.93 sys=0.00, >real=2.93 secs] >62698.088: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9299386 secs] [Times: user=2.93 sys=0.00, >real=2.93 secs] >62701.019: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8994903 secs] [Times: user=2.90 sys=0.00, >real=2.90 secs] >62703.919: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9163417 secs] [Times: user=2.92 sys=0.00, >real=2.92 secs] >62706.836: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9216473 secs] [Times: user=2.93 sys=0.00, >real=2.93 secs] >62709.758: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.9052547 secs] [Times: user=2.89 sys=0.00, >real=2.90 secs] >62712.664: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8902824 secs] [Times: user=2.85 sys=0.00, >real=2.89 secs] >62715.555: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8865932 secs] [Times: user=2.87 sys=0.00, >real=2.89 secs] >62718.442: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8605445 secs] [Times: user=2.87 sys=0.00, >real=2.87 secs] >62721.304: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8662771 secs] [Times: user=2.84 sys=0.00, >real=2.86 secs] >62724.171: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >683679K->683679K(699072K)] 781919K->781919K(913792K) [PSPermGen: >49694K->49694K(49984K)], 2.8369076 secs] [Times: user=2.84 sys=0.00, >real=2.84 secs] > > > From sits at nuix.com Tue Feb 24 22:19:20 2009 From: sits at nuix.com (David Sitsky) Date: Wed, 25 Feb 2009 17:19:20 +1100 Subject: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application In-Reply-To: <49A4DE63.5030704@sun.com> References: <499CA7D9.9040903@nuix.com> <4E0D3F42-021A-4D48-888E-594A5980D0E1@sun.com> <49A33600.7000004@nuix.com> <49A3454A.4010507@nuix.com> <49A34B69.2000608@sun.com> <49A34DF2.2010800@sun.com> <49A48B14.8070307@nuix.com> <49A4DE63.5030704@sun.com> Message-ID: <49A4E2E8.9020405@nuix.com> I am doing a 64-bit run now, where I set -Xmx to 1300m rather than 1024m, and set MaxPermGen to 200M rather than the default. Things look much better already, but I'd like to let it run overnight before being sure all is well. I'll send another update tomorrow morning, but things look much better. Here is the last bit from the GC logs: 11313.578: [GC [PSYoungGen: 364993K->33709K(389120K)] 1188848K->857564K(1276608K), 0.0349691 secs] [Times: user=0.05 sys=0.00, real=0.03 secs] 11314.289: [GC [PSYoungGen: 374125K->50984K(391424K)] 1197980K->874935K(1278912K), 0.0561384 secs] [Times: user=0.19 sys=0.00, real=0.05 secs] 11315.420: [GC-- [PSYoungGen: 391400K->391400K(391424K)] 1215351K->1278883K(1278912K), 0.6189272 secs] [Times: user=0.80 sys=0.94, real=0.62 secs] 11316.039: [Full GC [PSYoungGen: 391400K->0K(391424K)] [PSOldGen: 887483K->618360K(887488K)] 1278883K->618360K(1278912K) [PSPermGen: 50266K->50266K(50752K)], 1.8320395 secs] [Times: user=1.83 sys=0.00, real=1.83 secs] 11318.491: [GC [PSYoungGen: 340416K->3744K(377856K)] 958776K->622104K(1265344K), 0.0092145 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 11319.059: [GC [PSYoungGen: 329312K->7424K(384640K)] 947672K->625784K(1272128K), 0.0188922 secs] [Times: user=0.05 sys=0.00, real=0.03 secs] 11319.653: [GC [PSYoungGen: 332992K->11104K(379200K)] 951352K->629464K(1266688K), 0.0087598 secs] [Times: user=0.03 sys=0.00, real=0.02 secs] 11320.937: [GC [PSYoungGen: 337888K->15025K(382528K)] 956248K->633385K(1270016K), 0.0283276 secs] [Times: user=0.03 sys=0.00, real=0.03 secs] 11322.676: [GC [PSYoungGen: 341809K->25602K(385408K)] 960169K->643962K(1272896K), 0.0335247 secs] [Times: user=0.06 sys=0.00, real=0.03 secs] 11323.404: [GC [PSYoungGen: 360642K->39323K(386944K)] 979002K->657683K(1274432K), 0.0363427 secs] [Times: user=0.12 sys=0.00, real=0.03 secs] 11330.091: [GC [PSYoungGen: 374363K->51064K(372928K)] 992723K->669424K(1260416K), 0.0981955 secs] [Times: user=0.09 sys=0.01, real=0.11 secs] 11334.309: [GC [PSYoungGen: 368056K->18156K(380352K)] 986416K->644283K(1267840K), 0.0465189 secs] [Times: user=0.03 sys=0.00, real=0.05 secs] 11340.519: [GC [PSYoungGen: 335148K->21564K(371200K)] 961275K->653271K(1258688K), 0.0342244 secs] [Times: user=0.06 sys=0.00, real=0.03 secs] 11371.331: [GC [PSYoungGen: 341308K->27445K(377152K)] 973015K->659151K(1264640K), 0.0363716 secs] [Times: user=0.03 sys=0.00, real=0.03 secs] 11410.448: [GC [PSYoungGen: 347189K->39966K(382848K)] 978895K->671672K(1270336K), 0.0486682 secs] [Times: user=0.06 sys=0.00, real=0.05 secs] 11448.664: [GC [PSYoungGen: 367454K->52103K(379648K)] 999160K->683810K(1267136K), 0.0573727 secs] [Times: user=0.11 sys=0.00, real=0.06 secs] 11486.981: [GC [PSYoungGen: 379591K->62465K(360576K)] 1011298K->694172K(1248064K), 0.0588064 secs] [Times: user=0.08 sys=0.00, real=0.05 secs] 11525.279: [GC [PSYoungGen: 358977K->73574K(370112K)] 990684K->705681K(1257600K), 0.0749627 secs] [Times: user=0.08 sys=0.00, real=0.06 secs] 11561.256: [GC [PSYoungGen: 370086K->73568K(322752K)] 1002193K->714370K(1210240K), 0.0797409 secs] [Times: user=0.11 sys=0.00, real=0.08 secs] 11588.447: [GC [PSYoungGen: 322720K->81599K(330752K)] 963522K->724332K(1218240K), 0.0694797 secs] [Times: user=0.11 sys=0.00, real=0.06 secs] 11621.230: [GC [PSYoungGen: 330751K->89408K(316224K)] 973484K->732141K(1203712K), 0.0618009 secs] [Times: user=0.20 sys=0.00, real=0.06 secs] 11648.851: [GC [PSYoungGen: 298880K->94931K(304448K)] 941613K->737664K(1191936K), 0.0845136 secs] [Times: user=0.17 sys=0.00, real=0.08 secs] 11683.046: [GC [PSYoungGen: 304403K->100613K(296512K)] 947136K->743346K(1184000K), 0.0694421 secs] [Times: user=0.23 sys=0.00, real=0.06 secs] 11711.063: [GC [PSYoungGen: 269893K->105281K(274624K)] 912626K->748014K(1162112K), 0.0714455 secs] [Times: user=0.22 sys=0.00, real=0.06 secs] 11733.698: [GC [PSYoungGen: 274561K->110528K(294592K)] 917294K->753261K(1182080K), 0.0749614 secs] [Times: user=0.23 sys=0.00, real=0.08 secs] 11756.761: [GC [PSYoungGen: 258432K->111207K(295808K)] 901165K->757037K(1183296K), 0.0724225 secs] [Times: user=0.23 sys=0.02, real=0.08 secs] 11778.512: [GC [PSYoungGen: 259111K->91382K(295808K)] 904941K->757823K(1183296K), 0.0654707 secs] [Times: user=0.26 sys=0.00, real=0.08 secs] 11793.092: [GC [PSYoungGen: 239286K->72962K(295808K)] 905727K->760647K(1183296K), 0.0600261 secs] [Times: user=0.16 sys=0.00, real=0.06 secs] 11813.452: [GC [PSYoungGen: 220866K->57620K(295040K)] 908551K->763749K(1182528K), 0.1455811 secs] [Times: user=0.11 sys=0.00, real=0.14 secs] 11829.488: [GC [PSYoungGen: 205524K->61773K(209728K)] 911653K->767902K(1097216K), 0.0425208 secs] [Times: user=0.14 sys=0.00, real=0.05 secs] 11840.928: [GC [PSYoungGen: 209677K->65692K(284480K)] 915806K->771821K(1171968K), 0.0694456 secs] [Times: user=0.16 sys=0.00, real=0.08 secs] 11842.649: [GC [PSYoungGen: 217628K->69783K(287680K)] 923757K->775913K(1175168K), 0.0566314 secs] [Times: user=0.13 sys=0.00, real=0.05 secs] 11847.187: [GC [PSYoungGen: 221719K->69786K(278272K)] 927849K->775915K(1165760K), 0.0484082 secs] [Times: user=0.13 sys=0.00, real=0.05 secs] 11851.564: [GC [PSYoungGen: 230362K->70502K(284224K)] 936491K->776632K(1171712K), 0.0523338 secs] [Times: user=0.16 sys=0.00, real=0.06 secs] 11854.192: [GC [PSYoungGen: 231078K->62490K(284096K)] 937208K->775899K(1171584K), 0.0575282 secs] [Times: user=0.12 sys=0.00, real=0.05 secs] 11857.563: [GC [PSYoungGen: 233690K->58020K(286144K)] 947099K->778109K(1173632K), 0.1305652 secs] [Times: user=0.08 sys=0.00, real=0.13 secs] 11861.968: [GC [PSYoungGen: 229220K->51990K(293568K)] 949309K->777585K(1181056K), 0.0625429 secs] [Times: user=0.09 sys=0.00, real=0.06 secs] 11865.344: [GC [PSYoungGen: 236758K->48739K(295680K)] 962353K->779600K(1183168K), 0.0652676 secs] [Times: user=0.09 sys=0.00, real=0.06 secs] 11865.764: [GC [PSYoungGen: 233507K->64759K(313408K)] 964368K->800519K(1200896K), 0.0783293 secs] [Times: user=0.17 sys=0.00, real=0.08 secs] 11866.155: [GC [PSYoungGen: 268599K->56226K(309056K)] 1004359K->800886K(1196544K), 0.0556912 secs] [Times: user=0.14 sys=0.00, real=0.05 secs] 11866.564: [GC [PSYoungGen: 260066K->48994K(332928K)] 1004726K->801264K(1220416K), 0.0981246 secs] [Times: user=0.09 sys=0.00, real=0.09 secs] 11867.462: [GC [PSYoungGen: 279202K->41223K(331648K)] 1031472K->801219K(1219136K), 0.0917128 secs] [Times: user=0.13 sys=0.00, real=0.09 secs] 11868.182: [GC [PSYoungGen: 271431K->36265K(340672K)] 1031427K->799645K(1228160K), 0.0501109 secs] [Times: user=0.14 sys=0.00, real=0.06 secs] 11868.587: [GC [PSYoungGen: 275753K->32206K(340736K)] 1039133K->798457K(1228224K), 0.0378368 secs] [Times: user=0.19 sys=0.00, real=0.05 secs] 11869.019: [GC [PSYoungGen: 271694K->31433K(341632K)] 1037945K->799542K(1229120K), 0.0411616 secs] [Times: user=0.09 sys=0.00, real=0.05 secs] 11870.862: [GC [PSYoungGen: 272585K->30761K(342016K)] 1040694K->801733K(1229504K), 0.0781323 secs] [Times: user=0.09 sys=0.00, real=0.08 secs] 11874.853: [GC [PSYoungGen: 271913K->6525K(338560K)] 1042885K->777505K(1226048K), 0.0278125 secs] [Times: user=0.01 sys=0.00, real=0.03 secs] 11876.975: [GC [PSYoungGen: 245181K->6580K(245248K)] 1016161K->777600K(1132736K), 0.0268619 secs] [Times: user=0.02 sys=0.00, real=0.03 secs] 11882.627: [GC [PSYoungGen: 245236K->9706K(340608K)] 1016256K->780741K(1228096K), 0.0366189 secs] [Times: user=0.03 sys=0.00, real=0.05 secs] 11887.944: [GC [PSYoungGen: 246634K->12331K(249280K)] 1017669K->783796K(1136768K), 0.0265703 secs] [Times: user=0.05 sys=0.00, real=0.03 secs] 11892.216: [GC [PSYoungGen: 249259K->10949K(340416K)] 1020724K->784370K(1227904K), 0.0265194 secs] [Times: user=0.06 sys=0.00, real=0.03 secs] 11898.521: [GC [PSYoungGen: 250053K->13116K(338240K)] 1023474K->786536K(1225728K), 0.0402077 secs] [Times: user=0.08 sys=0.00, real=0.05 secs] 11900.503: [GC [PSYoungGen: 252220K->12023K(341504K)] 1025640K->785443K(1228992K), 0.0220321 secs] [Times: user=0.05 sys=0.00, real=0.03 secs] 11901.476: [GC [PSYoungGen: 178540K->13179K(339456K)] 951960K->786599K(1226944K), 0.0296537 secs] [Times: user=0.00 sys=0.00, real=0.03 secs] 11903.630: [GC [PSYoungGen: 259515K->13652K(346880K)] 1032935K->787073K(1234368K), 0.0456301 secs] [Times: user=0.01 sys=0.00, real=0.05 secs] 11905.259: [GC [PSYoungGen: 272788K->14625K(345088K)] 1046209K->788045K(1232576K), 0.0240913 secs] [Times: user=0.06 sys=0.00, real=0.03 secs] 11907.041: [GC [PSYoungGen: 273761K->18120K(353344K)] 1047181K->791540K(1240832K), 0.0195635 secs] [Times: user=0.06 sys=0.00, real=0.03 secs] 11908.356: [GC [PSYoungGen: 292552K->20112K(352128K)] 1065972K->793532K(1239616K), 0.0301132 secs] [Times: user=0.05 sys=0.00, real=0.03 secs] 11911.109: [GC [PSYoungGen: 294544K->27881K(362432K)] 1067964K->801301K(1249920K), 0.0269477 secs] [Times: user=0.06 sys=0.00, real=0.03 secs] 11917.829: [GC [PSYoungGen: 318569K->29749K(360320K)] 1091989K->803169K(1247808K), 0.0304822 secs] [Times: user=0.06 sys=0.00, real=0.03 secs] 11921.244: [GC [PSYoungGen: 320437K->33044K(370560K)] 1093857K->806465K(1258048K), 0.0380831 secs] [Times: user=0.05 sys=0.00, real=0.03 secs] 11929.343: [GC [PSYoungGen: 336596K->31440K(369344K)] 1110017K->804860K(1256832K), 0.0303735 secs] [Times: user=0.06 sys=0.00, real=0.03 secs] 11930.926: [GC [PSYoungGen: 334992K->29112K(375168K)] 1108412K->802533K(1262656K), 0.0362781 secs] [Times: user=0.13 sys=0.00, real=0.05 secs] 11938.038: [GC [PSYoungGen: 342776K->30034K(374720K)] 1116197K->805172K(1262208K), 0.0344521 secs] [Times: user=0.13 sys=0.00, real=0.05 secs] 11942.977: [GC [PSYoungGen: 343698K->30400K(380736K)] 1118836K->806920K(1268224K), 0.0291603 secs] [Times: user=0.08 sys=0.01, real=0.03 secs] 11946.432: [GC [PSYoungGen: 353472K->33984K(379968K)] 1129992K->812395K(1267456K), 0.0286985 secs] [Times: user=0.09 sys=0.00, real=0.03 secs] 11947.686: [GC [PSYoungGen: 357056K->33120K(385856K)] 1135467K->812685K(1273344K), 0.0290596 secs] [Times: user=0.06 sys=0.05, real=0.03 secs] 11950.300: [GC [PSYoungGen: 363232K->36768K(385536K)] 1142797K->817668K(1273024K), 0.0366832 secs] [Times: user=0.13 sys=0.00, real=0.05 secs] 11951.435: [GC [PSYoungGen: 366880K->35568K(387968K)] 1147780K->817763K(1275456K), 0.0323035 secs] [Times: user=0.09 sys=0.00, real=0.03 secs] 11955.819: [GC [PSYoungGen: 368112K->42132K(374720K)] 1150307K->824516K(1262208K), 0.0582372 secs] [Times: user=0.09 sys=0.00, real=0.06 secs] 11960.127: [GC [PSYoungGen: 374676K->39262K(385600K)] 1157060K->823945K(1273088K), 0.0382100 secs] [Times: user=0.13 sys=0.00, real=0.05 secs] 11965.304: [GC [PSYoungGen: 367518K->37723K(366016K)] 1152201K->826247K(1253504K), 0.0402685 secs] [Times: user=0.13 sys=0.00, real=0.05 secs] 11970.348: [GC [PSYoungGen: 365979K->38700K(386048K)] 1154503K->828528K(1273536K), 0.0363140 secs] [Times: user=0.06 sys=0.00, real=0.03 secs] 11975.174: [GC [PSYoungGen: 367532K->42372K(371264K)] 1157360K->833840K(1258752K), 0.0475132 secs] [Times: user=0.08 sys=0.00, real=0.05 secs] 11982.275: [GC [PSYoungGen: 371204K->46658K(381184K)] 1162672K->839441K(1268672K), 0.0512600 secs] [Times: user=0.05 sys=0.00, real=0.05 secs] 11983.858: [GC [PSYoungGen: 369794K->37237K(383424K)] 1162577K->831565K(1270912K), 0.0333564 secs] [Times: user=0.06 sys=0.00, real=0.03 secs] 11986.367: [GC [PSYoungGen: 360373K->40329K(381952K)] 1154701K->836977K(1269440K), 0.0380363 secs] [Times: user=0.11 sys=0.00, real=0.05 secs] 11987.312: [GC [PSYoungGen: 365257K->43968K(382912K)] 1161905K->840740K(1270400K), 0.0465223 secs] [Times: user=0.09 sys=0.00, real=0.05 secs] 11990.187: [GC [PSYoungGen: 368896K->42089K(385216K)] 1165668K->843282K(1272704K), 0.0759708 secs] [Times: user=0.08 sys=0.00, real=0.08 secs] 11993.893: [GC [PSYoungGen: 368617K->42846K(369408K)] 1169810K->846423K(1256896K), 0.0547113 secs] [Times: user=0.05 sys=0.00, real=0.05 secs] 11998.538: [GC [PSYoungGen: 369374K->44138K(384640K)] 1172951K->850832K(1272128K), 0.0425213 secs] [Times: user=0.05 sys=0.00, real=0.03 secs] 12002.205: [GC [PSYoungGen: 370410K->43699K(384896K)] 1177104K->852795K(1272384K), 0.2005315 secs] [Times: user=0.06 sys=0.00, real=0.19 secs] 12008.992: [GC [PSYoungGen: 369971K->42770K(383872K)] 1179067K->853973K(1271360K), 0.0378665 secs] [Times: user=0.08 sys=0.00, real=0.03 secs] 12013.427: [GC [PSYoungGen: 369298K->38177K(384512K)] 1180501K->852090K(1272000K), 0.0432763 secs] [Times: user=0.06 sys=0.00, real=0.05 secs] 12018.994: [GC [PSYoungGen: 364705K->39371K(383424K)] 1178618K->855239K(1270912K), 0.0339062 secs] [Times: user=0.08 sys=0.00, real=0.03 secs] 12023.966: [GC [PSYoungGen: 368779K->37609K(384064K)] 1184647K->855038K(1271552K), 0.0335413 secs] [Times: user=0.05 sys=0.00, real=0.03 secs] 12027.236: [GC [PSYoungGen: 367017K->40065K(387456K)] 1184446K->859404K(1274944K), 0.0422529 secs] [Times: user=0.11 sys=0.00, real=0.05 secs] Jon Masamitsu wrote: > David, > > Can you also send a GC log from a run where there > is not a problem? As I understand it, that would > be a 32bit run. > > Jon > > David Sitsky wrote On 02/24/09 16:04,: > >> Jon Masamitsu wrote: >> >> >>> Jon Masamitsu wrote On 02/23/09 17:20,: >>> >>> >>> >>>> ... >>>> >>>> Increase the heap by 30%. Also increase the the perm gen size >>>> (-XX:MaxPermSize=). >>>> >>>> Please use -XX:+PrintGCDetails -XX:+PrintGCTimeStamps when gathering the >>>> GC logs. >>>> If you've already gathering some, send those but in future runs, use the >>>> above. >>>> >>>> >> Here is a sample of output from a stuck process. You can see its doing >> a full GC about every 3 seconds, and it seems as if there is little >> progress.. >> >> Please let me know if you need more information. >> >> Cheers, >> David >> >> 62402.320: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8063178 secs] [Times: user=2.81 sys=0.00, >> real=2.81 secs] >> 62405.128: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8029997 secs] [Times: user=2.79 sys=0.00, >> real=2.81 secs] >> 62407.932: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.7917325 secs] [Times: user=2.79 sys=0.00, >> real=2.79 secs] >> 62410.725: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.7891387 secs] [Times: user=2.79 sys=0.00, >> real=2.79 secs] >> 62413.515: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.7649110 secs] [Times: user=2.76 sys=0.00, >> real=2.76 secs] >> 62416.281: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.7803983 secs] [Times: user=2.78 sys=0.00, >> real=2.78 secs] >> 62419.063: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.7643979 secs] [Times: user=2.76 sys=0.00, >> real=2.76 secs] >> 62421.828: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8114336 secs] [Times: user=2.81 sys=0.00, >> real=2.81 secs] >> 62424.640: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.7964912 secs] [Times: user=2.79 sys=0.00, >> real=2.79 secs] >> 62427.438: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8107278 secs] [Times: user=2.81 sys=0.00, >> real=2.81 secs] >> 62430.249: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 3.2345212 secs] [Times: user=2.84 sys=0.00, >> real=3.24 secs] >> 62433.484: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8341520 secs] [Times: user=2.82 sys=0.00, >> real=2.82 secs] >> 62436.319: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8698768 secs] [Times: user=2.87 sys=0.00, >> real=2.87 secs] >> 62439.190: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9323230 secs] [Times: user=2.90 sys=0.00, >> real=2.92 secs] >> 62442.124: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9644960 secs] [Times: user=2.96 sys=0.00, >> real=2.96 secs] >> 62445.089: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 3.0059221 secs] [Times: user=3.00 sys=0.00, >> real=3.00 secs] >> 62448.095: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9832815 secs] [Times: user=3.00 sys=0.00, >> real=2.99 secs] >> 62451.079: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9587156 secs] [Times: user=2.93 sys=0.00, >> real=2.95 secs] >> 62454.039: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9488345 secs] [Times: user=2.92 sys=0.00, >> real=2.95 secs] >> 62456.988: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8969788 secs] [Times: user=2.90 sys=0.00, >> real=2.90 secs] >> 62459.886: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8794991 secs] [Times: user=2.89 sys=0.00, >> real=2.89 secs] >> 62462.766: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8842411 secs] [Times: user=2.87 sys=0.00, >> real=2.89 secs] >> 62465.651: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683675K(699072K)] 781916K->781915K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8669173 secs] [Times: user=2.85 sys=0.00, >> real=2.85 secs] >> 62468.519: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8664429 secs] [Times: user=2.85 sys=0.00, >> real=2.86 secs] >> 62471.386: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8844494 secs] [Times: user=2.87 sys=0.00, >> real=2.89 secs] >> 62474.271: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8648398 secs] [Times: user=2.87 sys=0.00, >> real=2.87 secs] >> 62477.137: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8971068 secs] [Times: user=2.87 sys=0.00, >> real=2.90 secs] >> 62480.034: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8655618 secs] [Times: user=2.86 sys=0.00, >> real=2.86 secs] >> 62482.901: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 3.0366140 secs] [Times: user=2.78 sys=0.00, >> real=3.04 secs] >> 62485.939: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8541753 secs] [Times: user=2.85 sys=0.00, >> real=2.85 secs] >> 62488.794: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8582816 secs] [Times: user=2.86 sys=0.00, >> real=2.86 secs] >> 62491.653: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8673218 secs] [Times: user=2.85 sys=0.00, >> real=2.86 secs] >> 62494.521: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9014120 secs] [Times: user=2.87 sys=0.00, >> real=2.90 secs] >> 62497.424: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8805843 secs] [Times: user=2.89 sys=0.00, >> real=2.89 secs] >> 62500.305: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8905128 secs] [Times: user=2.89 sys=0.00, >> real=2.89 secs] >> 62503.196: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9052007 secs] [Times: user=2.90 sys=0.00, >> real=2.92 secs] >> 62506.102: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9004575 secs] [Times: user=2.89 sys=0.00, >> real=2.90 secs] >> 62509.003: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9160655 secs] [Times: user=2.90 sys=0.00, >> real=2.92 secs] >> 62511.920: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9013277 secs] [Times: user=2.90 sys=0.00, >> real=2.90 secs] >> 62514.822: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8982061 secs] [Times: user=2.89 sys=0.00, >> real=2.89 secs] >> 62517.721: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8922437 secs] [Times: user=2.89 sys=0.00, >> real=2.89 secs] >> 62520.614: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8873520 secs] [Times: user=2.87 sys=0.00, >> real=2.89 secs] >> 62523.502: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8805296 secs] [Times: user=2.89 sys=0.00, >> real=2.89 secs] >> 62526.383: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8958714 secs] [Times: user=2.85 sys=0.00, >> real=2.89 secs] >> 62529.279: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8735384 secs] [Times: user=2.89 sys=0.00, >> real=2.89 secs] >> 62532.154: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8705676 secs] [Times: user=2.87 sys=0.00, >> real=2.87 secs] >> 62535.025: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8723947 secs] [Times: user=2.85 sys=0.00, >> real=2.87 secs] >> 62537.898: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8624400 secs] [Times: user=2.86 sys=0.00, >> real=2.86 secs] >> 62540.761: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8245748 secs] [Times: user=2.84 sys=0.00, >> real=2.84 secs] >> 62543.587: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8432269 secs] [Times: user=2.84 sys=0.00, >> real=2.84 secs] >> 62546.432: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8394157 secs] [Times: user=2.84 sys=0.00, >> real=2.84 secs] >> 62549.272: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8471951 secs] [Times: user=2.85 sys=0.00, >> real=2.85 secs] >> 62552.121: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8584107 secs] [Times: user=2.85 sys=0.00, >> real=2.86 secs] >> 62554.981: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8376807 secs] [Times: user=2.84 sys=0.00, >> real=2.84 secs] >> 62557.820: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8402486 secs] [Times: user=2.84 sys=0.00, >> real=2.84 secs] >> 62560.661: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8482704 secs] [Times: user=2.86 sys=0.00, >> real=2.85 secs] >> 62563.511: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8115973 secs] [Times: user=2.81 sys=0.00, >> real=2.81 secs] >> 62566.324: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8523278 secs] [Times: user=2.85 sys=0.00, >> real=2.86 secs] >> 62569.177: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8128563 secs] [Times: user=2.81 sys=0.00, >> real=2.81 secs] >> 62571.990: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.7830644 secs] [Times: user=2.79 sys=0.00, >> real=2.79 secs] >> 62574.774: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8065106 secs] [Times: user=2.79 sys=0.00, >> real=2.81 secs] >> 62577.582: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.7892171 secs] [Times: user=2.79 sys=0.00, >> real=2.79 secs] >> 62580.372: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8059306 secs] [Times: user=2.79 sys=0.00, >> real=2.79 secs] >> 62583.179: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8641470 secs] [Times: user=2.82 sys=0.00, >> real=2.86 secs] >> 62586.044: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8421364 secs] [Times: user=2.84 sys=0.00, >> real=2.84 secs] >> 62588.887: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8852699 secs] [Times: user=2.89 sys=0.00, >> real=2.89 secs] >> 62591.773: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9164279 secs] [Times: user=2.90 sys=0.00, >> real=2.92 secs] >> 62594.690: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9450010 secs] [Times: user=2.95 sys=0.00, >> real=2.95 secs] >> 62597.636: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9744636 secs] [Times: user=2.98 sys=0.00, >> real=2.98 secs] >> 62600.611: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9900849 secs] [Times: user=2.99 sys=0.00, >> real=3.00 secs] >> 62603.602: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.6332370 secs] [Times: user=2.62 sys=0.00, >> real=2.62 secs] >> 62606.236: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9801260 secs] [Times: user=2.95 sys=0.00, >> real=2.98 secs] >> 62609.226: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9166374 secs] [Times: user=2.89 sys=0.00, >> real=2.92 secs] >> 62612.150: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9475729 secs] [Times: user=2.95 sys=0.00, >> real=2.95 secs] >> 62615.098: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9328670 secs] [Times: user=2.90 sys=0.00, >> real=2.93 secs] >> 62618.040: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8963825 secs] [Times: user=2.89 sys=0.00, >> real=2.90 secs] >> 62620.937: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8834715 secs] [Times: user=2.89 sys=0.00, >> real=2.89 secs] >> 62623.821: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8800691 secs] [Times: user=2.86 sys=0.00, >> real=2.87 secs] >> 62626.701: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683677K(699072K)] 781918K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8642587 secs] [Times: user=2.87 sys=0.00, >> real=2.87 secs] >> 62629.566: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8574615 secs] [Times: user=2.84 sys=0.00, >> real=2.86 secs] >> 62632.424: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8383412 secs] [Times: user=2.84 sys=0.00, >> real=2.84 secs] >> 62635.264: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8409891 secs] [Times: user=2.82 sys=0.00, >> real=2.84 secs] >> 62638.106: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.7906216 secs] [Times: user=2.79 sys=0.00, >> real=2.79 secs] >> 62640.898: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.7891730 secs] [Times: user=2.79 sys=0.00, >> real=2.79 secs] >> 62643.688: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.7892940 secs] [Times: user=2.79 sys=0.00, >> real=2.79 secs] >> 62646.479: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.7766807 secs] [Times: user=2.78 sys=0.00, >> real=2.78 secs] >> 62649.257: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.7796531 secs] [Times: user=2.78 sys=0.00, >> real=2.78 secs] >> 62652.037: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.7687240 secs] [Times: user=2.76 sys=0.00, >> real=2.76 secs] >> 62654.807: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.7613769 secs] [Times: user=2.76 sys=0.00, >> real=2.76 secs] >> 62657.570: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.7712254 secs] [Times: user=2.78 sys=0.00, >> real=2.78 secs] >> 62660.342: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.7968108 secs] [Times: user=2.79 sys=0.00, >> real=2.79 secs] >> 62663.139: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.7924173 secs] [Times: user=2.79 sys=0.00, >> real=2.79 secs] >> 62665.933: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8002912 secs] [Times: user=2.79 sys=0.00, >> real=2.81 secs] >> 62668.736: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8291434 secs] [Times: user=2.82 sys=0.00, >> real=2.82 secs] >> 62671.566: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8527186 secs] [Times: user=2.86 sys=0.00, >> real=2.85 secs] >> 62674.419: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8982825 secs] [Times: user=2.90 sys=0.00, >> real=2.90 secs] >> 62677.318: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9254483 secs] [Times: user=2.93 sys=0.00, >> real=2.93 secs] >> 62680.244: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9707015 secs] [Times: user=2.95 sys=0.00, >> real=2.96 secs] >> 62683.216: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9894145 secs] [Times: user=3.00 sys=0.00, >> real=3.00 secs] >> 62686.206: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9870305 secs] [Times: user=2.98 sys=0.00, >> real=2.98 secs] >> 62689.193: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9884647 secs] [Times: user=2.98 sys=0.00, >> real=3.00 secs] >> 62692.183: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9635276 secs] [Times: user=2.96 sys=0.00, >> real=2.96 secs] >> 62695.147: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9407559 secs] [Times: user=2.93 sys=0.00, >> real=2.93 secs] >> 62698.088: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9299386 secs] [Times: user=2.93 sys=0.00, >> real=2.93 secs] >> 62701.019: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8994903 secs] [Times: user=2.90 sys=0.00, >> real=2.90 secs] >> 62703.919: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9163417 secs] [Times: user=2.92 sys=0.00, >> real=2.92 secs] >> 62706.836: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9216473 secs] [Times: user=2.93 sys=0.00, >> real=2.93 secs] >> 62709.758: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.9052547 secs] [Times: user=2.89 sys=0.00, >> real=2.90 secs] >> 62712.664: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8902824 secs] [Times: user=2.85 sys=0.00, >> real=2.89 secs] >> 62715.555: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8865932 secs] [Times: user=2.87 sys=0.00, >> real=2.89 secs] >> 62718.442: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8605445 secs] [Times: user=2.87 sys=0.00, >> real=2.87 secs] >> 62721.304: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8662771 secs] [Times: user=2.84 sys=0.00, >> real=2.86 secs] >> 62724.171: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: >> 683679K->683679K(699072K)] 781919K->781919K(913792K) [PSPermGen: >> 49694K->49694K(49984K)], 2.8369076 secs] [Times: user=2.84 sys=0.00, >> real=2.84 secs] >> >> >> -- Cheers, David Nuix Pty Ltd Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 0699 Web: http://www.nuix.com Fax: +61 2 9212 6902 From heiko.wagner at apis.de Wed Feb 25 03:46:52 2009 From: heiko.wagner at apis.de (Heiko Wagner) Date: Wed, 25 Feb 2009 12:46:52 +0100 Subject: [Fwd: Re: Unicode support in Java JRE on Windows] In-Reply-To: <1ccfd1c10902241822w39ccced3y62cdd12d89c22516@mail.gmail.com> Message-ID: <194C4BEA64A042A08A8CFDF12A2474BC@HeikoXP> Martin, thanks for your explanation. As I am fighting against WIN32 API, for over ten years, I can understand what you are pointing out. I usually also have the bad feeling the WIN32 API wins the fight almost all the time. Despite my great admiration for our fellow japanese friends, who have achieved great zen mastership in painlessly using software that has some issues in a unicode environment, I wonder if there is any way of contributing/suggesting some changes without a bunch of jdk team members getting mad at me? ;-) Regards Heiko -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net]On Behalf Of Martin Buchholz Sent: Mittwoch, 25. Februar 2009 03:23 To: Naoto Sato Cc: hotspot-dev at openjdk.java.net; Core-Libs-Dev Subject: Re: [Fwd: Re: Unicode support in Java JRE on Windows] Part of the history here is that the JDK used to continue supporting windows 98 for many years, longer than Microsoft itself! With that support having been dropped, it is much easier to make changes like this (switch from "A" to "W" interfaces consistently) but it's hard to find the enthusiasm. Fighting with the win32 API is no fun. Many distinct jdk teams own affected interfaces, making a thorough fix organizationally difficult. Martin On Tue, Feb 24, 2009 at 17:54, Naoto Sato wrote: > 4519026: (process) Process should support Unicode on Win NT > > This is a long standing known limitation, which has never been addressed > because it would require fairly big effort. > > Thanks, > Naoto > >> Subject: Re: Unicode support in Java JRE on Windows >> Date: Mon, 23 Feb 2009 16:14:11 -0500 >> From: Karen Kinnear >> To: Heiko Wagner >> CC: hotspot-dev at openjdk.java.net, core-libs-dev at openjdk.java.net >> References: >> >> Heiko, >> >> I'm copying this to the core-libs-dev at openjdk.java.net alias, since >> I think the APIs you are referring to are more familiar to that team. >> And I've retitled it "Java JRE" so folks see the bigger picture. >> >> hope this helps, >> Karen >> >> Heiko Wagner wrote: >>> >>> Hi, >>> >>> I am currently investigating on a problem of the Java VM on Windows. The >>> VM >>> is started using the JNI invocation api. This works unless the path >>> contains >>> non-ansi characters. So I hacked the classpath with >>> addURLToAppClassLoader() >>> in sun.misc.Launcher. I at least could make a shared JRE installation, >>> started from a ansi path, find my JARs. Since one of my JARs does use >>> native >>> code I then got stuck at the System.loadLibrary() call. Hacking the >>> correct >>> path into the 'usr_paths' field into the ClassLoader did not help, >>> because >>> the actual Windows API call LoadLibrary() seems to be ansi flavour >>> instead >>> of wide char api. Would it be possible to make this two enhancements >>> without >>> hurting the Java VM spec?: >>> >>> 1) fill the property java.class.path from the env variable CLASSPATH with >>> a >>> call to GetEnvironmentVariableW instead of GetEnvironmentVariableA to >>> enable >>> setting the classpath with unicode characters >>> >>> 2) fill the property java.library.path and issue the actual LoadLibrary >>> with >>> appropriate wide char api >>> >>>> From a quick look at the VM source I found out, that most string >>>> operations >>> >>> use the ANSI C string functions. >>> Maybe it would be possible to use UTF-8 encoding to transfer the path >>> strings throu the Java VM routines to the final Windows API calls, to >>> avoid >>> large changes in the code base. >>> >>> Regards >>> Heiko Wagner >>> >> > > > -- > Naoto Sato > From gbenson at redhat.com Wed Feb 25 04:39:58 2009 From: gbenson at redhat.com (Gary Benson) Date: Wed, 25 Feb 2009 12:39:58 +0000 Subject: Compiling Object. Message-ID: <20090225123957.GB3223@redhat.com> Hi all, I'm writing a JIT for OpenJDK, and I'm not sure what I should be doing when compiling Object.. I was confused to see it scheduled for compilation at all, since it's an empty method, but now I see its one bytecode is not _return but _return_register_finalizer so of course the empty method detector doesn't recognise it. When it gets compiled, the bytecode is read via a ciBytecodeStream, and it seems to be coming through as a _return as I have no code to handle _return_register_finalizer and it would have aborted if it got that. Do I need to detect that I'm compiling Object. and special case it? Cheers, Gary -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Wed Feb 25 07:01:10 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 25 Feb 2009 16:01:10 +0100 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <1235509145.11128.200.camel@localhost.localdomain> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> <1235407641.11128.98.camel@localhost.localdomain> <1235410237.11128.103.camel@localhost.localdomain> <8B73CF14-A44D-4460-870F-B4D65E204312@sun.com> <1235469506.11128.166.camel@localhost.localdomain> <49A45A82.8040503@sun.com> <1235509145.11128.200.camel@localhost.localdomain> Message-ID: <1235574070.11128.213.camel@localhost.localdomain> On Tue, 2009-02-24 at 21:59 +0100, Christian Thalinger wrote: > On Tue, 2009-02-24 at 12:37 -0800, Vladimir Kozlov wrote: > > Changes looks good. > > Can you just rename (add prefix/suffix) methods defined in MatchRule > > to avoid the warnings? > > Sure. As Tom also said, I already tried to make some of them virtual > but it didn't work, so renaming sounds like the better idea. I will do > that tomorrow. http://cr.openjdk.java.net/~twisti/6778669/webrev.02/ Here is the final version. I've fixed all method name problems, either with renaming them or using virtual methods. With SunCC it builds now with +w -errwarn (like GCC's -Werror). -- Christian From martinrb at google.com Wed Feb 25 08:05:24 2009 From: martinrb at google.com (Martin Buchholz) Date: Wed, 25 Feb 2009 08:05:24 -0800 Subject: [Fwd: Re: Unicode support in Java JRE on Windows] In-Reply-To: <194C4BEA64A042A08A8CFDF12A2474BC@HeikoXP> References: <1ccfd1c10902241822w39ccced3y62cdd12d89c22516@mail.gmail.com> <194C4BEA64A042A08A8CFDF12A2474BC@HeikoXP> Message-ID: <1ccfd1c10902250805q790ed497o9aece863efcca3c2@mail.gmail.com> On Wed, Feb 25, 2009 at 03:46, Heiko Wagner wrote: > Martin, > > thanks for your explanation. As I am fighting against WIN32 API, for over > ten years, I can understand what you are pointing out. I usually also have > the bad feeling the WIN32 API wins the fight almost all the time. Despite my > great admiration for our fellow japanese friends, who have achieved great > zen mastership in painlessly using software that has some issues in a > unicode environment, I wonder if there is any way of contributing/suggesting > some changes without a bunch of jdk team members getting mad at me? ;-) You can start by fixing the JDK one piece at a time. My personal favorite is command line, both java's own in the launcher, and when starting subprocesses. If you fix ProcessImpl.c to use CreateProcessW, I will be your reviewer. There are already comments there to get you started. /* Java and Windows are both pure Unicode systems at heart. * Windows has both a legacy byte-based API and a 16-bit Unicode * "W" API. The Right Thing here is to call CreateProcessW, since * that will allow all process-related information like command * line arguments to be passed properly to the child. We don't do * that currently, since we would first have to have "W" versions * of JVM_NativePath and perhaps other functions. In the * meantime, we can call CreateProcess with the magic flag * CREATE_UNICODE_ENVIRONMENT, which passes only the environment * in "W" mode. We will fix this later. */ ret = CreateProcess(0, /* executable name */ Apparently, "We" means "you". Martin > Regards > Heiko > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net > [mailto:hotspot-dev-bounces at openjdk.java.net]On Behalf Of Martin > Buchholz > Sent: Mittwoch, 25. Februar 2009 03:23 > To: Naoto Sato > Cc: hotspot-dev at openjdk.java.net; Core-Libs-Dev > Subject: Re: [Fwd: Re: Unicode support in Java JRE on Windows] > > > Part of the history here is that the JDK used to continue supporting > windows 98 for many years, longer than Microsoft itself! > With that support having been dropped, it is much easier to make > changes like this (switch from "A" to "W" interfaces consistently) > but it's hard to find the enthusiasm. ?Fighting with the win32 API is no > fun. > Many distinct jdk teams own affected interfaces, making a thorough > fix organizationally difficult. > > Martin > > On Tue, Feb 24, 2009 at 17:54, Naoto Sato wrote: >> 4519026: (process) Process should support Unicode on Win NT >> >> This is a long standing known limitation, which has never been addressed >> because it would require fairly big effort. >> >> Thanks, >> Naoto >> >>> Subject: Re: Unicode support in Java JRE on Windows >>> Date: Mon, 23 Feb 2009 16:14:11 -0500 >>> From: Karen Kinnear >>> To: Heiko Wagner >>> CC: hotspot-dev at openjdk.java.net, core-libs-dev at openjdk.java.net >>> References: >>> >>> Heiko, >>> >>> I'm copying this to the core-libs-dev at openjdk.java.net alias, since >>> I think the APIs you are referring to are more familiar to that team. >>> And I've retitled it "Java JRE" so folks see the bigger picture. >>> >>> hope this helps, >>> Karen >>> >>> Heiko Wagner wrote: >>>> >>>> Hi, >>>> >>>> I am currently investigating on a problem of the Java VM on Windows. The >>>> VM >>>> is started using the JNI invocation api. This works unless the path >>>> contains >>>> non-ansi characters. So I hacked the classpath with >>>> addURLToAppClassLoader() >>>> in sun.misc.Launcher. I at least could make a shared JRE installation, >>>> started from a ansi path, find my JARs. Since one of my JARs does use >>>> native >>>> code I then got stuck at the System.loadLibrary() call. Hacking the >>>> correct >>>> path into the 'usr_paths' field into the ClassLoader did not help, >>>> because >>>> the actual Windows API call LoadLibrary() seems to be ansi flavour >>>> instead >>>> of wide char api. Would it be possible to make this two enhancements >>>> without >>>> hurting the Java VM spec?: >>>> >>>> 1) fill the property java.class.path from the env variable CLASSPATH > with >>>> a >>>> call to GetEnvironmentVariableW instead of GetEnvironmentVariableA to >>>> enable >>>> setting the classpath with unicode characters >>>> >>>> 2) fill the property java.library.path and issue the actual LoadLibrary >>>> with >>>> appropriate wide char api >>>> >>>>> From a quick look at the VM source I found out, that most string >>>>> operations >>>> >>>> use the ANSI C string functions. >>>> Maybe it would be possible to use UTF-8 encoding to transfer the path >>>> strings throu the Java VM routines to the final Windows API calls, to >>>> avoid >>>> large changes in the code base. >>>> >>>> Regards >>>> Heiko Wagner >>>> >>> >> >> >> -- >> Naoto Sato >> > > From Vladimir.Kozlov at Sun.COM Wed Feb 25 08:55:09 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 25 Feb 2009 08:55:09 -0800 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <1235574070.11128.213.camel@localhost.localdomain> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> <1235407641.11128.98.camel@localhost.localdomain> <1235410237.11128.103.camel@localhost.localdomain> <8B73CF14-A44D-4460-870F-B4D65E204312@sun.com> <1235469506.11128.166.camel@localhost.localdomain> <49A45A82.8040503@sun.com> <1235509145.11128.200.camel@localhost.localdomain> <1235574070.11128.213.camel@localhost.localdomain> Message-ID: <49A577ED.6090801@sun.com> Looks good. In formssel.hpp I would mark MatchRule::append_components() and MatchRule::equivalent() as virtual also. Vladimir Christian Thalinger wrote: > On Tue, 2009-02-24 at 21:59 +0100, Christian Thalinger wrote: >> On Tue, 2009-02-24 at 12:37 -0800, Vladimir Kozlov wrote: >>> Changes looks good. >>> Can you just rename (add prefix/suffix) methods defined in MatchRule >>> to avoid the warnings? >> Sure. As Tom also said, I already tried to make some of them virtual >> but it didn't work, so renaming sounds like the better idea. I will do >> that tomorrow. > > http://cr.openjdk.java.net/~twisti/6778669/webrev.02/ > > Here is the final version. I've fixed all method name problems, either > with renaming them or using virtual methods. With SunCC it builds now > with +w -errwarn (like GCC's -Werror). > > -- Christian > From Thomas.Rodriguez at Sun.COM Wed Feb 25 09:35:22 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 25 Feb 2009 09:35:22 -0800 Subject: Compiling Object. In-Reply-To: <20090225123957.GB3223@redhat.com> References: <20090225123957.GB3223@redhat.com> Message-ID: <4EC17452-91DE-4787-B507-37FE9B7BEA35@sun.com> The new version of the JLS and JVMS changed the point at which finalizable objects are registered to be finalized. They are now registered once we reach Object.. This help deal with various tricks that allow a subclass to execute code before the super constructor has run which can result in incompletely initialized objects being registered for finalization. To implement this in the interpreter a new internal bytecode was added. In the compilers we treat Object. as an intrinsic and insert the registration call when we return from it. For example: void Parse::return_current(Node* value) { if (RegisterFinalizersAtInit && method()->intrinsic_id() == vmIntrinsics::_Object_init) { call_register_finalizer(); } Conceivably you could modify the ciBytecodeStream to allow return_register_finalizer to leak through to the parser but that's more tricky. tom On Feb 25, 2009, at 4:39 AM, Gary Benson wrote: > Hi all, > > I'm writing a JIT for OpenJDK, and I'm not sure what I should be doing > when compiling Object.. I was confused to see it scheduled for > compilation at all, since it's an empty method, but now I see its one > bytecode is not _return but _return_register_finalizer so of course > the empty method detector doesn't recognise it. > > When it gets compiled, the bytecode is read via a ciBytecodeStream, > and it seems to be coming through as a _return as I have no code to > handle _return_register_finalizer and it would have aborted if it got > that. > > Do I need to detect that I'm compiling Object. and special case > it? > > Cheers, > Gary > > -- > http://gbenson.net/ From Thomas.Rodriguez at Sun.COM Wed Feb 25 10:09:26 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 25 Feb 2009 10:09:26 -0800 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <1235574070.11128.213.camel@localhost.localdomain> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> <1235407641.11128.98.camel@localhost.localdomain> <1235410237.11128.103.camel@localhost.localdomain> <8B73CF14-A44D-4460-870F-B4D65E204312@sun.com> <1235469506.11128.166.camel@localhost.localdomain> <49A45A82.8040503@sun.com> <1235509145.11128.200.camel@localhost.localdomain> <1235574070.11128.213.camel@localhost.localdomain> Message-ID: Have you confirmed that this doesn't change what gets generated by adlc? In particular making methods virtual could change what gets called and I don't see any obvious gotchas but I'd like to confirm that nothing changes in the output. tom On Feb 25, 2009, at 7:01 AM, Christian Thalinger wrote: > On Tue, 2009-02-24 at 21:59 +0100, Christian Thalinger wrote: >> On Tue, 2009-02-24 at 12:37 -0800, Vladimir Kozlov wrote: >>> Changes looks good. >>> Can you just rename (add prefix/suffix) methods defined in MatchRule >>> to avoid the warnings? >> >> Sure. As Tom also said, I already tried to make some of them virtual >> but it didn't work, so renaming sounds like the better idea. I >> will do >> that tomorrow. > > http://cr.openjdk.java.net/~twisti/6778669/webrev.02/ > > Here is the final version. I've fixed all method name problems, > either > with renaming them or using virtual methods. With SunCC it builds now > with +w -errwarn (like GCC's -Werror). > > -- Christian > From Christian.Thalinger at Sun.COM Wed Feb 25 10:37:02 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 25 Feb 2009 19:37:02 +0100 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> <1235407641.11128.98.camel@localhost.localdomain> <1235410237.11128.103.camel@localhost.localdomain> <8B73CF14-A44D-4460-870F-B4D65E204312@sun.com> <1235469506.11128.166.camel@localhost.localdomain> <49A45A82.8040503@sun.com> <1235509145.11128.200.camel@localhost.localdomain> <1235574070.11128.213.camel@localhost.localdomain> Message-ID: <1235587022.1382.1.camel@localhost.localdomain> On Wed, 2009-02-25 at 10:09 -0800, Tom Rodriguez wrote: > Have you confirmed that this doesn't change what gets generated by > adlc? In particular making methods virtual could change what gets > called and I don't see any obvious gotchas but I'd like to confirm > that nothing changes in the output. I have compared the md5sum's of the generated files on solaris-amd64. I could compare them on other architectures too (except Windows, I don't know how to build it there). -- Christian From Christian.Thalinger at Sun.COM Wed Feb 25 16:15:40 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 26 Feb 2009 01:15:40 +0100 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <49A577ED.6090801@sun.com> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> <1235407641.11128.98.camel@localhost.localdomain> <1235410237.11128.103.camel@localhost.localdomain> <8B73CF14-A44D-4460-870F-B4D65E204312@sun.com> <1235469506.11128.166.camel@localhost.localdomain> <49A45A82.8040503@sun.com> <1235509145.11128.200.camel@localhost.localdomain> <1235574070.11128.213.camel@localhost.localdomain> <49A577ED.6090801@sun.com> Message-ID: <1235607340.1382.2.camel@localhost.localdomain> On Wed, 2009-02-25 at 08:55 -0800, Vladimir Kozlov wrote: > Looks good. > In formssel.hpp I would mark MatchRule::append_components() and > MatchRule::equivalent() as virtual also. I tried that but the arguments are different, so the subclass would shadow the superclass' methods. I didn't find a solution. -- Christian From Vladimir.Kozlov at Sun.COM Wed Feb 25 16:36:18 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 25 Feb 2009 16:36:18 -0800 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <1235607340.1382.2.camel@localhost.localdomain> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> <1235407641.11128.98.camel@localhost.localdomain> <1235410237.11128.103.camel@localhost.localdomain> <8B73CF14-A44D-4460-870F-B4D65E204312@sun.com> <1235469506.11128.166.camel@localhost.localdomain> <49A45A82.8040503@sun.com> <1235509145.11128.200.camel@localhost.localdomain> <1235574070.11128.213.camel@localhost.localdomain> <49A577ED.6090801@sun.com> <1235607340.1382.2.camel@localhost.localdomain> Message-ID: <49A5E402.3030604@sun.com> No, these 2 methods arguments are the same. I am not talking about renamed methods but these two: class MatchNode { virtual void append_components(FormDict& locals, ComponentList& components, bool def_flag = false) const; virtual bool equivalent(FormDict& globals, MatchNode* mNode2); } class MatchRule: public MatchNode { void append_components(FormDict& locals, ComponentList& components, bool def_flag = false) const; bool equivalent(FormDict& globals, MatchNode* mRule2); } In such situation C++ implicitly marks methods in MatchRule class as virtual also. And I only asked to specify 'virtual' explicitly for these two methods. Vladimir Christian Thalinger wrote: > On Wed, 2009-02-25 at 08:55 -0800, Vladimir Kozlov wrote: >> Looks good. >> In formssel.hpp I would mark MatchRule::append_components() and >> MatchRule::equivalent() as virtual also. > > I tried that but the arguments are different, so the subclass would > shadow the superclass' methods. I didn't find a solution. > > -- Christian > From erik.trimble at sun.com Wed Feb 25 23:00:57 2009 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Thu, 26 Feb 2009 07:00:57 +0000 Subject: hg: jdk7/hotspot/hotspot: 6 new changesets Message-ID: <20090226070109.DBAE8E1A0@hg.openjdk.java.net> Changeset: ba02d80fc550 Author: xdono Date: 2009-02-05 16:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ba02d80fc550 Added tag jdk7-b46 for changeset 16bb38eeda35 ! .hgtags Changeset: fcb923bad68e Author: trims Date: 2009-02-10 20:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fcb923bad68e Merge Changeset: bcb33806d186 Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/bcb33806d186 Added tag jdk7-b47 for changeset fcb923bad68e ! .hgtags Changeset: 6b7f6a17455e Author: trims Date: 2009-02-18 18:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6b7f6a17455e Merge Changeset: 1605bb4eb5a7 Author: trims Date: 2009-02-18 18:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1605bb4eb5a7 6807345: Bump HS15 build number to 02 Summary: Update the HS15 Build number to 02 Reviewed-by: jcoomes ! make/hotspot_version Changeset: ef3b3df478b9 Author: trims Date: 2009-02-25 22:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ef3b3df478b9 Merge - src/cpu/x86/vm/vm_version_x86_32.cpp - src/cpu/x86/vm/vm_version_x86_32.hpp - src/cpu/x86/vm/vm_version_x86_64.cpp - src/cpu/x86/vm/vm_version_x86_64.hpp From Christian.Thalinger at Sun.COM Thu Feb 26 01:30:42 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 26 Feb 2009 10:30:42 +0100 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <49A5E402.3030604@sun.com> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> <1235407641.11128.98.camel@localhost.localdomain> <1235410237.11128.103.camel@localhost.localdomain> <8B73CF14-A44D-4460-870F-B4D65E204312@sun.com> <1235469506.11128.166.camel@localhost.localdomain> <49A45A82.8040503@sun.com> <1235509145.11128.200.camel@localhost.localdomain> <1235574070.11128.213.camel@localhost.localdomain> <49A577ED.6090801@sun.com> <1235607340.1382.2.camel@localhost.localdomain> <49A5E402.3030604@sun.com> Message-ID: <1235640642.1382.4.camel@localhost.localdomain> On Wed, 2009-02-25 at 16:36 -0800, Vladimir Kozlov wrote: > No, these 2 methods arguments are the same. > I am not talking about renamed methods but these two: > > class MatchNode { > virtual void append_components(FormDict& locals, ComponentList& components, > bool def_flag = false) const; > virtual bool equivalent(FormDict& globals, MatchNode* mNode2); > } > > class MatchRule: public MatchNode { > void append_components(FormDict& locals, ComponentList& components, bool def_flag = false) > const; > bool equivalent(FormDict& globals, MatchNode* mRule2); > } > > In such situation C++ implicitly marks methods in MatchRule class as virtual also. > And I only asked to specify 'virtual' explicitly for these two methods. Ahh! Sorry, I misunderstood that. Yes, I will make them virtual explicitly. I will push it then. -- Christian From gbenson at redhat.com Thu Feb 26 06:47:02 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 26 Feb 2009 14:47:02 +0000 Subject: Quick question Message-ID: <20090226144702.GB8970@redhat.com> Hi all, A quick question: is it necessary to check for pending exceptions after calling SafepointSynchronize::block? Cheers, Gary -- http://gbenson.net/ From Paul.Hohensee at Sun.COM Thu Feb 26 07:25:12 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Thu, 26 Feb 2009 10:25:12 -0500 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <49A5E402.3030604@sun.com> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> <1235407641.11128.98.camel@localhost.localdomain> <1235410237.11128.103.camel@localhost.localdomain> <8B73CF14-A44D-4460-870F-B4D65E204312@sun.com> <1235469506.11128.166.camel@localhost.localdomain> <49A45A82.8040503@sun.com> <1235509145.11128.200.camel@localhost.localdomain> <1235574070.11128.213.camel@localhost.localdomain> <49A577ED.6090801@sun.com> <1235607340.1382.2.camel@localhost.localdomain> <49A5E402.3030604@sun.com> Message-ID: <49A6B458.5050902@sun.com> I agree with Vladimir. C++ has a lot of implicit defaults, of which this is one, and all of which cause confusion. I like to mark every implicitly virtual method in subclasses with an explicit "virtual". Then I can understand the cost of what I'm doing without looking up the entire class hierarchy. Paul Vladimir Kozlov wrote: > No, these 2 methods arguments are the same. > I am not talking about renamed methods but these two: > > class MatchNode { > virtual void append_components(FormDict& locals, ComponentList& > components, > bool def_flag = false) const; > virtual bool equivalent(FormDict& globals, MatchNode* mNode2); > } > > class MatchRule: public MatchNode { > void append_components(FormDict& locals, ComponentList& > components, bool def_flag = false) const; > bool equivalent(FormDict& globals, MatchNode* mRule2); > } > > In such situation C++ implicitly marks methods in MatchRule class as > virtual also. > And I only asked to specify 'virtual' explicitly for these two methods. > > Vladimir > > Christian Thalinger wrote: >> On Wed, 2009-02-25 at 08:55 -0800, Vladimir Kozlov wrote: >>> Looks good. >>> In formssel.hpp I would mark MatchRule::append_components() and >>> MatchRule::equivalent() as virtual also. >> >> I tried that but the arguments are different, so the subclass would >> shadow the superclass' methods. I didn't find a solution. >> >> -- Christian >> From Christian.Thalinger at Sun.COM Thu Feb 26 07:28:43 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 26 Feb 2009 16:28:43 +0100 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <49A6B458.5050902@sun.com> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> <1235407641.11128.98.camel@localhost.localdomain> <1235410237.11128.103.camel@localhost.localdomain> <8B73CF14-A44D-4460-870F-B4D65E204312@sun.com> <1235469506.11128.166.camel@localhost.localdomain> <49A45A82.8040503@sun.com> <1235509145.11128.200.camel@localhost.localdomain> <1235574070.11128.213.camel@localhost.localdomain> <49A577ED.6090801@sun.com> <1235607340.1382.2.camel@localhost.localdomain> <49A5E402.3030604@sun.com> <49A6B458.5050902@sun.com> Message-ID: <1235662123.2004.179.camel@localhost.localdomain> On Thu, 2009-02-26 at 10:25 -0500, Paul Hohensee wrote: > I agree with Vladimir. C++ has a lot of implicit defaults, of which > this is one, > and all of which cause confusion. I like to mark every implicitly > virtual method > in subclasses with an explicit "virtual". Then I can understand the > cost of what > I'm doing without looking up the entire class hierarchy. Very true indeed. -- Christian From Christian.Thalinger at Sun.COM Thu Feb 26 08:02:01 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 26 Feb 2009 17:02:01 +0100 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <1235587022.1382.1.camel@localhost.localdomain> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> <1235407641.11128.98.camel@localhost.localdomain> <1235410237.11128.103.camel@localhost.localdomain> <8B73CF14-A44D-4460-870F-B4D65E204312@sun.com> <1235469506.11128.166.camel@localhost.localdomain> <49A45A82.8040503@sun.com> <1235509145.11128.200.camel@localhost.localdomain> <1235574070.11128.213.camel@localhost.localdomain> <1235587022.1382.1.camel@localhost.localdomain> Message-ID: <1235664121.2004.214.camel@localhost.localdomain> On Wed, 2009-02-25 at 19:37 +0100, Christian Thalinger wrote: > On Wed, 2009-02-25 at 10:09 -0800, Tom Rodriguez wrote: > > Have you confirmed that this doesn't change what gets generated by > > adlc? In particular making methods virtual could change what gets > > called and I don't see any obvious gotchas but I'd like to confirm > > that nothing changes in the output. > > I have compared the md5sum's of the generated files on solaris-amd64. I > could compare them on other architectures too (except Windows, I don't > know how to build it there). Additionally I compared the md5sum's of solaris-i486, solaris-sparc and solaris-sparcv9 and all were identical. I think it's safe to commit. -- Christian From Thomas.Rodriguez at Sun.COM Thu Feb 26 08:48:12 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 26 Feb 2009 08:48:12 -0800 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <1235664121.2004.214.camel@localhost.localdomain> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> <1235407641.11128.98.camel@localhost.localdomain> <1235410237.11128.103.camel@localhost.localdomain> <8B73CF14-A44D-4460-870F-B4D65E204312@sun.com> <1235469506.11128.166.camel@localhost.localdomain> <49A45A82.8040503@sun.com> <1235509145.11128.200.camel@localhost.localdomain> <1235574070.11128.213.camel@localhost.localdomain> <1235587022.1382.1.camel@localhost.localdomain> <1235664121.2004.214.camel@localhost.localdomain> Message-ID: <4A9B3091-DE4D-4C82-949E-DDCA0FF98AB1@Sun.COM> Sounds good. tom On Feb 26, 2009, at 8:02 AM, Christian Thalinger wrote: > On Wed, 2009-02-25 at 19:37 +0100, Christian Thalinger wrote: >> On Wed, 2009-02-25 at 10:09 -0800, Tom Rodriguez wrote: >>> Have you confirmed that this doesn't change what gets generated by >>> adlc? In particular making methods virtual could change what gets >>> called and I don't see any obvious gotchas but I'd like to confirm >>> that nothing changes in the output. >> >> I have compared the md5sum's of the generated files on solaris- >> amd64. I >> could compare them on other architectures too (except Windows, I >> don't >> know how to build it there). > > Additionally I compared the md5sum's of solaris-i486, solaris-sparc > and > solaris-sparcv9 and all were identical. I think it's safe to commit. > > -- Christian > From Thomas.Rodriguez at Sun.COM Thu Feb 26 09:09:19 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 26 Feb 2009 09:09:19 -0800 Subject: Quick question In-Reply-To: <20090226144702.GB8970@redhat.com> References: <20090226144702.GB8970@redhat.com> Message-ID: Async exceptions can be delivered to a thread during a safepoint so yes you need to check for a pending exception. Check out JavaThread::check_and_handle_async_exceptions and JavaThread::handle_special_runtime_exit_condition and generate_handler_blob in sharedRuntime_.cpp. Generally speaking if you call into the runtime for any reason you should be checking for pending exceptions. tom On Feb 26, 2009, at 6:47 AM, Gary Benson wrote: > Hi all, > > A quick question: is it necessary to check for pending exceptions > after calling SafepointSynchronize::block? > > Cheers, > Gary > > -- > http://gbenson.net/ From Naoto.Sato at Sun.COM Tue Feb 24 17:54:42 2009 From: Naoto.Sato at Sun.COM (Naoto Sato) Date: Tue, 24 Feb 2009 17:54:42 -0800 Subject: [Fwd: Re: Unicode support in Java JRE on Windows] In-Reply-To: <49A4997E.9030900@sun.com> References: <49A4997E.9030900@sun.com> Message-ID: <49A4A4E2.7010503@Sun.COM> 4519026: (process) Process should support Unicode on Win NT This is a long standing known limitation, which has never been addressed because it would require fairly big effort. Thanks, Naoto > Subject: Re: Unicode support in Java JRE on Windows > Date: Mon, 23 Feb 2009 16:14:11 -0500 > From: Karen Kinnear > To: Heiko Wagner > CC: hotspot-dev at openjdk.java.net, core-libs-dev at openjdk.java.net > References: > > Heiko, > > I'm copying this to the core-libs-dev at openjdk.java.net alias, since > I think the APIs you are referring to are more familiar to that team. > And I've retitled it "Java JRE" so folks see the bigger picture. > > hope this helps, > Karen > > Heiko Wagner wrote: >> Hi, >> >> I am currently investigating on a problem of the Java VM on Windows. >> The VM >> is started using the JNI invocation api. This works unless the path >> contains >> non-ansi characters. So I hacked the classpath with >> addURLToAppClassLoader() >> in sun.misc.Launcher. I at least could make a shared JRE installation, >> started from a ansi path, find my JARs. Since one of my JARs does use >> native >> code I then got stuck at the System.loadLibrary() call. Hacking the >> correct >> path into the 'usr_paths' field into the ClassLoader did not help, >> because >> the actual Windows API call LoadLibrary() seems to be ansi flavour >> instead >> of wide char api. Would it be possible to make this two enhancements >> without >> hurting the Java VM spec?: >> >> 1) fill the property java.class.path from the env variable CLASSPATH >> with a >> call to GetEnvironmentVariableW instead of GetEnvironmentVariableA to >> enable >> setting the classpath with unicode characters >> >> 2) fill the property java.library.path and issue the actual >> LoadLibrary with >> appropriate wide char api >> >>> From a quick look at the VM source I found out, that most string >>> operations >> use the ANSI C string functions. >> Maybe it would be possible to use UTF-8 encoding to transfer the path >> strings throu the Java VM routines to the final Windows API calls, to >> avoid >> large changes in the code base. >> >> Regards >> Heiko Wagner >> > -- Naoto Sato From penberg at cs.helsinki.fi Tue Feb 24 23:58:40 2009 From: penberg at cs.helsinki.fi (Pekka Enberg) Date: Wed, 25 Feb 2009 09:58:40 +0200 Subject: Question on HotSpot JIT and invokeinterface Message-ID: <1235548720.3849.14.camel@penberg-laptop> Hi all, I have a question regarding HotSpot JIT and invokeinterface. There's a nice description of how HotSpot implements JIT'ed invokeinterface at HotSpot Internals wiki: http://wikis.sun.com/display/HotSpotInternals/InterfaceCalls Unfortunately there are no pointers to the actual code. I recently started looking at how the interface resolution stubs are generated and spent quite a lot of time figuring out what was going on! I think I got it mostly right but thought I thought I'd get a second opinion. Maybe this is something that could be added to the wiki as well? --- [Assuming 32-bit x86 here.] I think it's the VtableStubs::create_itable_stub() function in src/cpu/x86/vm/vtableStubs_x86_32.cpp. Tracing trough the the callers in reverse order, we have: VtableStubs::create_itable_stub() VtableStubs::create_stub() CompiledIC::set_to_megamorphic() SharedRuntime::handle_ic_miss_helper() SharedRuntime::handle_wrong_method_ic_miss() and in src/cpu/x86/vm/sharedRuntime_x86_32.cpp we have SharedRuntime::generate_stubs() that generates a resolve blob that points to SharedRuntime::handle_wrong_method_ic_miss(): _ic_miss_blob = generate_resolve_blob( CAST_FROM_FN_PTR( address, SharedRuntime::handle_wrong_method_ic_miss), "ic_miss_stub"); Now the IC miss stub is called if we can't find a method in the inline cache. The instruction sequence of _ic_miss_blob is returned by: static address SharedRuntime::get_ic_miss_stub() { assert(_ic_miss_blob!= NULL, "oops"); return _ic_miss_blob->instructions_begin(); } Looking at a reverse call-graph: SharedRuntime::get_ic_miss_stub() SharedRuntime::generate_i2c2i_adapters() AdapterHandlerLibrary::get_create_adapter_index() AdapterHandlerLibrary::get_adapter() methodOopDesc::make_adapters() we can see how a method oop adapter has a pointer to the IC miss stub. To complete the explanation, lets look at how HotSpot loads a Java class and jumps into the main() method: src/os/linux/launcher/java.c::main() src/os/linux/launcher/java.c::CallStaticVoidMethod() src/share/vm/prims/jni.cpp::jni_invoke_static() src/share/vm/runtime/javaCalls.cpp::JavaCalls::call() src/share/vm/runtime/javaCalls.cpp::JavaCalls::call_helper() Now JavaCalls::call_helper() does: src/share/vm/runtime/stubRoutines.hpp::StubRoutines::call_stub() which returns a function pointer to a stub and calls that. The call stub in turn delegates to is something called the entry point which is obtained in JavaCalls::call_helper() as follows: address entry_point = method->from_interpreted_entry(); Now when a method is compiled into native code, the src/share/vm/ci/ciEnv.cpp:ciEnv::register_method() function calls src/share/vm/oops/methodOop.cpp::methodOopDesc::set_code() which sets up _from_interpreted_entry like this: mh->_from_interpreted_entry = mh->get_i2c_entry(); where get_i2_c_entry() looks like this: address methodOopDesc::get_i2c_entry() { assert(_adapter != NULL, "must have"); return _adapter->get_i2c_entry(); } The _adapter of type class AdapterHandlerEntry which are created in src/cpu/x86/vm/sharedRuntime_x86_32.cpp::SharedRuntime::generate_i2c2i_adapters() which we know already to jump to a stub returned by SharedRuntime::get_ic_miss_stub() if a method cannot be found in the inline cache. --- That's it! Comments and corrections are most appreciated! Regards, Pekka From Y.S.Ramakrishna at Sun.COM Wed Feb 25 00:38:58 2009 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Wed, 25 Feb 2009 00:38:58 -0800 Subject: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application In-Reply-To: <49A4DE63.5030704@sun.com> References: <499CA7D9.9040903@nuix.com> <4E0D3F42-021A-4D48-888E-594A5980D0E1@sun.com> <49A33600.7000004@nuix.com> <49A3454A.4010507@nuix.com> <49A34B69.2000608@sun.com> <49A34DF2.2010800@sun.com> <49A48B14.8070307@nuix.com> <49A4DE63.5030704@sun.com> Message-ID: <6ed08c5e5b2a.49a49322@sun.com> Doesn't the heap look too full? If a 64-bit JVM why use such an oversubscribed and small heap? Either make the old gen bigger or make the young gen smaller (giving that space to the older gen) so that each scavenge does not degenerate to a full gc as in your trace below. This discussion probably belongs on hotspot-gc-use at o.j.n list so i have cross-posted over to that list with a bcc to the hotspot-dev list. Also the GC tuning guides to be found here might be useful reading:- http://java.sun.com/javase/technologies/hotspot/gc/index.jsp -- ramki ----- Original Message ----- From: Jon Masamitsu Date: Tuesday, February 24, 2009 10:00 pm Subject: Re: 100% CPU usage in "VM Thread" for Hotspot 10/11 on x64 platform within data processing application To: David Sitsky Cc: hotspot-dev at openjdk.java.net, Tom Rodriguez > David, > > Can you also send a GC log from a run where there > is not a problem? As I understand it, that would > be a 32bit run. > > Jon > > David Sitsky wrote On 02/24/09 16:04,: > > >Jon Masamitsu wrote: > > > > > >>Jon Masamitsu wrote On 02/23/09 17:20,: > >> > >> > >> > >>>... > >>> > >>>Increase the heap by 30%. Also increase the the perm gen size > >>>(-XX:MaxPermSize=). > >>> > >>>Please use -XX:+PrintGCDetails -XX:+PrintGCTimeStamps when > gathering the > >>>GC logs. > >>>If you've already gathering some, send those but in future runs, > use the > >>>above. > >>> > >>> > > > >Here is a sample of output from a stuck process. You can see its > doing > >a full GC about every 3 seconds, and it seems as if there is little > >progress.. > > > >Please let me know if you need more information. > > > >Cheers, > >David > > > >62402.320: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8063178 secs] [Times: user=2.81 sys=0.00, > > >real=2.81 secs] > >62405.128: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8029997 secs] [Times: user=2.79 sys=0.00, > > >real=2.81 secs] > >62407.932: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.7917325 secs] [Times: user=2.79 sys=0.00, > > >real=2.79 secs] > >62410.725: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.7891387 secs] [Times: user=2.79 sys=0.00, > > >real=2.79 secs] > >62413.515: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.7649110 secs] [Times: user=2.76 sys=0.00, > > >real=2.76 secs] > >62416.281: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.7803983 secs] [Times: user=2.78 sys=0.00, > > >real=2.78 secs] > >62419.063: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.7643979 secs] [Times: user=2.76 sys=0.00, > > >real=2.76 secs] > >62421.828: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8114336 secs] [Times: user=2.81 sys=0.00, > > >real=2.81 secs] > >62424.640: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.7964912 secs] [Times: user=2.79 sys=0.00, > > >real=2.79 secs] > >62427.438: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8107278 secs] [Times: user=2.81 sys=0.00, > > >real=2.81 secs] > >62430.249: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 3.2345212 secs] [Times: user=2.84 sys=0.00, > > >real=3.24 secs] > >62433.484: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8341520 secs] [Times: user=2.82 sys=0.00, > > >real=2.82 secs] > >62436.319: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8698768 secs] [Times: user=2.87 sys=0.00, > > >real=2.87 secs] > >62439.190: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9323230 secs] [Times: user=2.90 sys=0.00, > > >real=2.92 secs] > >62442.124: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9644960 secs] [Times: user=2.96 sys=0.00, > > >real=2.96 secs] > >62445.089: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 3.0059221 secs] [Times: user=3.00 sys=0.00, > > >real=3.00 secs] > >62448.095: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9832815 secs] [Times: user=3.00 sys=0.00, > > >real=2.99 secs] > >62451.079: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9587156 secs] [Times: user=2.93 sys=0.00, > > >real=2.95 secs] > >62454.039: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9488345 secs] [Times: user=2.92 sys=0.00, > > >real=2.95 secs] > >62456.988: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8969788 secs] [Times: user=2.90 sys=0.00, > > >real=2.90 secs] > >62459.886: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8794991 secs] [Times: user=2.89 sys=0.00, > > >real=2.89 secs] > >62462.766: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683675K->683675K(699072K)] 781915K->781915K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8842411 secs] [Times: user=2.87 sys=0.00, > > >real=2.89 secs] > >62465.651: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683675K(699072K)] 781916K->781915K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8669173 secs] [Times: user=2.85 sys=0.00, > > >real=2.85 secs] > >62468.519: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8664429 secs] [Times: user=2.85 sys=0.00, > > >real=2.86 secs] > >62471.386: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8844494 secs] [Times: user=2.87 sys=0.00, > > >real=2.89 secs] > >62474.271: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8648398 secs] [Times: user=2.87 sys=0.00, > > >real=2.87 secs] > >62477.137: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8971068 secs] [Times: user=2.87 sys=0.00, > > >real=2.90 secs] > >62480.034: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8655618 secs] [Times: user=2.86 sys=0.00, > > >real=2.86 secs] > >62482.901: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 3.0366140 secs] [Times: user=2.78 sys=0.00, > > >real=3.04 secs] > >62485.939: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8541753 secs] [Times: user=2.85 sys=0.00, > > >real=2.85 secs] > >62488.794: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8582816 secs] [Times: user=2.86 sys=0.00, > > >real=2.86 secs] > >62491.653: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8673218 secs] [Times: user=2.85 sys=0.00, > > >real=2.86 secs] > >62494.521: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9014120 secs] [Times: user=2.87 sys=0.00, > > >real=2.90 secs] > >62497.424: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8805843 secs] [Times: user=2.89 sys=0.00, > > >real=2.89 secs] > >62500.305: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8905128 secs] [Times: user=2.89 sys=0.00, > > >real=2.89 secs] > >62503.196: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9052007 secs] [Times: user=2.90 sys=0.00, > > >real=2.92 secs] > >62506.102: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9004575 secs] [Times: user=2.89 sys=0.00, > > >real=2.90 secs] > >62509.003: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9160655 secs] [Times: user=2.90 sys=0.00, > > >real=2.92 secs] > >62511.920: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9013277 secs] [Times: user=2.90 sys=0.00, > > >real=2.90 secs] > >62514.822: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8982061 secs] [Times: user=2.89 sys=0.00, > > >real=2.89 secs] > >62517.721: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8922437 secs] [Times: user=2.89 sys=0.00, > > >real=2.89 secs] > >62520.614: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8873520 secs] [Times: user=2.87 sys=0.00, > > >real=2.89 secs] > >62523.502: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8805296 secs] [Times: user=2.89 sys=0.00, > > >real=2.89 secs] > >62526.383: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8958714 secs] [Times: user=2.85 sys=0.00, > > >real=2.89 secs] > >62529.279: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8735384 secs] [Times: user=2.89 sys=0.00, > > >real=2.89 secs] > >62532.154: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8705676 secs] [Times: user=2.87 sys=0.00, > > >real=2.87 secs] > >62535.025: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8723947 secs] [Times: user=2.85 sys=0.00, > > >real=2.87 secs] > >62537.898: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8624400 secs] [Times: user=2.86 sys=0.00, > > >real=2.86 secs] > >62540.761: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8245748 secs] [Times: user=2.84 sys=0.00, > > >real=2.84 secs] > >62543.587: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8432269 secs] [Times: user=2.84 sys=0.00, > > >real=2.84 secs] > >62546.432: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8394157 secs] [Times: user=2.84 sys=0.00, > > >real=2.84 secs] > >62549.272: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8471951 secs] [Times: user=2.85 sys=0.00, > > >real=2.85 secs] > >62552.121: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8584107 secs] [Times: user=2.85 sys=0.00, > > >real=2.86 secs] > >62554.981: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683676K->683676K(699072K)] 781916K->781916K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8376807 secs] [Times: user=2.84 sys=0.00, > > >real=2.84 secs] > >62557.820: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8402486 secs] [Times: user=2.84 sys=0.00, > > >real=2.84 secs] > >62560.661: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8482704 secs] [Times: user=2.86 sys=0.00, > > >real=2.85 secs] > >62563.511: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8115973 secs] [Times: user=2.81 sys=0.00, > > >real=2.81 secs] > >62566.324: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8523278 secs] [Times: user=2.85 sys=0.00, > > >real=2.86 secs] > >62569.177: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8128563 secs] [Times: user=2.81 sys=0.00, > > >real=2.81 secs] > >62571.990: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.7830644 secs] [Times: user=2.79 sys=0.00, > > >real=2.79 secs] > >62574.774: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8065106 secs] [Times: user=2.79 sys=0.00, > > >real=2.81 secs] > >62577.582: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.7892171 secs] [Times: user=2.79 sys=0.00, > > >real=2.79 secs] > >62580.372: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8059306 secs] [Times: user=2.79 sys=0.00, > > >real=2.79 secs] > >62583.179: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8641470 secs] [Times: user=2.82 sys=0.00, > > >real=2.86 secs] > >62586.044: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8421364 secs] [Times: user=2.84 sys=0.00, > > >real=2.84 secs] > >62588.887: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8852699 secs] [Times: user=2.89 sys=0.00, > > >real=2.89 secs] > >62591.773: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9164279 secs] [Times: user=2.90 sys=0.00, > > >real=2.92 secs] > >62594.690: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9450010 secs] [Times: user=2.95 sys=0.00, > > >real=2.95 secs] > >62597.636: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9744636 secs] [Times: user=2.98 sys=0.00, > > >real=2.98 secs] > >62600.611: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9900849 secs] [Times: user=2.99 sys=0.00, > > >real=3.00 secs] > >62603.602: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.6332370 secs] [Times: user=2.62 sys=0.00, > > >real=2.62 secs] > >62606.236: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9801260 secs] [Times: user=2.95 sys=0.00, > > >real=2.98 secs] > >62609.226: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9166374 secs] [Times: user=2.89 sys=0.00, > > >real=2.92 secs] > >62612.150: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9475729 secs] [Times: user=2.95 sys=0.00, > > >real=2.95 secs] > >62615.098: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9328670 secs] [Times: user=2.90 sys=0.00, > > >real=2.93 secs] > >62618.040: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8963825 secs] [Times: user=2.89 sys=0.00, > > >real=2.90 secs] > >62620.937: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8834715 secs] [Times: user=2.89 sys=0.00, > > >real=2.89 secs] > >62623.821: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8800691 secs] [Times: user=2.86 sys=0.00, > > >real=2.87 secs] > >62626.701: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683677K(699072K)] 781918K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8642587 secs] [Times: user=2.87 sys=0.00, > > >real=2.87 secs] > >62629.566: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683677K->683677K(699072K)] 781917K->781917K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8574615 secs] [Times: user=2.84 sys=0.00, > > >real=2.86 secs] > >62632.424: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8383412 secs] [Times: user=2.84 sys=0.00, > > >real=2.84 secs] > >62635.264: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8409891 secs] [Times: user=2.82 sys=0.00, > > >real=2.84 secs] > >62638.106: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.7906216 secs] [Times: user=2.79 sys=0.00, > > >real=2.79 secs] > >62640.898: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.7891730 secs] [Times: user=2.79 sys=0.00, > > >real=2.79 secs] > >62643.688: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.7892940 secs] [Times: user=2.79 sys=0.00, > > >real=2.79 secs] > >62646.479: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.7766807 secs] [Times: user=2.78 sys=0.00, > > >real=2.78 secs] > >62649.257: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.7796531 secs] [Times: user=2.78 sys=0.00, > > >real=2.78 secs] > >62652.037: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.7687240 secs] [Times: user=2.76 sys=0.00, > > >real=2.76 secs] > >62654.807: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.7613769 secs] [Times: user=2.76 sys=0.00, > > >real=2.76 secs] > >62657.570: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.7712254 secs] [Times: user=2.78 sys=0.00, > > >real=2.78 secs] > >62660.342: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.7968108 secs] [Times: user=2.79 sys=0.00, > > >real=2.79 secs] > >62663.139: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.7924173 secs] [Times: user=2.79 sys=0.00, > > >real=2.79 secs] > >62665.933: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8002912 secs] [Times: user=2.79 sys=0.00, > > >real=2.81 secs] > >62668.736: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8291434 secs] [Times: user=2.82 sys=0.00, > > >real=2.82 secs] > >62671.566: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8527186 secs] [Times: user=2.86 sys=0.00, > > >real=2.85 secs] > >62674.419: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8982825 secs] [Times: user=2.90 sys=0.00, > > >real=2.90 secs] > >62677.318: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9254483 secs] [Times: user=2.93 sys=0.00, > > >real=2.93 secs] > >62680.244: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9707015 secs] [Times: user=2.95 sys=0.00, > > >real=2.96 secs] > >62683.216: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9894145 secs] [Times: user=3.00 sys=0.00, > > >real=3.00 secs] > >62686.206: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9870305 secs] [Times: user=2.98 sys=0.00, > > >real=2.98 secs] > >62689.193: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9884647 secs] [Times: user=2.98 sys=0.00, > > >real=3.00 secs] > >62692.183: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9635276 secs] [Times: user=2.96 sys=0.00, > > >real=2.96 secs] > >62695.147: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9407559 secs] [Times: user=2.93 sys=0.00, > > >real=2.93 secs] > >62698.088: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9299386 secs] [Times: user=2.93 sys=0.00, > > >real=2.93 secs] > >62701.019: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8994903 secs] [Times: user=2.90 sys=0.00, > > >real=2.90 secs] > >62703.919: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9163417 secs] [Times: user=2.92 sys=0.00, > > >real=2.92 secs] > >62706.836: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9216473 secs] [Times: user=2.93 sys=0.00, > > >real=2.93 secs] > >62709.758: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.9052547 secs] [Times: user=2.89 sys=0.00, > > >real=2.90 secs] > >62712.664: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8902824 secs] [Times: user=2.85 sys=0.00, > > >real=2.89 secs] > >62715.555: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8865932 secs] [Times: user=2.87 sys=0.00, > > >real=2.89 secs] > >62718.442: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8605445 secs] [Times: user=2.87 sys=0.00, > > >real=2.87 secs] > >62721.304: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683678K->683678K(699072K)] 781918K->781918K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8662771 secs] [Times: user=2.84 sys=0.00, > > >real=2.86 secs] > >62724.171: [Full GC [PSYoungGen: 98240K->98240K(214720K)] [PSOldGen: > > >683679K->683679K(699072K)] 781919K->781919K(913792K) [PSPermGen: > >49694K->49694K(49984K)], 2.8369076 secs] [Times: user=2.84 sys=0.00, > > >real=2.84 secs] > > > > > > > From John.Rose at Sun.COM Thu Feb 26 11:32:34 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 26 Feb 2009 11:32:34 -0800 Subject: Question on HotSpot JIT and invokeinterface In-Reply-To: <1235548720.3849.14.camel@penberg-laptop> References: <1235548720.3849.14.camel@penberg-laptop> Message-ID: <72CE6C8D-724B-433E-A7E5-17E4C4C156D9@sun.com> On Feb 24, 2009, at 11:58 PM, Pekka Enberg wrote: > There's a nice description of how HotSpot implements JIT'ed > invokeinterface > at HotSpot Internals wiki: > > http://wikis.sun.com/display/HotSpotInternals/InterfaceCalls Please add your discoveries to it! Part of the benefit of the wiki is that people can share their "learning curves", so we don't all have to rediscover the same things. > Unfortunately there are no pointers to the actual code. It's easy enough to make pointers, at least at the file level: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/file/tip/src/cpu/x86/vm/vtableStubs_x86_32.cpp (Too bad URLs can't end with tags-like search terms, as **.cpp#/ create_itable_stub.) > I recently started > looking at how the interface resolution stubs are generated and > spent quite > a lot of time figuring out what was going on! Yes, it takes a lot of time. The wiki is there to help the second person in line. :-) > I think I got it mostly right but thought I thought I'd get a second > opinion. Maybe this is something that could be added to the wiki as > well? It looks good. Please feel free to add it, in some useful form, to the wiki. > --- > > [Assuming 32-bit x86 here.] > > I think it's the VtableStubs::create_itable_stub() function in > src/cpu/x86/vm/vtableStubs_x86_32.cpp. Tracing trough the the > callers in > reverse order, we have: > > VtableStubs::create_itable_stub() > VtableStubs::create_stub() > CompiledIC::set_to_megamorphic() > SharedRuntime::handle_ic_miss_helper() > SharedRuntime::handle_wrong_method_ic_miss() The megamorphic state is the final catch-all state for a CompiledIC (compiled inline cache). The header file that documents the (highly interesting!) state transitions is: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/file/tip/src/share/vm/code/compiledIC.hpp States before megamorphic are clean (fresh from compiler) and monomorphic (common case). An inline cache miss transitions the call site to megamorphic. > and in src/cpu/x86/vm/sharedRuntime_x86_32.cpp we have > > SharedRuntime::generate_stubs() > > that generates a resolve blob that points to > SharedRuntime::handle_wrong_method_ic_miss(): > > _ic_miss_blob = generate_resolve_blob( > CAST_FROM_FN_PTR( > address, SharedRuntime::handle_wrong_method_ic_miss), > "ic_miss_stub"); > > Now the IC miss stub is called if we can't find a method in the > inline cache. > The instruction sequence of _ic_miss_blob is returned by: > > static address SharedRuntime::get_ic_miss_stub() { > assert(_ic_miss_blob!= NULL, "oops"); > return _ic_miss_blob->instructions_begin(); > } > > Looking at a reverse call-graph: > > SharedRuntime::get_ic_miss_stub() > SharedRuntime::generate_i2c2i_adapters() > AdapterHandlerLibrary::get_create_adapter_index() > AdapterHandlerLibrary::get_adapter() > methodOopDesc::make_adapters() > > we can see how a method oop adapter has a pointer to the IC miss stub. The rest of this is wonderful too, but belongs on a new page or pages, such as CallsIntoJava and/or CallTransitions. > To > complete the explanation, lets look at how HotSpot loads a Java > class and jumps > into the main() method: > > src/os/linux/launcher/java.c::main() > src/os/linux/launcher/java.c::CallStaticVoidMethod() > src/share/vm/prims/jni.cpp::jni_invoke_static() > src/share/vm/runtime/javaCalls.cpp::JavaCalls::call() > src/share/vm/runtime/javaCalls.cpp::JavaCalls::call_helper() > > Now JavaCalls::call_helper() does: > > src/share/vm/runtime/stubRoutines.hpp::StubRoutines::call_stub() > > which returns a function pointer to a stub and calls that. The call > stub in > turn delegates to is something called the entry point which is > obtained in JavaCalls::call_helper() as follows: > > address entry_point = method->from_interpreted_entry(); > > Now when a method is compiled into native code, the > > src/share/vm/ci/ciEnv.cpp:ciEnv::register_method() > > function calls > > src/share/vm/oops/methodOop.cpp::methodOopDesc::set_code() > > which sets up _from_interpreted_entry like this: > > mh->_from_interpreted_entry = mh->get_i2c_entry(); > > where get_i2_c_entry() looks like this: > > address methodOopDesc::get_i2c_entry() { > assert(_adapter != NULL, "must have"); > return _adapter->get_i2c_entry(); > } > > The _adapter of type class AdapterHandlerEntry which are created in > > src/cpu/x86/vm/ > sharedRuntime_x86_32.cpp::SharedRuntime::generate_i2c2i_adapters() > > which we know already to jump to a stub returned by > SharedRuntime::get_ic_miss_stub() if a method cannot be found in the > inline cache. > > --- > > That's it! Comments and corrections are most appreciated! Please post! Best wishes, -- John > Regards, > > Pekka -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090226/24dc5a0e/attachment.html From Thomas.Rodriguez at Sun.COM Thu Feb 26 11:55:09 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 26 Feb 2009 11:55:09 -0800 Subject: Question on HotSpot JIT and invokeinterface In-Reply-To: <1235548720.3849.14.camel@penberg-laptop> References: <1235548720.3849.14.camel@penberg-laptop> Message-ID: <2B9C3671-E72F-4055-B81B-F2E0F0EC39B3@sun.com> If you want a full sketch of the process then you're missing one important piece which is the behaviour of the inline cache itself. If an interface call site only ever has one receiver type then we'll never use the itable stub at all. The itable stub is only used once the inline cache misses which means there is more 1 receiver type involved. I think the order that you lay things out is slightly confusing. It feels like it starts in the middle. A description that followed the processing from an unresolved inline cache to a single receiver and then onto a second receiver would be quite nice. The invokevirtual path parallels invokeinterface so you could include that without much trouble. If that seems like more than you want to bite off I'd just suggest structuring your description in the order of what happens during the process and describe where each part comes from when you get to it. You also describe the call graphs as reversed and they don't seem reversed to me. They seem like the natural order you'd describe them in so I'd just leave out the word revered. Also mixing in the description of how main gets invoked seems odd since it's not an interface. Anyway, it looks like a good start at a description. tom On Feb 24, 2009, at 11:58 PM, Pekka Enberg wrote: > Hi all, > > I have a question regarding HotSpot JIT and invokeinterface. > > There's a nice description of how HotSpot implements JIT'ed > invokeinterface > at HotSpot Internals wiki: > > http://wikis.sun.com/display/HotSpotInternals/InterfaceCalls > > Unfortunately there are no pointers to the actual code. I recently > started > looking at how the interface resolution stubs are generated and > spent quite > a lot of time figuring out what was going on! > > I think I got it mostly right but thought I thought I'd get a second > opinion. Maybe this is something that could be added to the wiki as > well? > > --- > > [Assuming 32-bit x86 here.] > > I think it's the VtableStubs::create_itable_stub() function in > src/cpu/x86/vm/vtableStubs_x86_32.cpp. Tracing trough the the > callers in > reverse order, we have: > > VtableStubs::create_itable_stub() > VtableStubs::create_stub() > CompiledIC::set_to_megamorphic() > SharedRuntime::handle_ic_miss_helper() > SharedRuntime::handle_wrong_method_ic_miss() > > and in src/cpu/x86/vm/sharedRuntime_x86_32.cpp we have > > SharedRuntime::generate_stubs() > > that generates a resolve blob that points to > SharedRuntime::handle_wrong_method_ic_miss(): > > _ic_miss_blob = generate_resolve_blob( > CAST_FROM_FN_PTR( > address, SharedRuntime::handle_wrong_method_ic_miss), > "ic_miss_stub"); > > Now the IC miss stub is called if we can't find a method in the > inline cache. > The instruction sequence of _ic_miss_blob is returned by: > > static address SharedRuntime::get_ic_miss_stub() { > assert(_ic_miss_blob!= NULL, "oops"); > return _ic_miss_blob->instructions_begin(); > } > > Looking at a reverse call-graph: > > SharedRuntime::get_ic_miss_stub() > SharedRuntime::generate_i2c2i_adapters() > AdapterHandlerLibrary::get_create_adapter_index() > AdapterHandlerLibrary::get_adapter() > methodOopDesc::make_adapters() > > we can see how a method oop adapter has a pointer to the IC miss > stub. To > complete the explanation, lets look at how HotSpot loads a Java > class and jumps > into the main() method: > > src/os/linux/launcher/java.c::main() > src/os/linux/launcher/java.c::CallStaticVoidMethod() > src/share/vm/prims/jni.cpp::jni_invoke_static() > src/share/vm/runtime/javaCalls.cpp::JavaCalls::call() > src/share/vm/runtime/javaCalls.cpp::JavaCalls::call_helper() > > Now JavaCalls::call_helper() does: > > src/share/vm/runtime/stubRoutines.hpp::StubRoutines::call_stub() > > which returns a function pointer to a stub and calls that. The call > stub in > turn delegates to is something called the entry point which is > obtained in JavaCalls::call_helper() as follows: > > address entry_point = method->from_interpreted_entry(); > > Now when a method is compiled into native code, the > > src/share/vm/ci/ciEnv.cpp:ciEnv::register_method() > > function calls > > src/share/vm/oops/methodOop.cpp::methodOopDesc::set_code() > > which sets up _from_interpreted_entry like this: > > mh->_from_interpreted_entry = mh->get_i2c_entry(); > > where get_i2_c_entry() looks like this: > > address methodOopDesc::get_i2c_entry() { > assert(_adapter != NULL, "must have"); > return _adapter->get_i2c_entry(); > } > > The _adapter of type class AdapterHandlerEntry which are created in > > src/cpu/x86/vm/ > sharedRuntime_x86_32.cpp::SharedRuntime::generate_i2c2i_adapters() > > which we know already to jump to a stub returned by > SharedRuntime::get_ic_miss_stub() if a method cannot be found in the > inline cache. > > --- > > That's it! Comments and corrections are most appreciated! > > Regards, > > Pekka > From Christian.Thalinger at Sun.COM Thu Feb 26 13:56:52 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 26 Feb 2009 22:56:52 +0100 Subject: Request for review (M): 6810672: Comment typos Message-ID: <1235685412.2004.589.camel@localhost.localdomain> http://cr.openjdk.java.net/~twisti/6810672/webrev.00/ From Christian.Thalinger at Sun.COM Thu Feb 26 14:07:31 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 26 Feb 2009 23:07:31 +0100 Subject: Request for review (M): 6778669: Patch from Red Hat -- fixes compilation errors In-Reply-To: <4A9B3091-DE4D-4C82-949E-DDCA0FF98AB1@Sun.COM> References: <1235315926.11128.34.camel@localhost.localdomain> <49A1B30C.5060501@sun.com> <1235334082.11128.44.camel@localhost.localdomain> <17c6771e0902221235h3b670ebds22058ec8adb118b7@mail.gmail.com> <1235407641.11128.98.camel@localhost.localdomain> <1235410237.11128.103.camel@localhost.localdomain> <8B73CF14-A44D-4460-870F-B4D65E204312@sun.com> <1235469506.11128.166.camel@localhost.localdomain> <49A45A82.8040503@sun.com> <1235509145.11128.200.camel@localhost.localdomain> <1235574070.11128.213.camel@localhost.localdomain> <1235587022.1382.1.camel@localhost.localdomain> <1235664121.2004.214.camel@localhost.localdomain> <4A9B3091-DE4D-4C82-949E-DDCA0FF98AB1@Sun.COM> Message-ID: <1235686051.2004.608.camel@localhost.localdomain> On Thu, 2009-02-26 at 08:48 -0800, Tom Rodriguez wrote: > Sounds good. I tried a JPRT run and it failed, so I had to change some minor stuff to get it built with the GCC used. The last run I did was successful. Here is the latest patch: http://cr.openjdk.java.net/~twisti/6778669/webrev.03/ I will submit this if there are no objections. -- Christian From Vladimir.Kozlov at Sun.COM Thu Feb 26 14:35:23 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 26 Feb 2009 14:35:23 -0800 Subject: Request for review (M): 6810672: Comment typos In-Reply-To: <1235685412.2004.589.camel@localhost.localdomain> References: <1235685412.2004.589.camel@localhost.localdomain> Message-ID: <49A7192B.8060402@sun.com> You forgot Peter's suggestion to fix examples in node.cpp: Peter B. Kessler wrote: > - 980 // Example: reshape "X*4" into "X<<1" > - 981 // return new (C,3) LShiftINode( in(1), phase->intcon(1) ); > + 980 // Example: reshape "X*4" into "X<<2" > + 981 // return new (C,3) LShiftINode( in(1), phase->intcon(2) ); > 982 // > 983 // You must call 'phase->transform(X)' on any new Nodes X you make, except > - 984 // for the returned root node. Example: reshape "X*31" with "(X<<5)-1". > - 985 // Node *shift=phase->transform(new(C,3)LShiftINode(in(1),phase->intcon(5))); > - 986 // return new (C,3) AddINode(shift, phase->intcon(-1)); > + 984 // for the returned root node. Example: reshape "X*31" with "(X<<5)-X". > + 985 // Node *shift=phase->transform(new(C,3)LShiftINode(in(1),phase->intcon(5))); > + 986 // return new (C,3) SubINode(shift, in(1)); Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6810672/webrev.00/ > From andrei.pangin at sun.com Thu Feb 26 19:31:00 2009 From: andrei.pangin at sun.com (andrei.pangin at sun.com) Date: Fri, 27 Feb 2009 03:31:00 +0000 Subject: hg: jdk7/hotspot/hotspot: 7 new changesets Message-ID: <20090227033115.0581BE278@hg.openjdk.java.net> Changeset: 69c752d99841 Author: ohair Date: 2009-01-31 17:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/69c752d99841 6799141: Build with --hash-style=both so that binaries can work on SuSE 10 Reviewed-by: tbell ! make/linux/makefiles/gcc.make Changeset: 01ddca3f0730 Author: jcoomes Date: 2009-02-09 13:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/01ddca3f0730 Merge Changeset: 3264b1424f72 Author: apangin Date: 2009-02-15 20:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3264b1424f72 Merge Changeset: a53107650e8b Author: apangin Date: 2009-02-22 17:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a53107650e8b Merge Changeset: 82e4d969e7cb Author: ikrylov Date: 2009-02-19 04:54 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/82e4d969e7cb 6806046: Hotspot build error when compiled from Visual Studio Summary: Define HOTSPOT_LIB_ARCH in the preprocessor flags of the generated projects Reviewed-by: kamg, xlu ! src/share/tools/MakeDeps/BuildConfig.java Changeset: 1b68c738c0d9 Author: apangin Date: 2009-02-22 17:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1b68c738c0d9 Merge Changeset: 7898caac2071 Author: apangin Date: 2009-02-26 14:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7898caac2071 Merge - src/cpu/x86/vm/vm_version_x86_32.cpp - src/cpu/x86/vm/vm_version_x86_32.hpp - src/cpu/x86/vm/vm_version_x86_64.cpp - src/cpu/x86/vm/vm_version_x86_64.hpp From Christian.Thalinger at Sun.COM Thu Feb 26 23:25:23 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 27 Feb 2009 08:25:23 +0100 Subject: Request for review (M): 6810672: Comment typos In-Reply-To: <49A7192B.8060402@sun.com> References: <1235685412.2004.589.camel@localhost.localdomain> <49A7192B.8060402@sun.com> Message-ID: <1235719523.2004.1167.camel@localhost.localdomain> On Thu, 2009-02-26 at 14:35 -0800, Vladimir Kozlov wrote: > You forgot Peter's suggestion to fix examples in node.cpp: Arghhh! I accidentally removed it when I added Tom's changes. -- Christian From john.coomes at sun.com Thu Feb 26 23:33:58 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 27 Feb 2009 07:33:58 +0000 Subject: hg: jdk7/hotspot: Added tag jdk7-b49 for changeset aee93a8992d2 Message-ID: <20090227073358.A0B16E2F2@hg.openjdk.java.net> Changeset: 5111e13e44e5 Author: xdono Date: 2009-02-26 10:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/5111e13e44e5 Added tag jdk7-b49 for changeset aee93a8992d2 ! .hgtags From john.coomes at sun.com Thu Feb 26 23:36:38 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 27 Feb 2009 07:36:38 +0000 Subject: hg: jdk7/hotspot/corba: Added tag jdk7-b49 for changeset d70978bc64bc Message-ID: <20090227073640.575B6E2F7@hg.openjdk.java.net> Changeset: 0edbd0074b02 Author: xdono Date: 2009-02-26 10:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/0edbd0074b02 Added tag jdk7-b49 for changeset d70978bc64bc ! .hgtags From john.coomes at sun.com Thu Feb 26 23:42:00 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 27 Feb 2009 07:42:00 +0000 Subject: hg: jdk7/hotspot/jaxp: Added tag jdk7-b49 for changeset 5c1f24531903 Message-ID: <20090227074203.72D9CE2FC@hg.openjdk.java.net> Changeset: e8514e2be76d Author: xdono Date: 2009-02-26 10:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/e8514e2be76d Added tag jdk7-b49 for changeset 5c1f24531903 ! .hgtags From john.coomes at sun.com Thu Feb 26 23:44:45 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 27 Feb 2009 07:44:45 +0000 Subject: hg: jdk7/hotspot/jaxws: Added tag jdk7-b49 for changeset 18ca864890f3 Message-ID: <20090227074447.48DF1E301@hg.openjdk.java.net> Changeset: 5be52db581f1 Author: xdono Date: 2009-02-26 10:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/5be52db581f1 Added tag jdk7-b49 for changeset 18ca864890f3 ! .hgtags From john.coomes at sun.com Thu Feb 26 23:47:30 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 27 Feb 2009 07:47:30 +0000 Subject: hg: jdk7/hotspot/jdk: Added tag jdk7-b49 for changeset 8311105ea7a3 Message-ID: <20090227074803.CDD3EE306@hg.openjdk.java.net> Changeset: 383d6bebfba6 Author: xdono Date: 2009-02-26 10:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/383d6bebfba6 Added tag jdk7-b49 for changeset 8311105ea7a3 ! .hgtags From john.coomes at sun.com Thu Feb 26 23:56:20 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 27 Feb 2009 07:56:20 +0000 Subject: hg: jdk7/hotspot/langtools: Added tag jdk7-b49 for changeset d17d927ad9bd Message-ID: <20090227075621.C63C2E30B@hg.openjdk.java.net> Changeset: cc69a0495ac5 Author: xdono Date: 2009-02-26 10:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/cc69a0495ac5 Added tag jdk7-b49 for changeset d17d927ad9bd ! .hgtags From gbenson at redhat.com Fri Feb 27 01:58:26 2009 From: gbenson at redhat.com (Gary Benson) Date: Fri, 27 Feb 2009 09:58:26 +0000 Subject: Compiling Object. In-Reply-To: <4EC17452-91DE-4787-B507-37FE9B7BEA35@sun.com> References: <20090225123957.GB3223@redhat.com> <4EC17452-91DE-4787-B507-37FE9B7BEA35@sun.com> Message-ID: <20090227095825.GA3219@redhat.com> Thanks Tom, I did it the way you suggested and it works perfectly. It even fixed a bug I've had for months and was dreading fixing! :) Cheers, Gary Tom Rodriguez wrote: > The new version of the JLS and JVMS changed the point at which > finalizable objects are registered to be finalized. They are now > registered once we reach Object.. This help deal with various > tricks that allow a subclass to execute code before the super > constructor has run which can result in incompletely initialized > objects being registered for finalization. To implement this in the > interpreter a new internal bytecode was added. In the compilers we > treat Object. as an intrinsic and insert the registration call > when we return from it. For example: > > void Parse::return_current(Node* value) { > if (RegisterFinalizersAtInit && > method()->intrinsic_id() == vmIntrinsics::_Object_init) { > call_register_finalizer(); > } > > Conceivably you could modify the ciBytecodeStream to allow > return_register_finalizer to leak through to the parser but that's > more tricky. > > tom > > On Feb 25, 2009, at 4:39 AM, Gary Benson wrote: > > Hi all, > > > > I'm writing a JIT for OpenJDK, and I'm not sure what I should be doing > > when compiling Object.. I was confused to see it scheduled for > > compilation at all, since it's an empty method, but now I see its one > > bytecode is not _return but _return_register_finalizer so of course > > the empty method detector doesn't recognise it. > > > > When it gets compiled, the bytecode is read via a ciBytecodeStream, > > and it seems to be coming through as a _return as I have no code to > > handle _return_register_finalizer and it would have aborted if it got > > that. > > > > Do I need to detect that I'm compiling Object. and special case > > it? > > > > Cheers, > > Gary > > > > -- > > http://gbenson.net/ -- http://gbenson.net/ From gbenson at redhat.com Fri Feb 27 01:59:47 2009 From: gbenson at redhat.com (Gary Benson) Date: Fri, 27 Feb 2009 09:59:47 +0000 Subject: Quick question In-Reply-To: References: <20090226144702.GB8970@redhat.com> Message-ID: <20090227095947.GB3219@redhat.com> Ah, I forgot about asynchronous exceptions... Thanks, Gary Tom Rodriguez wrote: > Async exceptions can be delivered to a thread during a safepoint so > yes you need to check for a pending exception. Check out > JavaThread::check_and_handle_async_exceptions and > JavaThread::handle_special_runtime_exit_condition and > generate_handler_blob in sharedRuntime_.cpp. Generally > speaking if you call into the runtime for any reason you should be > checking for pending exceptions. > > tom > > On Feb 26, 2009, at 6:47 AM, Gary Benson wrote: > > Hi all, > > > > A quick question: is it necessary to check for pending exceptions > > after calling SafepointSynchronize::block? > > > > Cheers, > > Gary > > > > -- > > http://gbenson.net/ -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Fri Feb 27 04:50:32 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 27 Feb 2009 13:50:32 +0100 Subject: Request for review (XXL): 6810672: Comment typos In-Reply-To: <1235685412.2004.589.camel@localhost.localdomain> References: <1235685412.2004.589.camel@localhost.localdomain> Message-ID: <1235739032.2004.1544.camel@localhost.localdomain> On Thu, 2009-02-26 at 22:56 +0100, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6810672/webrev.00/ Tom sent me a list of typos he grep'ed from the sources and I wrote a small script that replaced all of them, hopefully correctly. Almost all are comment changes only, except two code snippets: @@ -2672,9 +2672,9 @@ void PhaseIdealLoop::build_loop_late_pos pinned = false; } if( pinned ) { - IdealLoopTree *choosen_loop = get_loop(n->is_CFG() ? n : get_ctrl(n)); - if( !choosen_loop->_child ) // Inner loop? - choosen_loop->_body.push(n); // Collect inner loops + IdealLoopTree *chosen_loop = get_loop(n->is_CFG() ? n : get_ctrl(n)); + if( !chosen_loop->_child ) // Inner loop? + chosen_loop->_body.push(n); // Collect inner loops return; } } else { // No slot zero @@ -2746,9 +2746,9 @@ void PhaseIdealLoop::build_loop_late_pos set_ctrl(n, least); // Collect inner loop bodies - IdealLoopTree *choosen_loop = get_loop(least); - if( !choosen_loop->_child ) // Inner loop? - choosen_loop->_body.push(n);// Collect inner loops + IdealLoopTree *chosen_loop = get_loop(least); + if( !chosen_loop->_child ) // Inner loop? + chosen_loop->_body.push(n);// Collect inner loops } #ifndef PRODUCT But I think these should be okay. Here is the updated and (now) huge webrev: http://cr.openjdk.java.net/~twisti/6810672/webrev.01/ -- Christian From Vladimir.Kozlov at Sun.COM Fri Feb 27 08:08:34 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 27 Feb 2009 08:08:34 -0800 Subject: Request for review (XXL): 6810672: Comment typos In-Reply-To: <1235739032.2004.1544.camel@localhost.localdomain> References: <1235685412.2004.589.camel@localhost.localdomain> <1235739032.2004.1544.camel@localhost.localdomain> Message-ID: <49A81002.1060806@sun.com> Looks OK. Vladimir Christian Thalinger wrote: > On Thu, 2009-02-26 at 22:56 +0100, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/6810672/webrev.00/ > > Tom sent me a list of typos he grep'ed from the sources and I wrote a > small script that replaced all of them, hopefully correctly. Almost all > are comment changes only, except two code snippets: > > @@ -2672,9 +2672,9 @@ void PhaseIdealLoop::build_loop_late_pos > pinned = false; > } > if( pinned ) { > - IdealLoopTree *choosen_loop = get_loop(n->is_CFG() ? n : get_ctrl(n)); > - if( !choosen_loop->_child ) // Inner loop? > - choosen_loop->_body.push(n); // Collect inner loops > + IdealLoopTree *chosen_loop = get_loop(n->is_CFG() ? n : get_ctrl(n)); > + if( !chosen_loop->_child ) // Inner loop? > + chosen_loop->_body.push(n); // Collect inner loops > return; > } > } else { // No slot zero > @@ -2746,9 +2746,9 @@ void PhaseIdealLoop::build_loop_late_pos > set_ctrl(n, least); > > // Collect inner loop bodies > - IdealLoopTree *choosen_loop = get_loop(least); > - if( !choosen_loop->_child ) // Inner loop? > - choosen_loop->_body.push(n);// Collect inner loops > + IdealLoopTree *chosen_loop = get_loop(least); > + if( !chosen_loop->_child ) // Inner loop? > + chosen_loop->_body.push(n);// Collect inner loops > } > > #ifndef PRODUCT > > But I think these should be okay. Here is the updated and (now) huge > webrev: > > http://cr.openjdk.java.net/~twisti/6810672/webrev.01/ > > -- Christian > From Thomas.Rodriguez at Sun.COM Fri Feb 27 10:16:47 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 27 Feb 2009 10:16:47 -0800 Subject: SuperWord optimization In-Reply-To: <49820C21-ED92-4E85-9272-27E473E258EA@Sun.COM> References: <535236.3158.qm@web30006.mail.mud.yahoo.com> <4149a0430812231021r7e1a600budf99a1b8be4de070@mail.gmail.com> <657532.97748.qm@web30003.mail.mud.yahoo.com> <4149a0430812290953o43f864f7ve9e3496ef565906b@mail.gmail.com> <148719.53851.qm@web30001.mail.mud.yahoo.com> <7D161C9E-CD80-464C-9D2F-507FA600DEDF@sun.com> <49820C21-ED92-4E85-9272-27E473E258EA@Sun.COM> Message-ID: <1426D335-3066-4BE5-910F-87980628B1F4@Sun.COM> So somehow I blew away the original version of this though I still had the pieces that were used to make it, so I spent some time recreating it. I haven't finished all the ad file changes but it's working and spilling 128 bit values into properly aligned stack slots. There's a new ideal type RegQ for quads and a TypeQuad to go along with it. The XMM registers are properly represented at 128 bits wide and the regmasks have been modified to support aligned 128 bit registers. The heap alignment issues still aren't resolved so for the momemt I'm using the unaligned variants for heap access to allow the code to run. It could run with the aligned ones on Nehalem since unaligned memory accesses are fast there. The stack accesses are still using the aligned versions though. The ad file changes are mostly incomplete but they are reasonably straightforward. x86_32.ad is the only one which is even vaguely complete. The most complex set of changes are in the register allocator and type system and those are mostly the way they should be. One problem with superword that these changes highlight is that it doesn't really support multiple vector sizes. Currently you have to pick the size up front and all the code generation has to reflect that choice. To really add 128 bit vector operations I think superword has to be changed to support multiple vector sizes. Otherwise we may miss opportunities with smaller vectors or smaller arrays where the overhead of the larger vector would be greater. This would mean that the vector nodes would have to be told their size when they were created and the ad file would decide how big the vector operation was based on the ideal reg type used. As far as the alignment issues, one platforms like Nehalem where unaligned accesses are as fast as aligned we could simply skip that step. On other platforms we'd need to adjust the alignment preloop to be address based instead of index based. I don't think this is too hard. I guess I'm not holding my breath for 16 byte alignment in the GC. No one is actually working on this code the moment, though it's possible the quad support might go in separately. The full webrev includes support for all the vector math ops but it has only been lightly tested on x86_32. The vector math op support is pretty much exactly what Ross left behind and the rest is all me. Anyway, the very large and very rough webrev is at http://cr.openjdk.java.net/~never/quad for those interested. tom On Jan 5, 2009, at 12:57 PM, John Rose wrote: > I'd love to see that webrev. (You've got some great back-burner > stuff, Tom!) > > An alternative to adding pointer alignment logic (in the compiler > and also the hand-tuned assembly code) is allocating all arrays > above some fixed length (e.g., 10 words) with an additional > alignment constraint. > > This has the advantage of making any pair of large-enough arrays > mutually aligned, if their access indexes are aligned. The compiler > and assembly stubs already have special paths for very short arrays; > these cut-outs could be adapted to take into account the strong > alignment size. Or we could just unswitch the the whole loop (or > predicate it with an uncommon trap, given the right length profile > data). > > -- John > > P.S. In general, if there's an optimization that makes sense mainly > for large arrays, the JVM has the option of allocating large arrays > with special tactics (alignment, chunking, multianewarray layout, > cache line coloring, CPU affinity for work-stealing, etc., etc.). > This option is not yet exercised, except in the simple case of slow- > pathing truly huge arrays, bigger than FastAllocateSizeLimit. This > class of optimizations gets more valuable as CPU-to-memory distances > increase, but it is still waiting for the right PhD student to come > along. > > > On Jan 5, 2009, at 11:39 AM, Tom Rodriguez wrote: > >> I have a workspace that combines Ross's initial work supporting >> arbitrary ALU operations for vectorization with some work I did for >> adding a new RegQ type for 128-bit vector operations. It was >> limping along when I stopped looking at it but I could post a >> webrev of it if there is interest. It's not something I'm working >> on but I'd wanted to bring the parts forward so they didn't get >> completely lost. All the code generation pieces were working and >> the main remaining piece is fixing the loop alignment code to >> support aligning to 128 bit boundaries. The heap is only aligned >> to 64-bits so the alignment code that superword uses needs to >> switch to a pointer alignment calculation instead of using index >> alignment. >> >> Once we add 128 bit vectors we'll need some policy work to choose >> vector sizes based on the code we see. Currently the code assumes >> there is only one vector register size. From Thomas.Rodriguez at Sun.COM Fri Feb 27 10:42:57 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 27 Feb 2009 10:42:57 -0800 Subject: Request for review (XXL): 6810672: Comment typos In-Reply-To: <1235739032.2004.1544.camel@localhost.localdomain> References: <1235685412.2004.589.camel@localhost.localdomain> <1235739032.2004.1544.camel@localhost.localdomain> Message-ID: You went crazier then me. ;) I'd only looked for things in src/share/ vm/opto but I guess misspellings are pretty standard. Looks good. tom On Feb 27, 2009, at 4:50 AM, Christian Thalinger wrote: > On Thu, 2009-02-26 at 22:56 +0100, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/6810672/webrev.00/ > > Tom sent me a list of typos he grep'ed from the sources and I wrote a > small script that replaced all of them, hopefully correctly. Almost > all > are comment changes only, except two code snippets: > > @@ -2672,9 +2672,9 @@ void PhaseIdealLoop::build_loop_late_pos > pinned = false; > } > if( pinned ) { > - IdealLoopTree *choosen_loop = get_loop(n->is_CFG() ? n : > get_ctrl(n)); > - if( !choosen_loop->_child ) // Inner loop? > - choosen_loop->_body.push(n); // Collect inner loops > + IdealLoopTree *chosen_loop = get_loop(n->is_CFG() ? n : > get_ctrl(n)); > + if( !chosen_loop->_child ) // Inner loop? > + chosen_loop->_body.push(n); // Collect inner loops > return; > } > } else { // No slot zero > @@ -2746,9 +2746,9 @@ void PhaseIdealLoop::build_loop_late_pos > set_ctrl(n, least); > > // Collect inner loop bodies > - IdealLoopTree *choosen_loop = get_loop(least); > - if( !choosen_loop->_child ) // Inner loop? > - choosen_loop->_body.push(n);// Collect inner loops > + IdealLoopTree *chosen_loop = get_loop(least); > + if( !chosen_loop->_child ) // Inner loop? > + chosen_loop->_body.push(n);// Collect inner loops > } > > #ifndef PRODUCT > > But I think these should be okay. Here is the updated and (now) huge > webrev: > > http://cr.openjdk.java.net/~twisti/6810672/webrev.01/ > > -- Christian > From imdupeng at gmail.com Fri Feb 27 19:18:33 2009 From: imdupeng at gmail.com (Peng Du) Date: Fri, 27 Feb 2009 21:18:33 -0600 Subject: Hotspot Finalizations Message-ID: Hello, everyone Here is a newbie question: I've added instrumentation code to Hotspot which will collect some runtime information and print them out before VM shuts down. Intuitively, I thought "jni_DestroyJavaVM" is a good place to do the printing. But it did not work as I expected that the printing routine runned simultaneously while Hotspot was interpreting the Java program. And it kept working like that even if I move the printing code to the end of that JNI function. So, the results are obviously incorrect. I know there are multiple threads in Hotspot. and they die one after another upon completions of their work. But isn't jni_DestroyJavaVM the ultimate exit of a VM execution? If not, where should I put my printing routine? Thanks in advance! Peng Du 02/27/2009 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090227/58445767/attachment.html From imdupeng at gmail.com Fri Feb 27 20:24:02 2009 From: imdupeng at gmail.com (Peng Du) Date: Fri, 27 Feb 2009 22:24:02 -0600 Subject: Hotspot Finalizations In-Reply-To: References: Message-ID: Never mind. For the record, before_exit() in java.cpp is the right place. Thanks Peng Du On Fri, Feb 27, 2009 at 9:18 PM, Peng Du wrote: > Hello, everyone > > Here is a newbie question: I've added instrumentation code to Hotspot which > will collect some runtime information and print them out before VM shuts > down. Intuitively, I thought "jni_DestroyJavaVM" is a good place to do the > printing. But it did not work as I expected that the printing routine runned > simultaneously while Hotspot was interpreting the Java program. And it kept > working like that even if I move the printing code to the end of that JNI > function. So, the results are obviously incorrect. > > I know there are multiple threads in Hotspot. and they die one after > another upon completions of their work. But isn't jni_DestroyJavaVM the > ultimate exit of a VM execution? If not, where should I put my printing > routine? Thanks in advance! > > > Peng Du > 02/27/2009 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090227/f74735de/attachment.html From y.s.ramakrishna at sun.com Fri Feb 27 21:11:46 2009 From: y.s.ramakrishna at sun.com (y.s.ramakrishna at sun.com) Date: Sat, 28 Feb 2009 05:11:46 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20090228051154.3845AE492@hg.openjdk.java.net> Changeset: 3698e8f47799 Author: tonyp Date: 2009-02-24 15:50 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3698e8f47799 6804746: G1: guarantee(variance() > -1.0,"variance should be >= 0") (due to evacuation failure) Summary: Under certain circumstances (evacuation failure) the pause time is not communicated to the policy and, as a result, the pause time field is not initialized properly. Reviewed-by: jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: 83ef1482304c Author: jmasa Date: 2009-02-24 22:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/83ef1482304c 6806226: Signed integer overflow in growable array code causes JVM crash Summary: Workaround the overflow by doing the intermediate calculations in an unsigned variable. Reviewed-by: ysr, jcoomes ! src/share/vm/utilities/growableArray.cpp Changeset: 59150d6667e1 Author: jmasa Date: 2009-02-24 22:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/59150d6667e1 Merge Changeset: 1fa16c3565be Author: ysr Date: 2009-02-27 15:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1fa16c3565be Merge