From Thomas.Rodriguez at Sun.COM Tue Jun 2 13:18:15 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 02 Jun 2009 13:18:15 -0700 Subject: review (S) for 6847305: solaris reorder mapfiles generate too many warnings Message-ID: <355247E7-5D80-44F9-88B3-D7D21ABCFDAA@Sun.COM> http://cr.openjdk.java.net/~never/6847305 From Vladimir.Kozlov at Sun.COM Tue Jun 2 13:45:20 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 02 Jun 2009 13:45:20 -0700 Subject: review (S) for 6847305: solaris reorder mapfiles generate too many warnings In-Reply-To: <355247E7-5D80-44F9-88B3-D7D21ABCFDAA@Sun.COM> References: <355247E7-5D80-44F9-88B3-D7D21ABCFDAA@Sun.COM> Message-ID: <4A258F60.3040409@sun.com> So you are finally tired of these warnings :) Did you use a script? Could you keep it around to use after an other few years? ;) Looks good. Thanks for cleaning it Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6847305 From Thomas.Rodriguez at Sun.COM Tue Jun 2 14:41:50 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 02 Jun 2009 14:41:50 -0700 Subject: review (S) for 6847305: solaris reorder mapfiles generate too many warnings In-Reply-To: <4A258F60.3040409@sun.com> References: <355247E7-5D80-44F9-88B3-D7D21ABCFDAA@Sun.COM> <4A258F60.3040409@sun.com> Message-ID: <8390AD61-8182-48A3-8032-6D8C003913D4@Sun.COM> I started to do it once before by hand but gave up. This time I did use a script. I was going to drop it into the bug report. Unsurprisingly it's kind of hacky. Originally I'd written a validator that checked the mapfile against the object files to see if the lines were valid but that left a bunch of warnings. Sometimes the compiler generates multiple copies of the same function in different files but only ends up using one of them. If there are mapfile entries for each of them then it complains about all the others after the first. So basically I resorted to parsing the warnings and mapping them to lines in the reorder file and deleting those lines. Gack. tom On Jun 2, 2009, at 1:45 PM, Vladimir Kozlov wrote: > So you are finally tired of these warnings :) > Did you use a script? Could you keep it around to use after an other > few years? ;) > > Looks good. Thanks for cleaning it > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6847305 From dmytro_sheyko at hotmail.com Wed Jun 3 07:20:27 2009 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Wed, 3 Jun 2009 21:20:27 +0700 Subject: Cant detect deadlock when thread reenters synchronization block in Object.wait() Message-ID: Hi, Could you have a look at following patch regarding deadlock detection: Cant detect deadlock when thread reenters synchronization block in Object.wait() https://bugs.openjdk.java.net/show_bug.cgi?id=100058 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6841139 Thank you, Dmytro Sheyko _________________________________________________________________ Show them the way! Add maps and directions to your party invites. http://www.microsoft.com/windows/windowslive/products/events.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090603/475ef9fd/attachment.html From dmytro_sheyko at hotmail.com Wed Jun 3 07:21:22 2009 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Wed, 3 Jun 2009 21:21:22 +0700 Subject: Deadlock detection mechanism incorrectly assumes that thread cannot block itself Message-ID: Hi, One more regarding deadlock detection: Deadlock detection mechanism incorrectly assumes that thread cannot block itself https://bugs.openjdk.java.net/show_bug.cgi?id=100059 -- Dmytro Sheyko _________________________________________________________________ More than messages?check out the rest of the Windows Live?. http://www.microsoft.com/windows/windowslive/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090603/82a47ff1/attachment.html From David.Holmes at Sun.COM Wed Jun 3 08:04:23 2009 From: David.Holmes at Sun.COM (David Holmes) Date: Thu, 04 Jun 2009 01:04:23 +1000 Subject: Cant detect deadlock when thread reenters synchronization block in Object.wait() In-Reply-To: References: Message-ID: <4A2690F7.5020507@sun.com> Hi Dmytro, Can you split this into two separate bug reports please. The changes to the VM are quite separate from the changes to the java.util.concurrent classes. The j.u.c changes should then be discussed on the concurrent-interest mailing list: http://cs.oswego.edu/mailman/listinfo/concurrency-interest This will let all the JSR-166 EG members, and the genercal c-i community evaluate what you have done. At this stage I have not evaluated the actual proposals. Thanks, David Holmes (j.u.c bug evaluator) Dmytro Sheyko wrote: > Hi, > > Could you have a look at following patch regarding deadlock detection: > > Cant detect deadlock when thread reenters synchronization block in > Object.wait() > https://bugs.openjdk.java.net/show_bug.cgi?id=100058 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6841139 > > Thank you, > Dmytro Sheyko > > ------------------------------------------------------------------------ > See all the ways you can stay connected to friends and family > From dawn2004 at gmail.com Sun Jun 7 21:20:45 2009 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Sun, 7 Jun 2009 21:20:45 -0700 (PDT) Subject: Who and when do put receiver onto the stack in bytecode interpreter? Message-ID: <23918031.post@talk.nabble.com> Hi, I have a question about the c++ interpreter. For an "invokevirtual" method, the operand stack is like: ..., objectref, [arg1, [arg2 ...]] I know the arguments are put onto the stack by some "load" instructions explicitly. But, how is the objectref (receiver object) put onto the stack? Who did that and when? Thanks a lot! Colin -- View this message in context: http://www.nabble.com/Who-and-when-do-put-receiver-onto-the-stack-in-bytecode-interpreter--tp23918031p23918031.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From gnu_andrew at member.fsf.org Mon Jun 8 10:04:15 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 8 Jun 2009 18:04:15 +0100 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 Message-ID: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> The following webrev: http://fuseyism.com/6781583/webrev.00/ is backported from OpenJDK7. It allows hs14 to be built using GCC 4.3 and above. Otherwise, the build fails. IcedTea has been applying an equivalent fix as three separately developed patches, two of which have been there pretty much since its inception in the summer of 2007. Ok to commit? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Mon Jun 8 10:05:14 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 8 Jun 2009 18:05:14 +0100 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> Message-ID: <17c6771e0906081005w14655c3w58d6cecee6eed013@mail.gmail.com> 2009/6/8 Andrew John Hughes : > The following webrev: > > http://fuseyism.com/6781583/webrev.00/ > > is backported from OpenJDK7. ?It allows hs14 to be built using GCC 4.3 > and above. ?Otherwise, the build fails. ?IcedTea has been applying an > equivalent fix as three separately developed patches, two of which > have been there pretty much since its inception in the summer of 2007. > > Ok to commit? > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > It's in the webrev, but to be explicit: this is for the new hs14 tree. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Kelly.Ohair at Sun.COM Mon Jun 8 12:49:33 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 08 Jun 2009 12:49:33 -0700 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> Message-ID: <4A2D6B4D.4020104@sun.com> Someone from the hotspot team really needs to review this, but my observations on these changes: * Changing the typedef for jlong seemed really risky to me, but I investigated it more and I'm pretty sure this is the right change, and forces it to match the public definition from jni.h/jni_md.h. So it looks right. * The realpath() changes in src/os/linux/vm/os_linux.cpp seem to change the definition of this method when an error occurs, the control flow has changed, and I'm not exactly sure what the return value is when realpath() fails. I doubt realpath() fails very often here, but won't the buf[] array get some arbitrary directory when realpath() fails? Is that ok? That jvm_path() is a bizarre little method. :^{ * Changing the _lineno field in src/share/vm/utilities/vmError.hpp from an int to a size_t might seem right type wise, but sure seems like a waste of space. Does a lineno really need to use up 64bits of space? * The *PTR* changes look right. * The addition of an unused local variable like in src/share/vm/utilities/ostream.cpp to avoid a warning message just seems wrong to me, and will likely create a new warning message about an unused local variable. Seems like I've had this discussion before. I prefer an explicit (void) cast on a function call whose return value is not needed and I am frustrated with GCC's inability to understand what that (void) cast means. I really like the idea of using -Werror and not allowing warnings, but at times like this I have to wonder if we should just remove the -Werror unless we know that specific version of GCC is < 4.3. But like I said, a 'real' hotspot developer should probably review this. ;^) -kto Andrew John Hughes wrote: > The following webrev: > > http://fuseyism.com/6781583/webrev.00/ > > is backported from OpenJDK7. It allows hs14 to be built using GCC 4.3 > and above. Otherwise, the build fails. IcedTea has been applying an > equivalent fix as three separately developed patches, two of which > have been there pretty much since its inception in the summer of 2007. > > Ok to commit? From danhicks at ieee.org Mon Jun 8 14:09:14 2009 From: danhicks at ieee.org (Dan Hicks) Date: Mon, 08 Jun 2009 16:09:14 -0500 Subject: hotspot-dev Digest, Vol 26, Issue 2 In-Reply-To: References: Message-ID: <4A2D7DFA.2030606@ieee.org> Message: 1 > Date: Sun, 7 Jun 2009 21:20:45 -0700 (PDT) > From: "Colin(Du Li)" > Subject: Who and when do put receiver onto the stack in bytecode > interpreter? > To: hotspot-dev at openjdk.java.net > Message-ID: <23918031.post at talk.nabble.com> > Content-Type: text/plain; charset=us-ascii > > > > Hi, I have a question about the c++ interpreter. > For an "invokevirtual" method, the operand stack is like: > ..., objectref, [arg1, [arg2 ...]] > > I know the arguments are put onto the stack by some "load" instructions > explicitly. But, how is the objectref (receiver object) put onto the stack? > Who did that and when? > > Thanks a lot! > > Colin > The objectref can be loaded any number of ways -- any way an object reference can get onto the stack. For instance, it could be loaded with a getstatic operation, it could be an argument passed on the call to the current method, or it could be an exception object that was implicitly placed in the stack by the exception handling mechanism. The Java interpreter, from this point of view, is no different from any other "stack machine", such as the Burroughs B5000 series, the UCSD Pascal p-machine, and Adobe PostScript. http://en.wikipedia.org/wiki/Stack_machine -- Dan Hicks I don't trust a man who uses the word evil eighteen times in ten minutes. If you're half evil, nothing soothes you more than to think the person you are opposed to is totally evil. --Norman Mailer From gnu_andrew at member.fsf.org Mon Jun 8 14:40:24 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 8 Jun 2009 22:40:24 +0100 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <4A2D6B4D.4020104@sun.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> <4A2D6B4D.4020104@sun.com> Message-ID: <17c6771e0906081440k72a2cdb6tad75653d1e7cbcce@mail.gmail.com> 2009/6/8 Kelly O'Hair : > Someone from the hotspot team really needs to review this Errr.... 4 of them already did: http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/2328d1d3f8cf I'm not the author of this patch, I just backported it from OpenJDK7 where it's been applied for over six months. I don't remember this patch being reviewed openly and I disliked having all the fixes rolled into one megafix like this. But given this had been reviewed and was in 7, it seemed better to backport this (just a matter of hg export/import) rather than trying to get each individual IcedTea patch through, especially as one of ours just turns off -Werror... (to some degree anyway) The relevant IcedTea patches are icedtea-fortify-source.patch (author: Matthias Klose), hotspot/default/icedtea-format.patch (author: me), icedtea-no-bcopy.patch (author: Matthias Klose), hotspot/default/icedtea-gcc-4.3.patch (originally part of a patch by Bernhard Rosenkraenzer according to the ChangeLog). , but my > observations on these changes: > > ?* Changing the typedef for jlong seemed really risky to me, but I > ? ?investigated it more and I'm pretty sure this is the right change, > ? ?and forces it to match the public definition from jni.h/jni_md.h. > ? ?So it looks right. > It's kind of annoying it has to be defined repeatedly for each arch. We also had to add this to Zero in IcedTea. > ?* The realpath() changes in src/os/linux/vm/os_linux.cpp seem to change > ? ?the definition of this method when an error occurs, the control > ? ?flow has changed, and I'm not exactly sure what the return value is > ? ?when realpath() fails. I doubt realpath() fails very often here, > ? ?but won't the buf[] array get some arbitrary directory when realpath() > ? ?fails? Is that ok? That jvm_path() is a bizarre little method. :^{ > In IcedTea, an unused variable is used which isn't ideal either, but at least doesn't change the semantics. > ?* Changing the _lineno field in src/share/vm/utilities/vmError.hpp > ? ?from an int to a size_t might seem right type wise, but sure seems > ? ?like a waste of space. Does a lineno really need to use up 64bits of > space? This doesn't seem to be patched in IcedTea, so I don't know the reasoning for the change. Increasing the size to 64 bits on x86_64 does seem wrong though. > > ?* The *PTR* changes look right. > Yeah, our patches are virtually identical on this :) > ?* The addition of an unused local variable like in > ? ? ?src/share/vm/utilities/ostream.cpp > ? ?to avoid a warning message just seems wrong to me, and will likely > ? ?create a new warning message about an unused local variable. > ? ?Seems like I've had this discussion before. > ? ?I prefer an explicit (void) cast on a function call whose return > ? ?value is not needed and I am frustrated with GCC's inability to > ? ?understand what that (void) cast means. > ? ?I really like the idea of using -Werror and not allowing warnings, > ? ?but at times like this I have to wonder if we should just remove > ? ?the -Werror unless we know that specific version of GCC is < 4.3. > IcedTea does the same for this and the one above, but uses __attribute__(unused) to avoid the warning. > But like I said, a 'real' hotspot developer should probably review this. ;^) > > -kto > > > Andrew John Hughes wrote: >> >> The following webrev: >> >> http://fuseyism.com/6781583/webrev.00/ >> >> is backported from OpenJDK7. ?It allows hs14 to be built using GCC 4.3 >> and above. ?Otherwise, the build fails. ?IcedTea has been applying an >> equivalent fix as three separately developed patches, two of which >> have been there pretty much since its inception in the summer of 2007. >> >> Ok to commit? > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Kelly.Ohair at Sun.COM Mon Jun 8 15:44:07 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 08 Jun 2009 15:44:07 -0700 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <17c6771e0906081440k72a2cdb6tad75653d1e7cbcce@mail.gmail.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> <4A2D6B4D.4020104@sun.com> <17c6771e0906081440k72a2cdb6tad75653d1e7cbcce@mail.gmail.com> Message-ID: <4A2D9437.7080901@sun.com> Andrew John Hughes wrote: > 2009/6/8 Kelly O'Hair : >> Someone from the hotspot team really needs to review this > > > Errr.... 4 of them already did: > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/2328d1d3f8cf Humm... ok, ... ... sorry... if this is in jdk7 already, then so be it. > > I'm not the author of this patch, I just backported it from OpenJDK7 > where it's been applied for over six months. I don't remember this > patch being reviewed openly and I disliked having all the fixes rolled > into one megafix like this. Yeah, I probably would have separated them, oh well. > But given this had been reviewed and was in 7, it seemed better to > backport this (just a matter of hg export/import) rather than trying > to get each individual IcedTea patch through, especially as one of > ours just turns off -Werror... (to some degree anyway) > Agreed. Matching jdk7 is the best route to take. > The relevant IcedTea patches are icedtea-fortify-source.patch (author: > Matthias Klose), hotspot/default/icedtea-format.patch (author: me), > icedtea-no-bcopy.patch (author: Matthias Klose), > hotspot/default/icedtea-gcc-4.3.patch (originally part of a patch by > Bernhard Rosenkraenzer according to the ChangeLog). > > , but my >> observations on these changes: >> >> * Changing the typedef for jlong seemed really risky to me, but I >> investigated it more and I'm pretty sure this is the right change, >> and forces it to match the public definition from jni.h/jni_md.h. >> So it looks right. >> > > It's kind of annoying it has to be defined repeatedly for each arch. Yeah... I think the idea of the xxx_md.h files was to avoid ifdef's, then we turn around and fill them with ifdef's :^{ Note that there has been a long standing issue that the jni*.h files in hotspot may not match the jni*.h files in the resulting jdk install image, they come from the copies checked into the jdk repository (see the directories jdk/src/{share,solaris,windows}/javavm/export). So one of these days, the public jni interface will be defined by hotspot 'and' it will deliver the jni include files too. ;^) > We also had to add this to Zero in IcedTea. > >> * The realpath() changes in src/os/linux/vm/os_linux.cpp seem to change >> the definition of this method when an error occurs, the control >> flow has changed, and I'm not exactly sure what the return value is >> when realpath() fails. I doubt realpath() fails very often here, >> but won't the buf[] array get some arbitrary directory when realpath() >> fails? Is that ok? That jvm_path() is a bizarre little method. :^{ >> > > In IcedTea, an unused variable is used which isn't ideal either, but > at least doesn't change the semantics. If the hotspot guys made this change in jdk7, I guess that's what they want. The 'gamma' and '_g' stuff isn't executed in most cases anyway. > >> * Changing the _lineno field in src/share/vm/utilities/vmError.hpp >> from an int to a size_t might seem right type wise, but sure seems >> like a waste of space. Does a lineno really need to use up 64bits of >> space? > > This doesn't seem to be patched in IcedTea, so I don't know the > reasoning for the change. Increasing the size to 64 bits on x86_64 > does seem wrong though. Yeah, seemed like it to me. Oh well. > >> * The *PTR* changes look right. >> > > Yeah, our patches are virtually identical on this :) > >> * The addition of an unused local variable like in >> src/share/vm/utilities/ostream.cpp >> to avoid a warning message just seems wrong to me, and will likely >> create a new warning message about an unused local variable. >> Seems like I've had this discussion before. >> I prefer an explicit (void) cast on a function call whose return >> value is not needed and I am frustrated with GCC's inability to >> understand what that (void) cast means. >> I really like the idea of using -Werror and not allowing warnings, >> but at times like this I have to wonder if we should just remove >> the -Werror unless we know that specific version of GCC is < 4.3. >> > > IcedTea does the same for this and the one above, but uses > __attribute__(unused) to avoid the warning. ok. I'm just never a fan of planting compiler implementation specifics into the source. -kto > >> But like I said, a 'real' hotspot developer should probably review this. ;^) >> >> -kto >> >> >> Andrew John Hughes wrote: >>> The following webrev: >>> >>> http://fuseyism.com/6781583/webrev.00/ >>> >>> is backported from OpenJDK7. It allows hs14 to be built using GCC 4.3 >>> and above. Otherwise, the build fails. IcedTea has been applying an >>> equivalent fix as three separately developed patches, two of which >>> have been there pretty much since its inception in the summer of 2007. >>> >>> Ok to commit? > > > From Paul.Hohensee at Sun.COM Mon Jun 8 16:06:19 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Mon, 08 Jun 2009 19:06:19 -0400 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <17c6771e0906081005w14655c3w58d6cecee6eed013@mail.gmail.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> <17c6771e0906081005w14655c3w58d6cecee6eed013@mail.gmail.com> Message-ID: <4A2D996B.6070206@sun.com> There seems to be some confusion here. hs14 is the version of hotspot that shipped with 6u14 and as such, is frozen. We do not intend to apply or allow any further bug fixes to it, including the one you propose here. It was never intended to be the basis for another openjdk version of hotspot. Ongoing hotspot development goes forward only in the openjdk hotspot repo, which is currently labeled hs16. Of course, anyone may feel free to clone hs14 if they like, and apply what fixes they will to said clone. One of those clones could easily be jdk6 open, but that's not our (the hotspot group's) decision to make. The next jdk6 update release will include a new version of hotspot, based either on hs14 (in which case it'll be an SSR, we'll likely call it hs14.1, and this fix will be off limits) or the current openjdk hotspot repo (in which case it will be a limited update, it'll likely be hs16, and the fix is already in it). The going-forward release is hs16. hs14 is a dead end. Paul Andrew John Hughes wrote: > 2009/6/8 Andrew John Hughes : > >> The following webrev: >> >> http://fuseyism.com/6781583/webrev.00/ >> >> is backported from OpenJDK7. It allows hs14 to be built using GCC 4.3 >> and above. Otherwise, the build fails. IcedTea has been applying an >> equivalent fix as three separately developed patches, two of which >> have been there pretty much since its inception in the summer of 2007. >> >> Ok to commit? >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >> >> > > It's in the webrev, but to be explicit: this is for the new hs14 tree. > From David.Holmes at Sun.COM Mon Jun 8 17:56:34 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Tue, 09 Jun 2009 10:56:34 +1000 Subject: hotspot-dev Digest, Vol 26, Issue 2 In-Reply-To: <4A2D7DFA.2030606@ieee.org> References: <4A2D7DFA.2030606@ieee.org> Message-ID: <4A2DB342.107@sun.com> Folks, When replying to a post you see in a Digest, please set the subject line explicitly to refer to the subject of _that_ post. A subject like: Re: hotspot-dev Digest, Vol 26, Issue 2 is meaningless. Thanks, David Holmes From gnu_andrew at member.fsf.org Tue Jun 9 02:33:12 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 9 Jun 2009 10:33:12 +0100 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <4A2D996B.6070206@sun.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> <17c6771e0906081005w14655c3w58d6cecee6eed013@mail.gmail.com> <4A2D996B.6070206@sun.com> Message-ID: <17c6771e0906090233hd16cecah7dea33a817ff23cc@mail.gmail.com> 2009/6/9 Paul Hohensee : > There seems to be some confusion here. > Clearly, because what I believe we asked for was a stability branch and that was the point of going through this whole process for over three months. Why setup a forest unless it will be updated? > hs14 is the version of hotspot that shipped with 6u14 and as such, is > frozen. > We do not intend to apply or allow any further bug fixes to it, including > the > one you propose here. I'm not asking you to apply it. I'm suggesting that I do. It was never intended to be the basis for another > openjdk > version of hotspot. The entire __point__ of making hs14 available was to use it in OpenJDK6, at least from the point of view of IcedTea developers. ?Ongoing hotspot development goes forward only in the > openjdk hotspot repo, which is currently labeled hs16. ?Of course, anyone > may > feel free to clone hs14 if they like, and apply what fixes they will to said > clone. So you want us to create a fork? How does that help us all work together? > One of those clones could easily be jdk6 open, but that's not our (the > hotspot > group's) decision to make. > > The next jdk6 update release will include a new version of hotspot, based > either on hs14 (in which case it'll be an SSR, we'll likely call it hs14.1, > and this > fix will be off limits) Why? or the current openjdk hotspot repo (in which case > it > will be a limited update, it'll likely be hs16, and the fix is already in > it). ?The > going-forward release is hs16. ?hs14 is a dead end. > > Paul > > Andrew John Hughes wrote: >> >> 2009/6/8 Andrew John Hughes : >> >>> >>> The following webrev: >>> >>> http://fuseyism.com/6781583/webrev.00/ >>> >>> is backported from OpenJDK7. ?It allows hs14 to be built using GCC 4.3 >>> and above. ?Otherwise, the build fails. ?IcedTea has been applying an >>> equivalent fix as three separately developed patches, two of which >>> have been there pretty much since its inception in the summer of 2007. >>> >>> Ok to commit? >>> -- >>> Andrew :-) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> Support Free Java! >>> Contribute to GNU Classpath and the OpenJDK >>> http://www.gnu.org/software/classpath >>> http://openjdk.java.net >>> >>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>> >>> >> >> It's in the webrev, but to be explicit: this is for the new hs14 tree. >> > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Tue Jun 9 02:34:56 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 9 Jun 2009 10:34:56 +0100 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <4A2D9437.7080901@sun.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> <4A2D6B4D.4020104@sun.com> <17c6771e0906081440k72a2cdb6tad75653d1e7cbcce@mail.gmail.com> <4A2D9437.7080901@sun.com> Message-ID: <17c6771e0906090234u514372d5j86b8e5fb3dcb9094@mail.gmail.com> 2009/6/8 Kelly O'Hair : > > > Andrew John Hughes wrote: >> >> 2009/6/8 Kelly O'Hair : >>> >>> Someone from the hotspot team really needs to review this >> >> >> Errr.... 4 of them already did: >> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/2328d1d3f8cf > > Humm... ?ok, ... ... sorry... > if this is in jdk7 already, then so be it. > No apology required. It just shows this patch should have had an open review before being committed. >> >> I'm not the author of this patch, I just backported it from OpenJDK7 >> where it's been applied for over six months. ?I don't remember this >> patch being reviewed openly and I disliked having all the fixes rolled >> into one megafix like this. > > Yeah, I probably would have separated them, oh well. > >> But given this had been reviewed and was in 7, it seemed better to >> backport this (just a matter of hg export/import) rather than trying >> to get each individual IcedTea patch through, especially as one of >> ours just turns off -Werror... (to some degree anyway) >> > > Agreed. Matching jdk7 is the best route to take. > >> The relevant IcedTea patches are icedtea-fortify-source.patch (author: >> Matthias Klose), hotspot/default/icedtea-format.patch (author: me), >> icedtea-no-bcopy.patch (author: Matthias Klose), >> hotspot/default/icedtea-gcc-4.3.patch (originally part of a patch by >> Bernhard Rosenkraenzer according to the ChangeLog). >> >> , but my >>> >>> observations on these changes: >>> >>> ?* Changing the typedef for jlong seemed really risky to me, but I >>> ? investigated it more and I'm pretty sure this is the right change, >>> ? and forces it to match the public definition from jni.h/jni_md.h. >>> ? So it looks right. >>> >> >> It's kind of annoying it has to be defined repeatedly for each arch. > > Yeah... ?I think the idea of the xxx_md.h files was to avoid ifdef's, > then we turn around and fill them with ifdef's :^{ > > Note that there has been a long standing issue that the jni*.h files > in hotspot may not match the jni*.h files in the resulting jdk install > image, they come from the copies checked into the jdk repository > (see the directories jdk/src/{share,solaris,windows}/javavm/export). > So one of these days, the public jni interface will be defined by > hotspot 'and' it will deliver the jni include files too. ;^) > >> We also had to add this to Zero in IcedTea. >> >>> ?* The realpath() changes in src/os/linux/vm/os_linux.cpp seem to change >>> ? the definition of this method when an error occurs, the control >>> ? flow has changed, and I'm not exactly sure what the return value is >>> ? when realpath() fails. I doubt realpath() fails very often here, >>> ? but won't the buf[] array get some arbitrary directory when realpath() >>> ? fails? Is that ok? That jvm_path() is a bizarre little method. :^{ >>> >> >> In IcedTea, an unused variable is used which isn't ideal either, but >> at least doesn't change the semantics. > > If the hotspot guys made this change in jdk7, I guess that's what they > want. The 'gamma' and '_g' stuff isn't executed in most cases anyway. > >> >>> ?* Changing the _lineno field in src/share/vm/utilities/vmError.hpp >>> ? from an int to a size_t might seem right type wise, but sure seems >>> ? like a waste of space. Does a lineno really need to use up 64bits of >>> space? >> >> This doesn't seem to be patched in IcedTea, so I don't know the >> reasoning for the change. ?Increasing the size to 64 bits on x86_64 >> does seem wrong though. > > Yeah, seemed like it to me. Oh well. > >> >>> ?* The *PTR* changes look right. >>> >> >> Yeah, our patches are virtually identical on this :) >> >>> ?* The addition of an unused local variable like in >>> ? ? src/share/vm/utilities/ostream.cpp >>> ? to avoid a warning message just seems wrong to me, and will likely >>> ? create a new warning message about an unused local variable. >>> ? Seems like I've had this discussion before. >>> ? I prefer an explicit (void) cast on a function call whose return >>> ? value is not needed and I am frustrated with GCC's inability to >>> ? understand what that (void) cast means. >>> ? I really like the idea of using -Werror and not allowing warnings, >>> ? but at times like this I have to wonder if we should just remove >>> ? the -Werror unless we know that specific version of GCC is < 4.3. >>> >> >> IcedTea does the same for this and the one above, but uses >> __attribute__(unused) to avoid the warning. > > ok. > > I'm just never a fan of planting compiler implementation specifics into the > source. > Yeah, I'm not trying to defend it by any means :) > -kto > >> >>> But like I said, a 'real' hotspot developer should probably review this. >>> ;^) >>> >>> -kto >>> >>> >>> Andrew John Hughes wrote: >>>> >>>> The following webrev: >>>> >>>> http://fuseyism.com/6781583/webrev.00/ >>>> >>>> is backported from OpenJDK7. ?It allows hs14 to be built using GCC 4.3 >>>> and above. ?Otherwise, the build fails. ?IcedTea has been applying an >>>> equivalent fix as three separately developed patches, two of which >>>> have been there pretty much since its inception in the summer of 2007. >>>> >>>> Ok to commit? >> >> >> > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Paul.Hohensee at Sun.COM Tue Jun 9 04:00:56 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Tue, 09 Jun 2009 07:00:56 -0400 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <17c6771e0906090233hd16cecah7dea33a817ff23cc@mail.gmail.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> <17c6771e0906081005w14655c3w58d6cecee6eed013@mail.gmail.com> <4A2D996B.6070206@sun.com> <17c6771e0906090233hd16cecah7dea33a817ff23cc@mail.gmail.com> Message-ID: <4A2E40E8.3050606@sun.com> Yes, we want you to create a fork. We can work together on the fork. The hs14 repo isn't a clone of Sun's 6u14 hotspot repo, it _is_ our 6u14 hotspot repo. As such, we need it to stay as is so we can use it as the basis for customer one-offs containing single fixes, etc. Think of hs14 as a distro repo that happens to be public. Would it make sense for a company like Redhat to have allowed community changes to, say, it's ES 5.1 repo after it shipped? What we believed was asked for was a stable repo that could be used as the _basis_ for things like 6-open. As I said, feel free to clone hs14 for that purpose and then update the clone. Doing so seems to us to fulfill IcedTea developer requirements. SSRs are Synchronized Security Releases put out by Sun to fix particular security holes across all Sun-supported jdk releases at the same time. They contain only security fixes, so non-security fixes like this one are off-limits. What we call Limited Update Releases can contain other-than-security fixes. We alternate jdk6 update releases between SSRs and LURs. Paul Andrew John Hughes wrote: > 2009/6/9 Paul Hohensee : > >> There seems to be some confusion here. >> >> > > Clearly, because what I believe we asked for was a stability branch > and that was the point of going through this whole process for over > three months. Why setup a forest unless it will be updated? > > >> hs14 is the version of hotspot that shipped with 6u14 and as such, is >> frozen. >> We do not intend to apply or allow any further bug fixes to it, including >> the >> one you propose here. >> > > I'm not asking you to apply it. I'm suggesting that I do. > > It was never intended to be the basis for another > >> openjdk >> version of hotspot. >> > > The entire __point__ of making hs14 available was to use it in > OpenJDK6, at least from the point of view of IcedTea developers. > > Ongoing hotspot development goes forward only in the > >> openjdk hotspot repo, which is currently labeled hs16. Of course, anyone >> may >> feel free to clone hs14 if they like, and apply what fixes they will to said >> clone. >> > > So you want us to create a fork? How does that help us all work together? > > >> One of those clones could easily be jdk6 open, but that's not our (the >> hotspot >> group's) decision to make. >> >> The next jdk6 update release will include a new version of hotspot, based >> either on hs14 (in which case it'll be an SSR, we'll likely call it hs14.1, >> and this >> fix will be off limits) >> > > Why? > > or the current openjdk hotspot repo (in which case > >> it >> will be a limited update, it'll likely be hs16, and the fix is already in >> it). The >> going-forward release is hs16. hs14 is a dead end. >> >> Paul >> >> Andrew John Hughes wrote: >> >>> 2009/6/8 Andrew John Hughes : >>> >>> >>>> The following webrev: >>>> >>>> http://fuseyism.com/6781583/webrev.00/ >>>> >>>> is backported from OpenJDK7. It allows hs14 to be built using GCC 4.3 >>>> and above. Otherwise, the build fails. IcedTea has been applying an >>>> equivalent fix as three separately developed patches, two of which >>>> have been there pretty much since its inception in the summer of 2007. >>>> >>>> Ok to commit? >>>> -- >>>> Andrew :-) >>>> >>>> Free Java Software Engineer >>>> Red Hat, Inc. (http://www.redhat.com) >>>> >>>> Support Free Java! >>>> Contribute to GNU Classpath and the OpenJDK >>>> http://www.gnu.org/software/classpath >>>> http://openjdk.java.net >>>> >>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>> >>>> >>>> >>> It's in the webrev, but to be explicit: this is for the new hs14 tree. >>> >>> > > > > From thomas.rodriguez at sun.com Tue Jun 9 16:28:07 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Tue, 09 Jun 2009 23:28:07 +0000 Subject: hg: jdk7/hotspot/hotspot: 22 new changesets Message-ID: <20090609232848.126D6E1F5@hg.openjdk.java.net> Changeset: 93c14e5562c4 Author: twisti Date: 2009-05-06 00:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/93c14e5562c4 6823354: Add intrinsics for {Integer,Long}.{numberOfLeadingZeros,numberOfTrailingZeros}() Summary: These methods can be instrinsified by using bit scan, bit test, and population count instructions. Reviewed-by: kvn, never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/runtime/globals.hpp + test/compiler/6823354/Test6823354.java Changeset: e85af0c0c94b Author: twisti Date: 2009-05-07 00:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e85af0c0c94b Merge Changeset: f53b154d959d Author: twisti Date: 2009-05-06 08:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f53b154d959d 6837906: compiler tests of 6636138 fail with IllegalAccessException Summary: The compiler tests of 6636138 fail with an IllegalAccessException. Reviewed-by: kvn ! test/compiler/6636138/Test1.java ! test/compiler/6636138/Test2.java Changeset: f2954231d190 Author: twisti Date: 2009-05-07 04:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f2954231d190 Merge Changeset: d0e0d6d824d8 Author: kvn Date: 2009-05-08 10:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d0e0d6d824d8 Merge ! src/share/vm/runtime/globals.hpp Changeset: c96bf21b756f Author: kvn Date: 2009-05-08 10:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c96bf21b756f 6788527: Server vm intermittently fails with assertion "live value must not be garbage" with fastdebug bits Summary: Cache Jvmti and DTrace flags used by Compiler. Reviewed-by: never ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp Changeset: 44ccd7a9065c Author: ohair Date: 2009-05-08 15:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/44ccd7a9065c 6839151: Add a JPRT default test of -Xshare:dump when new hotspot is built Reviewed-by: never, kvn ! make/jprt.properties ! test/Makefile Changeset: 900e4df4b0c3 Author: ohair Date: 2009-05-08 23:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/900e4df4b0c3 Merge Changeset: a9e116455022 Author: kvn Date: 2009-05-11 17:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a9e116455022 6832293: JIT compiler got wrong result in type checking with -server Summary: Check for an object array of interface in CmpPNode::sub(). Reviewed-by: never ! src/share/vm/opto/subnode.cpp + test/compiler/6832293/Test.java Changeset: b2934faac289 Author: kvn Date: 2009-05-11 18:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b2934faac289 6836054: java/util/Arrays/CopyMethods.java fails on solaris-sparc with IllegalArgumentException Summary: Do not mark an allocation as scalar replaceable if its actual type in unknown statically. Reviewed-by: never ! src/share/vm/opto/escape.cpp Changeset: 2056494941db Author: twisti Date: 2009-05-13 00:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2056494941db 6814842: Load shortening optimizations Summary: 6797305 handles load widening but no shortening which should be covered here. Reviewed-by: never, kvn ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/output_c.cpp + test/compiler/6814842/Test6814842.java Changeset: 5d4dd2f5f6a1 Author: aph Date: 2009-04-17 15:50 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5d4dd2f5f6a1 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair Contributed-by: Andrew Haley ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make Changeset: 7a485bc4da16 Author: xdono Date: 2009-05-07 10:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7a485bc4da16 Merge Changeset: 116b019a3961 Author: ohair Date: 2009-05-08 14:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/116b019a3961 6839126: Type error found by newer windows compiler Reviewed-by: never, kvn ! src/share/vm/adlc/filebuff.hpp Changeset: 27d660246893 Author: ohair Date: 2009-05-15 18:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/27d660246893 Merge ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make Changeset: aabd393cf1ee Author: kvn Date: 2009-05-21 10:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/aabd393cf1ee 6772683: Thread.isInterrupted() fails to return true on multiprocessor PC Summary: Set the control edge for the field _interrupted load in inline_native_isInterrupted(). Reviewed-by: never ! src/share/vm/opto/library_call.cpp + test/compiler/6772683/InterruptedTest.java Changeset: 1851e1fb420e Author: kvn Date: 2009-05-27 12:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1851e1fb420e 6843752: missing code for an anti-dependent Phi in GCM Summary: Don't place a load below anti-dependent PHI. Reviewed-by: never, twisti ! src/share/vm/opto/gcm.cpp + test/compiler/6843752/Test.java Changeset: 273b2358ef1a Author: cfang Date: 2009-05-28 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/273b2358ef1a 6837146: Should perform unswitch before maximally unroll in loop transformation Summary: Move loop unswitch before maximally unroll Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp Changeset: 435f0808b826 Author: never Date: 2009-06-03 15:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/435f0808b826 6847305: solaris reorder mapfiles generate too many warnings Reviewed-by: kvn ! make/solaris/makefiles/reorder_COMPILER1_i486 ! make/solaris/makefiles/reorder_COMPILER1_sparc ! make/solaris/makefiles/reorder_COMPILER2_amd64 ! make/solaris/makefiles/reorder_COMPILER2_sparcv9 ! make/solaris/makefiles/reorder_TIERED_i486 ! make/solaris/makefiles/reorder_TIERED_sparc Changeset: 8b0b8998e1c3 Author: never Date: 2009-06-03 15:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8b0b8998e1c3 Merge Changeset: 085dd9ee61aa Author: never Date: 2009-06-03 18:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/085dd9ee61aa Merge Changeset: eacd97c88873 Author: cfang Date: 2009-06-05 10:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/eacd97c88873 6848466: frame::frame_size() assertion failure with -XX:+DebugDeoptimization Summary: add a RegisterMap* argument to frame::frame_size() to correctly compute the sender frame Reviewed-by: never ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/vframe.cpp From martinrb at google.com Tue Jun 9 18:04:13 2009 From: martinrb at google.com (Martin Buchholz) Date: Tue, 9 Jun 2009 18:04:13 -0700 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <4A2E40E8.3050606@sun.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> <17c6771e0906081005w14655c3w58d6cecee6eed013@mail.gmail.com> <4A2D996B.6070206@sun.com> <17c6771e0906090233hd16cecah7dea33a817ff23cc@mail.gmail.com> <4A2E40E8.3050606@sun.com> Message-ID: <1ccfd1c10906091804j7c379f0by937829a70c60c714@mail.gmail.com> Paul, Thanks for the clear explanation. Given this, I'm thinking we lobby Joe Darcy to use a *copy* of hotspot 14 stable as the hotspot to use with OpenJDK6. Which can then evolve with community input. Andrew can do the first commit. Martin On Tue, Jun 9, 2009 at 04:00, Paul Hohensee wrote: > Yes, we want you to create a fork. We can work together on the fork. > > The hs14 repo isn't a clone of Sun's 6u14 hotspot repo, it _is_ our 6u14 > hotspot repo. As such, we need it to stay as is so we can use it as the > basis for customer one-offs containing single fixes, etc. Think of hs14 > as a distro repo that happens to be public. Would it make sense for > a company like Redhat to have allowed community changes to, say, it's > ES 5.1 repo after it shipped? > > What we believed was asked for was a stable repo that could be used > as the _basis_ for things like 6-open. As I said, feel free to clone hs14 > for > that purpose and then update the clone. Doing so seems to us to fulfill > IcedTea developer requirements. > > SSRs are Synchronized Security Releases put out by Sun to fix particular > security holes across all Sun-supported jdk releases at the same time. > They > contain only security fixes, so non-security fixes like this one are > off-limits. > What we call Limited Update Releases can contain other-than-security fixes. > We alternate jdk6 update releases between SSRs and LURs. > > > Paul > > Andrew John Hughes wrote: > >> 2009/6/9 Paul Hohensee : >> >> >>> There seems to be some confusion here. >>> >>> >>> >> >> Clearly, because what I believe we asked for was a stability branch >> and that was the point of going through this whole process for over >> three months. Why setup a forest unless it will be updated? >> >> >> >>> hs14 is the version of hotspot that shipped with 6u14 and as such, is >>> frozen. >>> We do not intend to apply or allow any further bug fixes to it, including >>> the >>> one you propose here. >>> >>> >> >> I'm not asking you to apply it. I'm suggesting that I do. >> >> It was never intended to be the basis for another >> >> >>> openjdk >>> version of hotspot. >>> >>> >> >> The entire __point__ of making hs14 available was to use it in >> OpenJDK6, at least from the point of view of IcedTea developers. >> >> Ongoing hotspot development goes forward only in the >> >> >>> openjdk hotspot repo, which is currently labeled hs16. Of course, anyone >>> may >>> feel free to clone hs14 if they like, and apply what fixes they will to >>> said >>> clone. >>> >>> >> >> So you want us to create a fork? How does that help us all work together? >> >> >> >>> One of those clones could easily be jdk6 open, but that's not our (the >>> hotspot >>> group's) decision to make. >>> >>> The next jdk6 update release will include a new version of hotspot, based >>> either on hs14 (in which case it'll be an SSR, we'll likely call it >>> hs14.1, >>> and this >>> fix will be off limits) >>> >>> >> >> Why? >> >> or the current openjdk hotspot repo (in which case >> >> >>> it >>> will be a limited update, it'll likely be hs16, and the fix is already in >>> it). The >>> going-forward release is hs16. hs14 is a dead end. >>> >>> Paul >>> >>> Andrew John Hughes wrote: >>> >>> >>>> 2009/6/8 Andrew John Hughes : >>>> >>>> >>>> >>>>> The following webrev: >>>>> >>>>> http://fuseyism.com/6781583/webrev.00/ >>>>> >>>>> is backported from OpenJDK7. It allows hs14 to be built using GCC 4.3 >>>>> and above. Otherwise, the build fails. IcedTea has been applying an >>>>> equivalent fix as three separately developed patches, two of which >>>>> have been there pretty much since its inception in the summer of 2007. >>>>> >>>>> Ok to commit? >>>>> -- >>>>> Andrew :-) >>>>> >>>>> Free Java Software Engineer >>>>> Red Hat, Inc. (http://www.redhat.com) >>>>> >>>>> Support Free Java! >>>>> Contribute to GNU Classpath and the OpenJDK >>>>> http://www.gnu.org/software/classpath >>>>> http://openjdk.java.net >>>>> >>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>> >>>>> >>>>> >>>>> >>>> It's in the webrev, but to be explicit: this is for the new hs14 tree. >>>> >>>> >>>> >>> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090609/91da31b4/attachment.html From Paul.Hohensee at Sun.COM Tue Jun 9 19:44:35 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Tue, 09 Jun 2009 22:44:35 -0400 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <1ccfd1c10906091804j7c379f0by937829a70c60c714@mail.gmail.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> <17c6771e0906081005w14655c3w58d6cecee6eed013@mail.gmail.com> <4A2D996B.6070206@sun.com> <17c6771e0906090233hd16cecah7dea33a817ff23cc@mail.gmail.com> <4A2E40E8.3050606@sun.com> <1ccfd1c10906091804j7c379f0by937829a70c60c714@mail.gmail.com> Message-ID: <4A2F1E13.707@sun.com> Excellent idea. :) Paul Martin Buchholz wrote: > Paul, > Thanks for the clear explanation. > > Given this, I'm thinking we lobby Joe Darcy > to use a *copy* of hotspot 14 stable > as the hotspot to use with OpenJDK6. > Which can then evolve with community input. > Andrew can do the first commit. > > Martin > > On Tue, Jun 9, 2009 at 04:00, Paul Hohensee > wrote: > > Yes, we want you to create a fork. We can work together on the fork. > > The hs14 repo isn't a clone of Sun's 6u14 hotspot repo, it _is_ > our 6u14 > hotspot repo. As such, we need it to stay as is so we can use it > as the > basis for customer one-offs containing single fixes, etc. Think > of hs14 > as a distro repo that happens to be public. Would it make sense for > a company like Redhat to have allowed community changes to, say, it's > ES 5.1 repo after it shipped? > > What we believed was asked for was a stable repo that could be used > as the _basis_ for things like 6-open. As I said, feel free to > clone hs14 for > that purpose and then update the clone. Doing so seems to us to > fulfill > IcedTea developer requirements. > > SSRs are Synchronized Security Releases put out by Sun to fix > particular > security holes across all Sun-supported jdk releases at the same > time. They > contain only security fixes, so non-security fixes like this one > are off-limits. > What we call Limited Update Releases can contain > other-than-security fixes. > We alternate jdk6 update releases between SSRs and LURs. > > > Paul > > Andrew John Hughes wrote: > > 2009/6/9 Paul Hohensee >: > > > There seems to be some confusion here. > > > > > Clearly, because what I believe we asked for was a stability > branch > and that was the point of going through this whole process for > over > three months. Why setup a forest unless it will be updated? > > > > hs14 is the version of hotspot that shipped with 6u14 and > as such, is > frozen. > We do not intend to apply or allow any further bug fixes > to it, including > the > one you propose here. > > > > I'm not asking you to apply it. I'm suggesting that I do. > > It was never intended to be the basis for another > > > openjdk > version of hotspot. > > > > The entire __point__ of making hs14 available was to use it in > OpenJDK6, at least from the point of view of IcedTea developers. > > Ongoing hotspot development goes forward only in the > > > openjdk hotspot repo, which is currently labeled hs16. Of > course, anyone > may > feel free to clone hs14 if they like, and apply what fixes > they will to said > clone. > > > > So you want us to create a fork? How does that help us all > work together? > > > > One of those clones could easily be jdk6 open, but that's > not our (the > hotspot > group's) decision to make. > > The next jdk6 update release will include a new version of > hotspot, based > either on hs14 (in which case it'll be an SSR, we'll > likely call it hs14.1, > and this > fix will be off limits) > > > > Why? > > or the current openjdk hotspot repo (in which case > > > it > will be a limited update, it'll likely be hs16, and the > fix is already in > it). The > going-forward release is hs16. hs14 is a dead end. > > Paul > > Andrew John Hughes wrote: > > > 2009/6/8 Andrew John Hughes >: > > > > The following webrev: > > http://fuseyism.com/6781583/webrev.00/ > > is backported from OpenJDK7. It allows hs14 to be > built using GCC 4.3 > and above. Otherwise, the build fails. IcedTea > has been applying an > equivalent fix as three separately developed > patches, two of which > have been there pretty much since its inception in > the summer of 2007. > > Ok to commit? > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C > 2591 94EF D9D8 > > > > > It's in the webrev, but to be explicit: this is for > the new hs14 tree. > > > > > > > > > From Joe.Darcy at Sun.COM Wed Jun 10 00:02:47 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Wed, 10 Jun 2009 00:02:47 -0700 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <4A2F1E13.707@sun.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> <17c6771e0906081005w14655c3w58d6cecee6eed013@mail.gmail.com> <4A2D996B.6070206@sun.com> <17c6771e0906090233hd16cecah7dea33a817ff23cc@mail.gmail.com> <4A2E40E8.3050606@sun.com> <1ccfd1c10906091804j7c379f0by937829a70c60c714@mail.gmail.com> <4A2F1E13.707@sun.com> Message-ID: <4A2F5A97.9080805@sun.com> Myself and much of the Sun JDK team is out of the office this week. I'll consider Martin's suggestion and other approaches to this issue when I get back into the office next week. -Joe Paul Hohensee wrote: > Excellent idea. :) > > Paul > > Martin Buchholz wrote: >> Paul, >> Thanks for the clear explanation. >> >> Given this, I'm thinking we lobby Joe Darcy >> to use a *copy* of hotspot 14 stable >> as the hotspot to use with OpenJDK6. >> Which can then evolve with community input. >> Andrew can do the first commit. >> >> Martin >> >> On Tue, Jun 9, 2009 at 04:00, Paul Hohensee > > wrote: >> >> Yes, we want you to create a fork. We can work together on the >> fork. >> >> The hs14 repo isn't a clone of Sun's 6u14 hotspot repo, it _is_ >> our 6u14 >> hotspot repo. As such, we need it to stay as is so we can use it >> as the >> basis for customer one-offs containing single fixes, etc. Think >> of hs14 >> as a distro repo that happens to be public. Would it make sense for >> a company like Redhat to have allowed community changes to, say, >> it's >> ES 5.1 repo after it shipped? >> >> What we believed was asked for was a stable repo that could be used >> as the _basis_ for things like 6-open. As I said, feel free to >> clone hs14 for >> that purpose and then update the clone. Doing so seems to us to >> fulfill >> IcedTea developer requirements. >> >> SSRs are Synchronized Security Releases put out by Sun to fix >> particular >> security holes across all Sun-supported jdk releases at the same >> time. They >> contain only security fixes, so non-security fixes like this one >> are off-limits. >> What we call Limited Update Releases can contain >> other-than-security fixes. >> We alternate jdk6 update releases between SSRs and LURs. >> >> >> Paul >> >> Andrew John Hughes wrote: >> >> 2009/6/9 Paul Hohensee > >: >> >> There seems to be some confusion here. >> >> >> >> Clearly, because what I believe we asked for was a stability >> branch >> and that was the point of going through this whole process for >> over >> three months. Why setup a forest unless it will be updated? >> >> >> hs14 is the version of hotspot that shipped with 6u14 and >> as such, is >> frozen. >> We do not intend to apply or allow any further bug fixes >> to it, including >> the >> one you propose here. >> >> >> I'm not asking you to apply it. I'm suggesting that I do. >> >> It was never intended to be the basis for another >> >> openjdk >> version of hotspot. >> >> >> The entire __point__ of making hs14 available was to use it in >> OpenJDK6, at least from the point of view of IcedTea developers. >> >> Ongoing hotspot development goes forward only in the >> >> openjdk hotspot repo, which is currently labeled hs16. Of >> course, anyone >> may >> feel free to clone hs14 if they like, and apply what fixes >> they will to said >> clone. >> >> >> So you want us to create a fork? How does that help us all >> work together? >> >> >> One of those clones could easily be jdk6 open, but that's >> not our (the >> hotspot >> group's) decision to make. >> >> The next jdk6 update release will include a new version of >> hotspot, based >> either on hs14 (in which case it'll be an SSR, we'll >> likely call it hs14.1, >> and this >> fix will be off limits) >> >> >> Why? >> >> or the current openjdk hotspot repo (in which case >> >> it >> will be a limited update, it'll likely be hs16, and the >> fix is already in >> it). The >> going-forward release is hs16. hs14 is a dead end. >> >> Paul >> >> Andrew John Hughes wrote: >> >> 2009/6/8 Andrew John Hughes > >: >> >> >> The following webrev: >> >> http://fuseyism.com/6781583/webrev.00/ >> >> is backported from OpenJDK7. It allows hs14 to be >> built using GCC 4.3 >> and above. Otherwise, the build fails. IcedTea >> has been applying an >> equivalent fix as three separately developed >> patches, two of which >> have been there pretty much since its inception in >> the summer of 2007. >> >> Ok to commit? >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C >> 2591 94EF D9D8 >> >> >> >> It's in the webrev, but to be explicit: this is for >> the new hs14 tree. >> >> >> >> >> >> >> From gbenson at redhat.com Wed Jun 10 06:55:00 2009 From: gbenson at redhat.com (Gary Benson) Date: Wed, 10 Jun 2009 14:55:00 +0100 Subject: When might a CodeBuffer be moved? Message-ID: <20090610135500.GB26952@redhat.com> Hi all, I know CodeBuffers aren't moved by the garbage collector, but can they move at all? I remember someone (Steve Goldman?) telling me about a code compactor once, but can't remember the details. Can a code buffer move at any safepoint? Cheers, Gary -- http://gbenson.net/ From gnu_andrew at member.fsf.org Wed Jun 10 08:37:25 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 10 Jun 2009 16:37:25 +0100 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <4A2E40E8.3050606@sun.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> <17c6771e0906081005w14655c3w58d6cecee6eed013@mail.gmail.com> <4A2D996B.6070206@sun.com> <17c6771e0906090233hd16cecah7dea33a817ff23cc@mail.gmail.com> <4A2E40E8.3050606@sun.com> Message-ID: <17c6771e0906100837i2e5176bbvcbed36a8f0216511@mail.gmail.com> 2009/6/9 Paul Hohensee : > Yes, we want you to create a fork. ?We can work together on the fork. > > The hs14 repo isn't a clone of Sun's 6u14 hotspot repo, it _is_ our 6u14 > hotspot repo. ?As such, we need it to stay as is so we can use it as the > basis for customer one-offs containing single fixes, etc. ?Think of hs14 > as a distro repo that happens to be public. ?Would it make sense for > a company like Redhat to have allowed community changes to, say, it's > ES 5.1 repo after it shipped? > I'm sorry, but I can't follow your logic here. From what you've said in previous emails and simple common sense, I can't see these customer one-offs being created one on top of each other in the public repository. So what you seem to be saying is you need to keep the tip of the repository the same as it is now for these private forks - why not just tag the tree at this point and use that tag for future private forks for customer one-offs? Things would be much easier generally if the HotSpot 'releases' (hs16b03, etc.) were tagged, as I believe has been mentioned before. > What we believed was asked for was a stable repo that could be used > as the _basis_ for things like 6-open. ?As I said, feel free to clone hs14 > for > that purpose and then update the clone. ?Doing so seems to us to fulfill > IcedTea developer requirements. > To be honest, it doesn't really matter that much whether we use hsx or a clone to me; I'm just trying to understand why effort was put into creating a forest which is essentially frozen in time. What worries me is that this discussion keeps throwing up 'us' and 'them' scenarios, as you refer to here with 'IcedTea developer requirements'. I thought we were trying to work together as an OpenJDK community which includes those inside Sun and those outside it (which is represented by our newly expanded IGB). As far as IcedTea requirements are concerned, the mere availability of an updated hs14 has allowed us to ship IcedTea6 1.5 with this included. The push for updating OpenJDK6 and making it actually buildable on a modern system is because we want OpenJDK itself to succeed for the benefit of everyone. That's the last thing I'm going to add with regard to this, as the whole conversation seems to have gone on too long and doesn't appear to be getting us anywhere. Please just let us know when there is a hs14 available somewhere to which we can contribute our patches. > SSRs are Synchronized Security Releases put out by Sun to fix particular > security holes across all Sun-supported jdk releases at the same time. ?They > contain only security fixes, so non-security fixes like this one are > off-limits. > What we call Limited Update Releases can contain other-than-security fixes. > We alternate jdk6 update releases between SSRs and LURs. > > Paul > > Andrew John Hughes wrote: >> >> 2009/6/9 Paul Hohensee : >> >>> >>> There seems to be some confusion here. >>> >>> >> >> Clearly, because what I believe we asked for was a stability branch >> and that was the point of going through this whole process for over >> three months. ?Why setup a forest unless it will be updated? >> >> >>> >>> hs14 is the version of hotspot that shipped with 6u14 and as such, is >>> frozen. >>> We do not intend to apply or allow any further bug fixes to it, including >>> the >>> one you propose here. >>> >> >> I'm not asking you to apply it. ?I'm suggesting that I do. >> >> It was never intended to be the basis for another >> >>> >>> openjdk >>> version of hotspot. >>> >> >> The entire __point__ of making hs14 available was to use it in >> OpenJDK6, at least from the point of view of IcedTea developers. >> >> ?Ongoing hotspot development goes forward only in the >> >>> >>> openjdk hotspot repo, which is currently labeled hs16. ?Of course, anyone >>> may >>> feel free to clone hs14 if they like, and apply what fixes they will to >>> said >>> clone. >>> >> >> So you want us to create a fork? ?How does that help us all work together? >> >> >>> >>> One of those clones could easily be jdk6 open, but that's not our (the >>> hotspot >>> group's) decision to make. >>> >>> The next jdk6 update release will include a new version of hotspot, based >>> either on hs14 (in which case it'll be an SSR, we'll likely call it >>> hs14.1, >>> and this >>> fix will be off limits) >>> >> >> Why? >> >> or the current openjdk hotspot repo (in which case >> >>> >>> it >>> will be a limited update, it'll likely be hs16, and the fix is already in >>> it). ?The >>> going-forward release is hs16. ?hs14 is a dead end. >>> >>> Paul >>> >>> Andrew John Hughes wrote: >>> >>>> >>>> 2009/6/8 Andrew John Hughes : >>>> >>>> >>>>> >>>>> The following webrev: >>>>> >>>>> http://fuseyism.com/6781583/webrev.00/ >>>>> >>>>> is backported from OpenJDK7. ?It allows hs14 to be built using GCC 4.3 >>>>> and above. ?Otherwise, the build fails. ?IcedTea has been applying an >>>>> equivalent fix as three separately developed patches, two of which >>>>> have been there pretty much since its inception in the summer of 2007. >>>>> >>>>> Ok to commit? >>>>> -- >>>>> Andrew :-) >>>>> >>>>> Free Java Software Engineer >>>>> Red Hat, Inc. (http://www.redhat.com) >>>>> >>>>> Support Free Java! >>>>> Contribute to GNU Classpath and the OpenJDK >>>>> http://www.gnu.org/software/classpath >>>>> http://openjdk.java.net >>>>> >>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>>>> >>>>> >>>>> >>>> >>>> It's in the webrev, but to be explicit: this is for the new hs14 tree. >>>> >>>> >> >> >> >> > Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Thomas.Rodriguez at Sun.COM Wed Jun 10 09:16:09 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 10 Jun 2009 09:16:09 -0700 Subject: When might a CodeBuffer be moved? In-Reply-To: <20090610135500.GB26952@redhat.com> References: <20090610135500.GB26952@redhat.com> Message-ID: <1AD018C8-2B59-4091-8BC1-545D65EC1445@sun.com> CodeBlobs are never moved automatically by anything. CodeBuffers have support for resizing the code generation buffer by moving the instructions from one CodeBlob to a new larger one but you have to ask for that using maybe_expand_to_ensure_remaining. nmethod can be reclaimed by the sweeper once they are no longer referenced as a result of being made not entrant or zombie. tom On Jun 10, 2009, at 6:55 AM, Gary Benson wrote: > Hi all, > > I know CodeBuffers aren't moved by the garbage collector, but can they > move at all? I remember someone (Steve Goldman?) telling me about a > code compactor once, but can't remember the details. Can a code > buffer move at any safepoint? > > Cheers, > Gary > > -- > http://gbenson.net/ From Dalibor.Topic at Sun.COM Wed Jun 10 10:42:54 2009 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Wed, 10 Jun 2009 19:42:54 +0200 Subject: CFV: Project Sponsorship: Hotspot Express In-Reply-To: <4A0B35CF.8050502@sun.com> References: <4A0B35CF.8050502@sun.com> Message-ID: <4A2FF09E.3010605@sun.com> Erik Trimble wrote: > Question: Should the Hotspot Group sponsor the proposed Hotspot Express > [1] Project? > > > Once a decision has been made the votes will be summarized and > reported to this list and also to discuss at openjdk.java.net. > Hi, >From the looks of it on the list the vote concluded successfully, but I must have missed the summary mail. Correct? cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin H?ring From jon.masamitsu at sun.com Wed Jun 10 17:43:48 2009 From: jon.masamitsu at sun.com (jon.masamitsu at sun.com) Date: Thu, 11 Jun 2009 00:43:48 +0000 Subject: hg: jdk7/hotspot/hotspot: 7 new changesets Message-ID: <20090611004402.B8399E332@hg.openjdk.java.net> Changeset: 315a5d70b295 Author: iveresov Date: 2009-05-11 16:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/315a5d70b295 6484957: G1: parallel concurrent refinement 6826318: G1: remove traversal-based refinement code Summary: Removed traversal-based refinement code as it's no longer used. Made the concurrent refinement (queue-based) parallel. Reviewed-by: tonyp ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: 215f81b4d9b3 Author: iveresov Date: 2009-05-18 11:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/215f81b4d9b3 6841831: G1: assert(contains_reference(from),"We just added it!") fires Summary: During parallel rset updating we have to make sure that the worker ids of the refinement threads do not intersect with the worker ids that can be claimed by the mutator threads. Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: 29e7d79232b9 Author: apetrusenko Date: 2009-05-19 04:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/29e7d79232b9 6819065: G1: eliminate high serial card table clearing time Reviewed-by: iveresov, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 7fd05714f579 Author: jcoomes Date: 2009-05-26 16:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7fd05714f579 Merge Changeset: fe1574da39fc Author: ysr Date: 2009-06-07 00:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fe1574da39fc 6848641: CMSCollector::_roots_scanning_options should be initialized Summary: The field is now initialized in the constructor. Reviewed-by: iveresov, jmasa, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp Changeset: f89cf529c3c7 Author: iveresov Date: 2009-06-08 16:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f89cf529c3c7 6849122: G1: Typo introduced during implementation of the parallel refinement Summary: Typo fix Reviewed-by: jcoomes ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp Changeset: 7295839252de Author: jmasa Date: 2009-06-10 14:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7295839252de Merge From gbenson at redhat.com Thu Jun 11 02:18:57 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 11 Jun 2009 10:18:57 +0100 Subject: When might a CodeBuffer be moved? In-Reply-To: <1AD018C8-2B59-4091-8BC1-545D65EC1445@sun.com> References: <20090610135500.GB26952@redhat.com> <1AD018C8-2B59-4091-8BC1-545D65EC1445@sun.com> Message-ID: <20090611091857.GB3238@redhat.com> Oh, that's excellent news. Now to figure out if I can use it! ;) Cheers, Gary Tom Rodriguez wrote: > CodeBlobs are never moved automatically by anything. CodeBuffers > have support for resizing the code generation buffer by moving the > instructions from one CodeBlob to a new larger one but you have to > ask for that using maybe_expand_to_ensure_remaining. nmethod can > be reclaimed by the sweeper once they are no longer referenced as > a result of being made not entrant or zombie. > > tom > > On Jun 10, 2009, at 6:55 AM, Gary Benson wrote: > > Hi all, > > > > I know CodeBuffers aren't moved by the garbage collector, but can > > they move at all? I remember someone (Steve Goldman?) telling me > > about a code compactor once, but can't remember the details. Can > > a code buffer move at any safepoint? > > > > Cheers, > > Gary > > > > -- > > http://gbenson.net/ From Thomas.Rodriguez at Sun.COM Thu Jun 11 17:56:50 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 11 Jun 2009 17:56:50 -0700 Subject: When might a CodeBuffer be moved? In-Reply-To: <20090611091857.GB3238@redhat.com> References: <20090610135500.GB26952@redhat.com> <1AD018C8-2B59-4091-8BC1-545D65EC1445@sun.com> <20090611091857.GB3238@redhat.com> Message-ID: <64618985-C3CD-4C51-BDA9-F64BD61DB780@sun.com> You wouldn't want to just build a CodeBuffer and keep it around. Normally we use BufferBlobs for any piece of code that we want to generate but which doesn't need to be relocatable. The interpreter for instance is constructed this way as are a lot of helper snippers of various kinds. You wouldn't want to just build a CodeBuffer and keep it around. The preferred way would be the make a BufferBlob and then build a CodeBuffer on top of it to use for code generation. You'd just drop the CodeBuffer onces you were done with code generation and build a new one if you needed it. tom On Jun 11, 2009, at 2:18 AM, Gary Benson wrote: > Oh, that's excellent news. Now to figure out if I can use it! ;) > > Cheers, > Gary > > Tom Rodriguez wrote: >> CodeBlobs are never moved automatically by anything. CodeBuffers >> have support for resizing the code generation buffer by moving the >> instructions from one CodeBlob to a new larger one but you have to >> ask for that using maybe_expand_to_ensure_remaining. nmethod can >> be reclaimed by the sweeper once they are no longer referenced as >> a result of being made not entrant or zombie. >> >> tom >> >> On Jun 10, 2009, at 6:55 AM, Gary Benson wrote: >>> Hi all, >>> >>> I know CodeBuffers aren't moved by the garbage collector, but can >>> they move at all? I remember someone (Steve Goldman?) telling me >>> about a code compactor once, but can't remember the details. Can >>> a code buffer move at any safepoint? >>> >>> Cheers, >>> Gary >>> >>> -- >>> http://gbenson.net/ From john.coomes at sun.com Thu Jun 11 20:38:34 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 12 Jun 2009 03:38:34 +0000 Subject: hg: jdk7/hotspot: 6 new changesets Message-ID: <20090612033834.B6AFFE3F2@hg.openjdk.java.net> Changeset: a942ea653d97 Author: aph Date: 2009-04-17 15:37 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/a942ea653d97 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair Contributed-by: Andrew Haley ! make/sanity-rules.gmk Changeset: f5ab6d6ae4b1 Author: xdono Date: 2009-05-07 10:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/f5ab6d6ae4b1 Merge - make/jprt.config Changeset: 37fad8722d92 Author: ohair Date: 2009-03-26 16:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/37fad8722d92 6822913: Consolidate make/jprt.config files, let JPRT manage this file make it optional in repos Reviewed-by: tbell - make/jprt.config Changeset: b284e021293c Author: ohair Date: 2009-05-08 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/b284e021293c Merge Changeset: 39565502682c Author: ohair Date: 2009-05-15 13:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/39565502682c Merge Changeset: 472c21584cfd Author: xdono Date: 2009-06-11 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/472c21584cfd Added tag jdk7-b60 for changeset 39565502682c ! .hgtags From john.coomes at sun.com Thu Jun 11 20:44:54 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 12 Jun 2009 03:44:54 +0000 Subject: hg: jdk7/hotspot/corba: 6 new changesets Message-ID: <20090612034500.A370DE3F7@hg.openjdk.java.net> Changeset: 7b47536c234e Author: ohair Date: 2009-03-26 16:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/7b47536c234e 6822374: Windows: detect X64 when PROCESSOR_IDENTIFIER contains EM64T or Intel64 6822913: Consolidate make/jprt.config files, let JPRT manage this file make it optional in repos Reviewed-by: tbell ! make/common/shared/Platform.gmk - make/jprt.config Changeset: 39aa6ae82075 Author: ohair Date: 2009-05-08 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/39aa6ae82075 Merge Changeset: da27d54e06bd Author: ohair Date: 2009-05-15 13:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/da27d54e06bd Merge Changeset: 5dcbe748e580 Author: ohair Date: 2009-05-19 17:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/5dcbe748e580 6843041: Remove duplicate README files in repositories (make/README) Reviewed-by: robilad - make/README Changeset: f1e1cccbd13a Author: ohair Date: 2009-05-19 18:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/f1e1cccbd13a 6733313: corba build warnings: /bin/sh: gcc: not found Reviewed-by: tbell ! make/common/shared/Compiler-gcc.gmk ! make/common/shared/Compiler-sun.gmk Changeset: e906b16a12a9 Author: xdono Date: 2009-06-11 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/e906b16a12a9 Added tag jdk7-b60 for changeset f1e1cccbd13a ! .hgtags From john.coomes at sun.com Thu Jun 11 20:56:06 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 12 Jun 2009 03:56:06 +0000 Subject: hg: jdk7/hotspot/jaxp: 8 new changesets Message-ID: <20090612035618.DDC64E3FC@hg.openjdk.java.net> Changeset: 19c316392d9e Author: aph Date: 2009-04-17 15:55 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/19c316392d9e 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair Contributed-by: Andrew Haley ! make/Makefile ! make/build.xml Changeset: 7967d26b229c Author: aph Date: 2009-04-20 19:00 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/7967d26b229c 6832141: Bug 100045 - Fix for 100028 breaks debug info for class files Summary: Correct fallout from 100028 patch Reviewed-by: ohair Contributed-by: Andrew Haley ! make/Makefile Changeset: 04af70c1189c Author: ohair Date: 2009-05-06 11:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/04af70c1189c 6837665: Deal with windows ant problem where commas in -D options do not work Reviewed-by: xdono ! make/Makefile ! make/build.properties Changeset: 44e5ca2a846c Author: xdono Date: 2009-05-07 10:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/44e5ca2a846c Merge Changeset: 0ea9bb9c6ddc Author: xdono Date: 2009-05-07 12:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/0ea9bb9c6ddc Merge - src/share/classes/com/sun/org/apache/xalan/internal/client/XSLTProcessorApplet.java - src/share/classes/com/sun/org/apache/xalan/internal/client/package.html Changeset: cdc8761f136a Author: ohair Date: 2009-05-15 13:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/cdc8761f136a Merge Changeset: 259aef5045a1 Author: ohair Date: 2009-05-19 17:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/259aef5045a1 6843041: Remove duplicate README files in repositories (make/README) Reviewed-by: robilad - make/README Changeset: f1ac756616ea Author: xdono Date: 2009-06-11 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/f1ac756616ea Added tag jdk7-b60 for changeset 259aef5045a1 ! .hgtags From john.coomes at sun.com Thu Jun 11 21:03:12 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 12 Jun 2009 04:03:12 +0000 Subject: hg: jdk7/hotspot/jaxws: 8 new changesets Message-ID: <20090612040324.62D21E403@hg.openjdk.java.net> Changeset: a92183572d99 Author: aph Date: 2009-04-17 15:56 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/a92183572d99 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair Contributed-by: Andrew Haley ! make/Makefile ! make/build.xml Changeset: ab30d5761947 Author: aph Date: 2009-04-20 19:01 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/ab30d5761947 6832141: Bug 100045 - Fix for 100028 breaks debug info for class files Summary: Correct fallout from 100028 patch Reviewed-by: ohair Contributed-by: Andrew Haley ! make/Makefile Changeset: 35c29ff8d904 Author: ohair Date: 2009-05-06 11:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/35c29ff8d904 6837665: Deal with windows ant problem where commas in -D options do not work Reviewed-by: xdono ! make/Makefile ! make/build.properties Changeset: d95fec0fa489 Author: xdono Date: 2009-05-07 10:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/d95fec0fa489 Merge ! make/Makefile ! make/build.xml - src/share/classes/com/sun/tools/internal/txw2/AntErrorListener.java - src/share/classes/com/sun/tools/internal/txw2/ConsoleErrorReporter.java - src/share/classes/com/sun/tools/internal/txw2/ErrorListener.java - src/share/classes/com/sun/tools/internal/txw2/Main.java - src/share/classes/com/sun/tools/internal/txw2/NameUtil.java - src/share/classes/com/sun/tools/internal/txw2/RELAXNGLoader.java - src/share/classes/com/sun/tools/internal/txw2/SchemaBuilder.java - src/share/classes/com/sun/tools/internal/txw2/TxwOptions.java - src/share/classes/com/sun/tools/internal/txw2/TxwTask.java - src/share/classes/com/sun/tools/internal/txw2/XmlSchemaLoader.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/AnnotationsImpl.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/CommentListImpl.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/DataPatternBuilderImpl.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/DatatypeFactory.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/DivImpl.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/ElementAnnotationBuilderImpl.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/GrammarImpl.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/GrammarSectionImpl.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/SchemaBuilderImpl.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/package.html - src/share/classes/com/sun/tools/internal/txw2/builder/xsd/XmlSchemaBuilder.java - src/share/classes/com/sun/tools/internal/txw2/builder/xsd/package.html - src/share/classes/com/sun/tools/internal/txw2/model/Attribute.java - src/share/classes/com/sun/tools/internal/txw2/model/CycleIterator.java - src/share/classes/com/sun/tools/internal/txw2/model/Data.java - src/share/classes/com/sun/tools/internal/txw2/model/Define.java - src/share/classes/com/sun/tools/internal/txw2/model/Element.java - src/share/classes/com/sun/tools/internal/txw2/model/Empty.java - src/share/classes/com/sun/tools/internal/txw2/model/Grammar.java - src/share/classes/com/sun/tools/internal/txw2/model/Leaf.java - src/share/classes/com/sun/tools/internal/txw2/model/List.java - src/share/classes/com/sun/tools/internal/txw2/model/Node.java - src/share/classes/com/sun/tools/internal/txw2/model/NodeSet.java - src/share/classes/com/sun/tools/internal/txw2/model/Ref.java - src/share/classes/com/sun/tools/internal/txw2/model/Text.java - src/share/classes/com/sun/tools/internal/txw2/model/Value.java - src/share/classes/com/sun/tools/internal/txw2/model/WriterNode.java - src/share/classes/com/sun/tools/internal/txw2/model/XmlNode.java - src/share/classes/com/sun/tools/internal/txw2/model/prop/AttributeProp.java - src/share/classes/com/sun/tools/internal/txw2/model/prop/ElementProp.java - src/share/classes/com/sun/tools/internal/txw2/model/prop/LeafElementProp.java - src/share/classes/com/sun/tools/internal/txw2/model/prop/Prop.java - src/share/classes/com/sun/tools/internal/txw2/model/prop/ValueProp.java - src/share/classes/com/sun/tools/internal/txw2/model/prop/XmlItemProp.java - src/share/classes/com/sun/tools/internal/ws/processor/Processor.java - src/share/classes/com/sun/tools/internal/ws/processor/ProcessorAction.java - src/share/classes/com/sun/tools/internal/ws/processor/ProcessorActionVersion.java - src/share/classes/com/sun/tools/internal/ws/processor/ProcessorConstants.java - src/share/classes/com/sun/tools/internal/ws/processor/ProcessorNotificationListener.java - src/share/classes/com/sun/tools/internal/ws/processor/ProcessorOptions.java - src/share/classes/com/sun/tools/internal/ws/processor/config/ClassModelInfo.java - src/share/classes/com/sun/tools/internal/ws/processor/config/Configuration.java - src/share/classes/com/sun/tools/internal/ws/processor/config/ConfigurationException.java - src/share/classes/com/sun/tools/internal/ws/processor/config/HandlerChainInfo.java - src/share/classes/com/sun/tools/internal/ws/processor/config/HandlerInfo.java - src/share/classes/com/sun/tools/internal/ws/processor/config/ModelInfo.java - src/share/classes/com/sun/tools/internal/ws/processor/config/WSDLModelInfo.java - src/share/classes/com/sun/tools/internal/ws/processor/config/parser/ClassModelParser.java - src/share/classes/com/sun/tools/internal/ws/processor/config/parser/CustomizationParser.java - src/share/classes/com/sun/tools/internal/ws/processor/config/parser/InputParser.java - src/share/classes/com/sun/tools/internal/ws/processor/config/parser/JAXWSBindingInfoParser.java - src/share/classes/com/sun/tools/internal/ws/processor/config/parser/ParserUtil.java - src/share/classes/com/sun/tools/internal/ws/processor/config/parser/Reader.java - src/share/classes/com/sun/tools/internal/ws/processor/generator/JAXBTypeGenerator.java - src/share/classes/com/sun/tools/internal/ws/processor/generator/SimpleToBoxedUtil.java - src/share/classes/com/sun/tools/internal/ws/processor/modeler/ModelerUtils.java - src/share/classes/com/sun/tools/internal/ws/processor/modeler/annotation/WebServiceReferenceCollector.java - src/share/classes/com/sun/tools/internal/ws/processor/util/ClientProcessorEnvironment.java - src/share/classes/com/sun/tools/internal/ws/processor/util/GeneratedFileInfo.java - src/share/classes/com/sun/tools/internal/ws/processor/util/ProcessorEnvironment.java - src/share/classes/com/sun/tools/internal/ws/processor/util/ProcessorEnvironmentBase.java - src/share/classes/com/sun/tools/internal/ws/util/JAXWSClassFactory.java - src/share/classes/com/sun/tools/internal/ws/util/JavaCompilerHelper.java - src/share/classes/com/sun/tools/internal/ws/util/MapBase.java - src/share/classes/com/sun/tools/internal/ws/util/ToolBase.java - src/share/classes/com/sun/tools/internal/ws/util/xml/NodeListIterator.java - src/share/classes/com/sun/tools/internal/ws/util/xml/NullEntityResolver.java - src/share/classes/com/sun/tools/internal/ws/util/xml/PrettyPrintingXmlWriter.java - src/share/classes/com/sun/tools/internal/ws/util/xml/XmlWriter.java - src/share/classes/com/sun/tools/internal/ws/wscompile/ActionConstants.java - src/share/classes/com/sun/tools/internal/ws/wscompile/CompileTool.java - src/share/classes/com/sun/tools/internal/ws/wsdl/document/schema/BuiltInTypes.java - src/share/classes/com/sun/tools/internal/ws/wsdl/document/schema/Schema.java - src/share/classes/com/sun/tools/internal/ws/wsdl/document/schema/SchemaAttribute.java - src/share/classes/com/sun/tools/internal/ws/wsdl/document/schema/SchemaDocument.java - src/share/classes/com/sun/tools/internal/ws/wsdl/document/schema/SchemaElement.java - src/share/classes/com/sun/tools/internal/ws/wsdl/document/schema/SchemaEntity.java - src/share/classes/com/sun/tools/internal/ws/wsdl/framework/Extensible.java - src/share/classes/com/sun/tools/internal/ws/wsdl/framework/Extension.java - src/share/classes/com/sun/tools/internal/ws/wsdl/framework/ParserContext.java - src/share/classes/com/sun/tools/internal/ws/wsdl/framework/WriterContext.java - src/share/classes/com/sun/tools/internal/ws/wsdl/parser/ExtensionHandler.java - src/share/classes/com/sun/tools/internal/ws/wsdl/parser/ExtensionHandlerBase.java - src/share/classes/com/sun/tools/internal/ws/wsdl/parser/SchemaExtensionHandler.java - src/share/classes/com/sun/tools/internal/ws/wsdl/parser/SchemaParser.java - src/share/classes/com/sun/tools/internal/ws/wsdl/parser/SchemaWriter.java - src/share/classes/com/sun/tools/internal/ws/wsdl/parser/WSDLWriter.java - src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/DOM4JLocator.java - src/share/classes/com/sun/tools/internal/xjc/util/XMLStreamReaderToContentHandler.java - src/share/classes/com/sun/xml/internal/bind/v2/doc-files/packages.png - src/share/classes/com/sun/xml/internal/bind/v2/doc-files/packages.vsd - src/share/classes/com/sun/xml/internal/bind/v2/doc-files/readme.txt - src/share/classes/com/sun/xml/internal/ws/binding/http/HTTPBindingImpl.java - src/share/classes/com/sun/xml/internal/ws/binding/soap/SOAPBindingImpl.java - src/share/classes/com/sun/xml/internal/ws/client/AsyncHandlerService.java - src/share/classes/com/sun/xml/internal/ws/client/ClientConfigurationException.java - src/share/classes/com/sun/xml/internal/ws/client/ContactInfoBase.java - src/share/classes/com/sun/xml/internal/ws/client/ContactInfoListImpl.java - src/share/classes/com/sun/xml/internal/ws/client/ContactInfoListIteratorBase.java - src/share/classes/com/sun/xml/internal/ws/client/ContextMap.java - src/share/classes/com/sun/xml/internal/ws/client/EndpointIFBase.java - src/share/classes/com/sun/xml/internal/ws/client/EndpointIFContext.java - src/share/classes/com/sun/xml/internal/ws/client/EndpointIFInvocationHandler.java - src/share/classes/com/sun/xml/internal/ws/client/InternalBindingProvider.java - src/share/classes/com/sun/xml/internal/ws/client/PortInfoBase.java - src/share/classes/com/sun/xml/internal/ws/client/ServiceContext.java - src/share/classes/com/sun/xml/internal/ws/client/ServiceContextBuilder.java - src/share/classes/com/sun/xml/internal/ws/client/WSFuture.java - src/share/classes/com/sun/xml/internal/ws/client/dispatch/DispatchBase.java - src/share/classes/com/sun/xml/internal/ws/client/dispatch/DispatchContext.java - src/share/classes/com/sun/xml/internal/ws/client/dispatch/ResponseImpl.java - src/share/classes/com/sun/xml/internal/ws/client/dispatch/impl/DispatchContactInfoList.java - src/share/classes/com/sun/xml/internal/ws/client/dispatch/impl/DispatchDelegate.java - src/share/classes/com/sun/xml/internal/ws/client/dispatch/impl/encoding/DispatchSerializer.java - src/share/classes/com/sun/xml/internal/ws/client/dispatch/impl/encoding/DispatchUtil.java - src/share/classes/com/sun/xml/internal/ws/client/dispatch/impl/protocol/MessageDispatcherHelper.java - src/share/classes/com/sun/xml/internal/ws/encoding/EncoderDecoderBase.java - src/share/classes/com/sun/xml/internal/ws/encoding/JAXWSAttachmentMarshaller.java - src/share/classes/com/sun/xml/internal/ws/encoding/JAXWSAttachmentUnmarshaller.java - src/share/classes/com/sun/xml/internal/ws/encoding/internal/InternalEncoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/jaxb/JAXBBeanInfo.java - src/share/classes/com/sun/xml/internal/ws/encoding/jaxb/JAXBBridgeInfo.java - src/share/classes/com/sun/xml/internal/ws/encoding/jaxb/JAXBTypeSerializer.java - src/share/classes/com/sun/xml/internal/ws/encoding/jaxb/RpcLitPayload.java - src/share/classes/com/sun/xml/internal/ws/encoding/jaxb/RpcLitPayloadSerializer.java - src/share/classes/com/sun/xml/internal/ws/encoding/simpletype/EncoderUtils.java - src/share/classes/com/sun/xml/internal/ws/encoding/simpletype/SimpleTypeConstants.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/ClientEncoderDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/EncoderDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/SOAPDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/SOAPEPTFactory.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/SOAPEncoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/SOAPVersion.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/ServerEncoderDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/client/SOAP12XMLDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/client/SOAP12XMLEncoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/client/SOAPXMLDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/client/SOAPXMLEncoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/AttachmentBlock.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/BodyBlock.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/DelegateBase.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/HeaderBlock.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/InternalMessage.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/MessageBlock.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/MessageInfoBase.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/SOAP12NotUnderstoodHeaderBlock.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/FaultCode.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/FaultCodeEnum.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/FaultReason.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/FaultReasonText.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/FaultSubcode.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/SOAP12FaultInfo.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/SOAPFaultInfo.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/SOAPMsgCreateException.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/SOAPMsgFactoryCreateException.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/server/ProviderSED.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/server/SOAP12XMLDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/server/SOAP12XMLEncoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/server/SOAPXMLDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/server/SOAPXMLEncoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/xml/XMLDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/xml/XMLEPTFactory.java - src/share/classes/com/sun/xml/internal/ws/encoding/xml/XMLEncoder.java - src/share/classes/com/sun/xml/internal/ws/handler/HandlerChainCaller.java - src/share/classes/com/sun/xml/internal/ws/handler/HandlerContext.java - src/share/classes/com/sun/xml/internal/ws/handler/HandlerResolverImpl.java - src/share/classes/com/sun/xml/internal/ws/handler/MessageContextUtil.java - src/share/classes/com/sun/xml/internal/ws/handler/SHDSOAPMessageContext.java - src/share/classes/com/sun/xml/internal/ws/handler/SOAPHandlerContext.java - src/share/classes/com/sun/xml/internal/ws/handler/XMLHandlerContext.java - src/share/classes/com/sun/xml/internal/ws/handler/XMLLogicalMessageContextImpl.java - src/share/classes/com/sun/xml/internal/ws/handler/XMLLogicalMessageImpl.java - src/share/classes/com/sun/xml/internal/ws/handler/package-info.java - src/share/classes/com/sun/xml/internal/ws/model/CheckedException.java - src/share/classes/com/sun/xml/internal/ws/model/ExceptionType.java - src/share/classes/com/sun/xml/internal/ws/model/JavaMethod.java - src/share/classes/com/sun/xml/internal/ws/model/Mode.java - src/share/classes/com/sun/xml/internal/ws/model/Parameter.java - src/share/classes/com/sun/xml/internal/ws/model/ParameterBinding.java - src/share/classes/com/sun/xml/internal/ws/model/RuntimeModel.java - src/share/classes/com/sun/xml/internal/ws/model/soap/SOAPBinding.java - src/share/classes/com/sun/xml/internal/ws/model/soap/SOAPRuntimeModel.java - src/share/classes/com/sun/xml/internal/ws/model/soap/Style.java - src/share/classes/com/sun/xml/internal/ws/model/soap/Use.java - src/share/classes/com/sun/xml/internal/ws/modeler/RuntimeModeler.java - src/share/classes/com/sun/xml/internal/ws/modeler/RuntimeModelerException.java - src/share/classes/com/sun/xml/internal/ws/pept/Delegate.java - src/share/classes/com/sun/xml/internal/ws/pept/encoding/Decoder.java - src/share/classes/com/sun/xml/internal/ws/pept/encoding/Encoder.java - src/share/classes/com/sun/xml/internal/ws/pept/ept/Acceptor.java - src/share/classes/com/sun/xml/internal/ws/pept/ept/ContactInfo.java - src/share/classes/com/sun/xml/internal/ws/pept/ept/ContactInfoList.java - src/share/classes/com/sun/xml/internal/ws/pept/ept/ContactInfoListIterator.java - src/share/classes/com/sun/xml/internal/ws/pept/ept/EPTFactory.java - src/share/classes/com/sun/xml/internal/ws/pept/ept/MessageInfo.java - src/share/classes/com/sun/xml/internal/ws/pept/presentation/MessageStruct.java - src/share/classes/com/sun/xml/internal/ws/pept/presentation/Stub.java - src/share/classes/com/sun/xml/internal/ws/pept/presentation/TargetFinder.java - src/share/classes/com/sun/xml/internal/ws/pept/presentation/Tie.java - src/share/classes/com/sun/xml/internal/ws/pept/protocol/Interceptors.java - src/share/classes/com/sun/xml/internal/ws/pept/protocol/MessageDispatcher.java - src/share/classes/com/sun/xml/internal/ws/protocol/soap/client/SOAPMessageDispatcher.java - src/share/classes/com/sun/xml/internal/ws/protocol/soap/server/ProviderSOAPMD.java - src/share/classes/com/sun/xml/internal/ws/protocol/soap/server/SOAPMessageDispatcher.java - src/share/classes/com/sun/xml/internal/ws/protocol/xml/client/XMLMessageDispatcher.java - src/share/classes/com/sun/xml/internal/ws/protocol/xml/server/ProviderXMLMD.java - src/share/classes/com/sun/xml/internal/ws/protocol/xml/server/XMLMessageDispatcher.java - src/share/classes/com/sun/xml/internal/ws/server/AppMsgContextImpl.java - src/share/classes/com/sun/xml/internal/ws/server/DocInfo.java - src/share/classes/com/sun/xml/internal/ws/server/EPTFactoryBase.java - src/share/classes/com/sun/xml/internal/ws/server/EPTFactoryFactoryBase.java - src/share/classes/com/sun/xml/internal/ws/server/PeptTie.java - src/share/classes/com/sun/xml/internal/ws/server/RuntimeContext.java - src/share/classes/com/sun/xml/internal/ws/server/RuntimeEndpointInfo.java - src/share/classes/com/sun/xml/internal/ws/server/TargetFinderImpl.java - src/share/classes/com/sun/xml/internal/ws/server/Tie.java - src/share/classes/com/sun/xml/internal/ws/server/XMLEPTFactoryImpl.java - src/share/classes/com/sun/xml/internal/ws/server/provider/ProviderModel.java - src/share/classes/com/sun/xml/internal/ws/server/provider/ProviderPeptTie.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/Binding.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/ClientTransportFactory.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/ClientTransportFactoryTypes.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/InternalSoapEncoder.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/Invoker.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/MessageContext.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/MtomCallback.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/RuntimeEndpointInfo.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/SOAPMessageContext.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/StubBase.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/SystemHandlerDelegate.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/SystemHandlerDelegateFactory.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/Tie.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/WSConnection.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/WebServiceContext.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/package-info.java - src/share/classes/com/sun/xml/internal/ws/streaming/XMLStreamReaderFactory.java - src/share/classes/com/sun/xml/internal/ws/streaming/XMLStreamWriterFactory.java - src/share/classes/com/sun/xml/internal/ws/transport/WSConnectionImpl.java - src/share/classes/com/sun/xml/internal/ws/transport/http/client/HttpClientTransportFactory.java - src/share/classes/com/sun/xml/internal/ws/transport/http/server/EndpointDocInfo.java - src/share/classes/com/sun/xml/internal/ws/transport/http/server/EndpointEntityResolver.java - src/share/classes/com/sun/xml/internal/ws/transport/http/server/WebServiceContextImpl.java - src/share/classes/com/sun/xml/internal/ws/transport/local/LocalMessage.java - src/share/classes/com/sun/xml/internal/ws/transport/local/client/LocalClientTransport.java - src/share/classes/com/sun/xml/internal/ws/transport/local/client/LocalClientTransportFactory.java - src/share/classes/com/sun/xml/internal/ws/transport/local/server/LocalConnectionImpl.java - src/share/classes/com/sun/xml/internal/ws/transport/local/server/LocalWSContextImpl.java - src/share/classes/com/sun/xml/internal/ws/util/Base64Util.java - src/share/classes/com/sun/xml/internal/ws/util/MessageInfoUtil.java - src/share/classes/com/sun/xml/internal/ws/util/NullIterator.java - src/share/classes/com/sun/xml/internal/ws/util/SOAPConnectionUtil.java - src/share/classes/com/sun/xml/internal/ws/util/SOAPUtil.java - src/share/classes/com/sun/xml/internal/ws/util/SunStAXReflection.java - src/share/classes/com/sun/xml/internal/ws/util/XMLConnectionUtil.java - src/share/classes/com/sun/xml/internal/ws/util/xml/XMLStreamReaderToContentHandler.java - src/share/classes/com/sun/xml/internal/ws/wsdl/WSDLContext.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/Binding.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/BindingOperation.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/Message.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/Part.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/Port.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/PortType.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/PortTypeOperation.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/Service.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/WSDLDocument.java - src/share/classes/com/sun/xml/internal/ws/wsdl/writer/WSDLOutputResolver.java - src/share/classes/com/sun/xml/internal/xsom/impl/util/ConcatIterator.java - src/share/classes/com/sun/xml/internal/xsom/impl/util/FilterIterator.java Changeset: 1626ba49a98e Author: xdono Date: 2009-05-07 12:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/1626ba49a98e Merge Changeset: af4d62e31af8 Author: ohair Date: 2009-05-15 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/af4d62e31af8 Merge Changeset: 3b054db3e277 Author: ohair Date: 2009-05-19 17:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/3b054db3e277 6843041: Remove duplicate README files in repositories (make/README) Reviewed-by: robilad - make/README Changeset: aeabf802f2a1 Author: xdono Date: 2009-06-11 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/aeabf802f2a1 Added tag jdk7-b60 for changeset 3b054db3e277 ! .hgtags From john.coomes at sun.com Thu Jun 11 21:11:21 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 12 Jun 2009 04:11:21 +0000 Subject: hg: jdk7/hotspot/jdk: 31 new changesets Message-ID: <20090612041805.8152FE408@hg.openjdk.java.net> Changeset: 9ad7e6462145 Author: aph Date: 2009-04-17 15:56 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9ad7e6462145 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair Contributed-by: Andrew Haley ! make/common/Defs-linux.gmk ! make/sun/awt/mawt.gmk Changeset: 5ceb9eb621d1 Author: chegar Date: 2009-05-07 17:02 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5ceb9eb621d1 6837982: SCTP API docs not being generated. Summary: Update docs makefile to build javadoc for the com.sun.nio.sctp package. Reviewed-by: jccollet, alanb, weijun ! make/docs/Makefile Changeset: 86d2541a9ba2 Author: xdono Date: 2009-05-07 10:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/86d2541a9ba2 Merge - src/share/native/java/util/zip/ZipEntry.c - src/share/native/sun/java2d/pipe/RenderBuffer.c - test/com/sun/awt/Translucency/TranslucentJAppletTest/TranslucentJAppletTest.java - test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TSFrame.java - test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.form - test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java Changeset: 39d93fb6926c Author: xdono Date: 2009-05-07 12:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/39d93fb6926c Merge Changeset: 6ca1c622dd6e Author: ohair Date: 2009-05-07 18:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6ca1c622dd6e 6835803: Type error in src/windows/native/sun/windows/awt_Window.cpp Reviewed-by: prr ! src/windows/native/sun/windows/awt_Window.cpp Changeset: 7ec6857812d2 Author: ohair Date: 2009-05-08 11:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7ec6857812d2 Merge ! src/windows/native/sun/windows/awt_Window.cpp Changeset: 9eeeeee69368 Author: ohair Date: 2009-05-15 13:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9eeeeee69368 6841873: Fix windows redist default location for msvc runtime dlls Reviewed-by: tbell ! make/common/shared/Defs-windows.gmk Changeset: 97064d73976f Author: ohair Date: 2009-05-15 13:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/97064d73976f Merge Changeset: fdbc48164a8b Author: ohair Date: 2009-05-18 10:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/fdbc48164a8b 6842023: Improve test reliability, Increase timeout factor on jtreg tests, etc. Reviewed-by: tbell ! make/jprt.properties ! test/Makefile ! test/java/lang/ThreadGroup/NullThreadName.java ! test/java/util/ResourceBundle/RestrictedBundleTest.java ! test/java/util/WeakHashMap/GCDuringIteration.java Changeset: c06d30bd8c69 Author: andrew Date: 2009-05-21 16:29 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c06d30bd8c69 6841728: Make building the Nimbus L 'n' F optional (100054) Summary: Add DISABLE_NIMBUS variable to prevent Nimbus subdirs being built Reviewed-by: mr, ohair ! make/common/shared/Sanity.gmk ! make/javax/swing/plaf/Makefile ! make/tools/Makefile Changeset: 238591c80bc5 Author: aph Date: 2009-05-21 18:41 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/238591c80bc5 6839133: lcms 1.18 update breaks ICC_ProfileRGB Tests Reviewed-by: avu, prr ! src/share/native/sun/java2d/cmm/lcms/LCMS.c Changeset: f62f7fcc9965 Author: art Date: 2009-05-15 15:40 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f62f7fcc9965 6678385: Random java.lang.StackOverflowError from various JDKs Reviewed-by: stayer ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/MotifDnDConstants.java ! src/solaris/classes/sun/awt/X11/MotifDnDDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/MotifDnDDropTargetProtocol.java ! src/solaris/classes/sun/awt/X11/WindowPropertyGetter.java ! src/solaris/classes/sun/awt/X11/XAWTXSettings.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java ! src/solaris/classes/sun/awt/X11/XDnDDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/XDnDDropTargetProtocol.java ! src/solaris/classes/sun/awt/X11/XDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/XDropTargetRegistry.java ! src/solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java + src/solaris/classes/sun/awt/X11/XErrorHandler.java ! src/solaris/classes/sun/awt/X11/XProtocol.java ! src/solaris/classes/sun/awt/X11/XQueryTree.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XTranslateCoordinates.java ! src/solaris/classes/sun/awt/X11/XWM.java ! src/solaris/classes/sun/awt/X11/XlibUtil.java ! src/solaris/classes/sun/awt/X11/XlibWrapper.java ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_InputMethod.c ! src/solaris/native/sun/awt/awt_MToolkit.c ! src/solaris/native/sun/xawt/XToolkit.c ! src/solaris/native/sun/xawt/XlibWrapper.c Changeset: 019fd945ebc5 Author: yan Date: 2009-05-18 12:39 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/019fd945ebc5 6834525: PIT: RowToleranceTransitivityTest test fail with crash on rhel4 x86 and rhel 5x86 Summary: do not try to use released XKB resources Reviewed-by: art ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/keysym2ucs.h Changeset: 875524a2b311 Author: anthony Date: 2009-05-19 12:15 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/875524a2b311 6811219: Deadlock java AWT in XWarningWindow Summary: The locking scheme has been re-architected, the code slightly refactored. Reviewed-by: art, dcherepanov ! src/solaris/classes/sun/awt/X11/XWarningWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java Changeset: 5eaa495dc929 Author: anthony Date: 2009-05-19 14:14 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5eaa495dc929 6812298: Dynamic GraphicsConfig changes don't work on X11 platforms Summary: The peer gets recreated if the visual of the new GC differs from the previous one Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/sun/awt/NullComponentPeer.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java Changeset: ac08fa3d6c98 Author: anthony Date: 2009-05-19 14:43 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ac08fa3d6c98 6833444: _BOOTDIR1/_BOOTDIR2 on MS Windows should be consistent with other platforms Summary: Added optional _BOOTDIR3 that provides the J: path for the BOOTDIR on Windows Reviewed-by: ohair, xdono ! make/common/Sanity.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Sanity.gmk Changeset: 315f315b8d3c Author: anthony Date: 2009-05-19 17:03 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/315f315b8d3c 6839999: Cumulative fix for 6762511 and 6838003 Summary: Adds support for ARGB and ABGR X11 surfaces. Reviewed-by: art, yan ! src/solaris/classes/sun/awt/X11/generator/sizes.64-solaris-i386 ! src/solaris/classes/sun/awt/X11/generator/xlibtypes.txt ! src/solaris/classes/sun/awt/X11GraphicsConfig.java ! src/solaris/classes/sun/java2d/x11/X11PMBlitBgLoops.java ! src/solaris/classes/sun/java2d/x11/X11PMBlitLoops.java ! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java ! src/solaris/native/sun/awt/X11Color.c ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_p.h Changeset: b33466bb2fed Author: art Date: 2009-05-21 12:29 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b33466bb2fed 6794764: Translucent windows are completely repainted on every paint event, on Windows 6719382: Printing of AWT components on windows is not working 6726866: Repainting artifacts when resizing or dragging JInternalFrames in non-opaque toplevel 6683775: Painting artifacts is seen when panel is made setOpaque(false) for a translucent window Reviewed-by: anthony, tdv, alexp ! src/share/classes/java/awt/GraphicsConfiguration.java ! src/share/classes/java/awt/GraphicsDevice.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/peer/WindowPeer.java ! src/share/classes/javax/swing/DefaultDesktopManager.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/EmbeddedFrame.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/windows/classes/sun/awt/windows/TranslucentWindowPainter.java ! src/windows/classes/sun/awt/windows/WCanvasPeer.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WObjectPeer.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_Window.cpp ! src/windows/native/sun/windows/awt_Window.h + test/javax/swing/JComponent/6683775/bug6683775.java + test/javax/swing/JInternalFrame/6726866/bug6726866.html + test/javax/swing/JInternalFrame/6726866/bug6726866.java Changeset: 97ece6b3d84f Author: ant Date: 2009-05-21 15:04 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/97ece6b3d84f 6833019: KeyboardFocusManager.getCurrentKeyboardFocusManager() throws unspecified HeadlessException Reviewed-by: art ! src/share/classes/sun/awt/HeadlessToolkit.java Changeset: cfe73335a065 Author: dav Date: 2009-05-22 16:09 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/cfe73335a065 6799099: All automatic regression tests that create Robot fail on X11 Reviewed-by: art, ant ! make/sun/xawt/mapfile-vers ! src/share/classes/java/awt/Robot.java ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/java/awt/event/MouseEvent.java ! src/share/classes/java/awt/peer/RobotPeer.java ! src/share/classes/sun/awt/SunToolkit.java ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XDragSourceContextPeer.java ! src/solaris/classes/sun/awt/X11/XRobotPeer.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/classes/sun/awt/motif/MToolkit.java ! src/solaris/native/sun/awt/awt_MToolkit.c ! src/solaris/native/sun/awt/awt_Robot.c ! src/solaris/native/sun/xawt/XToolkit.c ! src/windows/classes/sun/awt/windows/WRobotPeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/native/sun/windows/awt_Robot.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 52493efeb137 Author: dav Date: 2009-05-25 18:22 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/52493efeb137 6844750: Solaris build failed after 6799099 Reviewed-by: yan ! src/solaris/native/sun/xawt/XToolkit.c Changeset: 7da360c3baf6 Author: yan Date: 2009-06-01 01:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7da360c3baf6 Merge Changeset: f29cd35647b1 Author: peytoia Date: 2009-05-12 15:21 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f29cd35647b1 6834474: (tz) Support tzdata2009g Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: 62bfe2674e48 Author: yan Date: 2009-05-14 00:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/62bfe2674e48 Merge - src/share/native/sun/java2d/pipe/RenderBuffer.c Changeset: 455b357442c7 Author: peterz Date: 2009-05-14 18:12 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/455b357442c7 6741426: ClassCastException from ComboBoxEditableState (Nimbus LaF) in JDK 1.6.0_10 RC Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/nimbus/skin.laf + test/javax/swing/plaf/nimbus/Test6741426.java Changeset: af491a9b7c1d Author: peterz Date: 2009-05-15 12:06 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/af491a9b7c1d 6827581: Contextkey does not work in Nimbus Reviewed-by: rupashka ! src/share/classes/sun/swing/plaf/GTKKeybindings.java ! src/share/classes/sun/swing/plaf/WindowsKeybindings.java Changeset: 993a5f0fe2e0 Author: rupashka Date: 2009-05-15 17:26 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/993a5f0fe2e0 6713352: Deadlock in JFileChooser with synchronized custom FileSystemView Reviewed-by: malenkov, peterz ! src/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java ! src/share/classes/sun/awt/shell/ShellFolder.java ! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java + test/javax/swing/JFileChooser/6713352/bug6713352.java Changeset: 019908df0313 Author: rupashka Date: 2009-05-28 18:11 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/019908df0313 6845805: Test for CR 6713352 is failed under Linux Reviewed-by: malenkov ! test/javax/swing/JFileChooser/6713352/bug6713352.java Changeset: 951ecbad4068 Author: yan Date: 2009-06-01 01:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/951ecbad4068 Merge Changeset: 0c3ef2d612a4 Author: yan Date: 2009-06-09 23:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0c3ef2d612a4 Merge ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity.gmk ! src/windows/native/sun/windows/awt_Window.cpp Changeset: f72c0dc047b9 Author: xdono Date: 2009-06-11 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f72c0dc047b9 Added tag jdk7-b60 for changeset 0c3ef2d612a4 ! .hgtags From john.coomes at sun.com Thu Jun 11 21:31:06 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 12 Jun 2009 04:31:06 +0000 Subject: hg: jdk7/hotspot/langtools: 8 new changesets Message-ID: <20090612043121.2C38EE40D@hg.openjdk.java.net> Changeset: 4b72c2556789 Author: aph Date: 2009-04-17 15:56 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/4b72c2556789 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair Contributed-by: Andrew Haley ! make/Makefile Changeset: 321854d9ab19 Author: aph Date: 2009-04-20 19:01 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/321854d9ab19 6832141: Bug 100045 - Fix for 100028 breaks debug info for class files Summary: Correct fallout from 100028 patch Reviewed-by: ohair Contributed-by: Andrew Haley ! make/Makefile Changeset: f3d27f02683c Author: aph Date: 2009-05-06 18:04 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/f3d27f02683c 6837665: Deal with windows ant problem where commas in -D options do not work Summary: Rewrite to avoid commas in -D options Reviewed-by: ohair ! make/Makefile ! make/build.xml Changeset: 43a781cc6473 Author: xdono Date: 2009-05-07 10:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/43a781cc6473 Merge Changeset: 846944dd48a4 Author: xdono Date: 2009-05-07 12:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/846944dd48a4 Merge Changeset: 65f2ee956fb9 Author: ohair Date: 2009-05-15 13:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/65f2ee956fb9 Merge Changeset: 5cdce469ea2a Author: ohair Date: 2009-05-19 17:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/5cdce469ea2a 6843041: Remove duplicate README files in repositories (make/README) Reviewed-by: robilad ! README - make/README Changeset: 522520757dd3 Author: xdono Date: 2009-06-11 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/522520757dd3 Added tag jdk7-b60 for changeset 5cdce469ea2a ! .hgtags From gbenson at redhat.com Fri Jun 12 02:00:58 2009 From: gbenson at redhat.com (Gary Benson) Date: Fri, 12 Jun 2009 10:00:58 +0100 Subject: When might a CodeBuffer be moved? In-Reply-To: <64618985-C3CD-4C51-BDA9-F64BD61DB780@sun.com> References: <20090610135500.GB26952@redhat.com> <1AD018C8-2B59-4091-8BC1-545D65EC1445@sun.com> <20090611091857.GB3238@redhat.com> <64618985-C3CD-4C51-BDA9-F64BD61DB780@sun.com> Message-ID: <20090612090057.GA3164@redhat.com> The only place I explicitly create one is in Shark, I think. Shark compiles the method into it, then passes it to ciEnv::register_method along with everything else. After that, as I understand it, the code is relocated into a more permanent area, and the original CodeBuffer gets freed automagically when the frame it's in exits (it's a StackObj, right?) Cheers, Gary Tom Rodriguez wrote: > You wouldn't want to just build a CodeBuffer and keep it around. > Normally we use BufferBlobs for any piece of code that we want to > generate but which doesn't need to be relocatable. The interpreter > for instance is constructed this way as are a lot of helper snippers > of various kinds. You wouldn't want to just build a CodeBuffer and > keep it around. The preferred way would be the make a BufferBlob > and then build a CodeBuffer on top of it to use for code generation. > You'd just drop the CodeBuffer onces you were done with code > generation and build a new one if you needed it. > > tom > > On Jun 11, 2009, at 2:18 AM, Gary Benson wrote: > > Oh, that's excellent news. Now to figure out if I can use it! ;) > > > > Cheers, > > Gary > > > > Tom Rodriguez wrote: > > > CodeBlobs are never moved automatically by anything. > > > CodeBuffers have support for resizing the code generation buffer > > > by moving the instructions from one CodeBlob to a new larger one > > > but you have to ask for that using > > > maybe_expand_to_ensure_remaining. nmethod can be reclaimed by > > > the sweeper once they are no longer referenced as a result of > > > being made not entrant or zombie. > > > > > > tom > > > > > > On Jun 10, 2009, at 6:55 AM, Gary Benson wrote: > > > > Hi all, > > > > > > > > I know CodeBuffers aren't moved by the garbage collector, but > > > > can they move at all? I remember someone (Steve Goldman?) > > > > telling me about a code compactor once, but can't remember the > > > > details. Can a code buffer move at any safepoint? > > > > > > > > Cheers, > > > > Gary > > > > > > > > -- > > > > http://gbenson.net/ From Thomas.Rodriguez at Sun.COM Fri Jun 12 08:49:59 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 12 Jun 2009 08:49:59 -0700 Subject: When might a CodeBuffer be moved? In-Reply-To: <20090612090057.GA3164@redhat.com> References: <20090610135500.GB26952@redhat.com> <1AD018C8-2B59-4091-8BC1-545D65EC1445@sun.com> <20090611091857.GB3238@redhat.com> <64618985-C3CD-4C51-BDA9-F64BD61DB780@sun.com> <20090612090057.GA3164@redhat.com> Message-ID: <407F060F-B179-4EAE-B92B-387B3560775D@sun.com> Yes. That's all correct. I was just suggesting that if you were going do any trickery that relied on a code blob not needing to be relocatable that you explicitly use a BufferBlob instead of hanging onto a CodeBuffer. tom On Jun 12, 2009, at 2:00 AM, Gary Benson wrote: > The only place I explicitly create one is in Shark, I think. Shark > compiles the method into it, then passes it to ciEnv::register_method > along with everything else. After that, as I understand it, the code > is relocated into a more permanent area, and the original CodeBuffer > gets freed automagically when the frame it's in exits (it's a > StackObj, right?) > > Cheers, > Gary > > Tom Rodriguez wrote: >> You wouldn't want to just build a CodeBuffer and keep it around. >> Normally we use BufferBlobs for any piece of code that we want to >> generate but which doesn't need to be relocatable. The interpreter >> for instance is constructed this way as are a lot of helper snippers >> of various kinds. You wouldn't want to just build a CodeBuffer and >> keep it around. The preferred way would be the make a BufferBlob >> and then build a CodeBuffer on top of it to use for code generation. >> You'd just drop the CodeBuffer onces you were done with code >> generation and build a new one if you needed it. >> >> tom >> >> On Jun 11, 2009, at 2:18 AM, Gary Benson wrote: >>> Oh, that's excellent news. Now to figure out if I can use it! ;) >>> >>> Cheers, >>> Gary >>> >>> Tom Rodriguez wrote: >>>> CodeBlobs are never moved automatically by anything. >>>> CodeBuffers have support for resizing the code generation buffer >>>> by moving the instructions from one CodeBlob to a new larger one >>>> but you have to ask for that using >>>> maybe_expand_to_ensure_remaining. nmethod can be reclaimed by >>>> the sweeper once they are no longer referenced as a result of >>>> being made not entrant or zombie. >>>> >>>> tom >>>> >>>> On Jun 10, 2009, at 6:55 AM, Gary Benson wrote: >>>>> Hi all, >>>>> >>>>> I know CodeBuffers aren't moved by the garbage collector, but >>>>> can they move at all? I remember someone (Steve Goldman?) >>>>> telling me about a code compactor once, but can't remember the >>>>> details. Can a code buffer move at any safepoint? >>>>> >>>>> Cheers, >>>>> Gary >>>>> >>>>> -- >>>>> http://gbenson.net/ From marioml at ices.utexas.edu Mon Jun 15 16:19:18 2009 From: marioml at ices.utexas.edu (Mario Mendez-Lojo) Date: Mon, 15 Jun 2009 18:19:18 -0500 Subject: Profiling the execution in the VM Message-ID: <4A36D6F6.3080809@ices.utexas.edu> Hi guys, First of all, this is a generic question so please redirect me to the right list (I just couldn't find one) if you consider my post off-topic. Our project requires of detailed profiling (memory, cpu) of a set of Java applications. The information we get out of -Xprof is not enough. We have been using JProfiler, and are quite happy with it. But we wonder if there is a better, or at least open source, alternative. Can you recommend any other good profiler? Thank you very much, Mario Mendez-Lojo postdoc, ICES dpt, UT Austin, TX From xerxes at zafena.se Tue Jun 16 01:03:20 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Tue, 16 Jun 2009 10:03:20 +0200 Subject: Profiling the execution in the VM In-Reply-To: <4A36D6F6.3080809@ices.utexas.edu> References: <4A36D6F6.3080809@ices.utexas.edu> Message-ID: <4A3751C8.9040902@zafena.se> Mario Mendez-Lojo skrev: > Hi guys, > > First of all, this is a generic question so please redirect me to the > right list (I just couldn't find one) if you consider my post off-topic. > > Our project requires of detailed profiling (memory, cpu) of a set of > Java applications. The information we get out of -Xprof is not enough. > We have been using JProfiler, and are quite happy with it. But we > wonder if there is a better, or at least open source, alternative. Can > you recommend any other good profiler? > > Thank you very much, > Mario Mendez-Lojo > postdoc, > ICES dpt, UT Austin, TX Four free software profiling alternatives pops into my mind that might solve your needs: VisualVM https://visualvm.dev.java.net/ VisualVM are quite good for regular java (cpu, memory, threads) program profiling it can attach to already running JVM's and are a breeze to use. This are the same profiler used in NetBeans. OProfile http://oprofile.sourceforge.net If you want a system wide profiler then use oprofile. It can display detailed information of the JVM, system library and the kernel calls without having to modify the JVM in any special way. If you want even more detail of what the JVM are doing then you can use gprof (part of gnu binutils) or systemtap, both requires that the JVM are modified in order to insert the profiling hooks. Gprof http://sourceware.org/binutils/docs-2.19/gprof/index.html (part of gnu binutils) http://mail.openjdk.java.net/pipermail/zero-dev/2009-February/000028.html - example of information gathered with gprof Systemtap http://sourceware.org/systemtap/ Systemtap hooks can easily be inserted into the OpenJDK hotspot by building it using the Icedtea infrastructure and adding --enable-systemtap to icedtea's configure. http://blog.fuseyism.com/index.php/2009/06/01/icedtea-110-released/ http://icedtea.classpath.org/wiki/Main_Page Cheers Xerxes From Christian.Thalinger at Sun.COM Tue Jun 16 04:52:51 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 16 Jun 2009 13:52:51 +0200 Subject: 64-bit constants in source code Message-ID: <4A378793.6030605@Sun.COM> Hi! Yesterday I noticed that there are compiler specific CONST64 macros which emit the correct syntax for 64-bit constants for the various compilers HotSpot supports. Is it recommended/required to use: CONST64(0x00000000FFFFFFFF) instead of: 0x00000000FFFFFFFFL (I commited some code lately that uses the later.) -- Christian From David.Holmes at Sun.COM Tue Jun 16 05:13:27 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Tue, 16 Jun 2009 22:13:27 +1000 Subject: 64-bit constants in source code In-Reply-To: <4A378793.6030605@Sun.COM> References: <4A378793.6030605@Sun.COM> Message-ID: <4A378C67.3040707@sun.com> Christian, According to the definition of the macro you should have used a LL suffix not just L. The macros deal with compiler specific mechanisms for defining 64-bit constants. Looks like gcc and SS have converged these days, but Visual Studio is quite different: globalDefinitions_gcc.hpp:#define CONST64(x) (x ## LL) globalDefinitions_gcc.hpp:#define UCONST64(x) (x ## ULL) globalDefinitions_sparcWorks.hpp:#define CONST64(x) (x ## LL) globalDefinitions_sparcWorks.hpp:#define UCONST64(x) (x ## ULL) globalDefinitions_visCPP.hpp:#define CONST64(x) (x ## i64) globalDefinitions_visCPP.hpp:#define UCONST64(x) ((uint64_t)CONST64(x)) Cheers, David Holmes Christian Thalinger said the following on 06/16/09 21:52: > Hi! > > Yesterday I noticed that there are compiler specific CONST64 macros > which emit the correct syntax for 64-bit constants for the various > compilers HotSpot supports. > > Is it recommended/required to use: > > CONST64(0x00000000FFFFFFFF) > > instead of: > > 0x00000000FFFFFFFFL > > (I commited some code lately that uses the later.) > > -- Christian From Christian.Thalinger at Sun.COM Tue Jun 16 10:37:02 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 16 Jun 2009 19:37:02 +0200 Subject: 64-bit constants in source code In-Reply-To: <4A378C67.3040707@sun.com> References: <4A378793.6030605@Sun.COM> <4A378C67.3040707@sun.com> Message-ID: <4A37D83E.8000503@Sun.COM> David Holmes - Sun Microsystems wrote: > Christian, > > According to the definition of the macro you should have used a LL > suffix not just L. Right. I noticed that because of a picky GCC. > > The macros deal with compiler specific mechanisms for defining 64-bit > constants. Looks like gcc and SS have converged these days, but Visual > Studio is quite different: > > globalDefinitions_gcc.hpp:#define CONST64(x) (x ## LL) > globalDefinitions_gcc.hpp:#define UCONST64(x) (x ## ULL) > globalDefinitions_sparcWorks.hpp:#define CONST64(x) (x ## LL) > globalDefinitions_sparcWorks.hpp:#define UCONST64(x) (x ## ULL) > globalDefinitions_visCPP.hpp:#define CONST64(x) (x ## i64) > globalDefinitions_visCPP.hpp:#define UCONST64(x) ((uint64_t)CONST64(x)) I think I change my code to use them. -- Christian From erik.trimble at sun.com Tue Jun 16 19:43:00 2009 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Wed, 17 Jun 2009 02:43:00 +0000 Subject: hg: jdk7/hotspot/hotspot: 7 new changesets Message-ID: <20090617024317.82A2CE81E@hg.openjdk.java.net> Changeset: aa0c48844632 Author: vasya Date: 2009-05-14 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/aa0c48844632 Added tag jdk7-b59 for changeset c55be0c7bd32 ! .hgtags Changeset: f5ee65f94d9a Author: ohair Date: 2009-05-15 13:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f5ee65f94d9a Merge - make/jprt.config ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make Changeset: a77eddcd510c Author: ohair Date: 2009-05-19 17:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a77eddcd510c 6843041: Remove duplicate README files in repositories (make/README) Reviewed-by: robilad - make/README Changeset: cf4f487696ba Author: trims Date: 2009-06-11 17:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/cf4f487696ba Merge Changeset: 08f86fa55a31 Author: trims Date: 2009-06-11 17:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/08f86fa55a31 6850551: Bump the HS16 build number to 04 Summary: Update the HS16 build number to 04 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 86092459c54d Author: xdono Date: 2009-06-11 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/86092459c54d Added tag jdk7-b60 for changeset a77eddcd510c ! .hgtags Changeset: 27b728fd1281 Author: trims Date: 2009-06-11 21:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/27b728fd1281 Merge From marioml at ices.utexas.edu Wed Jun 17 11:19:13 2009 From: marioml at ices.utexas.edu (Mario Mendez-Lojo) Date: Wed, 17 Jun 2009 13:19:13 -0500 Subject: programmatic query of time spent doing GC Message-ID: <4A3933A1.6030300@ices.utexas.edu> First of all, thank you all for your amazing response to previous questions! I have a question: I want to programmatically measure the time spent by the JVM in the *application* I'm running - i.e., I would like to substract any time spent in garbage collection. I already maximized the heap in order to avoid GC, but there is still some GC activity. Is there any programmatic way of figuring out what that time is? I can always verbose the GC statistics, and do the calculations manually, but is obviously more painful. From John.Coomes at sun.com Wed Jun 17 11:29:44 2009 From: John.Coomes at sun.com (John Coomes) Date: Wed, 17 Jun 2009 11:29:44 -0700 Subject: programmatic query of time spent doing GC In-Reply-To: <4A3933A1.6030300@ices.utexas.edu> References: <4A3933A1.6030300@ices.utexas.edu> Message-ID: <19001.13848.353808.742533@sun.com> Mario Mendez-Lojo (marioml at ices.utexas.edu) wrote: > First of all, thank you all for your amazing response to previous questions! > > I have a question: I want to programmatically measure the time spent by the JVM > in the *application* I'm running - i.e., I would like to substract any time > spent in garbage collection. I already maximized the heap in order to avoid GC, > but there is still some GC activity. > > Is there any programmatic way of figuring out what that time is? I can always > verbose the GC statistics, and do the calculations manually, but is obviously > more painful. There is java.lang.management.GarbageCollectorMXBean: http://java.sun.com/javase/6/docs/api/java/lang/management/GarbageCollectorMXBean.html -John From Dalibor.Topic at Sun.COM Wed Jun 17 21:12:50 2009 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Thu, 18 Jun 2009 06:12:50 +0200 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <4A2F1E13.707@sun.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> <17c6771e0906081005w14655c3w58d6cecee6eed013@mail.gmail.com> <4A2D996B.6070206@sun.com> <17c6771e0906090233hd16cecah7dea33a817ff23cc@mail.gmail.com> <4A2E40E8.3050606@sun.com> <1ccfd1c10906091804j7c379f0by937829a70c60c714@mail.gmail.com> <4A2F1E13.707@sun.com> Message-ID: <4A39BEC2.4050706@sun.com> Paul Hohensee wrote: > Excellent idea. :) > > Paul > > Martin Buchholz wrote: >> Paul, >> Thanks for the clear explanation. >> >> Given this, I'm thinking we lobby Joe Darcy >> to use a *copy* of hotspot 14 stable >> as the hotspot to use with OpenJDK6. >> Which can then evolve with community input. >> Andrew can do the first commit. I agree. The hsx team can easily keep the gcc version they use stable, so they don't need to introduce changes to make hsx code work with latest gcc releases. OpenJDK 6, otoh, is used in distributions that ship bleeding edge gccs, so it needs to keep evolving along with gcc, which implies two different drivers, and that's a good reason to copy and go. In order to avoid accumulating gcc patchlets monotonously in OpenJDK 6 clone of hsx, such fixes should also be submitted to the hotspot team, where they apply to the in development version of hotspot. cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin H?ring From gnu_andrew at member.fsf.org Thu Jun 18 07:10:25 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 18 Jun 2009 15:10:25 +0100 Subject: Request for approval: Backport of 6781583 to hs14/OpenJDK6 In-Reply-To: <4A39BEC2.4050706@sun.com> References: <17c6771e0906081004l32817c24tea4729b9420900c5@mail.gmail.com> <17c6771e0906081005w14655c3w58d6cecee6eed013@mail.gmail.com> <4A2D996B.6070206@sun.com> <17c6771e0906090233hd16cecah7dea33a817ff23cc@mail.gmail.com> <4A2E40E8.3050606@sun.com> <1ccfd1c10906091804j7c379f0by937829a70c60c714@mail.gmail.com> <4A2F1E13.707@sun.com> <4A39BEC2.4050706@sun.com> Message-ID: <17c6771e0906180710v5ea30dd8qe8b09f684cb78dc7@mail.gmail.com> 2009/6/18 Dalibor Topic : > Paul Hohensee wrote: >> Excellent idea. :) >> >> Paul >> >> Martin Buchholz wrote: >>> Paul, >>> Thanks for the clear explanation. >>> >>> Given this, I'm thinking we lobby Joe Darcy >>> to use a *copy* of hotspot 14 stable >>> as the hotspot to use with OpenJDK6. >>> Which can then evolve with community input. >>> Andrew can do the first commit. > > I agree. The hsx team can easily keep the gcc version they use > stable, so they don't need to introduce changes to make hsx code > work with latest gcc releases. OpenJDK 6, otoh, is used in > distributions that ship bleeding edge gccs, so it needs to keep > evolving along with gcc, which implies two different drivers, and > that's a good reason to copy and go. > I wouldn't call 4.3 'bleeding edge'. it's over a year since it was released. Heck, even Debian has it (though I guess it's not in RHEL). No one has yet adequately explained why we now have a 'read only' HotSpot repository. This isn't about the HotSpot team wanting to keep using an old version of gcc - this patch is a backported from the HotSpot tree. > In order to avoid accumulating gcc patchlets monotonously in > OpenJDK 6 clone of hsx, such fixes should also be submitted > to the hotspot team, where they apply to the in development > version of hotspot. > Well, yes. Indeed I'd expect them to be applied to the HotSpot tree *first* and then backported to the *stable* OpenJDK6 tree as appropriate. Speaking of which, can we have an HotSpot tree we can actually *commit to* sometime soon? > cheers, > dalibor topic > -- > ******************************************************************* > Dalibor Topic ? ? ? ? ? ? ? ? ? Tel: (+49 40) 23 646 738 > Java F/OSS Ambassador ? ? ? ? ? AIM: robiladonaim > Sun Microsystems GmbH ? ? ? ? ? Mobile: (+49 177) 2664 192 > Nagelsweg 55 ? ? ? ? ? ? ? ? ? ?http://openjdk.java.net > D-20097 Hamburg ? ? ? ? ? ? ? ? mailto:Dalibor.Topic at sun.com > Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten > Amtsgericht M?nchen: HRB 161028 > Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel > Vorsitzender des Aufsichtsrates: Martin H?ring > > > Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From jon.masamitsu at sun.com Thu Jun 18 20:27:51 2009 From: jon.masamitsu at sun.com (jon.masamitsu at sun.com) Date: Fri, 19 Jun 2009 03:27:51 +0000 Subject: hg: jdk7/hotspot/hotspot: 5 new changesets Message-ID: <20090619032801.32CFBEA50@hg.openjdk.java.net> Changeset: 821269eca479 Author: ysr Date: 2009-06-11 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/821269eca479 6820167: GCALotAtAllSafepoints + FullGCALot(ScavengeALot) options crash JVM Summary: Short-circuit gc-a-lot attempts by non-JavaThreads; SkipGCALot c'tor to elide re-entrant gc-a-lot attempts. Reviewed-by: apetrusenko, jcoomes, jmasa, kamg ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/runtime/interfaceSupport.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmThread.cpp Changeset: d44bdab1c03d Author: johnc Date: 2009-06-11 17:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d44bdab1c03d 6843694: G1: assert(index < _vs.committed_size(),"bad index"), g1BlockOffsetTable.inline.hpp:55 Summary: For heaps larger than 32Gb, the number of heap regions overflows the data type used to hold the region index in the SparsePRT structure. Changed the region indexes, card indexes, and RSet hash table buckets to ints and added some size overflow guarantees. Reviewed-by: ysr, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: 353ba4575581 Author: jcoomes Date: 2009-06-07 22:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/353ba4575581 6814552: par compact - some compilers fail to optimize bitmap code Reviewed-by: tonyp, iveresov, jmasa, ysr ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp Changeset: 6e2afda171db Author: jcoomes Date: 2009-06-11 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6e2afda171db 6849716: BitMap - performance regression introduced with G1 Summary: make verification code visible only in debug builds Reviewed-by: iveresov, ysr, johnc, apetrusenko, tonyp ! src/share/vm/includeDB_compiler1 ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/bitMap.hpp ! src/share/vm/utilities/bitMap.inline.hpp ! src/share/vm/utilities/macros.hpp Changeset: 3104f76478ee Author: jmasa Date: 2009-06-18 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3104f76478ee Merge From john.coomes at sun.com Thu Jun 18 20:35:49 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Jun 2009 03:35:49 +0000 Subject: hg: jdk7/hotspot: Added tag jdk7-b61 for changeset 472c21584cfd Message-ID: <20090619033549.D7A20EA57@hg.openjdk.java.net> Changeset: 68836ec8bcc7 Author: xdono Date: 2009-06-18 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/68836ec8bcc7 Added tag jdk7-b61 for changeset 472c21584cfd ! .hgtags From john.coomes at sun.com Thu Jun 18 20:40:19 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Jun 2009 03:40:19 +0000 Subject: hg: jdk7/hotspot/corba: Added tag jdk7-b61 for changeset e906b16a12a9 Message-ID: <20090619034020.B9F3FEA5C@hg.openjdk.java.net> Changeset: c73934e09f00 Author: xdono Date: 2009-06-18 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/c73934e09f00 Added tag jdk7-b61 for changeset e906b16a12a9 ! .hgtags From john.coomes at sun.com Thu Jun 18 20:49:45 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Jun 2009 03:49:45 +0000 Subject: hg: jdk7/hotspot/jaxp: Added tag jdk7-b61 for changeset f1ac756616ea Message-ID: <20090619034948.0ADF5EA61@hg.openjdk.java.net> Changeset: db1d07f881a1 Author: xdono Date: 2009-06-18 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/db1d07f881a1 Added tag jdk7-b61 for changeset f1ac756616ea ! .hgtags From john.coomes at sun.com Thu Jun 18 20:54:17 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Jun 2009 03:54:17 +0000 Subject: hg: jdk7/hotspot/jaxws: Added tag jdk7-b61 for changeset aeabf802f2a1 Message-ID: <20090619035419.9EDFFEA68@hg.openjdk.java.net> Changeset: 55681156ec1a Author: xdono Date: 2009-06-18 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/55681156ec1a Added tag jdk7-b61 for changeset aeabf802f2a1 ! .hgtags From john.coomes at sun.com Thu Jun 18 20:58:49 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Jun 2009 03:58:49 +0000 Subject: hg: jdk7/hotspot/jdk: Added tag jdk7-b61 for changeset f72c0dc047b9 Message-ID: <20090619035913.80D85EA6D@hg.openjdk.java.net> Changeset: 03f2ac812821 Author: xdono Date: 2009-06-18 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/03f2ac812821 Added tag jdk7-b61 for changeset f72c0dc047b9 ! .hgtags From john.coomes at sun.com Thu Jun 18 21:12:17 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Jun 2009 04:12:17 +0000 Subject: hg: jdk7/hotspot/langtools: Added tag jdk7-b61 for changeset 522520757dd3 Message-ID: <20090619041219.EB980EA72@hg.openjdk.java.net> Changeset: 950d50e13a9e Author: xdono Date: 2009-06-18 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/950d50e13a9e Added tag jdk7-b61 for changeset 522520757dd3 ! .hgtags From Christian.Thalinger at Sun.COM Tue Jun 23 02:47:59 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 23 Jun 2009 11:47:59 +0200 Subject: not regenerating _precompiled.incl.gch Message-ID: <4A40A4CF.7000404@Sun.COM> Hi! It seems there is a problem updating _precompiled.incl.gch when a header changed. I noticed that already yesterday and right now, just after an update, it didn't get regenerated and so some new declarations were missing. Anyone else seeing this problem? Are we missing Makefile dependencies? -- Christian From gbenson at redhat.com Tue Jun 23 02:59:40 2009 From: gbenson at redhat.com (Gary Benson) Date: Tue, 23 Jun 2009 10:59:40 +0100 Subject: not regenerating _precompiled.incl.gch In-Reply-To: <4A40A4CF.7000404@Sun.COM> References: <4A40A4CF.7000404@Sun.COM> Message-ID: <20090623095940.GA3422@redhat.com> Christian Thalinger wrote: > It seems there is a problem updating _precompiled.incl.gch when a > header changed. I noticed that already yesterday and right now, > just after an update, it didn't get regenerated and so some new > declarations were missing. > > Anyone else seeing this problem? Are we missing Makefile > dependencies? Yeah, I've seen this, I've never figured it out though. Cheers, Gary -- http://gbenson.net/ From volker.simonis at gmail.com Tue Jun 23 03:26:02 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 23 Jun 2009 12:26:02 +0200 Subject: not regenerating _precompiled.incl.gch In-Reply-To: <4A40A4CF.7000404@Sun.COM> References: <4A40A4CF.7000404@Sun.COM> Message-ID: Yes, that's real magic. I usually just delete _precompiled.incl.gch if I have the impression something is out of sync... Volker On 6/23/09, Christian Thalinger wrote: > Hi! > > It seems there is a problem updating _precompiled.incl.gch when a header > changed. I noticed that already yesterday and right now, just after an > update, it didn't get regenerated and so some new declarations were missing. > > Anyone else seeing this problem? Are we missing Makefile dependencies? > > -- Christian > From Andrey.Petrusenko at Sun.COM Tue Jun 23 05:44:55 2009 From: Andrey.Petrusenko at Sun.COM (Andrey Petrusenko) Date: Tue, 23 Jun 2009 16:44:55 +0400 Subject: not regenerating _precompiled.incl.gch In-Reply-To: <4A40A4CF.7000404@Sun.COM> References: <4A40A4CF.7000404@Sun.COM> Message-ID: <4A40CE47.7070509@sun.com> It looks like a bug in MakeDeps: when it's in a "diff mode" it does not update nPrecompiledFiles member which is used to put the names of files used to build the .gch into Dependencies file. I will file a bug and investigate it further. Andrey > Hi! > > It seems there is a problem updating _precompiled.incl.gch when a header > changed. I noticed that already yesterday and right now, just after an > update, it didn't get regenerated and so some new declarations were > missing. > > Anyone else seeing this problem? Are we missing Makefile dependencies? > > -- Christian From Christian.Thalinger at Sun.COM Tue Jun 23 06:51:10 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 23 Jun 2009 15:51:10 +0200 Subject: not regenerating _precompiled.incl.gch In-Reply-To: <4A40CE47.7070509@sun.com> References: <4A40A4CF.7000404@Sun.COM> <4A40CE47.7070509@sun.com> Message-ID: <4A40DDCE.2000800@Sun.COM> Andrey Petrusenko wrote: > It looks like a bug in MakeDeps: when it's in a "diff mode" it does not > update nPrecompiledFiles member which is used to put the names of files > used to build the .gch into Dependencies file. I will file a bug and > investigate it further. Thanks Andrey! -- Christian From John.Rose at Sun.COM Tue Jun 23 02:58:03 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 23 Jun 2009 02:58:03 -0700 Subject: not regenerating _precompiled.incl.gch In-Reply-To: <4A40A4CF.7000404@Sun.COM> References: <4A40A4CF.7000404@Sun.COM> Message-ID: <30A449F7-B089-478E-A153-A92215658B62@sun.com> As a workaround to this issue, my build script unconditionally removes the pch files (rm -f $(find ...)). It takes seconds to reconstruct one and in turn that does not force a rebuild of the *.o files. -- John On Jun 23, 2009, at 2:47 AM, Christian Thalinger wrote: > It seems there is a problem updating _precompiled.incl.gch when a > header changed. I noticed that already yesterday and right now, > just after an update, it didn't get regenerated and so some new > declarations were missing. > > Anyone else seeing this problem? Are we missing Makefile > dependencies? From John.Rose at Sun.COM Tue Jun 23 14:42:51 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 23 Jun 2009 14:42:51 -0700 Subject: not regenerating _precompiled.incl.gch In-Reply-To: <4A40A4CF.7000404@Sun.COM> References: <4A40A4CF.7000404@Sun.COM> Message-ID: As a workaround to this issue, my build script unconditionally removes the pch files (rm -f $(find ...)). It takes seconds to reconstruct one and in turn that does not force a rebuild of the *.o files. -- John On Jun 23, 2009, at 2:47 AM, Christian Thalinger wrote: > It seems there is a problem updating _precompiled.incl.gch when a > header changed. I noticed that already yesterday and right now, > just after an update, it didn't get regenerated and so some new > declarations were missing. > > Anyone else seeing this problem? Are we missing Makefile > dependencies? From Jonathan.Gibbons at Sun.COM Tue Jun 23 16:25:38 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 23 Jun 2009 16:25:38 -0700 Subject: javah and LLNI Message-ID: <4A416472.7010100@sun.com> HotSpot folk, JDK javah currently supports an undocumented option for generating heading files in LLNI (low level native interface) mode. Vestiges of the support can be seen in the Usage message, for the -jni switch, which says to generate JNI-style header info (default), without giving any other alternatives. A Google search for LLNI only turns up info from over 10 years ago. I would like to drop support for this feature from the javah tool. Does anyone have any reason why we should not drop it? -- Jon Gibbons From Thomas.Rodriguez at Sun.COM Wed Jun 24 11:59:59 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 24 Jun 2009 11:59:59 -0700 Subject: javah and LLNI In-Reply-To: <4A416472.7010100@sun.com> References: <4A416472.7010100@sun.com> Message-ID: Seems like a fine idea. tom On Jun 23, 2009, at 4:25 PM, Jonathan Gibbons wrote: > HotSpot folk, > > JDK javah currently supports an undocumented option for generating > heading files in LLNI (low level native interface) mode. Vestiges of > the support can be seen in the Usage message, for the -jni switch, > which says to generate JNI-style header info (default), without > giving any other alternatives. > > A Google search for LLNI only turns up info from over 10 years ago. > > I would like to drop support for this feature from the javah tool. > Does anyone have any reason why we should not drop it? > > -- Jon Gibbons From volker.simonis at gmail.com Thu Jun 25 03:06:55 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 25 Jun 2009 12:06:55 +0200 Subject: Could the JIT be started before JVMTI agents are loaded? Message-ID: Hi, we currently have some problems with long startup times due to JVMTI agents loaded with -javaagent. While investigating the problem we realized that the JIT compiler is only started AFTER the agent was loaded and initialized and therefore the whole agent initialization takes place in interpreted mode. Here is the corresponding code from thread.cpp: 3137 // Notify JVMTI agents that VM initialization is complete - nop if no agents. 3138 JvmtiExport::post_vm_initialized(); 3139 3140 Chunk::start_chunk_pool_cleaner_task(); 3141 3142 // initialize compiler(s) 3143 CompileBroker::compilation_init(); Is there any particualr reason that the JIT gets initialized only after the agent initialization or could it be done just as well before? A short test where we placed "CompileBroker::compilation_init()" just before "JvmtiExport::post_vm_initialized()" succeeded with a considerable startup speedup, but we are not sure if this change would be valid in general. Regards, Volker From Daniel.Daugherty at Sun.COM Thu Jun 25 07:55:29 2009 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Thu, 25 Jun 2009 08:55:29 -0600 Subject: Could the JIT be started before JVMTI agents are loaded? In-Reply-To: References: Message-ID: <4A438FE1.2000708@sun.com> The compiler is initialized after JVMTI has posted the VM_INIT event intentionally. The compiler may have to initialize differently depending on the capabilities that were enabled by the JVMTI agent. Dan Volker Simonis wrote: > Hi, > > we currently have some problems with long startup times due to JVMTI > agents loaded with -javaagent. While investigating the problem we > realized that the JIT compiler is only started AFTER the agent was > loaded and initialized and therefore the whole agent initialization > takes place in interpreted mode. Here is the corresponding code from > thread.cpp: > > 3137 // Notify JVMTI agents that VM initialization is complete > - nop if no agents. > 3138 JvmtiExport::post_vm_initialized(); > 3139 > 3140 Chunk::start_chunk_pool_cleaner_task(); > 3141 > 3142 // initialize compiler(s) > 3143 CompileBroker::compilation_init(); > > Is there any particualr reason that the JIT gets initialized only > after the agent initialization or could it be done just as well > before? A short test where we placed > "CompileBroker::compilation_init()" just before > "JvmtiExport::post_vm_initialized()" succeeded with a considerable > startup speedup, but we are not sure if this change would be valid in > general. > > Regards, > Volker > From Alan.Bateman at Sun.COM Thu Jun 25 07:55:19 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 25 Jun 2009 15:55:19 +0100 Subject: Could the JIT be started before JVMTI agents are loaded? In-Reply-To: References: Message-ID: <4A438FD7.4020209@sun.com> Volker Simonis wrote: > Hi, > > we currently have some problems with long startup times due to JVMTI > agents loaded with -javaagent. While investigating the problem we > realized that the JIT compiler is only started AFTER the agent was > loaded and initialized and therefore the whole agent initialization > takes place in interpreted mode. Here is the corresponding code from > thread.cpp: > > 3137 // Notify JVMTI agents that VM initialization is complete > - nop if no agents. > 3138 JvmtiExport::post_vm_initialized(); > 3139 > 3140 Chunk::start_chunk_pool_cleaner_task(); > 3141 > 3142 // initialize compiler(s) > 3143 CompileBroker::compilation_init(); > > Is there any particualr reason that the JIT gets initialized only > after the agent initialization or could it be done just as well > before? A short test where we placed > "CompileBroker::compilation_init()" just before > "JvmtiExport::post_vm_initialized()" succeeded with a considerable > startup speedup, but we are not sure if this change would be valid in > general. > I agree it would be desirable to have the compiler enabled before the agent's premain is invoked. I haven't worked in this area for some time, and don't recall the reasoning for the ordering. One possible side effort is when you have multiple agents, say a java agent and native agent that enables CompieldMethodLoad. Depending on the ordering that they are initiated then the native agent might get compilation events before its VMInit is called (assuming the event is enabled early). I'm not saying this is a problem, just something to check into. Robert, Dan - do you recall the reason for the ordering? (carried over from JVMDI perhaps?). -Alan. From Alan.Bateman at Sun.COM Thu Jun 25 07:59:02 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 25 Jun 2009 15:59:02 +0100 Subject: Could the JIT be started before JVMTI agents are loaded? In-Reply-To: <4A438FE1.2000708@sun.com> References: <4A438FE1.2000708@sun.com> Message-ID: <4A4390B6.9090303@sun.com> Daniel D. Daugherty wrote: > The compiler is initialized after JVMTI has posted the VM_INIT > event intentionally. The compiler may have to initialize differently > depending on the capabilities that were enabled by the JVMTI agent. > > Dan We should be in the live phase at this point, do you mean capabilities enabled in the onload phase? -Alan. From Daniel.Daugherty at Sun.COM Thu Jun 25 08:08:57 2009 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Thu, 25 Jun 2009 09:08:57 -0600 Subject: Could the JIT be started before JVMTI agents are loaded? In-Reply-To: <4A4390B6.9090303@sun.com> References: <4A438FE1.2000708@sun.com> <4A4390B6.9090303@sun.com> Message-ID: <4A439309.80305@sun.com> Alan Bateman wrote: > Daniel D. Daugherty wrote: >> The compiler is initialized after JVMTI has posted the VM_INIT >> event intentionally. The compiler may have to initialize differently >> depending on the capabilities that were enabled by the JVMTI agent. >> >> Dan > We should be in the live phase at this point, do you mean capabilities > enabled in the onload phase? I generically mean things done by the VM_INIT event handler in the agent's code. Could be more capabilities, could be other "things". The VM_INIT event marks a specific point in time during VM bringup. Starting the compiler before VM_INIT would not be right because that would change expectations. It might even be a spec violation, but I didn't crack open the spec this AM. Sorry, working on JavaFX stuff at the moment... :-) Dan From volker.simonis at gmail.com Thu Jun 25 10:03:12 2009 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 25 Jun 2009 19:03:12 +0200 Subject: Could the JIT be started before JVMTI agents are loaded? In-Reply-To: <4A439309.80305@sun.com> References: <4A438FE1.2000708@sun.com> <4A4390B6.9090303@sun.com> <4A439309.80305@sun.com> Message-ID: Thanks for you advice! We were already thinking to start the compilers before JVMTI has posted the VM_INIT event but then discard all the compiled methods AFTER the agents have been initialized. We still need to investigate however if it would be enough to just recompile the methods after the agents have been initialized or if a complete re-initialization of the compiler would be necessary. Thanks, Volker On 6/25/09, Daniel D. Daugherty wrote: > Alan Bateman wrote: > > > Daniel D. Daugherty wrote: > > > > > The compiler is initialized after JVMTI has posted the VM_INIT > > > event intentionally. The compiler may have to initialize differently > > > depending on the capabilities that were enabled by the JVMTI agent. > > > > > > Dan > > > > > We should be in the live phase at this point, do you mean capabilities > enabled in the onload phase? > > > > I generically mean things done by the VM_INIT event handler > in the agent's code. Could be more capabilities, could be > other "things". > > The VM_INIT event marks a specific point in time during VM > bringup. Starting the compiler before VM_INIT would not be > right because that would change expectations. It might even > be a spec violation, but I didn't crack open the spec this > AM. Sorry, working on JavaFX stuff at the moment... :-) > > Dan > > From Thomas.Rodriguez at Sun.COM Thu Jun 25 13:19:14 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 25 Jun 2009 13:19:14 -0700 Subject: Could the JIT be started before JVMTI agents are loaded? In-Reply-To: References: <4A438FE1.2000708@sun.com> <4A4390B6.9090303@sun.com> <4A439309.80305@sun.com> Message-ID: <0DA876B6-7E26-41B7-9CEF-F9DA4FF93442@sun.com> On Jun 25, 2009, at 10:03 AM, Volker Simonis wrote: > Thanks for you advice! > > We were already thinking to start the compilers before JVMTI has > posted the VM_INIT > event but then discard all the compiled methods AFTER the agents have > been initialized. > > We still need to investigate however if it would be enough to just > recompile the methods after the agents have been initialized or if a > complete re-initialization of the compiler would be necessary. You shouldn't have to reinitialize the compilers. They are fairly stateless, except for the stubs and none of them have any JVMTI dependencies. The only thing you have to worry about is whether existing generated code was generated appropriately for any features that got enabled later. It's reasonably easy to invalidate all the existing nmethods if some feature is needed that wasn't enabled previously. The compiler currently don't record anything about which JVMTI features they were compiled to support so you only choice is to throw out everything. If we recorded more info then you could throw out only thing which needed to be regenerated. tom > > Thanks, > Volker > > On 6/25/09, Daniel D. Daugherty wrote: >> Alan Bateman wrote: >> >>> Daniel D. Daugherty wrote: >>> >>>> The compiler is initialized after JVMTI has posted the VM_INIT >>>> event intentionally. The compiler may have to initialize >>>> differently >>>> depending on the capabilities that were enabled by the JVMTI agent. >>>> >>>> Dan >>>> >>> We should be in the live phase at this point, do you mean >>> capabilities >> enabled in the onload phase? >>> >> >> I generically mean things done by the VM_INIT event handler >> in the agent's code. Could be more capabilities, could be >> other "things". >> >> The VM_INIT event marks a specific point in time during VM >> bringup. Starting the compiler before VM_INIT would not be >> right because that would change expectations. It might even >> be a spec violation, but I didn't crack open the spec this >> AM. Sorry, working on JavaFX stuff at the moment... :-) >> >> Dan >> >> From john.coomes at sun.com Thu Jun 25 20:39:42 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Jun 2009 03:39:42 +0000 Subject: hg: jdk7/hotspot: 6 new changesets Message-ID: <20090626033942.813E0E1DA@hg.openjdk.java.net> Changeset: 54d14906940b Author: jjg Date: 2009-05-20 14:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/54d14906940b 6827026: Change javac source and target default to 7 Reviewed-by: darcy, ohair ! make/Defs-internal.gmk Changeset: 2734c0deab69 Author: tbell Date: 2009-06-11 21:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/2734c0deab69 Merge Changeset: e84b527d8be8 Author: tbell Date: 2009-06-21 23:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/e84b527d8be8 Merge Changeset: 60b818e5e4f9 Author: andrew Date: 2009-06-17 20:53 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/60b818e5e4f9 6851515: awt_p.h incorporates a chunk of the XRender header Summary: Use XRender header directly rather than copying chunks locally Reviewed-by: anthony, ohair ! README-builds.html Changeset: c7ed15ab92ce Author: yan Date: 2009-06-23 23:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/c7ed15ab92ce Merge Changeset: 57f7e028c7ad Author: xdono Date: 2009-06-25 12:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/57f7e028c7ad Added tag jdk7-b62 for changeset c7ed15ab92ce ! .hgtags From john.coomes at sun.com Thu Jun 25 20:44:23 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Jun 2009 03:44:23 +0000 Subject: hg: jdk7/hotspot/corba: 4 new changesets Message-ID: <20090626034428.2B31AE1E1@hg.openjdk.java.net> Changeset: 2752d8bd4142 Author: jjg Date: 2009-05-20 13:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/2752d8bd4142 6827026: Change javac source and target default to 7 Reviewed-by: darcy, ohair ! make/Makefile Changeset: 23f2c435056b Author: tbell Date: 2009-06-11 21:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/23f2c435056b Merge Changeset: 65b66117dbd7 Author: tbell Date: 2009-06-21 23:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/65b66117dbd7 Merge Changeset: d20e45cd539f Author: xdono Date: 2009-06-25 12:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/d20e45cd539f Added tag jdk7-b62 for changeset 65b66117dbd7 ! .hgtags From john.coomes at sun.com Thu Jun 25 20:52:54 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Jun 2009 03:52:54 +0000 Subject: hg: jdk7/hotspot/jaxp: 4 new changesets Message-ID: <20090626035301.37EFBE1E8@hg.openjdk.java.net> Changeset: bdaf6acaf6e3 Author: jjg Date: 2009-05-20 13:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/bdaf6acaf6e3 6827026: Change javac source and target default to 7 Reviewed-by: darcy, ohair ! make/Makefile ! make/build.properties ! make/build.xml Changeset: 97344798aaf7 Author: tbell Date: 2009-06-11 21:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/97344798aaf7 Merge ! make/Makefile ! make/build.properties ! make/build.xml Changeset: a97dd57a6260 Author: tbell Date: 2009-06-21 23:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/a97dd57a6260 Merge Changeset: ae449e9c04c1 Author: xdono Date: 2009-06-25 12:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/ae449e9c04c1 Added tag jdk7-b62 for changeset a97dd57a6260 ! .hgtags From john.coomes at sun.com Thu Jun 25 20:57:46 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Jun 2009 03:57:46 +0000 Subject: hg: jdk7/hotspot/jaxws: 4 new changesets Message-ID: <20090626035752.580A2E1ED@hg.openjdk.java.net> Changeset: 605e1cdeba48 Author: jjg Date: 2009-05-20 13:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/605e1cdeba48 6827026: Change javac source and target default to 7 Reviewed-by: darcy, ohair ! make/Makefile ! make/build.properties ! make/build.xml Changeset: 2ec98e99e4ea Author: tbell Date: 2009-06-11 21:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/2ec98e99e4ea Merge ! make/Makefile ! make/build.properties ! make/build.xml Changeset: 75c801c13ea1 Author: tbell Date: 2009-06-21 23:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/75c801c13ea1 Merge Changeset: b8a6e883c0a6 Author: xdono Date: 2009-06-25 12:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/b8a6e883c0a6 Added tag jdk7-b62 for changeset 75c801c13ea1 ! .hgtags From john.coomes at sun.com Thu Jun 25 21:03:34 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Jun 2009 04:03:34 +0000 Subject: hg: jdk7/hotspot/jdk: 47 new changesets Message-ID: <20090626041416.DAD80E1F7@hg.openjdk.java.net> Changeset: 842fb12a21d7 Author: sherman Date: 2009-05-19 15:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/842fb12a21d7 6831794: charset EUC_TW is 12.6% of the total size of charsets.jar 6229811: Several codepoints in EUC_TW failed in roundtrip conversion Summary: Re-write EUC_TW charset to address the size and roundtrip issue. Reviewed-by: alanb ! make/java/nio/Makefile ! make/sun/Makefile ! make/sun/nio/FILES_java.gmk ! make/sun/nio/Makefile ! make/tools/CharsetMapping/Makefile ! make/tools/src/build/tools/charsetmapping/CharsetMapping.java ! make/tools/src/build/tools/charsetmapping/GenerateMapping.java ! make/tools/src/build/tools/charsetmapping/GenerateSBCS.java ! src/share/classes/sun/io/ByteToCharEUC_TW.java ! src/share/classes/sun/io/CharToByteEUC_TW.java ! src/share/classes/sun/nio/cs/ext/EUC_TW.java ! src/share/classes/sun/nio/cs/ext/ISO2022.java ! src/share/classes/sun/nio/cs/ext/ISO2022_CN.java ! src/solaris/classes/sun/awt/motif/X11CNS11643.java ! test/sun/nio/cs/TestISO2022CNDecoder.java Changeset: 72e4312ea1e0 Author: sherman Date: 2009-05-19 16:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/72e4312ea1e0 6843079: Putback for the new EUC_TW is not complete Summary: Putback the files missed in last putback Reviewed-by: alanb + make/tools/CharsetMapping/euc_tw.map + make/tools/src/build/tools/charsetmapping/GenerateEUC_TW.java + make/tools/src/build/tools/charsetmapping/Main.java + test/sun/nio/cs/EUC_TW_OLD.java + test/sun/nio/cs/TestEUC_TW.java + test/sun/nio/cs/TestX11CNS.java + test/sun/nio/cs/X11CNS11643.java + test/sun/nio/cs/X11CNS11643P1.java + test/sun/nio/cs/X11CNS11643P2.java + test/sun/nio/cs/X11CNS11643P3.java Changeset: 49478a651a28 Author: sherman Date: 2009-05-19 16:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/49478a651a28 6728376: Wrong error handling in Java_java_util_zip_Deflater_deflateBytes leads to size 0 if compress fails 6735255: ZipFile.close() does not close ZipFileInputStreams, contrary to the API document Summary: Throws OOM when malloc failed. Closes all outstanding streams when closing Reviewed-by: alanb ! src/share/classes/java/util/zip/ZipFile.java ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c Changeset: 057cc7d16812 Author: sherman Date: 2009-05-19 16:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/057cc7d16812 Merge Changeset: 02b02a886b9b Author: weijun Date: 2009-05-20 10:11 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/02b02a886b9b 6832016: {DigestMD5Base,Des3DkCrypto}.setParityBit should use Integer.bitCount Reviewed-by: weijun Contributed-by: Christian Thalinger ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java ! src/share/classes/sun/security/krb5/internal/crypto/dk/Des3DkCrypto.java Changeset: 4d607dc5cb22 Author: weijun Date: 2009-05-20 10:12 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4d607dc5cb22 6682516: SPNEGO_HTTP_AUTH/WWW_KRB and SPNEGO_HTTP_AUTH/WWW_SPNEGO failed on all non-windows platforms Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/PrincipalName.java + test/sun/security/krb5/canonicalize/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor + test/sun/security/krb5/canonicalize/Test.java Changeset: eb46247f6c53 Author: weijun Date: 2009-05-20 10:12 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/eb46247f6c53 6832353: Krb5LoginModule: use the KRB5CCNAME when searching for Kerberos ticket cache Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java Changeset: 1bc5be8665cc Author: jjg Date: 2009-05-20 13:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1bc5be8665cc 6827026: Change javac source and target default to 7 Reviewed-by: darcy, ohair ! make/common/shared/Defs-control.gmk ! make/common/shared/Defs-java.gmk ! make/javax/swing/beaninfo/SwingBeans.gmk Changeset: 914c33c7de3e Author: sherman Date: 2009-05-21 23:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/914c33c7de3e 6843578: Re-implement IBM doublebyte charsets 6639450: IBM949C encoder modifies state of IBM949 encoder 6569191: Cp943 io converter returns U+0000 and U+FFFD for unconvertable character 6577466: Character encoder IBM970 throws a BufferOverflowException 5065777: CharsetEncoder canEncode() methods often incorrectly return false Summary: Re-write 11 IBM doublebyte charsets. Thanks Ulf.Zibis for the codereview! Reviewed-by: martin ! make/sun/nio/FILES_java.gmk ! make/sun/nio/Makefile + make/tools/CharsetMapping/DoubleByte-X.java + make/tools/CharsetMapping/IBM1381.c2b + make/tools/CharsetMapping/IBM1381.map + make/tools/CharsetMapping/IBM1383.c2b + make/tools/CharsetMapping/IBM1383.map + make/tools/CharsetMapping/IBM1383.nr + make/tools/CharsetMapping/IBM930.c2b + make/tools/CharsetMapping/IBM930.map + make/tools/CharsetMapping/IBM930.nr + make/tools/CharsetMapping/IBM933.c2b + make/tools/CharsetMapping/IBM933.map + make/tools/CharsetMapping/IBM935.c2b + make/tools/CharsetMapping/IBM935.map + make/tools/CharsetMapping/IBM935.nr + make/tools/CharsetMapping/IBM937.c2b + make/tools/CharsetMapping/IBM937.map + make/tools/CharsetMapping/IBM937.nr + make/tools/CharsetMapping/IBM939.c2b + make/tools/CharsetMapping/IBM939.map + make/tools/CharsetMapping/IBM939.nr + make/tools/CharsetMapping/IBM942.c2b + make/tools/CharsetMapping/IBM942.map + make/tools/CharsetMapping/IBM943.map + make/tools/CharsetMapping/IBM943.nr + make/tools/CharsetMapping/IBM948.c2b + make/tools/CharsetMapping/IBM948.map + make/tools/CharsetMapping/IBM949.map + make/tools/CharsetMapping/IBM950.c2b + make/tools/CharsetMapping/IBM950.map + make/tools/CharsetMapping/IBM970.c2b + make/tools/CharsetMapping/IBM970.map + make/tools/CharsetMapping/dbcs + make/tools/src/build/tools/charsetmapping/GenerateDBCS.java ! make/tools/src/build/tools/charsetmapping/Main.java ! src/share/classes/sun/io/ByteToCharCp1381.java ! src/share/classes/sun/io/ByteToCharCp1383.java ! src/share/classes/sun/io/ByteToCharCp834.java ! src/share/classes/sun/io/ByteToCharCp930.java ! src/share/classes/sun/io/ByteToCharCp933.java ! src/share/classes/sun/io/ByteToCharCp935.java ! src/share/classes/sun/io/ByteToCharCp937.java ! src/share/classes/sun/io/ByteToCharCp939.java ! src/share/classes/sun/io/ByteToCharCp942.java ! src/share/classes/sun/io/ByteToCharCp942C.java ! src/share/classes/sun/io/ByteToCharCp943.java ! src/share/classes/sun/io/ByteToCharCp943C.java ! src/share/classes/sun/io/ByteToCharCp948.java ! src/share/classes/sun/io/ByteToCharCp949.java ! src/share/classes/sun/io/ByteToCharCp949C.java ! src/share/classes/sun/io/ByteToCharCp950.java ! src/share/classes/sun/io/ByteToCharCp970.java ! src/share/classes/sun/io/ByteToCharDBCS_ASCII.java ! src/share/classes/sun/io/ByteToCharDBCS_EBCDIC.java + src/share/classes/sun/io/ByteToCharEUC2.java ! src/share/classes/sun/io/CharToByteCp1381.java ! src/share/classes/sun/io/CharToByteCp1383.java ! src/share/classes/sun/io/CharToByteCp834.java ! src/share/classes/sun/io/CharToByteCp930.java ! src/share/classes/sun/io/CharToByteCp933.java ! src/share/classes/sun/io/CharToByteCp935.java ! src/share/classes/sun/io/CharToByteCp937.java ! src/share/classes/sun/io/CharToByteCp939.java ! src/share/classes/sun/io/CharToByteCp942.java ! src/share/classes/sun/io/CharToByteCp942C.java ! src/share/classes/sun/io/CharToByteCp943.java ! src/share/classes/sun/io/CharToByteCp943C.java ! src/share/classes/sun/io/CharToByteCp948.java ! src/share/classes/sun/io/CharToByteCp949.java ! src/share/classes/sun/io/CharToByteCp949C.java ! src/share/classes/sun/io/CharToByteCp950.java ! src/share/classes/sun/io/CharToByteCp970.java ! src/share/classes/sun/io/CharToByteDBCS_ASCII.java ! src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java - src/share/classes/sun/nio/cs/ext/DBCSDecoderMapping.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Decoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Encoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Decoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Encoder.java - src/share/classes/sun/nio/cs/ext/DBCS_ONLY_IBM_EBCDIC_Decoder.java + src/share/classes/sun/nio/cs/ext/DoubleByte.java - src/share/classes/sun/nio/cs/ext/IBM1381.java - src/share/classes/sun/nio/cs/ext/IBM1383.java ! src/share/classes/sun/nio/cs/ext/IBM834.java - src/share/classes/sun/nio/cs/ext/IBM930.java - src/share/classes/sun/nio/cs/ext/IBM933.java - src/share/classes/sun/nio/cs/ext/IBM935.java - src/share/classes/sun/nio/cs/ext/IBM937.java - src/share/classes/sun/nio/cs/ext/IBM939.java - src/share/classes/sun/nio/cs/ext/IBM942.java ! src/share/classes/sun/nio/cs/ext/IBM942C.java - src/share/classes/sun/nio/cs/ext/IBM943.java ! src/share/classes/sun/nio/cs/ext/IBM943C.java - src/share/classes/sun/nio/cs/ext/IBM948.java - src/share/classes/sun/nio/cs/ext/IBM949.java ! src/share/classes/sun/nio/cs/ext/IBM949C.java - src/share/classes/sun/nio/cs/ext/IBM950.java - src/share/classes/sun/nio/cs/ext/IBM970.java - src/share/classes/sun/nio/cs/ext/SimpleEUCDecoder.java ! test/sun/nio/cs/FindCanEncodeBugs.java ! test/sun/nio/cs/FindEncoderBugs.java + test/sun/nio/cs/OLD/DBCSDecoderMapping.java + test/sun/nio/cs/OLD/DBCS_IBM_ASCII_Decoder.java + test/sun/nio/cs/OLD/DBCS_IBM_ASCII_Encoder.java + test/sun/nio/cs/OLD/DBCS_IBM_EBCDIC_Decoder.java + test/sun/nio/cs/OLD/DBCS_IBM_EBCDIC_Encoder.java + test/sun/nio/cs/OLD/DBCS_ONLY_IBM_EBCDIC_Decoder.java + test/sun/nio/cs/OLD/IBM1381_OLD.java + test/sun/nio/cs/OLD/IBM1383_OLD.java + test/sun/nio/cs/OLD/IBM930_OLD.java + test/sun/nio/cs/OLD/IBM933_OLD.java + test/sun/nio/cs/OLD/IBM935_OLD.java + test/sun/nio/cs/OLD/IBM937_OLD.java + test/sun/nio/cs/OLD/IBM939_OLD.java + test/sun/nio/cs/OLD/IBM942C_OLD.java + test/sun/nio/cs/OLD/IBM942_OLD.java + test/sun/nio/cs/OLD/IBM943C_OLD.java + test/sun/nio/cs/OLD/IBM943_OLD.java + test/sun/nio/cs/OLD/IBM948_OLD.java + test/sun/nio/cs/OLD/IBM949C_OLD.java + test/sun/nio/cs/OLD/IBM949_OLD.java + test/sun/nio/cs/OLD/IBM950_OLD.java + test/sun/nio/cs/OLD/IBM970_OLD.java + test/sun/nio/cs/OLD/SimpleEUCDecoder.java + test/sun/nio/cs/OLD/TestIBMDB.java ! test/sun/nio/cs/TestEUC_TW.java ! test/sun/nio/cs/TestIBMBugs.java Changeset: 8d2efec31d78 Author: xlu Date: 2009-05-24 16:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8d2efec31d78 6622432: RFE: Performance improvements to java.math.BigDecimal Reviewed-by: darcy ! src/share/classes/java/math/BigDecimal.java ! src/share/classes/java/math/BigInteger.java ! src/share/classes/java/math/BitSieve.java ! src/share/classes/java/math/MathContext.java ! src/share/classes/java/math/MutableBigInteger.java ! src/share/classes/java/math/SignedMutableBigInteger.java ! test/java/math/BigDecimal/AddTests.java ! test/java/math/BigDecimal/DivideTests.java Changeset: 3994c5c669cb Author: xlu Date: 2009-05-24 16:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3994c5c669cb 6806261: BigDecimal.longValueExact() method throws NullPointerException Summary: add various tests to test the change to 6622432 Reviewed-by: darcy + test/java/math/BigDecimal/EqualsTests.java + test/java/math/BigDecimal/LongValueExactTests.java + test/java/math/BigDecimal/MultiplyTests.java + test/java/math/BigDecimal/PrecisionTests.java + test/java/math/BigInteger/CompareToTests.java Changeset: 206d73d299d4 Author: jccollet Date: 2009-05-25 22:27 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/206d73d299d4 6349566: java.net.CookieManager doesn't set default domain Summary: Enforce default domain in CookieManager Reviewed-by: michaelm ! src/share/classes/java/net/CookieManager.java ! test/java/net/CookieHandler/CookieManagerTest.java Changeset: dc3865883a5a Author: weijun Date: 2009-05-26 10:12 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/dc3865883a5a 6844887: NPE in TextCallbackHandler Reviewed-by: xuelei ! src/share/classes/com/sun/security/auth/callback/TextCallbackHandler.java + test/com/sun/security/auth/callback/TextCallbackHandler/NPE.java Changeset: d93b7df1e260 Author: xuelei Date: 2009-05-26 16:19 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d93b7df1e260 6822460: support self-issued certificate Summary: checking self-issued certificate during certification path building Reviewed-by: mullan, weijun ! src/share/classes/sun/security/validator/PKIXValidator.java ! src/share/classes/sun/security/validator/SimpleValidator.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java Changeset: c3c5cc0f2a3e Author: xuelei Date: 2009-05-26 16:43 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c3c5cc0f2a3e 6720721: CRL check with circular depency support needed Summary: checking AKID of certificates and CRLs Reviewed-by: mullan, weijun ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java + test/java/security/cert/CertPathValidator/indirectCRL/CircularCRLOneLevel.java + test/java/security/cert/CertPathValidator/indirectCRL/CircularCRLOneLevelRevoked.java + test/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevel.java + test/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevelRevoked.java + test/java/security/cert/CertPathValidator/indirectCRL/README + test/java/security/cert/CertPathValidator/indirectCRL/generate.sh + test/java/security/cert/CertPathValidator/indirectCRL/openssl.cnf Changeset: 045aeb76b0ff Author: jccollet Date: 2009-05-26 16:03 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/045aeb76b0ff 6726695: HttpURLConnection shoul support 'Expect: 100-contimue' headers for PUT Summary: Added code triggered when 'Expect: 100-continue' header has been added Reviewed-by: chegar ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/http/HttpClient/B6726695.java Changeset: 25db260cb810 Author: xuelei Date: 2009-05-27 17:48 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/25db260cb810 6845286: Add regression test for name constraints Summary: create regression test cases on name constraints Reviewed-by: weijun + test/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithRID.java + test/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithUnexpectedRID.java + test/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithoutRID.java + test/java/security/cert/CertPathValidator/nameConstraints/generate.sh + test/java/security/cert/CertPathValidator/nameConstraints/openssl.cnf Changeset: 7772d77bd7c2 Author: mchung Date: 2009-05-26 17:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7772d77bd7c2 6829636: test/java/util/logging/LoggingDeadlock2.java is flaky Summary: remove @ignore Reviewed-by: swamyv ! src/share/classes/java/net/URLConnection.java ! test/Makefile ! test/java/util/logging/LoggingDeadlock2.java Changeset: 2aeaffb6c897 Author: mchung Date: 2009-05-26 17:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2aeaffb6c897 6798842: TEST_BUG: ThreadStackTrace.java fails intermittently with unexpected thread status. Summary: remove @ignore Reviewed-by: swamyv ! test/java/lang/management/ThreadMXBean/ThreadStackTrace.java + test/java/lang/management/ThreadMXBean/Utils.java Changeset: fba2425da9b1 Author: mchung Date: 2009-05-26 18:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/fba2425da9b1 5080203: TEST_BUG: ThreadStateTest fails intermittently. Summary: Retry a few times to check thread status before reporting failure Reviewed-by: swamyv ! test/java/lang/management/ThreadMXBean/ThreadStateTest.java Changeset: a7a38e606a7a Author: mchung Date: 2009-05-26 18:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a7a38e606a7a 6512493: TEST_BUG: unexpected LockInfo failure in LockedSynchronizers.java Summary: Retry a few times to check thread status before reporting failure Reviewed-by: swamyv ! test/java/lang/management/ThreadMXBean/LockingThread.java ! test/java/lang/management/ThreadMXBean/MonitorDeadlock.java Changeset: fb97068670e6 Author: mchung Date: 2009-05-26 18:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/fb97068670e6 6535104: TEST_BUG: FindDeadlocks.java fails intermittently. Summary: Retry a few times to check thread status before reporting failure Reviewed-by: swamyv ! test/java/lang/management/ThreadMXBean/SynchronizerDeadlock.java ! test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java Changeset: 742b55c45a70 Author: mchung Date: 2009-05-27 13:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/742b55c45a70 Merge Changeset: 59bbb9f3f430 Author: kamg Date: 2009-05-27 13:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/59bbb9f3f430 6838211: jdk docs creation broken for tracing docs Summary: Fix javadoc makefile macro Reviewed-by: ohair, jjg ! make/docs/Makefile Changeset: 8e77f61508cc Author: kamg Date: 2009-05-27 15:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8e77f61508cc Merge Changeset: 928e0f1043e6 Author: chegar Date: 2009-05-29 15:51 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/928e0f1043e6 6807602: Increase MAX_BUFFER_LEN and MAX_HEAP_BUFFER_LEN on 64-bit Solaris and Linux Reviewed-by: alanb ! src/solaris/native/java/net/net_util_md.h Changeset: aece9096d5cd Author: jjg Date: 2009-05-29 16:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/aece9096d5cd 6838199: remove support for old javap Reviewed-by: ohair, mcimadamore ! make/common/Release.gmk ! make/common/internal/Defs-langtools.gmk ! make/launchers/Makefile Changeset: d26c268597ed Author: sherman Date: 2009-05-29 16:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d26c268597ed 6808625: Incomplete code sample in Deflater javadoc Summary: added compresser.end() into example Reviewed-by: martin ! src/share/classes/java/util/zip/Deflater.java Changeset: 045743e0eb2d Author: xuelei Date: 2009-06-04 11:28 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/045743e0eb2d 6847459: Allow trust anchor self-issued intermediate version 1 and version 2 certificate Reviewed-by: weijun ! src/share/classes/sun/security/provider/certpath/ConstraintsChecker.java Changeset: 8f405b65ddac Author: weijun Date: 2009-06-09 14:17 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8f405b65ddac 6578647: Undefined requesting URL in java.net.Authenticator.getPasswordAuthentication() Reviewed-by: chegar, valeriep ! src/share/classes/sun/net/www/protocol/http/AuthenticationHeader.java + src/share/classes/sun/net/www/protocol/http/HttpCallerInfo.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java ! src/share/classes/sun/net/www/protocol/http/NegotiateCallbackHandler.java ! src/share/classes/sun/net/www/protocol/http/NegotiatorImpl.java + src/share/classes/sun/security/jgss/GSSCaller.java ! src/share/classes/sun/security/jgss/GSSManagerImpl.java ! src/share/classes/sun/security/jgss/GSSUtil.java + src/share/classes/sun/security/jgss/HttpCaller.java ! src/share/classes/sun/security/jgss/LoginConfigImpl.java ! src/share/classes/sun/security/jgss/ProviderList.java ! src/share/classes/sun/security/jgss/krb5/InitialToken.java ! src/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java ! src/share/classes/sun/security/jgss/spnego/SpNegoMechFactory.java ! src/share/classes/sun/security/jgss/wrapper/NativeGSSFactory.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! test/sun/security/jgss/DefaultGssConfig.java ! test/sun/security/jgss/GssNPE.java + test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/auto/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor Changeset: 4da7b972b391 Author: mullan Date: 2009-06-10 09:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4da7b972b391 6845161: Bottleneck in Configuration.getConfiguration synchronized call Summary: Reduce scope of synchronized block Reviewed-by: weijun ! src/share/classes/javax/security/auth/login/Configuration.java Changeset: ffbcf1d1103c Author: xuelei Date: 2009-06-12 09:00 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ffbcf1d1103c 6570344: Invalid RSA OID in sun.security.x509.AlgorithmId Summary: change RSA OID to "2.5.8.1.1" Reviewed-by: mullan ! src/share/classes/sun/security/x509/AlgorithmId.java Changeset: 328148f45b31 Author: tbell Date: 2009-06-11 21:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/328148f45b31 Merge ! make/docs/Makefile - src/share/classes/sun/nio/cs/ext/DBCSDecoderMapping.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Decoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Encoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Decoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Encoder.java - src/share/classes/sun/nio/cs/ext/DBCS_ONLY_IBM_EBCDIC_Decoder.java - src/share/classes/sun/nio/cs/ext/IBM1381.java - src/share/classes/sun/nio/cs/ext/IBM1383.java - src/share/classes/sun/nio/cs/ext/IBM930.java - src/share/classes/sun/nio/cs/ext/IBM933.java - src/share/classes/sun/nio/cs/ext/IBM935.java - src/share/classes/sun/nio/cs/ext/IBM937.java - src/share/classes/sun/nio/cs/ext/IBM939.java - src/share/classes/sun/nio/cs/ext/IBM942.java - src/share/classes/sun/nio/cs/ext/IBM943.java - src/share/classes/sun/nio/cs/ext/IBM948.java - src/share/classes/sun/nio/cs/ext/IBM949.java - src/share/classes/sun/nio/cs/ext/IBM950.java - src/share/classes/sun/nio/cs/ext/IBM970.java - src/share/classes/sun/nio/cs/ext/SimpleEUCDecoder.java ! test/Makefile Changeset: 74aefd0ab26d Author: martin Date: 2009-06-14 14:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/74aefd0ab26d 6850720: (process) Use clone(CLONE_VM), not fork, on Linux to avoid swap exhaustion Summary: Use clone(CLONE_VM) on Linux; Reluctantly implement execvpe. Reviewed-by: michaelm ! src/solaris/native/java/lang/UNIXProcess_md.c ! test/java/lang/ProcessBuilder/Basic.java + test/java/lang/ProcessBuilder/BigFork.java Changeset: d0de3e41426b Author: martin Date: 2009-06-14 14:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d0de3e41426b 6511515: poor performance of LogRecord.inferCaller depending on java.lang.Throwable.getStackTraceElement Summary: Allow random access to stack trace elements; retrieve only needed ones Reviewed-by: swamyv Contributed-by: jeremymanson at google.com ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Throwable.java ! src/share/classes/java/util/logging/LogRecord.java ! src/share/classes/sun/misc/JavaLangAccess.java Changeset: 5a5b56904855 Author: tbell Date: 2009-06-21 12:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5a5b56904855 6853336: (process) disable or remove clone-exec feature (6850720) Summary: clone-exec feature (6850720) needs more work on 32-bit Linux Reviewed-by: alanb, michaelm Contributed-by: Martin Buchholz ! src/solaris/native/java/lang/UNIXProcess_md.c Changeset: 55a584478eac Author: tbell Date: 2009-06-21 23:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/55a584478eac Merge Changeset: 6f1f159aed75 Author: yan Date: 2009-06-03 17:41 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6f1f159aed75 6839645: Swing application prints message in Control Panel if language is changed Summary: just remove debug printout from production builds; ignore multicharacter-generating keys Reviewed-by: uta ! src/windows/native/sun/windows/awt_Component.cpp Changeset: a3f970a8600b Author: anthony Date: 2009-06-04 15:18 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a3f970a8600b 6832386: Fix JTreg test: java/awt/Graphics/DrawImageBG/SystemBgColorTest.java Summary: Removed unneeded System.exit(0) call. Reviewed-by: art, ohair, anthony Contributed-by: Omair Majid ! test/java/awt/Graphics/DrawImageBG/SystemBgColorTest.java Changeset: 7289003cd1c9 Author: dcherepanov Date: 2009-06-05 17:30 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7289003cd1c9 6829180: Removing focused component from a window causes a JVM crash for JDK7b50+ on WinXP/Vista Summary: access pData on the toolkit thread Reviewed-by: art, anthony, naoto ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_InputMethod.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h ! src/windows/native/sun/windows/awtmsg.h Changeset: 70654407b626 Author: dcherepanov Date: 2009-06-15 11:15 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/70654407b626 6847584: closed/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.html fails Reviewed-by: anthony + test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.html ! test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java Changeset: 0e441c781cdc Author: yan Date: 2009-06-16 00:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0e441c781cdc Merge - src/share/native/sun/java2d/pipe/RenderBuffer.c Changeset: 2a526ccd12e8 Author: andrew Date: 2009-06-17 21:13 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2a526ccd12e8 6851515: awt_p.h incorporates a chunk of the XRender header Summary: Use XRender header directly rather than copying chunks locally Reviewed-by: anthony, ohair ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_p.h Changeset: 1bbbd0ef5d04 Author: peytoia Date: 2009-06-13 06:43 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1bbbd0ef5d04 6850113: Bidi class needs to be updated to support Unicode 5.1 Reviewed-by: okutsu ! make/java/text/FILES_java.gmk ! make/sun/font/FILES_c.gmk ! make/sun/font/Makefile ! make/sun/font/mapfile-vers ! make/sun/font/mapfile-vers.openjdk ! src/share/classes/java/text/Bidi.java + src/share/classes/sun/text/bidi/BidiBase.java + src/share/classes/sun/text/bidi/BidiLine.java + src/share/classes/sun/text/bidi/BidiRun.java ! src/share/classes/sun/text/normalizer/UCharacter.java - src/share/native/sun/font/bidi/cmemory.h - src/share/native/sun/font/bidi/jbidi.c - src/share/native/sun/font/bidi/jbidi.h - src/share/native/sun/font/bidi/ubidi.c - src/share/native/sun/font/bidi/ubidi.h - src/share/native/sun/font/bidi/ubidiimp.h - src/share/native/sun/font/bidi/ubidiln.c - src/share/native/sun/font/bidi/uchardir.c - src/share/native/sun/font/bidi/uchardir.h - src/share/native/sun/font/bidi/utypes.h ! src/share/native/sun/font/layout/LETypes.h ! test/java/text/Bidi/BidiBug.java + test/java/text/Bidi/BidiConformance.java ! test/java/text/Bidi/BidiEmbeddingTest.java + test/java/text/Bidi/Bug6850113.java Changeset: 45316d7cc9dc Author: yan Date: 2009-06-17 23:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/45316d7cc9dc Merge - src/share/native/sun/font/bidi/cmemory.h - src/share/native/sun/font/bidi/jbidi.c - src/share/native/sun/font/bidi/jbidi.h - src/share/native/sun/font/bidi/ubidi.c - src/share/native/sun/font/bidi/ubidi.h - src/share/native/sun/font/bidi/ubidiimp.h - src/share/native/sun/font/bidi/ubidiln.c - src/share/native/sun/font/bidi/uchardir.c - src/share/native/sun/font/bidi/uchardir.h - src/share/native/sun/font/bidi/utypes.h Changeset: 12e11fab9a83 Author: yan Date: 2009-06-23 23:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/12e11fab9a83 Merge - src/share/native/sun/font/bidi/cmemory.h - src/share/native/sun/font/bidi/jbidi.c - src/share/native/sun/font/bidi/jbidi.h - src/share/native/sun/font/bidi/ubidi.c - src/share/native/sun/font/bidi/ubidi.h - src/share/native/sun/font/bidi/ubidiimp.h - src/share/native/sun/font/bidi/ubidiln.c - src/share/native/sun/font/bidi/uchardir.c - src/share/native/sun/font/bidi/uchardir.h - src/share/native/sun/font/bidi/utypes.h Changeset: 8905d218cd0d Author: xdono Date: 2009-06-25 12:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8905d218cd0d Added tag jdk7-b62 for changeset 12e11fab9a83 ! .hgtags From john.coomes at sun.com Thu Jun 25 21:32:55 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Jun 2009 04:32:55 +0000 Subject: hg: jdk7/hotspot/langtools: 15 new changesets Message-ID: <20090626043320.AD861E1FD@hg.openjdk.java.net> Changeset: b5872f0790e7 Author: jjg Date: 2009-05-19 11:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/b5872f0790e7 6841422: classfile: add Type visitor Reviewed-by: mcimadamore Contributed-by: kevin.t.looney at sun.com ! src/share/classes/com/sun/tools/classfile/Type.java Changeset: f838537fb1ac Author: jjg Date: 2009-05-19 11:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/f838537fb1ac 6841420: classfile: add new methods to ConstantClassInfo Reviewed-by: mcimadamore Contributed-by: kevin.t.looney at sun.com ! src/share/classes/com/sun/tools/classfile/ConstantPool.java Changeset: fc634a593812 Author: jjg Date: 2009-05-19 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/fc634a593812 6841419: classfile: add constant pool iterator Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/ConstantPool.java Changeset: cd0630109de5 Author: jjg Date: 2009-05-19 11:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/cd0630109de5 6824493: experimental support for additional info for instructions Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/classfile/StackMapTable_attribute.java ! src/share/classes/com/sun/tools/javap/BasicWriter.java ! src/share/classes/com/sun/tools/javap/ClassWriter.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java + src/share/classes/com/sun/tools/javap/InstructionDetailWriter.java ! src/share/classes/com/sun/tools/javap/JavapTask.java + src/share/classes/com/sun/tools/javap/Messages.java ! src/share/classes/com/sun/tools/javap/Options.java + src/share/classes/com/sun/tools/javap/SourceWriter.java + src/share/classes/com/sun/tools/javap/StackMapWriter.java + src/share/classes/com/sun/tools/javap/TryBlockWriter.java ! src/share/classes/com/sun/tools/javap/resources/javap.properties + test/tools/javap/T6824493.java Changeset: 0c6cd88f72b9 Author: jjg Date: 2009-05-19 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/0c6cd88f72b9 6843013: missing files in fix for 6824493 Reviewed-by: darcy + src/share/classes/com/sun/tools/javap/LocalVariableTableWriter.java + src/share/classes/com/sun/tools/javap/LocalVariableTypeTableWriter.java Changeset: 4ce1c1400334 Author: jjg Date: 2009-05-19 15:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/4ce1c1400334 6832154: refactor Paths to be just a utility class for JavacFileManager Reviewed-by: darcy ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Changeset: 79eb8795a1de Author: jjg Date: 2009-05-20 13:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/79eb8795a1de 6827026: Change javac source and target default to 7 Reviewed-by: darcy, ohair ! make/Makefile ! make/build.properties ! make/build.xml ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java Changeset: 44eaac2b4501 Author: jjg Date: 2009-05-20 19:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/44eaac2b4501 6843648: tools/javac/versions/check.sh is broken Reviewed-by: darcy ! test/tools/javac/6341866/Anno.java ! test/tools/javac/6464451/BigFinally.java ! test/tools/javac/6464451/DeepNestedFinally.java ! test/tools/javac/6464451/ManyExitsInTry.java ! test/tools/javac/ClassLit.java ! test/tools/javac/T6557865.java ! test/tools/javac/foreach/T6682380.java ! test/tools/javac/processing/6348499/A.java ! test/tools/javac/processing/6414633/A.java ! test/tools/javac/processing/6430209/b6341534.java ! test/tools/javac/processing/T6439826.java ! test/tools/javac/stackmap/T4955930.sh ! test/tools/javac/versions/check.sh Changeset: d402db1005ad Author: mcimadamore Date: 2009-05-21 10:56 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/d402db1005ad 6722234: javac diagnostics need better integration with the type-system Summary: Added RichDiagnosticFormatter which provides better formatting capabilities for javac types/symbols Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! 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/ForwardingDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java + src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! test/tools/javac/6304921/T6304921.java ! test/tools/javac/6304921/T6304921.out ! test/tools/javac/6491592/T6491592.out + test/tools/javac/Diagnostics/6722234/T6722234a.java + test/tools/javac/Diagnostics/6722234/T6722234a_1.out + test/tools/javac/Diagnostics/6722234/T6722234a_2.out + test/tools/javac/Diagnostics/6722234/T6722234b.java + test/tools/javac/Diagnostics/6722234/T6722234b_1.out + test/tools/javac/Diagnostics/6722234/T6722234b_2.out + test/tools/javac/Diagnostics/6722234/T6722234c.java + test/tools/javac/Diagnostics/6722234/T6722234c.out + test/tools/javac/Diagnostics/6722234/T6722234d.java + test/tools/javac/Diagnostics/6722234/T6722234d_1.out + test/tools/javac/Diagnostics/6722234/T6722234d_2.out ! test/tools/javac/ExtendArray.java ! test/tools/javac/ExtendArray.out ! test/tools/javac/OverridePosition.java ! test/tools/javac/OverridePosition.out ! test/tools/javac/T4093617/T4093617.java ! test/tools/javac/T4093617/T4093617.out ! test/tools/javac/T5003235/T5003235c.java ! test/tools/javac/T5003235/T5003235c.out ! test/tools/javac/miranda/T4666866.java ! test/tools/javac/miranda/T4666866.out ! test/tools/javac/protectedAccess/ProtectedMemberAccess2.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess3.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess4.java Changeset: 84061bd68019 Author: darcy Date: 2009-05-27 22:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/84061bd68019 6843761: Update langtools tests to remove unncessary -source and -target options Reviewed-by: jjg ! test/com/sun/javadoc/testIndex/TestIndex.java ! test/com/sun/javadoc/testInterface/TestInterface.java ! test/com/sun/javadoc/testNavagation/TestNavagation.java ! test/com/sun/javadoc/testTagInheritence/TestTagInheritence.java ! test/tools/javac/5005368.java ! test/tools/javac/Ambig3.java ! test/tools/javac/ArrayCast.java ! test/tools/javac/BadCovar.java ! test/tools/javac/ClassLiterals/InitializeOuter.java ! test/tools/javac/ClassLiterals/InitializeTarget.java ! test/tools/javac/ClassToTypeParm.java ! test/tools/javac/Closure1.java ! test/tools/javac/Closure2.java ! test/tools/javac/Closure3.java ! test/tools/javac/Closure4.java ! test/tools/javac/Closure5.java ! test/tools/javac/CompoundBox.java ! test/tools/javac/ConditionalArgTypes_1.java ! test/tools/javac/ConditionalArgTypes_2.java ! test/tools/javac/DefiniteAssignment/DUAssert.java ! test/tools/javac/EarlyAssert.java ! test/tools/javac/Enum1.java ! test/tools/javac/GoodCovar.java ! test/tools/javac/HexFloatLiterals.java ! test/tools/javac/HexThree.java ! test/tools/javac/InterfaceAssert.java ! test/tools/javac/InvalidIntfCast.java ! test/tools/javac/NewGeneric.java ! test/tools/javac/ObjectMethodRefFromInterface.java ! test/tools/javac/PrivateLocalConstructor.java ! test/tools/javac/RawCrash.java ! test/tools/javac/SynthName2.java ! test/tools/javac/T5090006/compiler.sh ! test/tools/javac/T5092545.java ! test/tools/javac/T5105890.java ! test/tools/javac/annotations/default/A.java ! test/tools/javac/annotations/neg/AnnComma.java ! test/tools/javac/annotations/neg/ArrayLit.java ! test/tools/javac/annotations/neg/Constant.java ! test/tools/javac/annotations/neg/Cycle1.java ! test/tools/javac/annotations/neg/Cycle2.java ! test/tools/javac/annotations/neg/Cycle3.java ! test/tools/javac/annotations/neg/Dep.java ! test/tools/javac/annotations/neg/Dup.java ! test/tools/javac/annotations/neg/DupTarget.java ! test/tools/javac/annotations/neg/MemberOver.java ! test/tools/javac/annotations/neg/ObjectMembers.java ! test/tools/javac/annotations/neg/OverrideNo.java ! test/tools/javac/annotations/neg/Package.java ! test/tools/javac/annotations/neg/Recovery.java ! test/tools/javac/annotations/neg/Recovery1.java ! test/tools/javac/annotations/neg/Scope.java ! test/tools/javac/annotations/neg/Syntax1.java ! test/tools/javac/annotations/neg/WrongTarget.java ! test/tools/javac/annotations/neg/WrongTarget2.java ! test/tools/javac/annotations/neg/WrongValue.java ! test/tools/javac/annotations/neg/Z1.java ! test/tools/javac/annotations/neg/Z10.java ! test/tools/javac/annotations/neg/Z11.java ! test/tools/javac/annotations/neg/Z12.java ! test/tools/javac/annotations/neg/Z13.java ! test/tools/javac/annotations/neg/Z14.java ! test/tools/javac/annotations/neg/Z15.java ! test/tools/javac/annotations/neg/Z16.java ! test/tools/javac/annotations/neg/Z2.java ! test/tools/javac/annotations/neg/Z3.java ! test/tools/javac/annotations/neg/Z4.java ! test/tools/javac/annotations/neg/Z5.java ! test/tools/javac/annotations/neg/Z8.java ! test/tools/javac/annotations/neg/Z9.java ! test/tools/javac/annotations/pos/AnnoteElideBraces.java ! test/tools/javac/annotations/pos/ClassA.java ! test/tools/javac/annotations/pos/Dep.java ! test/tools/javac/annotations/pos/Enum1.java ! test/tools/javac/annotations/pos/Local.java ! test/tools/javac/annotations/pos/Members.java ! test/tools/javac/annotations/pos/NType.java ! test/tools/javac/annotations/pos/OverrideCheck.java ! test/tools/javac/annotations/pos/OverrideOK.java ! test/tools/javac/annotations/pos/Parameter.java ! test/tools/javac/annotations/pos/Primitives.java ! test/tools/javac/annotations/pos/RightTarget.java ! test/tools/javac/annotations/pos/Z1.java ! test/tools/javac/annotations/pos/Z2.java ! test/tools/javac/annotations/pos/Z3.java ! test/tools/javac/annotations/pos/Z4.java ! test/tools/javac/annotations/pos/package-info.java ! test/tools/javac/assert/Attach.java ! test/tools/javac/assert/DU1.java ! test/tools/javac/assert/DU2.java ! test/tools/javac/assert/Position.java ! test/tools/javac/boxing/BoxedForeach.java ! test/tools/javac/boxing/Boxing1.java ! test/tools/javac/boxing/Boxing2.java ! test/tools/javac/boxing/Boxing4.java ! test/tools/javac/boxing/BoxingCaching.java ! test/tools/javac/capture/Capture1.java ! test/tools/javac/capture/Capture2.java ! test/tools/javac/capture/Capture3.java ! test/tools/javac/capture/Capture5.java ! test/tools/javac/cast/BoxedArray.java ! test/tools/javac/enum/AbstractEmptyEnum.java ! test/tools/javac/enum/AbstractEnum1.java ! test/tools/javac/enum/DA1.java ! test/tools/javac/enum/DA2.java ! test/tools/javac/enum/DA3.java ! test/tools/javac/enum/Def.java ! test/tools/javac/enum/Enum1.java ! test/tools/javac/enum/Enum2.java ! test/tools/javac/enum/Enum3.java ! test/tools/javac/enum/EnumImplicitPrivateConstructor.java ! test/tools/javac/enum/EnumInit.java ! test/tools/javac/enum/EnumPrivateConstructor.java ! test/tools/javac/enum/EnumProtectedConstructor.java ! test/tools/javac/enum/EnumPublicConstructor.java ! test/tools/javac/enum/EnumSwitch1.java ! test/tools/javac/enum/EnumSwitch2.java ! test/tools/javac/enum/EnumSwitch3.java ! test/tools/javac/enum/EnumSwitch4.java ! test/tools/javac/enum/ExplicitlyAbstractEnum1.java ! test/tools/javac/enum/ExplicitlyAbstractEnum2.java ! test/tools/javac/enum/ExplicitlyFinalEnum1.java ! test/tools/javac/enum/ExplicitlyFinalEnum2.java ! test/tools/javac/enum/FauxEnum1.java ! test/tools/javac/enum/FauxEnum3.java ! test/tools/javac/enum/FauxSpecialEnum1.java ! test/tools/javac/enum/FauxSpecialEnum2.java ! test/tools/javac/enum/LocalEnum.java ! test/tools/javac/enum/NoFinal.java ! test/tools/javac/enum/NoFinal2.java ! test/tools/javac/enum/NoFinal3.java ! test/tools/javac/enum/NoFinal4.java ! test/tools/javac/enum/NoFinal5.java ! test/tools/javac/enum/OkFinal.java ! test/tools/javac/enum/SynthValues.java ! test/tools/javac/enum/T5075242.java ! test/tools/javac/enum/T5081785.java ! test/tools/javac/enum/TrailingComma.java ! test/tools/javac/enum/UserValue.java ! test/tools/javac/enum/ValueOf.java ! test/tools/javac/enum/enumSwitch/EnumSwitch.java ! test/tools/javac/foreach/Foreach.java ! test/tools/javac/foreach/GenericIterator.java ! test/tools/javac/foreach/IntersectIterator.java ! test/tools/javac/foreach/ListOfListTest.java ! test/tools/javac/foreach/SpecIterable.java ! test/tools/javac/foreach/StaticBlock.java ! test/tools/javac/foreach/SuperfluousAbstract.java ! test/tools/javac/generics/ArrayClone.java ! test/tools/javac/generics/ArrayTypearg.java ! test/tools/javac/generics/BridgeClash.java ! test/tools/javac/generics/BridgeOrder.java ! test/tools/javac/generics/CastCrash.java ! test/tools/javac/generics/Casting.java ! test/tools/javac/generics/Casting2.java ! test/tools/javac/generics/Casting3.java ! test/tools/javac/generics/Casting4.java ! test/tools/javac/generics/Conditional.java ! test/tools/javac/generics/Covar2.java ! test/tools/javac/generics/Covar3.java ! test/tools/javac/generics/Covar4.java ! test/tools/javac/generics/Crash01.java ! test/tools/javac/generics/Crash02.java ! test/tools/javac/generics/CyclicInheritance3.java ! test/tools/javac/generics/CyclicInheritance5.java ! test/tools/javac/generics/ErasureClashCrash.java ! test/tools/javac/generics/ExtendedRaw1.java ! test/tools/javac/generics/ExtendedRaw2.java ! test/tools/javac/generics/ExtendedRaw3.java ! test/tools/javac/generics/ExtendedRaw4.java ! test/tools/javac/generics/FinalBridge.java ! test/tools/javac/generics/GenLit1.java ! test/tools/javac/generics/GenLit2.java ! test/tools/javac/generics/GenericAnonCtor.java ! test/tools/javac/generics/GenericMerge.java ! test/tools/javac/generics/GenericOverride.java ! test/tools/javac/generics/GenericThrowable.java ! test/tools/javac/generics/GetClass.java ! test/tools/javac/generics/GetClass2.java ! test/tools/javac/generics/InheritanceConflict.java ! test/tools/javac/generics/InheritanceConflict2.java ! test/tools/javac/generics/InheritanceConflict3.java ! test/tools/javac/generics/InnerInterface1.java ! test/tools/javac/generics/InnerInterface2.java ! test/tools/javac/generics/InstanceOf1.java ! test/tools/javac/generics/InstanceOf2.java ! test/tools/javac/generics/InstanceOf3.java ! test/tools/javac/generics/InterfaceCast1.java ! test/tools/javac/generics/LoadOrder.java ! test/tools/javac/generics/MissingBridge.java ! test/tools/javac/generics/MissingCast.java ! test/tools/javac/generics/Multibound1.java ! test/tools/javac/generics/MultipleInheritance.java ! test/tools/javac/generics/NameOrder.java ! test/tools/javac/generics/Nonlinear.java ! test/tools/javac/generics/ParametricException.java ! test/tools/javac/generics/ParenVerify.java ! test/tools/javac/generics/PermuteBound.java ! test/tools/javac/generics/PrimitiveClass.java ! test/tools/javac/generics/PrimitiveVariant.java ! test/tools/javac/generics/RawClient.java ! test/tools/javac/generics/RefEqual.java ! test/tools/javac/generics/RelaxedArrays.java ! test/tools/javac/generics/ReverseOrder.java ! test/tools/javac/generics/SelfImplement.java ! test/tools/javac/generics/SilentUnchecked.java ! test/tools/javac/generics/SuperTypeargs.java ! test/tools/javac/generics/T4661029.java ! test/tools/javac/generics/T4683314.java ! test/tools/javac/generics/T4684378.java ! test/tools/javac/generics/T4695348.java ! test/tools/javac/generics/T4695415.java ! test/tools/javac/generics/T4695847.java ! test/tools/javac/generics/T4711570.java ! test/tools/javac/generics/T4711572.java ! test/tools/javac/generics/T4711694.java ! test/tools/javac/generics/T4738171.java ! test/tools/javac/generics/T4739399.java ! test/tools/javac/generics/T4757416.java ! test/tools/javac/generics/T4784207a.java ! test/tools/javac/generics/T4784219.java ! test/tools/javac/generics/T5011073.java ! test/tools/javac/generics/T5094318.java ! test/tools/javac/generics/TyparamLit.java ! test/tools/javac/generics/TyparamStaticScope.java ! test/tools/javac/generics/TyparamStaticScope2.java ! test/tools/javac/generics/UncheckedArray.java ! test/tools/javac/generics/UncheckedConstructor.java ! test/tools/javac/generics/UncheckedCovariance.java ! test/tools/javac/generics/UnsoundInference.java ! test/tools/javac/generics/Varargs.java ! test/tools/javac/generics/Varargs2.java ! test/tools/javac/generics/WrongNew.java ! test/tools/javac/generics/abstract/T4717181c.java ! test/tools/javac/generics/bridge1/D.java ! test/tools/javac/generics/classreader/HArrayMethod.java ! test/tools/javac/generics/compat/CovariantCompat1.java ! test/tools/javac/generics/compat/OverrideBridge1.java ! test/tools/javac/generics/forwardSeparateBound/ForwardSeparateBound2.java ! test/tools/javac/generics/genericAbstract/A.java ! test/tools/javac/generics/odersky/BadTest.java ! test/tools/javac/generics/odersky/BadTest2.java ! test/tools/javac/generics/odersky/BadTest3.java ! test/tools/javac/generics/odersky/BadTest4.java ! test/tools/javac/generics/odersky/Test.java ! test/tools/javac/generics/odersky/Test2.java ! test/tools/javac/generics/odersky/Test3.java ! test/tools/javac/generics/odersky/Test4.java ! test/tools/javac/generics/parametricException/J.java ! test/tools/javac/generics/rare/Rare1.java ! test/tools/javac/generics/rare/Rare10.java ! test/tools/javac/generics/rare/Rare11.java ! test/tools/javac/generics/rare/Rare2.java ! test/tools/javac/generics/rare/Rare3.java ! test/tools/javac/generics/rare/Rare4.java ! test/tools/javac/generics/rare/Rare5.java ! test/tools/javac/generics/rare/Rare6.java ! test/tools/javac/generics/rare/Rare7.java ! test/tools/javac/generics/rare/Rare8.java ! test/tools/javac/generics/rare/Rare9.java ! test/tools/javac/generics/rawSeparate/RetroLexer.java ! test/tools/javac/generics/typeargs/Basic.java ! test/tools/javac/generics/typeargs/Metharg1.java ! test/tools/javac/generics/typeargs/Metharg2.java ! test/tools/javac/generics/typeargs/Newarg1.java ! test/tools/javac/generics/typeargs/Newarg2.java ! test/tools/javac/generics/typeargs/Superarg1.java ! test/tools/javac/generics/typeargs/Superarg2.java ! test/tools/javac/generics/typeargs/ThisArg.java ! test/tools/javac/generics/typevars/4856983/T4856983.java ! test/tools/javac/generics/typevars/4856983/T4856983a.java ! test/tools/javac/generics/typevars/4856983/T4856983b.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes1.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes2.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes3.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes4.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes5.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes6.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes7.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes8.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes9.java ! test/tools/javac/generics/wildcards/AssignmentSameType1.java ! test/tools/javac/generics/wildcards/AssignmentSameType2.java ! test/tools/javac/generics/wildcards/AssignmentSameType3.java ! test/tools/javac/generics/wildcards/AssignmentSameType4.java ! test/tools/javac/generics/wildcards/AssignmentSameType5.java ! test/tools/javac/generics/wildcards/AssignmentSameType6.java ! test/tools/javac/generics/wildcards/AssignmentSameType7.java ! test/tools/javac/generics/wildcards/AssignmentSameType8.java ! test/tools/javac/generics/wildcards/BoundBug.java ! test/tools/javac/generics/wildcards/ContraArg.java ! test/tools/javac/generics/wildcards/T5097548.java ! test/tools/javac/generics/wildcards/T5097548b.java ! test/tools/javac/generics/wildcards/UnboundArray.java ! test/tools/javac/generics/wildcards/neg/AmbiguousCast.java ! test/tools/javac/generics/wildcards/neg/Capture.java ! test/tools/javac/generics/wildcards/neg/CastFail1.java ! test/tools/javac/generics/wildcards/neg/CastFail10.java ! test/tools/javac/generics/wildcards/neg/CastFail11.java ! test/tools/javac/generics/wildcards/neg/CastFail12.java ! test/tools/javac/generics/wildcards/neg/CastFail13.java ! test/tools/javac/generics/wildcards/neg/CastFail14.java ! test/tools/javac/generics/wildcards/neg/CastFail15.java ! test/tools/javac/generics/wildcards/neg/CastFail16.java ! test/tools/javac/generics/wildcards/neg/CastFail17.java ! test/tools/javac/generics/wildcards/neg/CastFail18.java ! test/tools/javac/generics/wildcards/neg/CastFail19.java ! test/tools/javac/generics/wildcards/neg/CastFail2.java ! test/tools/javac/generics/wildcards/neg/CastFail20.java ! test/tools/javac/generics/wildcards/neg/CastFail21.java ! test/tools/javac/generics/wildcards/neg/CastFail3.java ! test/tools/javac/generics/wildcards/neg/CastFail4.java ! test/tools/javac/generics/wildcards/neg/CastFail5.java ! test/tools/javac/generics/wildcards/neg/CastFail6.java ! test/tools/javac/generics/wildcards/neg/CastFail7.java ! test/tools/javac/generics/wildcards/neg/CastFail8.java ! test/tools/javac/generics/wildcards/neg/CastFail9.java ! test/tools/javac/generics/wildcards/neg/CastWarn10.java ! test/tools/javac/generics/wildcards/neg/CastWarn11.java ! test/tools/javac/generics/wildcards/neg/CastWarn12.java ! test/tools/javac/generics/wildcards/neg/CastWarn13.java ! test/tools/javac/generics/wildcards/neg/CastWarn14.java ! test/tools/javac/generics/wildcards/neg/CastWarn2.java ! test/tools/javac/generics/wildcards/neg/CastWarn3.java ! test/tools/javac/generics/wildcards/neg/CastWarn4.java ! test/tools/javac/generics/wildcards/neg/CastWarn5.java ! test/tools/javac/generics/wildcards/neg/CastWarn6.java ! test/tools/javac/generics/wildcards/neg/CastWarn7.java ! test/tools/javac/generics/wildcards/neg/CastWarn8.java ! test/tools/javac/generics/wildcards/neg/CastWarn9.java ! test/tools/javac/generics/wildcards/neg/ParamCast.java ! test/tools/javac/generics/wildcards/neg/Readonly.java ! test/tools/javac/generics/wildcards/neg/Unbounded.java ! test/tools/javac/generics/wildcards/pos/AmbiguousCast2.java ! test/tools/javac/generics/wildcards/pos/BoundsCollision.java ! test/tools/javac/generics/wildcards/pos/Capture.java ! test/tools/javac/generics/wildcards/pos/CastTest.java ! test/tools/javac/generics/wildcards/pos/InstanceOf.java ! test/tools/javac/generics/wildcards/pos/ParamCast.java ! test/tools/javac/generics/wildcards/pos/RvalConversion.java ! test/tools/javac/generics/wildcards/pos/UncheckedCast1.java ! test/tools/javac/importscope/A.java ! test/tools/javac/limits/FinallyNesting.java ! test/tools/javac/lint/Unchecked.java ! test/tools/javac/miranda/T4711325.java ! test/tools/javac/mixedTarget/CompatibleAbstracts1.java ! test/tools/javac/mixedTarget/ExtendCovariant2.java ! test/tools/javac/overload/T5090220.java ! test/tools/javac/processing/environment/TestSourceVersion.java ! test/tools/javac/stackmap/UninitThis.java ! test/tools/javac/staticImport/Ambig1.java ! test/tools/javac/staticImport/ImportInherit.java ! test/tools/javac/staticImport/ImportPrivate.java ! test/tools/javac/staticImport/PrivateStaticImport.java ! test/tools/javac/staticImport/Shadow.java ! test/tools/javac/staticImport/StaticImport.java ! test/tools/javac/staticImport/StaticImport2.java ! test/tools/javac/unicode/Unmappable.java ! test/tools/javac/varargs/Anon.java ! test/tools/javac/varargs/BadSyntax2.java ! test/tools/javac/varargs/Varargs1.java ! test/tools/javac/varargs/VarargsOverride.java ! test/tools/javac/varargs/Warn1.java ! test/tools/javac/varargs/Warn2.java ! test/tools/javac/varargs/warning/Warn2.java ! test/tools/javac/varargs/warning/Warn3.java ! test/tools/javadoc/LangVers.java ! test/tools/javadoc/annotations/annotateMethodsFields/Main.java ! test/tools/javadoc/annotations/annotatePackage/Main.java ! test/tools/javadoc/annotations/annotateParams/Main.java ! test/tools/javadoc/annotations/defaults/Main.java ! test/tools/javadoc/annotations/elementTypes/Main.java ! test/tools/javadoc/annotations/shortcuts/Main.java ! test/tools/javadoc/enum/docComments/Main.java ! test/tools/javadoc/enum/enumType/Main.java ! test/tools/javadoc/generics/genericClass/Main.java ! test/tools/javadoc/generics/genericInnerAndOuter/Main.java ! test/tools/javadoc/generics/genericInterface/Main.java ! test/tools/javadoc/generics/genericMethod/Main.java ! test/tools/javadoc/generics/genericSuper/Main.java ! test/tools/javadoc/generics/supertypes/Main.java ! test/tools/javadoc/generics/throwsGeneric/Main.java ! test/tools/javadoc/generics/tparamCycle/Main.java ! test/tools/javadoc/generics/tparamTagOnMethod/Main.java ! test/tools/javadoc/generics/tparamTagOnType/Main.java ! test/tools/javadoc/generics/wildcards/Main.java ! test/tools/javadoc/lib/Tester.java ! test/tools/javadoc/varArgs/Main.java Changeset: d4828eba4939 Author: jjg Date: 2009-05-28 09:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/d4828eba4939 6802102: unignore @ignored tests where possible Reviewed-by: mcimadamore ! test/tools/javac/T6405099.java ! test/tools/javac/api/6431257/T6431257.java ! test/tools/javac/api/TestJavacTaskScanner.java ! test/tools/javac/code/ArrayClone.java - test/tools/javac/code/ArrayClone.sh ! test/tools/javac/generics/inference/6365166/NewTest.java Changeset: 47cf04bb80c9 Author: jjg Date: 2009-05-29 16:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/47cf04bb80c9 6838199: remove support for old javap Reviewed-by: ohair, mcimadamore ! make/build.xml ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/Main.java ! src/share/classes/com/sun/tools/javap/resources/javap.properties - src/share/classes/sun/tools/javap/AttrData.java - src/share/classes/sun/tools/javap/CPX.java - src/share/classes/sun/tools/javap/CPX2.java - src/share/classes/sun/tools/javap/ClassData.java - src/share/classes/sun/tools/javap/Constants.java - src/share/classes/sun/tools/javap/FieldData.java - src/share/classes/sun/tools/javap/InnerClassData.java - src/share/classes/sun/tools/javap/JavapEnvironment.java - src/share/classes/sun/tools/javap/JavapPrinter.java - src/share/classes/sun/tools/javap/LineNumData.java - src/share/classes/sun/tools/javap/LocVarData.java - src/share/classes/sun/tools/javap/Main.java - src/share/classes/sun/tools/javap/MethodData.java - src/share/classes/sun/tools/javap/RuntimeConstants.java - src/share/classes/sun/tools/javap/StackMapData.java - src/share/classes/sun/tools/javap/StackMapTableData.java - src/share/classes/sun/tools/javap/Tables.java - src/share/classes/sun/tools/javap/TrapData.java - src/share/classes/sun/tools/javap/TypeSignature.java ! test/tools/javap/ExtPath.java - test/tools/javap/ListTest.java - test/tools/javap/OptionTest.java Changeset: 163f5d75f77a Author: tbell Date: 2009-06-11 21:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/163f5d75f77a Merge ! make/Makefile ! make/build.xml - src/share/classes/sun/tools/javap/AttrData.java - src/share/classes/sun/tools/javap/CPX.java - src/share/classes/sun/tools/javap/CPX2.java - src/share/classes/sun/tools/javap/ClassData.java - src/share/classes/sun/tools/javap/Constants.java - src/share/classes/sun/tools/javap/FieldData.java - src/share/classes/sun/tools/javap/InnerClassData.java - src/share/classes/sun/tools/javap/JavapEnvironment.java - src/share/classes/sun/tools/javap/JavapPrinter.java - src/share/classes/sun/tools/javap/LineNumData.java - src/share/classes/sun/tools/javap/LocVarData.java - src/share/classes/sun/tools/javap/Main.java - src/share/classes/sun/tools/javap/MethodData.java - src/share/classes/sun/tools/javap/RuntimeConstants.java - src/share/classes/sun/tools/javap/StackMapData.java - src/share/classes/sun/tools/javap/StackMapTableData.java - src/share/classes/sun/tools/javap/Tables.java - src/share/classes/sun/tools/javap/TrapData.java - src/share/classes/sun/tools/javap/TypeSignature.java - test/tools/javac/code/ArrayClone.sh - test/tools/javap/ListTest.java - test/tools/javap/OptionTest.java Changeset: 6855e5aa3348 Author: tbell Date: 2009-06-21 23:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/6855e5aa3348 Merge Changeset: 5c2c81120555 Author: xdono Date: 2009-06-25 12:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/5c2c81120555 Added tag jdk7-b62 for changeset 6855e5aa3348 ! .hgtags From jon.masamitsu at sun.com Thu Jun 25 21:43:06 2009 From: jon.masamitsu at sun.com (jon.masamitsu at sun.com) Date: Fri, 26 Jun 2009 04:43:06 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20090626044319.8B676E206@hg.openjdk.java.net> Changeset: 830ca2573896 Author: tonyp Date: 2009-06-12 16:20 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/830ca2573896 6850846: G1: extend G1 marking verification Summary: extend G1 marking verification to use either the "prev" or "next" marking information, as appropriate. Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 85d0690f7d12 Author: jmasa Date: 2009-06-19 07:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/85d0690f7d12 Merge From dawn2004 at gmail.com Sun Jun 28 20:29:51 2009 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Sun, 28 Jun 2009 20:29:51 -0700 (PDT) Subject: Why does GC need zap unused heap area? Message-ID: <24247943.post@talk.nabble.com> Hi, guys, I have a question about GC. Why does GC need fill the unused heap area with "badHeapWordVal" ("0xbaadbabe")? And when does this happen? Thanks Du Li -- View this message in context: http://www.nabble.com/Why-does-GC-need-zap-unused-heap-area--tp24247943p24247943.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From Y.S.Ramakrishna at Sun.COM Sun Jun 28 22:40:37 2009 From: Y.S.Ramakrishna at Sun.COM (Y. Srinivas Ramakrishna) Date: Sun, 28 Jun 2009 22:40:37 -0700 Subject: Why does GC need zap unused heap area? In-Reply-To: <24247943.post@talk.nabble.com> References: <24247943.post@talk.nabble.com> Message-ID: <4A4853D5.2000204@sun.com> It's just a debugging aid, an indicator that a specific portion of the heap has not yet been allocated to a Java object. It happens when space is first initialized into the heap (at initialization and space expansion) and then when newly freed space is identified by GC at the end of a collection (cycle). As you would have found, in product mode such "zapping" is not done. -- ramki Colin(Du Li) wrote: > Hi, guys, > > I have a question about GC. > Why does GC need fill the unused heap area with "badHeapWordVal" > ("0xbaadbabe")? > And when does this happen? > > Thanks > > Du Li > From dawn2004 at gmail.com Mon Jun 29 00:17:57 2009 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Mon, 29 Jun 2009 00:17:57 -0700 (PDT) Subject: Why does GC need zap unused heap area? In-Reply-To: <4A4853D5.2000204@sun.com> References: <24247943.post@talk.nabble.com> <4A4853D5.2000204@sun.com> Message-ID: <24249435.post@talk.nabble.com> Thanks for your reply! I modified the allocator, and copy some objects to new locations(similar to "clone"). I found some of the objects in new locations are filled with "0xbaadbabe" even if I set the zapping option as "false". I'm wondering who may take the action of filling the heap area with "0xbaadbabe". Could you give me any clue? Thanks again! Colin Y. Srinivas Ramakrishna wrote: > > It's just a debugging aid, an indicator that a specific portion of the > heap has > not yet been allocated to a Java object. It happens when space is > first initialized into the heap (at initialization and space expansion) > and then when newly freed space is identified by GC at the end of > a collection (cycle). As you would have found, in product mode such > "zapping" is not done. > > -- ramki > > Colin(Du Li) wrote: >> Hi, guys, >> >> I have a question about GC. >> Why does GC need fill the unused heap area with "badHeapWordVal" >> ("0xbaadbabe")? >> And when does this happen? >> >> Thanks >> >> Du Li >> > > > -- View this message in context: http://www.nabble.com/Why-does-GC-need-zap-unused-heap-area--tp24247943p24249435.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From David.Holmes at Sun.COM Mon Jun 29 01:47:01 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Mon, 29 Jun 2009 18:47:01 +1000 Subject: Why does GC need zap unused heap area? In-Reply-To: <24249435.post@talk.nabble.com> References: <24247943.post@talk.nabble.com> <4A4853D5.2000204@sun.com> <24249435.post@talk.nabble.com> Message-ID: <4A487F85.9020307@sun.com> Colin, Looks like the filling in is always done in a debug build - regardless of "Zap" flag: ./share/vm/memory/threadLocalAllocBuffer.inline.hpp inline HeapWord* ThreadLocalAllocBuffer::allocate(size_t size) { invariants(); HeapWord* obj = top(); if (pointer_delta(end(), obj) >= size) { // successful thread-local allocation DEBUG_ONLY(Copy::fill_to_words(obj, size, badHeapWordVal)); A grep for badHeapWordVal showed this. HTH David Holmes Colin(Du Li) said the following on 06/29/09 17:17: > Thanks for your reply! > I modified the allocator, and copy some objects to new locations(similar to > "clone"). I found some of the objects in new locations are filled with > "0xbaadbabe" even if I set the zapping option as "false". > I'm wondering who may take the action of filling the heap area with > "0xbaadbabe". Could you give me any clue? > Thanks again! > > Colin > > Y. Srinivas Ramakrishna wrote: >> It's just a debugging aid, an indicator that a specific portion of the >> heap has >> not yet been allocated to a Java object. It happens when space is >> first initialized into the heap (at initialization and space expansion) >> and then when newly freed space is identified by GC at the end of >> a collection (cycle). As you would have found, in product mode such >> "zapping" is not done. >> >> -- ramki >> >> Colin(Du Li) wrote: >>> Hi, guys, >>> >>> I have a question about GC. >>> Why does GC need fill the unused heap area with "badHeapWordVal" >>> ("0xbaadbabe")? >>> And when does this happen? >>> >>> Thanks >>> >>> Du Li >>> >> >> > From erik.trimble at sun.com Tue Jun 30 10:50:47 2009 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Tue, 30 Jun 2009 17:50:47 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20090630175100.6791DE70E@hg.openjdk.java.net> Changeset: a88386380bda Author: xdono Date: 2009-06-18 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a88386380bda Added tag jdk7-b61 for changeset 27b728fd1281 ! .hgtags Changeset: 8754a3c37762 Author: xdono Date: 2009-06-25 12:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8754a3c37762 Added tag jdk7-b62 for changeset a88386380bda ! .hgtags Changeset: f9c95d5dc41f Author: trims Date: 2009-06-25 22:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f9c95d5dc41f Merge Changeset: 32c83fb84370 Author: trims Date: 2009-06-30 10:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/32c83fb84370 6856257: Bump the HS16 build number to 05 Summary: Update the HS16 build number to 05 Reviewed-by: jcoomes ! make/hotspot_version