From daniel.daugherty at sun.com Fri Aug 1 00:42:35 2008 From: daniel.daugherty at sun.com (daniel.daugherty at sun.com) Date: Fri, 01 Aug 2008 07:42:35 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20080801074241.C9FA4DDA7@hg.openjdk.java.net> Changeset: 54499b980c23 Author: swamyv Date: 2008-07-29 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/54499b980c23 6710791: Remove files or build from source:maf-1_0.jar, jlfg-1_0.jar Summary: Removed maf-1_0.jar and jlfg-1_0.jar files. Reviewed-by: poonam, jjh ! agent/make/Makefile ! agent/make/bugspot.bat ! agent/make/build.xml ! agent/make/hsdb.bat ! agent/make/hsdb.sh ! agent/make/saenv.bat ! agent/make/saenv.sh ! agent/make/saenv64.bat ! agent/make/saenv64.sh + agent/src/share/classes/com/sun/java/swing/action/AboutAction.java + agent/src/share/classes/com/sun/java/swing/action/ActionManager.java + agent/src/share/classes/com/sun/java/swing/action/ActionUtilities.java + agent/src/share/classes/com/sun/java/swing/action/AlignCenterAction.java + agent/src/share/classes/com/sun/java/swing/action/AlignLeftAction.java + agent/src/share/classes/com/sun/java/swing/action/AlignRightAction.java + agent/src/share/classes/com/sun/java/swing/action/ApplyAction.java + agent/src/share/classes/com/sun/java/swing/action/BackAction.java + agent/src/share/classes/com/sun/java/swing/action/CancelAction.java + agent/src/share/classes/com/sun/java/swing/action/DelegateAction.java + agent/src/share/classes/com/sun/java/swing/action/ExitAction.java + agent/src/share/classes/com/sun/java/swing/action/FileMenu.java + agent/src/share/classes/com/sun/java/swing/action/FinishAction.java + agent/src/share/classes/com/sun/java/swing/action/HelpAction.java + agent/src/share/classes/com/sun/java/swing/action/HelpMenu.java + agent/src/share/classes/com/sun/java/swing/action/NewAction.java + agent/src/share/classes/com/sun/java/swing/action/NextAction.java + agent/src/share/classes/com/sun/java/swing/action/OkAction.java + agent/src/share/classes/com/sun/java/swing/action/OpenAction.java + agent/src/share/classes/com/sun/java/swing/action/SaveAction.java + agent/src/share/classes/com/sun/java/swing/action/SaveAsAction.java + agent/src/share/classes/com/sun/java/swing/action/StateChangeAction.java + agent/src/share/classes/com/sun/java/swing/action/ViewMenu.java + agent/src/share/classes/com/sun/java/swing/ui/CommonMenuBar.java + agent/src/share/classes/com/sun/java/swing/ui/CommonToolBar.java + agent/src/share/classes/com/sun/java/swing/ui/CommonUI.java + agent/src/share/classes/com/sun/java/swing/ui/OkCancelButtonPanel.java + agent/src/share/classes/com/sun/java/swing/ui/OkCancelDialog.java + agent/src/share/classes/com/sun/java/swing/ui/SplashScreen.java + agent/src/share/classes/com/sun/java/swing/ui/StatusBar.java + agent/src/share/classes/com/sun/java/swing/ui/TabsDlg.java + agent/src/share/classes/com/sun/java/swing/ui/ToggleActionPropertyChangeListener.java + agent/src/share/classes/com/sun/java/swing/ui/WizardDlg.java + agent/src/share/classes/images/toolbarButtonGraphics/development/Server16.gif + agent/src/share/classes/images/toolbarButtonGraphics/development/Server24.gif + agent/src/share/classes/images/toolbarButtonGraphics/general/About16.gif + agent/src/share/classes/images/toolbarButtonGraphics/general/About24.gif + agent/src/share/classes/images/toolbarButtonGraphics/general/Delete16.gif + agent/src/share/classes/images/toolbarButtonGraphics/general/Delete24.gif + agent/src/share/classes/images/toolbarButtonGraphics/general/Find16.gif + agent/src/share/classes/images/toolbarButtonGraphics/general/Help16.gif + agent/src/share/classes/images/toolbarButtonGraphics/general/Help24.gif + agent/src/share/classes/images/toolbarButtonGraphics/general/History16.gif + agent/src/share/classes/images/toolbarButtonGraphics/general/History24.gif + agent/src/share/classes/images/toolbarButtonGraphics/general/Information16.gif + agent/src/share/classes/images/toolbarButtonGraphics/general/Information24.gif + agent/src/share/classes/images/toolbarButtonGraphics/general/New16.gif + agent/src/share/classes/images/toolbarButtonGraphics/general/New24.gif + agent/src/share/classes/images/toolbarButtonGraphics/general/Open16.gif + agent/src/share/classes/images/toolbarButtonGraphics/general/Open24.gif + agent/src/share/classes/images/toolbarButtonGraphics/general/Save16.gif + agent/src/share/classes/images/toolbarButtonGraphics/general/Save24.gif + agent/src/share/classes/images/toolbarButtonGraphics/general/SaveAs16.gif + agent/src/share/classes/images/toolbarButtonGraphics/general/SaveAs24.gif + agent/src/share/classes/images/toolbarButtonGraphics/general/Zoom16.gif + agent/src/share/classes/images/toolbarButtonGraphics/general/ZoomIn16.gif + agent/src/share/classes/images/toolbarButtonGraphics/general/ZoomIn24.gif + agent/src/share/classes/images/toolbarButtonGraphics/navigation/Down16.gif + agent/src/share/classes/images/toolbarButtonGraphics/navigation/Up16.gif + agent/src/share/classes/images/toolbarButtonGraphics/text/AlignCenter16.gif + agent/src/share/classes/images/toolbarButtonGraphics/text/AlignCenter24.gif + agent/src/share/classes/images/toolbarButtonGraphics/text/AlignLeft16.gif + agent/src/share/classes/images/toolbarButtonGraphics/text/AlignLeft24.gif + agent/src/share/classes/images/toolbarButtonGraphics/text/AlignRight16.gif + agent/src/share/classes/images/toolbarButtonGraphics/text/AlignRight24.gif - agent/src/share/lib/jlfgr-1_0.jar - agent/src/share/lib/maf-1_0.jar Changeset: c7e8144ef65e Author: dcubed Date: 2008-07-30 14:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c7e8144ef65e Merge - agent/src/share/lib/jlfgr-1_0.jar - agent/src/share/lib/maf-1_0.jar Changeset: 610674f963d2 Author: dcubed Date: 2008-07-31 22:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/610674f963d2 Merge - agent/src/share/lib/jlfgr-1_0.jar - agent/src/share/lib/maf-1_0.jar From Ulf.Zibis at gmx.de Sat Aug 2 08:31:42 2008 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 02 Aug 2008 17:31:42 +0200 Subject: any impact on performance from javac's debug option ? Message-ID: <48947DDE.80700@gmx.de> Hi, does javac's debug option have any impact on the performance of the code ? I can't see any difference after some loops, but is there a difference principally ? Regards, Ulf From linuxhippy at gmail.com Sun Aug 3 06:51:54 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Sun, 3 Aug 2008 15:51:54 +0200 Subject: any impact on performance from javac's debug option ? In-Reply-To: <48947DDE.80700@gmx.de> References: <48947DDE.80700@gmx.de> Message-ID: <194f62550808030651k2281195ci482cd8ae4f1bd7be@mail.gmail.com> Hi, > does javac's debug option have any impact on the performance of the code ? > I can't see any difference after some loops, but is there a difference > principally ? as far as i know, no. lg Clemens From fw at deneb.enyo.de Sun Aug 3 15:55:04 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 04 Aug 2008 00:55:04 +0200 Subject: [patch] fix build on architectures with a signed size_t In-Reply-To: <4895EC16.6030406@ubuntu.com> (Matthias Klose's message of "Sun, 03 Aug 2008 19:34:14 +0200") References: <4895EC16.6030406@ubuntu.com> Message-ID: <87ej55k8tz.fsf@mid.deneb.enyo.de> * Matthias Klose: > attached are three patches to build on architectures with a signed size_t > (s390-linux-gnu). Yuck. Is this really true? Seems so. C99 requires size_t to be unsigned (section 6.5.3.4), and so does POSIX. I suspsect this was also the case in C90, it's not listed as a change in C99. And if it's unsigned in C90, it's unsigned in C++ (and the The C++ Programming Language, 3rd edition, confirms this). In fact, the GNU C++ standard library assumes that std::size_t is unsigned. IIRC, there is code out there which performs security checks (against integer overflows, for instance) and which assumes that size_t is unsigned. Call me insane, but it's the architecture that needs fixing, not OpenJDK. From fw at deneb.enyo.de Sun Aug 3 16:01:04 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 04 Aug 2008 01:01:04 +0200 Subject: [patch] fix build on architectures with a signed size_t In-Reply-To: <87ej55k8tz.fsf@mid.deneb.enyo.de> (Florian Weimer's message of "Mon, 04 Aug 2008 00:55:04 +0200") References: <4895EC16.6030406@ubuntu.com> <87ej55k8tz.fsf@mid.deneb.enyo.de> Message-ID: <877iaxk8jz.fsf@mid.deneb.enyo.de> * Florian Weimer: > * Matthias Klose: > >> attached are three patches to build on architectures with a signed size_t >> (s390-linux-gnu). > > Yuck. Is this really true? Seems so. No, it's not. At least not in the sid chroot on raptor.debian.org. FWIW, my corrected test case is: #include volatile size_t x; main() { x = -1; if (x < 0) puts("broken"); } From fw at deneb.enyo.de Mon Aug 4 04:27:41 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 04 Aug 2008 13:27:41 +0200 Subject: [patch] fix build on architectures with a signed size_t In-Reply-To: <4896E6D2.9030109@redhat.com> (Andrew Haley's message of "Mon, 04 Aug 2008 12:24:02 +0100") References: <4895EC16.6030406@ubuntu.com> <87ej55k8tz.fsf@mid.deneb.enyo.de> <877iaxk8jz.fsf@mid.deneb.enyo.de> <4896E6D2.9030109@redhat.com> Message-ID: <873allf2aa.fsf@mid.deneb.enyo.de> * Andrew Haley: > Florian Weimer wrote: >> * Florian Weimer: >> >>> * Matthias Klose: >>> >>>> attached are three patches to build on architectures with a signed size_t >>>> (s390-linux-gnu). >>> Yuck. Is this really true? Seems so. >> >> No, it's not. > > It's not. I was more concerned with the reality on s390, not what's in the standard. Unfortunately, my first test case was wrong. From fw at deneb.enyo.de Mon Aug 4 07:55:41 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 04 Aug 2008 16:55:41 +0200 Subject: [patch] fix build on architectures with a signed size_t In-Reply-To: <4896E9CA.60008@redhat.com> (Andrew Haley's message of "Mon, 04 Aug 2008 12:36:42 +0100") References: <4895EC16.6030406@ubuntu.com> <87ej55k8tz.fsf@mid.deneb.enyo.de> <877iaxk8jz.fsf@mid.deneb.enyo.de> <4896E6D2.9030109@redhat.com> <873allf2aa.fsf@mid.deneb.enyo.de> <4896E9CA.60008@redhat.com> Message-ID: <8763qgakya.fsf@mid.deneb.enyo.de> * Andrew Haley: >> I was more concerned with the reality on s390, not what's in the >> standard. Unfortunately, my first test case was wrong. > > Is the reality then that GNU C on s/390 is not ISO C compliant? > I didn't know that. It must break a ton of code. Let me repeat: My initial test case was wrong. It reported size_t as signed, when it wasn't. Sorry about that. At least on raptor.debian.org, in the sid chroot, size_t is unsigned. From aph at redhat.com Mon Aug 4 04:24:02 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 04 Aug 2008 12:24:02 +0100 Subject: [patch] fix build on architectures with a signed size_t In-Reply-To: <877iaxk8jz.fsf@mid.deneb.enyo.de> References: <4895EC16.6030406@ubuntu.com> <87ej55k8tz.fsf@mid.deneb.enyo.de> <877iaxk8jz.fsf@mid.deneb.enyo.de> Message-ID: <4896E6D2.9030109@redhat.com> Florian Weimer wrote: > * Florian Weimer: > >> * Matthias Klose: >> >>> attached are three patches to build on architectures with a signed size_t >>> (s390-linux-gnu). >> Yuck. Is this really true? Seems so. > > No, it's not. It's not. 7.17 Common definitions 1 The following types and macros are defined in the standard header . Some are also defined in other headers, as noted in their respective subclauses. 2 The types are ptrdiff_t which is the signed integer type of the result of subtracting two pointers; size_t which is the unsigned integer type of the result of the sizeof operator; Andrew. From doko at ubuntu.com Sun Aug 3 10:34:14 2008 From: doko at ubuntu.com (Matthias Klose) Date: Sun, 03 Aug 2008 19:34:14 +0200 Subject: [patch] fix build on architectures with a signed size_t Message-ID: <4895EC16.6030406@ubuntu.com> attached are three patches to build on architectures with a signed size_t (s390-linux-gnu). - jdk-signed-size_t.diff, there's already a compat SSIZE_T macro in the code, just use it. - hotspot-idx_t-signed-size_t.diff, the BitMap code assumes a unsigned size_t. - hotspot-params-signed-size_t.diff, command line parameters of type size_t currently are not supported. As a workaround, add casts. This may be better addressed. Matthias -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jdk-signed-size_t.diff Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080803/7513da86/attachment.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hotspot-idx_t-signed-size_t.diff Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080803/7513da86/attachment-0001.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hotspot-params-signed-size_t.diff Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080803/7513da86/attachment-0002.ksh From aph at redhat.com Mon Aug 4 04:36:42 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 04 Aug 2008 12:36:42 +0100 Subject: [patch] fix build on architectures with a signed size_t In-Reply-To: <873allf2aa.fsf@mid.deneb.enyo.de> References: <4895EC16.6030406@ubuntu.com> <87ej55k8tz.fsf@mid.deneb.enyo.de> <877iaxk8jz.fsf@mid.deneb.enyo.de> <4896E6D2.9030109@redhat.com> <873allf2aa.fsf@mid.deneb.enyo.de> Message-ID: <4896E9CA.60008@redhat.com> Florian Weimer wrote: > * Andrew Haley: > >> Florian Weimer wrote: >>> * Florian Weimer: >>> >>>> * Matthias Klose: >>>> >>>>> attached are three patches to build on architectures with a signed size_t >>>>> (s390-linux-gnu). >>>> Yuck. Is this really true? Seems so. >>> No, it's not. >> It's not. > > I was more concerned with the reality on s390, not what's in the > standard. Unfortunately, my first test case was wrong. Is the reality then that GNU C on s/390 is not ISO C compliant? I didn't know that. It must break a ton of code. Andrew. From aph at redhat.com Mon Aug 4 04:43:21 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 04 Aug 2008 12:43:21 +0100 Subject: [patch] fix build on architectures with a signed size_t In-Reply-To: <4896E9CA.60008@redhat.com> References: <4895EC16.6030406@ubuntu.com> <87ej55k8tz.fsf@mid.deneb.enyo.de> <877iaxk8jz.fsf@mid.deneb.enyo.de> <4896E6D2.9030109@redhat.com> <873allf2aa.fsf@mid.deneb.enyo.de> <4896E9CA.60008@redhat.com> Message-ID: <4896EB59.5010802@redhat.com> Andrew Haley wrote: > Florian Weimer wrote: >> * Andrew Haley: >> >>> Florian Weimer wrote: >>>> * Florian Weimer: >>>> >>>>> * Matthias Klose: >>>>> >>>>>> attached are three patches to build on architectures with a signed size_t >>>>>> (s390-linux-gnu). >>>>> Yuck. Is this really true? Seems so. >>>> No, it's not. >>> It's not. >> I was more concerned with the reality on s390, not what's in the >> standard. Unfortunately, my first test case was wrong. > > Is the reality then that GNU C on s/390 is not ISO C compliant? > I didn't know that. It must break a ton of code. I don't believe it. Here's s390/linux.h: #undef SIZE_TYPE #define SIZE_TYPE (TARGET_64BIT ? "long unsigned int" : "long unsigned int") #undef PTRDIFF_TYPE #define PTRDIFF_TYPE (TARGET_64BIT ? "long int" : "int") Andrew. From Thomas.Rodriguez at Sun.COM Mon Aug 4 10:42:43 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 04 Aug 2008 10:42:43 -0700 Subject: any impact on performance from javac's debug option ? In-Reply-To: <48947DDE.80700@gmx.de> References: <48947DDE.80700@gmx.de> Message-ID: <3C9D1295-C04B-4EE0-8048-97A4F349E929@sun.com> I looked into this a while back and the only code generation difference with -g is that locals which are declared as final constants actually get code emitted for them. Without -g things like "final int i = 4;" act pretty much like defines so that every use of i is simply replaced with 4. With -g a local is actually allocated and initialized though otherwise the code is the same. In general this won't have any effect on the code either c1 or c2 emit but it does slightly increase the size of the bytecodes. Since both c1 and c2 use bytecode size as a metric for inlining decisions it could cause a method not to be inlined. C1 is probably more sensitive to this since it has no profile feedback in it's inlining decisions. That's the only difference I'm aware of. tom On Aug 2, 2008, at 8:31 AM, Ulf Zibis wrote: > Hi, > > does javac's debug option have any impact on the performance of the > code ? > I can't see any difference after some loops, but is there a difference > principally ? > > Regards, > > Ulf > > > From daniel.daugherty at sun.com Mon Aug 4 11:12:00 2008 From: daniel.daugherty at sun.com (daniel.daugherty at sun.com) Date: Mon, 04 Aug 2008 18:12:00 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20080804181206.005B5D006@hg.openjdk.java.net> Changeset: 7f601f7c9b48 Author: martin Date: 2008-07-31 18:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7f601f7c9b48 6731726: jmap -permstat reports only 50-60% of permgen memory usage. Reviewed-by: swamyv, martin Contributed-by: yamauchi at google.com ! agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java Changeset: f31ba9518910 Author: dcubed Date: 2008-07-31 22:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f31ba9518910 Merge From charles.nutter at sun.com Mon Aug 4 12:53:03 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Mon, 04 Aug 2008 14:53:03 -0500 Subject: any impact on performance from javac's debug option ? In-Reply-To: <3C9D1295-C04B-4EE0-8048-97A4F349E929@sun.com> References: <48947DDE.80700@gmx.de> <3C9D1295-C04B-4EE0-8048-97A4F349E929@sun.com> Message-ID: <48975E1F.20409@sun.com> On a similar note, what about asserts? Do they add to bytecode size and thereby affect inlining decisions? Tom Rodriguez wrote: > I looked into this a while back and the only code generation difference > with -g is that locals which are declared as final constants actually > get code emitted for them. Without -g things like "final int i = 4;" > act pretty much like defines so that every use of i is simply replaced > with 4. With -g a local is actually allocated and initialized though > otherwise the code is the same. In general this won't have any effect > on the code either c1 or c2 emit but it does slightly increase the size > of the bytecodes. Since both c1 and c2 use bytecode size as a metric > for inlining decisions it could cause a method not to be inlined. C1 is > probably more sensitive to this since it has no profile feedback in it's > inlining decisions. That's the only difference I'm aware of. > > tom > > On Aug 2, 2008, at 8:31 AM, Ulf Zibis wrote: > >> Hi, >> >> does javac's debug option have any impact on the performance of the >> code ? >> I can't see any difference after some loops, but is there a difference >> principally ? >> >> Regards, >> >> Ulf >> >> >> > From Thomas.Rodriguez at Sun.COM Mon Aug 4 13:09:41 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 04 Aug 2008 13:09:41 -0700 Subject: any impact on performance from javac's debug option ? In-Reply-To: <48975E1F.20409@sun.com> References: <48947DDE.80700@gmx.de> <3C9D1295-C04B-4EE0-8048-97A4F349E929@sun.com> <48975E1F.20409@sun.com> Message-ID: Unfortunately yes. There's a bug filed about it though I don't remember the id offhand. The compilers should use sizing metrics which take asserts into account, along with having some bytecode specific metrics, but we haven't done any work on this yet. Hiding the existence of asserts is slighly tricky since it requires at least som control flow analysis. tom On Aug 4, 2008, at 12:53 PM, Charles Oliver Nutter wrote: > On a similar note, what about asserts? Do they add to bytecode size > and thereby affect inlining decisions? > > Tom Rodriguez wrote: >> I looked into this a while back and the only code generation >> difference with -g is that locals which are declared as final >> constants actually get code emitted for them. Without -g things >> like "final int i = 4;" act pretty much like defines so that every >> use of i is simply replaced with 4. With -g a local is actually >> allocated and initialized though otherwise the code is the same. >> In general this won't have any effect on the code either c1 or c2 >> emit but it does slightly increase the size of the bytecodes. >> Since both c1 and c2 use bytecode size as a metric for inlining >> decisions it could cause a method not to be inlined. C1 is >> probably more sensitive to this since it has no profile feedback in >> it's inlining decisions. That's the only difference I'm aware of. >> tom >> On Aug 2, 2008, at 8:31 AM, Ulf Zibis wrote: >>> Hi, >>> >>> does javac's debug option have any impact on the performance of >>> the code ? >>> I can't see any difference after some loops, but is there a >>> difference >>> principally ? >>> >>> Regards, >>> >>> Ulf >>> >>> >>> > From John.Rose at Sun.COM Mon Aug 4 13:17:11 2008 From: John.Rose at Sun.COM (John Rose) Date: Mon, 04 Aug 2008 13:17:11 -0700 Subject: any impact on performance from javac's debug option ? In-Reply-To: References: <48947DDE.80700@gmx.de> <3C9D1295-C04B-4EE0-8048-97A4F349E929@sun.com> <48975E1F.20409@sun.com> Message-ID: <806AEC03-F402-4929-BFAF-9D5A63238C5C@sun.com> We've seen cases where performance went down after an assert was added, solely due to an inlining heuristic that flipped. There will always be cases where a semantically null change will cause the heuristics to detune. But as Tom says there are things we want to do to make it happen less often, such as adjusting the sizing metrics to not charge for unused basic blocks. -- John On Aug 4, 2008, at 1:09 PM, Tom Rodriguez wrote: > Unfortunately yes. There's a bug filed about it though I don't > remember the id offhand. The compilers should use sizing metrics > which take asserts into account, along with having some bytecode > specific metrics, but we haven't done any work on this yet. Hiding > the existence of asserts is slighly tricky since it requires at > least som control flow analysis. > > tom > > On Aug 4, 2008, at 12:53 PM, Charles Oliver Nutter wrote: >> On a similar note, what about asserts? Do they add to bytecode >> size and thereby affect inlining decisions? From charles.nutter at sun.com Mon Aug 4 13:26:27 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Mon, 04 Aug 2008 15:26:27 -0500 Subject: any impact on performance from javac's debug option ? In-Reply-To: <806AEC03-F402-4929-BFAF-9D5A63238C5C@sun.com> References: <48947DDE.80700@gmx.de> <3C9D1295-C04B-4EE0-8048-97A4F349E929@sun.com> <48975E1F.20409@sun.com> <806AEC03-F402-4929-BFAF-9D5A63238C5C@sun.com> Message-ID: <489765F3.2060509@sun.com> I asked because I've seen that too...LogCompilation messages about a method being too big when that method consisted almost entirely of an assertion line. Guess I'll have to be more careful about not putting assertions in the hottest, smallest methods like field accessors, eh? John Rose wrote: > We've seen cases where performance went down after an assert was added, > solely due to an inlining heuristic that flipped. There will always be > cases where a semantically null change will cause the heuristics to > detune. But as Tom says there are things we want to do to make it > happen less often, such as adjusting the sizing metrics to not charge > for unused basic blocks. > > -- John > > On Aug 4, 2008, at 1:09 PM, Tom Rodriguez wrote: > >> Unfortunately yes. There's a bug filed about it though I don't >> remember the id offhand. The compilers should use sizing metrics >> which take asserts into account, along with having some bytecode >> specific metrics, but we haven't done any work on this yet. Hiding >> the existence of asserts is slighly tricky since it requires at least >> som control flow analysis. >> >> tom >> >> On Aug 4, 2008, at 12:53 PM, Charles Oliver Nutter wrote: >>> On a similar note, what about asserts? Do they add to bytecode size >>> and thereby affect inlining decisions? From John.Rose at Sun.COM Mon Aug 4 13:56:57 2008 From: John.Rose at Sun.COM (John Rose) Date: Mon, 04 Aug 2008 13:56:57 -0700 Subject: any impact on performance from javac's debug option ? In-Reply-To: <489765F3.2060509@sun.com> References: <48947DDE.80700@gmx.de> <3C9D1295-C04B-4EE0-8048-97A4F349E929@sun.com> <48975E1F.20409@sun.com> <806AEC03-F402-4929-BFAF-9D5A63238C5C@sun.com> <489765F3.2060509@sun.com> Message-ID: <967F3833-0927-47A9-A27C-88C37FA5BA07@Sun.COM> On Aug 4, 2008, at 1:26 PM, Charles Oliver Nutter wrote: > I asked because I've seen that too...LogCompilation messages about > a method being too big when that method consisted almost entirely > of an assertion line. Guess I'll have to be more careful about not > putting assertions in the hottest, smallest methods like field > accessors, eh? The most common cliff to step off of is MaxInlineSize, the size (in bytecodes) beyond which a method is not inlined unless there is strong evidence to the contrary, such as a hot profile. The number is currently 35. Adding an assert to a field accessor method should not kick you over that limit, unless the assert has a complex structure. Here's a rule of thumb, which should remain valid across a wide range of JVMs: If a hot method contains cold paths, factor the code on those paths out into a (private) subroutine. Assert expressions are cold paths, because they are not taken when asserts are disabled. -- John Not so good: String getName() { assert(name.indexOf('/') == name.lastIndexOf('/')); return name; } String getName2() { if (name.length() > 15) throw new RuntimeException("length of name is "+name.length()); return name; } Better: String getName() { assert(!nameHasTwoSlashes()); return name; } private boolean nameHasTwoSlashes() { return name.indexOf('/') != name.lastIndexOf('/'); } String getName2() { if (name.length() > 15) throw nameTooLongException(); return name; } private RuntimeException nameTooLongException() { return new RuntimeException("length of name is "+name.length ()); } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080804/e3d0fb80/attachment.html From charles.nutter at sun.com Mon Aug 4 14:02:39 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Mon, 04 Aug 2008 16:02:39 -0500 Subject: any impact on performance from javac's debug option ? In-Reply-To: <967F3833-0927-47A9-A27C-88C37FA5BA07@Sun.COM> References: <48947DDE.80700@gmx.de> <3C9D1295-C04B-4EE0-8048-97A4F349E929@sun.com> <48975E1F.20409@sun.com> <806AEC03-F402-4929-BFAF-9D5A63238C5C@sun.com> <489765F3.2060509@sun.com> <967F3833-0927-47A9-A27C-88C37FA5BA07@Sun.COM> Message-ID: <48976E6F.90301@sun.com> John Rose wrote: > On Aug 4, 2008, at 1:26 PM, Charles Oliver Nutter wrote: > >> I asked because I've seen that too...LogCompilation messages about a >> method being too big when that method consisted almost entirely of an >> assertion line. Guess I'll have to be more careful about not putting >> assertions in the hottest, smallest methods like field accessors, eh? >> > > The most common cliff to step off of is MaxInlineSize, the size (in > bytecodes) beyond which a method is not inlined unless there is strong > evidence to the contrary, such as a hot profile. The number is > currently 35. Adding an assert to a field accessor method should not > kick you over that limit, unless the assert has a complex structure. > > Here's a rule of thumb, which should remain valid across a wide range of > JVMs: If a hot method contains cold paths, factor the code on those > paths out into a (private) subroutine. Assert expressions are cold > paths, because they are not taken when asserts are disabled. That's the general approach I've been taking...run LogCompilation, look for "too big"s, slice and dice. I hadn't thought of splitting out the assertion checks though, so I'll give that a go. Most of our assertion checks aren't what I'd call complicated as much as comprehensive, in an effort to avoid requiring those checks at all when assertions are off. - Cahrlie From martinrb at google.com Mon Aug 4 14:36:37 2008 From: martinrb at google.com (Martin Buchholz) Date: Mon, 4 Aug 2008 14:36:37 -0700 Subject: any impact on performance from javac's debug option ? In-Reply-To: References: <48947DDE.80700@gmx.de> <3C9D1295-C04B-4EE0-8048-97A4F349E929@sun.com> <48975E1F.20409@sun.com> Message-ID: <1ccfd1c10808041436wc64d520w7d8f24bcd12454fb@mail.gmail.com> FYI: I filed the bug a few years ago http://bugs.sun.com/view_bug.do?bug_id=6445664 6445664: Eliminate remaining performance penalty for using assert where I wrote: Core library maintainers should be encouraged to use assert, so that more bugs could be found running tests with -esa. However, library maintainers are reluctant to do this because of lingering Fear Uncertainty and Doubt that their performance-critical code will run a little slower. One concern is the inlining threshold, which is based on the size of methods based on bytecode, which does not take into account code which is dead because it is conditional on a static final boolean. So library code maintainers fiddle with various inlining and "out"-lining strategies for static final booleans and asserts. private static final boolean flag = ....; void m() { if (flag} { ... } else { ... } } or void m1() { ... } void m2() { ... } void m() { if (flag) m1(); else m2(); } A compiler-maintainer-oriented way of expressing this request is: before any method's size as measured in bytecodes is used for inlining heuristics, make sure a dead-code elimination pass that takes final static booleans (or ints?) into account should be used to derive a better size for using with inlining heuristics. Another issue is the startup cost for computing asserts. Each class containing an assert runs a bit of code to initialize the synthetic static final boolean via a jni call. If every class in the JDK did this, this cost might be significant. Even if the cost is small, the cost is borne by every Java program that uses those classes, which, in the case of some core classes, means every Java program period. Martin On Mon, Aug 4, 2008 at 1:09 PM, Tom Rodriguez wrote: > Unfortunately yes. There's a bug filed about it though I don't remember the > id offhand. From jon.masamitsu at sun.com Mon Aug 4 16:56:03 2008 From: jon.masamitsu at sun.com (jon.masamitsu at sun.com) Date: Mon, 04 Aug 2008 23:56:03 +0000 Subject: hg: jdk7/hotspot/hotspot: 10 new changesets Message-ID: <20080804235623.97C45D105@hg.openjdk.java.net> Changeset: 12eea04c8b06 Author: jmasa Date: 2008-07-09 15:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/12eea04c8b06 6672698: mangle_unused_area() should not remangle the entire heap at each collection. Summary: Maintain a high water mark for the allocations in a space and mangle only up to that high water mark. Reviewed-by: ysr, apetrusenko ! src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/gc_implementation/includeDB_gc_parNew ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/includeDB_gc_shared ! src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/gc_implementation/shared/mutableSpace.hpp + src/share/vm/gc_implementation/shared/spaceDecorator.cpp + src/share/vm/gc_implementation/shared/spaceDecorator.hpp ! src/share/vm/includeDB_core ! src/share/vm/includeDB_features ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/dump.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 15dd2594d08e Author: jcoomes Date: 2008-07-11 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/15dd2594d08e 6718283: existing uses of *_FORMAT_W() were broken by 6521491 Reviewed-by: ysr, pbk ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp Changeset: f88815ca1af1 Author: jcoomes Date: 2008-07-11 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f88815ca1af1 6483129: par compact assertion failure (new_top > bottom) Summary: avoid computing the dense prefix if a space is empty Reviewed-by: pbk, tonyp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp Changeset: 2214b226b7f0 Author: jcoomes Date: 2008-07-11 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2214b226b7f0 6724367: par compact could clear less young gen summary data Reviewed-by: jmasa, apetrusenko ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp Changeset: 9d6a3a6891f8 Author: iveresov Date: 2008-07-14 04:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9d6a3a6891f8 6720130: NUMA allocator: The linux version should search for libnuma.so.1 Summary: Search for libnuma.so.1 on Linux and liblgrp.so.1 on Solaris. Reviewed-by: jmasa ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp Changeset: d6340ab4105b Author: iveresov Date: 2008-07-17 10:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d6340ab4105b 6723228: NUMA allocator: assert(lgrp_id != -1, "No lgrp_id set") 6723229: NUMA allocator: assert(lgrp_num > 0, "There should be at least one locality group") Summary: The fix takes care of the assertion triggered during TLAB resizing after reconfiguration. Also it now handles a defect in the topology graph, in which a single leaf node doesn't have memory. Reviewed-by: jmasa ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/gc_implementation/shared/gcUtil.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp Changeset: 850fdf70db2b Author: jmasa Date: 2008-07-28 15:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/850fdf70db2b Merge ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/includeDB_gc_shared ! src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/gc_implementation/shared/mutableSpace.hpp ! src/share/vm/includeDB_core ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/dump.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: b7f01ad69d30 Author: jmasa Date: 2008-08-04 12:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b7f01ad69d30 Merge - agent/src/share/lib/jlfgr-1_0.jar - agent/src/share/lib/maf-1_0.jar ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/includeDB_core Changeset: 818a18cd69a8 Author: jmasa Date: 2008-07-30 11:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/818a18cd69a8 6730514: assertion failure in mangling code when expanding by 0 bytes Summary: An expansion by 0 bytes was not anticipated when the assertion was composed. Reviewed-by: jjh, jcoomes, apetrusenko ! make/windows/makefiles/defs.make ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/shared/spaceDecorator.cpp ! src/share/vm/memory/compactingPermGenGen.cpp ! src/share/vm/memory/compactingPermGenGen.hpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/generation.hpp Changeset: e8cf9b1f7c93 Author: jmasa Date: 2008-08-04 12:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e8cf9b1f7c93 Merge From Thomas.Rodriguez at Sun.COM Wed Aug 6 12:50:11 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 06 Aug 2008 12:50:11 -0700 Subject: Crash on OS X, soylatte...but couldn't file a bug In-Reply-To: <486D217D.30408@sun.com> References: <486D217D.30408@sun.com> Message-ID: <6BE1E302-DADE-4F63-B380-77D42C8AA813@sun.com> I believe this is 6528763 which was fixed in 6u4 and 7b13. Here's the decoded crash log: V [libjvm.dylib+0x2b83e0];; __ZN21LoaderConstraintTable22find_loader_constraintE12symbolHandle6Handle +0x110 V [libjvm.dylib+0x2b8500];; __ZN21LoaderConstraintTable22find_constrained_klassE12symbolHandle6Handle +0x20 V [libjvm.dylib+0x3607c0];; __ZN16SystemDictionary40find_constrained_instance_or_array_klassE12symbolHandle6HandleP6Thread +0x80 V [libjvm.dylib+0xe526d];; __ZN5ciEnv22get_klass_by_name_implEP7ciKlassP8ciSymbolb+0x1fd V [libjvm.dylib+0xf8039];; __ZN11ciSignatureC2EP7ciKlassP8ciSymbol +0x389 V [libjvm.dylib+0xf8210];; __ZN11ciSignatureC1EP7ciKlassP8ciSymbol +0x20 V [libjvm.dylib+0xecdce];; __ZN8ciMethodC2E12methodHandle+0x28e V [libjvm.dylib+0xecf0d];; __ZN8ciMethodC1E12methodHandle+0x1d V [libjvm.dylib+0xf5586];; __ZN15ciObjectFactory17create_new_objectEP7oopDesc+0x246 V [libjvm.dylib+0xf6345];; __ZN15ciObjectFactory3getEP7oopDesc+0x1b5 V [libjvm.dylib+0xe4f6b];; __ZN5ciEnv22get_method_from_handleEP8_jobject+0xcb V [libjvm.dylib+0x124fcd];; __ZN13CompileBroker25invoke_compiler_on_methodEP11CompileTask+0x2ad V [libjvm.dylib+0x126940];; __ZN13CompileBroker20compiler_thread_loopEv+0x340 V [libjvm.dylib+0x3809d4];; __Z21compiler_thread_entryP10JavaThreadP6Thread+0x14 V [libjvm.dylib+0x389361];; __ZN10JavaThread17thread_main_innerEv+0x71 V [libjvm.dylib+0x38944e];; __ZN10JavaThread3runEv+0xde V [libjvm.dylib+0x2f3bb2];; __Z10java_startP6Thread+0xe2 C [libSystem.B.dylib+0x326f5] _pthread_start+0x141 C [libSystem.B.dylib+0x325b2] thread_start+0x22 tom On Jul 3, 2008, at 11:59 AM, Charles Oliver Nutter wrote: > Dunno if this is the place for it, but I had a segfault today > running JRuby tests and didn't feel right just ignoring it, even > though it appeared only the one time. So I'm tossing it here to make > myself feel better, and on the off chance that the dump contains > something that would be useful. > > This was on OS X 10.5.3 running "soylatte", a ported version of the > Java 6 JRL sources. Not reproducible. > > I've copied Landon Fuller (soylatte maintainer) on this as well. > > ----- > > # > # An unexpected error has been detected by Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x012b83e0, pid=2698, tid=0xb024b000 > # > # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-p3- > landonf_05_dec_2007_22_04-b00 mixed mode) > # Problematic frame: > # V [libjvm.dylib+0x2b83e0] > # > # Please submit bug reports to landonf at bikemonkey.org > # > > --------------- T H R E A D --------------- > > Current thread (0x0082c800): JavaThread "CompilerThread0" daemon > [_thread_in_vm, id=-1339772928] > > siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x006f55cc > > Registers: > EAX=0x006f55cc, EBX=0x01360756, ECX=0x00831a5c, EDX=0x008928d4 > ESP=0xb024a5c0, EBP=0xb024a618, ESI=0x00892b08, EDI=0x000df503 > EIP=0x012b83e0, EFLAGS=0x00010206 > > Top of Stack: (sp=0xb024a5c0) > 0xb024a5c0: 9e78bf89 0082c800 00000000 00831a58 > 0xb024a5d0: 010f9a98 01360556 b024a600 006f55cc > 0xb024a5e0: 00831a58 0082c800 b024a648 00001974 > 0xb024a5f0: 00001974 00831a5c 00831a58 00000000 > 0xb024a600: 00831a58 00831a5c 00000000 b024a630 > 0xb024a610: 00109b50 00831a5c b024a648 012b8500 > 0xb024a620: 00c65208 00000037 00730130 012b8500 > 0xb024a630: 00109b50 00831a58 00831a5c 00000024 > > Instructions: (pc=0x012b83e0) > 0x012b83d0: 00 89 4d c4 8b 4d d8 89 4d d4 8b 45 c4 8b 4d dc > 0x012b83e0: 8b 00 3b 01 74 ba 8b 45 e4 40 89 45 e4 8b 45 c4 > > Stack: [0xb01cb000,0xb024b000), sp=0xb024a5c0, free space=509k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > V [libjvm.dylib+0x2b83e0] > V [libjvm.dylib+0x2b8500] > V [libjvm.dylib+0x3607c0] > V [libjvm.dylib+0xe526d] > V [libjvm.dylib+0xf8039] > V [libjvm.dylib+0xf8210] > V [libjvm.dylib+0xecdce] > V [libjvm.dylib+0xecf0d] > V [libjvm.dylib+0xf5586] > V [libjvm.dylib+0xf6345] > V [libjvm.dylib+0xe4f6b] > V [libjvm.dylib+0x124fcd] > V [libjvm.dylib+0x126940] > V [libjvm.dylib+0x3809d4] > V [libjvm.dylib+0x389361] > V [libjvm.dylib+0x38944e] > V [libjvm.dylib+0x2f3bb2] > C [libSystem.B.dylib+0x326f5] _pthread_start+0x141 > C [libSystem.B.dylib+0x325b2] thread_start+0x22 > > > Current CompileTask: > C1:3469 ruby.jit.ruby.Users.headius.NetBeansProjects.jruby.lib.ruby. > $1_dot_8.webrick.server.initialize30815466_16937640BlockCallback > $block_0$RUBY$__block__xx1.call(Lorg/jruby/runtime/ > ThreadContext;Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/ > runtime/builtin/IRubyObject;)Lorg/jruby/runtime/builtin/IRubyObject; > (14 bytes) > > > --------------- P R O C E S S --------------- > > Java Threads: ( => current thread ) > 0x00c5bc00 JavaThread "Ruby Thread25332399" daemon > [_thread_blocked, id=-1338568704] > 0x00832000 JavaThread "Low Memory Detector" daemon > [_thread_blocked, id=-1339437056] > =>0x0082c800 JavaThread "CompilerThread0" daemon [_thread_in_vm, > id=-1339772928] > 0x00821000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, > id=-1340305408] > 0x0081fc00 JavaThread "Finalizer" daemon [_thread_blocked, > id=-1340641280] > 0x0081b800 JavaThread "Reference Handler" daemon [_thread_blocked, > id=-1340977152] > 0x00800800 JavaThread "main" [_thread_blocked, id=-1341845504] > > Other Threads: > 0x00819000 VMThread [id=-1341313024] > 0x00832c00 WatcherThread [id=-1338904576] > > VM state:synchronizing (normal execution) > > VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event]) > [0x00103190/0x001031c0] Threads_lock - owner thread: 0x00819000 > > Heap > def new generation total 18176K, used 13924K [0x03960000, > 0x04d10000, 0x04d10000) > eden space 16192K, 81% used [0x03960000, 0x046348f0, 0x04930000) > from space 1984K, 39% used [0x04b20000, 0x04be48a0, 0x04d10000) > to space 1984K, 0% used [0x04930000, 0x04930000, 0x04b20000) > tenured generation total 241984K, used 201960K [0x04d10000, > 0x13960000, 0x13960000) > the space 241984K, 83% used [0x04d10000, 0x1124a020, 0x1124a200, > 0x13960000) > compacting perm gen total 43008K, used 42824K [0x13960000, > 0x16360000, 0x17960000) > the space 43008K, 99% used [0x13960000, 0x163322d8, 0x16332400, > 0x16360000) > No shared spaces configured. > > Dynamic libraries: > Error: Cannot print dynamic libraries. > > VM Arguments: > jvm_args: -ea -Xmx256M -Djava.awt.headless=true -Djruby.home=/Users/ > headius/NetBeansProjects/jruby -Djruby.lib=lib - > Djruby.compile.mode=JIT -Djruby.jit.threshold=0 -Djruby.jit.max=-1 - > Djruby.compat.version=ruby1_8 -Djruby.objectspace.enabled=true - > Djruby.runtime.threadlocal=false -Djruby.thread.pool.enabled=false - > Djruby.reflection=false -Djruby.jit.logging.verbose=true - > Demma.coverage.out.file=/Users/headius/NetBeansProjects/jruby/build/ > test-results/coverage.emma -Demma.coverage.out.merge=true > java_command: > org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner > testsfile=/Users/headius/NetBeansProjects/jruby/ > junittestcases1457541522.properties filtertrace=true > haltOnError=false haltOnFailure=true showoutput=true > outputtoformatters=true logtestlistenerevents=true > formatter > = > org > .apache.tools.ant.taskdefs.optional.junit.XMLJUnitResultFormatter,/ > Users/headius/NetBeansProjects/jruby/build/test-results/ > IGNORETHIS.xml > formatter > = > org > .apache.tools.ant.taskdefs.optional.junit.BriefJUnitResultFormatter > crashfile=/Users/headius/NetBeansProjects/jruby/ > junitvmwatcher1541125117.properties propsfile=/Users/headius/ > NetBeansProjects/jruby/junit90313062.properties > Launcher Type: SUN_STANDARD > > Environment Variables: > JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/ > soylatte/Home > PATH=/System/Library/Frameworks/JavaVM.framework/Versions/soylatte/ > Home/bin:/Users/headius/NetBeansProjects/jruby/bin:/bin:/Users/ > headius/NetBeansProjects/rubinius/bin:/bin:/sbin:/usr/bin:/usr/sbin:/ > opt/local/bin:/opt/local/sbin > SHELL=/bin/bash > DISPLAY=/tmp/launch-dlPihr/:0 > DYLD_FALLBACK_LIBRARY_PATH=/System/Library/Frameworks/ > JavaVM.framework/Versions/soylatte/Home/jre/lib/i386/client:/System/ > Library/Frameworks/JavaVM.framework/Versions/soylatte/Home/jre/lib/ > i386:/System/Library/Frameworks/JavaVM.framework/Versions/soylatte/ > Home/jre/../lib/i386:/System/Library/Frameworks/JavaVM.framework/ > Versions/soylatte/Home/jre/lib/i386/server:/System/Library/ > Frameworks/JavaVM.framework/Versions/soylatte/Home/jre/lib/i386:/ > System/Library/Frameworks/JavaVM.framework/Versions/soylatte/Home/ > jre/../lib/i386 > > Signal Handlers: > SIGSEGV: [libjvm.dylib+0x3bfb80], sa_mask[0]=0xfffefeff, > sa_flags=0x00000042 > SIGBUS: [libjvm.dylib+0x3bfb80], sa_mask[0]=0xfffefeff, > sa_flags=0x00000042 > SIGFPE: [libjvm.dylib+0x2ef4e0], sa_mask[0]=0xfffefeff, > sa_flags=0x00000042 > SIGPIPE: [libjvm.dylib+0x2ef4e0], sa_mask[0]=0xfffefeff, > sa_flags=0x00000042 > SIGILL: [libjvm.dylib+0x2ef4e0], sa_mask[0]=0xfffefeff, > sa_flags=0x00000042 > SIGUSR1: SIG_DFL, sa_mask[0]=0x63807efb, sa_flags=0x00000000 > SIGUSR2: [libjvm.dylib+0x2f06d0], sa_mask[0]=0x00000004, > sa_flags=0x00000042 > SIGHUP: [libjvm.dylib+0x2f1a90], sa_mask[0]=0xfffefeff, > sa_flags=0x00000042 > SIGINT: [libjvm.dylib+0x2f1a90], sa_mask[0]=0xfffefeff, > sa_flags=0x00000042 > SIGQUIT: [libjvm.dylib+0x2f1a90], sa_mask[0]=0xfffefeff, > sa_flags=0x00000042 > SIGTERM: [libjvm.dylib+0x2f1a90], sa_mask[0]=0xfffefeff, > sa_flags=0x00000042 > SIGUSR2: [libjvm.dylib+0x2f06d0], sa_mask[0]=0x00000004, > sa_flags=0x00000042 > > > --------------- S Y S T E M --------------- > > OS:Bsd > uname:Darwin 9.3.0 Darwin Kernel Version 9.3.0: Fri May 23 00:49:16 > PDT 2008; root:xnu-1228.5.18~1/RELEASE_I386 i386 > rlimit: STACK 8192k, CORE 0k, NPROC 266, NOFILE 10240 > CPU:total 2 (2 cores per cpu, 1 threads per core) family 6 model 14 > stepping 8, cmov, cx8, fxsr, mmx, sse, sse2, sse3 > > Memory: 4k page, physical 1855496k(463874k free) > > vm_info: Java HotSpot(TM) Client VM (1.6.0_03-p3- > landonf_05_dec_2007_22_04-b00) for bsd-x86, built on Dec 5 2007 > 22:13:24 by "landonf" with gcc 4.0.1 (Apple Inc. build 5465) > From charles.nutter at sun.com Wed Aug 6 14:29:53 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Wed, 06 Aug 2008 16:29:53 -0500 Subject: Crash on OS X, soylatte...but couldn't file a bug In-Reply-To: <6BE1E302-DADE-4F63-B380-77D42C8AA813@sun.com> References: <486D217D.30408@sun.com> <6BE1E302-DADE-4F63-B380-77D42C8AA813@sun.com> Message-ID: <489A17D1.9010306@sun.com> Ok Tom, thanks for the follow-up. Tom Rodriguez wrote: > I believe this is 6528763 which was fixed in 6u4 and 7b13. Here's the > decoded crash log: > > V [libjvm.dylib+0x2b83e0];; > __ZN21LoaderConstraintTable22find_loader_constraintE12symbolHandle6Handle+0x110 > > V [libjvm.dylib+0x2b8500];; > __ZN21LoaderConstraintTable22find_constrained_klassE12symbolHandle6Handle+0x20 > > V [libjvm.dylib+0x3607c0];; > __ZN16SystemDictionary40find_constrained_instance_or_array_klassE12symbolHandle6HandleP6Thread+0x80 > > V [libjvm.dylib+0xe526d];; > __ZN5ciEnv22get_klass_by_name_implEP7ciKlassP8ciSymbolb+0x1fd > V [libjvm.dylib+0xf8039];; __ZN11ciSignatureC2EP7ciKlassP8ciSymbol+0x389 > V [libjvm.dylib+0xf8210];; __ZN11ciSignatureC1EP7ciKlassP8ciSymbol+0x20 > V [libjvm.dylib+0xecdce];; __ZN8ciMethodC2E12methodHandle+0x28e > V [libjvm.dylib+0xecf0d];; __ZN8ciMethodC1E12methodHandle+0x1d > V [libjvm.dylib+0xf5586];; > __ZN15ciObjectFactory17create_new_objectEP7oopDesc+0x246 > V [libjvm.dylib+0xf6345];; __ZN15ciObjectFactory3getEP7oopDesc+0x1b5 > V [libjvm.dylib+0xe4f6b];; > __ZN5ciEnv22get_method_from_handleEP8_jobject+0xcb > V [libjvm.dylib+0x124fcd];; > __ZN13CompileBroker25invoke_compiler_on_methodEP11CompileTask+0x2ad > V [libjvm.dylib+0x126940];; > __ZN13CompileBroker20compiler_thread_loopEv+0x340 > V [libjvm.dylib+0x3809d4];; > __Z21compiler_thread_entryP10JavaThreadP6Thread+0x14 > V [libjvm.dylib+0x389361];; __ZN10JavaThread17thread_main_innerEv+0x71 > V [libjvm.dylib+0x38944e];; __ZN10JavaThread3runEv+0xde > V [libjvm.dylib+0x2f3bb2];; __Z10java_startP6Thread+0xe2 > C [libSystem.B.dylib+0x326f5] _pthread_start+0x141 > C [libSystem.B.dylib+0x325b2] thread_start+0x22 > > > tom > > On Jul 3, 2008, at 11:59 AM, Charles Oliver Nutter wrote: > >> Dunno if this is the place for it, but I had a segfault today running >> JRuby tests and didn't feel right just ignoring it, even though it >> appeared only the one time. So I'm tossing it here to make myself feel >> better, and on the off chance that the dump contains something that >> would be useful. >> >> This was on OS X 10.5.3 running "soylatte", a ported version of the >> Java 6 JRL sources. Not reproducible. >> >> I've copied Landon Fuller (soylatte maintainer) on this as well. >> >> ----- >> >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x012b83e0, pid=2698, tid=0xb024b000 >> # >> # Java VM: Java HotSpot(TM) Client VM >> (1.6.0_03-p3-landonf_05_dec_2007_22_04-b00 mixed mode) >> # Problematic frame: >> # V [libjvm.dylib+0x2b83e0] >> # >> # Please submit bug reports to landonf at bikemonkey.org >> # >> >> --------------- T H R E A D --------------- >> >> Current thread (0x0082c800): JavaThread "CompilerThread0" daemon >> [_thread_in_vm, id=-1339772928] >> >> siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x006f55cc >> >> Registers: >> EAX=0x006f55cc, EBX=0x01360756, ECX=0x00831a5c, EDX=0x008928d4 >> ESP=0xb024a5c0, EBP=0xb024a618, ESI=0x00892b08, EDI=0x000df503 >> EIP=0x012b83e0, EFLAGS=0x00010206 >> >> Top of Stack: (sp=0xb024a5c0) >> 0xb024a5c0: 9e78bf89 0082c800 00000000 00831a58 >> 0xb024a5d0: 010f9a98 01360556 b024a600 006f55cc >> 0xb024a5e0: 00831a58 0082c800 b024a648 00001974 >> 0xb024a5f0: 00001974 00831a5c 00831a58 00000000 >> 0xb024a600: 00831a58 00831a5c 00000000 b024a630 >> 0xb024a610: 00109b50 00831a5c b024a648 012b8500 >> 0xb024a620: 00c65208 00000037 00730130 012b8500 >> 0xb024a630: 00109b50 00831a58 00831a5c 00000024 >> >> Instructions: (pc=0x012b83e0) >> 0x012b83d0: 00 89 4d c4 8b 4d d8 89 4d d4 8b 45 c4 8b 4d dc >> 0x012b83e0: 8b 00 3b 01 74 ba 8b 45 e4 40 89 45 e4 8b 45 c4 >> >> Stack: [0xb01cb000,0xb024b000), sp=0xb024a5c0, free space=509k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >> C=native code) >> V [libjvm.dylib+0x2b83e0] >> V [libjvm.dylib+0x2b8500] >> V [libjvm.dylib+0x3607c0] >> V [libjvm.dylib+0xe526d] >> V [libjvm.dylib+0xf8039] >> V [libjvm.dylib+0xf8210] >> V [libjvm.dylib+0xecdce] >> V [libjvm.dylib+0xecf0d] >> V [libjvm.dylib+0xf5586] >> V [libjvm.dylib+0xf6345] >> V [libjvm.dylib+0xe4f6b] >> V [libjvm.dylib+0x124fcd] >> V [libjvm.dylib+0x126940] >> V [libjvm.dylib+0x3809d4] >> V [libjvm.dylib+0x389361] >> V [libjvm.dylib+0x38944e] >> V [libjvm.dylib+0x2f3bb2] >> C [libSystem.B.dylib+0x326f5] _pthread_start+0x141 >> C [libSystem.B.dylib+0x325b2] thread_start+0x22 >> >> >> Current CompileTask: >> C1:3469 >> ruby.jit.ruby.Users.headius.NetBeansProjects.jruby.lib.ruby.$1_dot_8.webrick.server.initialize30815466_16937640BlockCallback$block_0$RUBY$__block__xx1.call(Lorg/jruby/runtime/ThreadContext;Lorg/jruby/runtime/builtin/IRubyObject;Lorg/jruby/runtime/builtin/IRubyObject;)Lorg/jruby/runtime/builtin/IRubyObject; >> (14 bytes) >> >> >> --------------- P R O C E S S --------------- >> >> Java Threads: ( => current thread ) >> 0x00c5bc00 JavaThread "Ruby Thread25332399" daemon [_thread_blocked, >> id=-1338568704] >> 0x00832000 JavaThread "Low Memory Detector" daemon [_thread_blocked, >> id=-1339437056] >> =>0x0082c800 JavaThread "CompilerThread0" daemon [_thread_in_vm, >> id=-1339772928] >> 0x00821000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, >> id=-1340305408] >> 0x0081fc00 JavaThread "Finalizer" daemon [_thread_blocked, >> id=-1340641280] >> 0x0081b800 JavaThread "Reference Handler" daemon [_thread_blocked, >> id=-1340977152] >> 0x00800800 JavaThread "main" [_thread_blocked, id=-1341845504] >> >> Other Threads: >> 0x00819000 VMThread [id=-1341313024] >> 0x00832c00 WatcherThread [id=-1338904576] >> >> VM state:synchronizing (normal execution) >> >> VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event]) >> [0x00103190/0x001031c0] Threads_lock - owner thread: 0x00819000 >> >> Heap >> def new generation total 18176K, used 13924K [0x03960000, >> 0x04d10000, 0x04d10000) >> eden space 16192K, 81% used [0x03960000, 0x046348f0, 0x04930000) >> from space 1984K, 39% used [0x04b20000, 0x04be48a0, 0x04d10000) >> to space 1984K, 0% used [0x04930000, 0x04930000, 0x04b20000) >> tenured generation total 241984K, used 201960K [0x04d10000, >> 0x13960000, 0x13960000) >> the space 241984K, 83% used [0x04d10000, 0x1124a020, 0x1124a200, >> 0x13960000) >> compacting perm gen total 43008K, used 42824K [0x13960000, >> 0x16360000, 0x17960000) >> the space 43008K, 99% used [0x13960000, 0x163322d8, 0x16332400, >> 0x16360000) >> No shared spaces configured. >> >> Dynamic libraries: >> Error: Cannot print dynamic libraries. >> >> VM Arguments: >> jvm_args: -ea -Xmx256M -Djava.awt.headless=true >> -Djruby.home=/Users/headius/NetBeansProjects/jruby -Djruby.lib=lib >> -Djruby.compile.mode=JIT -Djruby.jit.threshold=0 -Djruby.jit.max=-1 >> -Djruby.compat.version=ruby1_8 -Djruby.objectspace.enabled=true >> -Djruby.runtime.threadlocal=false -Djruby.thread.pool.enabled=false >> -Djruby.reflection=false -Djruby.jit.logging.verbose=true >> -Demma.coverage.out.file=/Users/headius/NetBeansProjects/jruby/build/test-results/coverage.emma >> -Demma.coverage.out.merge=true >> java_command: >> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner >> testsfile=/Users/headius/NetBeansProjects/jruby/junittestcases1457541522.properties >> filtertrace=true haltOnError=false haltOnFailure=true showoutput=true >> outputtoformatters=true logtestlistenerevents=true >> formatter=org.apache.tools.ant.taskdefs.optional.junit.XMLJUnitResultFormatter,/Users/headius/NetBeansProjects/jruby/build/test-results/IGNORETHIS.xml >> formatter=org.apache.tools.ant.taskdefs.optional.junit.BriefJUnitResultFormatter >> crashfile=/Users/headius/NetBeansProjects/jruby/junitvmwatcher1541125117.properties >> propsfile=/Users/headius/NetBeansProjects/jruby/junit90313062.properties >> Launcher Type: SUN_STANDARD >> >> Environment Variables: >> JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/soylatte/Home >> >> PATH=/System/Library/Frameworks/JavaVM.framework/Versions/soylatte/Home/bin:/Users/headius/NetBeansProjects/jruby/bin:/bin:/Users/headius/NetBeansProjects/rubinius/bin:/bin:/sbin:/usr/bin:/usr/sbin:/opt/local/bin:/opt/local/sbin >> >> SHELL=/bin/bash >> DISPLAY=/tmp/launch-dlPihr/:0 >> DYLD_FALLBACK_LIBRARY_PATH=/System/Library/Frameworks/JavaVM.framework/Versions/soylatte/Home/jre/lib/i386/client:/System/Library/Frameworks/JavaVM.framework/Versions/soylatte/Home/jre/lib/i386:/System/Library/Frameworks/JavaVM.framework/Versions/soylatte/Home/jre/../lib/i386:/System/Library/Frameworks/JavaVM.framework/Versions/soylatte/Home/jre/lib/i386/server:/System/Library/Frameworks/JavaVM.framework/Versions/soylatte/Home/jre/lib/i386:/System/Library/Frameworks/JavaVM.framework/Versions/soylatte/Home/jre/../lib/i386 >> >> >> Signal Handlers: >> SIGSEGV: [libjvm.dylib+0x3bfb80], sa_mask[0]=0xfffefeff, >> sa_flags=0x00000042 >> SIGBUS: [libjvm.dylib+0x3bfb80], sa_mask[0]=0xfffefeff, >> sa_flags=0x00000042 >> SIGFPE: [libjvm.dylib+0x2ef4e0], sa_mask[0]=0xfffefeff, >> sa_flags=0x00000042 >> SIGPIPE: [libjvm.dylib+0x2ef4e0], sa_mask[0]=0xfffefeff, >> sa_flags=0x00000042 >> SIGILL: [libjvm.dylib+0x2ef4e0], sa_mask[0]=0xfffefeff, >> sa_flags=0x00000042 >> SIGUSR1: SIG_DFL, sa_mask[0]=0x63807efb, sa_flags=0x00000000 >> SIGUSR2: [libjvm.dylib+0x2f06d0], sa_mask[0]=0x00000004, >> sa_flags=0x00000042 >> SIGHUP: [libjvm.dylib+0x2f1a90], sa_mask[0]=0xfffefeff, >> sa_flags=0x00000042 >> SIGINT: [libjvm.dylib+0x2f1a90], sa_mask[0]=0xfffefeff, >> sa_flags=0x00000042 >> SIGQUIT: [libjvm.dylib+0x2f1a90], sa_mask[0]=0xfffefeff, >> sa_flags=0x00000042 >> SIGTERM: [libjvm.dylib+0x2f1a90], sa_mask[0]=0xfffefeff, >> sa_flags=0x00000042 >> SIGUSR2: [libjvm.dylib+0x2f06d0], sa_mask[0]=0x00000004, >> sa_flags=0x00000042 >> >> >> --------------- S Y S T E M --------------- >> >> OS:Bsd >> uname:Darwin 9.3.0 Darwin Kernel Version 9.3.0: Fri May 23 00:49:16 >> PDT 2008; root:xnu-1228.5.18~1/RELEASE_I386 i386 >> rlimit: STACK 8192k, CORE 0k, NPROC 266, NOFILE 10240 >> CPU:total 2 (2 cores per cpu, 1 threads per core) family 6 model 14 >> stepping 8, cmov, cx8, fxsr, mmx, sse, sse2, sse3 >> >> Memory: 4k page, physical 1855496k(463874k free) >> >> vm_info: Java HotSpot(TM) Client VM >> (1.6.0_03-p3-landonf_05_dec_2007_22_04-b00) for bsd-x86, built on Dec >> 5 2007 22:13:24 by "landonf" with gcc 4.0.1 (Apple Inc. build 5465) >> > From andrei.pangin at sun.com Thu Aug 7 06:30:36 2008 From: andrei.pangin at sun.com (andrei.pangin at sun.com) Date: Thu, 07 Aug 2008 13:30:36 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20080807133044.5A03BD531@hg.openjdk.java.net> Changeset: 6f17a7c9f8b4 Author: xlu Date: 2008-08-01 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6f17a7c9f8b4 6719981: Update Hotspot Windows os_win32 for windows XP 64 bit and windows 2008 Reviewed-by: dholmes, kamg ! src/os/windows/vm/os_windows.cpp Changeset: f7e6d42d9323 Author: xlu Date: 2008-08-01 15:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f7e6d42d9323 6618886: Anonymous objects can be destructed immediately and so should not be used Reviewed-by: dholmes, kamg ! src/os/solaris/vm/osThread_solaris.cpp Changeset: 2bb5ef5c8a2d Author: coleenp Date: 2008-08-04 14:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2bb5ef5c8a2d 6732819: Turn off compressed oops by default for now Summary: A bug in compressed oops is preventing jdk build (pack200) Reviewed-by: never, phh ! src/share/vm/runtime/arguments.cpp Changeset: 8f5520445685 Author: apangin Date: 2008-08-06 19:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8f5520445685 Merge - agent/src/share/lib/jlfgr-1_0.jar - agent/src/share/lib/maf-1_0.jar ! src/share/vm/runtime/arguments.cpp From David.Cox at Sun.COM Fri Aug 8 16:44:15 2008 From: David.Cox at Sun.COM (David Cox) Date: Fri, 08 Aug 2008 16:44:15 -0700 Subject: CAUTION: don't pull from hotspot, hotspot-rt or hotspot-svc repositories Message-ID: <489CDA4F.1030408@sun.com> My apologies, but we've experienced a glitch with our mercurial usage and request that you avoid pulling from these three repositories until the issue can be resolved: jdk7/hotspot/hotspot jdk7/hotspot-rt/hotspot jdk7/hotspot-svc/hotspot Each of these contains a change set that fixes 6732819. The problem is that jdk7/jdk7/hotspot contains a different change set that also addresses 6732819. To fix this problem, we intend to roll back the above three repos to the point that they no longer include changes for 6732819 and then sync them with jdk7/jdk7/hotspot. This should happen later tonight; no later than Monday for sure. Until then, please don't update any clones of the "contaminated" hotspot repos that you may have. If you already have a contaminated clone, you'll need to fix it. I'll let others who actually work with Mercurial discuss how to do that. Dave From Erik.Trimble at Sun.COM Fri Aug 8 18:22:44 2008 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Fri, 08 Aug 2008 18:22:44 -0700 Subject: CRTITICAL: Hotspot, Hotspot-RT, and Hotspot-Svc repositories being rolled back Message-ID: <489CF164.7060201@sun.com> IF YOU HAVE CLONES OF ANY OF THE FOLLOWING REPOSITORIES, PLEASE READ THIS IMPORTANT MESSAGE: http://hg.openjdk.java.net/jdk7/hotspot/hotspot http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot http://hg.openjdk.java.net/jdk7/hotspot-svc/hotspot Due to a mistake in our internal promotion tree, two mercurial changesets with the same BugID crept into different repositories in the same promotion tree. This is not a circumstance that should occur, and we're adjusting our process to help avoid this kind of mistake again. Specifically, the conflicting changesets are: In http://hg.openjdk.java.net/jdk7/hotspot/hotspot changeset: 272:2bb5ef5c8a2d user: coleenp date: Mon Aug 04 14:17:47 2008 -0700 summary: 6732819: Turn off compressed oops by default for now In http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot changeset: 240:2bb5ef5c8a2d tag: tip user: coleenp date: Mon Aug 04 14:17:47 2008 -0700 summary: 6732819: Turn off compressed oops by default for now In http://hg.openjdk.java.net/jdk7/hotspot-svc/hotspot changeset: 272:2bb5ef5c8a2d user: coleenp date: Mon Aug 04 14:17:47 2008 -0700 summary: 6732819: Turn off compressed oops by default for now These changesets will be REMOVED by a repository rollback - that is, we will roll these three repositories back to an earlier snapshot without the changesets. In the processes, several other changesets which were integrated will also be removed. THESE CHANGESETS WILL BE QUICKLY RE-INTEGRATED. The correct changeset is currently in http://hg.openjdk.java.net/jdk7/jdk7/hotspot changeset: 239:b727c32788a9 tag: jdk7-b32 user: trims date: Fri Aug 01 18:51:27 2008 -0700 summary: 6732819: Turn off compressed oops by default for now ##### DOES THIS AFFECT YOU: ##### You may have to make some adjustments to your clone repositories IF you meet the following conditions: (1) You have a local clone of any of these three repositories: http://hg.openjdk.java.net/jdk7/hotspot/hotspot http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot http://hg.openjdk.java.net/jdk7/hotspot-svc/hotspot (2) You have pulled down from them in the last 5 days AND received the offending changeset. To determine if you have the offending changeset, run the following command in each repository: hg log | grep 2bb5ef5c8a2d If this command returns something, your clone has been infected with the bad changeset. ##### WHAT DO YOU DO? ##### (1) Do not pull or clone from any of the affected repositories until a message later tonight is sent, indicating that the repositories have been successfully rolled back. (2) A later message will be sent with instructions as to how to clean up your existing repositories, AFTER the rollback has been completed. Once again, we apologize for the inconvenience this has caused, and we are working hard to avoid this kind of problem in the future. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From Erik.Trimble at Sun.COM Fri Aug 8 22:38:53 2008 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Fri, 08 Aug 2008 22:38:53 -0700 Subject: UPDATE: [RE: CRTITICAL: Hotspot, Hotspot-RT, and Hotspot-Svc repositories being rolled back] In-Reply-To: <489CF164.7060201@sun.com> References: <489CF164.7060201@sun.com> Message-ID: <489D2D6D.3080200@sun.com> A further update on this issue: The rollback is temporarily in limbo, as we are experiencing other issues which require our systems personnel's attention right now. The repositories are still in the Wrong State, so please do NOT pull from them until additional notice is sent out. Sorry! -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From Ulf.Zibis at gmx.de Sun Aug 10 15:29:57 2008 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 11 Aug 2008 00:29:57 +0200 Subject: any impact on performance from javac's debug option ? In-Reply-To: <1ccfd1c10808041436wc64d520w7d8f24bcd12454fb@mail.gmail.com> References: <48947DDE.80700@gmx.de> <3C9D1295-C04B-4EE0-8048-97A4F349E929@sun.com> <48975E1F.20409@sun.com> <1ccfd1c10808041436wc64d520w7d8f24bcd12454fb@mail.gmail.com> Message-ID: <489F6BE5.5070700@gmx.de> Much thanks for this interesting discussion. This reminds me to post an other question regarding inlining. More about it next days. -Ulf Am 04.08.2008 23:36, Martin Buchholz schrieb: > FYI: I filed the bug a few years ago > > http://bugs.sun.com/view_bug.do?bug_id=6445664 > 6445664: Eliminate remaining performance penalty for using assert > > where I wrote: > > Core library maintainers should be encouraged to use assert, > so that more bugs could be found running tests with -esa. > However, library maintainers are reluctant to do this because of > lingering Fear Uncertainty and Doubt that their performance-critical > code will run a little slower. > > One concern is the inlining threshold, which is based on the size of > methods based on bytecode, which does not take into account code which > is dead because it is conditional on a static final boolean. > > So library code maintainers fiddle with various inlining and "out"-lining > strategies for static final booleans and asserts. > > private static final boolean flag = ....; > > void m() { if (flag} { ... } else { ... } } > or > void m1() { ... } void m2() { ... } void m() { if (flag) m1(); else m2(); } > > A compiler-maintainer-oriented way of expressing this request is: > before any method's size as measured in bytecodes is used > for inlining heuristics, make sure a dead-code elimination pass > that takes final static booleans (or ints?) into account should > be used to derive a better size for using with inlining heuristics. > > Another issue is the startup cost for computing asserts. > Each class containing an assert runs a bit of code to initialize the > synthetic static final boolean via a jni call. If every class in the JDK > did this, this cost might be significant. Even if the cost is small, the > cost is borne by every Java program that uses those classes, which, in the > case of some core classes, means every Java program period. > > Martin > > On Mon, Aug 4, 2008 at 1:09 PM, Tom Rodriguez wrote: > >> Unfortunately yes. There's a bug filed about it though I don't remember the >> id offhand. >> > > > From erik.trimble at sun.com Sun Aug 10 20:53:33 2008 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Mon, 11 Aug 2008 03:53:33 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20080811035339.9AC16DC88@hg.openjdk.java.net> Changeset: 6f17a7c9f8b4 Author: xlu Date: 2008-08-01 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6f17a7c9f8b4 6719981: Update Hotspot Windows os_win32 for windows XP 64 bit and windows 2008 Reviewed-by: dholmes, kamg ! src/os/windows/vm/os_windows.cpp Changeset: f7e6d42d9323 Author: xlu Date: 2008-08-01 15:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f7e6d42d9323 6618886: Anonymous objects can be destructed immediately and so should not be used Reviewed-by: dholmes, kamg ! src/os/solaris/vm/osThread_solaris.cpp Changeset: 4fa67937726c Author: trims Date: 2008-08-10 13:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4fa67937726c Merge - agent/src/share/lib/jlfgr-1_0.jar - agent/src/share/lib/maf-1_0.jar From Erik.Trimble at Sun.COM Sun Aug 10 21:01:13 2008 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Sun, 10 Aug 2008 21:01:13 -0700 Subject: IMPORTANT: Cleaning Up after the Hotspot repository rollbacks Message-ID: <489FB989.9050506@sun.com> This message is for those people who have a local clone of any of the following repositories: http://hg.openjdk.java.net/jdk7/hotspot/hotspot http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot http://hg.openjdk.java.net/jdk7/hotspot-svc/hotspot AND who have pulled down an incorrect changeset that was removed during tonight's rollback. To check if you have the offending changeset, in each local repository, run this command: % hg log | grep 2bb5ef5c8a2d Any output from this command indicates that your repository has been contaminated. ### HOW DO I FIX THIS? #### There are four cases; please following the appropriate section: CASE #1: You have no committed or uncommitted new work in the repository that you haven't already pushed to the hg.openjdk.java.net repository SOLUTION: Re-pull the repository from http://hg.openjdk.java.net This is the fastest, easiest solution - if you have no new work, simply get a clean copy. CASE #2: You have committed one or more changesets of your own work into the contaminated local repository SOLUTION: Clone a new copy of the repository from http://hg.openjdk.java.net, then apply your changesets to that new copy. Step 1: clone a fresh copy to Step 2: change directory to your old, contaminated repo: % cd Step 3: use 'hg outgoing' to discover which changeset IDs you have created since the last push to the repository Step 4: For each changeset of your work, do the following: % hg export -g -o /tmp/changesetID changesetID Step 5: change directory to Step 6: For each of your changesets, do the following: % hg import -p 1 /tmp/changesetID You are now up-to-date and ready to work. In a limited number of cases, where your work was based against an old branch of the repository, you may have problems with above procedure. Please send an email to this list regarding your problems, and someone will contact you shortly to help with the procedure. CASE #3: You have new work in the contaminated repository, but have not committed yet (i.e. you do not have a changeset of your work). SOLUTION: Create a patch using your working files, and apply that patch to a fresh clone from http://hg.openjdk.java.net Step 1: clone a fresh copy to Step 2: change directory to your old, contaminated repo: % cd Step 3: Run this command: % hg diff -g > /tmp/new_work.patch Step 4: change directory to the new repo: % cd Step 5: Using GNU patch, apply your changes: % patch -p 1 -i /tmp/new_work.patch CASE #4: You have both committed changesets, and uncommitted work in the contaminated local repository. SOLUTION: Follow the procedure in Case #2 to update your changesets, then follow the procedure in Case #3 to migrate your uncommitted working files. Once again, we apologize for the inconvenience this rollback has caused. If you have any questions regarding this rollback, or the above procedures to repair your local repositories, please send email to this list (not to me), and we will try to reply promptly. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From erik.trimble at sun.com Mon Aug 11 00:36:00 2008 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Mon, 11 Aug 2008 07:36:00 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20080811073608.27F1FDCA9@hg.openjdk.java.net> Changeset: b727c32788a9 Author: trims Date: 2008-08-01 18:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b727c32788a9 6732819: Turn off compressed oops by default for now Summary: Workaround for CompOops bug Reviewed-by: coleenp ! src/share/vm/runtime/arguments.cpp Changeset: 585535ec8a14 Author: xdono Date: 2008-08-04 13:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/585535ec8a14 Added tag jdk7-b32 for changeset b727c32788a9 ! .hgtags Changeset: aa8f54688692 Author: trims Date: 2008-08-10 21:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/aa8f54688692 Merge - agent/src/share/lib/jlfgr-1_0.jar - agent/src/share/lib/maf-1_0.jar ! src/share/vm/runtime/arguments.cpp Changeset: 79276d1b7e50 Author: trims Date: 2008-08-10 21:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/79276d1b7e50 6735720: Bump the HS14 build number to 03 Summary: Update Hotspot 14 build number to 03 Reviewed-by: jcoomes ! make/hotspot_version From John.Coomes at sun.com Mon Aug 11 12:32:03 2008 From: John.Coomes at sun.com (John Coomes) Date: Mon, 11 Aug 2008 12:32:03 -0700 Subject: IMPORTANT: Cleaning Up after the Hotspot repository rollbacks In-Reply-To: <489FB989.9050506@sun.com> References: <489FB989.9050506@sun.com> Message-ID: <18592.37811.445438.582501@sun.com> Erik Trimble (Erik.Trimble at Sun.COM) wrote: > This message is for those people who have a local clone of any of the > following repositories: > > http://hg.openjdk.java.net/jdk7/hotspot/hotspot > http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot > http://hg.openjdk.java.net/jdk7/hotspot-svc/hotspot > > AND who have pulled down an incorrect changeset that was removed during > tonight's rollback. > > To check if you have the offending changeset, in each local repository, > run this command: > > % hg log | grep 2bb5ef5c8a2d > > Any output from this command indicates that your repository has been > contaminated. > > > ### HOW DO I FIX THIS? #### > > There are four cases; please following the appropriate section: > > CASE #1: You have no committed or uncommitted new work in the > repository that you haven't already pushed to the hg.openjdk.java.net > repository > > SOLUTION: Re-pull the repository from http://hg.openjdk.java.net > This is the fastest, easiest solution - if you have no new work, > simply get a clean copy. Clarification - the old, contaminated repo should be deleted and a new one created with hg clone (i.e., you want to re-clone, not pull). -John > > CASE #2: You have committed one or more changesets of your own work > into the contaminated local repository > > SOLUTION: Clone a new copy of the repository from > http://hg.openjdk.java.net, then apply your changesets to that new copy. > Step 1: clone a fresh copy to > Step 2: change directory to your old, contaminated repo: > % cd > Step 3: use 'hg outgoing' to discover which changeset IDs you > have created since the last push to the repository > Step 4: For each changeset of your work, do the following: > % hg export -g -o /tmp/changesetID changesetID > Step 5: change directory to > Step 6: For each of your changesets, do the following: > % hg import -p 1 /tmp/changesetID > > You are now up-to-date and ready to work. > > In a limited number of cases, where your work was based against > an old branch of the repository, you may have problems with above > procedure. Please send an email to this list regarding your problems, > and someone will contact you shortly to help with the procedure. > > > > CASE #3: You have new work in the contaminated repository, but have not > committed yet (i.e. you do not have a changeset of your work). > > SOLUTION: Create a patch using your working files, and apply that patch > to a fresh clone from http://hg.openjdk.java.net > Step 1: clone a fresh copy to > Step 2: change directory to your old, contaminated repo: > % cd > Step 3: Run this command: % hg diff -g > /tmp/new_work.patch > Step 4: change directory to the new repo: % cd > Step 5: Using GNU patch, apply your changes: % patch -p > 1 -i /tmp/new_work.patch > > > > CASE #4: You have both committed changesets, and uncommitted work in > the contaminated local repository. > > SOLUTION: Follow the procedure in Case #2 to update your changesets, > then follow the procedure in Case #3 to migrate your uncommitted working > files. > > > > > Once again, we apologize for the inconvenience this rollback has caused. > > If you have any questions regarding this rollback, or the above > procedures to repair your local repositories, please send email to this > list (not to me), and we will try to reply promptly. > > > > -- > Erik Trimble > Java System Support > Mailstop: usca22-123 > Phone: x17195 > Santa Clara, CA > Timezone: US/Pacific (GMT-0800) > From gbenson at redhat.com Tue Aug 12 07:08:37 2008 From: gbenson at redhat.com (Gary Benson) Date: Tue, 12 Aug 2008 15:08:37 +0100 Subject: Pointer on clean card crosses boundary Message-ID: <20080812140837.GF3720@redhat.com> Hi all, I'm working on some additions to HotSpot, and I just found the VerifyBeforeGC and VerifyAfterGC options. I tried them, but I'm seeing this failure: # Internal Error (/home/gbenson/mixtec/openjdk-ecj/hotspot/src/share/vm/memory/cardTableRS.cpp:301), pid=19185, tid=3516646576 # Error: guarantee(*p == __null || (HeapWord*)p < boundary || (HeapWord*)(*p) >= boundary,"pointer on clean card crosses boundary") Does anyone know what I might be doing to cause this error? Cheers, Gary -- http://gbenson.net/ From tony.printezis at sun.com Tue Aug 12 08:09:43 2008 From: tony.printezis at sun.com (Tony Printezis) Date: Tue, 12 Aug 2008 11:09:43 -0400 Subject: Pointer on clean card crosses boundary In-Reply-To: <20080812140837.GF3720@redhat.com> References: <20080812140837.GF3720@redhat.com> Message-ID: <48A1A7B7.4050505@sun.com> Gary, I assume that the error happens with your changes? Can you give us a quick description of what your changes involve? Tony Gary Benson wrote: > Hi all, > > I'm working on some additions to HotSpot, and I just found the > VerifyBeforeGC and VerifyAfterGC options. I tried them, but I'm > seeing this failure: > > # Internal Error (/home/gbenson/mixtec/openjdk-ecj/hotspot/src/share/vm/memory/cardTableRS.cpp:301), pid=19185, tid=3516646576 > # Error: guarantee(*p == __null || (HeapWord*)p < boundary || (HeapWord*)(*p) >= boundary,"pointer on clean card crosses boundary") > > Does anyone know what I might be doing to cause this error? > > Cheers, > Gary > > -- ---------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS BUR02-311 | | e-mail: tony.printezis at sun.com | 35 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA01803-0902, USA | ---------------------------------------------------------------------- e-mail client: Thunderbird (Solaris) From gbenson at redhat.com Tue Aug 12 08:21:07 2008 From: gbenson at redhat.com (Gary Benson) Date: Tue, 12 Aug 2008 16:21:07 +0100 Subject: Pointer on clean card crosses boundary In-Reply-To: <48A1A7B7.4050505@sun.com> References: <20080812140837.GF3720@redhat.com> <48A1A7B7.4050505@sun.com> Message-ID: <20080812152106.GG3720@redhat.com> Hi Tony, I'm working on a new compiler, which uses a third-party compiler toolkit (LLVM) rather than generating machine code directly. I'm guessing I either allocated something incorrectly or I generated a broken oopmap, but I just wondered if there's some common thing that people do that would cause this error? Cheers, Gary Tony Printezis wrote: > Gary, > > I assume that the error happens with your changes? Can you give us a > quick description of what your changes involve? > > Tony > > Gary Benson wrote: > > Hi all, > > > > I'm working on some additions to HotSpot, and I just found the > > VerifyBeforeGC and VerifyAfterGC options. I tried them, but I'm > > seeing this failure: > > > > # Internal Error (/home/gbenson/mixtec/openjdk-ecj/hotspot/src/share/vm/memory/cardTableRS.cpp:301), pid=19185, tid=3516646576 > > # Error: guarantee(*p == __null || (HeapWord*)p < boundary || (HeapWord*)(*p) >= boundary,"pointer on clean card crosses boundary") > > > > Does anyone know what I might be doing to cause this error? > > > > Cheers, > > Gary > > -- > ---------------------------------------------------------------------- > | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | > | | MS BUR02-311 | > | e-mail: tony.printezis at sun.com | 35 Network Drive | > | office: +1 781 442 0998 (x20998) | Burlington, MA01803-0902, USA | > ---------------------------------------------------------------------- > e-mail client: Thunderbird (Solaris) -- http://gbenson.net/ From tony.printezis at sun.com Tue Aug 12 08:30:23 2008 From: tony.printezis at sun.com (Tony Printezis) Date: Tue, 12 Aug 2008 11:30:23 -0400 Subject: Pointer on clean card crosses boundary In-Reply-To: <20080812152106.GG3720@redhat.com> References: <20080812140837.GF3720@redhat.com> <48A1A7B7.4050505@sun.com> <20080812152106.GG3720@redhat.com> Message-ID: <48A1AC8F.1070606@sun.com> Gary, Do you generate card marks for all reference stores? Tony Gary Benson wrote: > Hi Tony, > > I'm working on a new compiler, which uses a third-party compiler > toolkit (LLVM) rather than generating machine code directly. I'm > guessing I either allocated something incorrectly or I generated > a broken oopmap, but I just wondered if there's some common thing > that people do that would cause this error? > > Cheers, > Gary > > Tony Printezis wrote: > >> Gary, >> >> I assume that the error happens with your changes? Can you give us a >> quick description of what your changes involve? >> >> Tony >> >> Gary Benson wrote: >> >>> Hi all, >>> >>> I'm working on some additions to HotSpot, and I just found the >>> VerifyBeforeGC and VerifyAfterGC options. I tried them, but I'm >>> seeing this failure: >>> >>> # Internal Error (/home/gbenson/mixtec/openjdk-ecj/hotspot/src/share/vm/memory/cardTableRS.cpp:301), pid=19185, tid=3516646576 >>> # Error: guarantee(*p == __null || (HeapWord*)p < boundary || (HeapWord*)(*p) >= boundary,"pointer on clean card crosses boundary") >>> >>> Does anyone know what I might be doing to cause this error? >>> >>> Cheers, >>> Gary >>> >> -- >> ---------------------------------------------------------------------- >> | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | >> | | MS BUR02-311 | >> | e-mail: tony.printezis at sun.com | 35 Network Drive | >> | office: +1 781 442 0998 (x20998) | Burlington, MA01803-0902, USA | >> ---------------------------------------------------------------------- >> e-mail client: Thunderbird (Solaris) >> > > -- ---------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS BUR02-311 | | e-mail: tony.printezis at sun.com | 35 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA01803-0902, USA | ---------------------------------------------------------------------- e-mail client: Thunderbird (Solaris) From Xiaobin.Lu at Sun.COM Tue Aug 12 11:46:51 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Tue, 12 Aug 2008 11:46:51 -0700 Subject: review request for 6608862 & 6459085 Message-ID: <48A1DA9B.7050402@Sun.COM> Webrev: http://javaweb.sfbay/~xl116366/webrev/6459085/ Details: This is a trivial fix for 6459085: naked pointer subtractions in class data sharing code. We should try to call pointer_delta instead of doing naked pointer operation to avoid surprise later. I also throw in a trivial fix to our linux make file. It seems like on Redhat 4, chcon command does not accept arguments to change the context for shared library and the OS in fact allows relocation to shared object file even with SELinux enabled. I guess that is because SELinux is in evolution and it is not as mature as later version such as RH5 etc. The failure execution of chcon command will cause VM build failure and exit. I actually removed the "exit 1" to let the build continue. I built and tested in dumbbell.east which is a Redhat 4 AS machine. Webrev: http://javaweb.sfbay/~xl116366/webrev/6608862/ Details: When some JVMTI operation such as stack walking is executed, Threads::threads_do will be called. While in the meantime, the VM is exiting as well and as a result, WatcherThread::watcher_thread returns NULL and the memory taken by it might be gone. To lock the WatcherThread in memory while do_thread is called on it, we grab the Terminator_lock which is also needs to be locked when WatcherThread exits and sets itself to NULL, this way, we can be certain that the WatcherThread and all its data structure is still there for reference. (thanks to David Holme's suggestion). Verified by: PRT. Test came with the bug report passed. NSK vm.full.testlist Thanks in advance. -Xiaobin From gbenson at redhat.com Wed Aug 13 01:31:02 2008 From: gbenson at redhat.com (Gary Benson) Date: Wed, 13 Aug 2008 09:31:02 +0100 Subject: Pointer on clean card crosses boundary In-Reply-To: <48A1AC8F.1070606@sun.com> References: <20080812140837.GF3720@redhat.com> <48A1A7B7.4050505@sun.com> <20080812152106.GG3720@redhat.com> <48A1AC8F.1070606@sun.com> Message-ID: <20080813083101.GA3746@redhat.com> Currently the only places I generate card marks are in putfield and putstatic. The only other place I can think of where I store an oop is in the implementation of new, where the klass pointer is stored in the new object, but I didn't think you needed one there. Where exactly do you need them? You don't need them if you store an oop in the stack do you? Cheers, Gary Tony Printezis wrote: > Gary, > > Do you generate card marks for all reference stores? > > Tony > > Gary Benson wrote: > > Hi Tony, > > > > I'm working on a new compiler, which uses a third-party compiler > > toolkit (LLVM) rather than generating machine code directly. I'm > > guessing I either allocated something incorrectly or I generated > > a broken oopmap, but I just wondered if there's some common thing > > that people do that would cause this error? > > > > Cheers, > > Gary > > > > Tony Printezis wrote: > > > Gary, > > > > > > I assume that the error happens with your changes? Can you give us a > > > quick description of what your changes involve? > > > > > > Tony > > > > > > Gary Benson wrote: > > > > > > >Hi all, > > > > > > > >I'm working on some additions to HotSpot, and I just found the > > > >VerifyBeforeGC and VerifyAfterGC options. I tried them, but I'm > > > >seeing this failure: > > > > > > > > # Internal Error > > > > (/home/gbenson/mixtec/openjdk-ecj/hotspot/src/share/vm/memory/cardTableRS.cpp:301), pid=19185, tid=3516646576 > > > > # Error: guarantee(*p == __null || (HeapWord*)p < boundary || > > > > (HeapWord*)(*p) >= boundary,"pointer on clean card crosses boundary") > > > > > > > >Does anyone know what I might be doing to cause this error? > > > > > > > >Cheers, > > > >Gary > > > > > > > -- > > > ---------------------------------------------------------------------- > > > | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | > > > | | MS BUR02-311 | > > > | e-mail: tony.printezis at sun.com | 35 Network Drive | > > > | office: +1 781 442 0998 (x20998) | Burlington, MA01803-0902, USA | > > > ---------------------------------------------------------------------- > > > e-mail client: Thunderbird (Solaris) > > > > > > > > > -- > ---------------------------------------------------------------------- > | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | > | | MS BUR02-311 | > | e-mail: tony.printezis at sun.com | 35 Network Drive | > | office: +1 781 442 0998 (x20998) | Burlington, MA01803-0902, USA | > ---------------------------------------------------------------------- > e-mail client: Thunderbird (Solaris) > > > -- http://gbenson.net/ From John.Rose at Sun.COM Wed Aug 13 11:49:53 2008 From: John.Rose at Sun.COM (John Rose) Date: Wed, 13 Aug 2008 11:49:53 -0700 Subject: Pointer on clean card crosses boundary In-Reply-To: <20080813083101.GA3746@redhat.com> References: <20080812140837.GF3720@redhat.com> <48A1A7B7.4050505@sun.com> <20080812152106.GG3720@redhat.com> <48A1AC8F.1070606@sun.com> <20080813083101.GA3746@redhat.com> Message-ID: <21C55A28-3250-491B-B286-1C314D6C0993@sun.com> Hi Gary. I'm not a GC person, but I'll chime in since it's often necessary for others (e.g., compiler people like you and me) to discover important system invariants. In order of preference: 1. Find a document that already describes what you need. The public home for such documents is http://wikis.sun.com/display/HotSpotInternals 2. Get someone who already knows to create such a document. (And have them put it on HotSpotInternals.) 3. Go spelunking through the code and discover the invariants for yourself. (As you do so, add to HotSpotInternals for the next engineer in line.) Although 1. and 2. are best cases, 3. is often the most practical choice. I suggest working through the interpreter code (which is simpler than the compiler code) looking at the placement of card marks. That's what I would do. You'll notice my comments are oriented to process and not content. I don't think Email is the right place to accumulate this sort of information. I started a wiki page with some of what I know about GC marks (which is not much); please add to it: http://wikis.sun.com/display/HotSpotInternals/StoreBarriers Best wishes, -- John P.S. Let me know your wiki ID and I will gladly give you author access to the wiki. This goes for anybody coding in the JVM. On Aug 13, 2008, at 1:31 AM, Gary Benson wrote: > Currently the only places I generate card marks are in putfield and > putstatic. The only other place I can think of where I store an oop > is in the implementation of new, where the klass pointer is stored in > the new object, but I didn't think you needed one there. Where > exactly do you need them? You don't need them if you store an oop in > the stack do you? From Thomas.Rodriguez at Sun.COM Wed Aug 13 13:04:22 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 13 Aug 2008 13:04:22 -0700 Subject: Pointer on clean card crosses boundary In-Reply-To: <20080813083101.GA3746@redhat.com> References: <20080812140837.GF3720@redhat.com> <48A1A7B7.4050505@sun.com> <20080812152106.GG3720@redhat.com> <48A1AC8F.1070606@sun.com> <20080813083101.GA3746@redhat.com> Message-ID: <6EFFD73E-638D-405F-8123-69F77A8B1071@sun.com> They are required for all oop stores into the java heap except the ones that are executed as part of the new bytecode itself. Do you do anything for aastore? tom On Aug 13, 2008, at 1:31 AM, Gary Benson wrote: > Currently the only places I generate card marks are in putfield and > putstatic. The only other place I can think of where I store an oop > is in the implementation of new, where the klass pointer is stored in > the new object, but I didn't think you needed one there. Where > exactly do you need them? You don't need them if you store an oop in > the stack do you? > > Cheers, > Gary > > Tony Printezis wrote: >> Gary, >> >> Do you generate card marks for all reference stores? >> >> Tony >> >> Gary Benson wrote: >>> Hi Tony, >>> >>> I'm working on a new compiler, which uses a third-party compiler >>> toolkit (LLVM) rather than generating machine code directly. I'm >>> guessing I either allocated something incorrectly or I generated >>> a broken oopmap, but I just wondered if there's some common thing >>> that people do that would cause this error? >>> >>> Cheers, >>> Gary >>> >>> Tony Printezis wrote: >>>> Gary, >>>> >>>> I assume that the error happens with your changes? Can you give >>>> us a >>>> quick description of what your changes involve? >>>> >>>> Tony >>>> >>>> Gary Benson wrote: >>>> >>>>> Hi all, >>>>> >>>>> I'm working on some additions to HotSpot, and I just found the >>>>> VerifyBeforeGC and VerifyAfterGC options. I tried them, but I'm >>>>> seeing this failure: >>>>> >>>>> # Internal Error >>>>> (/home/gbenson/mixtec/openjdk-ecj/hotspot/src/share/vm/memory/ >>>>> cardTableRS.cpp:301), pid=19185, tid=3516646576 >>>>> # Error: guarantee(*p == __null || (HeapWord*)p < boundary || >>>>> (HeapWord*)(*p) >= boundary,"pointer on clean card crosses >>>>> boundary") >>>>> >>>>> Does anyone know what I might be doing to cause this error? >>>>> >>>>> Cheers, >>>>> Gary >>>>> >>>> -- >>>> ---------------------------------------------------------------------- >>>> | Tony Printezis, Staff Engineer | Sun Microsystems >>>> Inc. | >>>> | | MS >>>> BUR02-311 | >>>> | e-mail: tony.printezis at sun.com | 35 Network >>>> Drive | >>>> | office: +1 781 442 0998 (x20998) | Burlington, MA01803-0902, >>>> USA | >>>> ---------------------------------------------------------------------- >>>> e-mail client: Thunderbird (Solaris) >>>> >>> >>> >> >> -- >> ---------------------------------------------------------------------- >> | Tony Printezis, Staff Engineer | Sun Microsystems >> Inc. | >> | | MS >> BUR02-311 | >> | e-mail: tony.printezis at sun.com | 35 Network >> Drive | >> | office: +1 781 442 0998 (x20998) | Burlington, MA01803-0902, >> USA | >> ---------------------------------------------------------------------- >> e-mail client: Thunderbird (Solaris) >> >> >> > > -- > http://gbenson.net/ From gbenson at redhat.com Thu Aug 14 01:18:06 2008 From: gbenson at redhat.com (Gary Benson) Date: Thu, 14 Aug 2008 09:18:06 +0100 Subject: Pointer on clean card crosses boundary In-Reply-To: <6EFFD73E-638D-405F-8123-69F77A8B1071@sun.com> References: <20080812140837.GF3720@redhat.com> <48A1A7B7.4050505@sun.com> <20080812152106.GG3720@redhat.com> <48A1AC8F.1070606@sun.com> <20080813083101.GA3746@redhat.com> <6EFFD73E-638D-405F-8123-69F77A8B1071@sun.com> Message-ID: <20080814081806.GB3781@redhat.com> That was it! Not only did it fix the VerifyBeforeGC error, but it fixed the bug I was trying to debug with it. What a fine start to the day :D Thanks! Gary Tom Rodriguez wrote: > They are required for all oop stores into the java heap except the > ones that are executed as part of the new bytecode itself. Do you > do anything for aastore? > > tom > > On Aug 13, 2008, at 1:31 AM, Gary Benson wrote: > > Currently the only places I generate card marks are in putfield > > and putstatic. The only other place I can think of where I store > > an oop is in the implementation of new, where the klass pointer is > > stored in the new object, but I didn't think you needed one there. > > Where exactly do you need them? You don't need them if you store > > an oop in the stack do you? > > > > Cheers, > > Gary > > > > Tony Printezis wrote: > > > Gary, > > > > > > Do you generate card marks for all reference stores? > > > > > > Tony -- http://gbenson.net/ From Ulf.Zibis at gmx.de Fri Aug 15 15:02:25 2008 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 16 Aug 2008 00:02:25 +0200 Subject: Can access by local method variables be faster then access by member variables ? Message-ID: <48A5FCF1.5090708@gmx.de> Hi experts, to avoid stack push + pop of src, dst I have refactored my code in moving the local method variables (sp, ...) to member variables (srcPos, ...). After this I have experienced that my code was little slower. For full source code see: https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/SingleByteEncoder.java?rev=291&view=markup https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/SingleByteEncoder.java?rev=302&view=markup ======================================== revisions 291 ======================================== private CoderResult encodeArraysLoop(CharBuffer src, ByteBuffer dst) { char[] sa = src.array(); int sp = src.arrayOffset() + src.position(); int sl = src.arrayOffset() + src.limit(); assert (sp <= sl); byte[] da = dst.array(); int dp = dst.arrayOffset() + dst.position(); int dl = dst.arrayOffset() + dst.limit(); assert (dp <= dl); try { for (; sp < sl; sp++) { current = sa[sp]; byte b = encodeSingle(); if (dp >= dl) return CoderResult.OVERFLOW; da[dp++] = b; } return CoderResult.UNDERFLOW; } catch (UnmappableCharacterException e) { if (Surrogate.isLow(current) || current >= '\uFFFE') return CODERRESULT_MALFORMED; if (Surrogate.isHigh(current)) try { if (sp+1 >= sl) return CoderResult.UNDERFLOW; encodeSurrogate(sa[sp+1]); } catch (UnmappableCharacterException e2) { return CODERRESULT_UNMAPPABLE2; } catch (MalformedInputException e2) { return CODERRESULT_MALFORMED2; } return CODERRESULT_UNMAPPABLE; } finally { src.position(sp - src.arrayOffset()); dst.position(dp - dst.arrayOffset()); } } ======================================== revisions 302 ======================================== private CoderResult encodeArraysLoop() throws RuntimeException, UnmappableCharacterException { for (; srcPos < srcLimit; srcPos++) { current = srcArray[srcPos]; byte b = encodeSingle(); if (dstPos < dstLimit) dstArray[dstPos++] = b; else return CoderResult.OVERFLOW; } return CoderResult.UNDERFLOW; } =============================================================================================== Thanks for your explanations, Ulf From Xiaobin.Lu at Sun.COM Fri Aug 15 15:26:55 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Fri, 15 Aug 2008 15:26:55 -0700 Subject: Can access by local method variables be faster then access by member variables ? In-Reply-To: <48A5FCF1.5090708@gmx.de> References: <48A5FCF1.5090708@gmx.de> Message-ID: <48A602AF.6090907@Sun.COM> I suspect that adding two members to the object would increase the object size which might affect the efficiency of object allocation. Have you had a chance to look at the generated code, it might be possible that the method itself is inlined so the pop/push operations have been completely eliminated? -Xiaobin Ulf Zibis wrote: > Hi experts, > > to avoid stack push + pop of src, dst I have refactored my code in > moving the local method variables (sp, ...) to member variables > (srcPos, ...). > > After this I have experienced that my code was little slower. > > For full source code see: > https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/SingleByteEncoder.java?rev=291&view=markup > > https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/SingleByteEncoder.java?rev=302&view=markup > > > ======================================== revisions 291 > ======================================== > > private CoderResult encodeArraysLoop(CharBuffer src, ByteBuffer dst) { > char[] sa = src.array(); > int sp = src.arrayOffset() + src.position(); > int sl = src.arrayOffset() + src.limit(); > assert (sp <= sl); > byte[] da = dst.array(); > int dp = dst.arrayOffset() + dst.position(); > int dl = dst.arrayOffset() + dst.limit(); > assert (dp <= dl); > try { > for (; sp < sl; sp++) { > current = sa[sp]; > byte b = encodeSingle(); > if (dp >= dl) > return CoderResult.OVERFLOW; > da[dp++] = b; > } > return CoderResult.UNDERFLOW; > } catch (UnmappableCharacterException e) { > if (Surrogate.isLow(current) || current >= '\uFFFE') > return CODERRESULT_MALFORMED; > if (Surrogate.isHigh(current)) > try { > if (sp+1 >= sl) > return CoderResult.UNDERFLOW; > encodeSurrogate(sa[sp+1]); > } catch (UnmappableCharacterException e2) { > return CODERRESULT_UNMAPPABLE2; > } catch (MalformedInputException e2) { > return CODERRESULT_MALFORMED2; > } > return CODERRESULT_UNMAPPABLE; > } finally { > src.position(sp - src.arrayOffset()); > dst.position(dp - dst.arrayOffset()); > } > } > > ======================================== revisions 302 > ======================================== > > private CoderResult encodeArraysLoop() throws RuntimeException, > UnmappableCharacterException { > for (; srcPos < srcLimit; srcPos++) { > current = srcArray[srcPos]; > byte b = encodeSingle(); > if (dstPos < dstLimit) > dstArray[dstPos++] = b; > else > return CoderResult.OVERFLOW; > } > return CoderResult.UNDERFLOW; > } > > =============================================================================================== > > > > Thanks for your explanations, > > Ulf > > > > From charles.nutter at sun.com Fri Aug 15 15:44:12 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Fri, 15 Aug 2008 18:44:12 -0400 Subject: Can access by local method variables be faster then access by member variables ? In-Reply-To: <48A5FCF1.5090708@gmx.de> References: <48A5FCF1.5090708@gmx.de> Message-ID: <48A606BC.7060705@sun.com> I'll be interested to hear from the HotSpot engineers, but a few things I know might help: - local variables will be allocated on the stack and will be much hotter in the cache - obviously member variables are going to need to load and dereference for every access, which would be slower than just retrieving a local variable, with or without pushes and pops - fields can obviously incur some cross-thread perf penalty if they result in memory caches getting wacked, which you would not have accessing local vars - When we're able to move Ruby local variables from a heap-based structure to local variables (stack-based) in JRuby, we see a tremendous improvement in performance. It's probably the single largest perf boost we get from compilation. - Charlie Ulf Zibis wrote: > Hi experts, > > to avoid stack push + pop of src, dst I have refactored my code in > moving the local method variables (sp, ...) to member variables (srcPos, > ...). > > After this I have experienced that my code was little slower. > > For full source code see: > https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/SingleByteEncoder.java?rev=291&view=markup > > https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/SingleByteEncoder.java?rev=302&view=markup > > > ======================================== revisions 291 > ======================================== > > private CoderResult encodeArraysLoop(CharBuffer src, ByteBuffer dst) { > char[] sa = src.array(); > int sp = src.arrayOffset() + src.position(); > int sl = src.arrayOffset() + src.limit(); > assert (sp <= sl); > byte[] da = dst.array(); > int dp = dst.arrayOffset() + dst.position(); > int dl = dst.arrayOffset() + dst.limit(); > assert (dp <= dl); > try { > for (; sp < sl; sp++) { > current = sa[sp]; > byte b = encodeSingle(); > if (dp >= dl) > return CoderResult.OVERFLOW; > da[dp++] = b; > } > return CoderResult.UNDERFLOW; > } catch (UnmappableCharacterException e) { > if (Surrogate.isLow(current) || current >= '\uFFFE') > return CODERRESULT_MALFORMED; > if (Surrogate.isHigh(current)) > try { > if (sp+1 >= sl) > return CoderResult.UNDERFLOW; > encodeSurrogate(sa[sp+1]); > } catch (UnmappableCharacterException e2) { > return CODERRESULT_UNMAPPABLE2; > } catch (MalformedInputException e2) { > return CODERRESULT_MALFORMED2; > } > return CODERRESULT_UNMAPPABLE; > } finally { > src.position(sp - src.arrayOffset()); > dst.position(dp - dst.arrayOffset()); > } > } > > ======================================== revisions 302 > ======================================== > > private CoderResult encodeArraysLoop() throws RuntimeException, > UnmappableCharacterException { > for (; srcPos < srcLimit; srcPos++) { > current = srcArray[srcPos]; > byte b = encodeSingle(); > if (dstPos < dstLimit) > dstArray[dstPos++] = b; > else > return CoderResult.OVERFLOW; > } > return CoderResult.UNDERFLOW; > } > > =============================================================================================== > > > > Thanks for your explanations, > > Ulf > > > > From Ulf.Zibis at gmx.de Fri Aug 15 15:45:31 2008 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 16 Aug 2008 00:45:31 +0200 Subject: Can access by local method variables be faster then access by member variables ? In-Reply-To: <48A602AF.6090907@Sun.COM> References: <48A5FCF1.5090708@gmx.de> <48A602AF.6090907@Sun.COM> Message-ID: <48A6070A.6000501@gmx.de> I don't think, that allocation of the object makes the difference, but the repeated access to the local/member variables in the for-loop which were accessed for each char in the possibly long to be encoded char buffer/array. -Ulf Am 16.08.2008 00:26, Xiaobin Lu schrieb: > I suspect that adding two members to the object would increase the > object size which might affect the efficiency of object allocation. > Have you had a chance to look at the generated code, it might be > possible that the method itself is inlined so the pop/push operations > have been completely eliminated? > > -Xiaobin > > Ulf Zibis wrote: >> Hi experts, >> >> to avoid stack push + pop of src, dst I have refactored my code in >> moving the local method variables (sp, ...) to member variables >> (srcPos, ...). >> >> After this I have experienced that my code was little slower. >> >> For full source code see: >> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/SingleByteEncoder.java?rev=291&view=markup >> >> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/SingleByteEncoder.java?rev=302&view=markup >> >> >> ======================================== revisions 291 >> ======================================== >> >> private CoderResult encodeArraysLoop(CharBuffer src, ByteBuffer >> dst) { >> char[] sa = src.array(); >> int sp = src.arrayOffset() + src.position(); >> int sl = src.arrayOffset() + src.limit(); >> assert (sp <= sl); >> byte[] da = dst.array(); >> int dp = dst.arrayOffset() + dst.position(); >> int dl = dst.arrayOffset() + dst.limit(); >> assert (dp <= dl); >> try { >> for (; sp < sl; sp++) { >> current = sa[sp]; >> byte b = encodeSingle(); >> if (dp >= dl) >> return CoderResult.OVERFLOW; >> da[dp++] = b; >> } >> return CoderResult.UNDERFLOW; >> } catch (UnmappableCharacterException e) { >> if (Surrogate.isLow(current) || current >= '\uFFFE') >> return CODERRESULT_MALFORMED; >> if (Surrogate.isHigh(current)) >> try { >> if (sp+1 >= sl) >> return CoderResult.UNDERFLOW; >> encodeSurrogate(sa[sp+1]); >> } catch (UnmappableCharacterException e2) { >> return CODERRESULT_UNMAPPABLE2; >> } catch (MalformedInputException e2) { >> return CODERRESULT_MALFORMED2; >> } >> return CODERRESULT_UNMAPPABLE; >> } finally { >> src.position(sp - src.arrayOffset()); >> dst.position(dp - dst.arrayOffset()); >> } >> } >> >> ======================================== revisions 302 >> ======================================== >> >> private CoderResult encodeArraysLoop() throws RuntimeException, >> UnmappableCharacterException { >> for (; srcPos < srcLimit; srcPos++) { >> current = srcArray[srcPos]; >> byte b = encodeSingle(); >> if (dstPos < dstLimit) >> dstArray[dstPos++] = b; >> else >> return CoderResult.OVERFLOW; >> } >> return CoderResult.UNDERFLOW; >> } >> >> =============================================================================================== >> >> >> >> Thanks for your explanations, >> >> Ulf >> >> >> >> > > From Thomas.Rodriguez at Sun.COM Fri Aug 15 16:16:37 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 15 Aug 2008 16:16:37 -0700 Subject: Can access by local method variables be faster then access by member variables ? In-Reply-To: <48A5FCF1.5090708@gmx.de> References: <48A5FCF1.5090708@gmx.de> Message-ID: <8BD4C140-30A3-49B5-8F30-C101EE69AE76@sun.com> What pushes and pops are you talking about? You should consider stack and local variable access to be completely free when any reasonable JIT is involved. The bytecodes that operate on the stack and locals don't correspond to any code that it's emitted by C1 or C2. Operations on member variables are definitely not free, though depending on how good your JIT is it may be able to reduce the number of actuals loads and stores that are issued. In general though the number issued will never become zero. C2 is fairly good at this and C1 does ok for simple cases but doesn't include any loop optimizations so it will be much less efficient for loopy code like you're showing. Basically the revision 302 code could be transformed into the revision 291 by a good compiler. 291 will definitely run faster with C1 because it doesn't have any loop optimizations around memory operations. C2 might be able to reproduce equivalent code, though I'm not positive it can delay the stores implied by the srcPos++ dstPos++ until the whole loop has completed. tom On Aug 15, 2008, at 3:02 PM, Ulf Zibis wrote: > Hi experts, > > to avoid stack push + pop of src, dst I have refactored my code in > moving the local method variables (sp, ...) to member variables > (srcPos, ...). > > After this I have experienced that my code was little slower. > > For full source code see: > https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/SingleByteEncoder.java?rev=291&view=markup > https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/SingleByteEncoder.java?rev=302&view=markup > > ======================================== revisions 291 > ======================================== > > private CoderResult encodeArraysLoop(CharBuffer src, ByteBuffer > dst) { > char[] sa = src.array(); > int sp = src.arrayOffset() + src.position(); > int sl = src.arrayOffset() + src.limit(); > assert (sp <= sl); > byte[] da = dst.array(); > int dp = dst.arrayOffset() + dst.position(); > int dl = dst.arrayOffset() + dst.limit(); > assert (dp <= dl); > try { > for (; sp < sl; sp++) { > current = sa[sp]; > byte b = encodeSingle(); > if (dp >= dl) > return CoderResult.OVERFLOW; > da[dp++] = b; > } > return CoderResult.UNDERFLOW; > } catch (UnmappableCharacterException e) { > if (Surrogate.isLow(current) || current >= '\uFFFE') > return CODERRESULT_MALFORMED; > if (Surrogate.isHigh(current)) > try { > if (sp+1 >= sl) > return CoderResult.UNDERFLOW; > encodeSurrogate(sa[sp+1]); > } catch (UnmappableCharacterException e2) { > return CODERRESULT_UNMAPPABLE2; > } catch (MalformedInputException e2) { > return CODERRESULT_MALFORMED2; > } > return CODERRESULT_UNMAPPABLE; > } finally { > src.position(sp - src.arrayOffset()); > dst.position(dp - dst.arrayOffset()); > } > } > > ======================================== revisions 302 > ======================================== > > private CoderResult encodeArraysLoop() throws RuntimeException, > UnmappableCharacterException { > for (; srcPos < srcLimit; srcPos++) { > current = srcArray[srcPos]; > byte b = encodeSingle(); > if (dstPos < dstLimit) > dstArray[dstPos++] = b; > else > return CoderResult.OVERFLOW; > } > return CoderResult.UNDERFLOW; > } > > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > ====================================================================== > > > Thanks for your explanations, > > Ulf > > > > From Ulf.Zibis at gmx.de Fri Aug 15 17:08:06 2008 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 16 Aug 2008 02:08:06 +0200 Subject: Can access by local method variables be faster then access by member variables ? In-Reply-To: <48A606BC.7060705@sun.com> References: <48A5FCF1.5090708@gmx.de> <48A606BC.7060705@sun.com> Message-ID: <48A61A66.9050702@gmx.de> Thanks for your first explanations. The answer from the HotSpot engineers would be interesting. In my imagination HotSpot should be able to detect and optimize this fact. -Ulf Am 16.08.2008 00:44, Charles Oliver Nutter schrieb: > I'll be interested to hear from the HotSpot engineers, but a few > things I know might help: > > - local variables will be allocated on the stack and will be much > hotter in the cache > - obviously member variables are going to need to load and dereference > for every access, which would be slower than just retrieving a local > variable, with or without pushes and pops > - fields can obviously incur some cross-thread perf penalty if they > result in memory caches getting wacked, which you would not have > accessing local vars > - When we're able to move Ruby local variables from a heap-based > structure to local variables (stack-based) in JRuby, we see a > tremendous improvement in performance. It's probably the single > largest perf boost we get from compilation. > > - Charlie > > Ulf Zibis wrote: >> Hi experts, >> >> to avoid stack push + pop of src, dst I have refactored my code in >> moving the local method variables (sp, ...) to member variables >> (srcPos, ...). >> >> After this I have experienced that my code was little slower. >> >> For full source code see: >> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/SingleByteEncoder.java?rev=291&view=markup >> >> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/SingleByteEncoder.java?rev=302&view=markup >> >> >> ======================================== revisions 291 >> ======================================== >> >> private CoderResult encodeArraysLoop(CharBuffer src, ByteBuffer >> dst) { >> char[] sa = src.array(); >> int sp = src.arrayOffset() + src.position(); >> int sl = src.arrayOffset() + src.limit(); >> assert (sp <= sl); >> byte[] da = dst.array(); >> int dp = dst.arrayOffset() + dst.position(); >> int dl = dst.arrayOffset() + dst.limit(); >> assert (dp <= dl); >> try { >> for (; sp < sl; sp++) { >> current = sa[sp]; >> byte b = encodeSingle(); >> if (dp >= dl) >> return CoderResult.OVERFLOW; >> da[dp++] = b; >> } >> return CoderResult.UNDERFLOW; >> } catch (UnmappableCharacterException e) { >> if (Surrogate.isLow(current) || current >= '\uFFFE') >> return CODERRESULT_MALFORMED; >> if (Surrogate.isHigh(current)) >> try { >> if (sp+1 >= sl) >> return CoderResult.UNDERFLOW; >> encodeSurrogate(sa[sp+1]); >> } catch (UnmappableCharacterException e2) { >> return CODERRESULT_UNMAPPABLE2; >> } catch (MalformedInputException e2) { >> return CODERRESULT_MALFORMED2; >> } >> return CODERRESULT_UNMAPPABLE; >> } finally { >> src.position(sp - src.arrayOffset()); >> dst.position(dp - dst.arrayOffset()); >> } >> } >> >> ======================================== revisions 302 >> ======================================== >> >> private CoderResult encodeArraysLoop() throws RuntimeException, >> UnmappableCharacterException { >> for (; srcPos < srcLimit; srcPos++) { >> current = srcArray[srcPos]; >> byte b = encodeSingle(); >> if (dstPos < dstLimit) >> dstArray[dstPos++] = b; >> else >> return CoderResult.OVERFLOW; >> } >> return CoderResult.UNDERFLOW; >> } >> >> =============================================================================================== >> >> >> >> Thanks for your explanations, >> >> Ulf >> >> >> >> > > From Ulf.Zibis at gmx.de Fri Aug 15 17:08:25 2008 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 16 Aug 2008 02:08:25 +0200 Subject: Can access by local method variables be faster then access by member variables ? In-Reply-To: <8BD4C140-30A3-49B5-8F30-C101EE69AE76@sun.com> References: <48A5FCF1.5090708@gmx.de> <8BD4C140-30A3-49B5-8F30-C101EE69AE76@sun.com> Message-ID: <48A61A79.3060601@gmx.de> Thanks for your answer. It's hard to follow for me in detail. What's C1 and C2 ? -Ulf Am 16.08.2008 01:16, Tom Rodriguez schrieb: > What pushes and pops are you talking about? You should consider stack > and local variable access to be completely free when any reasonable > JIT is involved. The bytecodes that operate on the stack and locals > don't correspond to any code that it's emitted by C1 or C2. > Operations on member variables are definitely not free, though > depending on how good your JIT is it may be able to reduce the number > of actuals loads and stores that are issued. In general though the > number issued will never become zero. C2 is fairly good at this and > C1 does ok for simple cases but doesn't include any loop optimizations > so it will be much less efficient for loopy code like you're showing. > > Basically the revision 302 code could be transformed into the revision > 291 by a good compiler. 291 will definitely run faster with C1 > because it doesn't have any loop optimizations around memory > operations. C2 might be able to reproduce equivalent code, though I'm > not positive it can delay the stores implied by the srcPos++ dstPos++ > until the whole loop has completed. > > tom > > On Aug 15, 2008, at 3:02 PM, Ulf Zibis wrote: > >> Hi experts, >> >> to avoid stack push + pop of src, dst I have refactored my code in >> moving the local method variables (sp, ...) to member variables >> (srcPos, ...). >> >> After this I have experienced that my code was little slower. >> >> For full source code see: >> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/SingleByteEncoder.java?rev=291&view=markup >> >> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/SingleByteEncoder.java?rev=302&view=markup >> >> >> ======================================== revisions 291 >> ======================================== >> >> private CoderResult encodeArraysLoop(CharBuffer src, ByteBuffer dst) { >> char[] sa = src.array(); >> int sp = src.arrayOffset() + src.position(); >> int sl = src.arrayOffset() + src.limit(); >> assert (sp <= sl); >> byte[] da = dst.array(); >> int dp = dst.arrayOffset() + dst.position(); >> int dl = dst.arrayOffset() + dst.limit(); >> assert (dp <= dl); >> try { >> for (; sp < sl; sp++) { >> current = sa[sp]; >> byte b = encodeSingle(); >> if (dp >= dl) >> return CoderResult.OVERFLOW; >> da[dp++] = b; >> } >> return CoderResult.UNDERFLOW; >> } catch (UnmappableCharacterException e) { >> if (Surrogate.isLow(current) || current >= '\uFFFE') >> return CODERRESULT_MALFORMED; >> if (Surrogate.isHigh(current)) >> try { >> if (sp+1 >= sl) >> return CoderResult.UNDERFLOW; >> encodeSurrogate(sa[sp+1]); >> } catch (UnmappableCharacterException e2) { >> return CODERRESULT_UNMAPPABLE2; >> } catch (MalformedInputException e2) { >> return CODERRESULT_MALFORMED2; >> } >> return CODERRESULT_UNMAPPABLE; >> } finally { >> src.position(sp - src.arrayOffset()); >> dst.position(dp - dst.arrayOffset()); >> } >> } >> >> ======================================== revisions 302 >> ======================================== >> >> private CoderResult encodeArraysLoop() throws RuntimeException, >> UnmappableCharacterException { >> for (; srcPos < srcLimit; srcPos++) { >> current = srcArray[srcPos]; >> byte b = encodeSingle(); >> if (dstPos < dstLimit) >> dstArray[dstPos++] = b; >> else >> return CoderResult.OVERFLOW; >> } >> return CoderResult.UNDERFLOW; >> } >> >> =============================================================================================== >> >> >> >> Thanks for your explanations, >> >> Ulf >> >> >> >> > > From martinrb at google.com Fri Aug 15 18:04:11 2008 From: martinrb at google.com (Martin Buchholz) Date: Fri, 15 Aug 2008 18:04:11 -0700 Subject: Can access by local method variables be faster then access by member variables ? In-Reply-To: <48A5FCF1.5090708@gmx.de> References: <48A5FCF1.5090708@gmx.de> Message-ID: <1ccfd1c10808151804g75c73b73sdb94a79eda7040d4@mail.gmail.com> The practice in java.util.concurrent, following Doug Lea, is to copy an unmodified field into a local at the beginning of a method, and then use that local for the duration of the method E.g.: private void interruptWorkers() { final ReentrantLock mainLock = this.mainLock; mainLock.lock(); try { ........................ } finally { mainLock.unlock(); } } It is believed this gives a performance win even when the field in question is final, where the jit (or even javac?) should be able to easily make such an optimization. Martin From fw at deneb.enyo.de Sun Aug 17 13:09:53 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 17 Aug 2008 22:09:53 +0200 Subject: Can access by local method variables be faster then access by member variables ? In-Reply-To: <48A61A79.3060601@gmx.de> (Ulf Zibis's message of "Sat, 16 Aug 2008 02:08:25 +0200") References: <48A5FCF1.5090708@gmx.de> <8BD4C140-30A3-49B5-8F30-C101EE69AE76@sun.com> <48A61A79.3060601@gmx.de> Message-ID: <871w0nxv1q.fsf@mid.deneb.enyo.de> * Ulf Zibis: > It's hard to follow for me in detail. What's C1 and C2 ? AFAIK, it's the client and server compilers. From charles.nutter at sun.com Sun Aug 17 13:44:16 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Sun, 17 Aug 2008 16:44:16 -0400 Subject: Can access by local method variables be faster then access by member variables ? In-Reply-To: <871w0nxv1q.fsf@mid.deneb.enyo.de> References: <48A5FCF1.5090708@gmx.de> <8BD4C140-30A3-49B5-8F30-C101EE69AE76@sun.com> <48A61A79.3060601@gmx.de> <871w0nxv1q.fsf@mid.deneb.enyo.de> Message-ID: <48A88DA0.5000404@sun.com> Florian Weimer wrote: > * Ulf Zibis: > >> It's hard to follow for me in detail. What's C1 and C2 ? > > AFAIK, it's the client and server compilers. Yes, C1 = client, C2 = server. From David.Holmes at Sun.COM Mon Aug 18 04:29:52 2008 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Mon, 18 Aug 2008 21:29:52 +1000 Subject: Finding the class represented by a Class instance Message-ID: <48A95D30.7060105@sun.com> In java_lang_Class::create_mirror(KlassHandle k, TRAPS) how can I determine for what type the java.lang.Class object is being created? Thanks, David Holmes From David.Holmes at Sun.COM Mon Aug 18 04:52:50 2008 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Mon, 18 Aug 2008 21:52:50 +1000 Subject: Finding the class represented by a Class instance In-Reply-To: <48A95D30.7060105@sun.com> References: <48A95D30.7060105@sun.com> Message-ID: <48A96292.5060606@sun.com> Well it's in k of course! So my real problem is that I want to trace Class object creation. But k->name()->as_C_string() crashes with a SIGSEGV. So I made this conditional on Universe::is_fully_initialized(), but it still crashes the first time I try to print the type name. It's crashing inside as_C_string but I haven't determined exactly where. I was kind of surprised there wasn't an existing flag to print Class instance creations ... though now I'm wondering whether classloading tracing will show the info I want ... Will try again tomorrow David David Holmes - Sun Microsystems said the following on 08/18/08 21:29: > In java_lang_Class::create_mirror(KlassHandle k, TRAPS) how can I > determine for what type the java.lang.Class object is being created? > > Thanks, > David Holmes From Keith.McGuigan at Sun.COM Mon Aug 18 07:00:05 2008 From: Keith.McGuigan at Sun.COM (Keith McGuigan) Date: Mon, 18 Aug 2008 10:00:05 -0400 Subject: Finding the class represented by a Class instance In-Reply-To: <48A96292.5060606@sun.com> References: <48A95D30.7060105@sun.com> <48A96292.5060606@sun.com> Message-ID: <48A98065.4000903@sun.com> David Holmes - Sun Microsystems wrote: > Well it's in k of course! So my real problem is that I want to trace > Class object creation. But k->name()->as_C_string() crashes with a > SIGSEGV. So I made this conditional on Universe::is_fully_initialized(), > but it still crashes the first time I try to print the type name. It's > crashing inside as_C_string but I haven't determined exactly where. There's a comment in klass.hpp which says that the _name field is only non-null for instance and array klasses. Could it be that you're trying to print a non-instance or non-array klass? Perhaps just check to see if k->name() is non-null before trying to print it? -- - Keith From daniel.daugherty at sun.com Mon Aug 18 15:05:51 2008 From: daniel.daugherty at sun.com (daniel.daugherty at sun.com) Date: Mon, 18 Aug 2008 22:05:51 +0000 Subject: hg: jdk7/hotspot/hotspot: 5 new changesets Message-ID: <20080818220601.39FB8D2BF@hg.openjdk.java.net> Changeset: 4852f4a82e58 Author: ohair Date: 2008-08-14 11:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4852f4a82e58 6724668: Hotspot: Official change to Sun Studio 12 compilers on Solaris Summary: Moving to SS12. Builds with SS11 still work, the compiler comes from your PATH when building hotspot. Reviewed-by: tbell ! make/jprt.config ! make/solaris/makefiles/sparcWorks.make Changeset: f3a650d8df24 Author: thurka Date: 2008-08-14 21:05 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f3a650d8df24 6625846: Export system property java.version via jvmstat Summary: java.version added to property_counters_ss array Reviewed-by: swamyv ! src/share/vm/runtime/statSampler.cpp Changeset: 7f9b895777f8 Author: thurka Date: 2008-08-15 05:55 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7f9b895777f8 Merge Changeset: a2de7dfbfcf0 Author: swamyv Date: 2008-08-12 12:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a2de7dfbfcf0 6718125: SA: jmap prints negative size for MaxNewHeap. Summary: Fixed printing of negative value for MaxNewHeap. Reviewed-by: jjh ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java Changeset: 44aea0a1e099 Author: swamyv Date: 2008-08-15 12:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/44aea0a1e099 Merge From john.coomes at sun.com Tue Aug 19 16:48:37 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Tue, 19 Aug 2008 23:48:37 +0000 Subject: hg: jdk7/hotspot: 6 new changesets Message-ID: <20080819234837.D3775D49D@hg.openjdk.java.net> Changeset: 5ceaca28a876 Author: xdono Date: 2008-08-04 13:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/5ceaca28a876 Added tag jdk7-b32 for changeset 64da805be725 ! .hgtags Changeset: 55b2666e52e1 Author: ohair Date: 2008-08-06 14:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/55b2666e52e1 6728161: Add SKIP_BOOT_CYCLE feature to create boot jdk and use it during build Reviewed-by: tbell ! Makefile ! make/Defs-internal.gmk ! make/jprt.config ! make/jprt.gmk Changeset: 844619bd3580 Author: ohair Date: 2008-08-06 16:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/844619bd3580 6724669: JDK7: Official change to Sun Studio 12 compilers on Solaris Reviewed-by: tbell ! README-builds.html ! make/jprt.config Changeset: 746ca6b12c56 Author: ohair Date: 2008-08-06 16:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/746ca6b12c56 Merge ! README-builds.html ! make/jprt.config Changeset: bb1ef4ee3d2c Author: xdono Date: 2008-08-12 15:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/bb1ef4ee3d2c Merge Changeset: 7aa4f433229a Author: xdono Date: 2008-08-14 09:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/7aa4f433229a Added tag jdk7-b33 for changeset bb1ef4ee3d2c ! .hgtags From john.coomes at sun.com Tue Aug 19 16:49:04 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Tue, 19 Aug 2008 23:49:04 +0000 Subject: hg: jdk7/hotspot/corba: 9 new changesets Message-ID: <20080819234911.C33ACD4A4@hg.openjdk.java.net> Changeset: f07251088084 Author: xdono Date: 2008-08-04 13:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/f07251088084 Added tag jdk7-b32 for changeset 80a0f46a6203 ! .hgtags Changeset: e9dad83f035c Author: ohair Date: 2008-08-01 13:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/e9dad83f035c 6732815: CORBA_2_3 java sources not explicitly compiled Reviewed-by: tbell ! make/org/omg/CORBA/Makefile Changeset: 41c585204e91 Author: tbell Date: 2008-08-07 09:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/41c585204e91 Merge Changeset: 6e0cf0dc59e5 Author: ohair Date: 2008-08-06 14:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/6e0cf0dc59e5 6734545: Corrections to missing explicit corba sources on javac compile lines Reviewed-by: tbell ! make/com/sun/corba/minclude/com_sun_corba_se_impl_dynamicany.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_impl_encoding.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_impl_ior.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_impl_orbutil.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_impl_protocol.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_spi_legacy_interceptor.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_spi_monitoring.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_spi_presentation_rmi.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_spi_transport.jmk ! make/com/sun/corba/minclude/org_omg_CosNaming.jmk ! make/com/sun/corba/minclude/org_omg_DynamicAny.jmk ! make/com/sun/corba/minclude/org_omg_PortableInterceptor.jmk ! make/com/sun/corba/se/sources/Makefile ! make/javax/xa/Makefile ! make/org/omg/CORBA/Makefile Changeset: 33486187d718 Author: ohair Date: 2008-08-06 16:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/33486187d718 6724669: JDK7: Official change to Sun Studio 12 compilers on Solaris Reviewed-by: tbell ! make/common/shared/Compiler-sun.gmk ! make/jprt.config Changeset: 6a5b9d2f8b20 Author: xdono Date: 2008-08-12 15:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/6a5b9d2f8b20 Merge Changeset: 05bf6aacc874 Author: xdono Date: 2008-08-14 09:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/05bf6aacc874 Added tag jdk7-b33 for changeset 6a5b9d2f8b20 ! .hgtags Changeset: e0e03ab25da0 Author: tbell Date: 2008-08-07 18:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/e0e03ab25da0 Merge Changeset: 0a812b9824e5 Author: tbell Date: 2008-08-14 22:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/0a812b9824e5 Merge From john.coomes at sun.com Tue Aug 19 16:50:52 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Tue, 19 Aug 2008 23:50:52 +0000 Subject: hg: jdk7/hotspot/jaxp: 2 new changesets Message-ID: <20080819235055.E2CF3D4A9@hg.openjdk.java.net> Changeset: 95375835527f Author: xdono Date: 2008-08-04 13:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/95375835527f Added tag jdk7-b32 for changeset 400a5ee432cc ! .hgtags Changeset: 01facdf8cabd Author: xdono Date: 2008-08-14 09:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/01facdf8cabd Added tag jdk7-b33 for changeset 95375835527f ! .hgtags From john.coomes at sun.com Tue Aug 19 16:51:22 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Tue, 19 Aug 2008 23:51:22 +0000 Subject: hg: jdk7/hotspot/jaxws: 2 new changesets Message-ID: <20080819235125.515D5D4AE@hg.openjdk.java.net> Changeset: 6dcbcfb9551a Author: xdono Date: 2008-08-04 13:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/6dcbcfb9551a Added tag jdk7-b32 for changeset e6daca2eced9 ! .hgtags Changeset: 7a9f629cd957 Author: xdono Date: 2008-08-14 09:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/7a9f629cd957 Added tag jdk7-b33 for changeset 6dcbcfb9551a ! .hgtags From john.coomes at sun.com Tue Aug 19 16:53:15 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Tue, 19 Aug 2008 23:53:15 +0000 Subject: hg: jdk7/hotspot/jdk: 68 new changesets Message-ID: <20080820000641.CBA16D4B3@hg.openjdk.java.net> Changeset: 89d30b258517 Author: ohair Date: 2008-07-16 09:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/89d30b258517 6548261: Use of SE in make/common/Defs-windows.gmk Reviewed-by: darcy ! make/common/Defs-windows.gmk ! make/common/Defs.gmk ! make/common/shared/Defs.gmk Changeset: 7754f0f4cf97 Author: xdono Date: 2008-07-25 08:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7754f0f4cf97 Merge Changeset: c51121419e30 Author: ohair Date: 2008-07-27 18:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c51121419e30 6727683: Cleanup use of COMPILER_WARNINGS_FATAL in makefiles Reviewed-by: tbell ! make/com/sun/java/pack/Makefile ! make/com/sun/security/auth/module/Makefile ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk ! make/common/shared/Compiler-gcc.gmk ! make/common/shared/Defs-java.gmk ! make/common/shared/Platform.gmk ! make/java/fdlibm/Makefile ! make/java/hpi/windows/Makefile ! make/java/java/Makefile ! make/java/java_crw_demo/Makefile ! make/java/java_hprof_demo/Makefile ! make/java/jli/Makefile ! make/java/net/Makefile ! make/java/nio/Makefile ! make/java/npt/Makefile ! make/java/verify/Makefile ! make/java/zip/Makefile ! make/jpda/back/Makefile ! make/jpda/transport/shmem/Makefile ! make/jpda/transport/socket/Makefile ! make/sun/cmm/kcms/Makefile ! make/sun/font/Makefile ! make/sun/font/t2k/Makefile ! make/sun/jdbc/Makefile ! make/sun/jpeg/Makefile Changeset: 12a0d0a1bb65 Author: xdono Date: 2008-08-04 13:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/12a0d0a1bb65 Added tag jdk7-b32 for changeset c51121419e30 ! .hgtags Changeset: 8f1a1b2f77a3 Author: igor Date: 2008-05-28 20:06 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8f1a1b2f77a3 6587560: OpenJDK problem handling bitmaps returned when LCD text is requested Reviewed-by: bae, prr ! src/share/native/sun/font/freetypeScaler.c Changeset: 3c4fc5111ff2 Author: lana Date: 2008-06-05 14:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3c4fc5111ff2 Merge Changeset: f0ede391c615 Author: prr Date: 2008-06-12 13:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f0ede391c615 6378099: RFE: Use libfontconfig to create/synthesise a fontconfig.properties Reviewed-by: tdv, igor ! make/sun/headless/mapfile-vers ! make/sun/xawt/mapfile-vers ! src/share/classes/sun/awt/FontConfiguration.java ! src/share/classes/sun/font/FontManager.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java + src/solaris/classes/sun/font/FcFontConfiguration.java ! src/solaris/native/sun/awt/fontconfig.h ! src/solaris/native/sun/awt/fontpath.c ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java Changeset: 9fae0ea75985 Author: srl Date: 2008-06-17 18:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9fae0ea75985 6711377: test/java/awt/font/TextLayout/VisibleAdvance.java missing GPL Reviewed-by: igor, prr ! test/java/awt/font/TextLayout/VisibleAdvance.java Changeset: 5755fe417a12 Author: jgodinez Date: 2008-06-23 13:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5755fe417a12 6708509: print dialog is not displayed when default paper is custom Reviewed-by: tdv, prr ! src/windows/native/sun/windows/awt_PrintJob.cpp + test/java/awt/print/PrinterJob/PrintAWTImage.java + test/java/awt/print/PrinterJob/duke.gif Changeset: c1e0755434eb Author: igor Date: 2008-07-15 16:04 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c1e0755434eb 6720240: IOB exception when getting font metrics of hershey font Reviewed-by: bae, prr ! src/share/classes/sun/font/NullFontScaler.java Changeset: 3efc003bf097 Author: tdv Date: 2008-07-18 10:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3efc003bf097 6725214: D3D: forward-port the new pipeline from 6u10 Summary: Forward port of the new Direct3D 9 rendering pipeline from 6u10. Also includes fixes for 6690659 6689025 6658398 6596234. Reviewed-by: campbell, prr ! make/common/shared/Platform.gmk ! make/common/shared/Sanity.gmk ! make/sun/awt/FILES_c_windows.gmk ! make/sun/awt/FILES_export_unix.gmk ! make/sun/awt/FILES_export_windows.gmk ! make/sun/awt/Makefile ! make/sun/awt/make.depend ! make/sun/awt/mapfile-mawt-vers ! make/sun/awt/mapfile-vers ! make/sun/awt/mapfile-vers-linux ! make/sun/font/FILES_c.gmk ! make/sun/font/Makefile ! make/sun/headless/mapfile-vers ! make/sun/jawt/make.depend ! make/sun/xawt/mapfile-vers ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/GraphicsDevice.java ! src/share/classes/java/awt/Robot.java ! src/share/classes/java/awt/image/DataBuffer.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/javax/swing/BufferStrategyPaintManager.java ! src/share/classes/sun/awt/NullComponentPeer.java ! src/share/classes/sun/awt/SubRegionShowable.java ! src/share/classes/sun/awt/image/SunVolatileImage.java ! src/share/classes/sun/awt/image/SunWritableRaster.java + src/share/classes/sun/awt/image/VSyncedBSManager.java ! src/share/classes/sun/awt/image/VolatileSurfaceManager.java ! src/share/classes/sun/font/StrikeCache.java + src/share/classes/sun/java2d/DestSurfaceProvider.java ! src/share/classes/sun/java2d/SunGraphics2D.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java + src/share/classes/sun/java2d/Surface.java ! src/share/classes/sun/java2d/SurfaceData.java ! src/share/classes/sun/java2d/SurfaceDataProxy.java ! src/share/classes/sun/java2d/loops/BlitBg.java ! src/share/classes/sun/java2d/loops/GeneralRenderer.java ! src/share/classes/sun/java2d/opengl/OGLBufImgOps.java ! src/share/classes/sun/java2d/opengl/OGLContext.java ! src/share/classes/sun/java2d/opengl/OGLGraphicsConfig.java ! src/share/classes/sun/java2d/opengl/OGLPaints.java ! src/share/classes/sun/java2d/opengl/OGLRenderer.java ! src/share/classes/sun/java2d/opengl/OGLSurfaceData.java ! src/share/classes/sun/java2d/pipe/BufferedContext.java ! src/share/classes/sun/java2d/pipe/BufferedOpCodes.java ! src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java ! src/share/classes/sun/java2d/pipe/DrawImage.java + src/share/classes/sun/java2d/pipe/ParallelogramPipe.java + src/share/classes/sun/java2d/pipe/PixelToParallelogramConverter.java + src/share/classes/sun/java2d/pipe/hw/AccelDeviceEventListener.java + src/share/classes/sun/java2d/pipe/hw/AccelDeviceEventNotifier.java + src/share/classes/sun/java2d/pipe/hw/AccelGraphicsConfig.java + src/share/classes/sun/java2d/pipe/hw/AccelSurface.java + src/share/classes/sun/java2d/pipe/hw/AccelTypedVolatileImage.java + src/share/classes/sun/java2d/pipe/hw/BufferedContextProvider.java + src/share/classes/sun/java2d/pipe/hw/ContextCapabilities.java + src/share/classes/sun/java2d/pipe/hw/ExtendedBufferCapabilities.java ! src/share/native/sun/font/AccelGlyphCache.c ! src/share/native/sun/font/AccelGlyphCache.h ! src/share/native/sun/font/sunFont.c + src/share/native/sun/java2d/ShaderList.c + src/share/native/sun/java2d/ShaderList.h ! src/share/native/sun/java2d/Trace.h ! src/share/native/sun/java2d/loops/BlitBg.c ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.c ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h ! src/share/native/sun/java2d/opengl/OGLContext.c ! src/share/native/sun/java2d/opengl/OGLContext.h ! src/share/native/sun/java2d/opengl/OGLFuncs.h ! src/share/native/sun/java2d/opengl/OGLRenderQueue.c ! src/share/native/sun/java2d/opengl/OGLRenderQueue.h ! src/share/native/sun/java2d/opengl/OGLRenderer.c ! src/share/native/sun/java2d/opengl/OGLRenderer.h ! src/share/native/sun/java2d/opengl/OGLSurfaceData.c ! src/share/native/sun/java2d/opengl/OGLSurfaceData.h ! src/share/native/sun/java2d/pipe/BufferedMaskBlit.c ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java ! src/solaris/classes/sun/awt/X11GraphicsConfig.java ! src/solaris/classes/sun/awt/X11GraphicsDevice.java ! src/solaris/classes/sun/awt/motif/MComponentPeer.java + src/solaris/classes/sun/java2d/BackBufferCapsProvider.java ! src/solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java ! src/solaris/classes/sun/java2d/opengl/GLXSurfaceData.java ! src/solaris/classes/sun/java2d/opengl/GLXVolatileSurfaceManager.java ! src/solaris/classes/sun/java2d/x11/X11PMBlitBgLoops.java ! src/solaris/native/sun/java2d/opengl/GLXGraphicsConfig.c ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c ! src/windows/classes/sun/awt/Win32GraphicsConfig.java ! src/windows/classes/sun/awt/Win32GraphicsDevice.java ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WEmbeddedFramePeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java + src/windows/classes/sun/java2d/ScreenUpdateManager.java ! src/windows/classes/sun/java2d/WindowsSurfaceManagerFactory.java - src/windows/classes/sun/java2d/d3d/D3DBackBufferSurfaceData.java ! src/windows/classes/sun/java2d/d3d/D3DBlitLoops.java + src/windows/classes/sun/java2d/d3d/D3DBufImgOps.java ! src/windows/classes/sun/java2d/d3d/D3DContext.java ! src/windows/classes/sun/java2d/d3d/D3DDrawImage.java + src/windows/classes/sun/java2d/d3d/D3DGraphicsConfig.java + src/windows/classes/sun/java2d/d3d/D3DGraphicsDevice.java + src/windows/classes/sun/java2d/d3d/D3DMaskBlit.java ! src/windows/classes/sun/java2d/d3d/D3DMaskFill.java + src/windows/classes/sun/java2d/d3d/D3DPaints.java + src/windows/classes/sun/java2d/d3d/D3DRenderQueue.java ! src/windows/classes/sun/java2d/d3d/D3DRenderer.java + src/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java ! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java + src/windows/classes/sun/java2d/d3d/D3DSurfaceDataProxy.java ! src/windows/classes/sun/java2d/d3d/D3DTextRenderer.java + src/windows/classes/sun/java2d/d3d/D3DVolatileSurfaceManager.java ! src/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java ! src/windows/classes/sun/java2d/opengl/WGLSurfaceData.java ! src/windows/classes/sun/java2d/opengl/WGLVolatileSurfaceManager.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/GDIBlitLoops.java + src/windows/classes/sun/java2d/windows/GDIWindowSurfaceData.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/classes/sun/java2d/windows/WindowsFlags.java + src/windows/native/sun/java2d/d3d/D3DBadHardware.h ! src/windows/native/sun/java2d/d3d/D3DBlitLoops.cpp + src/windows/native/sun/java2d/d3d/D3DBlitLoops.h + src/windows/native/sun/java2d/d3d/D3DBufImgOps.cpp + src/windows/native/sun/java2d/d3d/D3DBufImgOps.h ! src/windows/native/sun/java2d/d3d/D3DContext.cpp ! src/windows/native/sun/java2d/d3d/D3DContext.h + src/windows/native/sun/java2d/d3d/D3DGlyphCache.cpp + src/windows/native/sun/java2d/d3d/D3DGlyphCache.h + src/windows/native/sun/java2d/d3d/D3DGraphicsDevice.cpp + src/windows/native/sun/java2d/d3d/D3DGraphicsDevice.h + src/windows/native/sun/java2d/d3d/D3DMaskBlit.cpp + src/windows/native/sun/java2d/d3d/D3DMaskBlit.h + src/windows/native/sun/java2d/d3d/D3DMaskCache.cpp + src/windows/native/sun/java2d/d3d/D3DMaskCache.h ! src/windows/native/sun/java2d/d3d/D3DMaskFill.cpp + src/windows/native/sun/java2d/d3d/D3DMaskFill.h + src/windows/native/sun/java2d/d3d/D3DPaints.cpp + src/windows/native/sun/java2d/d3d/D3DPaints.h + src/windows/native/sun/java2d/d3d/D3DPipeline.cpp + src/windows/native/sun/java2d/d3d/D3DPipeline.h + src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp + src/windows/native/sun/java2d/d3d/D3DPipelineManager.h + src/windows/native/sun/java2d/d3d/D3DRenderQueue.cpp + src/windows/native/sun/java2d/d3d/D3DRenderQueue.h ! src/windows/native/sun/java2d/d3d/D3DRenderer.cpp + src/windows/native/sun/java2d/d3d/D3DRenderer.h + src/windows/native/sun/java2d/d3d/D3DResourceManager.cpp + src/windows/native/sun/java2d/d3d/D3DResourceManager.h - src/windows/native/sun/java2d/d3d/D3DRuntimeTest.cpp - src/windows/native/sun/java2d/d3d/D3DRuntimeTest.h + src/windows/native/sun/java2d/d3d/D3DShaderGen.c + src/windows/native/sun/java2d/d3d/D3DShaders.h ! src/windows/native/sun/java2d/d3d/D3DSurfaceData.cpp ! src/windows/native/sun/java2d/d3d/D3DSurfaceData.h - src/windows/native/sun/java2d/d3d/D3DTestRaster.h ! src/windows/native/sun/java2d/d3d/D3DTextRenderer.cpp + src/windows/native/sun/java2d/d3d/D3DTextRenderer.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/d3d/D3DVertexCacher.cpp + src/windows/native/sun/java2d/d3d/D3DVertexCacher.h ! src/windows/native/sun/java2d/opengl/WGLGraphicsConfig.c ! src/windows/native/sun/java2d/opengl/WGLSurfaceData.c ! src/windows/native/sun/java2d/opengl/WGLSurfaceData.h - src/windows/native/sun/java2d/windows/DDBlitLoops.cpp - src/windows/native/sun/java2d/windows/DDRenderer.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/GDIWindowSurfaceData.h - 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/WindowsFlags.cpp ! src/windows/native/sun/java2d/windows/WindowsFlags.h - 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/Devices.cpp ! src/windows/native/sun/windows/awt.h ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_DrawingSurface.cpp ! src/windows/native/sun/windows/awt_DrawingSurface.h ! src/windows/native/sun/windows/awt_Toolkit.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_Window.h ! src/windows/native/sun/windows/awtmsg.h + test/java/awt/FullScreen/BufferStrategyExceptionTest/BufferStrategyExceptionTest.java + test/java/awt/FullScreen/MultimonFullscreenTest/MultimonFullscreenTest.java + test/java/awt/FullScreen/NoResizeEventOnDMChangeTest/NoResizeEventOnDMChangeTest.java + test/java/awt/FullScreen/SetFSWindow/FSFrame.java + test/java/awt/Multiscreen/DeviceIdentificationTest/DeviceIdentificationTest.java + test/java/awt/image/MemoryLeakTest/MemoryLeakTest.java + test/sun/java2d/DirectX/AccelPaintsTest/AccelPaintsTest.java + test/sun/java2d/DirectX/AcceleratedScaleTest/AcceleratedScaleTest.java + test/sun/java2d/DirectX/IAEforEmptyFrameTest/IAEforEmptyFrameTest.java + test/sun/java2d/DirectX/InfiniteValidationLoopTest/InfiniteValidationLoopTest.java + test/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java + test/sun/java2d/DirectX/OverriddenInsetsTest/OverriddenInsetsTest.java + test/sun/java2d/DirectX/RenderingToCachedGraphicsTest/RenderingToCachedGraphicsTest.java + test/sun/java2d/DirectX/StrikeDisposalCrashTest/StrikeDisposalCrashTest.java + test/sun/java2d/DirectX/SwingOnScreenScrollingTest/SwingOnScreenScrollingTest.java + test/sun/java2d/DirectX/TransformedPaintTest/TransformedPaintTest.java + test/sun/java2d/GdiRendering/InsetClipping.java + test/sun/java2d/OpenGL/DrawBufImgOp.java + test/sun/java2d/SunGraphics2D/DrawImageBilinear.java + test/sun/java2d/SunGraphics2D/PolyVertTest.java + test/sun/java2d/SunGraphics2D/SimplePrimQuality.java + test/sun/java2d/SunGraphics2D/SourceClippingBlitTest/SourceClippingBlitTest.java + test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.java + test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.sh + test/sun/java2d/pipe/MutableColorTest/MutableColorTest.java + test/sun/java2d/pipe/hw/RSLAPITest/RSLAPITest.java + test/sun/java2d/pipe/hw/VSyncedBufferStrategyTest/VSyncedBufferStrategyTest.java Changeset: 2d7068a03750 Author: tdv Date: 2008-07-22 11:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2d7068a03750 6728492: typo in copyrights in some files touched by the d3d pipeline port Reviewed-by: prr ! make/common/shared/Platform.gmk ! make/common/shared/Sanity.gmk ! make/sun/awt/FILES_c_windows.gmk ! make/sun/awt/FILES_export_unix.gmk ! make/sun/awt/FILES_export_windows.gmk ! make/sun/awt/Makefile ! make/sun/awt/mapfile-mawt-vers ! make/sun/awt/mapfile-vers ! make/sun/awt/mapfile-vers-linux ! make/sun/font/FILES_c.gmk ! make/sun/font/Makefile ! make/sun/headless/mapfile-vers ! make/sun/xawt/mapfile-vers ! src/share/classes/java/awt/GraphicsDevice.java ! src/share/classes/java/awt/Robot.java ! src/share/classes/java/awt/image/DataBuffer.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/javax/swing/BufferStrategyPaintManager.java ! src/share/classes/sun/awt/NullComponentPeer.java ! src/share/classes/sun/awt/image/SunVolatileImage.java ! src/share/classes/sun/awt/image/SunWritableRaster.java ! src/share/classes/sun/awt/image/VolatileSurfaceManager.java ! src/share/classes/sun/font/StrikeCache.java ! src/share/classes/sun/java2d/SunGraphics2D.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/share/classes/sun/java2d/SurfaceData.java ! src/share/classes/sun/java2d/loops/BlitBg.java ! src/share/classes/sun/java2d/loops/GeneralRenderer.java ! src/share/classes/sun/java2d/opengl/OGLContext.java ! src/share/classes/sun/java2d/opengl/OGLGraphicsConfig.java ! src/share/classes/sun/java2d/opengl/OGLRenderer.java ! src/share/classes/sun/java2d/opengl/OGLSurfaceData.java ! src/share/classes/sun/java2d/pipe/BufferedOpCodes.java ! src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java ! src/share/classes/sun/java2d/pipe/DrawImage.java ! src/share/native/sun/font/AccelGlyphCache.c ! src/share/native/sun/font/AccelGlyphCache.h ! src/share/native/sun/java2d/Trace.h ! src/share/native/sun/java2d/loops/BlitBg.c ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.c ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h ! src/share/native/sun/java2d/opengl/OGLContext.c ! src/share/native/sun/java2d/opengl/OGLContext.h ! src/share/native/sun/java2d/opengl/OGLFuncs.h ! src/share/native/sun/java2d/opengl/OGLRenderQueue.c ! src/share/native/sun/java2d/opengl/OGLRenderQueue.h ! src/share/native/sun/java2d/opengl/OGLRenderer.c ! src/share/native/sun/java2d/opengl/OGLRenderer.h ! src/share/native/sun/java2d/opengl/OGLSurfaceData.c ! src/share/native/sun/java2d/opengl/OGLSurfaceData.h ! src/solaris/classes/sun/awt/X11GraphicsConfig.java ! src/solaris/classes/sun/awt/X11GraphicsDevice.java ! src/solaris/classes/sun/awt/motif/MComponentPeer.java ! src/solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java ! src/solaris/classes/sun/java2d/opengl/GLXSurfaceData.java ! src/solaris/classes/sun/java2d/opengl/GLXVolatileSurfaceManager.java ! src/solaris/classes/sun/java2d/x11/X11PMBlitBgLoops.java ! src/solaris/native/sun/java2d/opengl/GLXGraphicsConfig.c ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c ! src/windows/classes/sun/awt/Win32GraphicsConfig.java ! src/windows/classes/sun/awt/Win32GraphicsDevice.java ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WEmbeddedFramePeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java ! src/windows/classes/sun/java2d/opengl/WGLSurfaceData.java ! src/windows/classes/sun/java2d/opengl/WGLVolatileSurfaceManager.java ! src/windows/classes/sun/java2d/windows/GDIBlitLoops.java ! src/windows/classes/sun/java2d/windows/GDIWindowSurfaceData.java ! src/windows/classes/sun/java2d/windows/WindowsFlags.java ! src/windows/native/sun/java2d/opengl/WGLGraphicsConfig.c ! src/windows/native/sun/java2d/opengl/WGLSurfaceData.c ! src/windows/native/sun/java2d/opengl/WGLSurfaceData.h ! 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/GDIWindowSurfaceData.h ! src/windows/native/sun/java2d/windows/WindowsFlags.cpp ! src/windows/native/sun/java2d/windows/WindowsFlags.h ! src/windows/native/sun/windows/Devices.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_DrawingSurface.cpp ! src/windows/native/sun/windows/awt_DrawingSurface.h ! 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/awtmsg.h Changeset: 5a9e7ac25d30 Author: lana Date: 2008-07-24 21:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5a9e7ac25d30 Merge ! make/common/shared/Platform.gmk ! make/common/shared/Sanity.gmk ! make/sun/font/FILES_c.gmk ! make/sun/font/Makefile ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/image/DataBuffer.java ! src/share/classes/sun/awt/FontConfiguration.java ! src/share/classes/sun/awt/image/SunVolatileImage.java ! src/share/classes/sun/font/FontManager.java ! src/share/classes/sun/java2d/SunGraphics2D.java ! src/solaris/classes/sun/awt/X11GraphicsConfig.java ! src/solaris/classes/sun/awt/X11GraphicsDevice.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java ! src/windows/classes/sun/awt/windows/WEmbeddedFramePeer.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/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h Changeset: 2776a8638537 Author: lana Date: 2008-08-05 17:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2776a8638537 Merge ! make/common/shared/Platform.gmk ! make/sun/font/Makefile Changeset: ab3508401ce4 Author: jtusla Date: 2008-08-01 01:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ab3508401ce4 6509039: Swedish localization has incorrect am/pm markers in FormatData_sv Summary: Added respective section Reviewed-by: peytoia, jenda ! src/share/classes/sun/text/resources/FormatData_sv.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 52f21df467b4 Author: jtusla Date: 2008-08-01 02:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/52f21df467b4 6608572: Currency change for Malta and Cyprus Summary: Change the respective currencies Reviewed-by: naoto, jenda ! src/share/classes/java/util/CurrencyData.properties ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Currency/tablea1.txt Changeset: 1d3a19f9a015 Author: jtusla Date: 2008-08-07 04:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1d3a19f9a015 Merge Changeset: 2140be21d6e1 Author: alanb Date: 2008-07-24 12:40 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2140be21d6e1 6728728: (se) WindowsSelectorImpl.c doesn't compile with Visual Studio 2008 Reviewed-by: tbell, chegar ! src/windows/native/sun/nio/ch/WindowsSelectorImpl.c Changeset: 8bb706922a08 Author: alanb Date: 2008-07-24 12:46 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8bb706922a08 6726309: Compiler warnings in nio code Reviewed-by: sherman, iris ! src/share/classes/java/nio/channels/spi/AbstractSelector.java ! src/share/classes/java/nio/charset/Charset-X-Coder.java ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/java/nio/charset/CoderResult.java ! src/share/classes/sun/nio/ch/SelectorImpl.java ! src/share/classes/sun/nio/ch/Util.java ! src/share/native/java/nio/Bits.c ! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java ! src/solaris/native/java/nio/MappedByteBuffer.c ! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c ! src/solaris/native/sun/nio/ch/InheritedChannel.c ! src/solaris/native/sun/nio/ch/Net.c ! src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c ! src/solaris/native/sun/nio/ch/SocketChannelImpl.c ! src/windows/classes/sun/nio/ch/PipeImpl.java ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java Changeset: d01e7cae7b3e Author: ohair Date: 2008-07-24 14:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d01e7cae7b3e 6725543: Compiler warnings in serviceability native code Reviewed-by: alanb ! src/share/back/ThreadReferenceImpl.c ! src/share/back/transport.c ! src/share/demo/jvmti/hprof/hprof_io.c ! src/share/demo/jvmti/hprof/hprof_util.c ! src/share/transport/shmem/shmemBack.c ! src/share/transport/shmem/shmemBase.c ! src/share/transport/socket/socketTransport.c ! src/share/transport/socket/sysSocket.h ! src/solaris/transport/socket/socket_md.c ! src/windows/transport/socket/socket_md.c ! src/windows/transport/socket/socket_md.h Changeset: 7b7d051e3b96 Author: thurka Date: 2008-07-25 12:40 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7b7d051e3b96 6672135: setInterval() for local MonitoredHost and local MonitoredVm does not work Summary: super.setInterval() invoked with correct value Reviewed-by: swamyv ! src/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalMonitoredVm.java ! src/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/MonitoredHostProvider.java Changeset: 541631112989 Author: sherman Date: 2008-07-26 20:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/541631112989 6681798: (build) CharsetEncoder.java fails to compile in openjdk6 on ubutu 8.04 Summary: replace awk-sed based spp.sh with a java regex based pre-processor Reviewed-by: alanb ! make/java/nio/Makefile ! make/java/nio/genCoder.sh - make/java/nio/spp.sh ! make/tools/Makefile + make/tools/spp/Makefile + make/tools/src/build/tools/spp/Spp.java Changeset: f2547e64dc3c Author: jjh Date: 2008-07-28 12:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f2547e64dc3c 6730587: TEST: com/sun/jdi/MonitorFrameInfoTest.java fails with -server -Xcomp Summary: Fix test to prevent C2 escape analysis from deleting the required synchronized blocks Reviewed-by: swamyv ! test/com/sun/jdi/MonitorFrameInfo.java Changeset: 8c667d55b79e Author: dfuchs Date: 2008-07-29 19:21 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8c667d55b79e 6402254: Revisit ModelMBean DescriptorSupport implementation of equals and hashCode. Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/mbeanserver/Util.java ! src/share/classes/javax/management/ImmutableDescriptor.java ! src/share/classes/javax/management/modelmbean/DescriptorSupport.java Changeset: 571a6e4bbb91 Author: jccollet Date: 2008-07-01 13:29 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/571a6e4bbb91 6713809: FTP fails from multi-homed system Summary: Binds the data socket to the same address as the control socket Reviewed-by: michaelm ! src/share/classes/sun/net/ftp/FtpClient.java Changeset: b6a29195bc04 Author: jccollet Date: 2008-07-01 13:38 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b6a29195bc04 6656849: NullPointerException thrown while de-serializing IPV6 Address. Summary: Check for existence of interface name earlier in code Reviewed-by: michaelm ! src/share/classes/java/net/Inet6Address.java + test/java/net/Inet6Address/serialize/Readme.txt ! test/java/net/Inet6Address/serialize/Serialize.java + test/java/net/Inet6Address/serialize/serial-bge0.ser Changeset: cedc95b10b72 Author: wetmore Date: 2008-07-07 13:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/cedc95b10b72 Merge Changeset: 1d621ef0330b Author: weijun Date: 2008-07-09 12:03 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1d621ef0330b 6480981: keytool should be able to import certificates from remote SSL servers Reviewed-by: vinnie, wetmore ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/util/Resources.java + test/sun/security/tools/keytool/PrintSSL.java + test/sun/security/tools/keytool/printssl.sh Changeset: c9be2cc052b5 Author: michaelm Date: 2008-07-14 11:39 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c9be2cc052b5 6536211: flaw in ServerImpl Summary: removed doPrivileged block Reviewed-by: jccollet ! src/share/classes/sun/net/httpserver/ServerImpl.java Changeset: 3b8e5bfe2be7 Author: chegar Date: 2008-07-19 10:27 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3b8e5bfe2be7 6726164: jdk\src\windows\native\java\net\NetworkInterface.h(172) : error C2365: 'IpPrefixOriginOther' : redef Summary: Change the NetworkInterface header that allows it to compile on the current compiler/SDK version as well as the SDK bundled with Visual Studio 2008. Reviewed-by: ohair, alanb ! src/windows/native/java/net/NetworkInterface.h Changeset: 8f63365a2586 Author: michaelm Date: 2008-07-23 12:05 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8f63365a2586 6728076: Test case for 6536211 is failing on all platforms Summary: exception needed to be caught and logged Reviewed-by: chegar ! src/share/classes/sun/net/httpserver/ServerImpl.java Changeset: 701eaee7ebed Author: wetmore Date: 2008-07-23 12:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/701eaee7ebed Merge ! src/share/classes/sun/net/ftp/FtpClient.java Changeset: 9655476d50f4 Author: weijun Date: 2008-07-27 19:16 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9655476d50f4 6709758: keytool default cert fingerprint algorithm should be SHA1, not MD5 Reviewed-by: mullan, xuelei ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/util/Resources.java Changeset: b7fce4bac617 Author: chegar Date: 2008-07-28 13:02 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b7fce4bac617 6729881: Compiler warning in networking native code Summary: Cleanup compiler warnings Reviewed-by: alanb, jccollet, michaelm ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/PlainSocketImpl.c ! src/solaris/native/java/net/SocketInputStream.c ! src/solaris/native/java/net/SocketOutputStream.c ! src/solaris/native/java/net/linux_close.c ! src/solaris/native/java/net/net_util_md.c ! src/windows/native/java/net/Inet4AddressImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface.h ! src/windows/native/java/net/NetworkInterface_win9x.c ! src/windows/native/java/net/NetworkInterface_winXP.c ! src/windows/native/java/net/SocketOutputStream.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c ! src/windows/native/java/net/net_util_md.c ! src/windows/native/java/net/net_util_md.h ! src/windows/native/sun/net/dns/ResolverConfigurationImpl.c ! src/windows/native/sun/net/www/protocol/http/NTLMAuthSequence.c Changeset: 441f88d39988 Author: chegar Date: 2008-07-29 09:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/441f88d39988 6730740: Fix for 6729881 has apparently broken several 64 bit tests: "Bad address" Reviewed-by: alanb, jccollet ! src/solaris/native/java/net/linux_close.c ! src/solaris/native/java/net/net_util_md.c Changeset: 95ce89bf8cd2 Author: wetmore Date: 2008-07-29 10:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/95ce89bf8cd2 Merge Changeset: 498c2de672c1 Author: wetmore Date: 2008-07-29 16:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/498c2de672c1 Merge Changeset: 289bc9ca7556 Author: tbell Date: 2008-08-01 15:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/289bc9ca7556 Merge ! make/java/nio/Makefile Changeset: 7e10774d2a29 Author: tbell Date: 2008-08-07 09:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7e10774d2a29 Merge - 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 Changeset: e35680499077 Author: ohair Date: 2008-08-06 15:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e35680499077 6728161: Add SKIP_BOOT_CYCLE feature to create boot jdk and use it during build Summary: Needed BOOT_JAR_JFLAGS. Fixed PREVIOUS_RELEASE_IMAGE. Reviewed-by: tbell ! make/com/sun/crypto/provider/Makefile ! make/com/sun/inputmethods/indicim/Makefile ! make/com/sun/inputmethods/thaiim/Makefile ! make/common/BuildToolJar.gmk ! make/common/Demo.gmk ! make/common/Release.gmk ! make/common/internal/BinaryPlugs.gmk ! make/common/internal/ImportComponents.gmk ! make/common/shared/Defs-java.gmk ! make/java/management/Makefile ! make/javax/crypto/Makefile ! make/javax/swing/beaninfo/SwingBeans.gmk ! make/sun/jconsole/Makefile ! make/sun/net/spi/nameservice/dns/Makefile ! make/sun/nio/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile ! make/sun/text/Makefile Changeset: b374f6174534 Author: ohair Date: 2008-07-30 19:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b374f6174534 6729772: 64-bit build with SS12 compiler: SIGSEGV (0xb) at pc=0x0000000000000048, pid=14826, tid=2 Reviewed-by: tbell ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk ! make/common/Defs.gmk ! make/common/Library.gmk ! make/common/shared/Defs.gmk ! make/java/fdlibm/Makefile ! make/java/java_hprof_demo/Makefile ! make/sun/awt/Makefile ! make/sun/font/Makefile ! make/sun/font/t2k/Makefile ! make/sun/image/generic/Makefile ! make/sun/image/vis/Makefile ! make/sun/jpeg/Makefile Changeset: a140a5aa5f2c Author: ohair Date: 2008-08-06 16:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a140a5aa5f2c 6724669: JDK7: Official change to Sun Studio 12 compilers on Solaris Reviewed-by: tbell - make/README-builds.html - make/README.html ! make/common/shared/Compiler-sun.gmk ! make/jprt.config Changeset: a418b563ed63 Author: ohair Date: 2008-08-06 16:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a418b563ed63 Merge - make/README-builds.html - make/README.html ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk ! make/common/Defs.gmk ! make/common/shared/Defs.gmk ! make/java/fdlibm/Makefile ! make/java/java_hprof_demo/Makefile ! make/sun/font/Makefile ! make/sun/font/t2k/Makefile ! make/sun/jpeg/Makefile Changeset: a5e641698d38 Author: ohair Date: 2008-08-08 08:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a5e641698d38 6734977: Fix build failure regarding the now deleted file jdk/README.html Reviewed-by: xdono, tbell - make/ASSEMBLY_EXCEPTION - make/LICENSE - make/README - make/THIRD_PARTY_README ! make/common/Release.gmk Changeset: 32a4e56d5f68 Author: ohair Date: 2008-08-08 08:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/32a4e56d5f68 Merge - make/ASSEMBLY_EXCEPTION - make/LICENSE - make/README - make/THIRD_PARTY_README ! make/common/Release.gmk Changeset: fa4c0a6cdd25 Author: xdono Date: 2008-08-12 15:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/fa4c0a6cdd25 Merge - make/java/nio/spp.sh ! make/sun/awt/Makefile ! make/sun/font/Makefile - 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 Changeset: 4c24def75deb Author: xdono Date: 2008-08-14 09:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4c24def75deb Added tag jdk7-b33 for changeset fa4c0a6cdd25 ! .hgtags Changeset: 914370f03119 Author: dfuchs Date: 2008-07-31 12:41 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/914370f03119 6730926: Document that create/registerMBean can throw RuntimeMBeanException from postRegister Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/share/classes/javax/management/MBeanRegistration.java ! src/share/classes/javax/management/MBeanServer.java ! src/share/classes/javax/management/MBeanServerConnection.java + test/javax/management/MBeanServer/PostExceptionTest.java Changeset: 7622f1de1486 Author: dfuchs Date: 2008-07-31 14:20 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7622f1de1486 6689505: Improve MBeanServerNotification.toString Reviewed-by: emcmanus ! src/share/classes/javax/management/MBeanServerNotification.java + test/javax/management/MBeanServer/MBeanServerNotificationTest.java Changeset: 8f52c4d1d934 Author: sjiang Date: 2008-07-31 15:31 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8f52c4d1d934 5108776: Add reliable event handling to the JMX API 6218920: API bug - impossible to delete last MBeanServerForwarder on a connector Reviewed-by: emcmanus + src/share/classes/com/sun/jmx/event/DaemonThreadFactory.java + src/share/classes/com/sun/jmx/event/EventBuffer.java + src/share/classes/com/sun/jmx/event/EventClientFactory.java + src/share/classes/com/sun/jmx/event/EventConnection.java + src/share/classes/com/sun/jmx/event/EventParams.java + src/share/classes/com/sun/jmx/event/LeaseManager.java + src/share/classes/com/sun/jmx/event/LeaseRenewer.java + src/share/classes/com/sun/jmx/event/ReceiverBuffer.java + src/share/classes/com/sun/jmx/event/RepeatedSingletonJob.java + src/share/classes/com/sun/jmx/interceptor/MBeanServerSupport.java + src/share/classes/com/sun/jmx/interceptor/SingleMBeanForwarder.java ! src/share/classes/com/sun/jmx/interceptor/package.html ! src/share/classes/com/sun/jmx/mbeanserver/MBeanInjector.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanSupport.java + src/share/classes/com/sun/jmx/mbeanserver/PerThreadGroupPool.java ! src/share/classes/com/sun/jmx/mbeanserver/Util.java ! src/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java ! src/share/classes/com/sun/jmx/remote/internal/ProxyInputStream.java ! src/share/classes/com/sun/jmx/remote/internal/ProxyRef.java ! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! src/share/classes/com/sun/jmx/remote/security/FileLoginModule.java ! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java + src/share/classes/com/sun/jmx/remote/util/EventClientConnection.java ! src/share/classes/com/sun/jmx/snmp/tasks/ThreadService.java ! src/share/classes/javax/management/ImmutableDescriptor.java ! src/share/classes/javax/management/MBeanServer.java ! src/share/classes/javax/management/MBeanServerConnection.java ! src/share/classes/javax/management/MXBean.java ! src/share/classes/javax/management/QueryParser.java ! src/share/classes/javax/management/StringValueExp.java + src/share/classes/javax/management/event/EventClient.java + src/share/classes/javax/management/event/EventClientDelegate.java + src/share/classes/javax/management/event/EventClientDelegateMBean.java + src/share/classes/javax/management/event/EventClientNotFoundException.java + src/share/classes/javax/management/event/EventConsumer.java + src/share/classes/javax/management/event/EventForwarder.java + src/share/classes/javax/management/event/EventReceiver.java + src/share/classes/javax/management/event/EventRelay.java + src/share/classes/javax/management/event/EventSubscriber.java + src/share/classes/javax/management/event/FetchingEventForwarder.java + src/share/classes/javax/management/event/FetchingEventRelay.java + src/share/classes/javax/management/event/ListenerInfo.java + src/share/classes/javax/management/event/NotificationManager.java + src/share/classes/javax/management/event/RMIPushEventForwarder.java + src/share/classes/javax/management/event/RMIPushEventRelay.java + src/share/classes/javax/management/event/RMIPushServer.java + src/share/classes/javax/management/event/package-info.java ! src/share/classes/javax/management/loading/MLet.java ! src/share/classes/javax/management/modelmbean/ModelMBeanInfoSupport.java ! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java ! src/share/classes/javax/management/relation/RelationService.java + src/share/classes/javax/management/remote/IdentityMBeanServerForwarder.java ! src/share/classes/javax/management/remote/JMXConnector.java ! src/share/classes/javax/management/remote/JMXConnectorServer.java ! src/share/classes/javax/management/remote/JMXConnectorServerFactory.java ! src/share/classes/javax/management/remote/JMXConnectorServerMBean.java ! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java + test/javax/management/MBeanServer/DynamicWrapperMBeanTest.java + test/javax/management/MBeanServer/OldMBeanServerTest.java + test/javax/management/eventService/AddRemoveListenerTest.java + test/javax/management/eventService/CustomForwarderTest.java + test/javax/management/eventService/EventClientExecutorTest.java + test/javax/management/eventService/EventDelegateSecurityTest.java + test/javax/management/eventService/EventManagerTest.java + test/javax/management/eventService/FetchingTest.java + test/javax/management/eventService/LeaseManagerDeadlockTest.java + test/javax/management/eventService/LeaseTest.java + test/javax/management/eventService/ListenerTest.java + test/javax/management/eventService/MyFetchingEventForwarder.java + test/javax/management/eventService/NotSerializableNotifTest.java + test/javax/management/eventService/PublishTest.java + test/javax/management/eventService/ReconnectableConnectorTest.java + test/javax/management/eventService/SharingThreadTest.java + test/javax/management/eventService/SubscribeTest.java + test/javax/management/eventService/UsingEventService.java ! test/javax/management/mxbean/GenericArrayTypeTest.java ! test/javax/management/mxbean/LeakTest.java ! test/javax/management/mxbean/MBeanOperationInfoTest.java ! test/javax/management/mxbean/MXBeanTest.java ! test/javax/management/mxbean/ThreadMXBeanTest.java ! test/javax/management/mxbean/TigerMXBean.java ! test/javax/management/query/QueryNotifFilterTest.java ! test/javax/management/remote/mandatory/connection/CloseServerTest.java ! test/javax/management/remote/mandatory/connection/DeadLockTest.java ! test/javax/management/remote/mandatory/connection/IdleTimeoutTest.java ! test/javax/management/remote/mandatory/connection/RMIExitTest.java ! test/javax/management/remote/mandatory/connection/ReconnectTest.java + test/javax/management/remote/mandatory/connectorServer/ForwarderChainTest.java + test/javax/management/remote/mandatory/connectorServer/StandardForwardersTest.java ! test/javax/management/remote/mandatory/loading/MissingClassTest.java ! test/javax/management/remote/mandatory/notif/AddRemoveTest.java ! test/javax/management/remote/mandatory/notif/DiffHBTest.java ! test/javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java ! test/javax/management/remote/mandatory/notif/ListenerScaleTest.java ! test/javax/management/remote/mandatory/notif/NotifBufferSizePropertyNameTest.java ! test/javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java ! test/javax/management/remote/mandatory/notif/NotificationAccessControllerTest.java ! test/javax/management/remote/mandatory/notif/NotificationBufferCreationTest.java ! test/javax/management/remote/mandatory/notif/NotificationBufferDeadlockTest.java ! test/javax/management/remote/mandatory/notif/NotificationEmissionTest.java ! test/javax/management/remote/mandatory/notif/RMINotifTest.java ! test/javax/management/remote/mandatory/notif/UnexpectedNotifTest.java Changeset: 98caad5c563c Author: dfuchs Date: 2008-07-31 17:38 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/98caad5c563c 6616825: JMX query returns no value in 1.0 compatibility mode - deserialization bug in readObject() Reviewed-by: emcmanus ! src/share/classes/javax/management/ObjectName.java ! test/javax/management/ObjectName/SerialCompatTest.java Changeset: 3a1325be2806 Author: martin Date: 2008-08-01 00:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3a1325be2806 6730380: java.util.Timer should use AtomicInteger Reviewed-by: dl, chegar ! src/share/classes/java/util/Timer.java Changeset: f33c3846cecb Author: dl Date: 2008-08-01 00:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f33c3846cecb 6725789: ScheduledExecutorService does not work as expected in jdk7/6/5 Reviewed-by: martin, dholmes, chegar ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java + test/java/util/concurrent/ScheduledThreadPoolExecutor/DelayOverflow.java Changeset: e0dc076d99b8 Author: dfuchs Date: 2008-08-01 11:41 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e0dc076d99b8 6732192: CORE_PKGS.gmk: need to declare javax.management.event in the CORE_PKGS variable Reviewed-by: emcmanus ! make/docs/CORE_PKGS.gmk Changeset: 3232179e24ae Author: jjh Date: 2008-08-01 13:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3232179e24ae 6730273: TEST: JDI_REGRESSION test Solaris32AndSolaris64Test.sh fails if -XX:+UseCompressedOops is used Summary: Fix test to not pass -XX:[+-]UseCompressedOops to the debuggee. Reviewed-by: tbell ! test/com/sun/jdi/Solaris32AndSolaris64Test.sh Changeset: 00c40e393a75 Author: emcmanus Date: 2008-08-05 10:49 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/00c40e393a75 6733589: Intermittent failure of test/javax/management/eventService/SharingThreadTest.java Reviewed-by: sjiang ! test/javax/management/eventService/SharingThreadTest.java Changeset: 13b8426bb0cd Author: emcmanus Date: 2008-08-06 18:28 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/13b8426bb0cd 6734273: Minor updates to documentation of Custom MXBean Mappings Reviewed-by: dfuchs ! src/share/classes/javax/management/MXBean.java ! src/share/classes/javax/management/openmbean/MXBeanMapping.java ! src/share/classes/javax/management/openmbean/MXBeanMappingFactory.java Changeset: f8c58e72b807 Author: swamyv Date: 2008-08-06 10:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f8c58e72b807 6732441: TEST_BUG: ThreadMXBeanProxy test fails intermittently. Summary: Fixed the race condition in the test. Reviewed-by: jjh ! test/java/lang/management/ManagementFactory/ThreadMXBeanProxy.java Changeset: 871c10d47f8d Author: swamyv Date: 2008-08-06 10:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/871c10d47f8d Merge Changeset: 659b74b5373f Author: martin Date: 2008-08-07 06:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/659b74b5373f 6730507: java.util.Timer schedule delay Long.MAX_VALUE causes task to execute multiple times Reviewed-by: chegar ! src/share/classes/java/util/Timer.java + test/java/util/Timer/DelayOverflow.java Changeset: afe18ad188a1 Author: emcmanus Date: 2008-08-07 16:25 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/afe18ad188a1 6717257: MBeanServer doesn't describe RuntimeException for methods inherited from MBeanServerConnection Reviewed-by: dfuchs ! src/share/classes/javax/management/MBeanServer.java Changeset: 515175a26f49 Author: tbell Date: 2008-08-07 18:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/515175a26f49 Merge Changeset: 233f8854d8b4 Author: dfuchs Date: 2008-08-08 14:24 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/233f8854d8b4 6733294: MBeans tab - UI issues with writable attributes Reviewed-by: emcmanus ! make/netbeans/jconsole/build.properties ! make/netbeans/jconsole/build.xml ! src/share/classes/sun/tools/jconsole/inspector/TableSorter.java ! src/share/classes/sun/tools/jconsole/inspector/XMBeanAttributes.java ! src/share/classes/sun/tools/jconsole/inspector/XPlotter.java ! src/share/classes/sun/tools/jconsole/inspector/XSheet.java ! src/share/classes/sun/tools/jconsole/inspector/XTable.java ! src/share/classes/sun/tools/jconsole/inspector/XTextFieldEditor.java Changeset: e9de9ae8c214 Author: emcmanus Date: 2008-08-08 15:08 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e9de9ae8c214 6334663: TabularDataSupport should be able to return values in the insertion order Reviewed-by: dfuchs ! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/share/classes/javax/management/openmbean/TabularDataSupport.java + test/javax/management/openmbean/TabularDataOrderTest.java Changeset: 4fac95ca002a Author: emcmanus Date: 2008-08-08 15:10 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4fac95ca002a Merge Changeset: 343d63bb2609 Author: emcmanus Date: 2008-08-08 18:36 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/343d63bb2609 6610174: Improve CompositeDataSupport.toString when it includes arrays Reviewed-by: dfuchs ! src/share/classes/javax/management/openmbean/CompositeDataSupport.java + test/javax/management/openmbean/CompositeDataStringTest.java Changeset: c32e27a3c619 Author: tbell Date: 2008-08-10 18:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c32e27a3c619 Merge Changeset: e7d93d1d2bf0 Author: tbell Date: 2008-08-14 22:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e7d93d1d2bf0 Merge - make/ASSEMBLY_EXCEPTION - make/LICENSE - make/README - make/README-builds.html - make/README.html - make/THIRD_PARTY_README From john.coomes at sun.com Tue Aug 19 17:12:22 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Wed, 20 Aug 2008 00:12:22 +0000 Subject: hg: jdk7/hotspot/langtools: 23 new changesets Message-ID: <20080820001258.C0CF4D4B9@hg.openjdk.java.net> Changeset: 4af43632966c Author: xdono Date: 2008-08-04 13:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/4af43632966c Added tag jdk7-b32 for changeset 13aee98cc0d8 ! .hgtags Changeset: 866db3b5e7b2 Author: jjg Date: 2008-07-23 19:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/866db3b5e7b2 6726015: JavaCompiler: replace desugarLater by compileStates Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! test/tools/javac/6199662/Tree.java Changeset: 77dba8b57346 Author: mcimadamore Date: 2008-07-24 10:35 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/77dba8b57346 6651719: Compiler crashes possibly during forward reference of TypeParameter Summary: compiler should apply capture conversion when checking for bound conformance Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java - test/tools/javac/capture/Capture4.java + test/tools/javac/generics/wildcards/6651719/T6651719a.java + test/tools/javac/generics/wildcards/6651719/T6651719b.java Changeset: 36df13bde238 Author: mcimadamore Date: 2008-07-24 11:12 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/36df13bde238 6594284: NPE thrown when calling a method on an intersection type Summary: javac should report an error when the capture of an actual type parameter does not exist Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/capture/T6594284.java Changeset: 5c9cdeb740f2 Author: mcimadamore Date: 2008-07-24 19:06 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/5c9cdeb740f2 6717241: some diagnostic argument is prematurely converted into a String object Summary: removed early toString() conversions applied to diagnostic arguments Reviewed-by: jjg + src/share/classes/com/sun/tools/javac/api/Formattable.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/parser/Keywords.java ! src/share/classes/com/sun/tools/javac/parser/Parser.java ! src/share/classes/com/sun/tools/javac/parser/Token.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/DiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! test/tools/javac/5045412/out ! test/tools/javac/6330920/T6330920.out + test/tools/javac/6717241/T6717241a.java + test/tools/javac/6717241/T6717241a.out + test/tools/javac/6717241/T6717241b.java + test/tools/javac/6717241/T6717241b.out ! test/tools/javac/ExtendsAccess/ExtendsAccess.out ! test/tools/javac/NonStaticFieldExpr1.out ! test/tools/javac/NonStaticFieldExpr2.out ! test/tools/javac/NonStaticFieldExpr3.out ! test/tools/javac/T6247324.out ! test/tools/javac/annotations/6365854/test1.out ! test/tools/javac/generics/inference/6611449/T6611449.out ! test/tools/javac/policy/byfile.ABD.out ! test/tools/javac/policy/bytodo.ABD.out ! test/tools/javac/policy/simple.ABD.out Changeset: 8973372aedf8 Author: mcimadamore Date: 2008-07-25 12:05 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/8973372aedf8 6500701: Enhanced for loop with generics generates faulty bytecode Summary: Lower is too strict when translating enhanced causing CCE to be thrown at runtime Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/foreach/T6500701.java Changeset: dc4744d13247 Author: mcimadamore Date: 2008-07-25 12:22 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/dc4744d13247 6675483: Javac rejects multiple type-variable bound declarations starting with an enum type Summary: Intersection types bounded by an enum are erroeously considered harmful by javac Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/enum/T6675483.java Changeset: 37470f5ea179 Author: mcimadamore Date: 2008-07-28 10:22 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/37470f5ea179 6720185: DiagnosticFormatter refactoring Summary: Brand new hierarchy of diagnostic formatters for achieving better reusability Reviewed-by: jjg + src/share/classes/com/sun/tools/javac/api/DiagnosticFormatter.java + src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java + src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java - src/share/classes/com/sun/tools/javac/util/DiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/Log.java + src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java Changeset: 0a5f04fb7282 Author: tbell Date: 2008-08-07 09:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/0a5f04fb7282 Merge Changeset: 1c4a97a661b9 Author: xdono Date: 2008-08-14 09:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/1c4a97a661b9 Added tag jdk7-b33 for changeset 0a5f04fb7282 ! .hgtags Changeset: 3437676858e3 Author: jjg Date: 2008-08-01 15:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/3437676858e3 6627362: javac generates code that uses array.clone, which is not available on JavaCard 6627364: javac needs Float and Double on the bootclasspath even when not directly used 6627366: javac needs Cloneable and Serializable on the classpath even when not directly used Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! test/tools/javac/5045412/Bar.java ! test/tools/javac/5045412/Foo.java - test/tools/javac/5045412/out + test/tools/javac/6627362/T6627362.java + test/tools/javac/6627362/x/E.java + test/tools/javac/6627362/x/Object.java + test/tools/javac/synthesize/Boolean.java + test/tools/javac/synthesize/Byte.java + test/tools/javac/synthesize/Character.java + test/tools/javac/synthesize/Cloneable.java + test/tools/javac/synthesize/Double.java + test/tools/javac/synthesize/Float.java + test/tools/javac/synthesize/Integer.java + test/tools/javac/synthesize/Long.java + test/tools/javac/synthesize/Main.java + test/tools/javac/synthesize/Number.java + test/tools/javac/synthesize/Object.java + test/tools/javac/synthesize/Serializable.java + test/tools/javac/synthesize/Short.java + test/tools/javac/synthesize/Test.java + test/tools/javac/synthesize/Void.java Changeset: fd1d361ae294 Author: jjg Date: 2008-08-04 15:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/fd1d361ae294 4111861: static final field contents are not displayed Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javap/ClassWriter.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/Options.java ! src/share/classes/com/sun/tools/javap/resources/javap.properties + test/tools/javap/4111861/A.java + test/tools/javap/4111861/T4111861.java Changeset: 05684554f040 Author: jjg Date: 2008-08-04 17:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/05684554f040 4884240: additional option required for javap Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javap/ClassWriter.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/Options.java ! src/share/classes/com/sun/tools/javap/resources/javap.properties + test/tools/javap/T4884240.java ! test/tools/javap/T6622260.java Changeset: b6d5f53b3b29 Author: mcimadamore Date: 2008-08-05 12:54 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/b6d5f53b3b29 6730423: Diagnostic formatter should be an instance field of JCDiagnostic Summary: JCDiagnostic.fragment should be deprecated and the diagnostic factory should be used instead Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java Changeset: 6be961ee2290 Author: jjg Date: 2008-08-05 17:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/6be961ee2290 6733995: legal notice repair on langtools/src/share/classes/com/sun/tools/javap/JavapTask.java Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javap/JavapTask.java Changeset: 7ec8d871eb8c Author: tbell Date: 2008-08-07 18:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/7ec8d871eb8c Merge - test/tools/javac/5045412/out Changeset: d635feaf3747 Author: mcimadamore Date: 2008-08-08 15:16 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/d635feaf3747 6695838: javac does not detect cyclic inheritance involving static inner classes after import clause Summary: Javac fails to detect some errors due to the order in which a class' static imports are entered Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/staticImport/6695838/T6695838.java + test/tools/javac/staticImport/6695838/a/Foo.java + test/tools/javac/staticImport/6695838/a/FooInterface.java Changeset: 30a415f8667f Author: mcimadamore Date: 2008-08-08 17:38 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/30a415f8667f 6718364: inference fails when a generic method is invoked with raw arguments Summary: Bug in the implementation of Types.isSubtypeUnchecked Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/generics/inference/6718364/T6718364.java + test/tools/javac/generics/inference/6718364/T6718364.out Changeset: 6542933af8f4 Author: mcimadamore Date: 2008-08-08 17:43 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/6542933af8f4 6676362: Spurious forward reference error with final var + instance variable initializer Summary: Some javac forward reference errors aren't compliant with the JLS Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/ForwardReference/T6676362a.java + test/tools/javac/ForwardReference/T6676362b.java ! test/tools/javac/enum/forwardRef/T6425594.out Changeset: fac6b1beaa5a Author: mcimadamore Date: 2008-08-08 17:48 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/fac6b1beaa5a 6734819: Javac performs flows analysis on already translated classes Summary: Regression in JavaCompiler.desugar introduced in 6726015 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java + test/tools/javac/6734819/T6734819a.java + test/tools/javac/6734819/T6734819a.out + test/tools/javac/6734819/T6734819b.java + test/tools/javac/6734819/T6734819b.out + test/tools/javac/6734819/T6734819c.java + test/tools/javac/6734819/T6734819c.out Changeset: 938a80a47670 Author: mcimadamore Date: 2008-08-08 17:52 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/938a80a47670 6732461: broken message file for annotation processing Summary: Regression in sqe test introduced in 6720185 Reviewed-by: jjg ! src/share/classes/com/sun/tools/apt/util/Bark.java Changeset: eefde0421566 Author: tbell Date: 2008-08-10 18:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/eefde0421566 Merge Changeset: 4026dece07e8 Author: tbell Date: 2008-08-14 22:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/4026dece07e8 Merge From y.s.ramakrishna at sun.com Wed Aug 20 11:22:44 2008 From: y.s.ramakrishna at sun.com (y.s.ramakrishna at sun.com) Date: Wed, 20 Aug 2008 18:22:44 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20080820182248.9E572D63C@hg.openjdk.java.net> Changeset: 9199f248b0ee Author: ysr Date: 2008-08-14 17:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9199f248b0ee 6722112: CMS: Incorrect encoding of overflown object arrays during concurrent precleaning Summary: When an object array overflows during precleaning, we should have been marking the entire array dirty, not just its first card. Reviewed-by: jmasa, poonam, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: 92e12124e774 Author: ysr Date: 2008-08-20 01:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/92e12124e774 Merge From andrei.pangin at sun.com Wed Aug 20 17:02:50 2008 From: andrei.pangin at sun.com (andrei.pangin at sun.com) Date: Thu, 21 Aug 2008 00:02:50 +0000 Subject: hg: jdk7/hotspot/hotspot: 5 new changesets Message-ID: <20080821000300.13BF8D7AD@hg.openjdk.java.net> Changeset: 51ae48d8072f Author: kamg Date: 2008-08-13 08:56 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/51ae48d8072f 6736718: more copyright headers wrong Summary: Changed license headers to GPL Reviewed-by: tonyp, rasbold ! make/hotspot_distro ! test/compiler/6646019/Test.java ! test/compiler/6689060/Test.java ! test/compiler/6695810/Test.java Changeset: 3529d0e8d09c Author: xlu Date: 2008-08-15 10:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3529d0e8d09c 6608862: segv in JvmtiEnvBase::check_for_periodic_clean_up() Reviewed-by: dholmes, dcubed, jcoomes ! src/share/vm/runtime/thread.cpp Changeset: 6e76352f1f62 Author: xlu Date: 2008-08-18 14:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6e76352f1f62 6459085: naked pointer subtractions in class data sharing code Reviewed-by: jcoomes ! make/linux/makefiles/vm.make ! src/share/vm/memory/dump.cpp Changeset: 70c4fb9cf899 Author: apangin Date: 2008-08-19 06:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/70c4fb9cf899 Merge - agent/src/share/lib/jlfgr-1_0.jar - agent/src/share/lib/maf-1_0.jar ! src/share/vm/memory/dump.cpp ! test/compiler/6646019/Test.java ! test/compiler/6689060/Test.java ! test/compiler/6695810/Test.java Changeset: d7bb383033d6 Author: apangin Date: 2008-08-20 12:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d7bb383033d6 Merge From erik.trimble at sun.com Wed Aug 20 22:56:56 2008 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Thu, 21 Aug 2008 05:56:56 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20080821055700.2EE22D7E0@hg.openjdk.java.net> Changeset: 5b3b8a69f10f Author: xdono Date: 2008-08-14 09:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5b3b8a69f10f Added tag jdk7-b33 for changeset 585535ec8a14 ! .hgtags Changeset: 9f7cf8db35b8 Author: trims Date: 2008-08-20 20:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9f7cf8db35b8 Merge From chuck.rasbold at sun.com Thu Aug 21 08:21:33 2008 From: chuck.rasbold at sun.com (chuck.rasbold at sun.com) Date: Thu, 21 Aug 2008 15:21:33 +0000 Subject: hg: jdk7/hotspot/hotspot: 5 new changesets Message-ID: <20080821152145.8D1D7D814@hg.openjdk.java.net> Changeset: c3e045194476 Author: kvn Date: 2008-08-01 10:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c3e045194476 6731641: assert(m->adr_type() == mach->adr_type(),"matcher should not change adr type") Summary: fixed few addP node type and narrow oop type problems. Reviewed-by: rasbold, never ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/type.cpp Changeset: 616a07a75c3c Author: rasbold Date: 2008-08-14 10:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/616a07a75c3c 6732154: REG: Printing an Image using image/gif doc flavor crashes the VM, Solsparc Summary: delay transform call until uses of t2 are constructed Reviewed-by: never ! src/share/vm/opto/divnode.cpp Changeset: ea18057223c4 Author: never Date: 2008-08-18 23:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ea18057223c4 6732194: Data corruption dependent on -server/-client/-Xbatch Summary: rematerializing nodes results in incorrect inputs Reviewed-by: rasbold ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/reg_split.cpp Changeset: ce93a51457ae Author: rasbold Date: 2008-08-19 07:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ce93a51457ae 6730716: nulls from two unrelated classes compare not equal Summary: check for not-nullness after proving that types are unrelated Reviewed-by: kvn, never ! src/share/vm/opto/subnode.cpp Changeset: f8068895c22d Author: rasbold Date: 2008-08-21 05:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f8068895c22d Merge From Xiaobin.Lu at Sun.COM Fri Aug 22 18:51:08 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Fri, 22 Aug 2008 18:51:08 -0700 Subject: review request for 6740526 Message-ID: <48AF6D0C.7060307@Sun.COM> Webrev: http://javaweb.sfbay/~xl116366/webrev/6740526/ 6740526: sun/management/HotspotThreadMBean/GetInternalThreads.java test failed Details: The above test failure is caused by a recent fix for 6608862. The problem there was that when some JVMTI operation was made to examine all the threads' state and while in the meantime, the WatcherThread is actually exiting. This makes the ThreadClosure->do_thread call fail since we are now referencing a NULL pointer. To preserve WatcherThread and its data inside memory, we grab the Terminator_lock before making a call on it. So the thread calling WatcherThread::stop will be blocked and therefore can't set the reference to NULL and destroy the structure. I assumed that these operations (basically Threads::threads_do) are always called at safepoint, therefore, the rank checking when acquiring the Terminator_lock will be bypassed. The assumption is wrong since obviously some calls originating from management.cpp for example, aren't issued at safepoint, thus making the rank checking fail. The fix is that we remove the lock acquisition. As documented in the comment, strictly speaking, this isn't sufficient to make sure the data for WatcherThread is still there when the call is actually being made, but the chance of that is extremely small. Reviewed by: Verified by: All tests under sun/management Test reported in 6608862 PRT Thanks in advance! -Xiaobin From David.Holmes at Sun.COM Sat Aug 23 03:15:41 2008 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Sat, 23 Aug 2008 20:15:41 +1000 Subject: review request for 6740526 In-Reply-To: <48AF6D0C.7060307@Sun.COM> References: <48AF6D0C.7060307@Sun.COM> Message-ID: <48AFE34D.9020301@sun.com> Hi Xiaobin, I'd add to the comment: "The right way to prevent termination would be to acquire the Terminator_lock, but we can't do that without violating the lock rank checking in some cases." Cheers, David Xiaobin Lu said the following on 08/23/08 11:51: > Webrev: http://javaweb.sfbay/~xl116366/webrev/6740526/ > > 6740526: sun/management/HotspotThreadMBean/GetInternalThreads.java test > failed > > Details: > > The above test failure is caused by a recent fix for 6608862. The > problem there was that when some JVMTI operation was made to examine all > the threads' state and while in the meantime, the WatcherThread is > actually exiting. This makes the ThreadClosure->do_thread call fail > since we are now referencing a NULL pointer. To preserve WatcherThread > and its data inside memory, we grab the Terminator_lock before making a > call on it. So the thread calling WatcherThread::stop will be blocked > and therefore can't set the reference to NULL and destroy the structure. > I assumed that these operations (basically Threads::threads_do) are > always called at safepoint, therefore, the rank checking when acquiring > the Terminator_lock will be bypassed. The assumption is wrong since > obviously some calls originating from management.cpp for example, aren't > issued at safepoint, thus making the rank checking fail. > > The fix is that we remove the lock acquisition. As documented in the > comment, strictly speaking, this isn't sufficient to make sure the data > for WatcherThread is still there when the call is actually being made, > but the chance of that is extremely small. > > Reviewed by: > > Verified by: > All tests under sun/management > Test reported in 6608862 > PRT > > Thanks in advance! > > -Xiaobin From martinrb at google.com Sat Aug 23 16:22:03 2008 From: martinrb at google.com (Martin Buchholz) Date: Sat, 23 Aug 2008 16:22:03 -0700 Subject: Crash in ciTypeFlow.cpp Message-ID: <1ccfd1c10808231622x25ab2b16i52459b96ce74e361@mail.gmail.com> Hi hotspot maintainers, For a while now, there's been a crash in hotspot compiled with gcc 4.2 in ciTypeFlow.cpp (crashes in Swingset demo) There have been a number of approaches to fixing it. It appears that Matthias Klose has patched icedtea6 as follows: --- openjdk/hotspot/src/share/vm/ci/ciTypeFlow.hpp~ 2008-07-10 22:04:30.000000000 +0200 +++ openjdk/hotspot/src/share/vm/ci/ciTypeFlow.hpp 2008-07-25 14:32:03.544802121 +0200 @@ -130,7 +130,7 @@ // Used as a combined index for locals and temps enum Cell { - Cell_0 + Cell_0, Cell_max = UINT_MAX }; // A StateVector summarizes the type information at some Unfortunately, this fails to compile (at least with gcc 4.0 and OpenJDK7) cc1plus: warnings being treated as errors /usr/local/google/home/martin/ws/hotspot/hotspot/src/share/vm/ci/ciTypeFlow.cpp: In member function 'const ciTypeFlow::StateVector* ciTypeFlow::get_start_state()': /usr/local/google/home/martin/ws/hotspot/hotspot/src/share/vm/ci/ciTypeFlow.cpp:392: warning: comparison between signed and unsigned integer expressions make[6]: *** [ciTypeFlow.o] Error 1 Here's another try, and this time let's try to get it into both OpenJDK7 and OpenJDK6. I'll do the push into OpenJDK7. # HG changeset patch # User martin # Date 1219532277 25200 # Node ID 52c7e88431fc50fd682a0506cd9588c476ca7a00 # Parent f8068895c22d848b6f0e6998886652c3d2f51b24 6666666: Crash in ciTypeFlow with gcc 4.2, enum Cell range too small Reviewed-by: Contributed-by: doko at ubuntu.com diff --git a/src/share/vm/ci/ciTypeFlow.hpp b/src/share/vm/ci/ciTypeFlow.hpp --- a/src/share/vm/ci/ciTypeFlow.hpp +++ b/src/share/vm/ci/ciTypeFlow.hpp @@ -127,7 +127,7 @@ // Used as a combined index for locals and temps enum Cell { - Cell_0 + Cell_0, Cell_max = INT_MAX }; // A StateVector summarizes the type information at some There doesn't seem to be a bug for this in bugtraq. Sun folk, please file a bug, and let me know which team hg forest to push this into. For those of us using newer gccs, this is a P1 bug. As justification, note that the existing code is illegal C++ Enum variables must take on values in the range of the enum constants, which was not the case with the old code. @doko: please review. My version of this change maintains the signedness of enum Cell, avoiding possible changes in behavior and subtleties with signed/unsigned comparison. Let's all try harder to get "community"-developed patches upstream. Thanks, Martin From Daniel.Daugherty at Sun.COM Mon Aug 25 06:44:00 2008 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Mon, 25 Aug 2008 07:44:00 -0600 Subject: review request for 6740526 In-Reply-To: <48AFE34D.9020301@sun.com> References: <48AF6D0C.7060307@Sun.COM> <48AFE34D.9020301@sun.com> Message-ID: <48B2B720.7040301@sun.com> There is already some special casing for the Terminator_lock relative to the Safepoint_lock. Perhaps there is need for a more complete special case for the Terminator_lock. Or perhaps we need to have the ability to make orthogonal locks and then morph all the existing special case locks into orthogonal locks. I guess what I'm saying is that we need to revisit use of the Terminator_lock and its interaction with other locks. Dan David Holmes - Sun Microsystems wrote: > Hi Xiaobin, > > I'd add to the comment: > > "The right way to prevent termination would be to acquire the > Terminator_lock, but we can't do that without violating the lock rank > checking in some cases." > > Cheers, > David > > Xiaobin Lu said the following on 08/23/08 11:51: >> Webrev: http://javaweb.sfbay/~xl116366/webrev/6740526/ >> >> 6740526: sun/management/HotspotThreadMBean/GetInternalThreads.java >> test failed >> >> Details: >> >> The above test failure is caused by a recent fix for 6608862. The >> problem there was that when some JVMTI operation was made to examine >> all the threads' state and while in the meantime, the WatcherThread >> is actually exiting. This makes the ThreadClosure->do_thread call >> fail since we are now referencing a NULL pointer. To preserve >> WatcherThread and its data inside memory, we grab the Terminator_lock >> before making a call on it. So the thread calling WatcherThread::stop >> will be blocked and therefore can't set the reference to NULL and >> destroy the structure. I assumed that these operations (basically >> Threads::threads_do) are always called at safepoint, therefore, the >> rank checking when acquiring the Terminator_lock will be bypassed. >> The assumption is wrong since obviously some calls originating from >> management.cpp for example, aren't issued at safepoint, thus making >> the rank checking fail. >> >> The fix is that we remove the lock acquisition. As documented in the >> comment, strictly speaking, this isn't sufficient to make sure the >> data for WatcherThread is still there when the call is actually being >> made, but the chance of that is extremely small. >> >> Reviewed by: >> >> Verified by: >> All tests under sun/management >> Test reported in 6608862 >> PRT >> >> Thanks in advance! >> >> -Xiaobin From Xiaobin.Lu at Sun.COM Mon Aug 25 10:19:59 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Mon, 25 Aug 2008 10:19:59 -0700 Subject: review request for 6740526 In-Reply-To: <48B2B720.7040301@sun.com> References: <48AF6D0C.7060307@Sun.COM> <48AFE34D.9020301@sun.com> <48B2B720.7040301@sun.com> Message-ID: <48B2E9BF.10403@Sun.COM> Daniel D. Daugherty wrote: > There is already some special casing for the Terminator_lock > relative to the Safepoint_lock. Perhaps there is need for a > more complete special case for the Terminator_lock. Or perhaps > we need to have the ability to make orthogonal locks and then > morph all the existing special case locks into orthogonal locks. > > I guess what I'm saying is that we need to revisit use of the > Terminator_lock and its interaction with other locks. Hi Dan, I think it might be better to log a RFE for this feature and address this particular crash first. -Xiaobin > > Dan > > > David Holmes - Sun Microsystems wrote: >> Hi Xiaobin, >> >> I'd add to the comment: >> >> "The right way to prevent termination would be to acquire the >> Terminator_lock, but we can't do that without violating the lock rank >> checking in some cases." >> >> Cheers, >> David >> >> Xiaobin Lu said the following on 08/23/08 11:51: >>> Webrev: http://javaweb.sfbay/~xl116366/webrev/6740526/ >>> >>> 6740526: sun/management/HotspotThreadMBean/GetInternalThreads.java >>> test failed >>> >>> Details: >>> >>> The above test failure is caused by a recent fix for 6608862. The >>> problem there was that when some JVMTI operation was made to examine >>> all the threads' state and while in the meantime, the WatcherThread >>> is actually exiting. This makes the ThreadClosure->do_thread call >>> fail since we are now referencing a NULL pointer. To preserve >>> WatcherThread and its data inside memory, we grab the >>> Terminator_lock before making a call on it. So the thread calling >>> WatcherThread::stop will be blocked and therefore can't set the >>> reference to NULL and destroy the structure. I assumed that these >>> operations (basically Threads::threads_do) are always called at >>> safepoint, therefore, the rank checking when acquiring the >>> Terminator_lock will be bypassed. The assumption is wrong since >>> obviously some calls originating from management.cpp for example, >>> aren't issued at safepoint, thus making the rank checking fail. >>> >>> The fix is that we remove the lock acquisition. As documented in the >>> comment, strictly speaking, this isn't sufficient to make sure the >>> data for WatcherThread is still there when the call is actually >>> being made, but the chance of that is extremely small. >>> >>> Reviewed by: >>> >>> Verified by: >>> All tests under sun/management >>> Test reported in 6608862 >>> PRT >>> >>> Thanks in advance! >>> >>> -Xiaobin From volker.simonis at gmail.com Mon Aug 25 12:19:17 2008 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 25 Aug 2008 21:19:17 +0200 Subject: Problems with double reminder on Windows/x86_64 and Visual Studio 2005 Message-ID: Hi, we had a strange problem wich lead to failures in the JCK test Math2012. The problem only occured if some other JCK-Tests where compiled and execuetd in a special order before the tests in Math2012. I could finally track down the problem to the following simple test case: ==================================================== public class Log10 { public static double log10(double d) { return Math.log10(d); } public static double drem2(double d) { return d % 2; } public static void main(String args[]) { System.out.println("log10(0) = " + Math.log10(0.0d)); System.out.println("log10(0) = " + log10(0.0d)); System.out.println("drem2(4.0) = " + drem2(4.0d)); } } ==================================================== which always fails on Windows/x86_64 (i.e. prints "NaN" for the result of 4.0 % 2.0 which should be 0.0) if executed like this: java -Xcomp -Xbatch -XX:CompileCommand="compileonly Log10 log10" -XX:+PrintCompilation Log10 VM option 'CompileCommand=compileonly Log10 log10' VM option '+PrintCompilation' CompilerOracle: compileonly Log10.log10 log10(0) = -Infinity 1 b Log10::log10 (5 bytes) log10(0) = -Infinity drem2(4.0) = NaN Notice however that we are using a version of the Java 6 HotSpot compiled with Visual Studio 2005. I couldn't reproduce the problem with jdk-7-ea-bin-b32-windows-x64-debug-04_aug_2008 however I could verify that the code generated by both, our JDK 6 and the latest jdk-7 is virtually the same. The interesting part is the compiled version of the method Log10.log10(): 000 pushq rbp subq rsp, #16 # Create frame nop # nop for patch_verified_entry 006 fldlg2 #Log10 fyl2x # Q=Log10*Log_2(x) 024 addq rsp, 16 # Destroy frame popq rbp testl rax, [rip + #offset_to_poll_page] # Safepoint: poll for GC 02f ret The computation of Math.log10(0.0d) which correctly returns -Infinity sets the "Zero Divide" flag in the FP status word as described in http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26569.pdf. After this computation "SharedRuntime::drem()" is called for the computation of the double reminder in the method "drem2()" of the above example. "SharedRuntime::drem()" itself just delegates the computation to the "fmod()" function (defined in ) of the underlying platform. The presence of the "Zero Divide" flag in the FP status word seems to be no problem for the "fmod()" which is used by the jdk-7-ea-bin-b32-windows-x64-debug-04_aug_2008 executable (from msvcr71.dll) and it is no problem on Linux/x86_64 either, but it IS definitely a problem for the "fmod()" from the "msvcr80d.dll" which is used in our MSVC 2005 build. I have two questions now: 1. Is it ok that the intrinsic for Math.log10() leaves the exceptions bits as they are in the FP status word? 2. Can somebody confirm that the described behaviour of "fmod()" from "msvcr80d.dll" as used by MSVC 2005 is buggy? (I couldn't find any bug report and I also couldn't find reference if "fmod() should depend on the FP status word or not.) It would also be nice if somebody who has recent OpenJDK built with MSVC 2005 could confirm the above problem or if somebody could just confirm or disprove the "fmod()" problem within different versions of MSVC. Here's a small C-program which can be used to test if "fmod()" is dependent on the FP status word: ====================== fmod.c ==================== #include #include extern void fpu_asm(); int main(int argc, char* argv[]) { double d = 0.0; printf("fmod(4.0, 2.0) = %f\n", fmod(4.0, 2.0)); fpu_asm(); printf("fmod(4.0, 2.0) = %f\n", fmod(4.0, 2.0)); } ===================================================== ===================== fpu_asm.asm ==================== PUBLIC fpu_asm .CODE ALIGN 8 fpu_asm PROC fldlg2 fldz fyl2x ret ALIGN 8 fpu_asm ENDP END ====================================================== Compile and run with: ml64 /c fpu_asm.asm cl fmod.c fpu_asm.obj fmod.exe fmod(4.0, 2.0) = 0.000000 fmod(4.0, 2.0) = -1.#IND00 Regards, Volker PS: the obvious solution of calling "_clearfp()" as defined in just before a call to "fmod()" unfortunately doesn't work, because "_clearfp()" (at least in MSVC 2005) only cleans the SSE status register MXCSR. The only solution I see right now is using the FCLEX assembler instruction, and because MSVC 2005 has no inline assembler for x86_64 I'll probably have to write the whole assembler function for the assembler instruction. Or does somebody have a smarter solution? PPS: this is a nice example, how a compiler switch can get you a lot of fun (isn't it Kelly:) ... From y.s.ramakrishna at sun.com Mon Aug 25 16:50:10 2008 From: y.s.ramakrishna at sun.com (y.s.ramakrishna at sun.com) Date: Mon, 25 Aug 2008 23:50:10 +0000 Subject: hg: jdk7/hotspot/hotspot: 5 new changesets Message-ID: <20080825235022.CC58DDB08@hg.openjdk.java.net> Changeset: 1e5d20c34408 Author: tonyp Date: 2008-08-19 17:55 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1e5d20c34408 6736341: PermGen size is insufficient for jconsole Summary: Removing two buggy methods that should not be used, but ended up being used due to a re-organization in the class hierarchy. Reviewed-by: jmasa, ysr, kamg, coleenp ! src/share/vm/memory/compactingPermGenGen.cpp ! src/share/vm/memory/compactingPermGenGen.hpp Changeset: 331eaa715e58 Author: ysr Date: 2008-08-20 11:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/331eaa715e58 Merge Changeset: bfcb639d5bca Author: ysr Date: 2008-08-20 15:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/bfcb639d5bca 6739357: CMS: Switch off CMSPrecleanRefLists1 until 6722113 can be fixed Summary: Temporarily switch off the precleaning of Reference lists completely until related issues are fixed in 6722113. Reviewed-by: jmasa, poonam, tonyp ! src/share/vm/runtime/globals.hpp Changeset: 387a62b4be60 Author: jmasa Date: 2008-08-20 23:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/387a62b4be60 6728478: Assertion at parallel promotion from young to old generation Summary: The fix avoids a call to address_for_index() in this particular situation where it is not known if the passed index is in bounds. Reviewed-by: tonyp ! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp ! src/share/vm/memory/blockOffsetTable.hpp Changeset: 58eb97387b90 Author: ysr Date: 2008-08-25 12:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/58eb97387b90 Merge From Thomas.Rodriguez at Sun.COM Tue Aug 26 13:19:23 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 26 Aug 2008 13:19:23 -0700 Subject: Crash in ciTypeFlow.cpp In-Reply-To: <1ccfd1c10808231622x25ab2b16i52459b96ce74e361@mail.gmail.com> References: <1ccfd1c10808231622x25ab2b16i52459b96ce74e361@mail.gmail.com> Message-ID: Sorry this took so long. I had intended to pick this up when it was first discussed but with vacation and other things I lost track of it. Since we want everything, even trivial things, to go through our jprt build system, I picked this up and put it into the queue on its way to hotspot-comp/hotspot. It should be completed by the end of the day since it is second in line. The webrev is at http://webrev.invokedynamic.info/never/6741642 . INT_MAX is a good enough value since it should only contain positive integers. Again sorry for the delay in handling this. tom On Aug 23, 2008, at 4:22 PM, Martin Buchholz wrote: > Hi hotspot maintainers, > > For a while now, there's been a crash in hotspot compiled with gcc 4.2 > in ciTypeFlow.cpp (crashes in Swingset demo) > > There have been a number of approaches to fixing it. > It appears that Matthias Klose has patched icedtea6 as follows: > > > > --- openjdk/hotspot/src/share/vm/ci/ciTypeFlow.hpp~ 2008-07-10 > 22:04:30.000000000 +0200 > +++ openjdk/hotspot/src/share/vm/ci/ciTypeFlow.hpp 2008-07-25 > 14:32:03.544802121 +0200 > @@ -130,7 +130,7 @@ > > // Used as a combined index for locals and temps > enum Cell { > - Cell_0 > + Cell_0, Cell_max = UINT_MAX > }; > > // A StateVector summarizes the type information at some > > > Unfortunately, this fails to compile (at least with gcc 4.0 > and OpenJDK7) > > cc1plus: warnings being treated as errors > /usr/local/google/home/martin/ws/hotspot/hotspot/src/share/vm/ci/ > ciTypeFlow.cpp: > In member function 'const ciTypeFlow::StateVector* > ciTypeFlow::get_start_state()': > /usr/local/google/home/martin/ws/hotspot/hotspot/src/share/vm/ci/ > ciTypeFlow.cpp:392: > warning: comparison between signed and unsigned integer expressions > make[6]: *** [ciTypeFlow.o] Error 1 > > > Here's another try, > and this time let's try to get it into both OpenJDK7 and OpenJDK6. > I'll do the push into OpenJDK7. > > # HG changeset patch > # User martin > # Date 1219532277 25200 > # Node ID 52c7e88431fc50fd682a0506cd9588c476ca7a00 > # Parent f8068895c22d848b6f0e6998886652c3d2f51b24 > 6666666: Crash in ciTypeFlow with gcc 4.2, enum Cell range too small > Reviewed-by: > Contributed-by: doko at ubuntu.com > > diff --git a/src/share/vm/ci/ciTypeFlow.hpp b/src/share/vm/ci/ > ciTypeFlow.hpp > --- a/src/share/vm/ci/ciTypeFlow.hpp > +++ b/src/share/vm/ci/ciTypeFlow.hpp > @@ -127,7 +127,7 @@ > > // Used as a combined index for locals and temps > enum Cell { > - Cell_0 > + Cell_0, Cell_max = INT_MAX > }; > > // A StateVector summarizes the type information at some > > > There doesn't seem to be a bug for this in bugtraq. > Sun folk, please file a bug, > and let me know which team hg forest to push this into. > For those of us using newer gccs, this is a P1 bug. > > As justification, note that the existing code is illegal C++ > Enum variables must take on values in the range of the enum constants, > which was not the case with the old code. > > @doko: please review. My version of this change maintains the > signedness of enum Cell, avoiding possible changes in behavior > and subtleties with signed/unsigned comparison. > > Let's all try harder to get "community"-developed patches upstream. > > Thanks, > > Martin From Thomas.Rodriguez at Sun.COM Tue Aug 26 13:30:37 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 26 Aug 2008 13:30:37 -0700 Subject: Problems with double reminder on Windows/x86_64 and Visual Studio 2005 In-Reply-To: References: Message-ID: I can't confirm your problem but I'm not entirely surprised by it. > 1. Is it ok that the intrinsic for Math.log10() leaves the exceptions > bits as they are in the FP status word? The assembly we generate assumes that this is ok but it appears that calling out into library code could expose problems with this. > PS: the obvious solution of calling "_clearfp()" as defined in > just before a call to "fmod()" unfortunately doesn't work, > because "_clearfp()" (at least in MSVC 2005) only cleans the SSE > status register MXCSR. The only solution I see right now is using the > FCLEX assembler instruction, and because MSVC 2005 has no inline > assembler for x86_64 I'll probably have to write the whole assembler > function for the assembler instruction. Or does somebody have a > smarter solution? You could add the FCLEX to Java_to_Runtime encoding in windows_x86_64.ad though this will change all the CallLeaf variants. It would be nice if we never called out to C code for utility functions like this. We should have our own assembly versions of these functions to shield ourselves from problems. tom > > > PPS: this is a nice example, how a compiler switch can get you a lot > of fun (isn't it Kelly:) ... From martinrb at google.com Tue Aug 26 13:48:02 2008 From: martinrb at google.com (Martin Buchholz) Date: Tue, 26 Aug 2008 13:48:02 -0700 Subject: Crash in ciTypeFlow.cpp In-Reply-To: References: <1ccfd1c10808231622x25ab2b16i52459b96ce74e361@mail.gmail.com> Message-ID: <1ccfd1c10808261348k7ac4df03t67ef20790601d1b5@mail.gmail.com> Thanks, Tom. Could you include me ("martin") in the Reviewed-by: list? It would be nice if there was a JPRT "service" that non-Sun committers (pushers?) could use. One would think it would be good enough to push into a tributary forest like hotspot-runtime, since JPRT runs are certain to happen (twice, even!) on their way to the MASTER. If that's not good enough, provide a sub-sub-tributary forest. Martin From Joe.Darcy at Sun.COM Tue Aug 26 13:49:42 2008 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Tue, 26 Aug 2008 13:49:42 -0700 Subject: Crash in ciTypeFlow.cpp In-Reply-To: <1ccfd1c10808261348k7ac4df03t67ef20790601d1b5@mail.gmail.com> References: <1ccfd1c10808231622x25ab2b16i52459b96ce74e361@mail.gmail.com> <1ccfd1c10808261348k7ac4df03t67ef20790601d1b5@mail.gmail.com> Message-ID: <48B46C66.8020709@sun.com> Martin Buchholz wrote: > Thanks, Tom. > > Could you include me ("martin") in the Reviewed-by: list? > > It would be nice if there was a JPRT "service" that > non-Sun committers (pushers?) could use. > > One would think it would be good enough to push > into a tributary forest like hotspot-runtime, > since JPRT runs are certain to happen (twice, even!) > on their way to the MASTER. > If that's not good enough, provide a sub-sub-tributary forest. > > Martin > This fix will also be in OpenJDK 6 build 12. -Joe From Thomas.Rodriguez at Sun.COM Tue Aug 26 14:33:00 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 26 Aug 2008 14:33:00 -0700 Subject: Crash in ciTypeFlow.cpp In-Reply-To: <1ccfd1c10808261348k7ac4df03t67ef20790601d1b5@mail.gmail.com> References: <1ccfd1c10808231622x25ab2b16i52459b96ce74e361@mail.gmail.com> <1ccfd1c10808261348k7ac4df03t67ef20790601d1b5@mail.gmail.com> Message-ID: On Aug 26, 2008, at 1:48 PM, Martin Buchholz wrote: > Thanks, Tom. > > Could you include me ("martin") in the Reviewed-by: list? Sure thing. > > It would be nice if there was a JPRT "service" that > non-Sun committers (pushers?) could use. I know there's been talk about such a thing but I have no idea what's actually happening in that direction. tom From David.Holmes at Sun.COM Wed Aug 27 05:04:58 2008 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Wed, 27 Aug 2008 22:04:58 +1000 Subject: Problems with double reminder on Windows/x86_64 and Visual Studio 2005 In-Reply-To: References: Message-ID: <48B542EA.7040201@sun.com> Hi Volker, I don't know if this is related, or just coincidental timing but a new bug report has just been filed: 6741940 Nonvolatile XMM registers not preserved across JNI calls "Calls to the JNI entry point "CallVoidMethod" [in test program] do not preserve the nonvolatile XMM registers, unless running with -Xint. This is in violation of the Windows 64-bit ABI: http://msdn.microsoft.com/en-us/library/ms794547.aspx" This won't show up on BugParade for a day or so. Regards, David Holmes Volker Simonis said the following on 08/26/08 05:19: > Hi, > > we had a strange problem wich lead to failures in the JCK test > Math2012. The problem only occured if some other JCK-Tests where > compiled and execuetd in a special order before the tests in > Math2012. > > I could finally track down the problem to the following simple test case: > > ==================================================== > public class Log10 { > > public static double log10(double d) { > return Math.log10(d); > } > > public static double drem2(double d) { > return d % 2; > } > > public static void main(String args[]) { > System.out.println("log10(0) = " + Math.log10(0.0d)); > System.out.println("log10(0) = " + log10(0.0d)); > System.out.println("drem2(4.0) = " + drem2(4.0d)); > } > } > ==================================================== > > which always fails on Windows/x86_64 (i.e. prints "NaN" for the result > of 4.0 % 2.0 which should be 0.0) if executed like this: > > java -Xcomp -Xbatch -XX:CompileCommand="compileonly Log10 log10" > -XX:+PrintCompilation Log10 > > VM option 'CompileCommand=compileonly Log10 log10' > VM option '+PrintCompilation' > CompilerOracle: compileonly Log10.log10 > log10(0) = -Infinity > 1 b Log10::log10 (5 bytes) > log10(0) = -Infinity > drem2(4.0) = NaN > > Notice however that we are using a version of the Java 6 HotSpot > compiled with Visual Studio 2005. > > I couldn't reproduce the problem with > jdk-7-ea-bin-b32-windows-x64-debug-04_aug_2008 however I could verify > that the code generated by both, our JDK 6 and the latest jdk-7 is > virtually the same. The interesting part is the compiled version of > the method Log10.log10(): > > 000 pushq rbp > subq rsp, #16 # Create frame > nop # nop for patch_verified_entry > 006 fldlg2 #Log10 > fyl2x # Q=Log10*Log_2(x) > 024 addq rsp, 16 # Destroy frame > popq rbp > testl rax, [rip + #offset_to_poll_page] # Safepoint: poll for GC > 02f ret > > The computation of Math.log10(0.0d) which correctly returns -Infinity > sets the "Zero Divide" flag in the FP status word as described in > http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26569.pdf. > > After this computation "SharedRuntime::drem()" is called for the > computation of the double reminder in the method "drem2()" of the > above example. "SharedRuntime::drem()" itself just delegates the > computation to the "fmod()" function (defined in ) of the > underlying platform. > > The presence of the "Zero Divide" flag in the FP status word seems to > be no problem for the "fmod()" which is used by the > jdk-7-ea-bin-b32-windows-x64-debug-04_aug_2008 executable (from > msvcr71.dll) and it is no problem on Linux/x86_64 either, but it IS > definitely a problem for the "fmod()" from the "msvcr80d.dll" which is > used in our MSVC 2005 build. > > I have two questions now: > > 1. Is it ok that the intrinsic for Math.log10() leaves the exceptions > bits as they are in the FP status word? > 2. Can somebody confirm that the described behaviour of "fmod()" from > "msvcr80d.dll" as used by MSVC 2005 is buggy? (I couldn't find any bug > report and I also couldn't find reference if "fmod() should depend on > the FP status word or not.) > > It would also be nice if somebody who has recent OpenJDK built with > MSVC 2005 could confirm the above problem or if somebody could just > confirm or disprove the "fmod()" problem within different versions of > MSVC. Here's a small C-program which can be used to test if "fmod()" > is dependent on the FP status word: > > ====================== fmod.c ==================== > #include > #include > > extern void fpu_asm(); > > int main(int argc, char* argv[]) { > > double d = 0.0; > > printf("fmod(4.0, 2.0) = %f\n", fmod(4.0, 2.0)); > > fpu_asm(); > > printf("fmod(4.0, 2.0) = %f\n", fmod(4.0, 2.0)); > > } > ===================================================== > > ===================== fpu_asm.asm ==================== > PUBLIC fpu_asm > .CODE > ALIGN 8 > fpu_asm PROC > fldlg2 > fldz > fyl2x > ret > ALIGN 8 > fpu_asm ENDP > END > ====================================================== > > Compile and run with: > > ml64 /c fpu_asm.asm > cl fmod.c fpu_asm.obj > fmod.exe > fmod(4.0, 2.0) = 0.000000 > fmod(4.0, 2.0) = -1.#IND00 > > Regards, > Volker > > PS: the obvious solution of calling "_clearfp()" as defined in > just before a call to "fmod()" unfortunately doesn't work, > because "_clearfp()" (at least in MSVC 2005) only cleans the SSE > status register MXCSR. The only solution I see right now is using the > FCLEX assembler instruction, and because MSVC 2005 has no inline > assembler for x86_64 I'll probably have to write the whole assembler > function for the assembler instruction. Or does somebody have a > smarter solution? > > PPS: this is a nice example, how a compiler switch can get you a lot > of fun (isn't it Kelly:) ... From volker.simonis at gmail.com Wed Aug 27 08:01:47 2008 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 27 Aug 2008 17:01:47 +0200 Subject: Problems with double reminder on Windows/x86_64 and Visual Studio 2005 In-Reply-To: <48B542EA.7040201@sun.com> References: <48B542EA.7040201@sun.com> Message-ID: Hi David, I don't think that the problems are related although they are similar. In my case the problem is caused by the FPSW (on Windows, on Linux in gdb it's "fstat") register which is the status word for the FPU (formerly known as x87 and later as MMX) registers. The problem is that MSVC apperently doesn't support these registers any more in the sense that it doesn't generate code which uses them. This is probably also the reason why there "_clearfp()" function does not clear FPSW register but only the more modern MXCSR register (which is the status register for the XMM register set (also known as SSE2/SSE3)). On the other hand, Microsoft is STILL using the old FPU registers in their runtime functions (particularly in the "fmod()" function). And this usage interfers with the usage of the old FPU registers by the code generated from the HotSpot JIT compiler. I have no idea how the ABI convention for the FPSW register are and if such conventions even exist (I would be thankful for any pointer here). As Tom commented, the code generated by the JIT is aware of this behaviour but other C/library/JNI code may not. Regards, Volker On 8/27/08, David Holmes - Sun Microsystems wrote: > Hi Volker, > > I don't know if this is related, or just coincidental timing but a new bug > report has just been filed: > > 6741940 Nonvolatile XMM registers not preserved across JNI calls > > "Calls to the JNI entry point "CallVoidMethod" [in test program] do not > preserve the nonvolatile XMM registers, unless running with -Xint. This is > in violation of the Windows 64-bit ABI: > http://msdn.microsoft.com/en-us/library/ms794547.aspx" > > This won't show up on BugParade for a day or so. > > Regards, > David Holmes > > Volker Simonis said the following on 08/26/08 05:19: > > > > Hi, > > > > we had a strange problem wich lead to failures in the JCK test > > Math2012. The problem only occured if some other JCK-Tests where > > compiled and execuetd in a special order before the tests in > > Math2012. > > > > I could finally track down the problem to the following simple test case: > > > > ==================================================== > > public class Log10 { > > > > public static double log10(double d) { > > return Math.log10(d); > > } > > > > public static double drem2(double d) { > > return d % 2; > > } > > > > public static void main(String args[]) { > > System.out.println("log10(0) = " + Math.log10(0.0d)); > > System.out.println("log10(0) = " + log10(0.0d)); > > System.out.println("drem2(4.0) = " + drem2(4.0d)); > > } > > } > > ==================================================== > > > > which always fails on Windows/x86_64 (i.e. prints "NaN" for the result > > of 4.0 % 2.0 which should be 0.0) if executed like this: > > > > java -Xcomp -Xbatch -XX:CompileCommand="compileonly Log10 > log10" > > -XX:+PrintCompilation Log10 > > > > VM option 'CompileCommand=compileonly Log10 log10' > > VM option '+PrintCompilation' > > CompilerOracle: compileonly Log10.log10 > > log10(0) = -Infinity > > 1 b Log10::log10 (5 bytes) > > log10(0) = -Infinity > > drem2(4.0) = NaN > > > > Notice however that we are using a version of the Java 6 HotSpot > > compiled with Visual Studio 2005. > > > > I couldn't reproduce the problem with > > jdk-7-ea-bin-b32-windows-x64-debug-04_aug_2008 however I > could verify > > that the code generated by both, our JDK 6 and the latest jdk-7 is > > virtually the same. The interesting part is the compiled version of > > the method Log10.log10(): > > > > 000 pushq rbp > > subq rsp, #16 # Create frame > > nop # nop for patch_verified_entry > > 006 fldlg2 #Log10 > > fyl2x # Q=Log10*Log_2(x) > > 024 addq rsp, 16 # Destroy frame > > popq rbp > > testl rax, [rip + #offset_to_poll_page] # Safepoint: poll > for GC > > 02f ret > > > > The computation of Math.log10(0.0d) which correctly returns -Infinity > > sets the "Zero Divide" flag in the FP status word as described in > > > http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26569.pdf. > > > > After this computation "SharedRuntime::drem()" is called for the > > computation of the double reminder in the method "drem2()" of the > > above example. "SharedRuntime::drem()" itself just delegates the > > computation to the "fmod()" function (defined in ) of the > > underlying platform. > > > > The presence of the "Zero Divide" flag in the FP status word seems to > > be no problem for the "fmod()" which is used by the > > jdk-7-ea-bin-b32-windows-x64-debug-04_aug_2008 executable > (from > > msvcr71.dll) and it is no problem on Linux/x86_64 either, but it IS > > definitely a problem for the "fmod()" from the "msvcr80d.dll" which is > > used in our MSVC 2005 build. > > > > I have two questions now: > > > > 1. Is it ok that the intrinsic for Math.log10() leaves the exceptions > > bits as they are in the FP status word? > > 2. Can somebody confirm that the described behaviour of "fmod()" from > > "msvcr80d.dll" as used by MSVC 2005 is buggy? (I couldn't find any bug > > report and I also couldn't find reference if "fmod() should depend on > > the FP status word or not.) > > > > It would also be nice if somebody who has recent OpenJDK built with > > MSVC 2005 could confirm the above problem or if somebody could just > > confirm or disprove the "fmod()" problem within different versions of > > MSVC. Here's a small C-program which can be used to test if "fmod()" > > is dependent on the FP status word: > > > > ====================== fmod.c ==================== > > #include > > #include > > > > extern void fpu_asm(); > > > > int main(int argc, char* argv[]) { > > > > double d = 0.0; > > > > printf("fmod(4.0, 2.0) = %f\n", fmod(4.0, 2.0)); > > > > fpu_asm(); > > > > printf("fmod(4.0, 2.0) = %f\n", fmod(4.0, 2.0)); > > > > } > > ===================================================== > > > > ===================== fpu_asm.asm ==================== > > PUBLIC fpu_asm > > .CODE > > ALIGN 8 > > fpu_asm PROC > > fldlg2 > > fldz > > fyl2x > > ret > > ALIGN 8 > > fpu_asm ENDP > > END > > ====================================================== > > > > Compile and run with: > > > > ml64 /c fpu_asm.asm > > cl fmod.c fpu_asm.obj > > fmod.exe > > fmod(4.0, 2.0) = 0.000000 > > fmod(4.0, 2.0) = -1.#IND00 > > > > Regards, > > Volker > > > > PS: the obvious solution of calling "_clearfp()" as defined in > > just before a call to "fmod()" unfortunately doesn't work, > > because "_clearfp()" (at least in MSVC 2005) only cleans the SSE > > status register MXCSR. The only solution I see right now is using the > > FCLEX assembler instruction, and because MSVC 2005 has no inline > > assembler for x86_64 I'll probably have to write the whole assembler > > function for the assembler instruction. Or does somebody have a > > smarter solution? > > > > PPS: this is a nice example, how a compiler switch can get you a lot > > of fun (isn't it Kelly:) ... > > > From mcneill at streambase.com Wed Aug 27 13:34:34 2008 From: mcneill at streambase.com (Keith McNeill) Date: Wed, 27 Aug 2008 16:34:34 -0400 Subject: jdk deadlock bug in JDK 1.6.0_05? Message-ID: <48B5BA5A.5030500@streambase.com> A customer of ours is reporting a hang problem. They took a thread dump during the hang and the thread dump reported a deadlock. The relavent portion of the thread dump is (there are approx 500 threads running in the application): ...... Found one Java-level deadlock: ============================= "Thread-135314": waiting to lock monitor 0x08ab51e0 (object 0x78c478e0, a java.util.ArrayList), which is held by "Thread-997" "Thread-997": waiting to lock monitor 0x08abc554 (object 0x78089d38, a com.streambase.sb.runtime.ParallelModule$ParallelLockee), which is held by "Thread-11620" "Thread-11620": waiting to lock monitor 0x08ab51e0 (object 0x78c478e0, a java.util.ArrayList), which is held by "Thread-997" Java stack information for the threads listed above: =================================================== "Thread-135314": at com.streambase.sb.runtime.sbd.OutputQueue.subscribe(OutputQueue.java:361) - waiting to lock <0x78c478e0> (a java.util.ArrayList) at com.streambase.sb.sbd.InnerDequeueHandle.subscribe(InnerDequeueHandle.java:310) at com.streambase.sb.sbd.XmlRpcHandlerManager$SUBSCRIBEHandler.process(XmlRpcHandlerManager.java:181) at com.streambase.sb.xmlrpc.XmlRpcManager.process(XmlRpcManager.java:208) at com.streambase.sb.sbd.XmlRpcHandlerManager.processXmlRpcRequest(XmlRpcHandlerManager.java:119) at com.streambase.sb.sbd.StreamBaseServer.processXmlRpcRequest(StreamBaseServer.java:174) at com.streambase.sb.sbd.StreamBaseServer.processXmlRpcRequestJni(StreamBaseServer.java:164) "Thread-997": at com.streambase.sb.sbd.StreamBaseNode.enqueue(StreamBaseNode.java:797) - waiting to lock <0x78089d38> (a com.streambase.sb.runtime.ParallelModule$ParallelLockee) "Thread-11620": at cm._default_.sbd_1219465761228_1.s___Monitor_Input_O_S_(Unknown Source) - waiting to lock <0x78c478e0> (a java.util.ArrayList) at cm._default_.sbd_1219465761228_1.op___Monitoring_Routing__0(Unknown Source) at cm._default_.sbd_1219465761228_1.op___Monitor_Input_Monitor_Filter__0(Unknown Source) at cm._default_.sbd_1219465761228_1.s___Monitor_Input_(Unknown Source) at cm._default_.sbd_1219465761228_1._enqueue_Tuples_1_Monitor_Input_(Unknown Source) at cm._default_.sbd_1219465761228_1.enqueueTuples(Unknown Source) at com.streambase.sb.runtime.MainModule.enqueueTuples(MainModule.java:232) at com.streambase.sb.sbd.StreamBaseNode.enqueue(StreamBaseNode.java:799) - locked <0x78089d38> (a com.streambase.sb.runtime.ParallelModule$ParallelLockee) Found 1 deadlock. -------------------- The key is that the thread dump thinks that Thread-997 holds monitor 0x08ab51e0 (object 0x78c478e0). If I believe the thread dump output then that thread doesn't hold that monitor/lock: -------------- "Thread-997": at com.streambase.sb.sbd.StreamBaseNode.enqueue(StreamBaseNode.java:797) - waiting to lock <0x78089d38> (a com.streambase.sb.runtime.ParallelModule$ParallelLockee) ------------------- There is no locked <0x78c478e0> in that thread. In fact there is no locked <0x78c478e0> in the entire stack dump. So no one is holding that lock I could believe that in the past Thread-997 held that lock. But it doesn't now....at least according to the thread dump. Looking through the code the thread stack traces seem quite reasonable. All of the locked and waiting on locks seem correct except for the threads waiting on Thread-997 for a lock. Note that "Thread-997" is coming in via JNI I can see a couple of possibilities: 1) Thread dump is lying and the dead lock is happening somewhere else 2) JVM has a bug in that Thread-997 hasn't released the lock for some reason. Any suggestions on how to debug the problem with the customer? It doesn't seem like that the thread dump output is giving me good information. Thanks, Keith -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080827/c924b4cd/attachment.html From David.Holmes at Sun.COM Wed Aug 27 19:10:00 2008 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Thu, 28 Aug 2008 12:10:00 +1000 Subject: jdk deadlock bug in JDK 1.6.0_05? In-Reply-To: <48B5BA5A.5030500@streambase.com> References: <48B5BA5A.5030500@streambase.com> Message-ID: <48B608F8.9070006@sun.com> Hello Keith, There was bug whereby a thread that was blocked trying to acquire the monitor used for class initialization inside a synchronized block/method, would report that it was blocked acquiring the monitor associated with that synchronized block/method. But that was fixed in 6u2 and this is 6u5. Also note that monitors used for class initialization do not show "- locked XXXX" entries in the dump. I don't suppose this is on Solaris is it? If so a pstack dump (or jstack -ml) wold be more informative than the Java-level stack dump. David Holmes ----------- Keith McNeill said the following on 08/28/08 06:34: > A customer of ours is reporting a hang problem. They took a thread dump > during the hang and the thread dump reported a deadlock. The relavent > portion of the thread dump is (there are approx 500 threads running in > the application): > > ...... > Found one Java-level deadlock: > ============================= > "Thread-135314": > waiting to lock monitor 0x08ab51e0 (object 0x78c478e0, a > java.util.ArrayList), > which is held by "Thread-997" > "Thread-997": > waiting to lock monitor 0x08abc554 (object 0x78089d38, a > com.streambase.sb.runtime.ParallelModule$ParallelLockee), > which is held by "Thread-11620" > "Thread-11620": > waiting to lock monitor 0x08ab51e0 (object 0x78c478e0, a > java.util.ArrayList), > which is held by "Thread-997" > > Java stack information for the threads listed above: > =================================================== > "Thread-135314": > > at > com.streambase.sb.runtime.sbd.OutputQueue.subscribe(OutputQueue.java:361) > > - waiting to lock <0x78c478e0> (a java.util.ArrayList) > at > com.streambase.sb.sbd.InnerDequeueHandle.subscribe(InnerDequeueHandle.java:310) > > at > com.streambase.sb.sbd.XmlRpcHandlerManager$SUBSCRIBEHandler.process(XmlRpcHandlerManager.java:181) > > at > com.streambase.sb.xmlrpc.XmlRpcManager.process(XmlRpcManager.java:208) > at > com.streambase.sb.sbd.XmlRpcHandlerManager.processXmlRpcRequest(XmlRpcHandlerManager.java:119) > > at > com.streambase.sb.sbd.StreamBaseServer.processXmlRpcRequest(StreamBaseServer.java:174) > > at > com.streambase.sb.sbd.StreamBaseServer.processXmlRpcRequestJni(StreamBaseServer.java:164) > > > "Thread-997": > > at > com.streambase.sb.sbd.StreamBaseNode.enqueue(StreamBaseNode.java:797) > - waiting to lock <0x78089d38> (a > com.streambase.sb.runtime.ParallelModule$ParallelLockee) > > "Thread-11620": > > at cm._default_.sbd_1219465761228_1.s___Monitor_Input_O_S_(Unknown > Source) > - waiting to lock <0x78c478e0> (a java.util.ArrayList) > at > cm._default_.sbd_1219465761228_1.op___Monitoring_Routing__0(Unknown > Source) > at > cm._default_.sbd_1219465761228_1.op___Monitor_Input_Monitor_Filter__0(Unknown > Source) > at cm._default_.sbd_1219465761228_1.s___Monitor_Input_(Unknown Source) > at > cm._default_.sbd_1219465761228_1._enqueue_Tuples_1_Monitor_Input_(Unknown > Source) > at cm._default_.sbd_1219465761228_1.enqueueTuples(Unknown Source) > at > com.streambase.sb.runtime.MainModule.enqueueTuples(MainModule.java:232) > at > com.streambase.sb.sbd.StreamBaseNode.enqueue(StreamBaseNode.java:799) > - locked <0x78089d38> (a > com.streambase.sb.runtime.ParallelModule$ParallelLockee) > > > Found 1 deadlock. > -------------------- > > The key is that the thread dump thinks that Thread-997 holds monitor > 0x08ab51e0 (object 0x78c478e0). > > If I believe the thread dump output then that thread doesn't hold that > monitor/lock: > -------------- > "Thread-997": > > at > com.streambase.sb.sbd.StreamBaseNode.enqueue(StreamBaseNode.java:797) > - waiting to lock <0x78089d38> (a > com.streambase.sb.runtime.ParallelModule$ParallelLockee) > > ------------------- > There is no locked <0x78c478e0> in that thread. In fact there is no > locked <0x78c478e0> in the entire stack dump. So no one is holding that > lock > > I could believe that in the past Thread-997 held that lock. But it > doesn't now....at least according to the thread dump. > > Looking through the code the thread stack traces seem quite reasonable. > All of the locked and waiting on locks seem correct except for the > threads waiting on Thread-997 for a lock. > > Note that "Thread-997" is coming in via JNI > > I can see a couple of possibilities: > > 1) Thread dump is lying and the dead lock is happening somewhere else > 2) JVM has a bug in that Thread-997 hasn't released the lock for some > reason. > > Any suggestions on how to debug the problem with the customer? It > doesn't seem like that the thread dump output is giving me good information. > > Thanks, > > Keith > From mcneill at streambase.com Wed Aug 27 19:38:50 2008 From: mcneill at streambase.com (Keith McNeill) Date: Wed, 27 Aug 2008 22:38:50 -0400 Subject: jdk deadlock bug in JDK 1.6.0_05? In-Reply-To: <48B608F8.9070006@sun.com> References: <48B5BA5A.5030500@streambase.com> <48B608F8.9070006@sun.com> Message-ID: <48B60FBA.9090107@streambase.com> Nope, not solaris, it is on linux. But will try jstack -ml next time it happens. Thanks, Keith David Holmes - Sun Microsystems wrote: > Hello Keith, > > There was bug whereby a thread that was blocked trying to acquire the > monitor used for class initialization inside a synchronized > block/method, would report that it was blocked acquiring the monitor > associated with that synchronized block/method. But that was fixed in > 6u2 and this is 6u5. Also note that monitors used for class > initialization do not show "- locked XXXX" entries in the dump. > > I don't suppose this is on Solaris is it? If so a pstack dump (or > jstack -ml) wold be more informative than the Java-level stack dump. > > David Holmes > ----------- > > Keith McNeill said the following on 08/28/08 06:34: >> A customer of ours is reporting a hang problem. They took a thread >> dump during the hang and the thread dump reported a deadlock. The >> relavent portion of the thread dump is (there are approx 500 threads >> running in the application): >> >> ...... >> Found one Java-level deadlock: >> ============================= >> "Thread-135314": >> waiting to lock monitor 0x08ab51e0 (object 0x78c478e0, a >> java.util.ArrayList), >> which is held by "Thread-997" >> "Thread-997": >> waiting to lock monitor 0x08abc554 (object 0x78089d38, a >> com.streambase.sb.runtime.ParallelModule$ParallelLockee), >> which is held by "Thread-11620" >> "Thread-11620": >> waiting to lock monitor 0x08ab51e0 (object 0x78c478e0, a >> java.util.ArrayList), >> which is held by "Thread-997" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-135314": >> >> at >> >> com.streambase.sb.runtime.sbd.OutputQueue.subscribe(OutputQueue.java:361) >> >> >> - waiting to lock <0x78c478e0> (a java.util.ArrayList) >> at >> >> com.streambase.sb.sbd.InnerDequeueHandle.subscribe(InnerDequeueHandle.java:310) >> >> >> at >> >> com.streambase.sb.sbd.XmlRpcHandlerManager$SUBSCRIBEHandler.process(XmlRpcHandlerManager.java:181) >> >> >> at >> >> com.streambase.sb.xmlrpc.XmlRpcManager.process(XmlRpcManager.java:208) >> at >> >> com.streambase.sb.sbd.XmlRpcHandlerManager.processXmlRpcRequest(XmlRpcHandlerManager.java:119) >> >> >> at >> >> com.streambase.sb.sbd.StreamBaseServer.processXmlRpcRequest(StreamBaseServer.java:174) >> >> >> at >> >> com.streambase.sb.sbd.StreamBaseServer.processXmlRpcRequestJni(StreamBaseServer.java:164) >> >> >> >> "Thread-997": >> >> at >> >> com.streambase.sb.sbd.StreamBaseNode.enqueue(StreamBaseNode.java:797) >> - waiting to lock <0x78089d38> (a >> com.streambase.sb.runtime.ParallelModule$ParallelLockee) >> >> "Thread-11620": >> >> at cm._default_.sbd_1219465761228_1.s___Monitor_Input_O_S_(Unknown >> Source) >> - waiting to lock <0x78c478e0> (a java.util.ArrayList) >> at >> cm._default_.sbd_1219465761228_1.op___Monitoring_Routing__0(Unknown >> Source) >> at >> >> cm._default_.sbd_1219465761228_1.op___Monitor_Input_Monitor_Filter__0(Unknown >> >> Source) >> at cm._default_.sbd_1219465761228_1.s___Monitor_Input_(Unknown >> Source) >> at >> >> cm._default_.sbd_1219465761228_1._enqueue_Tuples_1_Monitor_Input_(Unknown >> >> Source) >> at cm._default_.sbd_1219465761228_1.enqueueTuples(Unknown Source) >> at >> >> com.streambase.sb.runtime.MainModule.enqueueTuples(MainModule.java:232) >> at >> >> com.streambase.sb.sbd.StreamBaseNode.enqueue(StreamBaseNode.java:799) >> - locked <0x78089d38> (a >> com.streambase.sb.runtime.ParallelModule$ParallelLockee) >> >> >> Found 1 deadlock. >> -------------------- >> >> The key is that the thread dump thinks that Thread-997 holds monitor >> 0x08ab51e0 (object 0x78c478e0). >> >> If I believe the thread dump output then that thread doesn't hold >> that monitor/lock: >> -------------- >> "Thread-997": >> >> at >> >> com.streambase.sb.sbd.StreamBaseNode.enqueue(StreamBaseNode.java:797) >> - waiting to lock <0x78089d38> (a >> com.streambase.sb.runtime.ParallelModule$ParallelLockee) >> >> ------------------- >> There is no locked <0x78c478e0> in that thread. In fact there is no >> locked <0x78c478e0> in the entire stack dump. So no one is holding >> that lock >> >> I could believe that in the past Thread-997 held that lock. But it >> doesn't now....at least according to the thread dump. >> >> Looking through the code the thread stack traces seem quite >> reasonable. All of the locked and waiting on locks seem correct >> except for the threads waiting on Thread-997 for a lock. >> >> Note that "Thread-997" is coming in via JNI >> >> I can see a couple of possibilities: >> >> 1) Thread dump is lying and the dead lock is happening somewhere else >> 2) JVM has a bug in that Thread-997 hasn't released the lock for some >> reason. >> >> Any suggestions on how to debug the problem with the customer? It >> doesn't seem like that the thread dump output is giving me good >> information. >> >> Thanks, >> >> Keith >> From Thomas.Rodriguez at Sun.COM Thu Aug 28 15:26:30 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 28 Aug 2008 15:26:30 -0700 Subject: jdk deadlock bug in JDK 1.6.0_05? In-Reply-To: <48B5BA5A.5030500@streambase.com> References: <48B5BA5A.5030500@streambase.com> Message-ID: <708D6A52-2C0F-4C63-9234-7B6B98125180@sun.com> Note that every lock held by a thread isn't shown in a thread dump. It doesn't show locks which are acquired by native code using MonitorEnter. Is there any native code that might be acquiring locks? tom On Aug 27, 2008, at 1:34 PM, Keith McNeill wrote: > A customer of ours is reporting a hang problem. They took a thread > dump during the hang and the thread dump reported a deadlock. The > relavent portion of the thread dump is (there are approx 500 > threads running in the application): > > ...... > Found one Java-level deadlock: > ============================= > "Thread-135314": > waiting to lock monitor 0x08ab51e0 (object 0x78c478e0, a > java.util.ArrayList), > which is held by "Thread-997" > "Thread-997": > waiting to lock monitor 0x08abc554 (object 0x78089d38, a > com.streambase.sb.runtime.ParallelModule$ParallelLockee), > which is held by "Thread-11620" > "Thread-11620": > waiting to lock monitor 0x08ab51e0 (object 0x78c478e0, a > java.util.ArrayList), > which is held by "Thread-997" > > Java stack information for the threads listed above: > =================================================== > "Thread-135314": > at > com.streambase.sb.runtime.sbd.OutputQueue.subscribe(OutputQueue.java: > 361) > - waiting to lock <0x78c478e0> (a java.util.ArrayList) > at > com > .streambase > .sb.sbd.InnerDequeueHandle.subscribe(InnerDequeueHandle.java:310) > at com.streambase.sb.sbd.XmlRpcHandlerManager > $SUBSCRIBEHandler.process(XmlRpcHandlerManager.java:181) > at com.streambase.sb.xmlrpc.XmlRpcManager.process(XmlRpcManager.java: > 208) > at > com > .streambase > .sb > .sbd > .XmlRpcHandlerManager.processXmlRpcRequest(XmlRpcHandlerManager.java: > 119) > at > com > .streambase > .sb.sbd.StreamBaseServer.processXmlRpcRequest(StreamBaseServer.java: > 174) > at > com > .streambase > .sb > .sbd.StreamBaseServer.processXmlRpcRequestJni(StreamBaseServer.java: > 164) > "Thread-997": > at com.streambase.sb.sbd.StreamBaseNode.enqueue(StreamBaseNode.java: > 797) > - waiting to lock <0x78089d38> (a > com.streambase.sb.runtime.ParallelModule$ParallelLockee) > "Thread-11620": > at cm._default_.sbd_1219465761228_1.s___Monitor_Input_O_S_(Unknown > Source) > - waiting to lock <0x78c478e0> (a java.util.ArrayList) > at > cm._default_.sbd_1219465761228_1.op___Monitoring_Routing__0(Unknown > Source) > at > cm > ._default_ > .sbd_1219465761228_1.op___Monitor_Input_Monitor_Filter__0(Unknown > Source) > at cm._default_.sbd_1219465761228_1.s___Monitor_Input_(Unknown Source) > at > cm > ._default_ > .sbd_1219465761228_1._enqueue_Tuples_1_Monitor_Input_(Unknown Source) > at cm._default_.sbd_1219465761228_1.enqueueTuples(Unknown Source) > at > com.streambase.sb.runtime.MainModule.enqueueTuples(MainModule.java: > 232) > at com.streambase.sb.sbd.StreamBaseNode.enqueue(StreamBaseNode.java: > 799) > - locked <0x78089d38> (a com.streambase.sb.runtime.ParallelModule > $ParallelLockee) > > Found 1 deadlock. > -------------------- > > The key is that the thread dump thinks that Thread-997 holds monitor > 0x08ab51e0 (object 0x78c478e0). > > If I believe the thread dump output then that thread doesn't hold > that monitor/lock: > -------------- > "Thread-997": > at com.streambase.sb.sbd.StreamBaseNode.enqueue(StreamBaseNode.java: > 797) > - waiting to lock <0x78089d38> (a > com.streambase.sb.runtime.ParallelModule$ParallelLockee) > ------------------- > There is no locked <0x78c478e0> in that thread. In fact there is no > locked <0x78c478e0> in the entire stack dump. So no one is holding > that lock > > I could believe that in the past Thread-997 held that lock. But it > doesn't now....at least according to the thread dump. > > Looking through the code the thread stack traces seem quite > reasonable. All of the locked and waiting on locks seem correct > except for the threads waiting on Thread-997 for a lock. > > Note that "Thread-997" is coming in via JNI > > I can see a couple of possibilities: > > 1) Thread dump is lying and the dead lock is happening somewhere else > 2) JVM has a bug in that Thread-997 hasn't released the lock for > some reason. > > Any suggestions on how to debug the problem with the customer? It > doesn't seem like that the thread dump output is giving me good > information. > > Thanks, > > Keith > From mcneill at streambase.com Thu Aug 28 18:15:47 2008 From: mcneill at streambase.com (Keith McNeill) Date: Thu, 28 Aug 2008 21:15:47 -0400 Subject: jdk deadlock bug in JDK 1.6.0_05? In-Reply-To: <708D6A52-2C0F-4C63-9234-7B6B98125180@sun.com> References: <48B5BA5A.5030500@streambase.com> <708D6A52-2C0F-4C63-9234-7B6B98125180@sun.com> Message-ID: <48B74DC3.4030004@streambase.com> There is native code. But we don't acquire any locks in the native code. Keith Tom Rodriguez wrote: > Note that every lock held by a thread isn't shown in a thread dump. It > doesn't show locks which are acquired by native code using > MonitorEnter. Is there any native code that might be acquiring locks? > > tom > > On Aug 27, 2008, at 1:34 PM, Keith McNeill wrote: > >> A customer of ours is reporting a hang problem. They took a thread >> dump during the hang and the thread dump reported a deadlock. The >> relavent portion of the thread dump is (there are approx 500 threads >> running in the application): >> >> ...... >> Found one Java-level deadlock: >> ============================= >> "Thread-135314": >> waiting to lock monitor 0x08ab51e0 (object 0x78c478e0, a >> java.util.ArrayList), >> which is held by "Thread-997" >> "Thread-997": >> waiting to lock monitor 0x08abc554 (object 0x78089d38, a >> com.streambase.sb.runtime.ParallelModule$ParallelLockee), >> which is held by "Thread-11620" >> "Thread-11620": >> waiting to lock monitor 0x08ab51e0 (object 0x78c478e0, a >> java.util.ArrayList), >> which is held by "Thread-997" >> >> Java stack information for the threads listed above: >> =================================================== >> "Thread-135314": >> at >> com.streambase.sb.runtime.sbd.OutputQueue.subscribe(OutputQueue.java:361) >> >> - waiting to lock <0x78c478e0> (a java.util.ArrayList) >> at >> com.streambase.sb.sbd.InnerDequeueHandle.subscribe(InnerDequeueHandle.java:310) >> >> at >> com.streambase.sb.sbd.XmlRpcHandlerManager$SUBSCRIBEHandler.process(XmlRpcHandlerManager.java:181) >> >> at >> com.streambase.sb.xmlrpc.XmlRpcManager.process(XmlRpcManager.java:208) >> at >> com.streambase.sb.sbd.XmlRpcHandlerManager.processXmlRpcRequest(XmlRpcHandlerManager.java:119) >> >> at >> com.streambase.sb.sbd.StreamBaseServer.processXmlRpcRequest(StreamBaseServer.java:174) >> >> at >> com.streambase.sb.sbd.StreamBaseServer.processXmlRpcRequestJni(StreamBaseServer.java:164) >> >> "Thread-997": >> at com.streambase.sb.sbd.StreamBaseNode.enqueue(StreamBaseNode.java:797) >> - waiting to lock <0x78089d38> (a >> com.streambase.sb.runtime.ParallelModule$ParallelLockee) >> "Thread-11620": >> at cm._default_.sbd_1219465761228_1.s___Monitor_Input_O_S_(Unknown >> Source) >> - waiting to lock <0x78c478e0> (a java.util.ArrayList) >> at >> cm._default_.sbd_1219465761228_1.op___Monitoring_Routing__0(Unknown >> Source) >> at >> cm._default_.sbd_1219465761228_1.op___Monitor_Input_Monitor_Filter__0(Unknown >> Source) >> at cm._default_.sbd_1219465761228_1.s___Monitor_Input_(Unknown Source) >> at >> cm._default_.sbd_1219465761228_1._enqueue_Tuples_1_Monitor_Input_(Unknown >> Source) >> at cm._default_.sbd_1219465761228_1.enqueueTuples(Unknown Source) >> at >> com.streambase.sb.runtime.MainModule.enqueueTuples(MainModule.java:232) >> at com.streambase.sb.sbd.StreamBaseNode.enqueue(StreamBaseNode.java:799) >> - locked <0x78089d38> (a >> com.streambase.sb.runtime.ParallelModule$ParallelLockee) >> >> Found 1 deadlock. >> -------------------- >> >> The key is that the thread dump thinks that Thread-997 holds monitor >> 0x08ab51e0 (object 0x78c478e0). >> >> If I believe the thread dump output then that thread doesn't hold >> that monitor/lock: >> -------------- >> "Thread-997": >> at com.streambase.sb.sbd.StreamBaseNode.enqueue(StreamBaseNode.java:797) >> - waiting to lock <0x78089d38> (a >> com.streambase.sb.runtime.ParallelModule$ParallelLockee) >> ------------------- >> There is no locked <0x78c478e0> in that thread. In fact there is no >> locked <0x78c478e0> in the entire stack dump. So no one is holding >> that lock >> >> I could believe that in the past Thread-997 held that lock. But it >> doesn't now....at least according to the thread dump. >> >> Looking through the code the thread stack traces seem quite >> reasonable. All of the locked and waiting on locks seem correct >> except for the threads waiting on Thread-997 for a lock. >> >> Note that "Thread-997" is coming in via JNI >> >> I can see a couple of possibilities: >> >> 1) Thread dump is lying and the dead lock is happening somewhere else >> 2) JVM has a bug in that Thread-997 hasn't released the lock for some >> reason. >> >> Any suggestions on how to debug the problem with the customer? It >> doesn't seem like that the thread dump output is giving me good >> information. >> >> Thanks, >> >> Keith >> >