From Joe.Darcy at Sun.COM Sat Aug 1 21:38:57 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Sat, 01 Aug 2009 21:38:57 -0700 Subject: [FOR REVIEW] hs14 merge for OpenJDK6 In-Reply-To: <4A73E58F.9020502@sun.com> References: <17c6771e0907312044q43080f55y3353927a57dca99f@mail.gmail.com> <4A73E58F.9020502@sun.com> Message-ID: <4A751861.2090901@sun.com> Erik Trimble wrote: > Andrew John Hughes wrote: >> Here it is, the mother of all webrevs: >> >> http://cr.openjdk.java.net/~andrew/jdk6-hs14-merge/webrev.01/ >> >> with the patch itself being ~13mb. >> >> This takes OpenJDK6 up to HotSpot 14 build 16 (see >> http://hg.openjdk.java.net/hsx/hsx14/master/), incorporating 553 >> changesets from the hs14 repo. and one merge changeset. >> I'll shortly push this to http://fuseyism.com/hg/hotspot too. >> >> Ok to push? >> > I approve. > I've taken a look too and don't see anything amiss; approved! Thanks, -Joe From gnu_andrew at member.fsf.org Mon Aug 3 03:02:18 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 3 Aug 2009 11:02:18 +0100 Subject: [FOR REVIEW] hs14 merge for OpenJDK6 In-Reply-To: <4A751861.2090901@sun.com> References: <17c6771e0907312044q43080f55y3353927a57dca99f@mail.gmail.com> <4A73E58F.9020502@sun.com> <4A751861.2090901@sun.com> Message-ID: <17c6771e0908030302k123c206br4a7632fbc77ee0b@mail.gmail.com> 2009/8/2 Joseph D. Darcy : > Erik Trimble wrote: >> >> Andrew John Hughes wrote: >>> >>> Here it is, the mother of all webrevs: >>> >>> http://cr.openjdk.java.net/~andrew/jdk6-hs14-merge/webrev.01/ >>> >>> with the patch itself being ~13mb. >>> >>> This takes OpenJDK6 up to HotSpot 14 build 16 (see >>> http://hg.openjdk.java.net/hsx/hsx14/master/), incorporating 553 >>> changesets from the hs14 repo. and one merge changeset. >>> I'll shortly push this to http://fuseyism.com/hg/hotspot too. >>> >>> Ok to push? >>> >> >> I approve. >> > > I've taken a look too and don't see anything amiss; approved! > > Thanks, > > -Joe > Thanks Erik and Joe for the (very quick) approval! Wasn't expecting that over a weekend :) It looks like pushing isn't working too well though: pushing to ssh://andrew at hg.openjdk.java.net/jdk6/jdk6-gate/hotspot searching for changes remote: adding changesets remote: abort: Permission denied: /hg/jdk6/jdk6-gate/hotspot/.hg/store/00changelog.i abort: unexpected response: empty string I've pushed to various trees before (tl, awt, build, icedtea, cvmi) so I'm guessing this might be related to some permission issues following the replacement of hotspot? Any ideas? CCing Mark Reinhold as well as he manages hg. 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 Vasanth.Venkatachalam at amd.com Tue Aug 4 08:46:34 2009 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Tue, 4 Aug 2009 10:46:34 -0500 Subject: Request for reviews (M): 6580131: Exposing Method Inlining InformationTo JVMTI Agents Message-ID: <7E25251AA9AC1F47937B3C615B77ADA850D6CF@SAUSEXMB2.amd.com> Hi Tom, Thank you for your detailed and insightful feedback on my JVMTI method inlining submission. Sorry for the delay in responding to your comments. We are scoping out the changes that you have recommended. Some of these changes could take longer, but we hope to be able to respond in a few days with some changes or at least a timeline on when we can get them in. Regards, Vasanth -- Vasanth Venkatachalam AMD Java Labs (512)602-6177 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090804/1c9bcac5/attachment.html From Thomas.Rodriguez at Sun.COM Tue Aug 4 15:06:23 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 04 Aug 2009 15:06:23 -0700 Subject: review (XS) for 6868051: (SA) FreeChunk support for compressed oops is broken Message-ID: <683BB62D-6E17-4969-B64D-92D506287766@sun.com> http://cr.openjdk.java.net/~never/6868051/ From Joe.Darcy at Sun.COM Tue Aug 4 17:51:22 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Tue, 04 Aug 2009 17:51:22 -0700 Subject: [FOR REVIEW] hs14 merge for OpenJDK6 In-Reply-To: <17c6771e0908030302k123c206br4a7632fbc77ee0b@mail.gmail.com> References: <17c6771e0907312044q43080f55y3353927a57dca99f@mail.gmail.com> <4A73E58F.9020502@sun.com> <4A751861.2090901@sun.com> <17c6771e0908030302k123c206br4a7632fbc77ee0b@mail.gmail.com> Message-ID: <4A78D78A.5000604@sun.com> Kelly, Do you have any ideas on how to resolve Andrew's push problem? Thanks, -Joe Andrew John Hughes wrote: > 2009/8/2 Joseph D. Darcy : >> Erik Trimble wrote: >>> Andrew John Hughes wrote: >>>> Here it is, the mother of all webrevs: >>>> >>>> http://cr.openjdk.java.net/~andrew/jdk6-hs14-merge/webrev.01/ >>>> >>>> with the patch itself being ~13mb. >>>> >>>> This takes OpenJDK6 up to HotSpot 14 build 16 (see >>>> http://hg.openjdk.java.net/hsx/hsx14/master/), incorporating 553 >>>> changesets from the hs14 repo. and one merge changeset. >>>> I'll shortly push this to http://fuseyism.com/hg/hotspot too. >>>> >>>> Ok to push? >>>> >>> I approve. >>> >> I've taken a look too and don't see anything amiss; approved! >> >> Thanks, >> >> -Joe >> > > > Thanks Erik and Joe for the (very quick) approval! Wasn't expecting > that over a weekend :) > > It looks like pushing isn't working too well though: > > pushing to ssh://andrew at hg.openjdk.java.net/jdk6/jdk6-gate/hotspot > searching for changes > remote: adding changesets > remote: abort: Permission denied: > /hg/jdk6/jdk6-gate/hotspot/.hg/store/00changelog.i > abort: unexpected response: empty string > > I've pushed to various trees before (tl, awt, build, icedtea, cvmi) so > I'm guessing this might be related to some permission issues following > the replacement of hotspot? > > Any ideas? CCing Mark Reinhold as well as he manages hg. > > Thanks, From Tim.Bell at Sun.COM Tue Aug 4 18:08:16 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Tue, 04 Aug 2009 18:08:16 -0700 Subject: [FOR REVIEW] hs14 merge for OpenJDK6 In-Reply-To: <4A78D78A.5000604@sun.com> References: <17c6771e0907312044q43080f55y3353927a57dca99f@mail.gmail.com> <4A73E58F.9020502@sun.com> <4A751861.2090901@sun.com> <17c6771e0908030302k123c206br4a7632fbc77ee0b@mail.gmail.com> <4A78D78A.5000604@sun.com> Message-ID: <4A78DB80.2030504@sun.com> Andrew wrote: >> It looks like pushing isn't working too well though: >> >> pushing to ssh://andrew at hg.openjdk.java.net/jdk6/jdk6-gate/hotspot >> searching for changes >> remote: adding changesets >> remote: abort: Permission denied: >> /hg/jdk6/jdk6-gate/hotspot/.hg/store/00changelog.i >> abort: unexpected response: empty string >> >> I've pushed to various trees before (tl, awt, build, icedtea, cvmi) so >> I'm guessing this might be related to some permission issues following >> the replacement of hotspot? >> >> Any ideas? CCing Mark Reinhold as well as he manages hg. Mark is on vacation, so I took a look at this. The problem seems to be that some files on hg.ojn belong to group 'green' instead of group 'hg'. I reset that. Andrew: please try your push again and let us know how it works. HTH- Tim P.S.: the 'green' group dates back to the early days of the 'Oak' project- long before this thing called Java[tm] was unleashed on the world. It is still around. From gnu_andrew at member.fsf.org Tue Aug 4 18:17:04 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 5 Aug 2009 02:17:04 +0100 Subject: [FOR REVIEW] hs14 merge for OpenJDK6 In-Reply-To: <4A78DB80.2030504@sun.com> References: <17c6771e0907312044q43080f55y3353927a57dca99f@mail.gmail.com> <4A73E58F.9020502@sun.com> <4A751861.2090901@sun.com> <17c6771e0908030302k123c206br4a7632fbc77ee0b@mail.gmail.com> <4A78D78A.5000604@sun.com> <4A78DB80.2030504@sun.com> Message-ID: <17c6771e0908041817h48a5fd1dhcfeb93dc1ae9c0ae@mail.gmail.com> 2009/8/5 Tim Bell : > Andrew wrote: > >>> It looks like pushing isn't working too well though: >>> >>> pushing to ssh://andrew at hg.openjdk.java.net/jdk6/jdk6-gate/hotspot >>> searching for changes >>> remote: adding changesets >>> remote: abort: Permission denied: >>> /hg/jdk6/jdk6-gate/hotspot/.hg/store/00changelog.i >>> abort: unexpected response: empty string >>> >>> I've pushed to various trees before (tl, awt, build, icedtea, cvmi) so >>> I'm guessing this might be related to some permission issues following >>> the replacement of hotspot? >>> >>> Any ideas? CCing Mark Reinhold as well as he manages hg. > > Mark is on vacation, so I took a look at this. ?The problem seems to > be that some files on hg.ojn belong to group 'green' instead of group 'hg'. > I reset that. > > Andrew: please try your push again and let us know how it works. > > HTH- > ?Tim > > P.S.: the 'green' group dates back to the early days of the 'Oak' project- > long before this thing called Java[tm] was unleashed on the world. ?It is > still around. > Nope, still the same error :( -- 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 Tim.Bell at Sun.COM Tue Aug 4 18:33:05 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Tue, 04 Aug 2009 18:33:05 -0700 Subject: [FOR REVIEW] hs14 merge for OpenJDK6 In-Reply-To: <17c6771e0908041817h48a5fd1dhcfeb93dc1ae9c0ae@mail.gmail.com> References: <17c6771e0907312044q43080f55y3353927a57dca99f@mail.gmail.com> <4A73E58F.9020502@sun.com> <4A751861.2090901@sun.com> <17c6771e0908030302k123c206br4a7632fbc77ee0b@mail.gmail.com> <4A78D78A.5000604@sun.com> <4A78DB80.2030504@sun.com> <17c6771e0908041817h48a5fd1dhcfeb93dc1ae9c0ae@mail.gmail.com> Message-ID: <4A78E151.9070304@sun.com> Andrew John Hughes wrote: > Nope, still the same error :( So I needed to fix the group ownership and also add group write permissions on a few files. Andrew: Sorry for the delay - Please try it again? Thanks- Tim From gustav.trede at gmail.com Wed Aug 5 02:19:18 2009 From: gustav.trede at gmail.com (gustav trede) Date: Wed, 5 Aug 2009 11:19:18 +0200 Subject: Math trig intrinsics and compiler options In-Reply-To: <4A5F4343.9020505@Sun.COM> References: <2793ec670907151921p3b558286we89f7e3e0575ed3c@mail.gmail.com> <4A5F4343.9020505@Sun.COM> Message-ID: <311e0eaf0908050219p1e06ecfavdcf8cc6ab4ecd2fa@mail.gmail.com> 2009/7/16 Christian Thalinger > Azeem Jiva wrote: > > Joe, > > Gustav sent me an email asking for help with the intrinsification of > > the trig functions and a suggestion I gave him was to not call > > fsin/fcos/ftan since those instructions are microcoded on Intel/AMD > > hardware and very slow. Slower than the call to > > sharedRuntimeTrig.cpp, and in all cases it's best to stay away from > > the hardware instructions. > > I just did some micro-benchmarking on an Intel Core2 Duo and in the > range of [0,2pi) inlining the hardware instructions is slightly faster > (about 2.5%). Limiting the range to [0,pi/4) (means no runtime calls) > hardware instructions are 1.5x faster. > > I think we should keep the current approach. > > -- Christian > Neither linux nor the windows platform has compiler opts enabled, only solaris does, it seems when this was evaluated many years ago no other platform had working compilers. That fact alone is likely to make the fsin,fcos path faster then the C version for the +-PI/4 range for those platforms. Its some work to check the current status for the different platforms/compilers regarding if they are still producing bad code with opts or not, its however reasonable to expect the compilers to improve over the years. Regarding the proposed patch, sharedRuntimeTrig.cpp usage for the entire input range without external rounding: I compare with 3 input,output pairs that has leaked from the JCK, and vs the current Math impl for many input,output pairs and i don't manage to detect any differences. There is consistent performance improvement for all input ranges, i get up to 40% improvement for intel core2 on solaris. Its hard for me to know if there are some corner cases that do require the external rounding in order to stay within the spec, thats the reason i asked for help here. -- regards gustav trede -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090805/f61ad3db/attachment.html From gnu_andrew at member.fsf.org Wed Aug 5 03:57:49 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 5 Aug 2009 11:57:49 +0100 Subject: [FOR REVIEW] hs14 merge for OpenJDK6 In-Reply-To: <4A78E151.9070304@sun.com> References: <17c6771e0907312044q43080f55y3353927a57dca99f@mail.gmail.com> <4A73E58F.9020502@sun.com> <4A751861.2090901@sun.com> <17c6771e0908030302k123c206br4a7632fbc77ee0b@mail.gmail.com> <4A78D78A.5000604@sun.com> <4A78DB80.2030504@sun.com> <17c6771e0908041817h48a5fd1dhcfeb93dc1ae9c0ae@mail.gmail.com> <4A78E151.9070304@sun.com> Message-ID: <17c6771e0908050357u792fd707h4f28cb9b08e9e395@mail.gmail.com> 2009/8/5 Tim Bell : > Andrew John Hughes wrote: > >> Nope, still the same error :( > > So I needed to fix the group ownership and also add group write permissions > on a few files. > > Andrew: Sorry for the delay - Please try it again? > > Thanks- > > Tim > Thanks Tim, that seems to have fixed the permissions issue. There now seems to be an issue with jcheck, as the merge causes some bugids to be repeated: pushing to ssh://hg.openjdk.java.net/jdk6/jdk6-gate/hotspot searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 555 changesets with 4771 changes to 1453 files remote: remote: > Changeset: 100:d821d920b465 remote: > Author: kvn remote: > Date: 2008-03-11 11:04 remote: > remote: > 6623167: C2 crashed in StoreCMNode::Value remote: > Summary: C2 crashed in StoreCMNode::Value because n->in(MemNode::OopStore) is 0. remote: > Reviewed-by: rasbold, never remote: remote: Bugid 6623167 already used in this repository, in revision 20 remote: remote: > Changeset: 104:2c106685d6d0 remote: > Author: dcubed remote: > Date: 2008-03-12 18:06 remote: > remote: > 6497639: 4/3 Profiling Swing application caused JVM crash remote: > Summary: Make RedefineClasses() interoperate better with class sharing. remote: > Reviewed-by: sspitsyn, jmasa remote: remote: Bugid 6497639 already used in this repository, in revision 20 remote: remote: > Changeset: 105:d8b3ef7ee3e5 remote: > Author: dcubed remote: > Date: 2008-03-12 18:07 remote: > remote: > 6599425: 4/3 OopMapCache::lookup() can cause later crash or assert() failure remote: > Summary: Add should_not_be_cached() to markOop and methodOop and query that status inOopMapCache::lookup() remote: > Reviewed-by: coleenp, sspitsyn, jmasa remote: remote: Bugid 6599425 already used in this repository, in revision 20 remote: remote: > Changeset: 240:65fe2bd88839 remote: > Author: never remote: > Date: 2008-06-05 21:44 remote: > remote: > 6614100: EXCEPTION_ACCESS_VIOLATION while running Eclipse with 1.6.0_05-ea remote: > Reviewed-by: kvn, jrose, rasbold remote: remote: Bugid 6614100 already used in this repository, in revision 20 remote: remote: > Changeset: 286:3e82d72933d0 remote: > Author: xlu remote: > Date: 2008-06-26 14:15 remote: > remote: > 6718830: Hotspot fails to build with gcc 4.3 remote: > Summary: Fixed linux make file and couple adlc code to meet the changes of gcc 4.3 remote: > Reviewed-by: kamg, igor remote: remote: Bugid 6718830 already used in this repository, in revision 32 remote: remote: > Changeset: 289:551f4309f476 remote: > Author: ohair remote: > Date: 2008-07-03 10:46 remote: > remote: > 6695777: Queens.class should be built from source, not put in source repo remote: > Reviewed-by: kvn remote: remote: Bugid 6695777 already used in this repository, in revision 20 remote: remote: > Changeset: 314:54499b980c23 remote: > Author: swamyv remote: > Date: 2008-07-29 13:54 remote: > remote: > 6710791: Remove files or build from source:maf-1_0.jar, jlfg-1_0.jar remote: > Summary: Removed maf-1_0.jar and jlfg-1_0.jar files. remote: > Reviewed-by: poonam, jjh remote: remote: Bugid 6710791 already used in this repository, in revision 20 remote: remote: > Changeset: 360:fa4d1d240383 remote: > Author: never remote: > Date: 2008-08-26 15:49 remote: > remote: > 6741642: bad enum definition in ciTypeFlow.hpp remote: > Reviewed-by: rasbold, martin remote: > Contributed-by: doko at ubuntu.com remote: remote: Bugid 6741642 already used in this repository, in revision 22 remote: remote: > Changeset: 589:748572b86af6 remote: > Author: never remote: > Date: 2009-04-07 14:46 remote: > remote: > 6636360: compiler/6595044/Main.java test fails with 64bit java on solaris-sparcv9 with SIGSEGV remote: > Reviewed-by: kvn, twisti remote: remote: Bugid 6636360 already used in this repository, in revision 29 remote: remote: abort: pretxnchangegroup.0.jcheck hook failed remote: transaction abort! remote: rollback completed abort: unexpected response: empty string Is there a way of getting it to ignore these for this one push? I don't know of a way to just pull out these nine changesets from the 555 waiting to go... -- 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 Tim.Bell at Sun.COM Wed Aug 5 13:53:05 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Wed, 05 Aug 2009 13:53:05 -0700 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <17c6771e0908050357u792fd707h4f28cb9b08e9e395@mail.gmail.com> References: <17c6771e0907312044q43080f55y3353927a57dca99f@mail.gmail.com> <4A73E58F.9020502@sun.com> <4A751861.2090901@sun.com> <17c6771e0908030302k123c206br4a7632fbc77ee0b@mail.gmail.com> <4A78D78A.5000604@sun.com> <4A78DB80.2030504@sun.com> <17c6771e0908041817h48a5fd1dhcfeb93dc1ae9c0ae@mail.gmail.com> <4A78E151.9070304@sun.com> <17c6771e0908050357u792fd707h4f28cb9b08e9e395@mail.gmail.com> Message-ID: <4A79F131.7040105@sun.com> Andrew John Hughes wrote: > Thanks Tim, that seems to have fixed the permissions issue. Good. > There now seems to be an issue with jcheck, as the merge causes some > bugids to be repeated: Hmmm - how did these changesets come in through two different paths? > pushing to ssh://hg.openjdk.java.net/jdk6/jdk6-gate/hotspot > searching for changes > remote: adding changesets > remote: adding manifests > remote: adding file changes > remote: added 555 changesets with 4771 changes to 1453 files > remote: > remote: > Changeset: 100:d821d920b465 > remote: > Author: kvn > remote: > Date: 2008-03-11 11:04 > remote: > > remote: > 6623167: C2 crashed in StoreCMNode::Value > remote: > Summary: C2 crashed in StoreCMNode::Value because > n->in(MemNode::OopStore) is 0. > remote: > Reviewed-by: rasbold, never > remote: > remote: Bugid 6623167 already used in this repository, in revision 20 > remote: > remote: > Changeset: 104:2c106685d6d0 > remote: > Author: dcubed > remote: > Date: 2008-03-12 18:06 > remote: > > remote: > 6497639: 4/3 Profiling Swing application caused JVM crash > remote: > Summary: Make RedefineClasses() interoperate better with > class sharing. > remote: > Reviewed-by: sspitsyn, jmasa > remote: > remote: Bugid 6497639 already used in this repository, in revision 20 > remote: > remote: > Changeset: 105:d8b3ef7ee3e5 > remote: > Author: dcubed > remote: > Date: 2008-03-12 18:07 > remote: > > remote: > 6599425: 4/3 OopMapCache::lookup() can cause later crash or > assert() failure > remote: > Summary: Add should_not_be_cached() to markOop and methodOop > and query that status inOopMapCache::lookup() > remote: > Reviewed-by: coleenp, sspitsyn, jmasa > remote: > remote: Bugid 6599425 already used in this repository, in revision 20 > remote: > remote: > Changeset: 240:65fe2bd88839 > remote: > Author: never > remote: > Date: 2008-06-05 21:44 > remote: > > remote: > 6614100: EXCEPTION_ACCESS_VIOLATION while running Eclipse > with 1.6.0_05-ea > remote: > Reviewed-by: kvn, jrose, rasbold > remote: > remote: Bugid 6614100 already used in this repository, in revision 20 > remote: > remote: > Changeset: 286:3e82d72933d0 > remote: > Author: xlu > remote: > Date: 2008-06-26 14:15 > remote: > > remote: > 6718830: Hotspot fails to build with gcc 4.3 > remote: > Summary: Fixed linux make file and couple adlc code to meet > the changes of gcc 4.3 > remote: > Reviewed-by: kamg, igor > remote: > remote: Bugid 6718830 already used in this repository, in revision 32 > remote: > remote: > Changeset: 289:551f4309f476 > remote: > Author: ohair > remote: > Date: 2008-07-03 10:46 > remote: > > remote: > 6695777: Queens.class should be built from source, not put > in source repo > remote: > Reviewed-by: kvn > remote: > remote: Bugid 6695777 already used in this repository, in revision 20 > remote: > remote: > Changeset: 314:54499b980c23 > remote: > Author: swamyv > remote: > Date: 2008-07-29 13:54 > remote: > > remote: > 6710791: Remove files or build from source:maf-1_0.jar, jlfg-1_0.jar > remote: > Summary: Removed maf-1_0.jar and jlfg-1_0.jar files. > remote: > Reviewed-by: poonam, jjh > remote: > remote: Bugid 6710791 already used in this repository, in revision 20 > remote: > remote: > Changeset: 360:fa4d1d240383 > remote: > Author: never > remote: > Date: 2008-08-26 15:49 > remote: > > remote: > 6741642: bad enum definition in ciTypeFlow.hpp > remote: > Reviewed-by: rasbold, martin > remote: > Contributed-by: doko at ubuntu.com > remote: > remote: Bugid 6741642 already used in this repository, in revision 22 > remote: > remote: > Changeset: 589:748572b86af6 > remote: > Author: never > remote: > Date: 2009-04-07 14:46 > remote: > > remote: > 6636360: compiler/6595044/Main.java test fails with 64bit > java on solaris-sparcv9 with SIGSEGV > remote: > Reviewed-by: kvn, twisti > remote: > remote: Bugid 6636360 already used in this repository, in revision 29 > remote: > remote: abort: pretxnchangegroup.0.jcheck hook failed > remote: transaction abort! > remote: rollback completed > abort: unexpected response: empty string > > Is there a way of getting it to ignore these for this one push? I > don't know of a way to just pull out these nine changesets from the > 555 waiting to go... I think they would need to be added to the jcheck whitelist for all time- but that is more of a question for Mark or Kelly. Tim From gnu_andrew at member.fsf.org Wed Aug 5 16:39:13 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 6 Aug 2009 00:39:13 +0100 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <4A79F131.7040105@sun.com> References: <17c6771e0907312044q43080f55y3353927a57dca99f@mail.gmail.com> <4A73E58F.9020502@sun.com> <4A751861.2090901@sun.com> <17c6771e0908030302k123c206br4a7632fbc77ee0b@mail.gmail.com> <4A78D78A.5000604@sun.com> <4A78DB80.2030504@sun.com> <17c6771e0908041817h48a5fd1dhcfeb93dc1ae9c0ae@mail.gmail.com> <4A78E151.9070304@sun.com> <17c6771e0908050357u792fd707h4f28cb9b08e9e395@mail.gmail.com> <4A79F131.7040105@sun.com> Message-ID: <17c6771e0908051639h4c9a9c79vfdc4f6048d17cca8@mail.gmail.com> 2009/8/5 Tim Bell : > Andrew John Hughes wrote: > >> Thanks Tim, that seems to have fixed the permissions issue. > > Good. > >> There now seems to be an issue with jcheck, as the merge causes some >> bugids to be repeated: > > Hmmm - how did these changesets come in through two different paths? > >> pushing to ssh://hg.openjdk.java.net/jdk6/jdk6-gate/hotspot >> searching for changes >> remote: adding changesets >> remote: adding manifests >> remote: adding file changes >> remote: added 555 changesets with 4771 changes to 1453 files >> remote: >> remote: > Changeset: 100:d821d920b465 >> remote: > Author: ? ?kvn >> remote: > Date: ? ? ?2008-03-11 11:04 >> remote: > >> remote: > 6623167: C2 crashed in StoreCMNode::Value >> remote: > Summary: C2 crashed in StoreCMNode::Value because >> n->in(MemNode::OopStore) is 0. >> remote: > Reviewed-by: rasbold, never >> remote: >> remote: Bugid 6623167 already used in this repository, in revision 20 >> remote: >> remote: > Changeset: 104:2c106685d6d0 >> remote: > Author: ? ?dcubed >> remote: > Date: ? ? ?2008-03-12 18:06 >> remote: > >> remote: > 6497639: 4/3 Profiling Swing application caused JVM crash >> remote: > Summary: Make RedefineClasses() interoperate better with >> class sharing. >> remote: > Reviewed-by: sspitsyn, jmasa >> remote: >> remote: Bugid 6497639 already used in this repository, in revision 20 >> remote: >> remote: > Changeset: 105:d8b3ef7ee3e5 >> remote: > Author: ? ?dcubed >> remote: > Date: ? ? ?2008-03-12 18:07 >> remote: > >> remote: > 6599425: 4/3 OopMapCache::lookup() can cause later crash or >> assert() failure >> remote: > Summary: Add should_not_be_cached() to markOop and methodOop >> and query that status inOopMapCache::lookup() >> remote: > Reviewed-by: coleenp, sspitsyn, jmasa >> remote: >> remote: Bugid 6599425 already used in this repository, in revision 20 >> remote: >> remote: > Changeset: 240:65fe2bd88839 >> remote: > Author: ? ?never >> remote: > Date: ? ? ?2008-06-05 21:44 >> remote: > >> remote: > 6614100: EXCEPTION_ACCESS_VIOLATION while running Eclipse >> with 1.6.0_05-ea >> remote: > Reviewed-by: kvn, jrose, rasbold >> remote: >> remote: Bugid 6614100 already used in this repository, in revision 20 >> remote: >> remote: > Changeset: 286:3e82d72933d0 >> remote: > Author: ? ?xlu >> remote: > Date: ? ? ?2008-06-26 14:15 >> remote: > >> remote: > 6718830: Hotspot fails to build with gcc 4.3 >> remote: > Summary: Fixed linux make file and couple adlc code to meet >> the changes of gcc 4.3 >> remote: > Reviewed-by: kamg, igor >> remote: >> remote: Bugid 6718830 already used in this repository, in revision 32 >> remote: >> remote: > Changeset: 289:551f4309f476 >> remote: > Author: ? ?ohair >> remote: > Date: ? ? ?2008-07-03 10:46 >> remote: > >> remote: > 6695777: Queens.class should be built from source, not put >> in source repo >> remote: > Reviewed-by: kvn >> remote: >> remote: Bugid 6695777 already used in this repository, in revision 20 >> remote: >> remote: > Changeset: 314:54499b980c23 >> remote: > Author: ? ?swamyv >> remote: > Date: ? ? ?2008-07-29 13:54 >> remote: > >> remote: > 6710791: Remove files or build from source:maf-1_0.jar, jlfg-1_0.jar >> remote: > Summary: Removed maf-1_0.jar and jlfg-1_0.jar files. >> remote: > Reviewed-by: poonam, jjh >> remote: >> remote: Bugid 6710791 already used in this repository, in revision 20 >> remote: >> remote: > Changeset: 360:fa4d1d240383 >> remote: > Author: ? ?never >> remote: > Date: ? ? ?2008-08-26 15:49 >> remote: > >> remote: > 6741642: bad enum definition in ciTypeFlow.hpp >> remote: > Reviewed-by: rasbold, martin >> remote: > Contributed-by: doko at ubuntu.com >> remote: >> remote: Bugid 6741642 already used in this repository, in revision 22 >> remote: >> remote: > Changeset: 589:748572b86af6 >> remote: > Author: ? ?never >> remote: > Date: ? ? ?2009-04-07 14:46 >> remote: > >> remote: > 6636360: compiler/6595044/Main.java test fails with 64bit >> java on solaris-sparcv9 with SIGSEGV >> remote: > Reviewed-by: kvn, twisti >> remote: >> remote: Bugid 6636360 already used in this repository, in revision 29 >> remote: >> remote: abort: pretxnchangegroup.0.jcheck hook failed >> remote: transaction abort! >> remote: rollback completed >> abort: unexpected response: empty string >> >> Is there a way of getting it to ignore these for this one push? ?I >> don't know of a way to just pull out these nine changesets from the >> 555 waiting to go... > > I think they would need to be added to the jcheck whitelist for all time- > but that is more of a question for Mark or Kelly. > > Tim > The early revisions (20, 32) are from OpenJDK6 which was rebased to allow HotSpot patches to be applied on top. So what happened here is that, as the fixes were already applied to OpenJDK6, the new changesets pulled in by the merge will be no-ops but still exist to keep the change history accurate. I think we just need a way of disabling this check. OpenJDK6 already has whitespace and comment checks turned to lax. See .jcheck: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/0282bf49b0f6. There may already be an option for this bugid check too, but I have no idea what the format of that file is. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From y.s.ramakrishna at sun.com Wed Aug 5 20:38:22 2009 From: y.s.ramakrishna at sun.com (y.s.ramakrishna at sun.com) Date: Thu, 06 Aug 2009 03:38:22 +0000 Subject: hg: jdk7/hotspot/hotspot: 5 new changesets Message-ID: <20090806033835.A6F28E450@hg.openjdk.java.net> Changeset: 061cd4d965fc Author: jmasa Date: 2009-08-02 18:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/061cd4d965fc 6862534: -XX:NewRatio completely ignored when combined with -XX:+UseConcMarkSweepG Summary: Use NewRatio if it is explicitly set. Reviewed-by: ysr, jcoomes ! src/share/vm/runtime/arguments.cpp Changeset: ff004bcd2596 Author: jmasa Date: 2009-08-02 19:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ff004bcd2596 6843292: "Expect to be beyond new region unless impacting another region" assertion too strong Summary: In the assertion allow for collision with the guard page. Reviewed-by: tonyp, ysr, jcoomes ! src/share/vm/memory/cardTableModRefBS.cpp Changeset: 59726d16b30d Author: jmasa Date: 2009-08-02 22:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/59726d16b30d Merge Changeset: 15c5903cf9e1 Author: johnc Date: 2009-08-03 12:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/15c5903cf9e1 6865703: G1: Parallelize hot card cache cleanup Summary: Have the GC worker threads clear the hot card cache in parallel by having each worker thread claim a chunk of the card cache and process the cards in that chunk. The size of the chunks that each thread will claim is determined at VM initialization from the size of the card cache and the number of worker threads. Reviewed-by: jmasa, tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 6cb8e9df7174 Author: johnc Date: 2009-08-04 16:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6cb8e9df7174 6819077: G1: first GC thread coming late into the GC. Summary: The first worker thread is delayed when entering the GC because it clears the card count table that is used in identifying hot cards. Replace the card count table with a dynamically sized evicting hash table that includes an epoch based counter. Reviewed-by: iveresov, tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! 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/includeDB_gc_g1 From y.s.ramakrishna at sun.com Wed Aug 5 23:01:13 2009 From: y.s.ramakrishna at sun.com (y.s.ramakrishna at sun.com) Date: Thu, 06 Aug 2009 06:01:13 +0000 Subject: hg: jdk7/hotspot/hotspot: 6868991: JPRT: elide GCBasher_G1 test on winx64 until 6867250 is resolved Message-ID: <20090806060119.21EC4E463@hg.openjdk.java.net> Changeset: 703065c670fa Author: ysr Date: 2009-08-05 18:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/703065c670fa 6868991: JPRT: elide GCBasher_G1 test on winx64 until 6867250 is resolved Summary: JPRT: elide GCBasher_G1 test on winx64 until 6867250 is resolved Reviewed-by: jcoomes ! make/jprt.properties From Joe.Darcy at Sun.COM Thu Aug 6 08:58:59 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 06 Aug 2009 08:58:59 -0700 Subject: Math trig intrinsics and compiler options In-Reply-To: <311e0eaf0908050219p1e06ecfavdcf8cc6ab4ecd2fa@mail.gmail.com> References: <2793ec670907151921p3b558286we89f7e3e0575ed3c@mail.gmail.com> <4A5F4343.9020505@Sun.COM> <311e0eaf0908050219p1e06ecfavdcf8cc6ab4ecd2fa@mail.gmail.com> Message-ID: <4A7AFDC3.7080008@sun.com> gustav trede wrote: > 2009/7/16 Christian Thalinger > > > Azeem Jiva wrote: > > Joe, > > Gustav sent me an email asking for help with the > intrinsification of > > the trig functions and a suggestion I gave him was to not call > > fsin/fcos/ftan since those instructions are microcoded on Intel/AMD > > hardware and very slow. Slower than the call to > > sharedRuntimeTrig.cpp, and in all cases it's best to stay away from > > the hardware instructions. > > I just did some micro-benchmarking on an Intel Core2 Duo and in the > range of [0,2pi) inlining the hardware instructions is slightly faster > (about 2.5%). Limiting the range to [0,pi/4) (means no runtime calls) > hardware instructions are 1.5x faster. > > I think we should keep the current approach. > > -- Christian > > > > Neither linux nor the windows platform has compiler opts enabled, only > solaris does, it seems when this was evaluated many years ago no other > platform had working compilers. > That fact alone is likely to make the fsin,fcos path faster then the C > version for the +-PI/4 range for those platforms. > > Its some work to check the current status for the different > platforms/compilers regarding if they are still producing bad code > with opts or not, > its however reasonable to expect the compilers to improve over the years. The code from the non-Sun C compilers is not "bad" per se, it is just bad in not implementing the desired semantics of the FDLIBM code, which is very sensitive to optimizations legal in C which defeat the purpose of the code. The Sun C compiler can be sufficiently attuned to such floating-point need under optimization, the other C compilers were not and I suspect still are not. My preferred long-term approach is to port the FDLIBM C code to Java, which I've wanted to do for a while, but has never bubbled to the top of my to-do list. > > Regarding the proposed patch, sharedRuntimeTrig.cpp usage for the > entire input range without external rounding: > I compare with 3 input,output pairs that has leaked from the JCK, and > vs the current Math impl for many input,output pairs and i don't > manage to detect any differences. What is many? There are on the order of 2^64 inputs to check! -Joe > > There is consistent performance improvement for all input ranges, i > get up to 40% improvement for intel core2 on solaris. > > Its hard for me to know if there are some corner cases that do require > the external rounding in order to stay within the spec, thats the > reason i asked for help here. > > > -- > regards > gustav trede > > From gustav.trede at gmail.com Thu Aug 6 09:31:05 2009 From: gustav.trede at gmail.com (gustav trede) Date: Thu, 6 Aug 2009 18:31:05 +0200 Subject: Math trig intrinsics and compiler options In-Reply-To: <4A7AFDC3.7080008@sun.com> References: <2793ec670907151921p3b558286we89f7e3e0575ed3c@mail.gmail.com> <4A5F4343.9020505@Sun.COM> <311e0eaf0908050219p1e06ecfavdcf8cc6ab4ecd2fa@mail.gmail.com> <4A7AFDC3.7080008@sun.com> Message-ID: <311e0eaf0908060931m591b6b78o957830778fd03385@mail.gmail.com> 2009/8/6 Joseph D. Darcy > gustav trede wrote: > >> 2009/7/16 Christian Thalinger > Christian.Thalinger at sun.com>> >> >> Azeem Jiva wrote: >> > Joe, >> > Gustav sent me an email asking for help with the >> intrinsification of >> > the trig functions and a suggestion I gave him was to not call >> > fsin/fcos/ftan since those instructions are microcoded on Intel/AMD >> > hardware and very slow. Slower than the call to >> > sharedRuntimeTrig.cpp, and in all cases it's best to stay away from >> > the hardware instructions. >> >> I just did some micro-benchmarking on an Intel Core2 Duo and in the >> range of [0,2pi) inlining the hardware instructions is slightly faster >> (about 2.5%). Limiting the range to [0,pi/4) (means no runtime calls) >> hardware instructions are 1.5x faster. >> >> I think we should keep the current approach. >> >> -- Christian >> >> >> >> Neither linux nor the windows platform has compiler opts enabled, only >> solaris does, it seems when this was evaluated many years ago no other >> platform had working compilers. >> That fact alone is likely to make the fsin,fcos path faster then the C >> version for the +-PI/4 range for those platforms. >> >> Its some work to check the current status for the different >> platforms/compilers regarding if they are still producing bad code with opts >> or not, >> its however reasonable to expect the compilers to improve over the years. >> > > The code from the non-Sun C compilers is not "bad" per se, it is just bad > in not implementing the desired semantics of the FDLIBM code, which is very > sensitive to optimizations legal in C which defeat the purpose of the code. > The Sun C compiler can be sufficiently attuned to such floating-point need > under optimization, the other C compilers were not and I suspect still are > not. > > My preferred long-term approach is to port the FDLIBM C code to Java, which > I've wanted to do for a while, but has never bubbled to the top of my to-do > list. > > >> Regarding the proposed patch, sharedRuntimeTrig.cpp usage for the entire >> input range without external rounding: >> I compare with 3 input,output pairs that has leaked from the JCK, and vs >> the current Math impl for many input,output pairs and i don't manage to >> detect any differences. >> > > What is many? There are on the order of 2^64 inputs to check! Yes I'm fully aware of the fact that its hardly practical to check all values, thats why i asked for help with conformance testing. I had the idea that perhaps someone knew if the rounding really is needed for Math trig or its only there for convenience. Answers like that the 1 ulp (cos,sin) fdlibm code is producing "arbitrary bad" values to motivate the need for rounding, that does not give a credible impression. Anyhow i will drop this issue now. Thanks for your time. gustav -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090806/9b1b0183/attachment.html From gnu_andrew at member.fsf.org Thu Aug 6 11:56:26 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 6 Aug 2009 19:56:26 +0100 Subject: Math trig intrinsics and compiler options In-Reply-To: <4A7AFDC3.7080008@sun.com> References: <2793ec670907151921p3b558286we89f7e3e0575ed3c@mail.gmail.com> <4A5F4343.9020505@Sun.COM> <311e0eaf0908050219p1e06ecfavdcf8cc6ab4ecd2fa@mail.gmail.com> <4A7AFDC3.7080008@sun.com> Message-ID: <17c6771e0908061156j6dd45d4blc8d10c356b1d97e8@mail.gmail.com> 2009/8/6 Joseph D. Darcy : > My preferred long-term approach is to port the FDLIBM C code to Java, which > I've wanted to do for a while, but has never bubbled to the top of my to-do > list. > I don't know the full history of it (perhaps mjw can shed some more light), but as far as I'm aware, the Java StrictMath methods in GNU Classpath were written as exactly this: Java versions of the fdlibm code. Developers of Java-based VMs such as JNode and JikesRVM preferred these, because they didn't have to incur the cost of dropping out to native code. -- 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 ian.rogers at manchester.ac.uk Thu Aug 6 17:00:14 2009 From: ian.rogers at manchester.ac.uk (Ian Rogers) Date: Thu, 6 Aug 2009 17:00:14 -0700 Subject: Math trig intrinsics and compiler options In-Reply-To: <17c6771e0908061156j6dd45d4blc8d10c356b1d97e8@mail.gmail.com> References: <2793ec670907151921p3b558286we89f7e3e0575ed3c@mail.gmail.com> <4A5F4343.9020505@Sun.COM> <311e0eaf0908050219p1e06ecfavdcf8cc6ab4ecd2fa@mail.gmail.com> <4A7AFDC3.7080008@sun.com> <17c6771e0908061156j6dd45d4blc8d10c356b1d97e8@mail.gmail.com> Message-ID: 2009/8/6 Andrew John Hughes : > 2009/8/6 Joseph D. Darcy : >> My preferred long-term approach is to port the FDLIBM C code to Java, which >> I've wanted to do for a while, but has never bubbled to the top of my to-do >> list. >> > > I don't know the full history of it (perhaps mjw can shed some more > light), but as far as I'm aware, the Java StrictMath methods in GNU > Classpath were written as exactly this: Java versions of the fdlibm > code. ?Developers of Java-based VMs such as JNode and JikesRVM > preferred these, because they didn't have to incur the cost of > dropping out to native code. Hi Andrew, I don't think we ever implemented this other than in the (never released) Jamaica port of Jikes RVM. Chris Kirkham did that port of fdlibm, perhaps he'd like to share the code :-) Ian -- Metacircular JVM Research - http://mrp.codehaus.org/ From Joe.Darcy at Sun.COM Thu Aug 6 17:49:15 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 06 Aug 2009 17:49:15 -0700 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <17c6771e0908051639h4c9a9c79vfdc4f6048d17cca8@mail.gmail.com> References: <17c6771e0907312044q43080f55y3353927a57dca99f@mail.gmail.com> <4A73E58F.9020502@sun.com> <4A751861.2090901@sun.com> <17c6771e0908030302k123c206br4a7632fbc77ee0b@mail.gmail.com> <4A78D78A.5000604@sun.com> <4A78DB80.2030504@sun.com> <17c6771e0908041817h48a5fd1dhcfeb93dc1ae9c0ae@mail.gmail.com> <4A78E151.9070304@sun.com> <17c6771e0908050357u792fd707h4f28cb9b08e9e395@mail.gmail.com> <4A79F131.7040105@sun.com> <17c6771e0908051639h4c9a9c79vfdc4f6048d17cca8@mail.gmail.com> Message-ID: <4A7B7A0B.6050804@sun.com> Andrew John Hughes wrote: > 2009/8/5 Tim Bell : > >> Andrew John Hughes wrote: >> >> >>> Thanks Tim, that seems to have fixed the permissions issue. >>> >> Good. >> >> >>> There now seems to be an issue with jcheck, as the merge causes some >>> bugids to be repeated: >>> >> Hmmm - how did these changesets come in through two different paths? >> >> >>> pushing to ssh://hg.openjdk.java.net/jdk6/jdk6-gate/hotspot >>> searching for changes >>> remote: adding changesets >>> remote: adding manifests >>> remote: adding file changes >>> remote: added 555 changesets with 4771 changes to 1453 files >>> remote: >>> remote: > Changeset: 100:d821d920b465 >>> remote: > Author: kvn >>> remote: > Date: 2008-03-11 11:04 >>> remote: > >>> remote: > 6623167: C2 crashed in StoreCMNode::Value >>> remote: > Summary: C2 crashed in StoreCMNode::Value because >>> n->in(MemNode::OopStore) is 0. >>> remote: > Reviewed-by: rasbold, never >>> remote: >>> remote: Bugid 6623167 already used in this repository, in revision 20 >>> remote: >>> remote: > Changeset: 104:2c106685d6d0 >>> remote: > Author: dcubed >>> remote: > Date: 2008-03-12 18:06 >>> remote: > >>> remote: > 6497639: 4/3 Profiling Swing application caused JVM crash >>> remote: > Summary: Make RedefineClasses() interoperate better with >>> class sharing. >>> remote: > Reviewed-by: sspitsyn, jmasa >>> remote: >>> remote: Bugid 6497639 already used in this repository, in revision 20 >>> remote: >>> remote: > Changeset: 105:d8b3ef7ee3e5 >>> remote: > Author: dcubed >>> remote: > Date: 2008-03-12 18:07 >>> remote: > >>> remote: > 6599425: 4/3 OopMapCache::lookup() can cause later crash or >>> assert() failure >>> remote: > Summary: Add should_not_be_cached() to markOop and methodOop >>> and query that status inOopMapCache::lookup() >>> remote: > Reviewed-by: coleenp, sspitsyn, jmasa >>> remote: >>> remote: Bugid 6599425 already used in this repository, in revision 20 >>> remote: >>> remote: > Changeset: 240:65fe2bd88839 >>> remote: > Author: never >>> remote: > Date: 2008-06-05 21:44 >>> remote: > >>> remote: > 6614100: EXCEPTION_ACCESS_VIOLATION while running Eclipse >>> with 1.6.0_05-ea >>> remote: > Reviewed-by: kvn, jrose, rasbold >>> remote: >>> remote: Bugid 6614100 already used in this repository, in revision 20 >>> remote: >>> remote: > Changeset: 286:3e82d72933d0 >>> remote: > Author: xlu >>> remote: > Date: 2008-06-26 14:15 >>> remote: > >>> remote: > 6718830: Hotspot fails to build with gcc 4.3 >>> remote: > Summary: Fixed linux make file and couple adlc code to meet >>> the changes of gcc 4.3 >>> remote: > Reviewed-by: kamg, igor >>> remote: >>> remote: Bugid 6718830 already used in this repository, in revision 32 >>> remote: >>> remote: > Changeset: 289:551f4309f476 >>> remote: > Author: ohair >>> remote: > Date: 2008-07-03 10:46 >>> remote: > >>> remote: > 6695777: Queens.class should be built from source, not put >>> in source repo >>> remote: > Reviewed-by: kvn >>> remote: >>> remote: Bugid 6695777 already used in this repository, in revision 20 >>> remote: >>> remote: > Changeset: 314:54499b980c23 >>> remote: > Author: swamyv >>> remote: > Date: 2008-07-29 13:54 >>> remote: > >>> remote: > 6710791: Remove files or build from source:maf-1_0.jar, jlfg-1_0.jar >>> remote: > Summary: Removed maf-1_0.jar and jlfg-1_0.jar files. >>> remote: > Reviewed-by: poonam, jjh >>> remote: >>> remote: Bugid 6710791 already used in this repository, in revision 20 >>> remote: >>> remote: > Changeset: 360:fa4d1d240383 >>> remote: > Author: never >>> remote: > Date: 2008-08-26 15:49 >>> remote: > >>> remote: > 6741642: bad enum definition in ciTypeFlow.hpp >>> remote: > Reviewed-by: rasbold, martin >>> remote: > Contributed-by: doko at ubuntu.com >>> remote: >>> remote: Bugid 6741642 already used in this repository, in revision 22 >>> remote: >>> remote: > Changeset: 589:748572b86af6 >>> remote: > Author: never >>> remote: > Date: 2009-04-07 14:46 >>> remote: > >>> remote: > 6636360: compiler/6595044/Main.java test fails with 64bit >>> java on solaris-sparcv9 with SIGSEGV >>> remote: > Reviewed-by: kvn, twisti >>> remote: >>> remote: Bugid 6636360 already used in this repository, in revision 29 >>> remote: >>> remote: abort: pretxnchangegroup.0.jcheck hook failed >>> remote: transaction abort! >>> remote: rollback completed >>> abort: unexpected response: empty string >>> >>> Is there a way of getting it to ignore these for this one push? I >>> don't know of a way to just pull out these nine changesets from the >>> 555 waiting to go... >>> >> I think they would need to be added to the jcheck whitelist for all time- >> but that is more of a question for Mark or Kelly. >> >> Tim >> >> > > The early revisions (20, 32) are from OpenJDK6 which was rebased to > allow HotSpot patches to be applied on top. So what happened here is > that, as the fixes were already applied to OpenJDK6, the new > changesets pulled in by the merge will be no-ops but still exist to > keep the change history accurate. > > I think we just need a way of disabling this check. OpenJDK6 already > has whitespace and comment checks turned to lax. See .jcheck: > http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/0282bf49b0f6. There > may already be an option for this bugid check too, but I have no idea > what the format of that file is. > *grumble* I'll talk to Mark about this when he is available to discuss the best way to get these changes back. -Joe From gnu_andrew at member.fsf.org Thu Aug 6 18:19:50 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 7 Aug 2009 02:19:50 +0100 Subject: Math trig intrinsics and compiler options In-Reply-To: References: <2793ec670907151921p3b558286we89f7e3e0575ed3c@mail.gmail.com> <4A5F4343.9020505@Sun.COM> <311e0eaf0908050219p1e06ecfavdcf8cc6ab4ecd2fa@mail.gmail.com> <4A7AFDC3.7080008@sun.com> <17c6771e0908061156j6dd45d4blc8d10c356b1d97e8@mail.gmail.com> Message-ID: <17c6771e0908061819h16abbc3bgec783fc275dff0b2@mail.gmail.com> 2009/8/7 Ian Rogers : > 2009/8/6 Andrew John Hughes : >> 2009/8/6 Joseph D. Darcy : >>> My preferred long-term approach is to port the FDLIBM C code to Java, which >>> I've wanted to do for a while, but has never bubbled to the top of my to-do >>> list. >>> >> >> I don't know the full history of it (perhaps mjw can shed some more >> light), but as far as I'm aware, the Java StrictMath methods in GNU >> Classpath were written as exactly this: Java versions of the fdlibm >> code. ?Developers of Java-based VMs such as JNode and JikesRVM >> preferred these, because they didn't have to incur the cost of >> dropping out to native code. > > Hi Andrew, > > I don't think we ever implemented this other than in the (never > released) Jamaica port of Jikes RVM. Chris Kirkham did that port of > fdlibm, perhaps he'd like to share the code :-) > > Ian > -- > Metacircular JVM Research - http://mrp.codehaus.org/ > At a naive glance, this: http://cvs.savannah.gnu.org/viewvc/classpath/java/lang/StrictMath.java?root=classpath&view=markup does seem to have the algorithms (at least <1.6) implemented in Java. It even credits fdlibm. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From john.coomes at sun.com Thu Aug 6 20:40:04 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 07 Aug 2009 03:40:04 +0000 Subject: hg: jdk7/hotspot: 4 new changesets Message-ID: <20090807034004.5A00FE681@hg.openjdk.java.net> Changeset: 59c202ab8a94 Author: jjg Date: 2009-07-27 15:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/59c202ab8a94 6854244: change source/target used to compile JDK to 7 Reviewed-by: ohair ! make/README.pre-components Changeset: fbc75d7ed6dc Author: tbell Date: 2009-07-27 23:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/fbc75d7ed6dc Merge Changeset: e1b972ff53cd Author: tbell Date: 2009-07-30 23:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/e1b972ff53cd Merge Changeset: 82e6c820c51a Author: xdono Date: 2009-08-06 10:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/82e6c820c51a Added tag jdk7-b68 for changeset e1b972ff53cd ! .hgtags From john.coomes at sun.com Thu Aug 6 20:45:42 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 07 Aug 2009 03:45:42 +0000 Subject: hg: jdk7/hotspot/corba: 4 new changesets Message-ID: <20090807034546.D72EFE686@hg.openjdk.java.net> Changeset: 2a160e4e0d06 Author: jjg Date: 2009-07-27 15:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/2a160e4e0d06 6854244: change source/target used to compile JDK to 7 Reviewed-by: ohair ! make/Makefile ! make/common/shared/Defs-java.gmk Changeset: ad500347ebc8 Author: tbell Date: 2009-07-27 23:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/ad500347ebc8 Merge Changeset: 5182bcc9c60c Author: tbell Date: 2009-07-30 23:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/5182bcc9c60c Merge ! make/Makefile ! make/common/shared/Defs-java.gmk Changeset: 8120d308ec4e Author: xdono Date: 2009-08-06 10:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/8120d308ec4e Added tag jdk7-b68 for changeset 5182bcc9c60c ! .hgtags From john.coomes at sun.com Thu Aug 6 20:54:28 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 07 Aug 2009 03:54:28 +0000 Subject: hg: jdk7/hotspot/jaxp: 4 new changesets Message-ID: <20090807035436.00996E68B@hg.openjdk.java.net> Changeset: 59cdcbf2c10d Author: jjg Date: 2009-07-27 15:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/59cdcbf2c10d 6854244: change source/target used to compile JDK to 7 Reviewed-by: ohair ! make/build.properties Changeset: ef9c2dee8a40 Author: tbell Date: 2009-07-27 23:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/ef9c2dee8a40 Merge Changeset: 83b2a9331383 Author: tbell Date: 2009-07-30 23:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/83b2a9331383 Merge ! make/build.properties Changeset: a4ab0d6ded63 Author: xdono Date: 2009-08-06 10:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/a4ab0d6ded63 Added tag jdk7-b68 for changeset 83b2a9331383 ! .hgtags From john.coomes at sun.com Thu Aug 6 21:00:11 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 07 Aug 2009 04:00:11 +0000 Subject: hg: jdk7/hotspot/jaxws: 4 new changesets Message-ID: <20090807040017.8C299E690@hg.openjdk.java.net> Changeset: c5dfd37d18a0 Author: jjg Date: 2009-07-27 15:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/c5dfd37d18a0 6854244: change source/target used to compile JDK to 7 Reviewed-by: ohair ! make/build.properties Changeset: a98e41351006 Author: tbell Date: 2009-07-27 23:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/a98e41351006 Merge Changeset: 845fa487f0f7 Author: tbell Date: 2009-07-30 23:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/845fa487f0f7 Merge ! make/build.properties Changeset: 3e64fdfb9291 Author: xdono Date: 2009-08-06 10:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/3e64fdfb9291 Added tag jdk7-b68 for changeset 845fa487f0f7 ! .hgtags From john.coomes at sun.com Thu Aug 6 21:08:32 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 07 Aug 2009 04:08:32 +0000 Subject: hg: jdk7/hotspot/jdk: 45 new changesets Message-ID: <20090807041910.1CC06E695@hg.openjdk.java.net> Changeset: aaf0cb20646e Author: darcy Date: 2009-07-15 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/aaf0cb20646e 6857789: (reflect) Create common superclass of reflective exceptions Reviewed-by: martin ! src/share/classes/java/lang/ClassNotFoundException.java ! src/share/classes/java/lang/IllegalAccessException.java ! src/share/classes/java/lang/InstantiationException.java ! src/share/classes/java/lang/NoSuchFieldException.java ! src/share/classes/java/lang/NoSuchMethodException.java + src/share/classes/java/lang/ReflectiveOperationException.java ! src/share/classes/java/lang/reflect/InvocationTargetException.java Changeset: 2a1b1075f583 Author: darcy Date: 2009-07-15 14:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2a1b1075f583 6463998: Undocumented NullPointerExeption from Float.parseFloat and Double.parseDouble Reviewed-by: lancea, iris ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java Changeset: 3acfd7c1f984 Author: tbell Date: 2009-07-17 09:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3acfd7c1f984 Merge Changeset: 1203425b5742 Author: mullan Date: 2009-07-20 17:16 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1203425b5742 6787645: CRL validation code should permit some clock skew when checking validity of CRLs Reviewed-by: vinnie ! src/share/classes/java/security/cert/CertPathHelperImpl.java ! src/share/classes/java/security/cert/X509CRLSelector.java ! src/share/classes/sun/security/provider/certpath/CertPathHelper.java ! src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java Changeset: 81e3117803a5 Author: weijun Date: 2009-07-22 16:39 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/81e3117803a5 6858589: more changes to Config on system properties Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! test/sun/security/krb5/ConfPlusProp.java Changeset: 8bb89d9fd061 Author: weijun Date: 2009-07-22 16:40 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8bb89d9fd061 6847026: keytool should be able to generate certreq and cert without subject name Reviewed-by: xuelei ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/util/Resources.java + test/sun/security/tools/keytool/emptysubject.sh Changeset: f4f55c2473b6 Author: weijun Date: 2009-07-22 16:40 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f4f55c2473b6 6854308: more ktab options Reviewed-by: mullan ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java ! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java Changeset: 29b076bfeafd Author: weijun Date: 2009-07-22 16:41 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/29b076bfeafd 6561126: keytool should use larger default keysize for keypairs Reviewed-by: mullan ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/util/Resources.java + test/sun/security/tools/jarsigner/newsize7.sh + test/sun/security/tools/keytool/NewSize7.java Changeset: dba7dc47b78e Author: poonam Date: 2009-07-22 07:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/dba7dc47b78e 6814140: deadlock due to synchronized demandLogger() code that locks ServerLogManager Summary: Making demandLogger() non-synchronized resolves the deadlock. Reviewed-by: dcubed ! src/share/classes/java/util/logging/LogManager.java Changeset: 645c1d0b9db9 Author: chegar Date: 2009-07-23 14:06 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/645c1d0b9db9 6863110: Newly connected/accepted SctpChannel should fire OP_READ if registered with a Selector Reviewed-by: jccollet ! src/solaris/classes/sun/nio/ch/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java ! src/solaris/native/sun/nio/ch/SctpChannelImpl.c + test/com/sun/nio/sctp/SctpChannel/CommUp.java ! test/com/sun/nio/sctp/SctpMultiChannel/Branch.java ! test/com/sun/nio/sctp/SctpMultiChannel/SocketOptionTests.java Changeset: cd7758c85d13 Author: valeriep Date: 2009-07-22 17:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/cd7758c85d13 6823905: crash in sun.security.pkcs11.wrapper.PKCS11.C_Sign during stress-test Summary: Initialize relevant return value to NULL Reviewed-by: vinnie ! src/share/native/sun/security/pkcs11/wrapper/p11_general.c ! src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_objmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h Changeset: 4b287af811ba Author: valeriep Date: 2009-07-23 12:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4b287af811ba Merge Changeset: abb221aa23e4 Author: martin Date: 2009-07-24 18:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/abb221aa23e4 6639443: Character.toCodePoint and Character.toSurrogates can be optimized Summary: rearranging code saves 5 bytes of bytecode Reviewed-by: sherman ! src/share/classes/java/lang/Character.java Changeset: e749fe2ed114 Author: martin Date: 2009-07-24 18:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e749fe2ed114 6639458: Improvements to Surrogate.java Summary: Optimize Surrogate.java Reviewed-by: sherman ! src/share/classes/sun/nio/cs/Surrogate.java Changeset: d78bfd73ee42 Author: xuelei Date: 2009-07-27 22:04 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d78bfd73ee42 6449574: Invalid ldap filter is accepted and processed Reviewed-by: vinnie ! src/share/classes/com/sun/jndi/ldap/Filter.java + test/com/sun/jndi/ldap/BalancedParentheses.java Changeset: 3eb4506815b6 Author: alanb Date: 2009-07-27 18:44 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3eb4506815b6 6863864: (fs) Path.createSymbolicLink doesn't set directory flag when creating sym link to directory (win) Reviewed-by: sherman ! src/windows/classes/sun/nio/fs/WindowsPath.java ! test/java/nio/file/Path/Links.java Changeset: 6fcddeeadd8c Author: alanb Date: 2009-07-27 18:46 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6fcddeeadd8c 6863667: (ch) Several tests in java/nio/channels/* need to be updated after 6638712 Reviewed-by: mcimadamore ! test/java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java ! test/java/nio/channels/AsynchronousChannelGroup/Identity.java ! test/java/nio/channels/AsynchronousChannelGroup/Restart.java ! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java ! test/java/nio/channels/AsynchronousDatagramChannel/Basic.java ! test/java/nio/channels/AsynchronousFileChannel/Basic.java ! test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java ! test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java Changeset: 74c4b8c743fb Author: alanb Date: 2009-07-27 19:22 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/74c4b8c743fb 6864319: (fs) Eliminate static dependency on fdopendir (lnx) Reviewed-by: martin ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c Changeset: 15878be84b9d Author: jjg Date: 2009-07-27 15:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/15878be84b9d 6854244: change source/target used to compile JDK to 7 Reviewed-by: ohair ! make/common/shared/Defs-control.gmk ! make/common/shared/Defs-java.gmk ! make/java/dyn/Makefile Changeset: 056c8e724015 Author: xuelei Date: 2009-07-28 11:15 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/056c8e724015 6865482: test case BalancedParentheses.java is missing GPL header. Reviewed-by: weijun ! test/com/sun/jndi/ldap/BalancedParentheses.java Changeset: aed3ce4ba35b Author: tbell Date: 2009-07-27 23:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/aed3ce4ba35b Merge Changeset: 03b4ab24cd2a Author: jjg Date: 2009-07-29 12:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/03b4ab24cd2a 6865753: 6854244 breaks partial (jdk-only) builds Summary: Makefiles which set -target 5 now need to set -source 5 as well. Reviewed-by: wetmore, tbell ! make/com/sun/crypto/provider/Makefile ! make/javax/crypto/Makefile Changeset: 18fee5159090 Author: tbell Date: 2009-07-30 23:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/18fee5159090 Merge Changeset: f214db928124 Author: art Date: 2009-07-17 15:40 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f214db928124 6844297: java/awt/EventQueue/6638195/bug6638195.java test failed in jdk7 on Windows just on b59,passed on b57 Reviewed-by: bchristi, dcherepanov ! test/java/awt/EventQueue/6638195/bug6638195.java Changeset: 29a065ef8341 Author: dcherepanov Date: 2009-07-22 13:00 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/29a065ef8341 6859935: REGRESSION: Settings are missing in JCP/Advanced tab on windows Reviewed-by: art ! src/windows/classes/sun/awt/windows/WToolkit.java Changeset: ab4860d7cf28 Author: anthony Date: 2009-07-23 13:46 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ab4860d7cf28 6848424: java/awt/Frame/FrameSize/TestFrameSize.java needs improvement Summary: The test now thoroughly verifies the pack() method Reviewed-by: art, dcherepanov ! test/java/awt/Frame/FrameSize/TestFrameSize.java Changeset: 045c3f367b06 Author: dcherepanov Date: 2009-07-27 15:37 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/045c3f367b06 6856929: Frame is not getting resized using Robot in OpenSolaris and Ubuntu Reviewed-by: art, dav ! src/solaris/classes/sun/awt/X11/XRobotPeer.java ! src/solaris/native/sun/awt/awt_Robot.c Changeset: 2fb41bc4d896 Author: yan Date: 2009-07-27 23:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2fb41bc4d896 Merge Changeset: dfd0f4b7c7d1 Author: yan Date: 2009-07-29 00:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/dfd0f4b7c7d1 Merge Changeset: b624f8613cc6 Author: gsm Date: 2009-07-15 19:05 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b624f8613cc6 6612541: api/javax_swing/text/LabelView/index.html#getXXX[LabelView0004] fails since JDK 7 b20 Reviewed-by: peterz ! src/share/classes/javax/swing/text/GlyphView.java Changeset: f727cac13697 Author: malenkov Date: 2009-07-16 20:12 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f727cac13697 6505027: terminateEditOnFocusLost making problems for table in JDesktopPane Reviewed-by: alexp ! src/share/classes/javax/swing/JInternalFrame.java + test/javax/swing/JInternalFrame/Test6505027.java Changeset: 59249ab7aa16 Author: peterz Date: 2009-07-17 15:25 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/59249ab7aa16 6387360: Usage of package-private class as a parameter of a method (javax.swing.text.ParagraphView) Reviewed-by: malenkov ! src/share/classes/javax/swing/text/ParagraphView.java Changeset: 4575323d917c Author: peterz Date: 2009-07-20 13:33 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4575323d917c 6857360: NimbusLAF: Menu indicator looks ugly with RTL orientation. Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/nimbus/NimbusIcon.java ! src/share/classes/sun/swing/MenuItemLayoutHelper.java Changeset: a2114bbf7f3e Author: peterz Date: 2009-07-20 13:34 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a2114bbf7f3e 6849331: Nimbus L&F: AbstractRegionPainter's paint context is not initialized Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java Changeset: 125eff6f653f Author: malenkov Date: 2009-07-22 12:21 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/125eff6f653f 6802868: JInternalFrame is not maximized when maximized parent frame. Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicDesktopIconUI.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameUI.java - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java + test/javax/swing/JInternalFrame/Test6802868.java Changeset: 9fc588f78952 Author: rupashka Date: 2009-07-23 17:56 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9fc588f78952 6460525: javax/swing/JFileChooser/6396844/TwentyThousandTest.java times out Reviewed-by: malenkov, peterz ! src/share/classes/javax/swing/JFileChooser.java ! src/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java ! src/share/classes/sun/awt/shell/ShellFolder.java ! src/share/classes/sun/awt/shell/ShellFolderManager.java ! src/share/classes/sun/swing/FilePane.java ! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java Changeset: 5054103dc032 Author: naoto Date: 2009-06-30 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5054103dc032 6852429: IME should call ImmIsUIMessage() or DefWindowProc() when it receives WM_IME_SETCONTEX Reviewed-by: peytoia ! src/windows/native/sun/windows/awt_Component.cpp Changeset: 584fe3163de9 Author: naoto Date: 2009-07-23 11:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/584fe3163de9 Merge - src/share/classes/java/nio/file/DirectoryStreamFilters.java - src/share/classes/java/nio/file/FileAction.java - src/share/classes/java/nio/file/spi/AbstractPath.java - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java - src/share/classes/sun/io/ByteToCharMS932DB.java - src/share/classes/sun/io/CharToByteMS932DB.java - src/share/classes/sun/nio/cs/ext/EUC_CN.java - src/share/classes/sun/nio/cs/ext/EUC_KR.java - src/share/classes/sun/nio/cs/ext/GBK.java - src/share/classes/sun/nio/cs/ext/Johab.java - src/share/classes/sun/nio/cs/ext/MS932.java - src/share/classes/sun/nio/cs/ext/MS932DB.java - src/share/classes/sun/nio/cs/ext/MS936.java - src/share/classes/sun/nio/cs/ext/MS949.java - src/share/classes/sun/nio/cs/ext/MS950.java - src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java - src/share/classes/sun/nio/fs/MimeType.java - src/share/classes/sun/swing/AccessibleMethod.java ! src/windows/native/sun/windows/awt_Component.cpp - test/java/nio/file/DirectoryStream/Filters.java - test/java/nio/file/Files/content_type.sh - test/java/nio/file/Path/temporary_files.sh - test/java/nio/file/attribute/Attributes/Basic.java Changeset: 80d076251250 Author: yan Date: 2009-07-27 03:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/80d076251250 Merge Changeset: 0ab4157789d9 Author: malenkov Date: 2009-07-28 13:10 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0ab4157789d9 6864297: Right-to-left oriented JScrollPane is aligned to the wrong direction while resizing the container Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java + test/javax/swing/JScrollPane/Test6526631.java + test/javax/swing/SwingTest.java Changeset: 425fcb6d8af4 Author: yan Date: 2009-07-29 00:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/425fcb6d8af4 Merge - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java Changeset: a48b0984ef2e Author: yan Date: 2009-08-05 00:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a48b0984ef2e Merge - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java Changeset: fe61ef5aada9 Author: wetmore Date: 2009-08-03 18:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/fe61ef5aada9 6647452: Remove obfuscation, framework and provider self-verification checking Reviewed-by: valeriep, vinnie ! make/com/sun/crypto/provider/Makefile ! make/javax/crypto/Defs-jce.gmk ! make/javax/crypto/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile ! src/share/classes/com/sun/crypto/provider/AESCipher.java ! src/share/classes/com/sun/crypto/provider/AESKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/AESWrapCipher.java ! src/share/classes/com/sun/crypto/provider/ARCFOURCipher.java ! src/share/classes/com/sun/crypto/provider/BlowfishCipher.java ! src/share/classes/com/sun/crypto/provider/BlowfishKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/DESCipher.java ! src/share/classes/com/sun/crypto/provider/DESKeyFactory.java ! src/share/classes/com/sun/crypto/provider/DESKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/DESedeCipher.java ! src/share/classes/com/sun/crypto/provider/DESedeKeyFactory.java ! src/share/classes/com/sun/crypto/provider/DESedeKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java ! src/share/classes/com/sun/crypto/provider/DHKeyAgreement.java ! src/share/classes/com/sun/crypto/provider/DHKeyFactory.java ! src/share/classes/com/sun/crypto/provider/HmacCore.java ! src/share/classes/com/sun/crypto/provider/HmacMD5.java ! src/share/classes/com/sun/crypto/provider/HmacMD5KeyGenerator.java ! src/share/classes/com/sun/crypto/provider/HmacPKCS12PBESHA1.java ! src/share/classes/com/sun/crypto/provider/HmacSHA1.java ! src/share/classes/com/sun/crypto/provider/HmacSHA1KeyGenerator.java - src/share/classes/com/sun/crypto/provider/JarVerifier.java ! src/share/classes/com/sun/crypto/provider/KeyGeneratorCore.java ! src/share/classes/com/sun/crypto/provider/PBEKeyFactory.java ! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndDESCipher.java ! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndTripleDESCipher.java ! src/share/classes/com/sun/crypto/provider/PBKDF2HmacSHA1Factory.java ! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/RC2Cipher.java ! src/share/classes/com/sun/crypto/provider/RSACipher.java ! src/share/classes/com/sun/crypto/provider/SslMacCore.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java ! src/share/classes/com/sun/crypto/provider/TlsMasterSecretGenerator.java ! src/share/classes/com/sun/crypto/provider/TlsPrfGenerator.java ! src/share/classes/com/sun/crypto/provider/TlsRsaPremasterSecretGenerator.java ! src/share/classes/javax/crypto/JarVerifier.java ! src/share/classes/javax/crypto/JceSecurity.java - src/share/classes/sun/security/pkcs11/JarVerifier.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java - src/windows/classes/sun/security/mscapi/JarVerifier.java ! src/windows/classes/sun/security/mscapi/RSACipher.java ! src/windows/classes/sun/security/mscapi/SunMSCAPI.java Changeset: b23d905cb5d3 Author: xdono Date: 2009-08-05 11:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b23d905cb5d3 Merge - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java Changeset: 9ae4027c5fe1 Author: xdono Date: 2009-08-06 10:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9ae4027c5fe1 Added tag jdk7-b68 for changeset b23d905cb5d3 ! .hgtags From john.coomes at sun.com Thu Aug 6 21:33:44 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 07 Aug 2009 04:33:44 +0000 Subject: hg: jdk7/hotspot/langtools: 12 new changesets Message-ID: <20090807043408.A1522E69A@hg.openjdk.java.net> Changeset: ad07b7ea9685 Author: mcimadamore Date: 2009-07-15 10:25 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/ad07b7ea9685 6846972: cannot access member of raw type when erasure change overriding into overloading Summary: fix of 6400189 caused a nasty problem in method resolution Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/generics/rawOverride/T6846972.java Changeset: 90d40dd5cfc7 Author: mcimadamore Date: 2009-07-15 17:01 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/90d40dd5cfc7 6860795: NullPointerException when compiling a negative java source Summary: Rich formatter shouldn't propagate visits on method symbols that have a null type Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java + test/tools/javac/Diagnostics/6860795/T6860795.java + test/tools/javac/Diagnostics/6860795/T6860795.out Changeset: 86ad2753f3be Author: tbell Date: 2009-07-17 09:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/86ad2753f3be Merge Changeset: 99b7a25185aa Author: jjg Date: 2009-07-23 11:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/99b7a25185aa 6863814: javap crashes when facing array class literals Reviewed-by: jjg Contributed-by: mali at csail.mit.edu ! src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java + test/tools/javap/typeAnnotations/ArrayClassLiterals.java Changeset: 49387c1440d0 Author: jjg Date: 2009-07-23 14:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/49387c1440d0 6863914: bug number missing from test Reviewed-by: tbell ! test/tools/javap/typeAnnotations/ArrayClassLiterals.java Changeset: 631425840408 Author: jjg Date: 2009-07-24 14:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/631425840408 6863746: javap should not scan ct.sym by default Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javap/JavapFileManager.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/Options.java + test/tools/javap/T6863746.java Changeset: d043adadc8b6 Author: darcy Date: 2009-07-26 21:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/d043adadc8b6 6381698: Warn of decommissioning of apt Reviewed-by: jjg ! make/build.properties ! src/share/classes/com/sun/mirror/apt/AnnotationProcessor.java ! src/share/classes/com/sun/mirror/apt/AnnotationProcessorEnvironment.java ! src/share/classes/com/sun/mirror/apt/AnnotationProcessorFactory.java ! src/share/classes/com/sun/mirror/apt/AnnotationProcessorListener.java ! src/share/classes/com/sun/mirror/apt/AnnotationProcessors.java ! src/share/classes/com/sun/mirror/apt/Filer.java ! src/share/classes/com/sun/mirror/apt/Messager.java ! src/share/classes/com/sun/mirror/apt/RoundCompleteEvent.java ! src/share/classes/com/sun/mirror/apt/RoundCompleteListener.java ! src/share/classes/com/sun/mirror/apt/RoundState.java + src/share/classes/com/sun/mirror/apt/package-info.java - src/share/classes/com/sun/mirror/apt/package.html ! src/share/classes/com/sun/mirror/declaration/AnnotationMirror.java ! src/share/classes/com/sun/mirror/declaration/AnnotationTypeDeclaration.java ! src/share/classes/com/sun/mirror/declaration/AnnotationTypeElementDeclaration.java ! src/share/classes/com/sun/mirror/declaration/AnnotationValue.java ! src/share/classes/com/sun/mirror/declaration/ClassDeclaration.java ! src/share/classes/com/sun/mirror/declaration/ConstructorDeclaration.java ! src/share/classes/com/sun/mirror/declaration/Declaration.java ! src/share/classes/com/sun/mirror/declaration/EnumConstantDeclaration.java ! src/share/classes/com/sun/mirror/declaration/EnumDeclaration.java ! src/share/classes/com/sun/mirror/declaration/ExecutableDeclaration.java ! src/share/classes/com/sun/mirror/declaration/FieldDeclaration.java ! src/share/classes/com/sun/mirror/declaration/InterfaceDeclaration.java ! src/share/classes/com/sun/mirror/declaration/MemberDeclaration.java ! src/share/classes/com/sun/mirror/declaration/MethodDeclaration.java ! src/share/classes/com/sun/mirror/declaration/Modifier.java ! src/share/classes/com/sun/mirror/declaration/PackageDeclaration.java ! src/share/classes/com/sun/mirror/declaration/ParameterDeclaration.java ! src/share/classes/com/sun/mirror/declaration/TypeDeclaration.java ! src/share/classes/com/sun/mirror/declaration/TypeParameterDeclaration.java + src/share/classes/com/sun/mirror/declaration/package-info.java - src/share/classes/com/sun/mirror/declaration/package.html ! src/share/classes/com/sun/mirror/type/AnnotationType.java ! src/share/classes/com/sun/mirror/type/ArrayType.java ! src/share/classes/com/sun/mirror/type/ClassType.java ! src/share/classes/com/sun/mirror/type/DeclaredType.java ! src/share/classes/com/sun/mirror/type/EnumType.java ! src/share/classes/com/sun/mirror/type/InterfaceType.java ! src/share/classes/com/sun/mirror/type/MirroredTypeException.java ! src/share/classes/com/sun/mirror/type/MirroredTypesException.java ! src/share/classes/com/sun/mirror/type/PrimitiveType.java ! src/share/classes/com/sun/mirror/type/ReferenceType.java ! src/share/classes/com/sun/mirror/type/TypeMirror.java ! src/share/classes/com/sun/mirror/type/TypeVariable.java ! src/share/classes/com/sun/mirror/type/VoidType.java ! src/share/classes/com/sun/mirror/type/WildcardType.java + src/share/classes/com/sun/mirror/type/package-info.java - src/share/classes/com/sun/mirror/type/package.html ! src/share/classes/com/sun/mirror/util/DeclarationFilter.java ! src/share/classes/com/sun/mirror/util/DeclarationScanner.java ! src/share/classes/com/sun/mirror/util/DeclarationVisitor.java ! src/share/classes/com/sun/mirror/util/DeclarationVisitors.java ! src/share/classes/com/sun/mirror/util/Declarations.java ! src/share/classes/com/sun/mirror/util/SimpleDeclarationVisitor.java ! src/share/classes/com/sun/mirror/util/SimpleTypeVisitor.java ! src/share/classes/com/sun/mirror/util/SourceOrderDeclScanner.java ! src/share/classes/com/sun/mirror/util/SourcePosition.java ! src/share/classes/com/sun/mirror/util/TypeVisitor.java ! src/share/classes/com/sun/mirror/util/Types.java + src/share/classes/com/sun/mirror/util/package-info.java - src/share/classes/com/sun/mirror/util/package.html ! src/share/classes/com/sun/tools/apt/comp/Apt.java ! src/share/classes/com/sun/tools/apt/comp/BootstrapAPF.java ! src/share/classes/com/sun/tools/apt/comp/PrintAP.java ! src/share/classes/com/sun/tools/apt/main/JavaCompiler.java ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/apt/mirror/AptEnv.java ! src/share/classes/com/sun/tools/apt/mirror/apt/AnnotationProcessorEnvironmentImpl.java ! src/share/classes/com/sun/tools/apt/mirror/apt/FilerImpl.java ! src/share/classes/com/sun/tools/apt/mirror/apt/MessagerImpl.java ! src/share/classes/com/sun/tools/apt/mirror/apt/RoundCompleteEventImpl.java ! src/share/classes/com/sun/tools/apt/mirror/apt/RoundStateImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationMirrorImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationTypeDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationTypeElementDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationValueImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/ClassDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/Constants.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/ConstructorDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/DeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/DeclarationMaker.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/EnumConstantDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/EnumDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/ExecutableDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/FieldDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/InterfaceDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/MemberDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/MethodDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/PackageDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/ParameterDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/TypeDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/TypeParameterDeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/AnnotationTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/ArrayTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/ClassTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/DeclaredTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/EnumTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/InterfaceTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/PrimitiveTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/TypeMaker.java ! src/share/classes/com/sun/tools/apt/mirror/type/TypeMirrorImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/TypeVariableImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/VoidTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/WildcardTypeImpl.java ! src/share/classes/com/sun/tools/apt/mirror/util/DeclarationsImpl.java ! src/share/classes/com/sun/tools/apt/mirror/util/SourcePositionImpl.java ! src/share/classes/com/sun/tools/apt/mirror/util/TypesImpl.java ! src/share/classes/com/sun/tools/apt/resources/apt.properties ! test/tools/apt/Basics/apt.sh ! test/tools/apt/Compile/compile.sh Changeset: cf08b64e87da Author: jjg Date: 2009-07-27 15:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/cf08b64e87da 6854244: change source/target used to compile JDK to 7 Reviewed-by: ohair ! make/build.properties Changeset: 7c2d6da61646 Author: jjg Date: 2009-07-27 19:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/7c2d6da61646 6865399: some javac files are missing Sun internal API comment Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/api/DiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/api/Formattable.java ! src/share/classes/com/sun/tools/javac/api/Messages.java ! src/share/classes/com/sun/tools/javac/code/BoundKind.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java ! src/share/classes/com/sun/tools/javac/file/CacheFSInfo.java ! src/share/classes/com/sun/tools/javac/file/FSInfo.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/file/RelativePath.java ! src/share/classes/com/sun/tools/javac/file/SymbolArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/ForwardingDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/Warner.java Changeset: e4ce529b2249 Author: tbell Date: 2009-07-27 23:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/e4ce529b2249 Merge - src/share/classes/com/sun/mirror/apt/package.html - src/share/classes/com/sun/mirror/declaration/package.html - src/share/classes/com/sun/mirror/type/package.html - src/share/classes/com/sun/mirror/util/package.html Changeset: 95c1212b07e3 Author: tbell Date: 2009-07-30 23:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/95c1212b07e3 Merge Changeset: ce9bcdcb7859 Author: xdono Date: 2009-08-06 10:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/ce9bcdcb7859 Added tag jdk7-b68 for changeset 95c1212b07e3 ! .hgtags From gustav.trede at gmail.com Fri Aug 7 01:25:35 2009 From: gustav.trede at gmail.com (gustav trede) Date: Fri, 7 Aug 2009 10:25:35 +0200 Subject: Math trig intrinsics and compiler options In-Reply-To: <17c6771e0908061819h16abbc3bgec783fc275dff0b2@mail.gmail.com> References: <2793ec670907151921p3b558286we89f7e3e0575ed3c@mail.gmail.com> <4A5F4343.9020505@Sun.COM> <311e0eaf0908050219p1e06ecfavdcf8cc6ab4ecd2fa@mail.gmail.com> <4A7AFDC3.7080008@sun.com> <17c6771e0908061156j6dd45d4blc8d10c356b1d97e8@mail.gmail.com> <17c6771e0908061819h16abbc3bgec783fc275dff0b2@mail.gmail.com> Message-ID: <311e0eaf0908070125j3ec6db68r69859bf3ba636819@mail.gmail.com> 2009/8/7 Andrew John Hughes > 2009/8/7 Ian Rogers : > > 2009/8/6 Andrew John Hughes : > >> 2009/8/6 Joseph D. Darcy : > >>> My preferred long-term approach is to port the FDLIBM C code to Java, > which > >>> I've wanted to do for a while, but has never bubbled to the top of my > to-do > >>> list. > >>> > >> > >> I don't know the full history of it (perhaps mjw can shed some more > >> light), but as far as I'm aware, the Java StrictMath methods in GNU > >> Classpath were written as exactly this: Java versions of the fdlibm > >> code. Developers of Java-based VMs such as JNode and JikesRVM > >> preferred these, because they didn't have to incur the cost of > >> dropping out to native code. > > > > Hi Andrew, > > > > I don't think we ever implemented this other than in the (never > > released) Jamaica port of Jikes RVM. Chris Kirkham did that port of > > fdlibm, perhaps he'd like to share the code :-) > > > > Ian > > -- > > Metacircular JVM Research - http://mrp.codehaus.org/ > > > > At a naive glance, this: > > > http://cvs.savannah.gnu.org/viewvc/classpath/java/lang/StrictMath.java?root=classpath&view=markup > > does seem to have the algorithms (at least <1.6) implemented in Java. > It even credits fdlibm. That code has room for some noticeable speedups, one is by refactoring remPiOver2 to not need double[] y as param and do callers following logic from within remPiOver2 instead. Thats possible to do quite nice with overriding an enum method for each usage case that is sent as a param instead of the double[] y. RemPioOver2 then calls the return enum.dostuff(..) when its done and the caller methods get their final result. It saves the need for both the array allocation and the index of bound checks for all its accesses, checks are still there with -XX:+AggressiveOpts . When i tested with b67 the current hotspot does not manage to remove that object allocation by using cpu registers, even on 64 bit jvm with its many registers available. Also breaking up some very large methods into several smaller is a general nice thing to do regarding both performance and OO design. -- regards gustav trede -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090807/c0fca30f/attachment.html From Christian.Thalinger at Sun.COM Fri Aug 7 02:21:56 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 07 Aug 2009 11:21:56 +0200 Subject: Math trig intrinsics and compiler options In-Reply-To: <311e0eaf0908070125j3ec6db68r69859bf3ba636819@mail.gmail.com> References: <2793ec670907151921p3b558286we89f7e3e0575ed3c@mail.gmail.com> <4A5F4343.9020505@Sun.COM> <311e0eaf0908050219p1e06ecfavdcf8cc6ab4ecd2fa@mail.gmail.com> <4A7AFDC3.7080008@sun.com> <17c6771e0908061156j6dd45d4blc8d10c356b1d97e8@mail.gmail.com> <17c6771e0908061819h16abbc3bgec783fc275dff0b2@mail.gmail.com> <311e0eaf0908070125j3ec6db68r69859bf3ba636819@mail.gmail.com> Message-ID: <4A7BF234.4050705@Sun.COM> gustav trede wrote: > When i tested with b67 the current hotspot does not manage to remove > that object allocation by using cpu registers, even on 64 bit jvm with > its many registers available. > Also breaking up some very large methods into several smaller is a > general nice thing to do regarding both performance and OO design. And how is the performance compared to the current implementation? -- Christian From mark at klomp.org Fri Aug 7 02:47:08 2009 From: mark at klomp.org (Mark Wielaard) Date: Fri, 07 Aug 2009 11:47:08 +0200 Subject: Math trig intrinsics and compiler options In-Reply-To: <17c6771e0908061156j6dd45d4blc8d10c356b1d97e8@mail.gmail.com> References: <2793ec670907151921p3b558286we89f7e3e0575ed3c@mail.gmail.com> <4A5F4343.9020505@Sun.COM> <311e0eaf0908050219p1e06ecfavdcf8cc6ab4ecd2fa@mail.gmail.com> <4A7AFDC3.7080008@sun.com> <17c6771e0908061156j6dd45d4blc8d10c356b1d97e8@mail.gmail.com> Message-ID: <1249638428.3477.9.camel@springer.wildebeest.org> Hi, On Thu, 2009-08-06 at 19:56 +0100, Andrew John Hughes wrote: > 2009/8/6 Joseph D. Darcy : > > My preferred long-term approach is to port the FDLIBM C code to Java, which > > I've wanted to do for a while, but has never bubbled to the top of my to-do > > list. > > > I don't know the full history of it (perhaps mjw can shed some more > light), but as far as I'm aware, the Java StrictMath methods in GNU > Classpath were written as exactly this: Java versions of the fdlibm > code. Developers of Java-based VMs such as JNode and JikesRVM > preferred these, because they didn't have to incur the cost of > dropping out to native code. Yes, Eric Blake implemented StrictMath in pure java back in 2002. http://lists.gnu.org/archive/html/classpath/2002-02/msg00173.html The discussion thread is interesting. As Eric said "converting arcane C to Java is not an exercise for the weak-minded :)". I believe this was originally done because of an initial misunderstanding that StrictMath had to be pure java strictfp. So Eric went off and just did that instead of plopping in fdlibm. So in GNU Classpath StrictMath is pure (strictfp) java, but Math uses VMMath intrinsics. If the VM doesn't implement those itself those fall back on the fdlibm c code (it could also have fallen back on the StrictMath implementation of course, but Math was written and used fdlibm before StrictMath was implemented). One drawback of having StrictMath in java itself is that not all VMs actually support strictfp mode. For such VMs falling back to the fdlibm c implementation would have been better. Cheers, Mark From vladimir.kozlov at sun.com Fri Aug 7 02:52:08 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 07 Aug 2009 09:52:08 +0000 Subject: hg: jdk7/hotspot/hotspot: 15 new changesets Message-ID: <20090807095250.A4D93E751@hg.openjdk.java.net> Changeset: a94af87c3357 Author: never Date: 2009-07-24 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a94af87c3357 6861984: solaris version of libsaproc.so should support SA_ALTROOT directly Reviewed-by: kvn, twisti ! agent/make/saenv.sh ! agent/make/saenv64.sh ! agent/src/os/solaris/proc/Makefile ! agent/src/os/solaris/proc/mapfile ! agent/src/os/solaris/proc/saproc.cpp + agent/src/os/solaris/proc/saproc_audit.cpp Changeset: dd0a4e1e219b Author: kvn Date: 2009-07-26 12:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/dd0a4e1e219b 6851386: assert(b->find_node(def) < j,"uses must follow definitions") Summary: Add additional check for a tight loop. Reviewed-by: never ! src/share/vm/opto/block.cpp Changeset: 665be97e8704 Author: kvn Date: 2009-07-26 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/665be97e8704 6863420: os::javaTimeNanos() go backward on Solaris x86 Summary: Use new atomic long load method Atomic::load() to load max_hrtime. Reviewed-by: never, ysr, johnc, phh, dcubed, acorn ! src/os/solaris/vm/os_solaris.cpp ! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp ! src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/share/vm/runtime/atomic.hpp + test/compiler/6863420/Test.java Changeset: 94b6d06fd759 Author: twisti Date: 2009-07-20 08:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/94b6d06fd759 6860920: serialize.cpp shouldn't use objArrayOopDesc::base_offset_in_bytes(T_BYTE) Summary: serialize.cpp currently uses objArrayOopDesc::base_offset_in_bytes(T_BYTE), which seems to be wrong. Reviewed-by: coleenp, kvn ! src/share/vm/memory/serialize.cpp ! src/share/vm/oops/objArrayOop.hpp ! src/share/vm/opto/library_call.cpp Changeset: 1cef5ec3ca56 Author: twisti Date: 2009-07-27 06:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1cef5ec3ca56 Merge ! src/share/vm/opto/library_call.cpp Changeset: 52898b0c43e9 Author: twisti Date: 2009-07-28 09:02 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/52898b0c43e9 6863155: Server compiler generates incorrect code (x86, long, bitshift, bitmask) Summary: Code compiled with server compiler generates an incorrect result. Reviewed-by: cfang, never, kvn ! src/share/vm/opto/mulnode.cpp + test/compiler/6863155/Test6863155.java Changeset: 60fea60a6db5 Author: kvn Date: 2009-07-30 16:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/60fea60a6db5 6864914: SPECjvm2008 produces invalid result with zero based Compressed Oops Summary: Always use "lea" instruction for narrow oop decoding instead of "shift". Reviewed-by: never ! src/cpu/x86/vm/assembler_x86.cpp Changeset: 55cb84cd1247 Author: kvn Date: 2009-07-31 12:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/55cb84cd1247 6865031: Application gives bad result (throws bad exception) with compressed oops Summary: Produce narrow type for new Phi from the original Phi type. Reviewed-by: cfang ! src/share/vm/opto/cfgnode.cpp + test/compiler/6865031/Test.java Changeset: 9987d9d5eb0e Author: cfang Date: 2009-07-31 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9987d9d5eb0e 6833129: specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot Summary: developed a reexecute logic for the interpreter to reexecute the bytecode when deopt happens Reviewed-by: kvn, never, jrose, twisti ! agent/src/share/classes/sun/jvm/hotspot/code/DebugInfoReadStream.java ! agent/src/share/classes/sun/jvm/hotspot/code/PCDesc.java ! agent/src/share/classes/sun/jvm/hotspot/code/ScopeDesc.java ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/code/debugInfo.hpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/debugInfoRec.hpp ! src/share/vm/code/scopeDesc.cpp ! src/share/vm/code/scopeDesc.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/runtime/vframe.hpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vframeArray.hpp ! src/share/vm/runtime/vframe_hp.cpp ! src/share/vm/runtime/vframe_hp.hpp + test/compiler/6833129/Test.java Changeset: 2b9164d13ce9 Author: kvn Date: 2009-08-04 17:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2b9164d13ce9 6868486: timouts and outOfMemory in regression tests Summary: Increase timeout for tests and heap size for 6851282 test. Reviewed-by: never, cfang ! test/compiler/6826736/Test.java ! test/compiler/6851282/Test.java Changeset: fc2281ddce3c Author: cfang Date: 2009-08-04 21:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fc2281ddce3c 6868269: CompileTheWorld assertion failure introduced by the reexecute bit implementation Summary: Improvement on reexecute implementation to fix the assertion failure Reviewed-by: kvn, never ! src/share/vm/opto/library_call.cpp Changeset: 15bbd3f505c0 Author: kvn Date: 2009-08-06 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/15bbd3f505c0 Merge ! agent/src/share/classes/sun/jvm/hotspot/code/DebugInfoReadStream.java ! agent/src/share/classes/sun/jvm/hotspot/code/ScopeDesc.java ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/runtime/vframe.hpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vframe_hp.cpp Changeset: ef671fb22f73 Author: never Date: 2009-08-06 12:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ef671fb22f73 6868051: (SA) FreeChunk support for compressed oops is broken Reviewed-by: kvn, dcubed ! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java ! agent/src/share/classes/sun/jvm/hotspot/memory/FreeChunk.java Changeset: bd2b1f617a4e Author: jrose Date: 2009-08-06 14:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/bd2b1f617a4e 6868487: EnableInvokeDynamic and EnableMethodHandles should not be visible flags in JDK6 or JDK7 Summary: switch them from product to experimental; 6817525 will toggle them and switch to diagnostic Reviewed-by: kvn ! src/share/vm/runtime/globals.hpp Changeset: 9c65a08a31a3 Author: jrose Date: 2009-08-06 16:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9c65a08a31a3 Merge From gustav.trede at gmail.com Fri Aug 7 03:19:00 2009 From: gustav.trede at gmail.com (gustav trede) Date: Fri, 7 Aug 2009 12:19:00 +0200 Subject: Math trig intrinsics and compiler options In-Reply-To: <4A7BF234.4050705@Sun.COM> References: <2793ec670907151921p3b558286we89f7e3e0575ed3c@mail.gmail.com> <4A5F4343.9020505@Sun.COM> <311e0eaf0908050219p1e06ecfavdcf8cc6ab4ecd2fa@mail.gmail.com> <4A7AFDC3.7080008@sun.com> <17c6771e0908061156j6dd45d4blc8d10c356b1d97e8@mail.gmail.com> <17c6771e0908061819h16abbc3bgec783fc275dff0b2@mail.gmail.com> <311e0eaf0908070125j3ec6db68r69859bf3ba636819@mail.gmail.com> <4A7BF234.4050705@Sun.COM> Message-ID: <311e0eaf0908070319y1ede64d3vebbced9df0332f10@mail.gmail.com> 2009/8/7 Christian Thalinger > gustav trede wrote: > > When i tested with b67 the current hotspot does not manage to remove > > that object allocation by using cpu registers, even on 64 bit jvm with > > its many registers available. > > Also breaking up some very large methods into several smaller is a > > general nice thing to do regarding both performance and OO design. > > And how is the performance compared to the current implementation? > > -- Christian > That implementation has done some optimizations that causes loss of accuracy: sin Double.longBitsToDouble(0xc01921fb54442d18L) should give Double.longBitsToDouble(0x3cb1a62633145c07L) but it fails with 285703 ulps. It also seems to never complete for for some input values, cos 1.7976931348623157E308 is one example. There are working java implementations, one is: http://www-sop.inria.fr/oasis/ProActive2/doc/release-doc/ProActive_src_html/org/objectweb/proactive/examples/profractal/JMath.java.html That one at least passes my informal tests, matching current strictmath results exactly for billions of values regarding cos, sin at least. performance difference depends heavily on platform, i will remove the double[] y usage and compare with the current solaris version, that seems to be the fastest one. -- regards gustav trede -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090807/b7f5a519/attachment.html From gnu_andrew at member.fsf.org Fri Aug 7 03:44:01 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 7 Aug 2009 11:44:01 +0100 Subject: Math trig intrinsics and compiler options In-Reply-To: <311e0eaf0908070125j3ec6db68r69859bf3ba636819@mail.gmail.com> References: <2793ec670907151921p3b558286we89f7e3e0575ed3c@mail.gmail.com> <4A5F4343.9020505@Sun.COM> <311e0eaf0908050219p1e06ecfavdcf8cc6ab4ecd2fa@mail.gmail.com> <4A7AFDC3.7080008@sun.com> <17c6771e0908061156j6dd45d4blc8d10c356b1d97e8@mail.gmail.com> <17c6771e0908061819h16abbc3bgec783fc275dff0b2@mail.gmail.com> <311e0eaf0908070125j3ec6db68r69859bf3ba636819@mail.gmail.com> Message-ID: <17c6771e0908070344n65f3b626o526a21199d8755fe@mail.gmail.com> 2009/8/7 gustav trede : > > > 2009/8/7 Andrew John Hughes >> >> 2009/8/7 Ian Rogers : >> > 2009/8/6 Andrew John Hughes : >> >> 2009/8/6 Joseph D. Darcy : >> >>> My preferred long-term approach is to port the FDLIBM C code to Java, >> >>> which >> >>> I've wanted to do for a while, but has never bubbled to the top of my >> >>> to-do >> >>> list. >> >>> >> >> >> >> I don't know the full history of it (perhaps mjw can shed some more >> >> light), but as far as I'm aware, the Java StrictMath methods in GNU >> >> Classpath were written as exactly this: Java versions of the fdlibm >> >> code. ?Developers of Java-based VMs such as JNode and JikesRVM >> >> preferred these, because they didn't have to incur the cost of >> >> dropping out to native code. >> > >> > Hi Andrew, >> > >> > I don't think we ever implemented this other than in the (never >> > released) Jamaica port of Jikes RVM. Chris Kirkham did that port of >> > fdlibm, perhaps he'd like to share the code :-) >> > >> > Ian >> > -- >> > Metacircular JVM Research - http://mrp.codehaus.org/ >> > >> >> At a naive glance, this: >> >> >> http://cvs.savannah.gnu.org/viewvc/classpath/java/lang/StrictMath.java?root=classpath&view=markup >> >> does seem to have the algorithms (at least <1.6) implemented in Java. >> It even credits fdlibm. > > That code has room for some noticeable speedups, one is by refactoring > remPiOver2 to not need double[] y as param and do callers following logic > from within remPiOver2 instead. > Thats possible to do quite nice with overriding an enum method for each > usage case that is sent as a param instead of the double[] y. > RemPioOver2 then calls the return enum.dostuff(..) when its done and the > caller methods get their final result. > It saves the need for both the array allocation and the index of bound > checks for all its accesses, checks are still there with -XX:+AggressiveOpts > . > When i tested with b67 the current hotspot does not manage to remove that > object allocation by using cpu registers, even on 64 bit jvm with its many > registers available. Nice; remember that there were no enums when this was written... :) > Also breaking up some very large methods into several smaller is a general > nice thing to do regarding both performance and OO design. > > -- > regards > ?gustav trede > > > -- 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 gustav.trede at gmail.com Sun Aug 9 12:04:09 2009 From: gustav.trede at gmail.com (gustav trede) Date: Sun, 9 Aug 2009 21:04:09 +0200 Subject: Math trig intrinsics and compiler options In-Reply-To: <4A5E0AA0.4080306@sun.com> References: <311e0eaf0907150543v5d877f55t3e6377b88ea43008@mail.gmail.com> <4A5DD7E9.8070904@Sun.COM> <4A5E0AA0.4080306@sun.com> Message-ID: <311e0eaf0908091204s57ea5b36r13b192b74f10fa47@mail.gmail.com> Hello , I have some questions regarding java impl of the fdlibm code. What methods if any needs to be declared as strictfp, i assume where its needed its for both math and strictmath ? I currently do not need to use it to get results to exactly match strictmath, but perhaps thats 'luck' and it will break on other cpu or platforms and to rely on that its a known jdk impl we run on with its characteristics is not a safe. Should StrictMath itself contain the massive implementations or delegate, replacing the native calls with a single line ? The algorithm specific doc per method for fdlibm would be nice to conserve , that would be natural to have as method jdoc in a delegate class. Or how do you want it done ? Regarding conformance testing, i try to do the best i can considering no JCK access and that im not an expert the the math used in the algorithms. I carefully lookup all crossover values for the different algorithm paths in the code, +- 100 million ulps around each value along with more silly tests like around each possible 2 exponent for double. for tan, cos , sin the results matches the current strictmath exactly, I have not tested the rest of the methods yet. Im still trying to figure out best impl for cos, sin, tan due to that as soon as you dont do simple loop tests but something more real life based, the different code paths is inlined and it becomes slow large blob of it. The performance boost is massive compared to the current jdk impl on solaris (and thats the fasted platform for jdk trig impl) , 21 vs 97 cycles for sin +-pi/4 on intel core2 , but its not nice when its not stable , can currently differ with a factor of up to 2 on some cases for certain input ranges.. So will work on stabilizing as high as possible real world performance by comparing different approaches. regards gustav -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090809/1a3116a3/attachment.html From y.s.ramakrishna at sun.com Sun Aug 9 22:10:23 2009 From: y.s.ramakrishna at sun.com (y.s.ramakrishna at sun.com) Date: Mon, 10 Aug 2009 05:10:23 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20090810051032.8F449E956@hg.openjdk.java.net> Changeset: 3ee342e25e57 Author: jcoomes Date: 2009-08-05 12:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3ee342e25e57 6821693: 64-bit TaskQueue capacity still too small 6821507: Alignment problem in GC taskqueue Reviewed-by: tonyp, apetrusenko ! src/share/vm/utilities/taskqueue.hpp Changeset: b1773b9a2ca1 Author: ysr Date: 2009-08-09 17:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b1773b9a2ca1 Merge From Joe.Darcy at Sun.COM Mon Aug 10 10:52:37 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Mon, 10 Aug 2009 10:52:37 -0700 Subject: Math trig intrinsics and compiler options In-Reply-To: <311e0eaf0908091204s57ea5b36r13b192b74f10fa47@mail.gmail.com> References: <311e0eaf0907150543v5d877f55t3e6377b88ea43008@mail.gmail.com> <4A5DD7E9.8070904@Sun.COM> <4A5E0AA0.4080306@sun.com> <311e0eaf0908091204s57ea5b36r13b192b74f10fa47@mail.gmail.com> Message-ID: <4A805E65.3050201@sun.com> gustav trede wrote: > Hello , > > I have some questions regarding java impl of the fdlibm code. > > What methods if any needs to be declared as strictfp, i assume where > its needed its for both math and strictmath ? No, not all methods in Math or even StrictMath need to be declared strictfp. While it is safe to put strictfp everywhere, just putting it where required can requite a subtle analysis. -Joe From gustav.trede at gmail.com Tue Aug 11 00:53:08 2009 From: gustav.trede at gmail.com (gustav trede) Date: Tue, 11 Aug 2009 09:53:08 +0200 Subject: Math trig intrinsics and compiler options In-Reply-To: <311e0eaf0908070319y1ede64d3vebbced9df0332f10@mail.gmail.com> References: <2793ec670907151921p3b558286we89f7e3e0575ed3c@mail.gmail.com> <4A5F4343.9020505@Sun.COM> <311e0eaf0908050219p1e06ecfavdcf8cc6ab4ecd2fa@mail.gmail.com> <4A7AFDC3.7080008@sun.com> <17c6771e0908061156j6dd45d4blc8d10c356b1d97e8@mail.gmail.com> <17c6771e0908061819h16abbc3bgec783fc275dff0b2@mail.gmail.com> <311e0eaf0908070125j3ec6db68r69859bf3ba636819@mail.gmail.com> <4A7BF234.4050705@Sun.COM> <311e0eaf0908070319y1ede64d3vebbced9df0332f10@mail.gmail.com> Message-ID: <311e0eaf0908110053p540b7857w60a5c42253e7d599@mail.gmail.com> 2009/8/7 gustav trede > > > There are working java implementations, one is: > > http://www-sop.inria.fr/oasis/ProActive2/doc/release-doc/ProActive_src_html/org/objectweb/proactive/examples/profractal/JMath.java.html I withdraw that statement =) bitoperators like & was changed to multiply on several places and a few if then code paths was wrongly done . Im working on sqrt at the moment, using the fdlibm c code in openjdk instead of trying to be clever and reuse the badly broken java ports on the net. -- regards gustav trede -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090811/f0e11758/attachment.html From bockisch at informatik.tu-darmstadt.de Tue Aug 11 10:54:01 2009 From: bockisch at informatik.tu-darmstadt.de (Christoph Bockisch) Date: Tue, 11 Aug 2009 19:54:01 +0200 Subject: Invitation to submit to VMIL'09 [1 week extension] Message-ID: <4A81B039.9010704@informatik.tu-darmstadt.de> Dear Colleagues: It gives us great pleasure to invite you to submit your contributions to **the third international workshop on Virtual Machines and Intermediate Languages (VMIL 2009)**, which will be co-located with OOPSLA 2009. This workshop is a forum for research in virtual machines (VM) and intermediate languages (IL). It is dedicated to identifying programming mechanisms and constructs that are currently realized as code transformations or implemented in libraries but should rather be supported at VM and IL level. -------------------------------------------------------------------- **Invited Talks** VMIL 2009 will feature talks by Steve Blackburn, Vivek Sarkar and Doug Simon (tentative). -------------------------------------------------------------------- **Due Dates** Full papers are due Aug 22, 2009. Abstract submission is recommended but not required. -------------------------------------------------------------------- **PC** We have once again assembled an excellent program committee which consists of Eric Bodden, Alex Buckley, Andreas Gal, Doug Lea, Stefan Marr, Filip Pizlo, Andreas Sewe, Jan Vitek, and the organizers. -------------------------------------------------------------------- For more details please see: http://www.cs.iastate.edu/~design/vmil/ We look forward to your submissions to VMIL 2009. Best regards, Hridesh Rajan, Christoph Bockisch, Michael Haupt, and Robert Dyer VMIL 2009 Organizers From john.cuthbertson at sun.com Thu Aug 13 17:36:11 2009 From: john.cuthbertson at sun.com (john.cuthbertson at sun.com) Date: Fri, 14 Aug 2009 00:36:11 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20090814003632.11C3BED4E@hg.openjdk.java.net> Changeset: b32a809aab08 Author: jcoomes Date: 2009-08-11 23:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b32a809aab08 6866585: debug code in ciObjectFactory too slow for large objects Reviewed-by: ysr, never, kvn ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/runtime/globals.hpp Changeset: 10d8c0d0d60e Author: jcoomes Date: 2009-08-12 14:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/10d8c0d0d60e 6867645: java -Xshare:dump failed - read only space too small Reviewed-by: iveresov, tonyp, ysr ! src/share/vm/runtime/globals.hpp From Joe.Darcy at Sun.COM Thu Aug 13 17:36:36 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Thu, 13 Aug 2009 17:36:36 -0700 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <17c6771e0908051639h4c9a9c79vfdc4f6048d17cca8@mail.gmail.com> References: <17c6771e0907312044q43080f55y3353927a57dca99f@mail.gmail.com> <4A73E58F.9020502@sun.com> <4A751861.2090901@sun.com> <17c6771e0908030302k123c206br4a7632fbc77ee0b@mail.gmail.com> <4A78D78A.5000604@sun.com> <4A78DB80.2030504@sun.com> <17c6771e0908041817h48a5fd1dhcfeb93dc1ae9c0ae@mail.gmail.com> <4A78E151.9070304@sun.com> <17c6771e0908050357u792fd707h4f28cb9b08e9e395@mail.gmail.com> <4A79F131.7040105@sun.com> <17c6771e0908051639h4c9a9c79vfdc4f6048d17cca8@mail.gmail.com> Message-ID: <4A84B194.1070108@sun.com> Andrew John Hughes wrote: > 2009/8/5 Tim Bell : > >> Andrew John Hughes wrote: >> >> >>> Thanks Tim, that seems to have fixed the permissions issue. >>> >> Good. >> >> >>> There now seems to be an issue with jcheck, as the merge causes some >>> bugids to be repeated: >>> >> Hmmm - how did these changesets come in through two different paths? >> >> >>> pushing to ssh://hg.openjdk.java.net/jdk6/jdk6-gate/hotspot >>> searching for changes >>> remote: adding changesets >>> remote: adding manifests >>> remote: adding file changes >>> remote: added 555 changesets with 4771 changes to 1453 files >>> remote: >>> remote: > Changeset: 100:d821d920b465 >>> remote: > Author: kvn >>> remote: > Date: 2008-03-11 11:04 >>> remote: > >>> remote: > 6623167: C2 crashed in StoreCMNode::Value >>> remote: > Summary: C2 crashed in StoreCMNode::Value because >>> n->in(MemNode::OopStore) is 0. >>> remote: > Reviewed-by: rasbold, never >>> remote: >>> remote: Bugid 6623167 already used in this repository, in revision 20 >>> remote: >>> remote: > Changeset: 104:2c106685d6d0 >>> remote: > Author: dcubed >>> remote: > Date: 2008-03-12 18:06 >>> remote: > >>> remote: > 6497639: 4/3 Profiling Swing application caused JVM crash >>> remote: > Summary: Make RedefineClasses() interoperate better with >>> class sharing. >>> remote: > Reviewed-by: sspitsyn, jmasa >>> remote: >>> remote: Bugid 6497639 already used in this repository, in revision 20 >>> remote: >>> remote: > Changeset: 105:d8b3ef7ee3e5 >>> remote: > Author: dcubed >>> remote: > Date: 2008-03-12 18:07 >>> remote: > >>> remote: > 6599425: 4/3 OopMapCache::lookup() can cause later crash or >>> assert() failure >>> remote: > Summary: Add should_not_be_cached() to markOop and methodOop >>> and query that status inOopMapCache::lookup() >>> remote: > Reviewed-by: coleenp, sspitsyn, jmasa >>> remote: >>> remote: Bugid 6599425 already used in this repository, in revision 20 >>> remote: >>> remote: > Changeset: 240:65fe2bd88839 >>> remote: > Author: never >>> remote: > Date: 2008-06-05 21:44 >>> remote: > >>> remote: > 6614100: EXCEPTION_ACCESS_VIOLATION while running Eclipse >>> with 1.6.0_05-ea >>> remote: > Reviewed-by: kvn, jrose, rasbold >>> remote: >>> remote: Bugid 6614100 already used in this repository, in revision 20 >>> remote: >>> remote: > Changeset: 286:3e82d72933d0 >>> remote: > Author: xlu >>> remote: > Date: 2008-06-26 14:15 >>> remote: > >>> remote: > 6718830: Hotspot fails to build with gcc 4.3 >>> remote: > Summary: Fixed linux make file and couple adlc code to meet >>> the changes of gcc 4.3 >>> remote: > Reviewed-by: kamg, igor >>> remote: >>> remote: Bugid 6718830 already used in this repository, in revision 32 >>> remote: >>> remote: > Changeset: 289:551f4309f476 >>> remote: > Author: ohair >>> remote: > Date: 2008-07-03 10:46 >>> remote: > >>> remote: > 6695777: Queens.class should be built from source, not put >>> in source repo >>> remote: > Reviewed-by: kvn >>> remote: >>> remote: Bugid 6695777 already used in this repository, in revision 20 >>> remote: >>> remote: > Changeset: 314:54499b980c23 >>> remote: > Author: swamyv >>> remote: > Date: 2008-07-29 13:54 >>> remote: > >>> remote: > 6710791: Remove files or build from source:maf-1_0.jar, jlfg-1_0.jar >>> remote: > Summary: Removed maf-1_0.jar and jlfg-1_0.jar files. >>> remote: > Reviewed-by: poonam, jjh >>> remote: >>> remote: Bugid 6710791 already used in this repository, in revision 20 >>> remote: >>> remote: > Changeset: 360:fa4d1d240383 >>> remote: > Author: never >>> remote: > Date: 2008-08-26 15:49 >>> remote: > >>> remote: > 6741642: bad enum definition in ciTypeFlow.hpp >>> remote: > Reviewed-by: rasbold, martin >>> remote: > Contributed-by: doko at ubuntu.com >>> remote: >>> remote: Bugid 6741642 already used in this repository, in revision 22 >>> remote: >>> remote: > Changeset: 589:748572b86af6 >>> remote: > Author: never >>> remote: > Date: 2009-04-07 14:46 >>> remote: > >>> remote: > 6636360: compiler/6595044/Main.java test fails with 64bit >>> java on solaris-sparcv9 with SIGSEGV >>> remote: > Reviewed-by: kvn, twisti >>> remote: >>> remote: Bugid 6636360 already used in this repository, in revision 29 >>> remote: >>> remote: abort: pretxnchangegroup.0.jcheck hook failed >>> remote: transaction abort! >>> remote: rollback completed >>> abort: unexpected response: empty string >>> >>> Is there a way of getting it to ignore these for this one push? I >>> don't know of a way to just pull out these nine changesets from the >>> 555 waiting to go... >>> >> I think they would need to be added to the jcheck whitelist for all time- >> but that is more of a question for Mark or Kelly. >> >> Tim >> >> > > The early revisions (20, 32) are from OpenJDK6 which was rebased to > allow HotSpot patches to be applied on top. So what happened here is > that, as the fixes were already applied to OpenJDK6, the new > changesets pulled in by the merge will be no-ops but still exist to > keep the change history accurate. > > I think we just need a way of disabling this check. OpenJDK6 already > has whitespace and comment checks turned to lax. See .jcheck: > http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/0282bf49b0f6. There > may already be an option for this bugid check too, but I have no idea > what the format of that file is. > Andrew, can you please try your push again? I chatted with Mark and the OpenJDK 6 HotSpot Mercurial repository should be configured to do lax checking on the bug ids. Thanks, -Joe From john.coomes at sun.com Thu Aug 13 20:38:31 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 14 Aug 2009 03:38:31 +0000 Subject: hg: jdk7/hotspot: Added tag jdk7-b69 for changeset 82e6c820c51a Message-ID: <20090814033831.472BEED6E@hg.openjdk.java.net> Changeset: 51a71c2c4b80 Author: xdono Date: 2009-08-13 12:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/51a71c2c4b80 Added tag jdk7-b69 for changeset 82e6c820c51a ! .hgtags From john.coomes at sun.com Thu Aug 13 20:44:08 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 14 Aug 2009 03:44:08 +0000 Subject: hg: jdk7/hotspot/corba: Added tag jdk7-b69 for changeset 8120d308ec4e Message-ID: <20090814034410.9F11DED73@hg.openjdk.java.net> Changeset: 07b3e9ba5085 Author: xdono Date: 2009-08-13 12:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/07b3e9ba5085 Added tag jdk7-b69 for changeset 8120d308ec4e ! .hgtags From john.coomes at sun.com Thu Aug 13 20:53:50 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 14 Aug 2009 03:53:50 +0000 Subject: hg: jdk7/hotspot/jaxp: Added tag jdk7-b69 for changeset a4ab0d6ded63 Message-ID: <20090814035352.DC572ED78@hg.openjdk.java.net> Changeset: 8287833daabc Author: xdono Date: 2009-08-13 12:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/8287833daabc Added tag jdk7-b69 for changeset a4ab0d6ded63 ! .hgtags From john.coomes at sun.com Thu Aug 13 20:59:28 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 14 Aug 2009 03:59:28 +0000 Subject: hg: jdk7/hotspot/jaxws: Added tag jdk7-b69 for changeset 3e64fdfb9291 Message-ID: <20090814035930.ADF3FED7D@hg.openjdk.java.net> Changeset: 1041c9cce799 Author: xdono Date: 2009-08-13 12:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/1041c9cce799 Added tag jdk7-b69 for changeset 3e64fdfb9291 ! .hgtags From john.coomes at sun.com Thu Aug 13 21:05:37 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 14 Aug 2009 04:05:37 +0000 Subject: hg: jdk7/hotspot/jdk: 4 new changesets Message-ID: <20090814040643.824CCED82@hg.openjdk.java.net> Changeset: 7e491e39ea0f Author: tbell Date: 2009-08-06 17:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7e491e39ea0f 6865853: Additional code changes needed to build deploy using WXP SP2 and Visual Studio 2008 Reviewed-by: ohair ! src/windows/native/sun/jkernel/kernel.cpp Changeset: 08baaf8638c9 Author: tbell Date: 2009-08-06 17:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/08baaf8638c9 Merge - src/share/classes/com/sun/crypto/provider/JarVerifier.java - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java - src/share/classes/sun/security/pkcs11/JarVerifier.java - src/windows/classes/sun/security/mscapi/JarVerifier.java Changeset: 226b20019b1f Author: xdono Date: 2009-08-12 10:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/226b20019b1f Merge Changeset: 36c8ddbe9bc5 Author: xdono Date: 2009-08-13 12:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/36c8ddbe9bc5 Added tag jdk7-b69 for changeset 226b20019b1f ! .hgtags From john.coomes at sun.com Thu Aug 13 21:16:43 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 14 Aug 2009 04:16:43 +0000 Subject: hg: jdk7/hotspot/langtools: Added tag jdk7-b69 for changeset ce9bcdcb7859 Message-ID: <20090814041646.F16DFED87@hg.openjdk.java.net> Changeset: 4ac89259512f Author: xdono Date: 2009-08-13 12:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/4ac89259512f Added tag jdk7-b69 for changeset ce9bcdcb7859 ! .hgtags From gnu_andrew at member.fsf.org Fri Aug 14 05:37:29 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 14 Aug 2009 13:37:29 +0100 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <4A84B194.1070108@sun.com> References: <17c6771e0907312044q43080f55y3353927a57dca99f@mail.gmail.com> <17c6771e0908030302k123c206br4a7632fbc77ee0b@mail.gmail.com> <4A78D78A.5000604@sun.com> <4A78DB80.2030504@sun.com> <17c6771e0908041817h48a5fd1dhcfeb93dc1ae9c0ae@mail.gmail.com> <4A78E151.9070304@sun.com> <17c6771e0908050357u792fd707h4f28cb9b08e9e395@mail.gmail.com> <4A79F131.7040105@sun.com> <17c6771e0908051639h4c9a9c79vfdc4f6048d17cca8@mail.gmail.com> <4A84B194.1070108@sun.com> Message-ID: <17c6771e0908140537g6f61faf8h3f912415b2f3e9c3@mail.gmail.com> 2009/8/14 Joe Darcy : > Andrew John Hughes wrote: >> >> 2009/8/5 Tim Bell : >> >>> >>> Andrew John Hughes wrote: >>> >>> >>>> >>>> Thanks Tim, that seems to have fixed the permissions issue. >>>> >>> >>> Good. >>> >>> >>>> >>>> There now seems to be an issue with jcheck, as the merge causes some >>>> bugids to be repeated: >>>> >>> >>> Hmmm - how did these changesets come in through two different paths? >>> >>> >>>> >>>> pushing to ssh://hg.openjdk.java.net/jdk6/jdk6-gate/hotspot >>>> searching for changes >>>> remote: adding changesets >>>> remote: adding manifests >>>> remote: adding file changes >>>> remote: added 555 changesets with 4771 changes to 1453 files >>>> remote: >>>> remote: > Changeset: 100:d821d920b465 >>>> remote: > Author: ? ?kvn >>>> remote: > Date: ? ? ?2008-03-11 11:04 >>>> remote: > >>>> remote: > 6623167: C2 crashed in StoreCMNode::Value >>>> remote: > Summary: C2 crashed in StoreCMNode::Value because >>>> n->in(MemNode::OopStore) is 0. >>>> remote: > Reviewed-by: rasbold, never >>>> remote: >>>> remote: Bugid 6623167 already used in this repository, in revision 20 >>>> remote: >>>> remote: > Changeset: 104:2c106685d6d0 >>>> remote: > Author: ? ?dcubed >>>> remote: > Date: ? ? ?2008-03-12 18:06 >>>> remote: > >>>> remote: > 6497639: 4/3 Profiling Swing application caused JVM crash >>>> remote: > Summary: Make RedefineClasses() interoperate better with >>>> class sharing. >>>> remote: > Reviewed-by: sspitsyn, jmasa >>>> remote: >>>> remote: Bugid 6497639 already used in this repository, in revision 20 >>>> remote: >>>> remote: > Changeset: 105:d8b3ef7ee3e5 >>>> remote: > Author: ? ?dcubed >>>> remote: > Date: ? ? ?2008-03-12 18:07 >>>> remote: > >>>> remote: > 6599425: 4/3 OopMapCache::lookup() can cause later crash or >>>> assert() failure >>>> remote: > Summary: Add should_not_be_cached() to markOop and methodOop >>>> and query that status inOopMapCache::lookup() >>>> remote: > Reviewed-by: coleenp, sspitsyn, jmasa >>>> remote: >>>> remote: Bugid 6599425 already used in this repository, in revision 20 >>>> remote: >>>> remote: > Changeset: 240:65fe2bd88839 >>>> remote: > Author: ? ?never >>>> remote: > Date: ? ? ?2008-06-05 21:44 >>>> remote: > >>>> remote: > 6614100: EXCEPTION_ACCESS_VIOLATION while running Eclipse >>>> with 1.6.0_05-ea >>>> remote: > Reviewed-by: kvn, jrose, rasbold >>>> remote: >>>> remote: Bugid 6614100 already used in this repository, in revision 20 >>>> remote: >>>> remote: > Changeset: 286:3e82d72933d0 >>>> remote: > Author: ? ?xlu >>>> remote: > Date: ? ? ?2008-06-26 14:15 >>>> remote: > >>>> remote: > 6718830: Hotspot fails to build with gcc 4.3 >>>> remote: > Summary: Fixed linux make file and couple adlc code to meet >>>> the changes of gcc 4.3 >>>> remote: > Reviewed-by: kamg, igor >>>> remote: >>>> remote: Bugid 6718830 already used in this repository, in revision 32 >>>> remote: >>>> remote: > Changeset: 289:551f4309f476 >>>> remote: > Author: ? ?ohair >>>> remote: > Date: ? ? ?2008-07-03 10:46 >>>> remote: > >>>> remote: > 6695777: Queens.class should be built from source, not put >>>> in source repo >>>> remote: > Reviewed-by: kvn >>>> remote: >>>> remote: Bugid 6695777 already used in this repository, in revision 20 >>>> remote: >>>> remote: > Changeset: 314:54499b980c23 >>>> remote: > Author: ? ?swamyv >>>> remote: > Date: ? ? ?2008-07-29 13:54 >>>> remote: > >>>> remote: > 6710791: Remove files or build from source:maf-1_0.jar, >>>> jlfg-1_0.jar >>>> remote: > Summary: Removed maf-1_0.jar and jlfg-1_0.jar files. >>>> remote: > Reviewed-by: poonam, jjh >>>> remote: >>>> remote: Bugid 6710791 already used in this repository, in revision 20 >>>> remote: >>>> remote: > Changeset: 360:fa4d1d240383 >>>> remote: > Author: ? ?never >>>> remote: > Date: ? ? ?2008-08-26 15:49 >>>> remote: > >>>> remote: > 6741642: bad enum definition in ciTypeFlow.hpp >>>> remote: > Reviewed-by: rasbold, martin >>>> remote: > Contributed-by: doko at ubuntu.com >>>> remote: >>>> remote: Bugid 6741642 already used in this repository, in revision 22 >>>> remote: >>>> remote: > Changeset: 589:748572b86af6 >>>> remote: > Author: ? ?never >>>> remote: > Date: ? ? ?2009-04-07 14:46 >>>> remote: > >>>> remote: > 6636360: compiler/6595044/Main.java test fails with 64bit >>>> java on solaris-sparcv9 with SIGSEGV >>>> remote: > Reviewed-by: kvn, twisti >>>> remote: >>>> remote: Bugid 6636360 already used in this repository, in revision 29 >>>> remote: >>>> remote: abort: pretxnchangegroup.0.jcheck hook failed >>>> remote: transaction abort! >>>> remote: rollback completed >>>> abort: unexpected response: empty string >>>> >>>> Is there a way of getting it to ignore these for this one push? ?I >>>> don't know of a way to just pull out these nine changesets from the >>>> 555 waiting to go... >>>> >>> >>> I think they would need to be added to the jcheck whitelist for all time- >>> but that is more of a question for Mark or Kelly. >>> >>> Tim >>> >>> >> >> The early revisions (20, 32) are from OpenJDK6 which was rebased to >> allow HotSpot patches to be applied on top. ?So what happened here is >> that, as the fixes were already applied to OpenJDK6, the new >> changesets pulled in by the merge will be no-ops but still exist to >> keep the change history accurate. >> >> I think we just need a way of disabling this check. ?OpenJDK6 already >> has whitespace and comment checks turned to lax. ?See .jcheck: >> http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/0282bf49b0f6. ?There >> may already be an option for this bugid check too, but I have no idea >> what the format of that file is. >> > > Andrew, can you please try your push again? > > I chatted with Mark and the OpenJDK 6 HotSpot Mercurial repository should be > configured to do lax checking on the bug ids. > > Thanks, > > -Joe > Sorry, same failure still occurs :( I didn't see any changes to .jcheck, which I would assume are needed to fix this (mr added one for the lax comments with the rebase). -- 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 andrey.petrusenko at sun.com Fri Aug 14 17:10:37 2009 From: andrey.petrusenko at sun.com (andrey.petrusenko at sun.com) Date: Sat, 15 Aug 2009 00:10:37 +0000 Subject: hg: jdk7/hotspot/hotspot: 6872000: G1: compilation fails on linux/older gcc Message-ID: <20090815001049.2CD81EE8E@hg.openjdk.java.net> Changeset: 308762b2bf14 Author: apetrusenko Date: 2009-08-14 13:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/308762b2bf14 6872000: G1: compilation fails on linux/older gcc Reviewed-by: jcoomes, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp From surenreddy at gmail.com Sat Aug 15 10:38:16 2009 From: surenreddy at gmail.com (Surendra Ippagunta) Date: Sat, 15 Aug 2009 23:08:16 +0530 Subject: CLDC Hostspot VM Source Code Message-ID: Is CLDC Hostspot VM Source Code is available?vWhere can I find it? Thanks in Advance, Regards Surendra From do.chuan at gmail.com Sun Aug 16 18:32:52 2009 From: do.chuan at gmail.com (douchuan) Date: Mon, 17 Aug 2009 09:32:52 +0800 Subject: CLDC Hostspot VM Source Code In-Reply-To: References: Message-ID: <4A88B344.8050104@gmail.com> pls search "PhoneME" Surendra Ippagunta ??: > Is CLDC Hostspot VM Source Code is available?vWhere can I find it? > > Thanks in Advance, > > Regards > Surendra > > From Ulf.Zibis at gmx.de Mon Aug 17 01:18:11 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 17 Aug 2009 10:18:11 +0200 Subject: CLDC Hostspot VM Source Code In-Reply-To: <4A88B344.8050104@gmail.com> References: <4A88B344.8050104@gmail.com> Message-ID: <4A891243.3020401@gmx.de> Google has bad results on only PhoneME. Better search for PhoneME + java, and you get: https://phoneme.dev.java.net/ -Ulf Am 17.08.2009 03:32, douchuan schrieb: > pls search "PhoneME" > > Surendra Ippagunta ??: >> Is CLDC Hostspot VM Source Code is available?vWhere can I find it? >> >> Thanks in Advance, >> >> Regards >> Surendra >> >> > > From gbenson at redhat.com Mon Aug 17 07:32:52 2009 From: gbenson at redhat.com (Gary Benson) Date: Mon, 17 Aug 2009 15:32:52 +0100 Subject: Review request: Zero assembler port of HotSpot Message-ID: <20090817143251.GB3394@redhat.com> Hi all, Zero is an interpreter-only port of HotSpot that uses no assembler and can trivially be built on any Linux system. The following webrev adds Zero support to OpenJDK: http://cr.openjdk.java.net/~gbenson/zero-07/ There are a number of environment variables that need setting before running make, but if you are using jdk/make/jdk_generic_profile.sh to set up your environment then you only need to set two, and a build can be as simple as: export CORE_BUILD=true export ZERO_BUILD=true . jdk/make/jdk_generic_profile.sh gmake sanity && gmake The two mandatory environment variables do the following: CORE_BUILD Setting CORE_BUILD to "true" will result in an interpreter-only HotSpot being built, with neither the client nor the server compilers. If CORE_BUILD is unset, or set to any other value than "true", then the compiler(s) will be built as normal. ZERO_BUILD Setting ZERO_BUILD to "true" will cause the Zero interpreter to be used. If ZERO_BUILD is unset, or set to any other value than "true", the standard, platform-specific interpreter will be used. The reason for having two separate flags is to allow for Zero builds with JIT compilers such as Shark (not included in this webrev). To build HotSpot with Zero and Shark you would set ZERO_BUILD to "true" but leave CORE_BUILD unset. Of the other environment variables the following are required when ZERO_BUILD is set to "true". These are set by jdk/make/jdk_generic_profile.sh based on the result of uname -m: ZERO_LIBARCH This is the name of the architecture-specific subdirectory under $JAVA_HOME/jre/lib. Typically this will be the same as the output of uname -m, although there are some exceptions: "amd64" instead of "x86_64", for example, and "i386" instead of "i686". ZERO_ARCHDEF The value of ZERO_ARCHDEF will be passed to the C++ compiler using -D${ZERO_ARCHDEF} to allow conditionalized platform-specific code. This is typically set to ZERO_LIBARCH converted to uppercase but, again, there are exceptions. "i386" becomes "IA32", to match what HotSpot already does, and on platforms with both 32- and 64-bit variants ZERO_ARCHDEF corresponds to the 32-bit version, so both ppc and ppc64 have ZERO_ARCHDEF set to "PPC". ZERO_ENDIANNESS This is set to "little" or "big". ZERO_BITSPERWORD This is set to "32" or "64". ZERO_ARCHFLAG This is a flag that will be passed to the C++ compiler and to the linker to instruct them to generate code for the particular platform. This is required for platforms with both 32- and 64-bit variants where the compiler needs to be told which variant to build for. ZERO_ARCHFLAG will typically be set to "-m32" or "-m64", except on 31-bit zSeries where it will be set to "-m31". Zero uses one external library, libffi, for JNI method invocation. The following two variables are used to tell the compiler and linker how to find libffi. These can be set by the user, but if left unset then jdk/make/jdk_generic_profile.sh will attempt to set them using pkg-config or, failing that, by supplying defaults pointing to the standard locations: LIBFFI_CFLAGS Flags to be passed to the C++ compiler to build against libffi. If unset (and pkg-config is not installed, or if libffi is not built with pkg-config) then this defaults to "". LIBFFI_LIBS Flags to be passed to the linker to link against libffi. If unset (and pkg-config is not installed, or if libffi is not built with pkg-config) then this defaults to "-lffi". Cheers, Gary -- http://gbenson.net/ From Joe.Darcy at Sun.COM Mon Aug 17 10:07:27 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Mon, 17 Aug 2009 10:07:27 -0700 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <17c6771e0908140537g6f61faf8h3f912415b2f3e9c3@mail.gmail.com> References: <17c6771e0907312044q43080f55y3353927a57dca99f@mail.gmail.com> <17c6771e0908030302k123c206br4a7632fbc77ee0b@mail.gmail.com> <4A78D78A.5000604@sun.com> <4A78DB80.2030504@sun.com> <17c6771e0908041817h48a5fd1dhcfeb93dc1ae9c0ae@mail.gmail.com> <4A78E151.9070304@sun.com> <17c6771e0908050357u792fd707h4f28cb9b08e9e395@mail.gmail.com> <4A79F131.7040105@sun.com> <17c6771e0908051639h4c9a9c79vfdc4f6048d17cca8@mail.gmail.com> <4A84B194.1070108@sun.com> <17c6771e0908140537g6f61faf8h3f912415b2f3e9c3@mail.gmail.com> Message-ID: <4A898E4F.5020007@sun.com> Andrew John Hughes wrote: > 2009/8/14 Joe Darcy : > >> Andrew John Hughes wrote: >> >>> 2009/8/5 Tim Bell : >>> >>> >>>> Andrew John Hughes wrote: >>>> >>>> >>>> >>>>> Thanks Tim, that seems to have fixed the permissions issue. >>>>> >>>>> >>>> Good. >>>> >>>> >>>> >>>>> There now seems to be an issue with jcheck, as the merge causes some >>>>> bugids to be repeated: >>>>> >>>>> >>>> Hmmm - how did these changesets come in through two different paths? >>>> >>>> >>>> >>>>> pushing to ssh://hg.openjdk.java.net/jdk6/jdk6-gate/hotspot >>>>> searching for changes >>>>> remote: adding changesets >>>>> remote: adding manifests >>>>> remote: adding file changes >>>>> remote: added 555 changesets with 4771 changes to 1453 files >>>>> remote: >>>>> remote: > Changeset: 100:d821d920b465 >>>>> remote: > Author: kvn >>>>> remote: > Date: 2008-03-11 11:04 >>>>> remote: > >>>>> remote: > 6623167: C2 crashed in StoreCMNode::Value >>>>> remote: > Summary: C2 crashed in StoreCMNode::Value because >>>>> n->in(MemNode::OopStore) is 0. >>>>> remote: > Reviewed-by: rasbold, never >>>>> remote: >>>>> remote: Bugid 6623167 already used in this repository, in revision 20 >>>>> remote: >>>>> remote: > Changeset: 104:2c106685d6d0 >>>>> remote: > Author: dcubed >>>>> remote: > Date: 2008-03-12 18:06 >>>>> remote: > >>>>> remote: > 6497639: 4/3 Profiling Swing application caused JVM crash >>>>> remote: > Summary: Make RedefineClasses() interoperate better with >>>>> class sharing. >>>>> remote: > Reviewed-by: sspitsyn, jmasa >>>>> remote: >>>>> remote: Bugid 6497639 already used in this repository, in revision 20 >>>>> remote: >>>>> remote: > Changeset: 105:d8b3ef7ee3e5 >>>>> remote: > Author: dcubed >>>>> remote: > Date: 2008-03-12 18:07 >>>>> remote: > >>>>> remote: > 6599425: 4/3 OopMapCache::lookup() can cause later crash or >>>>> assert() failure >>>>> remote: > Summary: Add should_not_be_cached() to markOop and methodOop >>>>> and query that status inOopMapCache::lookup() >>>>> remote: > Reviewed-by: coleenp, sspitsyn, jmasa >>>>> remote: >>>>> remote: Bugid 6599425 already used in this repository, in revision 20 >>>>> remote: >>>>> remote: > Changeset: 240:65fe2bd88839 >>>>> remote: > Author: never >>>>> remote: > Date: 2008-06-05 21:44 >>>>> remote: > >>>>> remote: > 6614100: EXCEPTION_ACCESS_VIOLATION while running Eclipse >>>>> with 1.6.0_05-ea >>>>> remote: > Reviewed-by: kvn, jrose, rasbold >>>>> remote: >>>>> remote: Bugid 6614100 already used in this repository, in revision 20 >>>>> remote: >>>>> remote: > Changeset: 286:3e82d72933d0 >>>>> remote: > Author: xlu >>>>> remote: > Date: 2008-06-26 14:15 >>>>> remote: > >>>>> remote: > 6718830: Hotspot fails to build with gcc 4.3 >>>>> remote: > Summary: Fixed linux make file and couple adlc code to meet >>>>> the changes of gcc 4.3 >>>>> remote: > Reviewed-by: kamg, igor >>>>> remote: >>>>> remote: Bugid 6718830 already used in this repository, in revision 32 >>>>> remote: >>>>> remote: > Changeset: 289:551f4309f476 >>>>> remote: > Author: ohair >>>>> remote: > Date: 2008-07-03 10:46 >>>>> remote: > >>>>> remote: > 6695777: Queens.class should be built from source, not put >>>>> in source repo >>>>> remote: > Reviewed-by: kvn >>>>> remote: >>>>> remote: Bugid 6695777 already used in this repository, in revision 20 >>>>> remote: >>>>> remote: > Changeset: 314:54499b980c23 >>>>> remote: > Author: swamyv >>>>> remote: > Date: 2008-07-29 13:54 >>>>> remote: > >>>>> remote: > 6710791: Remove files or build from source:maf-1_0.jar, >>>>> jlfg-1_0.jar >>>>> remote: > Summary: Removed maf-1_0.jar and jlfg-1_0.jar files. >>>>> remote: > Reviewed-by: poonam, jjh >>>>> remote: >>>>> remote: Bugid 6710791 already used in this repository, in revision 20 >>>>> remote: >>>>> remote: > Changeset: 360:fa4d1d240383 >>>>> remote: > Author: never >>>>> remote: > Date: 2008-08-26 15:49 >>>>> remote: > >>>>> remote: > 6741642: bad enum definition in ciTypeFlow.hpp >>>>> remote: > Reviewed-by: rasbold, martin >>>>> remote: > Contributed-by: doko at ubuntu.com >>>>> remote: >>>>> remote: Bugid 6741642 already used in this repository, in revision 22 >>>>> remote: >>>>> remote: > Changeset: 589:748572b86af6 >>>>> remote: > Author: never >>>>> remote: > Date: 2009-04-07 14:46 >>>>> remote: > >>>>> remote: > 6636360: compiler/6595044/Main.java test fails with 64bit >>>>> java on solaris-sparcv9 with SIGSEGV >>>>> remote: > Reviewed-by: kvn, twisti >>>>> remote: >>>>> remote: Bugid 6636360 already used in this repository, in revision 29 >>>>> remote: >>>>> remote: abort: pretxnchangegroup.0.jcheck hook failed >>>>> remote: transaction abort! >>>>> remote: rollback completed >>>>> abort: unexpected response: empty string >>>>> >>>>> Is there a way of getting it to ignore these for this one push? I >>>>> don't know of a way to just pull out these nine changesets from the >>>>> 555 waiting to go... >>>>> >>>>> >>>> I think they would need to be added to the jcheck whitelist for all time- >>>> but that is more of a question for Mark or Kelly. >>>> >>>> Tim >>>> >>>> >>>> >>> The early revisions (20, 32) are from OpenJDK6 which was rebased to >>> allow HotSpot patches to be applied on top. So what happened here is >>> that, as the fixes were already applied to OpenJDK6, the new >>> changesets pulled in by the merge will be no-ops but still exist to >>> keep the change history accurate. >>> >>> I think we just need a way of disabling this check. OpenJDK6 already >>> has whitespace and comment checks turned to lax. See .jcheck: >>> http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/0282bf49b0f6. There >>> may already be an option for this bugid check too, but I have no idea >>> what the format of that file is. >>> >>> >> Andrew, can you please try your push again? >> >> I chatted with Mark and the OpenJDK 6 HotSpot Mercurial repository should be >> configured to do lax checking on the bug ids. >> >> Thanks, >> >> -Joe >> >> > > Sorry, same failure still occurs :( > > I didn't see any changes to .jcheck, which I would assume are needed > to fix this (mr added one for the lax comments with the rebase). > *sigh* Okay; I'll chat with Mark again to get to the bottom of this. -Joe From Vasanth.Venkatachalam at amd.com Mon Aug 17 17:26:31 2009 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Mon, 17 Aug 2009 19:26:31 -0500 Subject: Request for reviews (M): 6580131: Exposing Method Inlining InformationTo JVMTI Agents Message-ID: <7E25251AA9AC1F47937B3C615B77ADA86A00D3@SAUSEXMB2.amd.com> Hi Tom, Thank you again for your detailed and insightful review. We have revised our implementation based on your suggestions and submitted new diffs for bugid 100085 with the changes described below. We have attached these diffs and new sample JVMTI agents to the bug report at: https://bugs.openjdk.java.net/show_bug.cgi?id=100085 1. Overall Structure We have added one new header file to the Hotspot JVM, jvmticmlr.h. This header defines a struct JvmtiCompiledMethodLoadRecordHeader that represents arbitrary information passed through the void pointer. The struct has a type field to indicate the type of information being passed, and a next pointer. The type field can also be used to capture versioning information. We also defined another struct, JvmtiCompiledMethodLoadInlineRecord, which contains the previous struct as the first member but in addition has extra fields for storing inlining information. One can similarly define additional structs to pass other kinds of information. As an example, we've defined a struct JvmtiCompiledMethodLoadDummyRecord, which contains a string "I am a dummy record." When the sample JVMTI agents that we have provided encounter a record of this type, they print the string contained in the dummy record. This new header file jvmticmlr.h lives in the Hotspot src/share/vm/code directory. However, we envision that the JDK installer would copy it to the JDK include/ directory to make this file available to external JVMTI agents, in the same way that it makes jni.h available. When a CompiledMethodLoad event is generated for an nmethod, the void pointer will contain a list of JvmtiCompiledMethodLoadInlineRecords. Each record has a pc address which actually represents a range of pc addresses between that JvmtiCompiledMethodLoadInlineRecord and the pc address of the next one in the list. When the sample JVMTI agents we have provided detect a CompiledMethodLoad event, they first cast the void pointer,of the CompiledMethodLoad callback to a JvmtiCompiledMethodLoadRecordHeader * list, and iterate over each of the records in the list, checking its type and then casting the record to the appropriate subtype (e.g., JvmtiCompiledMethodLoadInlineRecords) before deciding how to process it. 2. Code Changes The main code changes are to the jvmtiExport.cpp file, located in src/share/vm/prims. We have defined a new global method, create_inline_records which returns a list of records containing inline information for a given nmethod. The post_compiled_method_load method of JvmtiExport calls this method to retrieve the inlining information and pass it rhrough the void pointer. In addition to these changes, we have made the following miscellaneous changes that were requested: -We changed the date of the copyright notices in the new header files to 2009. -We have changed all function names to use lowercase with underscores. -We replaced null checks of impossible conditions with assertions as recommended. -We removed the unused type and offset fields from the data structure that was previously called InlineInfoRecord and is now called JVMTICompiledMethodLoadInlineRecord. We renamed the jmethodID[] array to methods and bytecodeindexes to bcis. -We removed the PCDescriptorList class since it was redundant. -We modified our code to use resource allocation rather than C heap allocations. Please see the create_inline_records method in jvmtiExport.cpp. -We modified jvmtiExport.cpp to set the _compile_info void pointer inside the JvmtiCompiledMethodLoadEventMark constructor, rather than setting this pointer in a separate method call. 3. Sample Agents The sample agents now use the jvmticmlr.h header file. For ease of testing, we have copied this header file from the JVM src/share/vm/code directory into the c and cpp directories containing the agents. However, as noted before, the JDK installer would ideally copy this header file to the JDK /include directory, so that it can be made available in the same way that jni.h is available. Again, we thank you for your detailed feedback. Please let us know if you have additional comments or questions Regards, Vasanth From: Venkatachalam, Vasanth Sent: Tuesday, August 04, 2009 10:47 AM To: 'hotspot-dev at openjdk.java.net' Cc: 'Thomas.Rodriguez at sun.com'; Joshi, Shrinivas; Pollan, Ben Subject: RE: Request for reviews (M): 6580131: Exposing Method Inlining InformationTo JVMTI Agents Hi Tom, Thank you for your detailed and insightful feedback on my JVMTI method inlining submission. Sorry for the delay in responding to your comments. We are scoping out the changes that you have recommended. Some of these changes could take longer, but we hope to be able to respond in a few days with some changes or at least a timeline on when we can get them in. Regards, Vasanth -- Vasanth Venkatachalam AMD Java Labs (512)602-6177 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090817/af372831/attachment.html From gnu_andrew at member.fsf.org Tue Aug 18 06:42:02 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 18 Aug 2009 14:42:02 +0100 Subject: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti Message-ID: <17c6771e0908180642k67a2cc68refa4232b1cf1770c@mail.gmail.com> The makeDeps and jvmti bootstrap tools are built without explicit source and target options. This webrev: http://cr.openjdk.java.net/~andrew/ecj/03/webrev.01/ sets them to 6 explicitly. The change has to be replicated three times, because for some reason, the javac invocations are in platform-specific makefiles. I've tested the change successfully on GNU/Linux, where it allows ecj to be used as javac. ecj defaults to <1.5 and thus otherwise fails to build. I've assumed that the same changes are applicable for Solaris and Windows, and that the source and target options don't have to be written in Latin or something to work on these platforms. Is this ok to push? 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 Daniel.Daugherty at Sun.COM Tue Aug 18 07:24:14 2009 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Tue, 18 Aug 2009 08:24:14 -0600 Subject: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <17c6771e0908180642k67a2cc68refa4232b1cf1770c@mail.gmail.com> References: <17c6771e0908180642k67a2cc68refa4232b1cf1770c@mail.gmail.com> Message-ID: <4A8AB98E.4030605@sun.com> Andrew, A couple of comments: - if you specify '-source 6', then '-target 6' is implied so you don't really need both - I would prefer to see a top-level macro that defines the bootstrap tools javac option and then have the various Makefiles use that macro. Something in make/defs.make: BOOTSTRAP_TOOLS.JAVAC.FLAGS="-source 6" or something like that. Which repo are you targeting for this change? Dan P.S. Yes, I see that SA uses '-source 1.4' in each platform makefile. That should be fixed also, but that's another issue... Andrew John Hughes wrote: > The makeDeps and jvmti bootstrap tools are built without explicit > source and target options. > > This webrev: > > http://cr.openjdk.java.net/~andrew/ecj/03/webrev.01/ > > sets them to 6 explicitly. The change has to be replicated three > times, because for some reason, the javac invocations are in > platform-specific makefiles. I've tested the change successfully on > GNU/Linux, where it allows ecj to be used as javac. ecj defaults to > <1.5 and thus otherwise fails to build. I've assumed that the same > changes are applicable for Solaris and Windows, and that the source > and target options don't have to be written in Latin or something to > work on these platforms. > > Is this ok to push? > > Thanks, > From gnu_andrew at member.fsf.org Tue Aug 18 07:52:45 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 18 Aug 2009 15:52:45 +0100 Subject: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <4A8AB98E.4030605@sun.com> References: <17c6771e0908180642k67a2cc68refa4232b1cf1770c@mail.gmail.com> <4A8AB98E.4030605@sun.com> Message-ID: <17c6771e0908180752t6b5c4e3ag39ffe786f09b3937@mail.gmail.com> 2009/8/18 Daniel D. Daugherty : > Andrew, > > A couple of comments: > > - if you specify '-source 6', then '-target 6' is implied > ?so you don't really need both The template I used for the change was the use of source/target 7 in corba, langtools and jdk, which specify both. It seems prudent to be explicit at the expense of some extra characters. > - I would prefer to see a top-level macro that defines the > ?bootstrap tools javac option and then have the various > ?Makefiles use that macro. Something in make/defs.make: > > ? ? BOOTSTRAP_TOOLS.JAVAC.FLAGS="-source 6" > > ?or something like that. > Sounds sensible. I'll post another webrev with such a change; I only saw JAVAC-related defines in the platform makefiles, so did the simplest changes to begin with. > Which repo are you targeting for this change? > Any of the OpenJDK7 HotSpot repositories - which do you think is most applicable? I suppose it could also go to build, but it seems better for such a change to be reviewed by those most dependent on building it. > Dan > > P.S. > Yes, I see that SA uses '-source 1.4' in each platform makefile. > That should be fixed also, but that's another issue... > > > > Andrew John Hughes wrote: >> >> The makeDeps and jvmti bootstrap tools are built without explicit >> source and target options. >> >> This webrev: >> >> http://cr.openjdk.java.net/~andrew/ecj/03/webrev.01/ >> >> sets them to 6 explicitly. The change has to be replicated three >> times, because for some reason, the javac invocations are in >> platform-specific makefiles. ?I've tested the change successfully on >> GNU/Linux, where it allows ecj to be used as javac. ?ecj defaults to >> <1.5 and thus otherwise fails to build. ?I've assumed that the same >> changes are applicable for Solaris and Windows, and that the source >> and target options don't have to be written in Latin or something to >> work on these platforms. >> >> Is this ok to push? >> >> Thanks, >> > Thanks for the quick response, -- 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 Daniel.Daugherty at Sun.COM Tue Aug 18 08:08:07 2009 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Tue, 18 Aug 2009 09:08:07 -0600 Subject: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <17c6771e0908180752t6b5c4e3ag39ffe786f09b3937@mail.gmail.com> References: <17c6771e0908180642k67a2cc68refa4232b1cf1770c@mail.gmail.com> <4A8AB98E.4030605@sun.com> <17c6771e0908180752t6b5c4e3ag39ffe786f09b3937@mail.gmail.com> Message-ID: <4A8AC3D7.7080205@sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090818/07520d4b/attachment.html From John.Coomes at sun.com Tue Aug 18 10:37:31 2009 From: John.Coomes at sun.com (John Coomes) Date: Tue, 18 Aug 2009 10:37:31 -0700 Subject: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <4A8AB98E.4030605@sun.com> References: <17c6771e0908180642k67a2cc68refa4232b1cf1770c@mail.gmail.com> <4A8AB98E.4030605@sun.com> Message-ID: <19082.59099.744855.256045@sun.com> Daniel D. Daugherty (Daniel.Daugherty at Sun.COM) wrote: > Andrew, > > A couple of comments: > > - if you specify '-source 6', then '-target 6' is implied > so you don't really need both > - I would prefer to see a top-level macro that defines the > bootstrap tools javac option and then have the various > Makefiles use that macro. Something in make/defs.make: > > BOOTSTRAP_TOOLS.JAVAC.FLAGS="-source 6" > > or something like that. +1 on the top-level macro. In HotSpot, I would call it JAVAC_FLAGS or COMPILE_JAVAC_FLAGS, and add it to the COMPILE.JAVAC macro (spelled COMPILE_JAVAC on windows) so that every compilation uses it. Then fewer places need to be touched. Also, please leave the default value empty. On platforms that need it, it can be set on the command line or in the environment. Specifying a value requires periodic maintenance. Yes, the period is long, but it's a pain when the build breaks because of some stale value in a makefile. > Which repo are you targeting for this change? I'd suggest hotspot-rt. Note that all hotspot changes have to be built on all platforms before being pushed; we have an automated system called jprt that does builds and tests on the various platforms. Unfortunately, it isn't available externally. Sync up with the latest hotspot-rt and then contact me privately with a patch or your repo location and I'll run it through. > Yes, I see that SA uses '-source 1.4' in each platform makefile. > That should be fixed also, but that's another issue... Sigh. Stale values in makefiles ... -John > > Andrew John Hughes wrote: > > The makeDeps and jvmti bootstrap tools are built without explicit > > source and target options. > > > > This webrev: > > > > http://cr.openjdk.java.net/~andrew/ecj/03/webrev.01/ > > > > sets them to 6 explicitly. The change has to be replicated three > > times, because for some reason, the javac invocations are in > > platform-specific makefiles. I've tested the change successfully on > > GNU/Linux, where it allows ecj to be used as javac. ecj defaults to > > <1.5 and thus otherwise fails to build. I've assumed that the same > > changes are applicable for Solaris and Windows, and that the source > > and target options don't have to be written in Latin or something to > > work on these platforms. > > > > Is this ok to push? > > > > Thanks, > > From erik.trimble at sun.com Tue Aug 18 20:47:03 2009 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Wed, 19 Aug 2009 03:47:03 +0000 Subject: hg: jdk7/hotspot/hotspot: 6 new changesets Message-ID: <20090819034728.9CAFE12042@hg.openjdk.java.net> Changeset: d07e68298d4e Author: xdono Date: 2009-07-30 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d07e68298d4e Added tag jdk7-b67 for changeset 18f526145aea ! .hgtags Changeset: 54fd4d923296 Author: xdono Date: 2009-08-06 10:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/54fd4d923296 Added tag jdk7-b68 for changeset d07e68298d4e ! .hgtags Changeset: 5021b9893d0a Author: xdono Date: 2009-08-13 12:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5021b9893d0a Added tag jdk7-b69 for changeset 54fd4d923296 ! .hgtags Changeset: f753dffae23e Author: trims Date: 2009-08-13 17:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f753dffae23e 6871765: Bump the HS16 build number to 08 Summary: Update the HS16 build number to 08 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 16314a31b961 Author: trims Date: 2009-08-13 17:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/16314a31b961 Merge Changeset: ac59d4e6dae5 Author: trims Date: 2009-08-14 17:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ac59d4e6dae5 Merge From gnu_andrew at member.fsf.org Wed Aug 19 12:30:20 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 19 Aug 2009 20:30:20 +0100 Subject: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <19082.59099.744855.256045@sun.com> References: <17c6771e0908180642k67a2cc68refa4232b1cf1770c@mail.gmail.com> <4A8AB98E.4030605@sun.com> <19082.59099.744855.256045@sun.com> Message-ID: <17c6771e0908191230y3aabadfcq70ab30782538036@mail.gmail.com> 2009/8/18 John Coomes : > Daniel D. Daugherty (Daniel.Daugherty at Sun.COM) wrote: >> Andrew, >> >> A couple of comments: >> >> - if you specify '-source 6', then '-target 6' is implied >> ? so you don't really need both >> - I would prefer to see a top-level macro that defines the >> ? bootstrap tools javac option and then have the various >> ? Makefiles use that macro. Something in make/defs.make: >> >> ? ? ? BOOTSTRAP_TOOLS.JAVAC.FLAGS="-source 6" >> >> ? or something like that. > > +1 on the top-level macro. ?In HotSpot, I would call it JAVAC_FLAGS or > COMPILE_JAVAC_FLAGS, and add it to the COMPILE.JAVAC macro (spelled > COMPILE_JAVAC on windows) so that every compilation uses it. ?Then > fewer places need to be touched. > > Also, please leave the default value empty. ?On platforms that need > it, it can be set on the command line or in the environment. > Specifying a value requires periodic maintenance. ?Yes, the period is > long, but it's a pain when the build breaks because of some stale > value in a makefile. > Ok, here's the changeset I was working on before I received your mail and which I've since successfully tested with hotspot-rt: http://cr.openjdk.java.net/~andrew/ecj/03/webrev.02/ This defines the variables in the top-level defs.make file. The versions are stored separately, in the same way as they are in the JDK: http://hg.openjdk.java.net/jdk7/build/jdk/rev/80368890a2a0 SA is still done separately as it's currently 1.4. The default for others is 6. The rest of the patch ensures this makefile is picked up and its values used for compilation across all three platforms. This is added to the invocations rather than COMPILE.JAVAC. As you imply in your mail, this value varies between platforms and even within the same platform. Just the GNU/Linux port itself defines it in about four ways. I don't agree with leaving the value blank. The issue is relevant on all platforms, as leaving it blank makes the build open to whatever the default value is of the bootstrap JDK. For instance, this just changed to 7 with OpenJDK, so current builds will produce 1.7 bytecode while builds using an older OpenJDK7 or OpenJDK6 will use 6. From personal experience, it's much harder to debug a problem when you have to take into account the boot JDK being used, which may vary, than when you have an explicit value. It seems much clearer to specify it explicitly in one common place for all platforms, which can also be easily overridden from the command line if needed. This is the same as is now done for JDK, langtools, jaxp and jaxws and will shortly be the case in corba. >> Which repo are you targeting for this change? > > I'd suggest hotspot-rt. > > Note that all hotspot changes have to be built on all platforms before > being pushed; we have an automated system called jprt that does builds > and tests on the various platforms. ?Unfortunately, it isn't available > externally. ?Sync up with the latest hotspot-rt and then contact me > privately with a patch or your repo location and I'll run it through. > The patch from this webrev is against hotspot-rt so can be tested. >> Yes, I see that SA uses '-source 1.4' in each platform makefile. >> That should be fixed also, but that's another issue... > > Sigh. ?Stale values in makefiles ... > Also fixed now by this patch. At least 1.4 is in one common makefile rather than occurring six times over three makefiles... :) > -John > >> > Andrew John Hughes wrote: >> > The makeDeps and jvmti bootstrap tools are built without explicit >> > source and target options. >> > >> > This webrev: >> > >> > http://cr.openjdk.java.net/~andrew/ecj/03/webrev.01/ >> > >> > sets them to 6 explicitly. The change has to be replicated three >> > times, because for some reason, the javac invocations are in >> > platform-specific makefiles. ?I've tested the change successfully on >> > GNU/Linux, where it allows ecj to be used as javac. ?ecj defaults to >> > <1.5 and thus otherwise fails to build. ?I've assumed that the same >> > changes are applicable for Solaris and Windows, and that the source >> > and target options don't have to be written in Latin or something to >> > work on these platforms. >> > >> > Is this ok to push? >> > >> > 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 John.Coomes at sun.com Wed Aug 19 16:19:27 2009 From: John.Coomes at sun.com (John Coomes) Date: Wed, 19 Aug 2009 16:19:27 -0700 Subject: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <17c6771e0908191230y3aabadfcq70ab30782538036@mail.gmail.com> References: <17c6771e0908180642k67a2cc68refa4232b1cf1770c@mail.gmail.com> <4A8AB98E.4030605@sun.com> <19082.59099.744855.256045@sun.com> <17c6771e0908191230y3aabadfcq70ab30782538036@mail.gmail.com> Message-ID: <19084.34943.379450.167908@sun.com> Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: > 2009/8/18 John Coomes : > > Daniel D. Daugherty (Daniel.Daugherty at Sun.COM) wrote: > >> Andrew, > >> > >> A couple of comments: > >> > >> - if you specify '-source 6', then '-target 6' is implied > >> ?? so you don't really need both > >> - I would prefer to see a top-level macro that defines the > >> ?? bootstrap tools javac option and then have the various > >> ?? Makefiles use that macro. Something in make/defs.make: > >> > >> ?? ?? ?? BOOTSTRAP_TOOLS.JAVAC.FLAGS="-source 6" > >> > >> ?? or something like that. > > > > +1 on the top-level macro. ??In HotSpot, I would call it JAVAC_FLAGS or > > COMPILE_JAVAC_FLAGS, and add it to the COMPILE.JAVAC macro (spelled > > COMPILE_JAVAC on windows) so that every compilation uses it. ??Then > > fewer places need to be touched. > > > > Also, please leave the default value empty. ??On platforms that need > > it, it can be set on the command line or in the environment. > > Specifying a value requires periodic maintenance. ??Yes, the period is > > long, but it's a pain when the build breaks because of some stale > > value in a makefile. > > > > Ok, here's the changeset I was working on before I received your mail > and which I've since successfully tested with hotspot-rt: > > http://cr.openjdk.java.net/~andrew/ecj/03/webrev.02/ I submitted your patch to the build queue; it will take several hours, there's one job ahead of it. After looking at it again, the include of make/defs.make in make/windows/makefiles/rules.make will most likely fail to build. The latter is a windows nmake file, so the gnu-specific syntax will be rejected and there are other unixisms in there (e.g., shell until). Instead, try updating MAKE_ARGS in make/defs.make, I believe those are exported to sub-makes. Since it has to be portable, I believe you'll have to use '_' instead of '.' in the macro name. > This defines the variables in the top-level defs.make file. The > versions are stored separately, in the same way as they are in the > JDK: > > http://hg.openjdk.java.net/jdk7/build/jdk/rev/80368890a2a0 > > SA is still done separately as it's currently 1.4. The default for others is 6. > The rest of the patch ensures this makefile is picked up and its > values used for compilation across all three platforms. > > This is added to the invocations rather than COMPILE.JAVAC. As you > imply in your mail, this value varies between platforms and even > within the same platform. Just the GNU/Linux port itself defines it > in about four ways. Take a look, it's simply selecting which path to use. After the def of COMPILE.JAVAC, a simple COMPILE.JAVAC += $(BOOTSTRAP_JAVAC.FLAGS) should do it. Windows will have to be different, though. > I don't agree with leaving the value blank. The issue is relevant on > all platforms, as leaving it blank makes the build open to whatever > the default value is of the bootstrap JDK. For instance, this just > changed to 7 with OpenJDK, so current builds will produce 1.7 bytecode > while builds using an older OpenJDK7 or OpenJDK6 will use 6. From > personal experience, it's much harder to debug a problem when you have > to take into account the boot JDK being used, which may vary, than > when you have an explicit value. > > It seems much clearer to specify it explicitly in one common place for > all platforms, which can also be easily overridden from the command > line if needed. This is the same as is now done for JDK, langtools, > jaxp and jaxws and will shortly be the case in corba. The jdk, langtools, etc., repos are much more sensitive to this setting than hotspot, which uses it only for makedeps and jvmti header generation. It's non-critical, and I think it's safe to assume that the default class file version produced by a boot jdk can also be run by that same boot jdk. So far, ecj is the only known boot env needing this set explicitly. -John > >> Which repo are you targeting for this change? > > > > I'd suggest hotspot-rt. > > > > Note that all hotspot changes have to be built on all platforms before > > being pushed; we have an automated system called jprt that does builds > > and tests on the various platforms. ??Unfortunately, it isn't available > > externally. ??Sync up with the latest hotspot-rt and then contact me > > privately with a patch or your repo location and I'll run it through. > > > > The patch from this webrev is against hotspot-rt so can be tested. > > >> Yes, I see that SA uses '-source 1.4' in each platform makefile. > >> That should be fixed also, but that's another issue... > > > > Sigh. ??Stale values in makefiles ... > > > > Also fixed now by this patch. At least 1.4 is in one common makefile > rather than occurring six times over three makefiles... :) > > > -John > > > >> > Andrew John Hughes wrote: > >> > The makeDeps and jvmti bootstrap tools are built without explicit > >> > source and target options. > >> > > >> > This webrev: > >> > > >> > http://cr.openjdk.java.net/~andrew/ecj/03/webrev.01/ > >> > > >> > sets them to 6 explicitly. The change has to be replicated three > >> > times, because for some reason, the javac invocations are in > >> > platform-specific makefiles. ??I've tested the change successfully on > >> > GNU/Linux, where it allows ecj to be used as javac. ??ecj defaults to > >> > <1.5 and thus otherwise fails to build. ??I've assumed that the same > >> > changes are applicable for Solaris and Windows, and that the source > >> > and target options don't have to be written in Latin or something to > >> > work on these platforms. > >> > > >> > Is this ok to push? > >> > > >> > 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 andrei.pangin at sun.com Wed Aug 19 18:09:52 2009 From: andrei.pangin at sun.com (andrei.pangin at sun.com) Date: Thu, 20 Aug 2009 01:09:52 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20090820011002.B09711211A@hg.openjdk.java.net> Changeset: 1760a1cbed36 Author: dcubed Date: 2009-08-11 11:57 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1760a1cbed36 6862945: 4/3 conversion of jmethodID to methodOop in JVMTI is too expensive Summary: Refactor JNIHandles::checked_resolve_jmethod_id() into fast and paranoid parts. Reviewed-by: never, alanb ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/runtime/jniHandles.hpp Changeset: 6ab1d6ece8bd Author: apangin Date: 2009-08-17 15:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6ab1d6ece8bd Merge Changeset: 585222cadf79 Author: apangin Date: 2009-08-19 15:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/585222cadf79 Merge From gnu_andrew at member.fsf.org Thu Aug 20 05:22:34 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 20 Aug 2009 13:22:34 +0100 Subject: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <19084.34943.379450.167908@sun.com> References: <17c6771e0908180642k67a2cc68refa4232b1cf1770c@mail.gmail.com> <4A8AB98E.4030605@sun.com> <19082.59099.744855.256045@sun.com> <17c6771e0908191230y3aabadfcq70ab30782538036@mail.gmail.com> <19084.34943.379450.167908@sun.com> Message-ID: <17c6771e0908200522u78b5a222j24661df5b76783c2@mail.gmail.com> 2009/8/20 John Coomes : > Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: >> 2009/8/18 John Coomes : >> > Daniel D. Daugherty (Daniel.Daugherty at Sun.COM) wrote: >> >> Andrew, >> >> >> >> A couple of comments: >> >> >> >> - if you specify '-source 6', then '-target 6' is implied >> >> ?? so you don't really need both >> >> - I would prefer to see a top-level macro that defines the >> >> ?? bootstrap tools javac option and then have the various >> >> ?? Makefiles use that macro. Something in make/defs.make: >> >> >> >> ?? ?? ?? BOOTSTRAP_TOOLS.JAVAC.FLAGS="-source 6" >> >> >> >> ?? or something like that. >> > >> > +1 on the top-level macro. ??In HotSpot, I would call it JAVAC_FLAGS or >> > COMPILE_JAVAC_FLAGS, and add it to the COMPILE.JAVAC macro (spelled >> > COMPILE_JAVAC on windows) so that every compilation uses it. ??Then >> > fewer places need to be touched. >> > >> > Also, please leave the default value empty. ??On platforms that need >> > it, it can be set on the command line or in the environment. >> > Specifying a value requires periodic maintenance. ??Yes, the period is >> > long, but it's a pain when the build breaks because of some stale >> > value in a makefile. >> > >> >> Ok, here's the changeset I was working on before I received your mail >> and which I've since successfully tested with hotspot-rt: >> >> http://cr.openjdk.java.net/~andrew/ecj/03/webrev.02/ > > I submitted your patch to the build queue; it will take several hours, > there's one job ahead of it. > > After looking at it again, the include of make/defs.make in > make/windows/makefiles/rules.make will most likely fail to build. ?The > latter is a windows nmake file, so the gnu-specific syntax will be > rejected and there are other unixisms in there (e.g., shell until). > I had a feeling Windows would be the one to bite... > Instead, try updating MAKE_ARGS in make/defs.make, I believe those are > exported to sub-makes. ?Since it has to be portable, I believe you'll > have to use '_' instead of '.' in the macro name. > Ok, in http://cr.openjdk.java.net/~andrew/ecj/03/webrev.03/ I've reverted the addtion of defs.make in favour of using MAKE_ARGS and renamed the variables using underscores (which I prefer anyway). Where I am confused is how the MAKE_ARGS changes get through to the Windows build if it doesn't parse defs.make. makefiles/windows/defs.make seems to imply that the top-level one will be read. >> This defines the variables in the top-level defs.make file. ?The >> versions are stored separately, in the same way as they are in the >> JDK: >> >> http://hg.openjdk.java.net/jdk7/build/jdk/rev/80368890a2a0 >> >> SA is still done separately as it's currently 1.4. ?The default for others is 6. >> The rest of the patch ensures this makefile is picked up and its >> values used for compilation across all three platforms. >> >> This is added to the invocations rather than COMPILE.JAVAC. ?As you >> imply in your mail, this value varies between platforms and even >> within the same platform. ?Just the GNU/Linux port itself defines it >> in about four ways. > > Take a look, it's simply selecting which path to use. ?After the def > of COMPILE.JAVAC, a simple > > ? ? ? ?COMPILE.JAVAC += $(BOOTSTRAP_JAVAC.FLAGS) > > should do it. ?Windows will have to be different, though. > Yes, the other problem is this forces the same options to SA as well which uses COMPILE.JAVAC. To keep the current status quo (at least for now), these need a different set of flags. >> I don't agree with leaving the value blank. ?The issue is relevant on >> all platforms, as leaving it blank makes the build open to whatever >> the default value is of the bootstrap JDK. ?For instance, this just >> changed to 7 with OpenJDK, so current builds will produce 1.7 bytecode >> while builds using an older OpenJDK7 or OpenJDK6 will use 6. ?From >> personal experience, it's much harder to debug a problem when you have >> to take into account the boot JDK being used, which may vary, than >> when you have an explicit value. >> >> It seems much clearer to specify it explicitly in one common place for >> all platforms, which can also be easily overridden from the command >> line if needed. ?This is the same as is now done for JDK, langtools, >> jaxp and jaxws and will shortly be the case in corba. > > The jdk, langtools, etc., repos are much more sensitive to this > setting than hotspot, which uses it only for makedeps and jvmti header > generation. ?It's non-critical, and I think it's safe to assume that > the default class file version produced by a boot jdk can also be run > by that same boot jdk. > > So far, ecj is the only known boot env needing this set explicitly. > That kind of assumption is the thing that tends to come back and bite you. It's especially true because: * The boot JDK is something determined on a per-user basis, so just updating the system JDK may cause a failure that's hard to diagnose. * Failures in HotSpot javac builds are already hard to diagnose because it doesn't print out the javac invocation. It took me longer to track this down than the equivalents in JDK and CORBA, and I've been working with the OpenJDK build for about two years now. Yes, ecj is the only one that fails. But we now have at least two JDKs that will produce different results: OpenJDK6 (which defaults to 6) and OpenJDK7 (which defaults to 7). There are even more if you include the proprietary JDKs and JDK 1.5 which I assume can also build OpenJDK at a push. One of the side effects of releasing code to the world is that people are going to try and run into all sorts of corner cases. Assuming the defaults are good works fine when the only people building the code are Sun developers, but this is no longer true and something like this is just the kind of thing a casual builder of the code will run into and wonder why it fails. I agree this code is less used than the equivalent JDK and CORBA code, but surely it's better to be as consistent as possible across the codebase? Finally, switching SA to use the defaults would be a visible change. > -John > >> >> Which repo are you targeting for this change? >> > >> > I'd suggest hotspot-rt. >> > >> > Note that all hotspot changes have to be built on all platforms before >> > being pushed; we have an automated system called jprt that does builds >> > and tests on the various platforms. ??Unfortunately, it isn't available >> > externally. ??Sync up with the latest hotspot-rt and then contact me >> > privately with a patch or your repo location and I'll run it through. >> > >> >> The patch from this webrev is against hotspot-rt so can be tested. >> >> >> Yes, I see that SA uses '-source 1.4' in each platform makefile. >> >> That should be fixed also, but that's another issue... >> > >> > Sigh. ??Stale values in makefiles ... >> > >> >> Also fixed now by this patch. ?At least 1.4 is in one common makefile >> rather than occurring six times over three makefiles... :) >> >> > -John >> > >> >> > Andrew John Hughes wrote: >> >> > The makeDeps and jvmti bootstrap tools are built without explicit >> >> > source and target options. >> >> > >> >> > This webrev: >> >> > >> >> > http://cr.openjdk.java.net/~andrew/ecj/03/webrev.01/ >> >> > >> >> > sets them to 6 explicitly. The change has to be replicated three >> >> > times, because for some reason, the javac invocations are in >> >> > platform-specific makefiles. ??I've tested the change successfully on >> >> > GNU/Linux, where it allows ecj to be used as javac. ??ecj defaults to >> >> > <1.5 and thus otherwise fails to build. ??I've assumed that the same >> >> > changes are applicable for Solaris and Windows, and that the source >> >> > and target options don't have to be written in Latin or something to >> >> > work on these platforms. >> >> > >> >> > Is this ok to push? >> >> > >> >> > 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 > > -- 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 gustav.trede at gmail.com Thu Aug 20 11:47:57 2009 From: gustav.trede at gmail.com (gustav trede) Date: Thu, 20 Aug 2009 20:47:57 +0200 Subject: FDLIBM 5.3 ported Message-ID: <311e0eaf0908201147g78f037abm6076749055cde576@mail.gmail.com> Hello, All methods but sqrt is ported. I would be happy to get help with further conformance testing and feedback in general. The tests for Math and StrictMath classes in openjdk passes along with my own similar tests, comparing to the current strictmath for identical results. The performance improvements seems to be rather massive for quite a few operations. I have signed a JCA a couple of years ago. -- regards gustav trede -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090820/9cc75317/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: StrictMath.java Type: application/octet-stream Size: 150781 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090820/9cc75317/attachment-0001.obj From nagy.mostafa at gmail.com Thu Aug 20 16:06:46 2009 From: nagy.mostafa at gmail.com (Nagy Mostafa) Date: Thu, 20 Aug 2009 16:06:46 -0700 Subject: Build hotspot only in IcedTea after a complete build. Message-ID: Hi Everyone, I am having trouble compiling hotspot only in IcedTea6. I build IcedTea with Zero as follows: ./configure --enable-zero; make; Now, I want to modify the bytecode interpreter. What is the simplest way to compile hotspot only without compiling all of IcedTea. I tried "make hotspot", but sometimes it doesn't detect my code changes and even worse the build breaks occasionally. Also, how can you do a "make clean" for hotspot only. Additionally, how to do the same for a debug build ? I build initially as follows: ./configure --enable-zero; make SKIP_FASTDEBUG_BUILD=true SKIP_DEBUG_BUILD=false DEBUG_NAME=fulldebug; thanks, - nagy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090820/c0eb84e7/attachment.html From John.Coomes at sun.com Thu Aug 20 17:41:04 2009 From: John.Coomes at sun.com (John Coomes) Date: Thu, 20 Aug 2009 17:41:04 -0700 Subject: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <17c6771e0908200522u78b5a222j24661df5b76783c2@mail.gmail.com> References: <17c6771e0908180642k67a2cc68refa4232b1cf1770c@mail.gmail.com> <4A8AB98E.4030605@sun.com> <19082.59099.744855.256045@sun.com> <17c6771e0908191230y3aabadfcq70ab30782538036@mail.gmail.com> <19084.34943.379450.167908@sun.com> <17c6771e0908200522u78b5a222j24661df5b76783c2@mail.gmail.com> Message-ID: <19085.60704.711648.209254@sun.com> Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: > 2009/8/20 John Coomes : > > Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: > >> 2009/8/18 John Coomes : > >> > Daniel D. Daugherty (Daniel.Daugherty at Sun.COM) wrote: > >> >> Andrew, > >> >> > >> >> A couple of comments: > >> >> > >> >> - if you specify '-source 6', then '-target 6' is implied > >> >> ???? so you don't really need both > >> >> - I would prefer to see a top-level macro that defines the > >> >> ???? bootstrap tools javac option and then have the various > >> >> ???? Makefiles use that macro. Something in make/defs.make: > >> >> > >> >> ???? ???? ???? BOOTSTRAP_TOOLS.JAVAC.FLAGS="-source 6" > >> >> > >> >> ???? or something like that. > >> > > >> > +1 on the top-level macro. ????In HotSpot, I would call it JAVAC_FLAGS or > >> > COMPILE_JAVAC_FLAGS, and add it to the COMPILE.JAVAC macro (spelled > >> > COMPILE_JAVAC on windows) so that every compilation uses it. ????Then > >> > fewer places need to be touched. > >> > > >> > Also, please leave the default value empty. ????On platforms that need > >> > it, it can be set on the command line or in the environment. > >> > Specifying a value requires periodic maintenance. ????Yes, the period is > >> > long, but it's a pain when the build breaks because of some stale > >> > value in a makefile. > >> > > >> > >> Ok, here's the changeset I was working on before I received your mail > >> and which I've since successfully tested with hotspot-rt: > >> > >> http://cr.openjdk.java.net/~andrew/ecj/03/webrev.02/ > > > > I submitted your patch to the build queue; it will take several hours, > > there's one job ahead of it. > > > > After looking at it again, the include of make/defs.make in > > make/windows/makefiles/rules.make will most likely fail to build. ??The > > latter is a windows nmake file, so the gnu-specific syntax will be > > rejected and there are other unixisms in there (e.g., shell until). > > > > I had a feeling Windows would be the one to bite... > > > Instead, try updating MAKE_ARGS in make/defs.make, I believe those are > > exported to sub-makes. ??Since it has to be portable, I believe you'll > > have to use '_' instead of '.' in the macro name. > > > > Ok, in http://cr.openjdk.java.net/~andrew/ecj/03/webrev.03/ I've > reverted the addtion > of defs.make in favour of using MAKE_ARGS and renamed the variables > using underscores (which I prefer anyway). > > Where I am confused is how the MAKE_ARGS changes get through to the > Windows build if it doesn't parse defs.make. > makefiles/windows/defs.make seems to imply that the top-level one will > be read. > > >> This defines the variables in the top-level defs.make file. ??The > >> versions are stored separately, in the same way as they are in the > >> JDK: > >> > >> http://hg.openjdk.java.net/jdk7/build/jdk/rev/80368890a2a0 > >> > >> SA is still done separately as it's currently 1.4. ??The default for others is 6. > >> The rest of the patch ensures this makefile is picked up and its > >> values used for compilation across all three platforms. > >> > >> This is added to the invocations rather than COMPILE.JAVAC. ??As you > >> imply in your mail, this value varies between platforms and even > >> within the same platform. ??Just the GNU/Linux port itself defines it > >> in about four ways. > > > > Take a look, it's simply selecting which path to use. ??After the def > > of COMPILE.JAVAC, a simple > > > > ?? ?? ?? ??COMPILE.JAVAC += $(BOOTSTRAP_JAVAC.FLAGS) > > > > should do it. ??Windows will have to be different, though. > > > > Yes, the other problem is this forces the same options to SA as well > which uses COMPILE.JAVAC. To keep the current status quo (at least > for now), these need a different set of flags. > > >> I don't agree with leaving the value blank. ??The issue is relevant on > >> all platforms, as leaving it blank makes the build open to whatever > >> the default value is of the bootstrap JDK. ??For instance, this just > >> changed to 7 with OpenJDK, so current builds will produce 1.7 bytecode > >> while builds using an older OpenJDK7 or OpenJDK6 will use 6. ??From > >> personal experience, it's much harder to debug a problem when you have > >> to take into account the boot JDK being used, which may vary, than > >> when you have an explicit value. > >> > >> It seems much clearer to specify it explicitly in one common place for > >> all platforms, which can also be easily overridden from the command > >> line if needed. ??This is the same as is now done for JDK, langtools, > >> jaxp and jaxws and will shortly be the case in corba. > > > > The jdk, langtools, etc., repos are much more sensitive to this > > setting than hotspot, which uses it only for makedeps and jvmti header > > generation. ??It's non-critical, and I think it's safe to assume that > > the default class file version produced by a boot jdk can also be run > > by that same boot jdk. > > > > So far, ecj is the only known boot env needing this set explicitly. > > That kind of assumption is the thing that tends to come back and bite > you. It's especially true because: > > * The boot JDK is something determined on a per-user basis, so just > updating the system JDK may cause a failure that's hard to diagnose. > * Failures in HotSpot javac builds are already hard to diagnose > because it doesn't print out the javac invocation. It took me longer > to track this down than the equivalents in JDK and CORBA, and I've > been working with the OpenJDK build for about two years now. FWIW, you can get hotspot builds to be verbose with gmake ... QUIETLY= (i.e., set QUIETLY to an empty value) and it should show all command invocations. > Yes, ecj is the only one that fails. But we now have at least two > JDKs that will produce different results: OpenJDK6 (which defaults to > 6) and OpenJDK7 (which defaults to 7). There are even more if you > include the proprietary JDKs and JDK 1.5 which I assume can also build > OpenJDK at a push. > ... Different, but still correct. I'm resisting a default because it will get stale (they always do, SA is a good example). And it's worked for *years* (6? 8?) without a problem. But I won't reject the rest of it because there's a default. Sigh. > Finally, switching SA to use the defaults would be a visible change. Dan mentioned the SA values in passing; my impression was he thought they should be updated or removed. I don't work with the SA, but I suspect the settings are relics from using a boot jdk that had 1.3 as a default when SA needed 1.4 features. Anyone recall? Even if for some odd reason SA source should be limited to using 1.4 features, if you update JAVAC_COMPILE to include JAVAC_FLAGS (or whatever it is), and the SA makefile also includes -source/-target options on the command-line, the latter will override the ones in JAVAC_FLAGS (the SA command line may need to include both -source and -target). At least try it, I think it'll be a simpler change. I submitted your latest patch to the build queue for test builds; hopefully it will send you mail when it's finished (but I've never tried including a non-Sun email address before). -John > >> >> Which repo are you targeting for this change? > >> > > >> > I'd suggest hotspot-rt. > >> > > >> > Note that all hotspot changes have to be built on all platforms before > >> > being pushed; we have an automated system called jprt that does builds > >> > and tests on the various platforms. ????Unfortunately, it isn't available > >> > externally. ????Sync up with the latest hotspot-rt and then contact me > >> > privately with a patch or your repo location and I'll run it through. > >> > > >> > >> The patch from this webrev is against hotspot-rt so can be tested. > >> > >> >> Yes, I see that SA uses '-source 1.4' in each platform makefile. > >> >> That should be fixed also, but that's another issue... > >> > > >> > Sigh. ????Stale values in makefiles ... > >> > > >> > >> Also fixed now by this patch. ??At least 1.4 is in one common makefile > >> rather than occurring six times over three makefiles... :) > >> > >> > -John > >> > > >> >> > Andrew John Hughes wrote: > >> >> > The makeDeps and jvmti bootstrap tools are built without explicit > >> >> > source and target options. > >> >> > > >> >> > This webrev: > >> >> > > >> >> > http://cr.openjdk.java.net/~andrew/ecj/03/webrev.01/ > >> >> > > >> >> > sets them to 6 explicitly. The change has to be replicated three > >> >> > times, because for some reason, the javac invocations are in > >> >> > platform-specific makefiles. ????I've tested the change successfully on > >> >> > GNU/Linux, where it allows ecj to be used as javac. ????ecj defaults to > >> >> > <1.5 and thus otherwise fails to build. ????I've assumed that the same > >> >> > changes are applicable for Solaris and Windows, and that the source > >> >> > and target options don't have to be written in Latin or something to > >> >> > work on these platforms. > >> >> > > >> >> > Is this ok to push? > >> >> > > >> >> > 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 > > > > > > > > -- > 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 nagy.mostafa at gmail.com Thu Aug 20 17:53:44 2009 From: nagy.mostafa at gmail.com (Nagy Mostafa) Date: Thu, 20 Aug 2009 17:53:44 -0700 Subject: Build hotspot only in IcedTea after a complete build. In-Reply-To: References: Message-ID: So I read the instructions on Volker's blog ( http://weblogs.java.net/blog/simonis/archive/2008/01/hotspot_develop.html#HotSpotBuild) and I managed to build hotspot only successfully. The problem now is enabling Zero. I am running on AMD64 and the build fail with CC_INTERP=1. Why does this happen and why is Zero built correctly when I do a full build of IcedTea ? Anyway to enable Zero on AMD64 when building hotspot only ? The command I use is: CC_INTERP=true LP64=1 LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-6-sun/ HOTSPOT_BUILD_JOBS=5 ALT_OUTPUT_DIR=../../build/hotspot-debug make jvmg The build error is: /home/nagy/research/icedtea6-debug/openjdk/hotspot/src/cpu/x86/vm/bytecodeInterpreter_x86.hpp: In static member function 'static void SharedRuntime::generate_deopt_blob()': /home/nagy/research/icedtea6-debug/openjdk/hotspot/src/cpu/x86/vm/bytecodeInterpreter_x86.hpp:31: error: 'intptr_t* BytecodeInterpreter::_sender_sp' is private /home/nagy/research/icedtea6-debug/openjdk/hotspot/src/cpu/x86/vm/sharedRuntime_x86_64.cpp:2788: error: within this context /home/nagy/research/icedtea6-debug/openjdk/hotspot/src/cpu/x86/vm/bytecodeInterpreter_x86.hpp: In static member function 'static void SharedRuntime::generate_uncommon_trap_blob()': /home/nagy/research/icedtea6-debug/openjdk/hotspot/src/cpu/x86/vm/bytecodeInterpreter_x86.hpp:31: error: 'intptr_t* BytecodeInterpreter::_sender_sp' is private /home/nagy/research/icedtea6-debug/openjdk/hotspot/src/cpu/x86/vm/sharedRuntime_x86_64.cpp:2970: error: within this context make[4]: *** [sharedRuntime_x86_64.o] Error 1 thanks, - nagy On Thu, Aug 20, 2009 at 4:06 PM, Nagy Mostafa wrote: > Hi Everyone, > I am having trouble compiling hotspot only in IcedTea6. I build IcedTea > with Zero as follows: > ./configure --enable-zero; make; > > Now, I want to modify the bytecode interpreter. What is the simplest way to > compile hotspot only without compiling all of IcedTea. I tried "make > hotspot", but sometimes it doesn't detect my code changes and even worse the > build breaks occasionally. Also, how can you do a "make clean" for hotspot > only. > > Additionally, how to do the same for a debug build ? I build initially as > follows: > ./configure --enable-zero; make SKIP_FASTDEBUG_BUILD=true > SKIP_DEBUG_BUILD=false DEBUG_NAME=fulldebug; > > thanks, > - nagy > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090820/6650c24e/attachment.html From Daniel.Daugherty at Sun.COM Thu Aug 20 19:00:16 2009 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Thu, 20 Aug 2009 20:00:16 -0600 Subject: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <19085.60704.711648.209254@sun.com> References: <17c6771e0908180642k67a2cc68refa4232b1cf1770c@mail.gmail.com> <4A8AB98E.4030605@sun.com> <19082.59099.744855.256045@sun.com> <17c6771e0908191230y3aabadfcq70ab30782538036@mail.gmail.com> <19084.34943.379450.167908@sun.com> <17c6771e0908200522u78b5a222j24661df5b76783c2@mail.gmail.com> <19085.60704.711648.209254@sun.com> Message-ID: <4A8DFFB0.6060505@sun.com> John Coomes wrote: >> Finally, switching SA to use the defaults would be a visible change. >> > > Dan mentioned the SA values in passing; my impression was he thought > they should be updated or removed. I don't work with the SA, but I > suspect the settings are relics from using a boot jdk that had 1.3 as > a default when SA needed 1.4 features. Anyone recall? > > Even if for some odd reason SA source should be limited to using 1.4 > features, if you update JAVAC_COMPILE to include JAVAC_FLAGS (or > whatever it is), and the SA makefile also includes -source/-target > options on the command-line, the latter will override the ones in > JAVAC_FLAGS (the SA command line may need to include both -source and > -target). At least try it, I think it'll be a simpler change. > > I submitted your latest patch to the build queue for test builds; > hopefully it will send you mail when it's finished (but I've never > tried including a non-Sun email address before). > I've sent a query to Sundar directly so hopefully he'll see that instead of the alias mail... I figure he should know :-) Dan From David.Holmes at Sun.COM Thu Aug 20 20:04:04 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Fri, 21 Aug 2009 13:04:04 +1000 Subject: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <19085.60704.711648.209254@sun.com> References: <17c6771e0908180642k67a2cc68refa4232b1cf1770c@mail.gmail.com> <4A8AB98E.4030605@sun.com> <19082.59099.744855.256045@sun.com> <17c6771e0908191230y3aabadfcq70ab30782538036@mail.gmail.com> <19084.34943.379450.167908@sun.com> <17c6771e0908200522u78b5a222j24661df5b76783c2@mail.gmail.com> <19085.60704.711648.209254@sun.com> Message-ID: <4A8E0EA4.1050908@sun.com> John Coomes said the following on 08/21/09 10:41: > Dan mentioned the SA values in passing; my impression was he thought > they should be updated or removed. I don't work with the SA, but I > suspect the settings are relics from using a boot jdk that had 1.3 as > a default when SA needed 1.4 features. Anyone recall? Actually it's the opposite problem: it was to stop it from being compiled by JDK5 as target 1.5 code, to avoid all the generics-related warnings that you otherwise encounter with non-generified code. See CRs 5038934 and 5053732. So I suggest that this needs to be left as -source 1.4 Cheers, David From john.coomes at sun.com Thu Aug 20 20:39:11 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 21 Aug 2009 03:39:11 +0000 Subject: hg: jdk7/hotspot: 4 new changesets Message-ID: <20090821033911.A7187121FF@hg.openjdk.java.net> Changeset: 4cad5a3f5038 Author: asaha Date: 2009-08-07 11:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/4cad5a3f5038 6803688: Integrate latest JAX-WS (2.1.6) in to JDK 6u14 Reviewed-by: darcy, ramap ! THIRD_PARTY_README Changeset: fb676d15f20f Author: asaha Date: 2009-08-10 10:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/fb676d15f20f Merge Changeset: 175cb3fe6159 Author: tbell Date: 2009-08-14 08:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/175cb3fe6159 Merge Changeset: de7a3e98c159 Author: xdono Date: 2009-08-20 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/de7a3e98c159 Added tag jdk7-b70 for changeset 175cb3fe6159 ! .hgtags From john.coomes at sun.com Thu Aug 20 20:45:13 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 21 Aug 2009 03:45:13 +0000 Subject: hg: jdk7/hotspot/corba: 4 new changesets Message-ID: <20090821034517.ED4BE12204@hg.openjdk.java.net> Changeset: f3f572ea0cf2 Author: asaha Date: 2009-08-07 11:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/f3f572ea0cf2 6803688: Integrate latest JAX-WS (2.1.6) in to JDK 6u14 Reviewed-by: darcy, ramap ! THIRD_PARTY_README Changeset: 691649734a70 Author: asaha Date: 2009-08-10 10:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/691649734a70 Merge Changeset: 175bd6877954 Author: tbell Date: 2009-08-14 08:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/175bd6877954 Merge Changeset: 9f1959c73473 Author: xdono Date: 2009-08-20 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/9f1959c73473 Added tag jdk7-b70 for changeset 175bd6877954 ! .hgtags From john.coomes at sun.com Thu Aug 20 20:54:36 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 21 Aug 2009 03:54:36 +0000 Subject: hg: jdk7/hotspot/jaxp: 11 new changesets Message-ID: <20090821035453.C4D8012209@hg.openjdk.java.net> Changeset: 1687f5192ce7 Author: asaha Date: 2009-06-22 13:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/1687f5192ce7 6845701: Xerces2 Java XML library infinite loop with malformed XML input Reviewed-by: hawtin ! src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLScanner.java Changeset: 1b3c6eec7d31 Author: asaha Date: 2009-06-30 16:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/1b3c6eec7d31 Merge Changeset: e8d3c15bb7f6 Author: asaha Date: 2009-07-06 11:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/e8d3c15bb7f6 Merge Changeset: 1c82b475604f Author: asaha Date: 2009-07-21 11:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/1c82b475604f Merge Changeset: fb3829850f08 Author: asaha Date: 2009-07-27 22:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/fb3829850f08 Merge Changeset: 66f9efcdd76c Author: asaha Date: 2009-08-03 12:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/66f9efcdd76c Merge Changeset: 16184436ba33 Author: asaha Date: 2009-08-06 22:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/16184436ba33 Merge Changeset: c7914d53581c Author: asaha Date: 2009-08-07 11:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/c7914d53581c 6803688: Integrate latest JAX-WS (2.1.6) in to JDK 6u14 Reviewed-by: darcy, ramap ! THIRD_PARTY_README Changeset: deec13478962 Author: asaha Date: 2009-08-10 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/deec13478962 Merge Changeset: c83f0106b78a Author: tbell Date: 2009-08-14 08:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/c83f0106b78a Merge Changeset: ff94d8ce0dad Author: xdono Date: 2009-08-20 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/ff94d8ce0dad Added tag jdk7-b70 for changeset c83f0106b78a ! .hgtags From john.coomes at sun.com Thu Aug 20 21:12:00 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 21 Aug 2009 04:12:00 +0000 Subject: hg: jdk7/hotspot/jdk: 98 new changesets Message-ID: <20090821043737.D732C12213@hg.openjdk.java.net> Changeset: 12e479399ced Author: dl Date: 2009-07-28 13:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/12e479399ced 6785442: ConcurrentLinkedQueue.remove() and poll() can both remove the same element 6493942: ConcurrentLinkedQueue.remove sometimes very slow Summary: new algorithm for handling concurrent linked lists Reviewed-by: martin ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java - test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java - test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java + test/java/util/concurrent/ConcurrentQueues/ConcurrentQueueLoops.java + test/java/util/concurrent/ConcurrentQueues/GCRetention.java + test/java/util/concurrent/ConcurrentQueues/LoopHelpers.java + test/java/util/concurrent/ConcurrentQueues/RemovePollRace.java ! test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: 49573ab3096a Author: dl Date: 2009-07-28 17:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/49573ab3096a 6805775: LinkedBlockingQueue Nodes should unlink themselves before becoming garbage 6815766: LinkedBlockingQueue's iterator can return null if drainTo(c) executes concurrently Summary: Faster, more correct. Use self-linking trick to avoid gc retention Reviewed-by: martin, dholmes ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java ! test/java/util/Collection/MOAT.java + test/java/util/concurrent/BlockingQueue/OfferDrainToLoops.java + test/java/util/concurrent/ConcurrentQueues/IteratorWeakConsistency.java Changeset: 8cabd2931621 Author: sherman Date: 2009-07-24 11:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8cabd2931621 5063507: (fmt) missing exception for "%#s" format specifier Summary: throw appropriate exception when necessary Reviewed-by: alanb ! src/share/classes/java/util/Formatter.java ! test/java/util/Formatter/Basic-X.java ! test/java/util/Formatter/Basic.java ! test/java/util/Formatter/BasicBigDecimal.java ! test/java/util/Formatter/BasicBigInteger.java ! test/java/util/Formatter/BasicBoolean.java ! test/java/util/Formatter/BasicBooleanObject.java ! test/java/util/Formatter/BasicByte.java ! test/java/util/Formatter/BasicByteObject.java ! test/java/util/Formatter/BasicChar.java ! test/java/util/Formatter/BasicCharObject.java ! test/java/util/Formatter/BasicDateTime.java ! test/java/util/Formatter/BasicDouble.java ! test/java/util/Formatter/BasicDoubleObject.java ! test/java/util/Formatter/BasicFloat.java ! test/java/util/Formatter/BasicFloatObject.java ! test/java/util/Formatter/BasicInt.java ! test/java/util/Formatter/BasicIntObject.java ! test/java/util/Formatter/BasicLong.java ! test/java/util/Formatter/BasicLongObject.java ! test/java/util/Formatter/BasicShort.java ! test/java/util/Formatter/BasicShortObject.java Changeset: eb5173d782ca Author: sherman Date: 2009-07-24 11:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/eb5173d782ca Merge Changeset: eb27b5587e18 Author: sherman Date: 2009-07-29 11:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/eb27b5587e18 Merge - test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java - test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java Changeset: 61d174a58edf Author: martin Date: 2009-07-29 13:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/61d174a58edf 6866554: Misc. javadoc warnings Reviewed-by: alanb ! src/share/classes/java/nio/channels/DatagramChannel.java ! src/share/classes/java/nio/channels/package-info.java ! src/share/classes/java/nio/file/DirectoryStream.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/nio/file/attribute/package-info.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java Changeset: bfd7abda8f79 Author: jjb Date: 2009-07-29 14:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/bfd7abda8f79 6804124: Replace "modified mergesort" in java.util.Arrays.sort with timsort Summary: Easy port of timsort from android Reviewed-by: martin ! make/java/java/FILES_java.gmk ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collections.java + src/share/classes/java/util/ComparableTimSort.java + src/share/classes/java/util/TimSort.java + test/java/util/TimSort/ArrayBuilder.java + test/java/util/TimSort/README + test/java/util/TimSort/SortPerf.java + test/java/util/TimSort/Sorter.java Changeset: 15a7df80058e Author: martin Date: 2009-07-29 21:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/15a7df80058e 6866719: Rename execvpe to avoid symbol clash with glibc 2.10 Reviewed-by: darcy ! src/solaris/native/java/lang/UNIXProcess_md.c Changeset: 0c58a7b6b978 Author: weijun Date: 2009-07-31 16:21 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0c58a7b6b978 6867231: Regression: jdk/test/sun/security/krb5/ConfPlusProp.java error against jdk7/pit/b68 Reviewed-by: xuelei ! test/sun/security/krb5/ConfPlusProp.java Changeset: e2d9696aa701 Author: alanb Date: 2009-07-31 08:44 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e2d9696aa701 6867101: Path.checkAccess fails with sharing violation on special files such as pagefile.sys Reviewed-by: sherman ! src/windows/classes/sun/nio/fs/WindowsConstants.java ! src/windows/classes/sun/nio/fs/WindowsFileAttributes.java ! test/java/nio/file/Path/Misc.java Changeset: d5ee8b871362 Author: alanb Date: 2009-07-31 08:45 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d5ee8b871362 6867244: Tests missing @run tag Reviewed-by: sherman ! test/java/nio/channels/DatagramChannel/BasicMulticastTests.java ! test/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java ! test/java/nio/file/Files/ContentType.java Changeset: 160e02039cf7 Author: alanb Date: 2009-07-31 19:23 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/160e02039cf7 Merge Changeset: 358ec67d3252 Author: tbell Date: 2009-07-31 17:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/358ec67d3252 Merge - test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java - test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java Changeset: 2536ab04dc68 Author: weijun Date: 2009-08-02 13:40 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2536ab04dc68 6867687: keytool's standard.sh test timeout sometimes Reviewed-by: xuelei ! test/sun/security/tools/keytool/standard.sh Changeset: 1c9cfd050949 Author: tbell Date: 2009-08-02 10:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1c9cfd050949 Merge Changeset: c390fd8fa885 Author: sherman Date: 2009-08-04 12:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c390fd8fa885 4116222: Errors in Arabic code-conversion tables, part II Summary: updated the IBM420 datatable Reviewed-by: alanb ! make/tools/CharsetMapping/IBM420.c2b ! make/tools/CharsetMapping/IBM420.map ! make/tools/CharsetMapping/IBM420.nr ! make/tools/src/build/tools/charsetmapping/GenerateSBCS.java Changeset: 55186701bdbc Author: martin Date: 2009-08-04 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/55186701bdbc 6868160: (process) Use vfork, not fork, on Linux to avoid swap exhaustion Summary: Boldly go where no jdk has dared go before Reviewed-by: michaelm ! src/solaris/native/java/lang/UNIXProcess_md.c Changeset: a789c68f1cf3 Author: martin Date: 2009-08-04 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a789c68f1cf3 6856590: (process) Use RESTARTABLE in UNIXProcess_md.c Summary: Wrap all system calls with RESTARTABLE Reviewed-by: michaelm ! src/solaris/native/java/lang/UNIXProcess_md.c Changeset: 92394e48eed3 Author: dcubed Date: 2009-08-05 13:17 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/92394e48eed3 6868533: 3/4 JDI: remove '-source 1.5' and '-target 1.5' options from com.sun.jdi tests Summary: We are long past needing to make sure these tests can build on Tiger/JDK1.5.0. Reviewed-by: tbell ! test/com/sun/jdi/EnumTest.java ! test/com/sun/jdi/GenericsTest.java ! test/com/sun/jdi/JdbVarargsTest.sh ! test/com/sun/jdi/StepTest.java ! test/com/sun/jdi/UTF8Test.java ! test/com/sun/jdi/VarargsTest.java Changeset: 2aa570c01c69 Author: wetmore Date: 2009-08-06 17:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2aa570c01c69 6867657: Many JSN tests do not run under cygwin Reviewed-by: ohair ! test/java/net/Authenticator/B4933582.sh ! test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh ! test/java/net/Socket/OldSocketImpl.sh ! test/java/net/URL/B5086147.sh ! test/java/net/URL/runconstructor.sh ! test/java/net/URLClassLoader/B5077773.sh ! test/java/net/URLClassLoader/sealing/checksealed.sh ! test/java/net/URLConnection/6212146/test.sh ! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock.sh ! test/java/security/Security/signedfirst/Dyn.sh ! test/java/security/Security/signedfirst/Static.sh ! test/javax/crypto/SecretKeyFactory/FailOverTest.sh ! test/javax/security/auth/Subject/doAs/Test.sh ! test/lib/security/java.policy/Ext_AllPolicy.sh ! test/sun/net/www/MarkResetTest.sh ! test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh ! test/sun/net/www/http/HttpClient/RetryPost.sh ! test/sun/net/www/protocol/jar/B5105410.sh ! test/sun/net/www/protocol/jar/jarbug/run.sh ! test/sun/security/pkcs11/Provider/ConfigQuotedString.sh ! test/sun/security/pkcs11/Provider/Login.sh ! test/sun/security/provider/PolicyFile/getinstance/getinstance.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh ! test/sun/security/tools/jarsigner/AlgOptions.sh ! test/sun/security/tools/jarsigner/PercentSign.sh ! test/sun/security/tools/jarsigner/oldsig.sh ! test/sun/security/tools/keytool/AltProviderPath.sh ! test/sun/security/tools/keytool/CloneKeyAskPassword.sh ! test/sun/security/tools/keytool/NoExtNPE.sh ! test/sun/security/tools/keytool/SecretKeyKS.sh ! test/sun/security/tools/keytool/StandardAlgName.sh ! test/sun/security/tools/keytool/i18n.sh ! test/sun/security/tools/keytool/printssl.sh ! test/sun/security/tools/keytool/resource.sh ! test/sun/security/tools/keytool/standard.sh Changeset: bc1deb18bfb1 Author: jrose Date: 2009-08-06 18:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/bc1deb18bfb1 6838598: Legal notice repair: jdk/src/share/classes/sun/dyn/FilterGeneric.java Reviewed-by: xdono ! src/share/classes/sun/dyn/FilterGeneric.java Changeset: bf41e885717f Author: tbell Date: 2009-08-06 19:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/bf41e885717f Merge - test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java - test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java Changeset: 0d99696fec64 Author: chegar Date: 2009-08-07 10:50 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0d99696fec64 6826780: URLClassPath should use HashMap instead of HashMap Summary: Replace URL with a String representation. Reviewed-by: michaelm, jccollet ! make/sun/net/FILES_java.gmk ! src/share/classes/sun/misc/URLClassPath.java + src/share/classes/sun/net/util/URLUtil.java Changeset: 9424d836691f Author: chegar Date: 2009-08-07 10:51 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9424d836691f 6826801: JarFileFactory should not use HashMap Summary: Replace URL with a String representation. Reviewed-by: michaelm, jccollet ! src/solaris/classes/sun/net/www/protocol/jar/JarFileFactory.java ! src/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java Changeset: c43105502f46 Author: malenkov Date: 2009-04-29 20:03 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c43105502f46 6660539: Introspector shares cache of mutable BeanInfo between AppContexts. Reviewed-by: peterz ! src/share/classes/java/beans/Introspector.java + test/java/beans/Introspector/Test6660539.java Changeset: 3aeaa5784b3a Author: malenkov Date: 2009-04-29 20:55 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3aeaa5784b3a 6777487: Encoder allows reading private variables with certain names Reviewed-by: peterz ! src/share/classes/java/beans/MetaData.java + test/java/beans/XMLEncoder/6777487/TestBox.java + test/java/beans/XMLEncoder/6777487/TestCheckedCollection.java + test/java/beans/XMLEncoder/6777487/TestCheckedList.java + test/java/beans/XMLEncoder/6777487/TestCheckedMap.java + test/java/beans/XMLEncoder/6777487/TestCheckedRandomAccessList.java + test/java/beans/XMLEncoder/6777487/TestCheckedSet.java + test/java/beans/XMLEncoder/6777487/TestCheckedSortedMap.java + test/java/beans/XMLEncoder/6777487/TestCheckedSortedSet.java + test/java/beans/XMLEncoder/6777487/TestEncoder.java + test/java/beans/XMLEncoder/6777487/TestEnumMap.java + test/java/beans/XMLEncoder/6777487/TestEnumSet.java Changeset: 903ce4bda292 Author: asaha Date: 2009-04-29 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/903ce4bda292 Merge Changeset: 5b166df43d63 Author: peterz Date: 2009-05-05 12:07 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5b166df43d63 6837293: Reapply fix for 6588003 to JDK7 Reviewed-by: alexp ! src/share/classes/javax/swing/text/LayoutQueue.java Changeset: ead34d1e3c9f Author: jccollet Date: 2009-05-05 11:02 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ead34d1e3c9f 6801497: Proxy is assumed to be immutable but is non-final Summary: Cloned the proxy instance when necessary Reviewed-by: chegar ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/URL.java Changeset: 38a0e21f345a Author: anthony Date: 2009-05-05 17:47 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/38a0e21f345a 6805231: Security Warning Icon is missing in Windows 2000 Prof from Jdk build 6u12 Summary: The icon becomes layered only when the fading-out effect is being performed. Reviewed-by: art, dcherepanov ! src/windows/native/sun/windows/awt_Window.cpp ! src/windows/native/sun/windows/awt_Window.h Changeset: e0636bb69562 Author: anthony Date: 2009-05-05 17:56 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e0636bb69562 6818787: It is possible to reposition the security icon too far from the border of the window on X11 Summary: The constraints for the position of the icon are moved to the shared code Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Window.java ! src/windows/native/sun/windows/awt_Window.cpp Changeset: 4b498e41c1c2 Author: art Date: 2009-05-06 15:17 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4b498e41c1c2 6656586: Cursor.predefined is protected static mutable (findbugs) Reviewed-by: hawtin, igor ! src/share/classes/java/awt/Cursor.java + test/java/awt/Cursor/PredefinedPrivate/PredefinedPrivate.java Changeset: a53a57a3260c Author: emcmanus Date: 2009-05-07 10:44 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a53a57a3260c 6736293: OpenType checks can be bypassed through finalizer resurrection Reviewed-by: hawtin ! src/share/classes/java/awt/Window.java ! src/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java ! src/share/classes/javax/management/openmbean/OpenType.java Changeset: 7b50813648d8 Author: bae Date: 2009-05-08 15:38 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7b50813648d8 6656625: ImageReaderSpi.STANDARD_INPUT_TYPE/ImageWriterSpi.STANDARD_OUTPUT_TYPE are mutable static (findbugs) Reviewed-by: prr ! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriterSpi.java ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageWriterSpi.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriterSpi.java ! src/share/classes/com/sun/imageio/plugins/png/PNGImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/png/PNGImageWriterSpi.java ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageWriterSpi.java ! src/share/classes/javax/imageio/spi/ImageReaderSpi.java ! src/share/classes/javax/imageio/spi/ImageWriterSpi.java Changeset: c6ea5b6c3a8d Author: bae Date: 2009-05-08 15:57 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c6ea5b6c3a8d 6657133: Mutable statics in imageio plugins (findbugs) Reviewed-by: prr ! src/share/classes/com/sun/imageio/stream/StreamCloser.java ! src/share/classes/javax/imageio/plugins/bmp/BMPImageWriteParam.java ! src/share/classes/javax/imageio/stream/FileCacheImageInputStream.java ! src/share/classes/javax/imageio/stream/FileCacheImageOutputStream.java ! src/share/lib/security/java.security ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 597377f1ee71 Author: bae Date: 2009-05-08 16:15 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/597377f1ee71 6823373: [ZDI-CAN-460] Java Web Start JPEG header parsing needs more scruity Reviewed-by: igor ! src/share/native/sun/awt/splashscreen/splashscreen_jpeg.c Changeset: 3de7b0daf355 Author: chegar Date: 2009-05-12 16:32 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3de7b0daf355 6801071: Remote sites can compromise user privacy and possibly hijack web sessions Reviewed-by: jccollet, hawtin ! make/sun/net/FILES_java.gmk ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/SocksSocketImpl.java ! src/share/classes/java/net/URL.java + src/share/classes/sun/net/ApplicationProxy.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: 05200aff312e Author: amenkov Date: 2009-05-13 13:52 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/05200aff312e 6657625: RmfFileReader/StandardMidiFileWriter.types are public mutable statics (findbugs) Reviewed-by: hawtin ! src/share/classes/com/sun/media/sound/StandardMidiFileWriter.java Changeset: d09b81d1eb85 Author: amenkov Date: 2009-05-13 14:32 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d09b81d1eb85 6738524: JDK13Services allows read access to system properties from untrusted code Reviewed-by: hawtin ! src/share/classes/com/sun/media/sound/JDK13Services.java Changeset: 43ed4f9a781a Author: amenkov Date: 2009-05-13 14:32 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/43ed4f9a781a 6777448: JDK13Services.getProviders creates instances with full privileges [hawtin, alexp] Reviewed-by: hawtin, alexp ! src/share/classes/com/sun/media/sound/JSSecurityManager.java Changeset: ae62878e6eef Author: asaha Date: 2009-05-07 13:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ae62878e6eef Merge ! src/share/classes/java/awt/Window.java - src/share/native/sun/java2d/pipe/RenderBuffer.c ! src/windows/native/sun/windows/awt_Window.cpp ! src/windows/native/sun/windows/awt_Window.h - 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: bf002235470d Author: asaha Date: 2009-06-12 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/bf002235470d Merge Changeset: 8156e661d016 Author: asaha Date: 2009-06-12 12:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8156e661d016 Merge ! src/share/classes/java/awt/Window.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.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/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 ! src/windows/native/sun/windows/awt_Window.cpp ! src/windows/native/sun/windows/awt_Window.h Changeset: f2d65a92ffb2 Author: malenkov Date: 2009-06-18 14:08 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f2d65a92ffb2 6660049: Synth Region.uiToRegionMap/lowerCaseNameMap are mutable statics Reviewed-by: hawtin ! src/share/classes/javax/swing/plaf/synth/Region.java + test/javax/swing/plaf/synth/Test6660049.java Changeset: a209372d6de8 Author: asaha Date: 2009-06-17 13:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a209372d6de8 Merge Changeset: 2f126d8c369d Author: asaha Date: 2009-06-18 22:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2f126d8c369d Merge Changeset: 94bd5497a0d3 Author: asaha Date: 2009-06-18 22:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/94bd5497a0d3 Merge Changeset: 75fe05d49f44 Author: asaha Date: 2009-06-22 13:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/75fe05d49f44 6656610: AccessibleResourceBundle.getContents exposes mutable static (findbugs) Reviewed-by: hawtin ! src/share/classes/javax/accessibility/AccessibleResourceBundle.java Changeset: ffb8e36b668c Author: mullan Date: 2009-06-23 13:54 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ffb8e36b668c 6824440: XML Signature HMAC issue Reviewed-by: asaha ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMHMACSignatureMethod.java + test/com/sun/org/apache/xml/internal/security/TruncateHMAC.java + test/com/sun/org/apache/xml/internal/security/signature-enveloping-hmac-sha1-trunclen-0-attack.xml + test/com/sun/org/apache/xml/internal/security/signature-enveloping-hmac-sha1-trunclen-8-attack.xml ! test/javax/xml/crypto/dsig/GenerationTests.java ! test/javax/xml/crypto/dsig/ValidationTests.java + test/javax/xml/crypto/dsig/data/signature-enveloping-hmac-sha1-trunclen-0-attack.xml + test/javax/xml/crypto/dsig/data/signature-enveloping-hmac-sha1-trunclen-8-attack.xml Changeset: 7352778840c7 Author: ksrini Date: 2009-06-22 07:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7352778840c7 6830335: Java JAR Pack200 Decompression Integer Overflow Vulnerability Summary: Fixes a potential vulnerability in the unpack200 logic, by adding extra checks, a back-port. Reviewed-by: asaha ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp Changeset: 043280e1fc76 Author: asaha Date: 2009-07-01 09:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/043280e1fc76 Merge ! make/sun/net/FILES_java.gmk ! src/share/classes/java/net/SocksSocketImpl.java - src/share/classes/java/nio/file/DirectoryStreamFilters.java - src/share/classes/java/nio/file/FileAction.java - src/share/classes/java/nio/file/spi/AbstractPath.java - src/share/classes/sun/io/ByteToCharMS932DB.java - src/share/classes/sun/io/CharToByteMS932DB.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java - src/share/classes/sun/nio/cs/ext/EUC_CN.java - src/share/classes/sun/nio/cs/ext/EUC_KR.java - src/share/classes/sun/nio/cs/ext/GBK.java - src/share/classes/sun/nio/cs/ext/Johab.java - src/share/classes/sun/nio/cs/ext/MS932.java - src/share/classes/sun/nio/cs/ext/MS932DB.java - src/share/classes/sun/nio/cs/ext/MS936.java - src/share/classes/sun/nio/cs/ext/MS949.java - src/share/classes/sun/nio/cs/ext/MS950.java - src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java - src/share/classes/sun/nio/fs/MimeType.java - test/java/nio/file/DirectoryStream/Filters.java - test/java/nio/file/Files/content_type.sh - test/java/nio/file/Path/temporary_files.sh - test/java/nio/file/attribute/Attributes/Basic.java Changeset: 46e4a2e56801 Author: asaha Date: 2009-07-06 11:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/46e4a2e56801 Merge ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReaderSpi.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.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 Changeset: e2726b43d1cc Author: mullan Date: 2009-07-08 16:57 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e2726b43d1cc 6858484: If an invalid HMAC XML Signature is validated, all subsequent valid HMAC signatures are invalid Reviewed-by: asaha ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java ! test/com/sun/org/apache/xml/internal/security/TruncateHMAC.java + test/com/sun/org/apache/xml/internal/security/signature-enveloping-hmac-sha1.xml Changeset: 78a1ffa5a675 Author: asaha Date: 2009-07-08 14:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/78a1ffa5a675 Merge Changeset: 9b15d9813292 Author: asaha Date: 2009-07-08 14:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9b15d9813292 Merge Changeset: 537d8716d8cd Author: asaha Date: 2009-07-13 08:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/537d8716d8cd Merge Changeset: 599a7f770842 Author: asaha Date: 2009-07-15 10:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/599a7f770842 Merge Changeset: 97a5d7c6fbfb Author: vinnie Date: 2009-07-17 20:29 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/97a5d7c6fbfb 6657619: DnsContext.debug is public static mutable (findbugs) Reviewed-by: alanb ! src/share/classes/com/sun/jndi/dns/DnsContext.java + test/com/sun/jndi/dns/CheckAccess.java Changeset: df7d8ae860cf Author: vinnie Date: 2009-07-17 20:43 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/df7d8ae860cf 6657695: AbstractSaslImpl.logger is a static mutable (findbugs) Reviewed-by: alanb ! src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java + test/com/sun/security/sasl/util/CheckAccess.java Changeset: 83d1885b22d6 Author: asaha Date: 2009-07-21 13:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/83d1885b22d6 Merge ! src/share/classes/java/awt/Window.java ! src/share/classes/java/beans/MetaData.java - src/share/classes/sun/swing/AccessibleMethod.java Changeset: 14c81c80a7f3 Author: asaha Date: 2009-07-21 13:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/14c81c80a7f3 Merge Changeset: baec332a0ff4 Author: asaha Date: 2009-07-27 22:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/baec332a0ff4 Merge Changeset: ebc7d26588b8 Author: asaha Date: 2009-08-04 08:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ebc7d26588b8 Merge ! src/share/classes/java/awt/Window.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/MetaData.java - test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java - test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java Changeset: 6fe590dcc49c Author: asaha Date: 2009-08-05 14:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6fe590dcc49c Merge Changeset: c223ce2294c1 Author: asaha Date: 2009-08-06 22:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c223ce2294c1 Merge - src/share/classes/com/sun/crypto/provider/JarVerifier.java - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java - src/share/classes/sun/security/pkcs11/JarVerifier.java - src/windows/classes/sun/security/mscapi/JarVerifier.java Changeset: 1774d87963ad Author: asaha Date: 2009-08-07 09:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1774d87963ad Merge ! make/sun/net/FILES_java.gmk Changeset: 88229bdd8aae Author: andrew Date: 2009-08-07 18:15 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/88229bdd8aae 6869697: Missing entry in makefiles for java/lang/ReflectiveOperationException.java Summary: Add new dependency explicitly so all compilers pick it up Reviewed-by: darcy, ohair ! make/java/java/FILES_java.gmk Changeset: 5439d705c04e Author: weijun Date: 2009-08-11 12:15 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5439d705c04e 6866479: libzip.so caused JVM to crash when running jarsigner Reviewed-by: mullan ! src/share/classes/sun/security/tools/JarSigner.java + test/sun/security/tools/jarsigner/samename.sh Changeset: c98d2798e16f Author: weijun Date: 2009-08-11 12:17 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c98d2798e16f 6710360: export Kerberos session key to applications Reviewed-by: valeriep + src/share/classes/com/sun/security/jgss/ExtendedGSSContext.java + src/share/classes/com/sun/security/jgss/InquireSecContextPermission.java + src/share/classes/com/sun/security/jgss/InquireType.java ! src/share/classes/sun/security/jgss/GSSContextImpl.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/spi/GSSContextSpi.java ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java ! src/share/classes/sun/security/jgss/wrapper/NativeGSSContext.java ! src/share/classes/sun/security/tools/PolicyTool.java + test/com/sun/security/jgss/InquireSecContextPermissionCheck.java ! test/sun/security/krb5/auto/Context.java Changeset: 6db21e653d99 Author: weijun Date: 2009-08-11 12:20 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6db21e653d99 6821190: more InquireType values for ExtendedGSSContext Reviewed-by: valeriep + src/share/classes/com/sun/security/jgss/AuthorizationDataEntry.java ! src/share/classes/com/sun/security/jgss/ExtendedGSSContext.java ! src/share/classes/com/sun/security/jgss/InquireType.java ! src/share/classes/sun/security/jgss/krb5/InitSecContextToken.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! src/share/classes/sun/security/krb5/internal/AuthorizationData.java ! src/share/classes/sun/security/tools/PolicyTool.java ! test/sun/security/krb5/auto/Context.java Changeset: efe2d2a55b3b Author: weijun Date: 2009-08-11 15:36 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/efe2d2a55b3b 6868867: Test: sun/security/tools/keytool/standard.sh fails under windows/cygwin Reviewed-by: wetmore ! src/share/classes/sun/security/tools/KeyTool.java Changeset: aface89bfcf6 Author: xuelei Date: 2009-08-11 18:27 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/aface89bfcf6 6585239: Regression: 2 DNS tests fail with JDK 5.0u13 b01 and pass with 5.0u12fcs Reviewed-by: vinnie ! src/share/classes/com/sun/jndi/dns/DnsContext.java Changeset: 5b5df0632ecf Author: alanb Date: 2009-08-11 12:37 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5b5df0632ecf 4516760: (so) Intermittent SocketException: Transport endpoint is not connected (lnx) Reviewed-by: sherman ! src/solaris/native/sun/nio/ch/Net.c ! test/java/nio/channels/SocketChannel/Shutdown.java Changeset: 18554eea6ce6 Author: alanb Date: 2009-08-11 12:38 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/18554eea6ce6 6867781: (file) Examples in javadoc use newFileAttributeView instead of getFileAttributeView Reviewed-by: sherman ! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java ! src/share/classes/java/nio/file/attribute/PosixFileAttributeView.java Changeset: a9a5aabecc01 Author: alanb Date: 2009-08-11 12:49 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a9a5aabecc01 6865748: (file) SimpleFileVisitor methods ignore null arguments Reviewed-by: sherman ! src/share/classes/java/nio/file/SimpleFileVisitor.java ! test/java/nio/file/Files/Misc.java Changeset: 8b97f8827d08 Author: asaha Date: 2009-08-07 11:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8b97f8827d08 6803688: Integrate latest JAX-WS (2.1.6) in to JDK 6u14 Reviewed-by: darcy, ramap ! THIRD_PARTY_README Changeset: 1ec22dda0652 Author: asaha Date: 2009-08-10 09:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1ec22dda0652 Merge - src/share/classes/com/sun/crypto/provider/JarVerifier.java - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java - src/share/classes/sun/security/pkcs11/JarVerifier.java - src/windows/classes/sun/security/mscapi/JarVerifier.java Changeset: 7681fa43d310 Author: asaha Date: 2009-08-11 08:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7681fa43d310 Merge Changeset: 1ff7163fc5f7 Author: vinnie Date: 2009-08-11 16:52 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1ff7163fc5f7 6840752: Provide out-of-the-box support for ECC algorithms Reviewed-by: alanb, mullan, wetmore ! make/sun/security/Makefile + make/sun/security/ec/FILES_c.gmk + make/sun/security/ec/Makefile + make/sun/security/ec/mapfile-vers ! make/sun/security/other/Makefile + src/share/classes/sun/security/ec/ECDHKeyAgreement.java + src/share/classes/sun/security/ec/ECDSASignature.java + src/share/classes/sun/security/ec/ECKeyPairGenerator.java + src/share/classes/sun/security/ec/SunEC.java + src/share/classes/sun/security/ec/SunECEntries.java ! src/share/lib/security/java.security ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows + src/share/native/sun/security/ec/ECC_JNI.cpp + src/share/native/sun/security/ec/ec.c + src/share/native/sun/security/ec/ec.h + src/share/native/sun/security/ec/ec2.h + src/share/native/sun/security/ec/ec2_163.c + src/share/native/sun/security/ec/ec2_193.c + src/share/native/sun/security/ec/ec2_233.c + src/share/native/sun/security/ec/ec2_aff.c + src/share/native/sun/security/ec/ec2_mont.c + src/share/native/sun/security/ec/ec_naf.c + src/share/native/sun/security/ec/ecc_impl.h + src/share/native/sun/security/ec/ecdecode.c + src/share/native/sun/security/ec/ecl-curve.h + src/share/native/sun/security/ec/ecl-exp.h + src/share/native/sun/security/ec/ecl-priv.h + src/share/native/sun/security/ec/ecl.c + src/share/native/sun/security/ec/ecl.h + src/share/native/sun/security/ec/ecl_curve.c + src/share/native/sun/security/ec/ecl_gf.c + src/share/native/sun/security/ec/ecl_mult.c + src/share/native/sun/security/ec/ecp.h + src/share/native/sun/security/ec/ecp_192.c + src/share/native/sun/security/ec/ecp_224.c + src/share/native/sun/security/ec/ecp_256.c + src/share/native/sun/security/ec/ecp_384.c + src/share/native/sun/security/ec/ecp_521.c + src/share/native/sun/security/ec/ecp_aff.c + src/share/native/sun/security/ec/ecp_jac.c + src/share/native/sun/security/ec/ecp_jm.c + src/share/native/sun/security/ec/ecp_mont.c + src/share/native/sun/security/ec/logtab.h + src/share/native/sun/security/ec/mp_gf2m-priv.h + src/share/native/sun/security/ec/mp_gf2m.c + src/share/native/sun/security/ec/mp_gf2m.h + src/share/native/sun/security/ec/mpi-config.h + src/share/native/sun/security/ec/mpi-priv.h + src/share/native/sun/security/ec/mpi.c + src/share/native/sun/security/ec/mpi.h + src/share/native/sun/security/ec/mplogic.c + src/share/native/sun/security/ec/mplogic.h + src/share/native/sun/security/ec/mpmontg.c + src/share/native/sun/security/ec/mpprime.h + src/share/native/sun/security/ec/oid.c + src/share/native/sun/security/ec/secitem.c + src/share/native/sun/security/ec/secoidt.h + test/sun/security/ec/TestEC.java + test/sun/security/ec/p12passwords.txt + test/sun/security/ec/pkcs12/secp256r1server-secp384r1ca.p12 + test/sun/security/ec/pkcs12/sect193r1server-rsa1024ca.p12 Changeset: 485d3eb9b50b Author: vinnie Date: 2009-08-11 16:57 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/485d3eb9b50b Merge Changeset: 95ae810b66fb Author: vinnie Date: 2009-08-11 17:01 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/95ae810b66fb Merge Changeset: 36e0f4e00f20 Author: dcubed Date: 2009-08-11 20:02 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/36e0f4e00f20 6870298: 4/4 fix minor typos in java/lang/instrument/Instrumentation.java Summary: Fix typos in the JavaDoc. Reviewed-by: tbell ! src/share/classes/java/lang/instrument/Instrumentation.java Changeset: 82b66d0368ff Author: dcubed Date: 2009-08-11 20:06 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/82b66d0368ff Merge - src/share/classes/com/sun/crypto/provider/JarVerifier.java - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java - src/share/classes/sun/security/pkcs11/JarVerifier.java - src/windows/classes/sun/security/mscapi/JarVerifier.java Changeset: abac33c4bd67 Author: tbell Date: 2009-08-14 08:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/abac33c4bd67 Merge Changeset: fb51d4974400 Author: uta Date: 2009-07-31 17:24 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/fb51d4974400 6851688: Hung up in applet application Reviewed-by: art, dcherepanov ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h Changeset: e6f6765a20f2 Author: yan Date: 2009-08-06 01:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e6f6765a20f2 Merge - src/share/classes/com/sun/crypto/provider/JarVerifier.java - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java - src/share/classes/sun/security/pkcs11/JarVerifier.java - src/windows/classes/sun/security/mscapi/JarVerifier.java Changeset: e066c998e4f3 Author: yan Date: 2009-08-12 00:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e066c998e4f3 Merge Changeset: 4c6a5ea563ba Author: peytoia Date: 2009-07-30 14:45 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4c6a5ea563ba 6866243: Javadoc for java.lang.Character still refers to Unicode 4 instead of 5 Reviewed-by: okutsu ! src/share/classes/java/lang/Character.java Changeset: 389cecd0ca18 Author: malenkov Date: 2009-07-31 16:27 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/389cecd0ca18 6865565: Test failed: /test/closed/javax/swing/JInternalFrame/6325652/bug6325652.java Reviewed-by: peterz + test/javax/swing/JInternalFrame/Test6325652.java ! test/javax/swing/JInternalFrame/Test6505027.java ! test/javax/swing/JInternalFrame/Test6802868.java ! test/javax/swing/JScrollPane/Test6526631.java ! test/javax/swing/SwingTest.java Changeset: 23dfc2c451e3 Author: gsm Date: 2009-08-03 19:22 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/23dfc2c451e3 6539700: JTextPane line wrap radically different from previous versions in jre 1.5.0_10+ Reviewed-by: peterz ! src/share/classes/javax/swing/text/GlyphView.java ! src/share/classes/javax/swing/text/ParagraphView.java + test/javax/swing/text/GlyphView/6539700/bug6539700.java Changeset: e548894909dc Author: andrew Date: 2009-08-06 16:04 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e548894909dc 6593649: Word wrap broken for JTextArea Summary: Layout correctly resizes components based on actual dimensions of the window they are in. Reviewed-by: gsm Contributed-by: Lillian Angel ! src/share/classes/javax/swing/text/WrappedPlainView.java + test/javax/swing/JTextArea/Test6593649.java Changeset: 7f2d92517f09 Author: yan Date: 2009-08-07 02:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7f2d92517f09 Merge - src/share/classes/com/sun/crypto/provider/JarVerifier.java ! src/share/classes/java/lang/Character.java - src/share/classes/sun/security/pkcs11/JarVerifier.java - src/windows/classes/sun/security/mscapi/JarVerifier.java Changeset: 082ffa4c6749 Author: malenkov Date: 2009-08-07 19:06 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/082ffa4c6749 6868189: Nested enum class with custom BeanInfo fails Reviewed-by: peterz ! src/share/classes/com/sun/beans/finder/BeanInfoFinder.java + test/java/beans/Introspector/Test6868189.java Changeset: 6794e1f16729 Author: rupashka Date: 2009-08-10 14:55 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6794e1f16729 6461173: One JCK test([NewFolderAction0001]) failed on Windows due to lack of PropertyPermission(s) Reviewed-by: peterz, malenkov ! src/share/classes/javax/swing/filechooser/FileSystemView.java ! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java Changeset: 8e65977e4969 Author: alexp Date: 2009-08-10 16:29 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8e65977e4969 6822696: Integrating JXLayer component to Swing library Reviewed-by: peterz, art + src/share/classes/javax/swing/JLayer.java + src/share/classes/javax/swing/plaf/LayerUI.java + test/javax/swing/JLayer/SerializationTest/SerializationTest.java Changeset: 5ff018677b2d Author: yan Date: 2009-08-12 00:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5ff018677b2d Merge Changeset: 893bcca951b7 Author: yan Date: 2009-08-18 23:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/893bcca951b7 Merge Changeset: de49d1343d86 Author: xdono Date: 2009-08-20 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/de49d1343d86 Added tag jdk7-b70 for changeset 893bcca951b7 ! .hgtags From john.coomes at sun.com Thu Aug 20 21:51:27 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 21 Aug 2009 04:51:27 +0000 Subject: hg: jdk7/hotspot/langtools: 32 new changesets Message-ID: <20090821045222.1358D12218@hg.openjdk.java.net> Changeset: 777a3efad0d5 Author: jjg Date: 2009-07-28 10:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/777a3efad0d5 6855990: javap InstructionDetailWriter should support new 308 annotations attribute Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java ! src/share/classes/com/sun/tools/javap/AnnotationWriter.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/TypeAnnotationWriter.java + test/tools/javap/typeAnnotations/T6855990.java Changeset: 85b317ac8a0c Author: jjg Date: 2009-07-28 11:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/85b317ac8a0c 6734068: Some variable length attributes set their size incorrectly. Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/classfile/CharacterRangeTable_attribute.java ! src/share/classes/com/sun/tools/classfile/LineNumberTable_attribute.java ! src/share/classes/com/sun/tools/classfile/LocalVariableTable_attribute.java ! src/share/classes/com/sun/tools/classfile/LocalVariableTypeTable_attribute.java ! src/share/classes/com/sun/tools/classfile/ModuleExportTable_attribute.java ! src/share/classes/com/sun/tools/classfile/ModuleMemberTable_attribute.java Changeset: c2dfab9e2f39 Author: jjg Date: 2009-07-29 13:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/c2dfab9e2f39 4777949: Javap Rewrite : Warn javap usage on package classes with simple name. Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javap/JavapFileManager.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/resources/javap.properties + test/tools/javap/T4777949.java Changeset: 85fecace920b Author: mcimadamore Date: 2009-07-30 10:29 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/85fecace920b 6827648: Extremely slow compilation time for visitor pattern code + generics Summary: Javac unnecessarily recomputates type-substitutions multiple times Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Types.java Changeset: b1e027181dd4 Author: mcimadamore Date: 2009-07-30 10:30 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/b1e027181dd4 6862608: rich diagnostic sometimes contain wrong type variable numbering Summary: The rich formatter generates worng numbers for type-variables in where clauses Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java + test/tools/javac/Diagnostics/6862608/T6862608a.java + test/tools/javac/Diagnostics/6862608/T6862608a.out + test/tools/javac/Diagnostics/6862608/T6862608b.java + test/tools/javac/Diagnostics/6862608/T6862608b.out Changeset: dd5c51734ad9 Author: mcimadamore Date: 2009-07-30 10:30 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/dd5c51734ad9 6864382: NPE in the rich formatter when processing an unattributed type-variable Summary: Unattributed type variable should not be accessed by the rich formatter when emitting where clauses Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java + test/tools/javac/Diagnostics/6864382/T6864382.java + test/tools/javac/Diagnostics/6864382/T6864382.out Changeset: 6d0add6ad778 Author: mcimadamore Date: 2009-07-30 10:30 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/6d0add6ad778 6861837: JCK compilation failures Summary: Type-annotations processing is accessing type info before they are available in MemberEnter Reviewed-by: jjg Contributed-by: mali at csail.mit.edu ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! test/tools/javac/typeAnnotations/InnerClass.java Changeset: 23505e6ea22d Author: jjg Date: 2009-07-30 07:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/23505e6ea22d 6866657: add byteLength method to primary classfile types Reviewed-by: mchung ! src/share/classes/com/sun/tools/classfile/AccessFlags.java ! src/share/classes/com/sun/tools/classfile/Attribute.java ! src/share/classes/com/sun/tools/classfile/Attributes.java ! src/share/classes/com/sun/tools/classfile/ClassFile.java ! src/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/share/classes/com/sun/tools/classfile/Field.java ! src/share/classes/com/sun/tools/classfile/Method.java + test/tools/javap/T6866657.java Changeset: e33efb09ed75 Author: jjg Date: 2009-07-30 09:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/e33efb09ed75 4880672: javap does not output inner interfaces of an interface Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/Options.java ! src/share/classes/com/sun/tools/javap/resources/javap.properties + test/tools/javap/T4880672.java Changeset: dbf8a2816201 Author: tbell Date: 2009-07-31 17:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/dbf8a2816201 Merge Changeset: 743f17b55b44 Author: jjg Date: 2009-08-04 17:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/743f17b55b44 6867671: javap whitespace formatting issues Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javap/AttributeWriter.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/ConstantWriter.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/Options.java Changeset: bc0b1f404c40 Author: jjg Date: 2009-08-05 07:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/bc0b1f404c40 6868553: 6867671 breaks some tests Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! test/tools/javac/code/ArrayClone.java ! test/tools/javap/4111861/T4111861.java ! test/tools/javap/T4884240.java ! test/tools/javap/T4975569.java ! test/tools/javap/stackmap/T6271292.sh Changeset: 526de25e0b28 Author: jjg Date: 2009-08-05 08:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/526de25e0b28 6729471: javap should accept class files on the command line Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javap/JavapTask.java + test/tools/javap/T6729471.java Changeset: b5ab848ba68f Author: tbell Date: 2009-08-06 19:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/b5ab848ba68f Merge Changeset: 160d7a994e69 Author: jjg Date: 2009-08-06 19:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/160d7a994e69 6858429: javap classfile library a minor bug Reviewed-by: ksrini ! src/share/classes/com/sun/tools/classfile/ClassWriter.java Changeset: 3e38c6da72ec Author: tbell Date: 2009-08-06 20:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/3e38c6da72ec Merge Changeset: cba827f72977 Author: jjg Date: 2009-08-08 17:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/cba827f72977 6868548: remove spurious ';' from after constant pool entries Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! src/share/classes/com/sun/tools/javap/ConstantWriter.java ! test/tools/javac/code/ArrayClone.java Changeset: 961dc3acdb06 Author: jjg Date: 2009-08-08 17:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/961dc3acdb06 6868539: javap should use current names for constant pool tags Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! src/share/classes/com/sun/tools/javap/ConstantWriter.java + test/tools/javap/T6868539.java Changeset: d5f6c475f475 Author: mcimadamore Date: 2009-08-11 01:11 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/d5f6c475f475 6806876: ClassCastException occurs in assignment expressions without any heap pollutions Summary: intersection types should be considered as non-reifiable by javac Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/varargs/6806876/T6806876.java + test/tools/javac/varargs/6806876/T6806876.out Changeset: abe992640c5a Author: mcimadamore Date: 2009-08-11 01:12 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/abe992640c5a 6390045: Unexpected error "cannot access java.lang.Void" with '-target cldc1.0' with -source >=1.5 Summary: javac needs to synthetize a fake java.lang.Void symbol if one is not given on the classpath Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symtab.java + test/tools/javac/6390045/T6390045a.java + test/tools/javac/6390045/T6390045b.java Changeset: 62073a5becc5 Author: mcimadamore Date: 2009-08-11 01:12 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/62073a5becc5 6840059: regression: javac silently crashes when resolving erroneous anonymous inner constructor Summary: resolved an internal crash with constructor resolution Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/6840059/T6840059.java + test/tools/javac/6840059/T6840059.out Changeset: 8227961c64d3 Author: mcimadamore Date: 2009-08-11 01:13 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/8227961c64d3 6521805: Regression: JDK5/JDK6 javac allows write access to outer class reference Summary: javac should warn/complain about identifiers with the same name as synthetic symbol Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/6521805/T6521805a.java + test/tools/javac/6521805/T6521805a_1.out + test/tools/javac/6521805/T6521805a_2.out + test/tools/javac/6521805/T6521805b.java + test/tools/javac/6521805/T6521805c.java + test/tools/javac/6521805/T6521805d.java + test/tools/javac/6521805/T6521805d.out + test/tools/javac/6521805/T6521805e.java + test/tools/javac/6521805/T6521805e.out + test/tools/javac/6521805/p/Outer.java + test/tools/javac/6521805/p/Sub.java ! test/tools/javac/6734819/T6734819a.out ! test/tools/javac/6734819/T6734819b.out ! test/tools/javac/policy/test2/byfile.AB.out ! test/tools/javac/policy/test2/bytodo.AB.out Changeset: 62fb6cafa93b Author: mcimadamore Date: 2009-08-11 01:13 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/62fb6cafa93b 6869075: regression: javac crashes when compiling compound string assignment with generics Summary: javac should not add syntehtic cast to the LHS of an assignment expression Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/tools/javac/generics/T6869075.java Changeset: 13902c0c9b83 Author: mcimadamore Date: 2009-08-11 01:14 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/13902c0c9b83 6569404: Cannot instantiate an inner class of a type variable Summary: javac is too strict in rejecting member selction from a type-var Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/generics/typevars/6569404/T6569404a.java + test/tools/javac/generics/typevars/6569404/T6569404b.java + test/tools/javac/generics/typevars/6569404/T6569404b.out + test/tools/javac/generics/typevars/6569404/T6569404c.java Changeset: c4c424badb83 Author: mcimadamore Date: 2009-08-11 01:14 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/c4c424badb83 6199153: Generic throws and overriding Summary: javac incorrectly rejects an uchecked overriding Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/OverrideChecks/6199153/T6199153.java + test/tools/javac/OverrideChecks/6199153/T6199153.out Changeset: 21f1d2462c7c Author: asaha Date: 2009-08-07 11:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/21f1d2462c7c 6803688: Integrate latest JAX-WS (2.1.6) in to JDK 6u14 Reviewed-by: darcy, ramap ! THIRD_PARTY_README Changeset: 91852fb12e2e Author: asaha Date: 2009-08-10 09:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/91852fb12e2e Merge Changeset: 38f54dbd2e5b Author: asaha Date: 2009-08-11 08:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/38f54dbd2e5b Merge Changeset: beefdeb352e6 Author: jjg Date: 2009-08-11 14:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/beefdeb352e6 6870591: langtools build sets javac.bootclasspath incorrectly Reviewed-by: ohair ! make/build.xml Changeset: 5a26c8fd0830 Author: jjg Date: 2009-08-11 18:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/5a26c8fd0830 6870743: update comments in langtools/make/build.properties Reviewed-by: darcy ! make/build.properties Changeset: 97d06f3e8787 Author: tbell Date: 2009-08-14 08:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/97d06f3e8787 Merge Changeset: 6f07b50a8796 Author: xdono Date: 2009-08-20 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/6f07b50a8796 Added tag jdk7-b70 for changeset 97d06f3e8787 ! .hgtags From Christian.Thalinger at Sun.COM Fri Aug 21 05:17:37 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 21 Aug 2009 14:17:37 +0200 Subject: Build hotspot only in IcedTea after a complete build. In-Reply-To: References: Message-ID: <4A8E9061.7000508@Sun.COM> Nagy Mostafa wrote: > So I read the instructions on Volker's blog > (http://weblogs.java.net/blog/simonis/archive/2008/01/hotspot_develop.html#HotSpotBuild) > and I managed to build hotspot only successfully. The problem now is > enabling Zero. I am running on AMD64 and the build fail with > CC_INTERP=1. Why does this happen and why is Zero built correctly when I > do a full build of IcedTea ? > > Anyway to enable Zero on AMD64 when building hotspot only ? The command > I use is: > > CC_INTERP=true LP64=1 LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-6-sun/ > HOTSPOT_BUILD_JOBS=5 ALT_OUTPUT_DIR=../../build/hotspot-debug make jvmg Zero is currently not part of HotSpot itself but a patch of the IcedTea project, so you might get better answers on distro-pkg-dev. Anyway, there is a patch in review to integrate Zero in HotSpot and the request also contains some instructions for building: http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001957.html -- Christian From gnu_andrew at member.fsf.org Fri Aug 21 05:23:42 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 21 Aug 2009 13:23:42 +0100 Subject: Build hotspot only in IcedTea after a complete build. In-Reply-To: <4A8E9061.7000508@Sun.COM> References: <4A8E9061.7000508@Sun.COM> Message-ID: <17c6771e0908210523i6854a162g7faf03a954245df8@mail.gmail.com> 2009/8/21 Christian Thalinger : > Nagy Mostafa wrote: >> So I read the instructions on Volker's blog >> (http://weblogs.java.net/blog/simonis/archive/2008/01/hotspot_develop.html#HotSpotBuild) >> and I managed to build hotspot only successfully. The problem now is >> enabling Zero. I am running on AMD64 and the build fail with >> CC_INTERP=1. Why does this happen and why is Zero built correctly when I >> do a full build of IcedTea ? >> >> Anyway to enable Zero on AMD64 when building hotspot only ? The command >> I use is: >> >> CC_INTERP=true LP64=1 LANG=C ALT_BOOTDIR=/usr/lib/jvm/java-6-sun/ >> HOTSPOT_BUILD_JOBS=5 ALT_OUTPUT_DIR=../../build/hotspot-debug make jvmg > > Zero is currently not part of HotSpot itself but a patch of the IcedTea > project, so you might get better answers on distro-pkg-dev. > > Anyway, there is a patch in review to integrate Zero in HotSpot and the > request also contains some instructions for building: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001957.html > > -- Christian > Will the HotSpot team be giving feedback on this patch sometime soon? The patch is already integrated into the IcedTea JDK7 forest and working just fine. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Christian.Thalinger at Sun.COM Fri Aug 21 05:33:36 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 21 Aug 2009 14:33:36 +0200 Subject: Build hotspot only in IcedTea after a complete build. In-Reply-To: <17c6771e0908210523i6854a162g7faf03a954245df8@mail.gmail.com> References: <4A8E9061.7000508@Sun.COM> <17c6771e0908210523i6854a162g7faf03a954245df8@mail.gmail.com> Message-ID: <4A8E9420.4000405@Sun.COM> Andrew John Hughes wrote: > Will the HotSpot team be giving feedback on this patch sometime soon? > The patch is already integrated into the IcedTea JDK7 forest and > working just fine. Yes. We already discussed it in one of our meetings and Tom Rodriguez will send some feedback (hopefully today). -- Christian From gbenson at redhat.com Fri Aug 21 06:00:36 2009 From: gbenson at redhat.com (Gary Benson) Date: Fri, 21 Aug 2009 14:00:36 +0100 Subject: Build hotspot only in IcedTea after a complete build. In-Reply-To: References: Message-ID: <20090821130036.GC3295@redhat.com> Nagy Mostafa wrote: > I am having trouble compiling hotspot only in IcedTea6. I build > IcedTea with Zero as follows: > > ./configure --enable-zero; make; > > Now, I want to modify the bytecode interpreter. What is the > simplest way to compile hotspot only without compiling all of > IcedTea. I tried "make hotspot", but sometimes it doesn't detect > my code changes and even worse the build breaks occasionally. IcedTea has a two stage build when you configure it that way. The first stage is a bootstrap: it builds OpenJDK using GCJ and ECJ. The bootstrapped OpenJDK lives in "openjdk-ecj". The second stage builds OpenJDK with the bootstrapped OpenJDK. This final OpenJDK lives in "openjdk". The "make hotspot" rule in IcedTea rebuilds the HotSpot in the bootstrap VM in "openjdk-ecj". So, to use "make hotspot" you need to do an initial build like this: ./configure --enable-zero make icedtea-against-ecj This will build the bootstrap VM only. Now you can edit the code in "openjdk-ecj" and rebuild like this: make hotspot > Also, how can you do a "make clean" for hotspot only. The easiest way is this: rm -Rf openjdk-ecj/build/*/hotspot ...and then do "make hotspot" again. Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Fri Aug 21 06:01:04 2009 From: gbenson at redhat.com (Gary Benson) Date: Fri, 21 Aug 2009 14:01:04 +0100 Subject: Build hotspot only in IcedTea after a complete build. In-Reply-To: <4A8E9420.4000405@Sun.COM> References: <4A8E9061.7000508@Sun.COM> <17c6771e0908210523i6854a162g7faf03a954245df8@mail.gmail.com> <4A8E9420.4000405@Sun.COM> Message-ID: <20090821130104.GD3295@redhat.com> Christian Thalinger wrote: > Andrew John Hughes wrote: > > Will the HotSpot team be giving feedback on this patch sometime > > soon? The patch is already integrated into the IcedTea JDK7 > > forest and working just fine. > > Yes. We already discussed it in one of our meetings and Tom > Rodriguez will send some feedback (hopefully today). Excellent, I'll look forward to it. Cheers, Gary -- http://gbenson.net/ From gnu_andrew at member.fsf.org Fri Aug 21 06:31:41 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 21 Aug 2009 14:31:41 +0100 Subject: Build hotspot only in IcedTea after a complete build. In-Reply-To: <20090821130036.GC3295@redhat.com> References: <20090821130036.GC3295@redhat.com> Message-ID: <17c6771e0908210631n40683637r7c33e20726165ef4@mail.gmail.com> 2009/8/21 Gary Benson : > Nagy Mostafa wrote: >> I am having trouble compiling hotspot only in IcedTea6. I build >> IcedTea with Zero as follows: >> >> ./configure --enable-zero; make; >> > >> Now, I want to modify the bytecode interpreter. ?What is the >> simplest way to compile hotspot only without compiling all of >> IcedTea. ?I tried "make hotspot", but sometimes it doesn't detect >> my code changes and even worse the build breaks occasionally. > > IcedTea has a two stage build when you configure it that way. ?The > first stage is a bootstrap: it builds OpenJDK using GCJ and ECJ. > The bootstrapped OpenJDK lives in "openjdk-ecj". ?The second stage > builds OpenJDK with the bootstrapped OpenJDK. ?This final OpenJDK > lives in "openjdk". > > The "make hotspot" rule in IcedTea rebuilds the HotSpot in the > bootstrap VM in "openjdk-ecj". ?So, to use "make hotspot" you > need to do an initial build like this: > > ?./configure --enable-zero > ?make icedtea-against-ecj > > This will build the bootstrap VM only. ?Now you can edit the code > in "openjdk-ecj" and rebuild like this: > > ?make hotspot > Doesn't this mean that 'make hotspot' is broken when you perform a --with-icedtea build? If so, that's a bug. Not sure how to solve it offhand though. >> Also, how can you do a "make clean" for hotspot only. > > The easiest way is this: > > ?rm -Rf openjdk-ecj/build/*/hotspot > > ...and then do "make hotspot" again. > hotspot seems to be about the only thing we don't have a clean-* rule for :) > Cheers, > Gary > > -- > http://gbenson.net/ > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From john.coomes at sun.com Thu Aug 20 21:01:31 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 21 Aug 2009 04:01:31 +0000 Subject: hg: jdk7/hotspot/jaxws: 5 new changesets Message-ID: <20090821040139.9B90F1220E@hg.openjdk.java.net> Changeset: 860b95cc8d1d Author: asaha Date: 2009-08-07 11:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/860b95cc8d1d 6813167: 6u14 JAX-WS audit mutable static bugs 6803688: Integrate latest JAX-WS (2.1.6) in to JDK 6u14 Reviewed-by: darcy, ramap ! THIRD_PARTY_README + jaxws.patch + patch.out ! src/share/classes/com/sun/codemodel/internal/JAnnotatable.java ! src/share/classes/com/sun/codemodel/internal/JAnnotationUse.java ! src/share/classes/com/sun/codemodel/internal/JAnnotationWriter.java ! src/share/classes/com/sun/codemodel/internal/JBlock.java ! src/share/classes/com/sun/codemodel/internal/JCommentPart.java ! src/share/classes/com/sun/codemodel/internal/JDirectClass.java ! src/share/classes/com/sun/codemodel/internal/JExpr.java ! src/share/classes/com/sun/codemodel/internal/JJavaName.java ! src/share/classes/com/sun/codemodel/internal/JMethod.java ! src/share/classes/com/sun/codemodel/internal/JPackage.java ! src/share/classes/com/sun/codemodel/internal/JTypeWildcard.java ! src/share/classes/com/sun/codemodel/internal/TypedAnnotationWriter.java - src/share/classes/com/sun/codemodel/internal/fmt/package.html ! src/share/classes/com/sun/codemodel/internal/package-info.java ! src/share/classes/com/sun/codemodel/internal/util/EncoderFactory.java ! src/share/classes/com/sun/codemodel/internal/util/MS1252Encoder.java ! src/share/classes/com/sun/codemodel/internal/writer/FilterCodeWriter.java + src/share/classes/com/sun/istack/internal/Builder.java ! src/share/classes/com/sun/istack/internal/Pool.java ! src/share/classes/com/sun/istack/internal/XMLStreamReaderToContentHandler.java + src/share/classes/com/sun/istack/internal/localization/Localizable.java + src/share/classes/com/sun/istack/internal/localization/LocalizableMessage.java + src/share/classes/com/sun/istack/internal/localization/LocalizableMessageFactory.java + src/share/classes/com/sun/istack/internal/localization/Localizer.java ! src/share/classes/com/sun/istack/internal/ws/AnnotationProcessorFactoryImpl.java ! src/share/classes/com/sun/tools/internal/jxc/ConfigReader.java ! src/share/classes/com/sun/tools/internal/jxc/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/jxc/Messages.java ! src/share/classes/com/sun/tools/internal/jxc/SchemaGenerator.java + src/share/classes/com/sun/tools/internal/jxc/SchemaGeneratorFacade.java ! src/share/classes/com/sun/tools/internal/jxc/apt/AnnotationParser.java ! src/share/classes/com/sun/tools/internal/jxc/apt/AnnotationProcessorFactoryImpl.java ! src/share/classes/com/sun/tools/internal/jxc/apt/Const.java ! src/share/classes/com/sun/tools/internal/jxc/apt/ErrorReceiverImpl.java ! src/share/classes/com/sun/tools/internal/jxc/apt/InlineAnnotationReaderImpl.java ! src/share/classes/com/sun/tools/internal/jxc/apt/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/jxc/apt/Messages.java ! src/share/classes/com/sun/tools/internal/jxc/apt/Options.java ! src/share/classes/com/sun/tools/internal/jxc/apt/SchemaGenerator.java ! src/share/classes/com/sun/tools/internal/jxc/gen/config/Classes.java ! src/share/classes/com/sun/tools/internal/jxc/gen/config/Config.java ! src/share/classes/com/sun/tools/internal/jxc/gen/config/Schema.java ! src/share/classes/com/sun/tools/internal/jxc/gen/config/config.xsd ! src/share/classes/com/sun/tools/internal/jxc/model/nav/APTNavigator.java ! src/share/classes/com/sun/tools/internal/ws/Invoker.java ! src/share/classes/com/sun/tools/internal/ws/api/TJavaGeneratorExtension.java + src/share/classes/com/sun/tools/internal/ws/api/WsgenExtension.java + src/share/classes/com/sun/tools/internal/ws/api/WsgenProtocol.java ! src/share/classes/com/sun/tools/internal/ws/api/wsdl/TWSDLExtensible.java ! src/share/classes/com/sun/tools/internal/ws/api/wsdl/TWSDLExtension.java ! src/share/classes/com/sun/tools/internal/ws/api/wsdl/TWSDLExtensionHandler.java ! src/share/classes/com/sun/tools/internal/ws/api/wsdl/TWSDLOperation.java ! src/share/classes/com/sun/tools/internal/ws/api/wsdl/TWSDLParserContext.java ! src/share/classes/com/sun/tools/internal/ws/package-info.java ! src/share/classes/com/sun/tools/internal/ws/processor/generator/GeneratorBase.java ! src/share/classes/com/sun/tools/internal/ws/processor/generator/SeiGenerator.java ! src/share/classes/com/sun/tools/internal/ws/processor/generator/ServiceGenerator.java ! src/share/classes/com/sun/tools/internal/ws/processor/generator/W3CAddressingJavaGeneratorExtension.java ! src/share/classes/com/sun/tools/internal/ws/processor/model/Port.java ! src/share/classes/com/sun/tools/internal/ws/processor/model/java/JavaMethod.java ! src/share/classes/com/sun/tools/internal/ws/processor/model/jaxb/JAXBType.java ! src/share/classes/com/sun/tools/internal/ws/processor/modeler/annotation/WebServiceAP.java ! src/share/classes/com/sun/tools/internal/ws/processor/modeler/annotation/WebServiceVisitor.java ! src/share/classes/com/sun/tools/internal/ws/processor/modeler/annotation/WebServiceWrapperGenerator.java ! src/share/classes/com/sun/tools/internal/ws/processor/modeler/wsdl/ConsoleErrorReporter.java ! src/share/classes/com/sun/tools/internal/ws/processor/modeler/wsdl/PseudoSchemaBuilder.java ! src/share/classes/com/sun/tools/internal/ws/processor/modeler/wsdl/WSDLModeler.java ! src/share/classes/com/sun/tools/internal/ws/processor/modeler/wsdl/WSDLModelerBase.java ! src/share/classes/com/sun/tools/internal/ws/processor/util/ClassNameCollector.java ! src/share/classes/com/sun/tools/internal/ws/resources/GeneratorMessages.java ! src/share/classes/com/sun/tools/internal/ws/resources/ModelMessages.java ! src/share/classes/com/sun/tools/internal/ws/resources/ModelerMessages.java ! src/share/classes/com/sun/tools/internal/ws/resources/WebserviceapMessages.java ! src/share/classes/com/sun/tools/internal/ws/resources/WscompileMessages.java ! src/share/classes/com/sun/tools/internal/ws/resources/WsdlMessages.java ! src/share/classes/com/sun/tools/internal/ws/resources/configuration.properties ! src/share/classes/com/sun/tools/internal/ws/resources/generator.properties ! src/share/classes/com/sun/tools/internal/ws/resources/javacompiler.properties ! src/share/classes/com/sun/tools/internal/ws/resources/model.properties ! src/share/classes/com/sun/tools/internal/ws/resources/modeler.properties ! src/share/classes/com/sun/tools/internal/ws/resources/processor.properties ! src/share/classes/com/sun/tools/internal/ws/resources/util.properties ! src/share/classes/com/sun/tools/internal/ws/resources/webserviceap.properties ! src/share/classes/com/sun/tools/internal/ws/resources/wscompile.properties ! src/share/classes/com/sun/tools/internal/ws/resources/wsdl.properties ! src/share/classes/com/sun/tools/internal/ws/version.properties ! src/share/classes/com/sun/tools/internal/ws/wscompile/AbortException.java + src/share/classes/com/sun/tools/internal/ws/wscompile/AuthInfo.java ! src/share/classes/com/sun/tools/internal/ws/wscompile/BadCommandLineException.java + src/share/classes/com/sun/tools/internal/ws/wscompile/DefaultAuthTester.java + src/share/classes/com/sun/tools/internal/ws/wscompile/DefaultAuthenticator.java ! src/share/classes/com/sun/tools/internal/ws/wscompile/ErrorReceiver.java ! src/share/classes/com/sun/tools/internal/ws/wscompile/ErrorReceiverFilter.java ! src/share/classes/com/sun/tools/internal/ws/wscompile/JavaCompilerHelper.java ! src/share/classes/com/sun/tools/internal/ws/wscompile/Options.java ! src/share/classes/com/sun/tools/internal/ws/wscompile/WsgenOptions.java ! src/share/classes/com/sun/tools/internal/ws/wscompile/WsgenTool.java ! src/share/classes/com/sun/tools/internal/ws/wscompile/WsimportListener.java ! src/share/classes/com/sun/tools/internal/ws/wscompile/WsimportOptions.java ! src/share/classes/com/sun/tools/internal/ws/wscompile/WsimportTool.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/document/Message.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/document/jaxws/JAXWSBinding.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/framework/AbstractDocument.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/AbstractReferenceFinderImpl.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/DOMBuilder.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/DOMForest.java + src/share/classes/com/sun/tools/internal/ws/wsdl/parser/DOMForestParser.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/DOMForestScanner.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/InternalizationLogic.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/Internalizer.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/MemberSubmissionAddressingExtensionHandler.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/MetadataFinder.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/NamespaceContextImpl.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/VersionChecker.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/W3CAddressingExtensionHandler.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/WSDLInternalizationLogic.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/WSDLParser.java ! src/share/classes/com/sun/tools/internal/ws/wsdl/parser/WhitespaceStripper.java + src/share/classes/com/sun/tools/internal/xjc/ClassLoaderBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/Driver.java ! src/share/classes/com/sun/tools/internal/xjc/Language.java ! src/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/xjc/ModelLoader.java ! src/share/classes/com/sun/tools/internal/xjc/Options.java ! src/share/classes/com/sun/tools/internal/xjc/ProgressCodeWriter.java ! src/share/classes/com/sun/tools/internal/xjc/SchemaCache.java + src/share/classes/com/sun/tools/internal/xjc/XJCFacade.java ! src/share/classes/com/sun/tools/internal/xjc/XJCListener.java ! src/share/classes/com/sun/tools/internal/xjc/addon/at_generated/PluginImpl.java ! src/share/classes/com/sun/tools/internal/xjc/addon/code_injector/Const.java ! src/share/classes/com/sun/tools/internal/xjc/addon/code_injector/PluginImpl.java ! src/share/classes/com/sun/tools/internal/xjc/addon/episode/PluginImpl.java ! src/share/classes/com/sun/tools/internal/xjc/addon/episode/package-info.java ! src/share/classes/com/sun/tools/internal/xjc/api/ClassNameAllocator.java ! src/share/classes/com/sun/tools/internal/xjc/api/J2SJAXBModel.java ! src/share/classes/com/sun/tools/internal/xjc/api/Reference.java ! src/share/classes/com/sun/tools/internal/xjc/api/S2JJAXBModel.java ! src/share/classes/com/sun/tools/internal/xjc/api/SchemaCompiler.java ! src/share/classes/com/sun/tools/internal/xjc/api/SpecVersion.java ! src/share/classes/com/sun/tools/internal/xjc/api/TypeAndAnnotation.java ! src/share/classes/com/sun/tools/internal/xjc/api/impl/j2s/JAXBModelImpl.java ! src/share/classes/com/sun/tools/internal/xjc/api/impl/j2s/JavaCompilerImpl.java - src/share/classes/com/sun/tools/internal/xjc/api/impl/j2s/Messages.java - src/share/classes/com/sun/tools/internal/xjc/api/impl/j2s/Messages.properties ! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/AbstractMappingImpl.java ! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/BeanMappingImpl.java ! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/DowngradingErrorHandler.java ! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/ElementAdapter.java ! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/ElementCollectionAdapter.java ! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/ElementMappingImpl.java ! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/ElementSingleAdapter.java ! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/PropertyImpl.java ! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/SchemaCompilerImpl.java ! src/share/classes/com/sun/tools/internal/xjc/api/impl/s2j/TypeAndAnnotationImpl.java ! src/share/classes/com/sun/tools/internal/xjc/api/package.html ! src/share/classes/com/sun/tools/internal/xjc/api/util/APTClassLoader.java ! src/share/classes/com/sun/tools/internal/xjc/api/util/FilerCodeWriter.java ! src/share/classes/com/sun/tools/internal/xjc/api/util/Messages.properties ! src/share/classes/com/sun/tools/internal/xjc/api/util/ToolsJarNotFoundException.java + src/share/classes/com/sun/tools/internal/xjc/generator/annotation/ri/OverrideAnnotationOfWriter.java ! src/share/classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementRefWriter.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/BeanGenerator.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/DualObjectFactoryGenerator.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/ElementOutlineImpl.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/ImplStructureStrategy.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/MethodWriter.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/ObjectFactoryGeneratorImpl.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/PackageOutlineImpl.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/PrivateObjectFactoryGenerator.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/PublicObjectFactoryGenerator.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/AbstractField.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/AbstractFieldWithVar.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/AbstractListField.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/ArrayField.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/ConstFieldRenderer.java + src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/ContentListField.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/DefaultFieldRenderer.java + src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/DummyListField.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/FieldRenderer.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/FieldRendererFactory.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/IsSetFieldRenderer.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/Messages.java + src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/NoExtendedContentField.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/SingleField.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/SinglePrimitiveAccessField.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/UnboxedField.java ! src/share/classes/com/sun/tools/internal/xjc/generator/bean/field/UntypedListFieldRenderer.java ! src/share/classes/com/sun/tools/internal/xjc/generator/package-info.java ! src/share/classes/com/sun/tools/internal/xjc/model/AbstractCElement.java ! src/share/classes/com/sun/tools/internal/xjc/model/AbstractCTypeInfoImpl.java ! src/share/classes/com/sun/tools/internal/xjc/model/AutoClassNameAllocator.java ! src/share/classes/com/sun/tools/internal/xjc/model/CAdapter.java ! src/share/classes/com/sun/tools/internal/xjc/model/CArrayInfo.java ! src/share/classes/com/sun/tools/internal/xjc/model/CAttributePropertyInfo.java ! src/share/classes/com/sun/tools/internal/xjc/model/CBuiltinLeafInfo.java ! src/share/classes/com/sun/tools/internal/xjc/model/CClass.java ! src/share/classes/com/sun/tools/internal/xjc/model/CClassInfo.java ! src/share/classes/com/sun/tools/internal/xjc/model/CClassInfoParent.java ! src/share/classes/com/sun/tools/internal/xjc/model/CClassRef.java ! src/share/classes/com/sun/tools/internal/xjc/model/CCustomizable.java ! src/share/classes/com/sun/tools/internal/xjc/model/CCustomizations.java ! src/share/classes/com/sun/tools/internal/xjc/model/CDefaultValue.java ! src/share/classes/com/sun/tools/internal/xjc/model/CElement.java ! src/share/classes/com/sun/tools/internal/xjc/model/CElementInfo.java ! src/share/classes/com/sun/tools/internal/xjc/model/CElementPropertyInfo.java ! src/share/classes/com/sun/tools/internal/xjc/model/CEnumConstant.java ! src/share/classes/com/sun/tools/internal/xjc/model/CNonElement.java ! src/share/classes/com/sun/tools/internal/xjc/model/CPluginCustomization.java ! src/share/classes/com/sun/tools/internal/xjc/model/CPropertyInfo.java ! src/share/classes/com/sun/tools/internal/xjc/model/CPropertyVisitor.java ! src/share/classes/com/sun/tools/internal/xjc/model/CReferencePropertyInfo.java ! src/share/classes/com/sun/tools/internal/xjc/model/CSingleTypePropertyInfo.java ! src/share/classes/com/sun/tools/internal/xjc/model/CTypeInfo.java ! src/share/classes/com/sun/tools/internal/xjc/model/CTypeRef.java ! src/share/classes/com/sun/tools/internal/xjc/model/CValuePropertyInfo.java ! src/share/classes/com/sun/tools/internal/xjc/model/CWildcardTypeInfo.java ! src/share/classes/com/sun/tools/internal/xjc/model/ClassNameAllocatorWrapper.java ! src/share/classes/com/sun/tools/internal/xjc/model/Model.java ! src/share/classes/com/sun/tools/internal/xjc/model/Populatable.java ! src/share/classes/com/sun/tools/internal/xjc/model/TypeUse.java ! src/share/classes/com/sun/tools/internal/xjc/model/TypeUseFactory.java ! src/share/classes/com/sun/tools/internal/xjc/model/TypeUseImpl.java ! src/share/classes/com/sun/tools/internal/xjc/model/nav/EagerNClass.java ! src/share/classes/com/sun/tools/internal/xjc/model/nav/EagerNType.java ! src/share/classes/com/sun/tools/internal/xjc/model/nav/NClass.java ! src/share/classes/com/sun/tools/internal/xjc/model/nav/NClassByJClass.java ! src/share/classes/com/sun/tools/internal/xjc/model/nav/NParameterizedType.java ! src/share/classes/com/sun/tools/internal/xjc/model/nav/NType.java ! src/share/classes/com/sun/tools/internal/xjc/model/nav/NavigatorImpl.java ! src/share/classes/com/sun/tools/internal/xjc/model/package-info.java ! src/share/classes/com/sun/tools/internal/xjc/outline/Aspect.java ! src/share/classes/com/sun/tools/internal/xjc/outline/ClassOutline.java ! src/share/classes/com/sun/tools/internal/xjc/outline/ElementOutline.java ! src/share/classes/com/sun/tools/internal/xjc/outline/EnumConstantOutline.java ! src/share/classes/com/sun/tools/internal/xjc/outline/EnumOutline.java ! src/share/classes/com/sun/tools/internal/xjc/package-info.java ! src/share/classes/com/sun/tools/internal/xjc/reader/AbstractExtensionBindingChecker.java ! src/share/classes/com/sun/tools/internal/xjc/reader/Const.java ! src/share/classes/com/sun/tools/internal/xjc/reader/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/xjc/reader/ModelChecker.java ! src/share/classes/com/sun/tools/internal/xjc/reader/RawTypeSet.java ! src/share/classes/com/sun/tools/internal/xjc/reader/Ring.java ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/Block.java ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/Element.java ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/ModelGroup.java ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/Occurence.java ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/Term.java ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/DOMBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/DOMUtil.java ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/DTDExtensionBindingChecker.java ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/bindingfile.rng ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/bindingfile.xsd ! src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/xjc.xsd ! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/Choice.java ! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/ConnectedComponent.java ! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/Element.java ! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/ElementSet.java ! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/ElementSets.java ! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/Expression.java ! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/Graph.java ! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/OneOrMore.java ! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/Sequence.java ! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/SinkNode.java ! src/share/classes/com/sun/tools/internal/xjc/reader/gbind/SourceNode.java ! src/share/classes/com/sun/tools/internal/xjc/reader/internalizer/ContentHandlerNamespacePrefixAdapter.java ! src/share/classes/com/sun/tools/internal/xjc/reader/internalizer/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/xjc/reader/internalizer/NamespaceContextImpl.java ! src/share/classes/com/sun/tools/internal/xjc/reader/internalizer/SCDBasedBindingSet.java ! src/share/classes/com/sun/tools/internal/xjc/reader/internalizer/WhitespaceStripper.java ! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/BindStyle.java ! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/ContentModelBinder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/DatatypeLib.java ! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/DefineFinder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/NameCalculator.java ! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/RELAXNGCompiler.java ! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/RawTypeSetBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/TypePatternBinder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/relaxng/TypeUseBinder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/Abstractifier.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/BGMBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/BindBlue.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/BindGreen.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/BindPurple.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/BindRed.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/BindYellow.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/BindingComponent.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ClassBinderFilter.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/CollisionInfo.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ColorBinder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/DefaultParticleBinder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ExpressionBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ExpressionParticleBinder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/GElement.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/GElementImpl.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/GWildcardElement.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/Messages.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/MultiplicityCounter.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/RawTypeSetBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/RefererFinder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/SimpleTypeBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/UnusedCustomizationChecker.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/AnnotationParserFactoryImpl.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIConversion.java + src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIFactoryMethod.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIGlobalBinding.java + src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIInlineBinaryData.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIProperty.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIXDom.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIXPluginCustomization.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIXSubstitutable.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BindInfo.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/CollectionTypeAttribute.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/DomHandlerEx.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/EnumMemberMode.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/ForkingFilter.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/LocalScoping.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/OptionalPropertyMode.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/binding.rng ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/binding.xsd ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/package-info.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/package.html ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/xjc.xsd ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/xs.xsd + src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/AbstractExtendedComplexTypeBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/ChoiceContentComplexTypeBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/ComplexTypeBindingMode.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/ComplexTypeFieldBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/ExtendedComplexTypeBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/Messages.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MixedComplexTypeBuilder.java + src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/MixedExtendedComplexTypeBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/RestrictedComplexTypeBuilder.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/LSInputSAXWrapper.java ! src/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/xjc/runtime/JAXBContextFactory.java ! src/share/classes/com/sun/tools/internal/xjc/runtime/ZeroOneBooleanAdapter.java ! src/share/classes/com/sun/tools/internal/xjc/util/ForkContentHandler.java ! src/share/classes/com/sun/tools/internal/xjc/util/ForkEntityResolver.java ! src/share/classes/com/sun/tools/internal/xjc/util/MessageBundle.properties ! src/share/classes/com/sun/tools/internal/xjc/util/MimeTypeRange.java ! src/share/classes/com/sun/tools/internal/xjc/util/NamespaceContextAdapter.java ! src/share/classes/com/sun/tools/internal/xjc/util/ReadOnlyAdapter.java ! src/share/classes/com/sun/tools/internal/xjc/util/StringCutter.java ! src/share/classes/com/sun/tools/internal/xjc/util/SubtreeCutter.java ! src/share/classes/com/sun/xml/internal/bind/AccessorFactoryImpl.java ! src/share/classes/com/sun/xml/internal/bind/AnyTypeAdapter.java ! src/share/classes/com/sun/xml/internal/bind/CycleRecoverable.java ! src/share/classes/com/sun/xml/internal/bind/DatatypeConverterImpl.java ! src/share/classes/com/sun/xml/internal/bind/IDResolver.java ! src/share/classes/com/sun/xml/internal/bind/Locatable.java ! src/share/classes/com/sun/xml/internal/bind/Util.java ! src/share/classes/com/sun/xml/internal/bind/ValidationEventLocatorEx.java ! src/share/classes/com/sun/xml/internal/bind/XmlAccessorFactory.java + src/share/classes/com/sun/xml/internal/bind/annotation/OverrideAnnotationOf.java ! src/share/classes/com/sun/xml/internal/bind/annotation/XmlIsSet.java ! src/share/classes/com/sun/xml/internal/bind/annotation/XmlLocation.java ! src/share/classes/com/sun/xml/internal/bind/api/AccessorException.java ! src/share/classes/com/sun/xml/internal/bind/api/Bridge.java ! src/share/classes/com/sun/xml/internal/bind/api/BridgeContext.java ! src/share/classes/com/sun/xml/internal/bind/api/ClassResolver.java ! src/share/classes/com/sun/xml/internal/bind/api/CompositeStructure.java ! src/share/classes/com/sun/xml/internal/bind/api/ErrorListener.java ! src/share/classes/com/sun/xml/internal/bind/api/JAXBRIContext.java + src/share/classes/com/sun/xml/internal/bind/api/Messages.java + src/share/classes/com/sun/xml/internal/bind/api/Messages.properties ! src/share/classes/com/sun/xml/internal/bind/api/RawAccessor.java ! src/share/classes/com/sun/xml/internal/bind/api/TypeReference.java ! src/share/classes/com/sun/xml/internal/bind/api/impl/NameConverter.java ! src/share/classes/com/sun/xml/internal/bind/api/impl/NameUtil.java ! src/share/classes/com/sun/xml/internal/bind/api/package-info.java ! src/share/classes/com/sun/xml/internal/bind/marshaller/DataWriter.java ! src/share/classes/com/sun/xml/internal/bind/marshaller/Messages.properties ! src/share/classes/com/sun/xml/internal/bind/marshaller/MinimumEscapeHandler.java ! src/share/classes/com/sun/xml/internal/bind/marshaller/NamespacePrefixMapper.java ! src/share/classes/com/sun/xml/internal/bind/marshaller/XMLWriter.java ! src/share/classes/com/sun/xml/internal/bind/unmarshaller/DOMScanner.java ! src/share/classes/com/sun/xml/internal/bind/unmarshaller/Messages.properties ! src/share/classes/com/sun/xml/internal/bind/unmarshaller/Patcher.java ! src/share/classes/com/sun/xml/internal/bind/util/AttributesImpl.java ! src/share/classes/com/sun/xml/internal/bind/util/ValidationEventLocatorExImpl.java ! src/share/classes/com/sun/xml/internal/bind/util/Which.java ! src/share/classes/com/sun/xml/internal/bind/v2/ClassFactory.java ! src/share/classes/com/sun/xml/internal/bind/v2/ContextFactory.java ! src/share/classes/com/sun/xml/internal/bind/v2/Messages.properties ! src/share/classes/com/sun/xml/internal/bind/v2/TODO.java ! src/share/classes/com/sun/xml/internal/bind/v2/bytecode/ClassTailor.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/AbstractInlineAnnotationReaderImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/AnnotationReader.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/AnnotationSource.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/ClassLocatable.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/FieldLocatable.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/Init.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/Locatable.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/LocatableAnnotation.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/Messages.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/Messages.properties ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/MethodLocatable.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/Quick.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/RuntimeAnnotationReader.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/RuntimeInlineAnnotationReader.java + src/share/classes/com/sun/xml/internal/bind/v2/model/annotation/XmlSchemaTypeQuick.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/Adapter.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/ArrayInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/AttributePropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/BuiltinLeafInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/ClassInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/Element.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/ElementInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/ElementPropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/EnumConstant.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/EnumLeafInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/ErrorHandler.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/ID.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/LeafInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/MapPropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/MaybeElement.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/NonElement.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/NonElementRef.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/PropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/PropertyKind.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/Ref.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/ReferencePropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/RegistryInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/TypeInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/TypeInfoSet.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/TypeRef.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/ValuePropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/WildcardMode.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/WildcardTypeInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/core/package-info.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/AnyTypeImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ArrayInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/AttributePropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/BuiltinLeafInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ClassInfoImpl.java + src/share/classes/com/sun/xml/internal/bind/v2/model/impl/DummyPropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ERPropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ElementInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ElementPropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/EnumConstantImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/EnumLeafInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/FieldPropertySeed.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/GetterSetterPropertySeed.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/LeafInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/MapPropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/Messages.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/Messages.properties ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ModelBuilder.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/PropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/PropertySeed.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ReferencePropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RegistryInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeAnyTypeImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeArrayInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeAttributePropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeBuiltinLeafInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeClassInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementPropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeEnumConstantImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeEnumLeafInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeMapPropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeModelBuilder.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeReferencePropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeTypeInfoSetImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeTypeRefImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeValuePropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/SingleTypePropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/TypeInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/TypeInfoSetImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/TypeRefImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/Util.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/impl/ValuePropertyInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/nav/GenericArrayTypeImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/nav/Navigator.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/nav/ParameterizedTypeImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/nav/ReflectionNavigator.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/nav/TypeVisitor.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/nav/WildcardTypeImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeArrayInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeAttributePropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeBuiltinLeafInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeClassInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeElement.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeElementInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeElementPropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeEnumLeafInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeLeafInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeMapPropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeNonElement.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeNonElementRef.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimePropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeReferencePropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeTypeInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeTypeInfoSet.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeTypeRef.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeValuePropertyInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/model/runtime/package-info.java ! src/share/classes/com/sun/xml/internal/bind/v2/package-info.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/AnyTypeBeanInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/ArrayBeanInfoImpl.java + src/share/classes/com/sun/xml/internal/bind/v2/runtime/AttributeAccessor.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/BinderImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/BridgeAdapter.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/BridgeContextImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/BridgeImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/ClassBeanInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/CompositeStructureBeanInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/Coordinator.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/DomPostInitAction.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/ElementBeanInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/FilterTransducer.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/IllegalAnnotationException.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/IllegalAnnotationsException.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/InlineBinaryTransducer.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/InternalBridge.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/JAXBContextImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/JaxBeanInfo.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/LeafBeanInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/LifecycleMethods.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/Location.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/MarshallerImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/Messages.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/Messages.properties ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/MimeTypedTransducer.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/Name.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/NameBuilder.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/NameList.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/RuntimeUtil.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/SchemaTypeTransducer.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/StAXPostInitAction.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/SwaRefAdapter.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/Transducer.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/ValueListBeanInfoImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/XMLSerializer.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/C14nXmlOutput.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/DOMOutput.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/Encoded.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/FastInfosetStreamWriterOutput.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/ForkXmlOutput.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/InPlaceDOMOutput.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/IndentingUTF8XmlOutput.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/MTOMXmlOutput.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/NamespaceContextImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/Pcdata.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/SAXOutput.java + src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/StAXExStreamWriterOutput.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/UTF8XmlOutput.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/XMLEventWriterOutput.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/XMLStreamWriterOutput.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/XmlOutput.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/XmlOutputAbstractImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/output/package-info.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/ArrayERProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/ArrayElementLeafProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/ArrayElementNodeProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/ArrayElementProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/ArrayProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/ArrayReferenceNodeProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/AttributeProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/ListElementProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/Messages.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/Messages.properties ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/Property.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/PropertyFactory.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/PropertyImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/SingleElementLeafProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/SingleElementNodeProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/SingleMapNodeProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/SingleReferenceNodeProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/StructureLoaderBuilder.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/TagAndType.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/UnmarshallerChain.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/property/ValueProperty.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/Accessor.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/AdaptedAccessor.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/AdaptedLister.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/DefaultTransducedAccessor.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/ListIterator.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/ListTransducedAccessorImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/Lister.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/Messages.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/Messages.properties ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/NullSafeAccessor.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerBoolean.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerByte.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerCharacter.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerDouble.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerFloat.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerInteger.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerLong.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerShort.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/TransducedAccessor.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/AccessorInjector.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/Bean.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/Const.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Boolean.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Byte.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Character.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Double.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Float.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Integer.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Long.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Ref.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Short.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/Injector.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Boolean.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Byte.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Character.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Double.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Float.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Integer.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Long.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Ref.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Short.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/OptimizedAccessorFactory.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/OptimizedTransducedAccessorFactory.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/Ref.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Boolean.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Byte.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Double.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Float.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Integer.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Long.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Short.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Boolean.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Byte.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Double.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Float.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Integer.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Long.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Short.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/AttributesEx.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/AttributesExImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Base64Data.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/ChildLoader.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/DefaultIDResolver.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/DefaultValueLoaderDecorator.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Discarder.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/DomLoader.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/FastInfosetConnector.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/IntArrayData.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/IntData.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Intercepter.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/InterningXmlVisitor.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/LeafPropertyLoader.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Loader.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/LocatorEx.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/LocatorExWrapper.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/MTOMDecorator.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages.properties ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Patcher.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/ProxyLoader.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Receiver.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/SAXConnector.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Scope.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/StAXConnector.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/StAXEventConnector.java + src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/StAXExConnector.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/StAXStreamConnector.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/StructureLoader.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/TagName.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/TextLoader.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/UnmarshallerImpl.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/UnmarshallingContext.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/ValuePropertyLoader.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/WildcardLoader.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/XmlVisitor.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/XsiNilLoader.java ! src/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/XsiTypeLoader.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/FoolProofResolver.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/Form.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/GroupKind.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/Messages.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/Messages.properties ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/MultiMap.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/Tree.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/XmlSchemaGenerator.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/episode/Bindings.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/episode/Klass.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/episode/SchemaBindings.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/episode/package-info.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/package-info.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ContentModelContainer.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Element.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Occurs.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Particle.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Schema.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleType.java ! src/share/classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Wildcard.java ! src/share/classes/com/sun/xml/internal/bind/v2/util/ByteArrayOutputStreamEx.java ! src/share/classes/com/sun/xml/internal/bind/v2/util/CollisionCheckStack.java ! src/share/classes/com/sun/xml/internal/bind/v2/util/DataSourceSource.java ! src/share/classes/com/sun/xml/internal/bind/v2/util/EditDistance.java ! src/share/classes/com/sun/xml/internal/bind/v2/util/FatalAdapter.java ! src/share/classes/com/sun/xml/internal/bind/v2/util/FlattenIterator.java ! src/share/classes/com/sun/xml/internal/bind/v2/util/QNameMap.java + src/share/classes/com/sun/xml/internal/bind/v2/util/StackRecorder.java ! src/share/classes/com/sun/xml/internal/bind/v2/util/TypeCast.java ! src/share/classes/com/sun/xml/internal/dtdparser/DTDParser.java ! src/share/classes/com/sun/xml/internal/dtdparser/resources/Messages.properties ! src/share/classes/com/sun/xml/internal/fastinfoset/AbstractResourceBundle.java ! src/share/classes/com/sun/xml/internal/fastinfoset/Decoder.java ! src/share/classes/com/sun/xml/internal/fastinfoset/DecoderStateTables.java ! src/share/classes/com/sun/xml/internal/fastinfoset/Encoder.java ! src/share/classes/com/sun/xml/internal/fastinfoset/algorithm/BuiltInEncodingAlgorithmFactory.java ! src/share/classes/com/sun/xml/internal/fastinfoset/algorithm/HexadecimalEncodingAlgorithm.java ! src/share/classes/com/sun/xml/internal/fastinfoset/algorithm/LongEncodingAlgorithm.java ! src/share/classes/com/sun/xml/internal/fastinfoset/algorithm/UUIDEncodingAlgorithm.java ! src/share/classes/com/sun/xml/internal/fastinfoset/dom/DOMDocumentParser.java ! src/share/classes/com/sun/xml/internal/fastinfoset/dom/DOMDocumentSerializer.java ! src/share/classes/com/sun/xml/internal/fastinfoset/org/apache/xerces/util/XMLChar.java ! src/share/classes/com/sun/xml/internal/fastinfoset/resources/ResourceBundle.properties ! src/share/classes/com/sun/xml/internal/fastinfoset/sax/AttributesHolder.java ! src/share/classes/com/sun/xml/internal/fastinfoset/sax/SAXDocumentParser.java ! src/share/classes/com/sun/xml/internal/fastinfoset/sax/SAXDocumentSerializer.java ! src/share/classes/com/sun/xml/internal/fastinfoset/sax/SAXDocumentSerializerWithPrefixMapping.java ! src/share/classes/com/sun/xml/internal/fastinfoset/stax/StAXDocumentParser.java ! src/share/classes/com/sun/xml/internal/fastinfoset/stax/StAXDocumentSerializer.java - src/share/classes/com/sun/xml/internal/fastinfoset/stax/events/StAXEventAllocator.java ! src/share/classes/com/sun/xml/internal/fastinfoset/tools/VocabularyGenerator.java ! src/share/classes/com/sun/xml/internal/fastinfoset/util/CharArrayIntMap.java ! src/share/classes/com/sun/xml/internal/fastinfoset/util/DuplicateAttributeVerifier.java ! src/share/classes/com/sun/xml/internal/fastinfoset/util/NamespaceContextImplementation.java ! src/share/classes/com/sun/xml/internal/fastinfoset/util/StringIntMap.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/SOAPExceptionImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/client/p2p/HttpSOAPConnection.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/client/p2p/HttpSOAPConnectionFactory.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/client/p2p/LocalStrings.properties ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/AttachmentPartImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/Envelope.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/EnvelopeFactory.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/FastInfosetDataContentHandler.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/GifDataContentHandler.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ImageDataContentHandler.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/JpegDataContentHandler.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/LocalStrings.properties ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageFactoryImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/MultipartDataContentHandler.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SAAJMetaFactoryImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocument.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocumentFragment.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocumentImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPFactoryImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPIOException.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPPartImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPVersionMismatchException.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/StringDataContentHandler.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/XmlDataContentHandler.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/dynamic/SOAPFactoryDynamicImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/dynamic/SOAPMessageFactoryDynamicImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/BodyElementImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/BodyImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/CDATAImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/CommentImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/DetailEntryImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/DetailImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/ElementFactory.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/ElementImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/EnvelopeImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/FaultElementImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/FaultImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/HeaderElementImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/HeaderImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/LocalStrings.properties ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/TextImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/TreeException.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/name/LocalStrings.properties ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/name/NameImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Body1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/BodyElement1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Detail1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/DetailEntry1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Envelope1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Fault1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/FaultElement1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Header1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/HeaderElement1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/LocalStrings.properties ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Message1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPFactory1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPMessageFactory1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPPart1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Body1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/BodyElement1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Detail1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/DetailEntry1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Envelope1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Fault1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/FaultElement1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Header1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/HeaderElement1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/LocalStrings.properties ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Message1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPFactory1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPMessageFactory1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPPart1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/Base64.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/ByteInputStream.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/ByteOutputStream.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/CharReader.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/CharWriter.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/FastInfosetReflection.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/FinalArrayList.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/JAXMStreamSource.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/JaxmURI.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/LocalStrings.properties ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/LogDomainConstants.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/MimeHeadersUtil.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/NamespaceContextIterator.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/ParseUtil.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/ParserPool.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/RejectDoctypeSaxFilter.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/TeeInputStream.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/XMLDeclarationParser.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/transform/EfficientStreamingTransformer.java ! src/share/classes/com/sun/xml/internal/org/jvnet/fastinfoset/FastInfosetSerializer.java ! src/share/classes/com/sun/xml/internal/org/jvnet/fastinfoset/sax/helpers/EncodingAlgorithmAttributesImpl.java + src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/Chunk.java + src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/ChunkInputStream.java + src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/Data.java + src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/DataFile.java + src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/DataHead.java + src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/FileData.java + src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/FinalArrayList.java + src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/Header.java + src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/InternetHeaders.java + src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEConfig.java + src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEEvent.java + src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEMessage.java + src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEParser.java + src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEParsingException.java + src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEPart.java + src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/MemoryData.java + src/share/classes/com/sun/xml/internal/org/jvnet/mimepull/WeakDataFile.java ! src/share/classes/com/sun/xml/internal/org/jvnet/staxex/Base64Data.java ! src/share/classes/com/sun/xml/internal/org/jvnet/staxex/Base64Encoder.java ! src/share/classes/com/sun/xml/internal/org/jvnet/staxex/ByteArrayOutputStreamEx.java ! src/share/classes/com/sun/xml/internal/org/jvnet/staxex/NamespaceContextEx.java + src/share/classes/com/sun/xml/internal/org/jvnet/staxex/StreamingDataHandler.java ! src/share/classes/com/sun/xml/internal/org/jvnet/staxex/XMLStreamReaderEx.java ! src/share/classes/com/sun/xml/internal/org/jvnet/staxex/XMLStreamWriterEx.java ! src/share/classes/com/sun/xml/internal/rngom/binary/Messages.properties ! src/share/classes/com/sun/xml/internal/rngom/dt/builtin/Messages.properties ! src/share/classes/com/sun/xml/internal/rngom/parse/Messages.properties ! src/share/classes/com/sun/xml/internal/rngom/parse/compact/Messages.properties ! src/share/classes/com/sun/xml/internal/rngom/parse/xml/Messages.properties ! src/share/classes/com/sun/xml/internal/stream/buffer/AbstractProcessor.java ! src/share/classes/com/sun/xml/internal/stream/buffer/MutableXMLStreamBuffer.java ! src/share/classes/com/sun/xml/internal/stream/buffer/sax/SAXBufferCreator.java ! src/share/classes/com/sun/xml/internal/stream/buffer/sax/SAXBufferProcessor.java ! src/share/classes/com/sun/xml/internal/stream/buffer/stax/StreamBufferCreator.java ! src/share/classes/com/sun/xml/internal/stream/buffer/stax/StreamReaderBufferCreator.java ! src/share/classes/com/sun/xml/internal/stream/buffer/stax/StreamReaderBufferProcessor.java ! src/share/classes/com/sun/xml/internal/stream/buffer/stax/StreamWriterBufferCreator.java ! src/share/classes/com/sun/xml/internal/stream/buffer/stax/StreamWriterBufferProcessor.java ! src/share/classes/com/sun/xml/internal/txw2/NamespaceSupport.java ! src/share/classes/com/sun/xml/internal/txw2/TXW.java ! src/share/classes/com/sun/xml/internal/txw2/annotation/XmlValue.java ! src/share/classes/com/sun/xml/internal/txw2/output/ResultFactory.java + src/share/classes/com/sun/xml/internal/txw2/output/TXWResult.java + src/share/classes/com/sun/xml/internal/txw2/output/TXWSerializer.java ! src/share/classes/com/sun/xml/internal/ws/addressing/EndpointReferenceUtil.java + src/share/classes/com/sun/xml/internal/ws/addressing/W3CWsaClientTube.java + src/share/classes/com/sun/xml/internal/ws/addressing/W3CWsaServerTube.java ! src/share/classes/com/sun/xml/internal/ws/addressing/WsaClientTube.java + src/share/classes/com/sun/xml/internal/ws/addressing/WsaPropertyBag.java ! src/share/classes/com/sun/xml/internal/ws/addressing/WsaServerTube.java ! src/share/classes/com/sun/xml/internal/ws/addressing/WsaTube.java ! src/share/classes/com/sun/xml/internal/ws/addressing/WsaTubeHelper.java ! src/share/classes/com/sun/xml/internal/ws/addressing/WsaTubeHelperImpl.java ! src/share/classes/com/sun/xml/internal/ws/addressing/model/ActionNotSupportedException.java + src/share/classes/com/sun/xml/internal/ws/addressing/model/InvalidAddressingHeaderException.java - src/share/classes/com/sun/xml/internal/ws/addressing/model/InvalidMapException.java - src/share/classes/com/sun/xml/internal/ws/addressing/model/MapRequiredException.java + src/share/classes/com/sun/xml/internal/ws/addressing/model/MissingAddressingHeaderException.java + src/share/classes/com/sun/xml/internal/ws/addressing/v200408/MemberSubmissionWsaClientTube.java + src/share/classes/com/sun/xml/internal/ws/addressing/v200408/MemberSubmissionWsaServerTube.java ! src/share/classes/com/sun/xml/internal/ws/addressing/v200408/WsaTubeHelperImpl.java ! src/share/classes/com/sun/xml/internal/ws/api/BindingID.java ! src/share/classes/com/sun/xml/internal/ws/api/EndpointAddress.java + src/share/classes/com/sun/xml/internal/ws/api/ResourceLoader.java ! src/share/classes/com/sun/xml/internal/ws/api/SOAPVersion.java ! src/share/classes/com/sun/xml/internal/ws/api/WSService.java ! src/share/classes/com/sun/xml/internal/ws/api/addressing/AddressingVersion.java ! src/share/classes/com/sun/xml/internal/ws/api/addressing/OutboundReferenceParameterHeader.java ! src/share/classes/com/sun/xml/internal/ws/api/addressing/WSEndpointReference.java + src/share/classes/com/sun/xml/internal/ws/api/handler/MessageHandler.java + src/share/classes/com/sun/xml/internal/ws/api/handler/MessageHandlerContext.java + src/share/classes/com/sun/xml/internal/ws/api/message/FilterMessageImpl.java ! src/share/classes/com/sun/xml/internal/ws/api/message/Message.java ! src/share/classes/com/sun/xml/internal/ws/api/message/Messages.java ! src/share/classes/com/sun/xml/internal/ws/api/message/Packet.java ! src/share/classes/com/sun/xml/internal/ws/api/model/JavaMethod.java + src/share/classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLBoundFault.java ! src/share/classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLBoundOperation.java ! src/share/classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLBoundPortType.java ! src/share/classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLExtensible.java ! src/share/classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLFault.java ! src/share/classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLInput.java ! src/share/classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLMessage.java ! src/share/classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLModel.java ! src/share/classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLOperation.java ! src/share/classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLOutput.java ! src/share/classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLPortType.java ! src/share/classes/com/sun/xml/internal/ws/api/pipe/ClientPipeAssemblerContext.java ! src/share/classes/com/sun/xml/internal/ws/api/pipe/ClientTubeAssemblerContext.java ! src/share/classes/com/sun/xml/internal/ws/api/pipe/Engine.java ! src/share/classes/com/sun/xml/internal/ws/api/pipe/Fiber.java ! src/share/classes/com/sun/xml/internal/ws/api/pipe/NextAction.java ! src/share/classes/com/sun/xml/internal/ws/api/pipe/ServerPipeAssemblerContext.java ! src/share/classes/com/sun/xml/internal/ws/api/pipe/ServerTubeAssemblerContext.java ! src/share/classes/com/sun/xml/internal/ws/api/pipe/StreamSOAPCodec.java ! src/share/classes/com/sun/xml/internal/ws/api/pipe/TransportTubeFactory.java ! src/share/classes/com/sun/xml/internal/ws/api/pipe/helper/AbstractFilterTubeImpl.java ! src/share/classes/com/sun/xml/internal/ws/api/pipe/helper/AbstractTubeImpl.java ! src/share/classes/com/sun/xml/internal/ws/api/server/BoundEndpoint.java + src/share/classes/com/sun/xml/internal/ws/api/server/EndpointComponent.java + src/share/classes/com/sun/xml/internal/ws/api/server/HttpEndpoint.java ! src/share/classes/com/sun/xml/internal/ws/api/server/InstanceResolver.java ! src/share/classes/com/sun/xml/internal/ws/api/server/PortAddressResolver.java ! src/share/classes/com/sun/xml/internal/ws/api/server/SDDocument.java ! src/share/classes/com/sun/xml/internal/ws/api/server/WSEndpoint.java ! src/share/classes/com/sun/xml/internal/ws/api/streaming/XMLStreamReaderFactory.java ! src/share/classes/com/sun/xml/internal/ws/api/streaming/XMLStreamWriterFactory.java ! src/share/classes/com/sun/xml/internal/ws/api/wsdl/parser/WSDLParserExtension.java ! src/share/classes/com/sun/xml/internal/ws/api/wsdl/parser/WSDLParserExtensionContext.java ! src/share/classes/com/sun/xml/internal/ws/binding/BindingImpl.java ! src/share/classes/com/sun/xml/internal/ws/binding/HTTPBindingImpl.java ! src/share/classes/com/sun/xml/internal/ws/binding/SOAPBindingImpl.java ! src/share/classes/com/sun/xml/internal/ws/binding/WebServiceFeatureList.java ! src/share/classes/com/sun/xml/internal/ws/client/AsyncInvoker.java ! src/share/classes/com/sun/xml/internal/ws/client/AsyncResponseImpl.java ! src/share/classes/com/sun/xml/internal/ws/client/BindingProviderProperties.java + src/share/classes/com/sun/xml/internal/ws/client/ClientContainer.java + src/share/classes/com/sun/xml/internal/ws/client/ClientSchemaValidationTube.java ! src/share/classes/com/sun/xml/internal/ws/client/HandlerConfiguration.java - src/share/classes/com/sun/xml/internal/ws/client/ResponseImpl.java ! src/share/classes/com/sun/xml/internal/ws/client/Stub.java ! src/share/classes/com/sun/xml/internal/ws/client/WSServiceDelegate.java ! src/share/classes/com/sun/xml/internal/ws/client/dispatch/DataSourceDispatch.java ! src/share/classes/com/sun/xml/internal/ws/client/dispatch/DispatchImpl.java ! src/share/classes/com/sun/xml/internal/ws/client/dispatch/RESTSourceDispatch.java ! src/share/classes/com/sun/xml/internal/ws/client/dispatch/SOAPMessageDispatch.java - src/share/classes/com/sun/xml/internal/ws/client/sei/AsyncBuilder.java ! src/share/classes/com/sun/xml/internal/ws/client/sei/AsyncMethodHandler.java ! src/share/classes/com/sun/xml/internal/ws/client/sei/BodyBuilder.java ! src/share/classes/com/sun/xml/internal/ws/client/sei/CallbackMethodHandler.java ! src/share/classes/com/sun/xml/internal/ws/client/sei/MessageFiller.java ! src/share/classes/com/sun/xml/internal/ws/client/sei/MethodHandler.java ! src/share/classes/com/sun/xml/internal/ws/client/sei/PollingMethodHandler.java ! src/share/classes/com/sun/xml/internal/ws/client/sei/ResponseBuilder.java + src/share/classes/com/sun/xml/internal/ws/client/sei/SEIMethodHandler.java ! src/share/classes/com/sun/xml/internal/ws/client/sei/SEIStub.java ! src/share/classes/com/sun/xml/internal/ws/client/sei/SyncMethodHandler.java ! src/share/classes/com/sun/xml/internal/ws/client/sei/ValueGetter.java + src/share/classes/com/sun/xml/internal/ws/client/sei/ValueGetterFactory.java ! src/share/classes/com/sun/xml/internal/ws/client/sei/ValueSetter.java + src/share/classes/com/sun/xml/internal/ws/client/sei/ValueSetterFactory.java + src/share/classes/com/sun/xml/internal/ws/client/sei/pacakge-info.java - src/share/classes/com/sun/xml/internal/ws/client/sei/package-info.java + src/share/classes/com/sun/xml/internal/ws/developer/BindingTypeFeature.java + src/share/classes/com/sun/xml/internal/ws/developer/JAXBContextFactory.java ! src/share/classes/com/sun/xml/internal/ws/developer/JAXWSProperties.java ! src/share/classes/com/sun/xml/internal/ws/developer/MemberSubmissionAddressing.java ! src/share/classes/com/sun/xml/internal/ws/developer/MemberSubmissionAddressingFeature.java ! src/share/classes/com/sun/xml/internal/ws/developer/MemberSubmissionEndpointReference.java + src/share/classes/com/sun/xml/internal/ws/developer/SchemaValidation.java + src/share/classes/com/sun/xml/internal/ws/developer/SchemaValidationFeature.java ! src/share/classes/com/sun/xml/internal/ws/developer/StatefulFeature.java + src/share/classes/com/sun/xml/internal/ws/developer/StreamingAttachment.java + src/share/classes/com/sun/xml/internal/ws/developer/StreamingAttachmentFeature.java + src/share/classes/com/sun/xml/internal/ws/developer/StreamingDataHandler.java + src/share/classes/com/sun/xml/internal/ws/developer/UsesJAXBContext.java + src/share/classes/com/sun/xml/internal/ws/developer/UsesJAXBContextFeature.java + src/share/classes/com/sun/xml/internal/ws/developer/ValidationErrorHandler.java ! src/share/classes/com/sun/xml/internal/ws/developer/WSBindingProvider.java - src/share/classes/com/sun/xml/internal/ws/encoding/AbstractXMLStreamWriterExImpl.java + src/share/classes/com/sun/xml/internal/ws/encoding/ContentType.java ! src/share/classes/com/sun/xml/internal/ws/encoding/ContentTypeImpl.java + src/share/classes/com/sun/xml/internal/ws/encoding/DataSourceStreamingDataHandler.java + src/share/classes/com/sun/xml/internal/ws/encoding/HeaderTokenizer.java + src/share/classes/com/sun/xml/internal/ws/encoding/ImageDataContentHandler.java + src/share/classes/com/sun/xml/internal/ws/encoding/MIMEPartStreamingDataHandler.java ! src/share/classes/com/sun/xml/internal/ws/encoding/MimeCodec.java ! src/share/classes/com/sun/xml/internal/ws/encoding/MimeMultipartParser.java ! src/share/classes/com/sun/xml/internal/ws/encoding/MtomCodec.java + src/share/classes/com/sun/xml/internal/ws/encoding/ParameterList.java + src/share/classes/com/sun/xml/internal/ws/encoding/RootOnlyCodec.java ! src/share/classes/com/sun/xml/internal/ws/encoding/SOAPBindingCodec.java ! src/share/classes/com/sun/xml/internal/ws/encoding/StreamSOAP11Codec.java ! src/share/classes/com/sun/xml/internal/ws/encoding/StreamSOAP12Codec.java ! src/share/classes/com/sun/xml/internal/ws/encoding/StreamSOAPCodec.java + src/share/classes/com/sun/xml/internal/ws/encoding/StringDataContentHandler.java ! src/share/classes/com/sun/xml/internal/ws/encoding/SwACodec.java ! src/share/classes/com/sun/xml/internal/ws/encoding/TagInfoset.java ! src/share/classes/com/sun/xml/internal/ws/encoding/XMLHTTPBindingCodec.java + src/share/classes/com/sun/xml/internal/ws/encoding/XmlDataContentHandler.java ! src/share/classes/com/sun/xml/internal/ws/encoding/fastinfoset/FastInfosetCodec.java ! src/share/classes/com/sun/xml/internal/ws/encoding/xml/XMLCodec.java ! src/share/classes/com/sun/xml/internal/ws/encoding/xml/XMLMessage.java ! src/share/classes/com/sun/xml/internal/ws/fault/SOAP11Fault.java ! src/share/classes/com/sun/xml/internal/ws/fault/SOAP12Fault.java ! src/share/classes/com/sun/xml/internal/ws/fault/SOAPFaultBuilder.java ! src/share/classes/com/sun/xml/internal/ws/handler/ClientLogicalHandlerTube.java + src/share/classes/com/sun/xml/internal/ws/handler/ClientMessageHandlerTube.java ! src/share/classes/com/sun/xml/internal/ws/handler/ClientSOAPHandlerTube.java ! src/share/classes/com/sun/xml/internal/ws/handler/HandlerTube.java + src/share/classes/com/sun/xml/internal/ws/handler/MessageHandlerContextImpl.java ! src/share/classes/com/sun/xml/internal/ws/handler/SOAPMessageContextImpl.java ! src/share/classes/com/sun/xml/internal/ws/handler/ServerLogicalHandlerTube.java + src/share/classes/com/sun/xml/internal/ws/handler/ServerMessageHandlerTube.java ! src/share/classes/com/sun/xml/internal/ws/handler/ServerSOAPHandlerTube.java ! src/share/classes/com/sun/xml/internal/ws/message/AttachmentUnmarshallerImpl.java ! src/share/classes/com/sun/xml/internal/ws/message/ByteArrayAttachment.java ! src/share/classes/com/sun/xml/internal/ws/message/DOMHeader.java ! src/share/classes/com/sun/xml/internal/ws/message/DataHandlerAttachment.java + src/share/classes/com/sun/xml/internal/ws/message/FaultMessage.java ! src/share/classes/com/sun/xml/internal/ws/message/JAXBAttachment.java ! src/share/classes/com/sun/xml/internal/ws/message/MimeAttachmentSet.java ! src/share/classes/com/sun/xml/internal/ws/message/jaxb/JAXBHeader.java ! src/share/classes/com/sun/xml/internal/ws/message/jaxb/JAXBMessage.java ! src/share/classes/com/sun/xml/internal/ws/message/jaxb/MarshallerBridge.java ! src/share/classes/com/sun/xml/internal/ws/message/saaj/SAAJMessage.java ! src/share/classes/com/sun/xml/internal/ws/message/stream/StreamAttachment.java ! src/share/classes/com/sun/xml/internal/ws/message/stream/StreamHeader.java ! src/share/classes/com/sun/xml/internal/ws/message/stream/StreamHeader11.java ! src/share/classes/com/sun/xml/internal/ws/message/stream/StreamHeader12.java ! src/share/classes/com/sun/xml/internal/ws/message/stream/StreamMessage.java ! src/share/classes/com/sun/xml/internal/ws/model/AbstractSEIModelImpl.java + src/share/classes/com/sun/xml/internal/ws/model/FieldSignature.java + src/share/classes/com/sun/xml/internal/ws/model/Injector.java ! src/share/classes/com/sun/xml/internal/ws/model/JavaMethodImpl.java ! src/share/classes/com/sun/xml/internal/ws/model/RuntimeModeler.java ! src/share/classes/com/sun/xml/internal/ws/model/SOAPSEIModel.java + src/share/classes/com/sun/xml/internal/ws/model/WrapperBeanGenerator.java + src/share/classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundFaultImpl.java ! src/share/classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundOperationImpl.java ! src/share/classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundPortTypeImpl.java ! src/share/classes/com/sun/xml/internal/ws/model/wsdl/WSDLFaultImpl.java ! src/share/classes/com/sun/xml/internal/ws/model/wsdl/WSDLInputImpl.java ! src/share/classes/com/sun/xml/internal/ws/model/wsdl/WSDLMessageImpl.java ! src/share/classes/com/sun/xml/internal/ws/model/wsdl/WSDLOutputImpl.java + src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/AnnotationVisitor.java + src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/AnnotationWriter.java + src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/Attribute.java + src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/ByteVector.java + src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/ClassReader.java + src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/ClassVisitor.java + src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/ClassWriter.java + src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/Edge.java + src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/FieldVisitor.java + src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/FieldWriter.java + src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/Frame.java + src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/Handler.java + src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/Item.java + src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/Label.java + src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/MethodVisitor.java + src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/MethodWriter.java + src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/Opcodes.java + src/share/classes/com/sun/xml/internal/ws/org/objectweb/asm/Type.java ! src/share/classes/com/sun/xml/internal/ws/protocol/soap/MUTube.java + src/share/classes/com/sun/xml/internal/ws/protocol/soap/MessageCreationException.java ! src/share/classes/com/sun/xml/internal/ws/resources/AddressingMessages.java ! src/share/classes/com/sun/xml/internal/ws/resources/ClientMessages.java ! src/share/classes/com/sun/xml/internal/ws/resources/ModelerMessages.java ! src/share/classes/com/sun/xml/internal/ws/resources/ProviderApiMessages.java ! src/share/classes/com/sun/xml/internal/ws/resources/ServerMessages.java ! src/share/classes/com/sun/xml/internal/ws/resources/WsservletMessages.java ! src/share/classes/com/sun/xml/internal/ws/resources/addressing.properties ! src/share/classes/com/sun/xml/internal/ws/resources/client.properties ! src/share/classes/com/sun/xml/internal/ws/resources/dispatch.properties ! src/share/classes/com/sun/xml/internal/ws/resources/encoding.properties ! src/share/classes/com/sun/xml/internal/ws/resources/handler.properties ! src/share/classes/com/sun/xml/internal/ws/resources/httpserver.properties ! src/share/classes/com/sun/xml/internal/ws/resources/modeler.properties ! src/share/classes/com/sun/xml/internal/ws/resources/providerApi.properties ! src/share/classes/com/sun/xml/internal/ws/resources/sender.properties ! src/share/classes/com/sun/xml/internal/ws/resources/server.properties ! src/share/classes/com/sun/xml/internal/ws/resources/soap.properties ! src/share/classes/com/sun/xml/internal/ws/resources/streaming.properties ! src/share/classes/com/sun/xml/internal/ws/resources/util.properties ! src/share/classes/com/sun/xml/internal/ws/resources/wsdlmodel.properties ! src/share/classes/com/sun/xml/internal/ws/resources/wsservlet.properties ! src/share/classes/com/sun/xml/internal/ws/resources/xmlmessage.properties ! src/share/classes/com/sun/xml/internal/ws/server/AbstractInstanceResolver.java + src/share/classes/com/sun/xml/internal/ws/server/DraconianValidationErrorHandler.java ! src/share/classes/com/sun/xml/internal/ws/server/EndpointFactory.java + src/share/classes/com/sun/xml/internal/ws/server/JMXAgent.java ! src/share/classes/com/sun/xml/internal/ws/server/SDDocumentImpl.java + src/share/classes/com/sun/xml/internal/ws/server/ServerSchemaValidationTube.java ! src/share/classes/com/sun/xml/internal/ws/server/StatefulInstanceResolver.java ! src/share/classes/com/sun/xml/internal/ws/server/UnsupportedMediaException.java ! src/share/classes/com/sun/xml/internal/ws/server/WSDLPatcher.java ! src/share/classes/com/sun/xml/internal/ws/server/WSEndpointImpl.java ! src/share/classes/com/sun/xml/internal/ws/server/provider/ProviderArgumentsBuilder.java ! src/share/classes/com/sun/xml/internal/ws/server/provider/XMLProviderArgumentBuilder.java ! src/share/classes/com/sun/xml/internal/ws/server/sei/EndpointArgumentsBuilder.java ! src/share/classes/com/sun/xml/internal/ws/server/sei/EndpointMethodDispatcher.java ! src/share/classes/com/sun/xml/internal/ws/server/sei/EndpointMethodDispatcherGetter.java ! src/share/classes/com/sun/xml/internal/ws/server/sei/EndpointMethodHandler.java ! src/share/classes/com/sun/xml/internal/ws/server/sei/PayloadQNameBasedDispatcher.java ! src/share/classes/com/sun/xml/internal/ws/server/sei/SEIInvokerTube.java + src/share/classes/com/sun/xml/internal/ws/server/sei/SOAPActionBasedDispatcher.java ! src/share/classes/com/sun/xml/internal/ws/spi/ProviderImpl.java ! src/share/classes/com/sun/xml/internal/ws/streaming/DOMStreamReader.java + src/share/classes/com/sun/xml/internal/ws/streaming/MtomStreamWriter.java - src/share/classes/com/sun/xml/internal/ws/streaming/XMLReader.java ! src/share/classes/com/sun/xml/internal/ws/streaming/XMLReaderException.java ! src/share/classes/com/sun/xml/internal/ws/streaming/XMLStreamReaderUtil.java ! src/share/classes/com/sun/xml/internal/ws/streaming/XMLStreamWriterUtil.java ! src/share/classes/com/sun/xml/internal/ws/transport/Headers.java ! src/share/classes/com/sun/xml/internal/ws/transport/http/DeploymentDescriptorParser.java ! src/share/classes/com/sun/xml/internal/ws/transport/http/HttpAdapter.java + src/share/classes/com/sun/xml/internal/ws/transport/http/HttpDump.java + src/share/classes/com/sun/xml/internal/ws/transport/http/HttpDumpMBean.java + src/share/classes/com/sun/xml/internal/ws/transport/http/HttpMetadataPublisher.java ! src/share/classes/com/sun/xml/internal/ws/transport/http/WSHTTPConnection.java ! src/share/classes/com/sun/xml/internal/ws/transport/http/client/HttpClientTransport.java ! src/share/classes/com/sun/xml/internal/ws/transport/http/client/HttpTransportPipe.java ! src/share/classes/com/sun/xml/internal/ws/transport/http/server/EndpointImpl.java ! src/share/classes/com/sun/xml/internal/ws/transport/http/server/HttpEndpoint.java ! src/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerConnectionImpl.java ! src/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java ! src/share/classes/com/sun/xml/internal/ws/transport/http/server/WSHttpHandler.java ! src/share/classes/com/sun/xml/internal/ws/util/ByteArrayBuffer.java ! src/share/classes/com/sun/xml/internal/ws/util/DOMUtil.java ! src/share/classes/com/sun/xml/internal/ws/util/HandlerAnnotationProcessor.java + src/share/classes/com/sun/xml/internal/ws/util/MetadataUtil.java ! src/share/classes/com/sun/xml/internal/ws/util/Pool.java ! src/share/classes/com/sun/xml/internal/ws/util/QNameMap.java ! src/share/classes/com/sun/xml/internal/ws/util/RuntimeVersion.java + src/share/classes/com/sun/xml/internal/ws/util/RuntimeVersionMBean.java + src/share/classes/com/sun/xml/internal/ws/util/pipe/AbstractSchemaValidationTube.java ! src/share/classes/com/sun/xml/internal/ws/util/pipe/DumpTube.java ! src/share/classes/com/sun/xml/internal/ws/util/pipe/StandaloneTubeAssembler.java ! src/share/classes/com/sun/xml/internal/ws/util/resources/Messages_en.properties ! src/share/classes/com/sun/xml/internal/ws/util/version.properties ! src/share/classes/com/sun/xml/internal/ws/util/xml/ContentHandlerToXMLStreamWriter.java + src/share/classes/com/sun/xml/internal/ws/util/xml/MetadataDocument.java ! src/share/classes/com/sun/xml/internal/ws/util/xml/StAXSource.java ! src/share/classes/com/sun/xml/internal/ws/util/xml/XMLStreamReaderToXMLStreamWriter.java ! src/share/classes/com/sun/xml/internal/ws/util/xml/XmlUtil.java ! src/share/classes/com/sun/xml/internal/ws/wsdl/parser/DelegatingParserExtension.java ! src/share/classes/com/sun/xml/internal/ws/wsdl/parser/FoolProofParserExtension.java ! src/share/classes/com/sun/xml/internal/ws/wsdl/parser/ParserUtil.java ! src/share/classes/com/sun/xml/internal/ws/wsdl/parser/RuntimeWSDLParser.java + src/share/classes/com/sun/xml/internal/ws/wsdl/parser/W3CAddressingMetadataWSDLParserExtension.java ! src/share/classes/com/sun/xml/internal/ws/wsdl/parser/WSDLParserExtensionContextImpl.java ! src/share/classes/com/sun/xml/internal/ws/wsdl/parser/WSDLParserExtensionFacade.java ! src/share/classes/com/sun/xml/internal/ws/wsdl/writer/UsingAddressing.java ! src/share/classes/com/sun/xml/internal/ws/wsdl/writer/W3CAddressingWSDLGeneratorExtension.java ! src/share/classes/com/sun/xml/internal/ws/wsdl/writer/WSDLGenerator.java ! src/share/classes/com/sun/xml/internal/xsom/ForeignAttributes.java ! src/share/classes/com/sun/xml/internal/xsom/SCD.java ! src/share/classes/com/sun/xml/internal/xsom/XSAnnotation.java ! src/share/classes/com/sun/xml/internal/xsom/XSAttContainer.java ! src/share/classes/com/sun/xml/internal/xsom/XSAttGroupDecl.java ! src/share/classes/com/sun/xml/internal/xsom/XSAttributeDecl.java ! src/share/classes/com/sun/xml/internal/xsom/XSAttributeUse.java ! src/share/classes/com/sun/xml/internal/xsom/XSComplexType.java ! src/share/classes/com/sun/xml/internal/xsom/XSComponent.java ! src/share/classes/com/sun/xml/internal/xsom/XSContentType.java ! src/share/classes/com/sun/xml/internal/xsom/XSDeclaration.java ! src/share/classes/com/sun/xml/internal/xsom/XSElementDecl.java ! src/share/classes/com/sun/xml/internal/xsom/XSFacet.java ! src/share/classes/com/sun/xml/internal/xsom/XSIdentityConstraint.java ! src/share/classes/com/sun/xml/internal/xsom/XSListSimpleType.java ! src/share/classes/com/sun/xml/internal/xsom/XSModelGroup.java ! src/share/classes/com/sun/xml/internal/xsom/XSModelGroupDecl.java ! src/share/classes/com/sun/xml/internal/xsom/XSNotation.java ! src/share/classes/com/sun/xml/internal/xsom/XSParticle.java ! src/share/classes/com/sun/xml/internal/xsom/XSRestrictionSimpleType.java ! src/share/classes/com/sun/xml/internal/xsom/XSSchema.java ! src/share/classes/com/sun/xml/internal/xsom/XSSchemaSet.java ! src/share/classes/com/sun/xml/internal/xsom/XSSimpleType.java ! src/share/classes/com/sun/xml/internal/xsom/XSTerm.java ! src/share/classes/com/sun/xml/internal/xsom/XSType.java ! src/share/classes/com/sun/xml/internal/xsom/XSUnionSimpleType.java ! src/share/classes/com/sun/xml/internal/xsom/XSVariety.java ! src/share/classes/com/sun/xml/internal/xsom/XSWildcard.java ! src/share/classes/com/sun/xml/internal/xsom/XSXPath.java ! src/share/classes/com/sun/xml/internal/xsom/XmlString.java ! src/share/classes/com/sun/xml/internal/xsom/impl/AnnotationImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/AttGroupDeclImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/AttributeDeclImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/AttributeUseImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/AttributesHolder.java ! src/share/classes/com/sun/xml/internal/xsom/impl/ComplexTypeImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/ComponentImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/Const.java ! src/share/classes/com/sun/xml/internal/xsom/impl/ContentTypeImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/DeclarationImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/ElementDecl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/EmptyImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/FacetImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/ForeignAttributesImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/IdentityConstraintImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/ListSimpleTypeImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/ModelGroupDeclImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/ModelGroupImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/NotationImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/ParticleImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/Ref.java ! src/share/classes/com/sun/xml/internal/xsom/impl/RestrictionSimpleTypeImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/SchemaImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/SchemaSetImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/SimpleTypeImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/UName.java ! src/share/classes/com/sun/xml/internal/xsom/impl/UnionSimpleTypeImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/Util.java ! src/share/classes/com/sun/xml/internal/xsom/impl/WildcardImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/XPathImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/package.html ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/BaseContentRef.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/DefaultAnnotationParser.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/DelayedRef.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/Messages.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/Messages.properties ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/Messages_ja.properties ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/NGCCRuntimeEx.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/ParserContext.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/Patch.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/PatcherManager.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/SAXParserFactoryAdaptor.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/SchemaDocumentImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/SubstGroupBaseTypeRef.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/Schema.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/SimpleType_List.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/SimpleType_Restriction.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/SimpleType_Union.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/annotation.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/attributeDeclBody.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/attributeGroupDecl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/attributeUses.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/complexType.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/complexType_complexContent_body.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/elementDeclBody.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/erSet.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/facet.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/group.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/identityConstraint.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/importDecl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/includeDecl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/modelGroupBody.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/notation.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/occurs.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/particle.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/qname.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/redefine.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/simpleType.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/wildcardBody.java ! src/share/classes/com/sun/xml/internal/xsom/impl/parser/state/xpath.java ! src/share/classes/com/sun/xml/internal/xsom/impl/scd/AbstractAxisImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/scd/Axis.java ! src/share/classes/com/sun/xml/internal/xsom/impl/scd/Iterators.java ! src/share/classes/com/sun/xml/internal/xsom/impl/scd/ParseException.java ! src/share/classes/com/sun/xml/internal/xsom/impl/scd/SCDImpl.java ! src/share/classes/com/sun/xml/internal/xsom/impl/scd/SCDParserConstants.java ! src/share/classes/com/sun/xml/internal/xsom/impl/scd/Step.java ! src/share/classes/com/sun/xml/internal/xsom/impl/util/DraconianErrorHandler.java ! src/share/classes/com/sun/xml/internal/xsom/impl/util/ResourceEntityResolver.java ! src/share/classes/com/sun/xml/internal/xsom/impl/util/SchemaTreeTraverser.java ! src/share/classes/com/sun/xml/internal/xsom/impl/util/SchemaWriter.java ! src/share/classes/com/sun/xml/internal/xsom/impl/util/Uri.java ! src/share/classes/com/sun/xml/internal/xsom/parser/AnnotationContext.java ! src/share/classes/com/sun/xml/internal/xsom/parser/AnnotationParser.java ! src/share/classes/com/sun/xml/internal/xsom/parser/AnnotationParserFactory.java ! src/share/classes/com/sun/xml/internal/xsom/parser/JAXPParser.java ! src/share/classes/com/sun/xml/internal/xsom/parser/SchemaDocument.java ! src/share/classes/com/sun/xml/internal/xsom/parser/XMLParser.java ! src/share/classes/com/sun/xml/internal/xsom/parser/XSOMParser.java ! src/share/classes/com/sun/xml/internal/xsom/parser/package.html ! src/share/classes/com/sun/xml/internal/xsom/util/ComponentNameFunction.java ! src/share/classes/com/sun/xml/internal/xsom/util/DeferedCollection.java ! src/share/classes/com/sun/xml/internal/xsom/util/DomAnnotationParserFactory.java ! src/share/classes/com/sun/xml/internal/xsom/util/NameGetter.java ! src/share/classes/com/sun/xml/internal/xsom/util/NameGetter.properties ! src/share/classes/com/sun/xml/internal/xsom/util/SimpleTypeSet.java ! src/share/classes/com/sun/xml/internal/xsom/util/TypeClosure.java ! src/share/classes/com/sun/xml/internal/xsom/util/TypeSet.java ! src/share/classes/com/sun/xml/internal/xsom/util/XSFinder.java ! src/share/classes/com/sun/xml/internal/xsom/util/XSFunctionFilter.java ! src/share/classes/com/sun/xml/internal/xsom/visitor/XSContentTypeFunction.java ! src/share/classes/com/sun/xml/internal/xsom/visitor/XSContentTypeVisitor.java ! src/share/classes/com/sun/xml/internal/xsom/visitor/XSFunction.java ! src/share/classes/com/sun/xml/internal/xsom/visitor/XSSimpleTypeFunction.java ! src/share/classes/com/sun/xml/internal/xsom/visitor/XSSimpleTypeVisitor.java ! src/share/classes/com/sun/xml/internal/xsom/visitor/XSTermFunction.java ! src/share/classes/com/sun/xml/internal/xsom/visitor/XSTermFunctionWithParam.java ! src/share/classes/com/sun/xml/internal/xsom/visitor/XSTermVisitor.java ! src/share/classes/com/sun/xml/internal/xsom/visitor/XSVisitor.java ! src/share/classes/com/sun/xml/internal/xsom/visitor/XSWildcardFunction.java ! src/share/classes/com/sun/xml/internal/xsom/visitor/XSWildcardVisitor.java ! src/share/classes/com/sun/xml/internal/xsom/visitor/package.html ! src/share/classes/javax/xml/bind/ContextFinder.java ! src/share/classes/javax/xml/bind/DatatypeConverter.java ! src/share/classes/javax/xml/bind/DatatypeConverterImpl.java ! src/share/classes/javax/xml/bind/DatatypeConverterInterface.java ! src/share/classes/javax/xml/bind/Element.java ! src/share/classes/javax/xml/bind/JAXBContext.java ! src/share/classes/javax/xml/bind/JAXBException.java ! src/share/classes/javax/xml/bind/MarshalException.java ! src/share/classes/javax/xml/bind/Marshaller.java ! src/share/classes/javax/xml/bind/Messages.properties ! src/share/classes/javax/xml/bind/NotIdentifiableEvent.java ! src/share/classes/javax/xml/bind/ParseConversionEvent.java ! src/share/classes/javax/xml/bind/PrintConversionEvent.java ! src/share/classes/javax/xml/bind/PropertyException.java ! src/share/classes/javax/xml/bind/TypeConstraintException.java ! src/share/classes/javax/xml/bind/UnmarshalException.java ! src/share/classes/javax/xml/bind/Unmarshaller.java ! src/share/classes/javax/xml/bind/UnmarshallerHandler.java ! src/share/classes/javax/xml/bind/ValidationEvent.java ! src/share/classes/javax/xml/bind/ValidationEventHandler.java ! src/share/classes/javax/xml/bind/ValidationEventLocator.java ! src/share/classes/javax/xml/bind/ValidationException.java ! src/share/classes/javax/xml/bind/Validator.java ! src/share/classes/javax/xml/bind/annotation/XmlAccessOrder.java ! src/share/classes/javax/xml/bind/annotation/XmlAccessType.java ! src/share/classes/javax/xml/bind/annotation/XmlAccessorOrder.java ! src/share/classes/javax/xml/bind/annotation/XmlAccessorType.java ! src/share/classes/javax/xml/bind/annotation/XmlAttribute.java ! src/share/classes/javax/xml/bind/annotation/XmlElement.java ! src/share/classes/javax/xml/bind/annotation/XmlID.java ! src/share/classes/javax/xml/bind/annotation/XmlIDREF.java ! src/share/classes/javax/xml/bind/annotation/XmlNs.java ! src/share/classes/javax/xml/bind/annotation/XmlNsForm.java ! src/share/classes/javax/xml/bind/annotation/XmlSchema.java ! src/share/classes/javax/xml/bind/annotation/XmlSeeAlso.java ! src/share/classes/javax/xml/bind/annotation/XmlTransient.java ! src/share/classes/javax/xml/bind/annotation/XmlType.java ! src/share/classes/javax/xml/bind/annotation/XmlValue.java ! src/share/classes/javax/xml/bind/annotation/adapters/XmlJavaTypeAdapter.java ! src/share/classes/javax/xml/bind/annotation/adapters/package.html ! src/share/classes/javax/xml/bind/annotation/package.html ! src/share/classes/javax/xml/bind/attachment/package.html ! src/share/classes/javax/xml/bind/helpers/AbstractMarshallerImpl.java ! src/share/classes/javax/xml/bind/helpers/AbstractUnmarshallerImpl.java ! src/share/classes/javax/xml/bind/helpers/DefaultValidationEventHandler.java ! src/share/classes/javax/xml/bind/helpers/Messages.properties ! src/share/classes/javax/xml/bind/helpers/NotIdentifiableEventImpl.java ! src/share/classes/javax/xml/bind/helpers/ParseConversionEventImpl.java ! src/share/classes/javax/xml/bind/helpers/PrintConversionEventImpl.java ! src/share/classes/javax/xml/bind/helpers/ValidationEventImpl.java ! src/share/classes/javax/xml/bind/helpers/ValidationEventLocatorImpl.java ! src/share/classes/javax/xml/bind/helpers/package.html ! src/share/classes/javax/xml/bind/package.html ! src/share/classes/javax/xml/bind/util/Messages.properties ! src/share/classes/javax/xml/bind/util/ValidationEventCollector.java ! src/share/classes/javax/xml/bind/util/package.html ! src/share/classes/javax/xml/soap/AttachmentPart.java ! src/share/classes/javax/xml/soap/Detail.java ! src/share/classes/javax/xml/soap/DetailEntry.java ! src/share/classes/javax/xml/soap/FactoryFinder.java ! src/share/classes/javax/xml/soap/MessageFactory.java ! src/share/classes/javax/xml/soap/MimeHeader.java ! src/share/classes/javax/xml/soap/MimeHeaders.java ! src/share/classes/javax/xml/soap/Name.java ! src/share/classes/javax/xml/soap/Node.java ! src/share/classes/javax/xml/soap/SAAJMetaFactory.java ! src/share/classes/javax/xml/soap/SAAJResult.java ! src/share/classes/javax/xml/soap/SOAPBody.java ! src/share/classes/javax/xml/soap/SOAPBodyElement.java ! src/share/classes/javax/xml/soap/SOAPConnection.java ! src/share/classes/javax/xml/soap/SOAPConnectionFactory.java ! src/share/classes/javax/xml/soap/SOAPConstants.java ! src/share/classes/javax/xml/soap/SOAPElement.java ! src/share/classes/javax/xml/soap/SOAPElementFactory.java ! src/share/classes/javax/xml/soap/SOAPEnvelope.java ! src/share/classes/javax/xml/soap/SOAPException.java ! src/share/classes/javax/xml/soap/SOAPFactory.java ! src/share/classes/javax/xml/soap/SOAPFault.java ! src/share/classes/javax/xml/soap/SOAPFaultElement.java ! src/share/classes/javax/xml/soap/SOAPHeader.java ! src/share/classes/javax/xml/soap/SOAPHeaderElement.java ! src/share/classes/javax/xml/soap/SOAPMessage.java ! src/share/classes/javax/xml/soap/SOAPPart.java ! src/share/classes/javax/xml/soap/Text.java ! src/share/classes/javax/xml/soap/package.html ! src/share/classes/javax/xml/ws/spi/FactoryFinder.java ! src/share/classes/javax/xml/ws/wsaddressing/W3CEndpointReference.java ! src/share/classes/org/relaxng/datatype/Datatype.java ! src/share/classes/org/relaxng/datatype/DatatypeBuilder.java ! src/share/classes/org/relaxng/datatype/DatatypeException.java ! src/share/classes/org/relaxng/datatype/DatatypeLibrary.java ! src/share/classes/org/relaxng/datatype/DatatypeLibraryFactory.java ! src/share/classes/org/relaxng/datatype/DatatypeStreamingValidator.java ! src/share/classes/org/relaxng/datatype/ValidationContext.java ! src/share/classes/org/relaxng/datatype/helpers/DatatypeLibraryLoader.java ! src/share/classes/org/relaxng/datatype/helpers/ParameterlessDatatypeBuilder.java ! src/share/classes/org/relaxng/datatype/helpers/StreamingValidatorImpl.java Changeset: 3d1c5fd9c01d Author: asaha Date: 2009-08-10 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/3d1c5fd9c01d Merge Changeset: 6608dd3dae86 Author: tbell Date: 2009-08-14 08:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/6608dd3dae86 Merge Changeset: dd3c5f3ec28d Author: tbell Date: 2009-08-18 16:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/dd3c5f3ec28d 6873200: patch.out and jaxws.patch do not belong in jaxws repository Reviewed-by: xdono, ohair - jaxws.patch - patch.out Changeset: 03314cf56a72 Author: xdono Date: 2009-08-20 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/03314cf56a72 Added tag jdk7-b70 for changeset dd3c5f3ec28d ! .hgtags From nagy.mostafa at gmail.com Fri Aug 21 10:06:15 2009 From: nagy.mostafa at gmail.com (Nagy Mostafa) Date: Fri, 21 Aug 2009 10:06:15 -0700 Subject: Build hotspot only in IcedTea after a complete build. In-Reply-To: <20090821130036.GC3295@redhat.com> References: <20090821130036.GC3295@redhat.com> Message-ID: Thanks Gary and all. Quite nice to wake up (California time here) to numerous useful replies. I am actually using the mercurial version of hotspot, so the zero patch is integrated. That's how, I assume, ./configure --enable-zero works. Another question though, is there a similar way to build a debug version ? I use the following to build IcedTea with fulldebug: ./configure; make icedtea-against-ecj SKIP_DEBUG_BUILD=false SKIP_FASTDEBUG_BUILD=true DEBUG_NAME=fulldebug; when I run "make hotspot SKIP_DEBUG_BUILD=false SKIP_FASTDEBUG_BUILD=true DEBUG_NAME=fulldebug;" afterwards, the flags are ignored and the (-DPRODUCT) flag is used instead. Anyway of doing incremental build while keeping the debug flags on ? I hope I am not asking for too much :) thanks, - nagy On Fri, Aug 21, 2009 at 6:00 AM, Gary Benson wrote: > Nagy Mostafa wrote: > > I am having trouble compiling hotspot only in IcedTea6. I build > > IcedTea with Zero as follows: > > > > ./configure --enable-zero; make; > > > > > Now, I want to modify the bytecode interpreter. What is the > > simplest way to compile hotspot only without compiling all of > > IcedTea. I tried "make hotspot", but sometimes it doesn't detect > > my code changes and even worse the build breaks occasionally. > > IcedTea has a two stage build when you configure it that way. The > first stage is a bootstrap: it builds OpenJDK using GCJ and ECJ. > The bootstrapped OpenJDK lives in "openjdk-ecj". The second stage > builds OpenJDK with the bootstrapped OpenJDK. This final OpenJDK > lives in "openjdk". > > The "make hotspot" rule in IcedTea rebuilds the HotSpot in the > bootstrap VM in "openjdk-ecj". So, to use "make hotspot" you > need to do an initial build like this: > > ./configure --enable-zero > make icedtea-against-ecj > > This will build the bootstrap VM only. Now you can edit the code > in "openjdk-ecj" and rebuild like this: > > make hotspot > > > Also, how can you do a "make clean" for hotspot only. > > The easiest way is this: > > rm -Rf openjdk-ecj/build/*/hotspot > > ...and then do "make hotspot" again. > > Cheers, > Gary > > -- > http://gbenson.net/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090821/ffa88034/attachment.html From gnu_andrew at member.fsf.org Fri Aug 21 10:42:46 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 21 Aug 2009 18:42:46 +0100 Subject: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <19085.60704.711648.209254@sun.com> References: <17c6771e0908180642k67a2cc68refa4232b1cf1770c@mail.gmail.com> <4A8AB98E.4030605@sun.com> <19082.59099.744855.256045@sun.com> <17c6771e0908191230y3aabadfcq70ab30782538036@mail.gmail.com> <19084.34943.379450.167908@sun.com> <17c6771e0908200522u78b5a222j24661df5b76783c2@mail.gmail.com> <19085.60704.711648.209254@sun.com> Message-ID: <17c6771e0908211042s4803c978wf63adbf2a41efdde@mail.gmail.com> 2009/8/21 John Coomes : > Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: >> 2009/8/20 John Coomes : >> > Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: >> >> 2009/8/18 John Coomes : >> >> > Daniel D. Daugherty (Daniel.Daugherty at Sun.COM) wrote: >> >> >> Andrew, >> >> >> >> >> >> A couple of comments: >> >> >> >> >> >> - if you specify '-source 6', then '-target 6' is implied >> >> >> ???? so you don't really need both >> >> >> - I would prefer to see a top-level macro that defines the >> >> >> ???? bootstrap tools javac option and then have the various >> >> >> ???? Makefiles use that macro. Something in make/defs.make: >> >> >> >> >> >> ???? ???? ???? BOOTSTRAP_TOOLS.JAVAC.FLAGS="-source 6" >> >> >> >> >> >> ???? or something like that. >> >> > >> >> > +1 on the top-level macro. ????In HotSpot, I would call it JAVAC_FLAGS or >> >> > COMPILE_JAVAC_FLAGS, and add it to the COMPILE.JAVAC macro (spelled >> >> > COMPILE_JAVAC on windows) so that every compilation uses it. ????Then >> >> > fewer places need to be touched. >> >> > >> >> > Also, please leave the default value empty. ????On platforms that need >> >> > it, it can be set on the command line or in the environment. >> >> > Specifying a value requires periodic maintenance. ????Yes, the period is >> >> > long, but it's a pain when the build breaks because of some stale >> >> > value in a makefile. >> >> > >> >> >> >> Ok, here's the changeset I was working on before I received your mail >> >> and which I've since successfully tested with hotspot-rt: >> >> >> >> http://cr.openjdk.java.net/~andrew/ecj/03/webrev.02/ >> > >> > I submitted your patch to the build queue; it will take several hours, >> > there's one job ahead of it. >> > >> > After looking at it again, the include of make/defs.make in >> > make/windows/makefiles/rules.make will most likely fail to build. ??The >> > latter is a windows nmake file, so the gnu-specific syntax will be >> > rejected and there are other unixisms in there (e.g., shell until). >> > >> >> I had a feeling Windows would be the one to bite... >> >> > Instead, try updating MAKE_ARGS in make/defs.make, I believe those are >> > exported to sub-makes. ??Since it has to be portable, I believe you'll >> > have to use '_' instead of '.' in the macro name. >> > >> >> Ok, in http://cr.openjdk.java.net/~andrew/ecj/03/webrev.03/ I've >> reverted the addtion >> of defs.make in favour of using MAKE_ARGS and renamed the variables >> using underscores (which I prefer anyway). >> >> Where I am confused is how the MAKE_ARGS changes get through to the >> Windows build if it doesn't parse defs.make. >> makefiles/windows/defs.make seems to imply that the top-level one will >> be read. >> >> >> This defines the variables in the top-level defs.make file. ??The >> >> versions are stored separately, in the same way as they are in the >> >> JDK: >> >> >> >> http://hg.openjdk.java.net/jdk7/build/jdk/rev/80368890a2a0 >> >> >> >> SA is still done separately as it's currently 1.4. ??The default for others is 6. >> >> The rest of the patch ensures this makefile is picked up and its >> >> values used for compilation across all three platforms. >> >> >> >> This is added to the invocations rather than COMPILE.JAVAC. ??As you >> >> imply in your mail, this value varies between platforms and even >> >> within the same platform. ??Just the GNU/Linux port itself defines it >> >> in about four ways. >> > >> > Take a look, it's simply selecting which path to use. ??After the def >> > of COMPILE.JAVAC, a simple >> > >> > ?? ?? ?? ??COMPILE.JAVAC += $(BOOTSTRAP_JAVAC.FLAGS) >> > >> > should do it. ??Windows will have to be different, though. >> > >> >> Yes, the other problem is this forces the same options to SA as well >> which uses COMPILE.JAVAC. ?To keep the current status quo (at least >> for now), these need a different set of flags. >> >> >> I don't agree with leaving the value blank. ??The issue is relevant on >> >> all platforms, as leaving it blank makes the build open to whatever >> >> the default value is of the bootstrap JDK. ??For instance, this just >> >> changed to 7 with OpenJDK, so current builds will produce 1.7 bytecode >> >> while builds using an older OpenJDK7 or OpenJDK6 will use 6. ??From >> >> personal experience, it's much harder to debug a problem when you have >> >> to take into account the boot JDK being used, which may vary, than >> >> when you have an explicit value. >> >> >> >> It seems much clearer to specify it explicitly in one common place for >> >> all platforms, which can also be easily overridden from the command >> >> line if needed. ??This is the same as is now done for JDK, langtools, >> >> jaxp and jaxws and will shortly be the case in corba. >> > >> > The jdk, langtools, etc., repos are much more sensitive to this >> > setting than hotspot, which uses it only for makedeps and jvmti header >> > generation. ??It's non-critical, and I think it's safe to assume that >> > the default class file version produced by a boot jdk can also be run >> > by that same boot jdk. >> > >> > So far, ecj is the only known boot env needing this set explicitly. >> >> That kind of assumption is the thing that tends to come back and bite >> you. ?It's especially true because: >> >> ? * The boot JDK is something determined on a per-user basis, so just >> updating the system JDK may cause a failure that's hard to diagnose. >> ? * Failures in HotSpot javac builds are already hard to diagnose >> because it doesn't print out the javac invocation. ?It took me longer >> to track this down than the equivalents in JDK and CORBA, and I've >> been working with the OpenJDK build for about two years now. > > FWIW, you can get hotspot builds to be verbose with > > ? ? ? ?gmake ... QUIETLY= > > (i.e., set QUIETLY to an empty value) and it should show all command > invocations. Ah thanks for that. Will probably make that the default for me by adding it to my build script. There's a thin line between being too verbose (e.g. the mass warnings ecj spits out which obscure real problems) and being too quiet that it becomes hard to debug an issue. I think some of the uses of QUIETLY go a little too far towards the latter. > >> Yes, ecj is the only one that fails. ?But we now have at least two >> JDKs that will produce different results: OpenJDK6 (which defaults to >> 6) and OpenJDK7 (which defaults to 7). ?There are even more if you >> include the proprietary JDKs and JDK 1.5 which I assume can also build >> OpenJDK at a push. >> ... > > Different, but still correct. ?I'm resisting a default because it will > get stale (they always do, SA is a good example). ?And it's worked for > *years* (6? 8?) without a problem. ?But I won't reject the rest of it > because there's a default. ?Sigh. > Correct if you regard having a mix of classfile versions in the finishing JDK as correct. We do already get that with SA but that's a bug that needs to be fixed in the long run. I understand where you're coming from with regards to stale defaults and, in general, I agree with you. But not specifying these doesn't remove the default, it just obscures it because the default is now implicit and will vary dependent on boot environment. You can see it working for 6-8 years as both a positive and a negative; the variance in boot JDK has clearly been quite small in this time period as no-one has tried building with a compiler that has a default below the minimum required to compile the code. This is reinforced by the fact that, while the classfile version is on its 8th revision, I can think of only three source breakages: inner classes (1.1), assert (1.4) and generics/enums/annotations (1.5). And I would imagine the use of assert is fairly low. Aside from these general issues, from my perspective, we're going to have this set somewhere for IcedTea builds as it's causing build breakage. I'd prefer that OpenJDK and IcedTea builds had as much in common in possible. Having it in OpenJDK itself also avoids this coming up when another user runs across it; this will undoubtedly happen as the next 6-8 years with OpenJDK as a Free Software project are going to see a lot more variance in the people building the code than in the last 6-8 years where it was proprietary and thus limited to certain companies and academia. >> Finally, switching SA to use the defaults would be a visible change. > > Dan mentioned the SA values in passing; my impression was he thought > they should be updated or removed. ?I don't work with the SA, but I > suspect the settings are relics from using a boot jdk that had 1.3 as > a default when SA needed 1.4 features. ?Anyone recall? > > Even if for some odd reason SA source should be limited to using 1.4 > features, if you update JAVAC_COMPILE to include JAVAC_FLAGS (or > whatever it is), and the SA makefile also includes -source/-target > options on the command-line, the latter will override the ones in > JAVAC_FLAGS (the SA command line may need to include both -source and > -target). ?At least try it, I think it'll be a simpler change. > > I submitted your latest patch to the build queue for test builds; > hopefully it will send you mail when it's finished (but I've never > tried including a non-Sun email address before). > Thanks. I haven't received anything yet, though it could have been lost in the deluge of email from the build promotion. Any idea what the subject of such a mail would be? > -John > >> >> >> Which repo are you targeting for this change? >> >> > >> >> > I'd suggest hotspot-rt. >> >> > >> >> > Note that all hotspot changes have to be built on all platforms before >> >> > being pushed; we have an automated system called jprt that does builds >> >> > and tests on the various platforms. ????Unfortunately, it isn't available >> >> > externally. ????Sync up with the latest hotspot-rt and then contact me >> >> > privately with a patch or your repo location and I'll run it through. >> >> > >> >> >> >> The patch from this webrev is against hotspot-rt so can be tested. >> >> >> >> >> Yes, I see that SA uses '-source 1.4' in each platform makefile. >> >> >> That should be fixed also, but that's another issue... >> >> > >> >> > Sigh. ????Stale values in makefiles ... >> >> > >> >> >> >> Also fixed now by this patch. ??At least 1.4 is in one common makefile >> >> rather than occurring six times over three makefiles... :) >> >> >> >> > -John >> >> > >> >> >> > Andrew John Hughes wrote: >> >> >> > The makeDeps and jvmti bootstrap tools are built without explicit >> >> >> > source and target options. >> >> >> > >> >> >> > This webrev: >> >> >> > >> >> >> > http://cr.openjdk.java.net/~andrew/ecj/03/webrev.01/ >> >> >> > >> >> >> > sets them to 6 explicitly. The change has to be replicated three >> >> >> > times, because for some reason, the javac invocations are in >> >> >> > platform-specific makefiles. ????I've tested the change successfully on >> >> >> > GNU/Linux, where it allows ecj to be used as javac. ????ecj defaults to >> >> >> > <1.5 and thus otherwise fails to build. ????I've assumed that the same >> >> >> > changes are applicable for Solaris and Windows, and that the source >> >> >> > and target options don't have to be written in Latin or something to >> >> >> > work on these platforms. >> >> >> > >> >> >> > Is this ok to push? >> >> >> > >> >> >> > 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 >> > >> > >> >> >> >> -- >> 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 > > 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 gnu_andrew at member.fsf.org Fri Aug 21 10:46:35 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 21 Aug 2009 18:46:35 +0100 Subject: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <4A8E0EA4.1050908@sun.com> References: <17c6771e0908180642k67a2cc68refa4232b1cf1770c@mail.gmail.com> <4A8AB98E.4030605@sun.com> <19082.59099.744855.256045@sun.com> <17c6771e0908191230y3aabadfcq70ab30782538036@mail.gmail.com> <19084.34943.379450.167908@sun.com> <17c6771e0908200522u78b5a222j24661df5b76783c2@mail.gmail.com> <19085.60704.711648.209254@sun.com> <4A8E0EA4.1050908@sun.com> Message-ID: <17c6771e0908211046l4bf5e610gb55ee374b0d383a3@mail.gmail.com> 2009/8/21 David Holmes - Sun Microsystems : > John Coomes said the following on 08/21/09 10:41: >> >> Dan mentioned the SA values in passing; my impression was he thought >> they should be updated or removed. ?I don't work with the SA, but I >> suspect the settings are relics from using a boot jdk that had 1.3 as >> a default when SA needed 1.4 features. ?Anyone recall? > > Actually it's the opposite problem: it was to stop it from being compiled by > JDK5 as target 1.5 code, to avoid all the generics-related warnings that you > otherwise encounter with non-generified code. See CRs 5038934 and 5053732. > Those bug IDs are very sparse on information, so I don't know the exact failure. However, there are generics warnings still on just about every piece of code in the JDK, together with some javadoc ones too. Using ecj (a very noisy compiler) produces over 16k warnings on just the subset of the JDK pre-compiled by IcedTea for bootstrap purposes. > So I suggest that this needs to be left as -source 1.4 > I have in this webrev. I'll look into these warnings further and see if they can be fixed. > Cheers, > David > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Fri Aug 21 10:53:12 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 21 Aug 2009 18:53:12 +0100 Subject: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <17c6771e0908211042s4803c978wf63adbf2a41efdde@mail.gmail.com> References: <17c6771e0908180642k67a2cc68refa4232b1cf1770c@mail.gmail.com> <4A8AB98E.4030605@sun.com> <19082.59099.744855.256045@sun.com> <17c6771e0908191230y3aabadfcq70ab30782538036@mail.gmail.com> <19084.34943.379450.167908@sun.com> <17c6771e0908200522u78b5a222j24661df5b76783c2@mail.gmail.com> <19085.60704.711648.209254@sun.com> <17c6771e0908211042s4803c978wf63adbf2a41efdde@mail.gmail.com> Message-ID: <17c6771e0908211053h78675e07j3ed20fd366f2f46e@mail.gmail.com> 2009/8/21 Andrew John Hughes : > 2009/8/21 John Coomes : >> Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: >>> 2009/8/20 John Coomes : >>> > Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: >>> >> 2009/8/18 John Coomes : >>> >> > Daniel D. Daugherty (Daniel.Daugherty at Sun.COM) wrote: >>> >> >> Andrew, >>> >> >> >>> >> >> A couple of comments: >>> >> >> >>> >> >> - if you specify '-source 6', then '-target 6' is implied >>> >> >> ???? so you don't really need both >>> >> >> - I would prefer to see a top-level macro that defines the >>> >> >> ???? bootstrap tools javac option and then have the various >>> >> >> ???? Makefiles use that macro. Something in make/defs.make: >>> >> >> >>> >> >> ???? ???? ???? BOOTSTRAP_TOOLS.JAVAC.FLAGS="-source 6" >>> >> >> >>> >> >> ???? or something like that. >>> >> > >>> >> > +1 on the top-level macro. ????In HotSpot, I would call it JAVAC_FLAGS or >>> >> > COMPILE_JAVAC_FLAGS, and add it to the COMPILE.JAVAC macro (spelled >>> >> > COMPILE_JAVAC on windows) so that every compilation uses it. ????Then >>> >> > fewer places need to be touched. >>> >> > >>> >> > Also, please leave the default value empty. ????On platforms that need >>> >> > it, it can be set on the command line or in the environment. >>> >> > Specifying a value requires periodic maintenance. ????Yes, the period is >>> >> > long, but it's a pain when the build breaks because of some stale >>> >> > value in a makefile. >>> >> > >>> >> >>> >> Ok, here's the changeset I was working on before I received your mail >>> >> and which I've since successfully tested with hotspot-rt: >>> >> >>> >> http://cr.openjdk.java.net/~andrew/ecj/03/webrev.02/ >>> > >>> > I submitted your patch to the build queue; it will take several hours, >>> > there's one job ahead of it. >>> > >>> > After looking at it again, the include of make/defs.make in >>> > make/windows/makefiles/rules.make will most likely fail to build. ??The >>> > latter is a windows nmake file, so the gnu-specific syntax will be >>> > rejected and there are other unixisms in there (e.g., shell until). >>> > >>> >>> I had a feeling Windows would be the one to bite... >>> >>> > Instead, try updating MAKE_ARGS in make/defs.make, I believe those are >>> > exported to sub-makes. ??Since it has to be portable, I believe you'll >>> > have to use '_' instead of '.' in the macro name. >>> > >>> >>> Ok, in http://cr.openjdk.java.net/~andrew/ecj/03/webrev.03/ I've >>> reverted the addtion >>> of defs.make in favour of using MAKE_ARGS and renamed the variables >>> using underscores (which I prefer anyway). >>> >>> Where I am confused is how the MAKE_ARGS changes get through to the >>> Windows build if it doesn't parse defs.make. >>> makefiles/windows/defs.make seems to imply that the top-level one will >>> be read. >>> >>> >> This defines the variables in the top-level defs.make file. ??The >>> >> versions are stored separately, in the same way as they are in the >>> >> JDK: >>> >> >>> >> http://hg.openjdk.java.net/jdk7/build/jdk/rev/80368890a2a0 >>> >> >>> >> SA is still done separately as it's currently 1.4. ??The default for others is 6. >>> >> The rest of the patch ensures this makefile is picked up and its >>> >> values used for compilation across all three platforms. >>> >> >>> >> This is added to the invocations rather than COMPILE.JAVAC. ??As you >>> >> imply in your mail, this value varies between platforms and even >>> >> within the same platform. ??Just the GNU/Linux port itself defines it >>> >> in about four ways. >>> > >>> > Take a look, it's simply selecting which path to use. ??After the def >>> > of COMPILE.JAVAC, a simple >>> > >>> > ?? ?? ?? ??COMPILE.JAVAC += $(BOOTSTRAP_JAVAC.FLAGS) >>> > >>> > should do it. ??Windows will have to be different, though. >>> > >>> >>> Yes, the other problem is this forces the same options to SA as well >>> which uses COMPILE.JAVAC. ?To keep the current status quo (at least >>> for now), these need a different set of flags. >>> >>> >> I don't agree with leaving the value blank. ??The issue is relevant on >>> >> all platforms, as leaving it blank makes the build open to whatever >>> >> the default value is of the bootstrap JDK. ??For instance, this just >>> >> changed to 7 with OpenJDK, so current builds will produce 1.7 bytecode >>> >> while builds using an older OpenJDK7 or OpenJDK6 will use 6. ??From >>> >> personal experience, it's much harder to debug a problem when you have >>> >> to take into account the boot JDK being used, which may vary, than >>> >> when you have an explicit value. >>> >> >>> >> It seems much clearer to specify it explicitly in one common place for >>> >> all platforms, which can also be easily overridden from the command >>> >> line if needed. ??This is the same as is now done for JDK, langtools, >>> >> jaxp and jaxws and will shortly be the case in corba. >>> > >>> > The jdk, langtools, etc., repos are much more sensitive to this >>> > setting than hotspot, which uses it only for makedeps and jvmti header >>> > generation. ??It's non-critical, and I think it's safe to assume that >>> > the default class file version produced by a boot jdk can also be run >>> > by that same boot jdk. >>> > >>> > So far, ecj is the only known boot env needing this set explicitly. >>> >>> That kind of assumption is the thing that tends to come back and bite >>> you. ?It's especially true because: >>> >>> ? * The boot JDK is something determined on a per-user basis, so just >>> updating the system JDK may cause a failure that's hard to diagnose. >>> ? * Failures in HotSpot javac builds are already hard to diagnose >>> because it doesn't print out the javac invocation. ?It took me longer >>> to track this down than the equivalents in JDK and CORBA, and I've >>> been working with the OpenJDK build for about two years now. >> >> FWIW, you can get hotspot builds to be verbose with >> >> ? ? ? ?gmake ... QUIETLY= >> >> (i.e., set QUIETLY to an empty value) and it should show all command >> invocations. > > Ah thanks for that. ?Will probably make that the default for me by > adding it to my build script. ?There's a thin line between being too > verbose (e.g. the mass warnings ecj spits out which obscure real > problems) and being too quiet that it becomes hard to debug an issue. > I think some of the uses of QUIETLY go a little too far towards the > latter. > >> >>> Yes, ecj is the only one that fails. ?But we now have at least two >>> JDKs that will produce different results: OpenJDK6 (which defaults to >>> 6) and OpenJDK7 (which defaults to 7). ?There are even more if you >>> include the proprietary JDKs and JDK 1.5 which I assume can also build >>> OpenJDK at a push. >>> ... >> >> Different, but still correct. ?I'm resisting a default because it will >> get stale (they always do, SA is a good example). ?And it's worked for >> *years* (6? 8?) without a problem. ?But I won't reject the rest of it >> because there's a default. ?Sigh. >> > > Correct if you regard having a mix of classfile versions in the > finishing JDK as correct. ?We do already get that with SA but that's a > bug that needs to be fixed in the long run. > > I understand where you're coming from with regards to stale defaults > and, in general, I agree with you. ?But not specifying these doesn't > remove the default, it just obscures it because the default is now > implicit and will vary dependent on boot environment. > > You can see it working for 6-8 years as both a positive and a > negative; the variance in boot JDK has clearly been quite small in > this time period as no-one has tried building with a compiler that has > a default below the minimum required to compile the code. ?This is > reinforced by the fact that, while the classfile version is on its 8th > revision, I can think of only three source breakages: inner classes > (1.1), assert (1.4) and generics/enums/annotations (1.5). ?And I would > imagine the use of assert is fairly low. > > Aside from these general issues, from my perspective, we're going to > have this set somewhere for IcedTea builds as it's causing build > breakage. ?I'd prefer that OpenJDK and IcedTea builds had as much in > common in possible. ?Having it in OpenJDK itself also avoids this > coming up when another user runs across it; this will undoubtedly > happen as the next 6-8 years with OpenJDK as a Free Software project > are going to see a lot more variance in the people building the code > than in the last 6-8 years where it was proprietary and thus limited > to certain companies and academia. > >>> Finally, switching SA to use the defaults would be a visible change. >> >> Dan mentioned the SA values in passing; my impression was he thought >> they should be updated or removed. ?I don't work with the SA, but I >> suspect the settings are relics from using a boot jdk that had 1.3 as >> a default when SA needed 1.4 features. ?Anyone recall? >> >> Even if for some odd reason SA source should be limited to using 1.4 >> features, if you update JAVAC_COMPILE to include JAVAC_FLAGS (or >> whatever it is), and the SA makefile also includes -source/-target >> options on the command-line, the latter will override the ones in >> JAVAC_FLAGS (the SA command line may need to include both -source and >> -target). ?At least try it, I think it'll be a simpler change. >> >> I submitted your latest patch to the build queue for test builds; >> hopefully it will send you mail when it's finished (but I've never >> tried including a non-Sun email address before). >> > > Thanks. ?I haven't received anything yet, though it could have been > lost in the deluge of email from the build promotion. ?Any idea what > the subject of such a mail would be? > Scrub that. I found it: JPRT: [hotspotwest] job notification - success with job 2009-08-21-000202.jcoomes.rt-javac-opts So it worked :) >> -John >> >>> >> >> Which repo are you targeting for this change? >>> >> > >>> >> > I'd suggest hotspot-rt. >>> >> > >>> >> > Note that all hotspot changes have to be built on all platforms before >>> >> > being pushed; we have an automated system called jprt that does builds >>> >> > and tests on the various platforms. ????Unfortunately, it isn't available >>> >> > externally. ????Sync up with the latest hotspot-rt and then contact me >>> >> > privately with a patch or your repo location and I'll run it through. >>> >> > >>> >> >>> >> The patch from this webrev is against hotspot-rt so can be tested. >>> >> >>> >> >> Yes, I see that SA uses '-source 1.4' in each platform makefile. >>> >> >> That should be fixed also, but that's another issue... >>> >> > >>> >> > Sigh. ????Stale values in makefiles ... >>> >> > >>> >> >>> >> Also fixed now by this patch. ??At least 1.4 is in one common makefile >>> >> rather than occurring six times over three makefiles... :) >>> >> >>> >> > -John >>> >> > >>> >> >> > Andrew John Hughes wrote: >>> >> >> > The makeDeps and jvmti bootstrap tools are built without explicit >>> >> >> > source and target options. >>> >> >> > >>> >> >> > This webrev: >>> >> >> > >>> >> >> > http://cr.openjdk.java.net/~andrew/ecj/03/webrev.01/ >>> >> >> > >>> >> >> > sets them to 6 explicitly. The change has to be replicated three >>> >> >> > times, because for some reason, the javac invocations are in >>> >> >> > platform-specific makefiles. ????I've tested the change successfully on >>> >> >> > GNU/Linux, where it allows ecj to be used as javac. ????ecj defaults to >>> >> >> > <1.5 and thus otherwise fails to build. ????I've assumed that the same >>> >> >> > changes are applicable for Solaris and Windows, and that the source >>> >> >> > and target options don't have to be written in Latin or something to >>> >> >> > work on these platforms. >>> >> >> > >>> >> >> > Is this ok to push? >>> >> >> > >>> >> >> > 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 >>> > >>> > >>> >>> >>> >>> -- >>> 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 >> >> > > > 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 > -- 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 gustav.trede at gmail.com Fri Aug 21 13:44:51 2009 From: gustav.trede at gmail.com (gustav trede) Date: Fri, 21 Aug 2009 22:44:51 +0200 Subject: FDLIBM 5.3 ported In-Reply-To: <311e0eaf0908201147g78f037abm6076749055cde576@mail.gmail.com> References: <311e0eaf0908201147g78f037abm6076749055cde576@mail.gmail.com> Message-ID: <311e0eaf0908211344w7334860gbdd9c5ea680f075a@mail.gmail.com> 2009/8/20 gustav trede > Hello, > > All methods but sqrt is ported. > > I would be happy to get help with further conformance testing and feedback > in general. > > The tests for Math and StrictMath classes in openjdk passes along with my > own similar tests, comparing to the current strictmath for identical > results. > > > The performance improvements seems to be rather massive for quite a few > operations. > > > I have signed a JCA a couple of years ago. > -- > regards > gustav trede > Apologies for the strange attachment, it seems the mailing lists server converted the java file to an .obj file. I have now attached a ziped java file instead. -- regards gustav trede -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090821/8deb2b2f/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: StrictMath.java.zip Type: application/zip Size: 34800 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090821/8deb2b2f/attachment-0001.zip From martinrb at google.com Fri Aug 21 13:53:34 2009 From: martinrb at google.com (Martin Buchholz) Date: Fri, 21 Aug 2009 13:53:34 -0700 Subject: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <17c6771e0908211042s4803c978wf63adbf2a41efdde@mail.gmail.com> References: <17c6771e0908180642k67a2cc68refa4232b1cf1770c@mail.gmail.com> <4A8AB98E.4030605@sun.com> <19082.59099.744855.256045@sun.com> <17c6771e0908191230y3aabadfcq70ab30782538036@mail.gmail.com> <19084.34943.379450.167908@sun.com> <17c6771e0908200522u78b5a222j24661df5b76783c2@mail.gmail.com> <19085.60704.711648.209254@sun.com> <17c6771e0908211042s4803c978wf63adbf2a41efdde@mail.gmail.com> Message-ID: <1ccfd1c10908211353g311adf28h72a86e6d4090fdae@mail.gmail.com> On Fri, Aug 21, 2009 at 10:42, Andrew John Hughes wrote: > > You can see it working for 6-8 years as both a positive and a > negative; the variance in boot JDK has clearly been quite small in > this time period as no-one has tried building with a compiler that has > a default below the minimum required to compile the code. If you are wearing your "extreme compatibility" hat, then you might think there is nothing wrong with ancient source files, and -source 1.0 is perfectly fine, and a java compiler that does not implement -source 1.0 is broken, in the same way that a java platform that doesn't implement all the library classes is broken. One might even think that leaving a few -source 1.0 in the jdk sources is a kind of sanity test, that checks that the bootstrap jdk is a "real" jdk. Incrementing -target to more recent levels has more justification, but there again leaving a few -target 1.0 .class files in rt.jar is a good way to ensure that jdk tools don't forget about compatibility. Compatibility is very annoying, but highly valued by real users. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090821/19f84ac8/attachment.html From schlosna at gmail.com Fri Aug 21 19:23:24 2009 From: schlosna at gmail.com (David Schlosnagle) Date: Fri, 21 Aug 2009 22:23:24 -0400 Subject: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <17c6771e0908200522u78b5a222j24661df5b76783c2@mail.gmail.com> References: <17c6771e0908180642k67a2cc68refa4232b1cf1770c@mail.gmail.com> <4A8AB98E.4030605@sun.com> <19082.59099.744855.256045@sun.com> <17c6771e0908191230y3aabadfcq70ab30782538036@mail.gmail.com> <19084.34943.379450.167908@sun.com> <17c6771e0908200522u78b5a222j24661df5b76783c2@mail.gmail.com> Message-ID: <9146341c0908211923l44c1a044p765a490468c67a1b@mail.gmail.com> Andrew, I'm just a beginner here trying to get a better understanding of the JDK by scanning code reviews and I have a comment on the changes in < http://cr.openjdk.java.net/~andrew/ecj/03/webrev.03/>. In all the sa.make files (Linux, Solaris & Windows), should the -g flag be removed from the two modified lines since it's included in the SA_JAVAC_FLAGS via JAVAC_FLAGS in defs.make? I'd assume that the duplicate -g won't cause failures, but it seems to force all debug info to always be included even if one tried to override the compile flags to disable or alter the debug information included. Thanks, David Schlosnagle On Thu, Aug 20, 2009 at 8:22 AM, Andrew John Hughes < gnu_andrew at member.fsf.org> wrote: > 2009/8/20 John Coomes : > > Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: > >> 2009/8/18 John Coomes : > >> > Daniel D. Daugherty (Daniel.Daugherty at Sun.COM) wrote: > >> >> Andrew, > >> >> > >> >> A couple of comments: > >> >> > >> >> - if you specify '-source 6', then '-target 6' is implied > >> >> ? so you don't really need both > >> >> - I would prefer to see a top-level macro that defines the > >> >> ? bootstrap tools javac option and then have the various > >> >> ? Makefiles use that macro. Something in make/defs.make: > >> >> > >> >> ? ? ? BOOTSTRAP_TOOLS.JAVAC.FLAGS="-source 6" > >> >> > >> >> ? or something like that. > >> > > >> > +1 on the top-level macro. ? In HotSpot, I would call it JAVAC_FLAGS > or > >> > COMPILE_JAVAC_FLAGS, and add it to the COMPILE.JAVAC macro (spelled > >> > COMPILE_JAVAC on windows) so that every compilation uses it. ? Then > >> > fewer places need to be touched. > >> > > >> > Also, please leave the default value empty. ? On platforms that need > >> > it, it can be set on the command line or in the environment. > >> > Specifying a value requires periodic maintenance. ? Yes, the period is > >> > long, but it's a pain when the build breaks because of some stale > >> > value in a makefile. > >> > > >> > >> Ok, here's the changeset I was working on before I received your mail > >> and which I've since successfully tested with hotspot-rt: > >> > >> http://cr.openjdk.java.net/~andrew/ecj/03/webrev.02/ > > > > I submitted your patch to the build queue; it will take several hours, > > there's one job ahead of it. > > > > After looking at it again, the include of make/defs.make in > > make/windows/makefiles/rules.make will most likely fail to build. The > > latter is a windows nmake file, so the gnu-specific syntax will be > > rejected and there are other unixisms in there (e.g., shell until). > > > > I had a feeling Windows would be the one to bite... > > > Instead, try updating MAKE_ARGS in make/defs.make, I believe those are > > exported to sub-makes. Since it has to be portable, I believe you'll > > have to use '_' instead of '.' in the macro name. > > > > Ok, in http://cr.openjdk.java.net/~andrew/ecj/03/webrev.03/I've > reverted the addtion > of defs.make in favour of using MAKE_ARGS and renamed the variables > using underscores (which I prefer anyway). > > Where I am confused is how the MAKE_ARGS changes get through to the > Windows build if it doesn't parse defs.make. > makefiles/windows/defs.make seems to imply that the top-level one will > be read. > > >> This defines the variables in the top-level defs.make file. The > >> versions are stored separately, in the same way as they are in the > >> JDK: > >> > >> http://hg.openjdk.java.net/jdk7/build/jdk/rev/80368890a2a0 > >> > >> SA is still done separately as it's currently 1.4. The default for > others is 6. > >> The rest of the patch ensures this makefile is picked up and its > >> values used for compilation across all three platforms. > >> > >> This is added to the invocations rather than COMPILE.JAVAC. As you > >> imply in your mail, this value varies between platforms and even > >> within the same platform. Just the GNU/Linux port itself defines it > >> in about four ways. > > > > Take a look, it's simply selecting which path to use. After the def > > of COMPILE.JAVAC, a simple > > > > COMPILE.JAVAC += $(BOOTSTRAP_JAVAC.FLAGS) > > > > should do it. Windows will have to be different, though. > > > > Yes, the other problem is this forces the same options to SA as well > which uses COMPILE.JAVAC. To keep the current status quo (at least > for now), these need a different set of flags. > > >> I don't agree with leaving the value blank. The issue is relevant on > >> all platforms, as leaving it blank makes the build open to whatever > >> the default value is of the bootstrap JDK. For instance, this just > >> changed to 7 with OpenJDK, so current builds will produce 1.7 bytecode > >> while builds using an older OpenJDK7 or OpenJDK6 will use 6. From > >> personal experience, it's much harder to debug a problem when you have > >> to take into account the boot JDK being used, which may vary, than > >> when you have an explicit value. > >> > >> It seems much clearer to specify it explicitly in one common place for > >> all platforms, which can also be easily overridden from the command > >> line if needed. This is the same as is now done for JDK, langtools, > >> jaxp and jaxws and will shortly be the case in corba. > > > > The jdk, langtools, etc., repos are much more sensitive to this > > setting than hotspot, which uses it only for makedeps and jvmti header > > generation. It's non-critical, and I think it's safe to assume that > > the default class file version produced by a boot jdk can also be run > > by that same boot jdk. > > > > So far, ecj is the only known boot env needing this set explicitly. > > > > That kind of assumption is the thing that tends to come back and bite > you. It's especially true because: > > * The boot JDK is something determined on a per-user basis, so just > updating the system JDK may cause a failure that's hard to diagnose. > * Failures in HotSpot javac builds are already hard to diagnose > because it doesn't print out the javac invocation. It took me longer > to track this down than the equivalents in JDK and CORBA, and I've > been working with the OpenJDK build for about two years now. > > Yes, ecj is the only one that fails. But we now have at least two > JDKs that will produce different results: OpenJDK6 (which defaults to > 6) and OpenJDK7 (which defaults to 7). There are even more if you > include the proprietary JDKs and JDK 1.5 which I assume can also build > OpenJDK at a push. > > One of the side effects of releasing code to the world is that people > are going to try and run into all sorts of corner cases. Assuming the > defaults are good works fine when the only people building the code > are Sun developers, but this is no longer true and something like this > is just the kind of thing a casual builder of the code will run into > and wonder why it fails. > > I agree this code is less used than the equivalent JDK and CORBA code, > but surely it's better to be as consistent as possible across the > codebase? > > Finally, switching SA to use the defaults would be a visible change. > > > -John > > > >> >> Which repo are you targeting for this change? > >> > > >> > I'd suggest hotspot-rt. > >> > > >> > Note that all hotspot changes have to be built on all platforms before > >> > being pushed; we have an automated system called jprt that does builds > >> > and tests on the various platforms. ? Unfortunately, it isn't > available > >> > externally. ? Sync up with the latest hotspot-rt and then contact me > >> > privately with a patch or your repo location and I'll run it through. > >> > > >> > >> The patch from this webrev is against hotspot-rt so can be tested. > >> > >> >> Yes, I see that SA uses '-source 1.4' in each platform makefile. > >> >> That should be fixed also, but that's another issue... > >> > > >> > Sigh. ? Stale values in makefiles ... > >> > > >> > >> Also fixed now by this patch. At least 1.4 is in one common makefile > >> rather than occurring six times over three makefiles... :) > >> > >> > -John > >> > > >> >> > Andrew John Hughes wrote: > >> >> > The makeDeps and jvmti bootstrap tools are built without explicit > >> >> > source and target options. > >> >> > > >> >> > This webrev: > >> >> > > >> >> > http://cr.openjdk.java.net/~andrew/ecj/03/webrev.01/ > >> >> > > >> >> > sets them to 6 explicitly. The change has to be replicated three > >> >> > times, because for some reason, the javac invocations are in > >> >> > platform-specific makefiles. ? I've tested the change successfully > on > >> >> > GNU/Linux, where it allows ecj to be used as javac. ? ecj defaults > to > >> >> > <1.5 and thus otherwise fails to build. ? I've assumed that the > same > >> >> > changes are applicable for Solaris and Windows, and that the source > >> >> > and target options don't have to be written in Latin or something > to > >> >> > work on these platforms. > >> >> > > >> >> > Is this ok to push? > >> >> > > >> >> > 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 > > > > > > > > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090821/254c311d/attachment-0001.html From gnu_andrew at member.fsf.org Fri Aug 21 20:17:56 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Sat, 22 Aug 2009 04:17:56 +0100 Subject: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <9146341c0908211923l44c1a044p765a490468c67a1b@mail.gmail.com> References: <17c6771e0908180642k67a2cc68refa4232b1cf1770c@mail.gmail.com> <4A8AB98E.4030605@sun.com> <19082.59099.744855.256045@sun.com> <17c6771e0908191230y3aabadfcq70ab30782538036@mail.gmail.com> <19084.34943.379450.167908@sun.com> <17c6771e0908200522u78b5a222j24661df5b76783c2@mail.gmail.com> <9146341c0908211923l44c1a044p765a490468c67a1b@mail.gmail.com> Message-ID: <17c6771e0908212017y162be11cvfc4cbce33106eccd@mail.gmail.com> 2009/8/22 David Schlosnagle : > Andrew, > > I'm just a beginner here trying to get a better understanding of the JDK by > scanning code reviews and I have a comment on the changes in > . > > In all the sa.make files (Linux, Solaris & Windows), should the -g flag be > removed from the two modified lines since it's included in the > SA_JAVAC_FLAGS via JAVAC_FLAGS in defs.make? I'd assume that the duplicate > -g won't cause failures, but it seems to force all debug info to always be > included even if one tried to override the compile flags to disable or alter > the debug information included. > > Thanks, > David Schlosnagle > Well spotted! They should have been removed. Revised in http://cr.openjdk.java.net/~andrew/ecj/03/webrev.04 > > On Thu, Aug 20, 2009 at 8:22 AM, Andrew John Hughes > wrote: >> >> 2009/8/20 John Coomes : >> > Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: >> >> 2009/8/18 John Coomes : >> >> > Daniel D. Daugherty (Daniel.Daugherty at Sun.COM) wrote: >> >> >> Andrew, >> >> >> >> >> >> A couple of comments: >> >> >> >> >> >> - if you specify '-source 6', then '-target 6' is implied >> >> >> ?? so you don't really need both >> >> >> - I would prefer to see a top-level macro that defines the >> >> >> ?? bootstrap tools javac option and then have the various >> >> >> ?? Makefiles use that macro. Something in make/defs.make: >> >> >> >> >> >> ?? ?? ?? BOOTSTRAP_TOOLS.JAVAC.FLAGS="-source 6" >> >> >> >> >> >> ?? or something like that. >> >> > >> >> > +1 on the top-level macro. ??In HotSpot, I would call it JAVAC_FLAGS >> >> > or >> >> > COMPILE_JAVAC_FLAGS, and add it to the COMPILE.JAVAC macro (spelled >> >> > COMPILE_JAVAC on windows) so that every compilation uses it. ??Then >> >> > fewer places need to be touched. >> >> > >> >> > Also, please leave the default value empty. ??On platforms that need >> >> > it, it can be set on the command line or in the environment. >> >> > Specifying a value requires periodic maintenance. ??Yes, the period >> >> > is >> >> > long, but it's a pain when the build breaks because of some stale >> >> > value in a makefile. >> >> > >> >> >> >> Ok, here's the changeset I was working on before I received your mail >> >> and which I've since successfully tested with hotspot-rt: >> >> >> >> http://cr.openjdk.java.net/~andrew/ecj/03/webrev.02/ >> > >> > I submitted your patch to the build queue; it will take several hours, >> > there's one job ahead of it. >> > >> > After looking at it again, the include of make/defs.make in >> > make/windows/makefiles/rules.make will most likely fail to build. ?The >> > latter is a windows nmake file, so the gnu-specific syntax will be >> > rejected and there are other unixisms in there (e.g., shell until). >> > >> >> I had a feeling Windows would be the one to bite... >> >> > Instead, try updating MAKE_ARGS in make/defs.make, I believe those are >> > exported to sub-makes. ?Since it has to be portable, I believe you'll >> > have to use '_' instead of '.' in the macro name. >> > >> >> Ok, in http://cr.openjdk.java.net/~andrew/ecj/03/webrev.03/ I've >> reverted the addtion >> of defs.make in favour of using MAKE_ARGS and renamed the variables >> using underscores (which I prefer anyway). >> >> Where I am confused is how the MAKE_ARGS changes get through to the >> Windows build if it doesn't parse defs.make. >> makefiles/windows/defs.make seems to imply that the top-level one will >> be read. >> >> >> This defines the variables in the top-level defs.make file. ?The >> >> versions are stored separately, in the same way as they are in the >> >> JDK: >> >> >> >> http://hg.openjdk.java.net/jdk7/build/jdk/rev/80368890a2a0 >> >> >> >> SA is still done separately as it's currently 1.4. ?The default for >> >> others is 6. >> >> The rest of the patch ensures this makefile is picked up and its >> >> values used for compilation across all three platforms. >> >> >> >> This is added to the invocations rather than COMPILE.JAVAC. ?As you >> >> imply in your mail, this value varies between platforms and even >> >> within the same platform. ?Just the GNU/Linux port itself defines it >> >> in about four ways. >> > >> > Take a look, it's simply selecting which path to use. ?After the def >> > of COMPILE.JAVAC, a simple >> > >> > ? ? ? ?COMPILE.JAVAC += $(BOOTSTRAP_JAVAC.FLAGS) >> > >> > should do it. ?Windows will have to be different, though. >> > >> >> Yes, the other problem is this forces the same options to SA as well >> which uses COMPILE.JAVAC. ?To keep the current status quo (at least >> for now), these need a different set of flags. >> >> >> I don't agree with leaving the value blank. ?The issue is relevant on >> >> all platforms, as leaving it blank makes the build open to whatever >> >> the default value is of the bootstrap JDK. ?For instance, this just >> >> changed to 7 with OpenJDK, so current builds will produce 1.7 bytecode >> >> while builds using an older OpenJDK7 or OpenJDK6 will use 6. ?From >> >> personal experience, it's much harder to debug a problem when you have >> >> to take into account the boot JDK being used, which may vary, than >> >> when you have an explicit value. >> >> >> >> It seems much clearer to specify it explicitly in one common place for >> >> all platforms, which can also be easily overridden from the command >> >> line if needed. ?This is the same as is now done for JDK, langtools, >> >> jaxp and jaxws and will shortly be the case in corba. >> > >> > The jdk, langtools, etc., repos are much more sensitive to this >> > setting than hotspot, which uses it only for makedeps and jvmti header >> > generation. ?It's non-critical, and I think it's safe to assume that >> > the default class file version produced by a boot jdk can also be run >> > by that same boot jdk. >> > >> > So far, ecj is the only known boot env needing this set explicitly. >> > >> >> That kind of assumption is the thing that tends to come back and bite >> you. ?It's especially true because: >> >> ?* The boot JDK is something determined on a per-user basis, so just >> updating the system JDK may cause a failure that's hard to diagnose. >> ?* Failures in HotSpot javac builds are already hard to diagnose >> because it doesn't print out the javac invocation. ?It took me longer >> to track this down than the equivalents in JDK and CORBA, and I've >> been working with the OpenJDK build for about two years now. >> >> Yes, ecj is the only one that fails. ?But we now have at least two >> JDKs that will produce different results: OpenJDK6 (which defaults to >> 6) and OpenJDK7 (which defaults to 7). ?There are even more if you >> include the proprietary JDKs and JDK 1.5 which I assume can also build >> OpenJDK at a push. >> >> One of the side effects of releasing code to the world is that people >> are going to try and run into all sorts of corner cases. ?Assuming the >> defaults are good works fine when the only people building the code >> are Sun developers, but this is no longer true and something like this >> is just the kind of thing a casual builder of the code will run into >> and wonder why it fails. >> >> I agree this code is less used than the equivalent JDK and CORBA code, >> but surely it's better to be as consistent as possible across the >> codebase? >> >> Finally, switching SA to use the defaults would be a visible change. >> >> > -John >> > >> >> >> Which repo are you targeting for this change? >> >> > >> >> > I'd suggest hotspot-rt. >> >> > >> >> > Note that all hotspot changes have to be built on all platforms >> >> > before >> >> > being pushed; we have an automated system called jprt that does >> >> > builds >> >> > and tests on the various platforms. ??Unfortunately, it isn't >> >> > available >> >> > externally. ??Sync up with the latest hotspot-rt and then contact me >> >> > privately with a patch or your repo location and I'll run it through. >> >> > >> >> >> >> The patch from this webrev is against hotspot-rt so can be tested. >> >> >> >> >> Yes, I see that SA uses '-source 1.4' in each platform makefile. >> >> >> That should be fixed also, but that's another issue... >> >> > >> >> > Sigh. ??Stale values in makefiles ... >> >> > >> >> >> >> Also fixed now by this patch. ?At least 1.4 is in one common makefile >> >> rather than occurring six times over three makefiles... :) >> >> >> >> > -John >> >> > >> >> >> > Andrew John Hughes wrote: >> >> >> > The makeDeps and jvmti bootstrap tools are built without explicit >> >> >> > source and target options. >> >> >> > >> >> >> > This webrev: >> >> >> > >> >> >> > http://cr.openjdk.java.net/~andrew/ecj/03/webrev.01/ >> >> >> > >> >> >> > sets them to 6 explicitly. The change has to be replicated three >> >> >> > times, because for some reason, the javac invocations are in >> >> >> > platform-specific makefiles. ??I've tested the change successfully >> >> >> > on >> >> >> > GNU/Linux, where it allows ecj to be used as javac. ??ecj defaults >> >> >> > to >> >> >> > <1.5 and thus otherwise fails to build. ??I've assumed that the >> >> >> > same >> >> >> > changes are applicable for Solaris and Windows, and that the >> >> >> > source >> >> >> > and target options don't have to be written in Latin or something >> >> >> > to >> >> >> > work on these platforms. >> >> >> > >> >> >> > Is this ok to push? >> >> >> > >> >> >> > 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 >> > >> > >> >> >> >> -- >> 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 > > -- 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 erik.trimble at sun.com Fri Aug 21 20:46:00 2009 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Sat, 22 Aug 2009 03:46:00 +0000 Subject: hg: jdk7/hotspot/hotspot: 7 new changesets Message-ID: <20090822034617.59C6512370@hg.openjdk.java.net> Changeset: 185d256992c3 Author: asaha Date: 2009-08-07 11:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/185d256992c3 6803688: Integrate latest JAX-WS (2.1.6) in to JDK 6u14 Reviewed-by: darcy, ramap ! THIRD_PARTY_README Changeset: adba5b333f26 Author: asaha Date: 2009-08-10 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/adba5b333f26 Merge Changeset: 0632c3e615a3 Author: tbell Date: 2009-08-14 08:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0632c3e615a3 Merge Changeset: 50a704b1d838 Author: xdono Date: 2009-08-20 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/50a704b1d838 Added tag jdk7-b70 for changeset 0632c3e615a3 ! .hgtags Changeset: 50a95aa4a247 Author: trims Date: 2009-08-21 20:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/50a95aa4a247 Merge Changeset: a05ea7791ee3 Author: trims Date: 2009-08-21 20:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a05ea7791ee3 6873236: Fork HS16 to HS17 - renumber Major and build numbers of JVM Summary: Update the Major and build numbers for HS17 fork Reviewed-by: jcoomes ! make/hotspot_version Changeset: a774e1abbe85 Author: trims Date: 2009-08-21 20:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a774e1abbe85 Merge From Erik.Trimble at Sun.COM Fri Aug 21 21:10:37 2009 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Fri, 21 Aug 2009 21:10:37 -0700 Subject: Creation of the Hotspot Express Project is APPROVED Message-ID: <4A8F6FBD.80603@sun.com> Sorry about the long notice on this. Per the interim governance guidelines for Projects [1] I'm pleased to announce the creation of the Hotspot Express Project [2] following the Hotspot Compiler Group's decision to sponsor it. The initial project of Hotspot Express is HSX 14 [3]. As this project is primarily intended for consumption by the OpenJDK 6 folks, discussion regarding this project is to be held on jdk6-dev at openjdk.java.net mailing list, rather than creating a new dedicated list. The vote was 16 for, none against. [1] http://openjdk.java.net/projects [2] http://mail.openjdk.java.net/pipermail/announce/2009-May/000076.html [3] http://hg.openjdk.java.net/hsx/hsx14 -- Erik Trimble Sun Microsystems, Inc. Java System Support Santa Clara, CA Timezone: US/Pacific (GMT-0800) From alexlamsl at gmail.com Sat Aug 22 05:57:14 2009 From: alexlamsl at gmail.com (Alex Lam S.L.) Date: Sat, 22 Aug 2009 13:57:14 +0100 Subject: FDLIBM 5.3 ported In-Reply-To: <311e0eaf0908211344w7334860gbdd9c5ea680f075a@mail.gmail.com> References: <311e0eaf0908201147g78f037abm6076749055cde576@mail.gmail.com> <311e0eaf0908211344w7334860gbdd9c5ea680f075a@mail.gmail.com> Message-ID: <746264c40908220557k7a451cb8i786309550665f3ae@mail.gmail.com> Hi there, Both attachments work just fine on here (Gmail), so I guess the mailing list server was doing its job right ;-) Alex. On Fri, Aug 21, 2009 at 9:44 PM, gustav trede wrote: > 2009/8/20 gustav trede >> >> Hello, >> >> All methods but sqrt is ported. >> >> I would be happy to get help with further conformance testing and feedback >> in general. >> >> The tests for Math and StrictMath classes in openjdk passes along with my >> own similar tests, comparing to the current strictmath for identical >> results. >> >> >> The performance improvements seems to be rather massive for quite a few >> operations. >> >> >> I have signed a JCA a couple of years ago. >> -- >> regards >> ?gustav trede > > Apologies for the strange attachment, it seems the mailing lists server > converted the java file to an .obj file. > I have now attached a ziped java file instead. > > -- > regards > ?gustav trede > > > -- Ted Turner - "Sports is like a war without the killing." - http://www.brainyquote.com/quotes/authors/t/ted_turner.html From gnu_andrew at member.fsf.org Mon Aug 24 09:57:34 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 24 Aug 2009 17:57:34 +0100 Subject: [PATCH FOR REVIEW]: Make source/target options explicit for MakeDeps and jvmti In-Reply-To: <17c6771e0908212017y162be11cvfc4cbce33106eccd@mail.gmail.com> References: <17c6771e0908180642k67a2cc68refa4232b1cf1770c@mail.gmail.com> <4A8AB98E.4030605@sun.com> <19082.59099.744855.256045@sun.com> <17c6771e0908191230y3aabadfcq70ab30782538036@mail.gmail.com> <19084.34943.379450.167908@sun.com> <17c6771e0908200522u78b5a222j24661df5b76783c2@mail.gmail.com> <9146341c0908211923l44c1a044p765a490468c67a1b@mail.gmail.com> <17c6771e0908212017y162be11cvfc4cbce33106eccd@mail.gmail.com> Message-ID: <17c6771e0908240957l75f3c6am9d3f538fe2edb335@mail.gmail.com> 2009/8/22 Andrew John Hughes : > 2009/8/22 David Schlosnagle : >> Andrew, >> >> I'm just a beginner here trying to get a better understanding of the JDK by >> scanning code reviews and I have a comment on the changes in >> . >> >> In all the sa.make files (Linux, Solaris & Windows), should the -g flag be >> removed from the two modified lines since it's included in the >> SA_JAVAC_FLAGS via JAVAC_FLAGS in defs.make? I'd assume that the duplicate >> -g won't cause failures, but it seems to force all debug info to always be >> included even if one tried to override the compile flags to disable or alter >> the debug information included. >> >> Thanks, >> David Schlosnagle >> > > Well spotted! They should have been removed. ?Revised in > http://cr.openjdk.java.net/~andrew/ecj/03/webrev.04 > >> >> On Thu, Aug 20, 2009 at 8:22 AM, Andrew John Hughes >> wrote: >>> >>> 2009/8/20 John Coomes : >>> > Andrew John Hughes (gnu_andrew at member.fsf.org) wrote: >>> >> 2009/8/18 John Coomes : >>> >> > Daniel D. Daugherty (Daniel.Daugherty at Sun.COM) wrote: >>> >> >> Andrew, >>> >> >> >>> >> >> A couple of comments: >>> >> >> >>> >> >> - if you specify '-source 6', then '-target 6' is implied >>> >> >> ?? so you don't really need both >>> >> >> - I would prefer to see a top-level macro that defines the >>> >> >> ?? bootstrap tools javac option and then have the various >>> >> >> ?? Makefiles use that macro. Something in make/defs.make: >>> >> >> >>> >> >> ?? ?? ?? BOOTSTRAP_TOOLS.JAVAC.FLAGS="-source 6" >>> >> >> >>> >> >> ?? or something like that. >>> >> > >>> >> > +1 on the top-level macro. ??In HotSpot, I would call it JAVAC_FLAGS >>> >> > or >>> >> > COMPILE_JAVAC_FLAGS, and add it to the COMPILE.JAVAC macro (spelled >>> >> > COMPILE_JAVAC on windows) so that every compilation uses it. ??Then >>> >> > fewer places need to be touched. >>> >> > >>> >> > Also, please leave the default value empty. ??On platforms that need >>> >> > it, it can be set on the command line or in the environment. >>> >> > Specifying a value requires periodic maintenance. ??Yes, the period >>> >> > is >>> >> > long, but it's a pain when the build breaks because of some stale >>> >> > value in a makefile. >>> >> > >>> >> >>> >> Ok, here's the changeset I was working on before I received your mail >>> >> and which I've since successfully tested with hotspot-rt: >>> >> >>> >> http://cr.openjdk.java.net/~andrew/ecj/03/webrev.02/ >>> > >>> > I submitted your patch to the build queue; it will take several hours, >>> > there's one job ahead of it. >>> > >>> > After looking at it again, the include of make/defs.make in >>> > make/windows/makefiles/rules.make will most likely fail to build. ?The >>> > latter is a windows nmake file, so the gnu-specific syntax will be >>> > rejected and there are other unixisms in there (e.g., shell until). >>> > >>> >>> I had a feeling Windows would be the one to bite... >>> >>> > Instead, try updating MAKE_ARGS in make/defs.make, I believe those are >>> > exported to sub-makes. ?Since it has to be portable, I believe you'll >>> > have to use '_' instead of '.' in the macro name. >>> > >>> >>> Ok, in http://cr.openjdk.java.net/~andrew/ecj/03/webrev.03/ I've >>> reverted the addtion >>> of defs.make in favour of using MAKE_ARGS and renamed the variables >>> using underscores (which I prefer anyway). >>> >>> Where I am confused is how the MAKE_ARGS changes get through to the >>> Windows build if it doesn't parse defs.make. >>> makefiles/windows/defs.make seems to imply that the top-level one will >>> be read. >>> >>> >> This defines the variables in the top-level defs.make file. ?The >>> >> versions are stored separately, in the same way as they are in the >>> >> JDK: >>> >> >>> >> http://hg.openjdk.java.net/jdk7/build/jdk/rev/80368890a2a0 >>> >> >>> >> SA is still done separately as it's currently 1.4. ?The default for >>> >> others is 6. >>> >> The rest of the patch ensures this makefile is picked up and its >>> >> values used for compilation across all three platforms. >>> >> >>> >> This is added to the invocations rather than COMPILE.JAVAC. ?As you >>> >> imply in your mail, this value varies between platforms and even >>> >> within the same platform. ?Just the GNU/Linux port itself defines it >>> >> in about four ways. >>> > >>> > Take a look, it's simply selecting which path to use. ?After the def >>> > of COMPILE.JAVAC, a simple >>> > >>> > ? ? ? ?COMPILE.JAVAC += $(BOOTSTRAP_JAVAC.FLAGS) >>> > >>> > should do it. ?Windows will have to be different, though. >>> > >>> >>> Yes, the other problem is this forces the same options to SA as well >>> which uses COMPILE.JAVAC. ?To keep the current status quo (at least >>> for now), these need a different set of flags. >>> >>> >> I don't agree with leaving the value blank. ?The issue is relevant on >>> >> all platforms, as leaving it blank makes the build open to whatever >>> >> the default value is of the bootstrap JDK. ?For instance, this just >>> >> changed to 7 with OpenJDK, so current builds will produce 1.7 bytecode >>> >> while builds using an older OpenJDK7 or OpenJDK6 will use 6. ?From >>> >> personal experience, it's much harder to debug a problem when you have >>> >> to take into account the boot JDK being used, which may vary, than >>> >> when you have an explicit value. >>> >> >>> >> It seems much clearer to specify it explicitly in one common place for >>> >> all platforms, which can also be easily overridden from the command >>> >> line if needed. ?This is the same as is now done for JDK, langtools, >>> >> jaxp and jaxws and will shortly be the case in corba. >>> > >>> > The jdk, langtools, etc., repos are much more sensitive to this >>> > setting than hotspot, which uses it only for makedeps and jvmti header >>> > generation. ?It's non-critical, and I think it's safe to assume that >>> > the default class file version produced by a boot jdk can also be run >>> > by that same boot jdk. >>> > >>> > So far, ecj is the only known boot env needing this set explicitly. >>> > >>> >>> That kind of assumption is the thing that tends to come back and bite >>> you. ?It's especially true because: >>> >>> ?* The boot JDK is something determined on a per-user basis, so just >>> updating the system JDK may cause a failure that's hard to diagnose. >>> ?* Failures in HotSpot javac builds are already hard to diagnose >>> because it doesn't print out the javac invocation. ?It took me longer >>> to track this down than the equivalents in JDK and CORBA, and I've >>> been working with the OpenJDK build for about two years now. >>> >>> Yes, ecj is the only one that fails. ?But we now have at least two >>> JDKs that will produce different results: OpenJDK6 (which defaults to >>> 6) and OpenJDK7 (which defaults to 7). ?There are even more if you >>> include the proprietary JDKs and JDK 1.5 which I assume can also build >>> OpenJDK at a push. >>> >>> One of the side effects of releasing code to the world is that people >>> are going to try and run into all sorts of corner cases. ?Assuming the >>> defaults are good works fine when the only people building the code >>> are Sun developers, but this is no longer true and something like this >>> is just the kind of thing a casual builder of the code will run into >>> and wonder why it fails. >>> >>> I agree this code is less used than the equivalent JDK and CORBA code, >>> but surely it's better to be as consistent as possible across the >>> codebase? >>> >>> Finally, switching SA to use the defaults would be a visible change. >>> >>> > -John >>> > >>> >> >> Which repo are you targeting for this change? >>> >> > >>> >> > I'd suggest hotspot-rt. >>> >> > >>> >> > Note that all hotspot changes have to be built on all platforms >>> >> > before >>> >> > being pushed; we have an automated system called jprt that does >>> >> > builds >>> >> > and tests on the various platforms. ??Unfortunately, it isn't >>> >> > available >>> >> > externally. ??Sync up with the latest hotspot-rt and then contact me >>> >> > privately with a patch or your repo location and I'll run it through. >>> >> > >>> >> >>> >> The patch from this webrev is against hotspot-rt so can be tested. >>> >> >>> >> >> Yes, I see that SA uses '-source 1.4' in each platform makefile. >>> >> >> That should be fixed also, but that's another issue... >>> >> > >>> >> > Sigh. ??Stale values in makefiles ... >>> >> > >>> >> >>> >> Also fixed now by this patch. ?At least 1.4 is in one common makefile >>> >> rather than occurring six times over three makefiles... :) >>> >> >>> >> > -John >>> >> > >>> >> >> > Andrew John Hughes wrote: >>> >> >> > The makeDeps and jvmti bootstrap tools are built without explicit >>> >> >> > source and target options. >>> >> >> > >>> >> >> > This webrev: >>> >> >> > >>> >> >> > http://cr.openjdk.java.net/~andrew/ecj/03/webrev.01/ >>> >> >> > >>> >> >> > sets them to 6 explicitly. The change has to be replicated three >>> >> >> > times, because for some reason, the javac invocations are in >>> >> >> > platform-specific makefiles. ??I've tested the change successfully >>> >> >> > on >>> >> >> > GNU/Linux, where it allows ecj to be used as javac. ??ecj defaults >>> >> >> > to >>> >> >> > <1.5 and thus otherwise fails to build. ??I've assumed that the >>> >> >> > same >>> >> >> > changes are applicable for Solaris and Windows, and that the >>> >> >> > source >>> >> >> > and target options don't have to be written in Latin or something >>> >> >> > to >>> >> >> > work on these platforms. >>> >> >> > >>> >> >> > Is this ok to push? >>> >> >> > >>> >> >> > 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 >>> > >>> > >>> >>> >>> >>> -- >>> 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 >> >> > > > > -- > 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 > Is this now ok to push? It passed the build. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Thomas.Rodriguez at Sun.COM Mon Aug 24 14:40:52 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 24 Aug 2009 14:40:52 -0700 Subject: Review request: Zero assembler port of HotSpot In-Reply-To: <20090817143251.GB3394@redhat.com> References: <20090817143251.GB3394@redhat.com> Message-ID: Sorry this took so long. Some generic comments first. The normal hotspot style is for the { to being always be on the same line instead of having a break in between. Many of the new files put a line break in between. I don't really like the introduction of the CORE_BUILD define. It seems orthogonal to the normal way of selecting builds. Also zero is a core-like build but it's not really core so reusing core for the build directory doesn't seem right. What's going to happen when shark is added? I guess I would expect the build directories to look like linux_i486_zero instead of linux_zero_core which is what I think you'd currently get. Is there some reason you can't allow ARCH_DATA_MODEL to be specified directly instead of adding ZERO_BITSPERWORD? And couldn't the same be done with ZERO_ENDIANNESS being replaced with ENDIANNESS? I'd prefer to generalize the makefiles instead of adding exceptions for zero. Maybe ZERO_LIBARCH could be handled similarly, though in at least one case we're inconsistent in our use of x86 vs. i386. Can you rename method_entry_t to something like MethodEntryFunc? I'm surprised by the amount of stubs you have. Presumably these are only because of virtuals for types you don't use? Wouldn't it be better to ifndef ZERO the files that aren't needed? I'm assuming it's not a huge number of files, something like assembler, stubRoutines, stubGenerator and maybe some others? Maybe that gets into a rathole? There's something unsatisfying about the structure of these changes that I can't put my finger on. Maybe it's that zero files end up containing both architecture independent and architecture dependent stuff. I know that's a pretty useless comment and I'm not sure what to do about it. Maybe you have some thoughts on this? Anyway, unless I can come up with something concrete doesn't worry about this. Also I only looked at the hotspot pieces so someone familiar with the other parts will have to review those before they can be committed. hotspot/make/Makefile Don't reuse C2_BASE_DIR: CORE_BASE_DIR=$(OUTPUTDIR)/$(VM_PLATFORM)_core hotspot/make/linux/makefiles/buildtree.make ZERO_ARCH_DATA_MODEL instead of ZERO_BITSPERWORD ? hotspot/make/linux/makefiles/vm.make remove the extra def of STATIC_CXX hotspot/src/share/vm/runtime/icache.cpp Why are you ifdefing this code instead of providing an empty implementation? As an aside, I'm not sure it's safe to not provide an implementation of this at all. Even the installation of newly generated code requires an icache flush, otherwise you might just see garbage instead of the code you actually generated. Is shark handling this differently? hotspot/src/share/vm/runtime/jniHandles.hpp What's the purpose of promoting clear() to protected in JNIHandleBlock? There are no subclasses of JNIHandle that I can see. It seems like only the friend declaration is needed and I don't think you need to ifdef it. It seems reasonable to allow CppInterpreter access to that. hotspot/src/share/vm/runtime/signature.hpp I'm ok with these change as is but it's unfortunate that there are ifdefs here at all. Any ideas how to restructure this to eliminate them completely? hotspot/src/share/vm/utilities/vmError.cpp The direct inclusion of stackPrinter_zero.hpp isn't very nice and the scattered ifdef to support it's use are somewhat ugly. Is there some reason the stack printing for zero can't be integrated better into the existing printing logic? src/cpu/zero/vm/assembler_zero.cpp Why do some functions like code_fill_byte have implementations? Shouldn't they be Unimplemented()? src/cpu/zero/vm/assembler_zero.hpp Can you move the include block to the beginning of the file. src/cpu/zero/vm/bytecodeInterpreter_zero.hpp what's the purpose of the LOTS_OF_REGS define? There's no reference to it anywhere else. hotspot/src/cpu/zero/vm/frame_zero.hpp Shouldn't is_deoptimizer_frame be is_deoptimized_frame? hotspot/src/cpu/zero/vm/frame_zero.inline.hpp I think you should be calling find_blob_unsafe instead of find_blob as the other frame code does. tom On Aug 17, 2009, at 7:32 AM, Gary Benson wrote: > Hi all, > > Zero is an interpreter-only port of HotSpot that uses no assembler and > can trivially be built on any Linux system. The following webrev adds > Zero support to OpenJDK: > > http://cr.openjdk.java.net/~gbenson/zero-07/ > > There are a number of environment variables that need setting before > running make, but if you are using jdk/make/jdk_generic_profile.sh > to set up your environment then you only need to set two, and a build > can be as simple as: > > export CORE_BUILD=true > export ZERO_BUILD=true > . jdk/make/jdk_generic_profile.sh > gmake sanity && gmake > > The two mandatory environment variables do the following: > > CORE_BUILD > Setting CORE_BUILD to "true" will result in an interpreter-only > HotSpot being built, with neither the client nor the server > compilers. If CORE_BUILD is unset, or set to any other value > than "true", then the compiler(s) will be built as normal. > > ZERO_BUILD > Setting ZERO_BUILD to "true" will cause the Zero interpreter to > be used. If ZERO_BUILD is unset, or set to any other value than > "true", the standard, platform-specific interpreter will be used. > > The reason for having two separate flags is to allow for Zero builds > with JIT compilers such as Shark (not included in this webrev). To > build HotSpot with Zero and Shark you would set ZERO_BUILD to "true" > but leave CORE_BUILD unset. > > Of the other environment variables the following are required when > ZERO_BUILD is set to "true". These are set by > jdk/make/jdk_generic_profile.sh based on the result of uname -m: > > ZERO_LIBARCH > This is the name of the architecture-specific subdirectory under > $JAVA_HOME/jre/lib. Typically this will be the same as the output > of uname -m, although there are some exceptions: "amd64" instead > of "x86_64", for example, and "i386" instead of "i686". > > ZERO_ARCHDEF > The value of ZERO_ARCHDEF will be passed to the C++ compiler using > -D${ZERO_ARCHDEF} to allow conditionalized platform-specific code. > This is typically set to ZERO_LIBARCH converted to uppercase but, > again, there are exceptions. "i386" becomes "IA32", to match what > HotSpot already does, and on platforms with both 32- and 64-bit > variants ZERO_ARCHDEF corresponds to the 32-bit version, so both > ppc and ppc64 have ZERO_ARCHDEF set to "PPC". > > ZERO_ENDIANNESS > This is set to "little" or "big". > > ZERO_BITSPERWORD > This is set to "32" or "64". > > ZERO_ARCHFLAG > This is a flag that will be passed to the C++ compiler and to the > linker to instruct them to generate code for the particular > platform. This is required for platforms with both 32- and 64-bit > variants where the compiler needs to be told which variant to > build for. ZERO_ARCHFLAG will typically be set to "-m32" or > "-m64", except on 31-bit zSeries where it will be set to "-m31". > > Zero uses one external library, libffi, for JNI method invocation. > The following two variables are used to tell the compiler and linker > how to find libffi. These can be set by the user, but if left unset > then jdk/make/jdk_generic_profile.sh will attempt to set them using > pkg-config or, failing that, by supplying defaults pointing to the > standard locations: > > LIBFFI_CFLAGS > Flags to be passed to the C++ compiler to build against libffi. > If unset (and pkg-config is not installed, or if libffi is not > built with pkg-config) then this defaults to "". > > LIBFFI_LIBS > Flags to be passed to the linker to link against libffi. If > unset (and pkg-config is not installed, or if libffi is not > built with pkg-config) then this defaults to "-lffi". > > Cheers, > Gary > > -- > http://gbenson.net/ From gbenson at redhat.com Tue Aug 25 04:12:21 2009 From: gbenson at redhat.com (Gary Benson) Date: Tue, 25 Aug 2009 12:12:21 +0100 Subject: Review request: Zero assembler port of HotSpot In-Reply-To: References: <20090817143251.GB3394@redhat.com> Message-ID: <20090825111221.GA3512@redhat.com> Hi Tom, Tom Rodriguez wrote: > Some generic comments first. The normal hotspot style is for the { > to being always be on the same line instead of having a break in > between. Many of the new files put a line break in between. Tqhis dates back from when I originally started work on all this. Back then the i486 and amd64 ports were separate, and the amd64 port had a different coding style from the others. I followed the amd64 convention thinking that, because it was the newest, it was most likely to be right (Oops!) Would you like me to reformat it? > I don't really like the introduction of the CORE_BUILD define. It > seems orthogonal to the normal way of selecting builds. Also zero > is a core-like build but it's not really core so reusing core for > the build directory doesn't seem right. Can you elaborate on this? From the Makefiles I got the impression that what "core" meant was "everything but the compiler": is that not correct? > What's going to happen when shark is added? To build Zero without Shark you set ZERO_BUILD=true and CORE_BUILD=true. To build Zero with Shark you set ZERO_BUILD=true and SHARK_BUILD=true. So CORE_BUILD=true is used only when you're building interpreter-only. > I guess I would expect the build directories to look like > linux_i486_zero instead of linux_zero_core which is what I think > you'd currently get. I originally tried doing it that way, but it was next to impossible. The modified Makefiles treat "zero" as the architecture of the build (ie a lot of the various $*ARCH variables are set to "zero"). When you're building with Shark you get linux_zero_shark. Note that this only a build-time thing; the JDK you get at the end will have its architecture-dependent stuff in a directory that matches the name of the platform (ie i386, sparc, ppc, etc). > Is there some reason you can't allow ARCH_DATA_MODEL to be specified > directly instead of adding ZERO_BITSPERWORD? And couldn't the same > be done with ZERO_ENDIANNESS being replaced with ENDIANNESS? I'd > prefer to generalize the makefiles instead of adding exceptions for > zero. Maybe ZERO_LIBARCH could be handled similarly, though in at > least one case we're inconsistent in our use of x86 vs. i386. I'm pretty sure these could be changed, the first two at any rate. > Can you rename method_entry_t to something like MethodEntryFunc? Sure. > I'm surprised by the amount of stubs you have. Presumably these are > only because of virtuals for types you don't use? There's virtuals in there, yes, but a lot of them are simply ordinary methods that are referenced by other code that doesn't get used when you build with Zero. I toyed with the idea of replacing all the calls to Unimplemented with calls to ShouldNotCallThis, just to make the point that they aren't used. What do you think? > Wouldn't it be better to ifndef ZERO the files that aren't needed? > I'm assuming it's not a huge number of files, something like > assembler, stubRoutines, stubGenerator and maybe some others? Maybe > that gets into a rathole? I'm not sure what you mean by "ifndef ZERO the files that aren't needed"... > There's something unsatisfying about the structure of these changes > that I can't put my finger on. Maybe it's that zero files end up > containing both architecture independent and architecture dependent > stuff. I know that's a pretty useless comment and I'm not sure what > to do about it. Maybe you have some thoughts on this? Anyway, > unless I can come up with something concrete doesn't worry about > this. Ok. > Also I only looked at the hotspot pieces so someone familiar with the > other parts will have to review those before they can be committed. Sure. > hotspot/make/Makefile > > Don't reuse C2_BASE_DIR: > > CORE_BASE_DIR=$(OUTPUTDIR)/$(VM_PLATFORM)_core Ok, should be simple. > hotspot/make/linux/makefiles/buildtree.make > > ZERO_ARCH_DATA_MODEL instead of ZERO_BITSPERWORD ? Or just ARCH_DATA_MODEL as you said before. > hotspot/make/linux/makefiles/vm.make > > remove the extra def of STATIC_CXX Ah, missed that :) > hotspot/src/share/vm/runtime/icache.cpp > > Why are you ifdefing this code instead of providing an empty > implementation? I think it turned out neater than trying to fudge call_flush_stub to pass the guarantee that the first call was for the flush stub itself. I can try and do it that way if you like? > As an aside, I'm not sure it's safe to not provide an implementation > of this at all. Even the installation of newly generated code > requires an icache flush, otherwise you might just see garbage > instead of the code you actually generated. Is shark handling this > differently? It's safe because there is never any actual code in codebuffers in Zero or Shark. In Zero everything that's executed is code compiled by the C++ compiler; in Shark, the cache invalidation is done by LLVM. > hotspot/src/share/vm/runtime/jniHandles.hpp > > What's the purpose of promoting clear() to protected in JNIHandleBlock? > There are no subclasses of JNIHandle that I can see. It seems like only > the friend declaration is needed and I don't think you need to ifdef it. > It seems reasonable to allow CppInterpreter access to that. What should I do, just make clear public? > hotspot/src/share/vm/runtime/signature.hpp > > I'm ok with these change as is but it's unfortunate that there are > ifdefs here at all. Any ideas how to restructure this to eliminate > them completely? It should be possible to remove them, but it would require the implementation of pass_float for i486 and sparc (which currently pass floats as ints). Shall I do this? > hotspot/src/share/vm/utilities/vmError.cpp > > The direct inclusion of stackPrinter_zero.hpp isn't very nice and > the scattered ifdef to support it's use are somewhat ugly. Is there > some reason the stack printing for zero can't be integrated better > into the existing printing logic? I'll look into this. > src/cpu/zero/vm/assembler_zero.cpp > > Why do some functions like code_fill_byte have implementations? > Shouldn't they be Unimplemented()? Everything with an implementation is used somewhere by something. For example, code_fill_byte is used by CodeBuffer::relocate_code_to to clear any padding left after whatever was in the codebuffer. > src/cpu/zero/vm/assembler_zero.hpp > > Can you move the include block to the beginning of the file. Sure. Is there a better place I can include those files though? I was never particularly happy with having them in that file. > src/cpu/zero/vm/bytecodeInterpreter_zero.hpp > > what's the purpose of the LOTS_OF_REGS define? There's no reference > to it anywhere else. It's used in bytecodeInterpreter.cpp: #ifdef LOTS_OF_REGS register JavaThread* THREAD = istate->thread(); register volatile jbyte* BYTE_MAP_BASE = _byte_map_base; #else #undef THREAD #define THREAD istate->thread() #undef BYTE_MAP_BASE #define BYTE_MAP_BASE _byte_map_base #endif > hotspot/src/cpu/zero/vm/frame_zero.hpp > > Shouldn't is_deoptimizer_frame be is_deoptimized_frame? I'll change it. > hotspot/src/cpu/zero/vm/frame_zero.inline.hpp > > I think you should be calling find_blob_unsafe instead of find_blob > as the other frame code does. Ok. Thanks for looking into this for me. Cheers, Gary -- http://gbenson.net/ From gnu_andrew at member.fsf.org Tue Aug 25 07:49:52 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 25 Aug 2009 15:49:52 +0100 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <4A898E4F.5020007@sun.com> References: <17c6771e0907312044q43080f55y3353927a57dca99f@mail.gmail.com> <4A78DB80.2030504@sun.com> <17c6771e0908041817h48a5fd1dhcfeb93dc1ae9c0ae@mail.gmail.com> <4A78E151.9070304@sun.com> <17c6771e0908050357u792fd707h4f28cb9b08e9e395@mail.gmail.com> <4A79F131.7040105@sun.com> <17c6771e0908051639h4c9a9c79vfdc4f6048d17cca8@mail.gmail.com> <4A84B194.1070108@sun.com> <17c6771e0908140537g6f61faf8h3f912415b2f3e9c3@mail.gmail.com> <4A898E4F.5020007@sun.com> Message-ID: <17c6771e0908250749s5c153aa4m40b15d155e3c5bbe@mail.gmail.com> 2009/8/17 Joseph D. Darcy : > Andrew John Hughes wrote: >> >> 2009/8/14 Joe Darcy : >> >>> >>> Andrew John Hughes wrote: >>> >>>> >>>> 2009/8/5 Tim Bell : >>>> >>>> >>>>> >>>>> Andrew John Hughes wrote: >>>>> >>>>> >>>>> >>>>>> >>>>>> Thanks Tim, that seems to have fixed the permissions issue. >>>>>> >>>>>> >>>>> >>>>> Good. >>>>> >>>>> >>>>> >>>>>> >>>>>> There now seems to be an issue with jcheck, as the merge causes some >>>>>> bugids to be repeated: >>>>>> >>>>>> >>>>> >>>>> Hmmm - how did these changesets come in through two different paths? >>>>> >>>>> >>>>> >>>>>> >>>>>> pushing to ssh://hg.openjdk.java.net/jdk6/jdk6-gate/hotspot >>>>>> searching for changes >>>>>> remote: adding changesets >>>>>> remote: adding manifests >>>>>> remote: adding file changes >>>>>> remote: added 555 changesets with 4771 changes to 1453 files >>>>>> remote: >>>>>> remote: > Changeset: 100:d821d920b465 >>>>>> remote: > Author: ? ?kvn >>>>>> remote: > Date: ? ? ?2008-03-11 11:04 >>>>>> remote: > >>>>>> remote: > 6623167: C2 crashed in StoreCMNode::Value >>>>>> remote: > Summary: C2 crashed in StoreCMNode::Value because >>>>>> n->in(MemNode::OopStore) is 0. >>>>>> remote: > Reviewed-by: rasbold, never >>>>>> remote: >>>>>> remote: Bugid 6623167 already used in this repository, in revision 20 >>>>>> remote: >>>>>> remote: > Changeset: 104:2c106685d6d0 >>>>>> remote: > Author: ? ?dcubed >>>>>> remote: > Date: ? ? ?2008-03-12 18:06 >>>>>> remote: > >>>>>> remote: > 6497639: 4/3 Profiling Swing application caused JVM crash >>>>>> remote: > Summary: Make RedefineClasses() interoperate better with >>>>>> class sharing. >>>>>> remote: > Reviewed-by: sspitsyn, jmasa >>>>>> remote: >>>>>> remote: Bugid 6497639 already used in this repository, in revision 20 >>>>>> remote: >>>>>> remote: > Changeset: 105:d8b3ef7ee3e5 >>>>>> remote: > Author: ? ?dcubed >>>>>> remote: > Date: ? ? ?2008-03-12 18:07 >>>>>> remote: > >>>>>> remote: > 6599425: 4/3 OopMapCache::lookup() can cause later crash or >>>>>> assert() failure >>>>>> remote: > Summary: Add should_not_be_cached() to markOop and methodOop >>>>>> and query that status inOopMapCache::lookup() >>>>>> remote: > Reviewed-by: coleenp, sspitsyn, jmasa >>>>>> remote: >>>>>> remote: Bugid 6599425 already used in this repository, in revision 20 >>>>>> remote: >>>>>> remote: > Changeset: 240:65fe2bd88839 >>>>>> remote: > Author: ? ?never >>>>>> remote: > Date: ? ? ?2008-06-05 21:44 >>>>>> remote: > >>>>>> remote: > 6614100: EXCEPTION_ACCESS_VIOLATION while running Eclipse >>>>>> with 1.6.0_05-ea >>>>>> remote: > Reviewed-by: kvn, jrose, rasbold >>>>>> remote: >>>>>> remote: Bugid 6614100 already used in this repository, in revision 20 >>>>>> remote: >>>>>> remote: > Changeset: 286:3e82d72933d0 >>>>>> remote: > Author: ? ?xlu >>>>>> remote: > Date: ? ? ?2008-06-26 14:15 >>>>>> remote: > >>>>>> remote: > 6718830: Hotspot fails to build with gcc 4.3 >>>>>> remote: > Summary: Fixed linux make file and couple adlc code to meet >>>>>> the changes of gcc 4.3 >>>>>> remote: > Reviewed-by: kamg, igor >>>>>> remote: >>>>>> remote: Bugid 6718830 already used in this repository, in revision 32 >>>>>> remote: >>>>>> remote: > Changeset: 289:551f4309f476 >>>>>> remote: > Author: ? ?ohair >>>>>> remote: > Date: ? ? ?2008-07-03 10:46 >>>>>> remote: > >>>>>> remote: > 6695777: Queens.class should be built from source, not put >>>>>> in source repo >>>>>> remote: > Reviewed-by: kvn >>>>>> remote: >>>>>> remote: Bugid 6695777 already used in this repository, in revision 20 >>>>>> remote: >>>>>> remote: > Changeset: 314:54499b980c23 >>>>>> remote: > Author: ? ?swamyv >>>>>> remote: > Date: ? ? ?2008-07-29 13:54 >>>>>> remote: > >>>>>> remote: > 6710791: Remove files or build from source:maf-1_0.jar, >>>>>> jlfg-1_0.jar >>>>>> remote: > Summary: Removed maf-1_0.jar and jlfg-1_0.jar files. >>>>>> remote: > Reviewed-by: poonam, jjh >>>>>> remote: >>>>>> remote: Bugid 6710791 already used in this repository, in revision 20 >>>>>> remote: >>>>>> remote: > Changeset: 360:fa4d1d240383 >>>>>> remote: > Author: ? ?never >>>>>> remote: > Date: ? ? ?2008-08-26 15:49 >>>>>> remote: > >>>>>> remote: > 6741642: bad enum definition in ciTypeFlow.hpp >>>>>> remote: > Reviewed-by: rasbold, martin >>>>>> remote: > Contributed-by: doko at ubuntu.com >>>>>> remote: >>>>>> remote: Bugid 6741642 already used in this repository, in revision 22 >>>>>> remote: >>>>>> remote: > Changeset: 589:748572b86af6 >>>>>> remote: > Author: ? ?never >>>>>> remote: > Date: ? ? ?2009-04-07 14:46 >>>>>> remote: > >>>>>> remote: > 6636360: compiler/6595044/Main.java test fails with 64bit >>>>>> java on solaris-sparcv9 with SIGSEGV >>>>>> remote: > Reviewed-by: kvn, twisti >>>>>> remote: >>>>>> remote: Bugid 6636360 already used in this repository, in revision 29 >>>>>> remote: >>>>>> remote: abort: pretxnchangegroup.0.jcheck hook failed >>>>>> remote: transaction abort! >>>>>> remote: rollback completed >>>>>> abort: unexpected response: empty string >>>>>> >>>>>> Is there a way of getting it to ignore these for this one push? ?I >>>>>> don't know of a way to just pull out these nine changesets from the >>>>>> 555 waiting to go... >>>>>> >>>>>> >>>>> >>>>> I think they would need to be added to the jcheck whitelist for all >>>>> time- >>>>> but that is more of a question for Mark or Kelly. >>>>> >>>>> Tim >>>>> >>>>> >>>>> >>>> >>>> The early revisions (20, 32) are from OpenJDK6 which was rebased to >>>> allow HotSpot patches to be applied on top. ?So what happened here is >>>> that, as the fixes were already applied to OpenJDK6, the new >>>> changesets pulled in by the merge will be no-ops but still exist to >>>> keep the change history accurate. >>>> >>>> I think we just need a way of disabling this check. ?OpenJDK6 already >>>> has whitespace and comment checks turned to lax. ?See .jcheck: >>>> http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/0282bf49b0f6. ?There >>>> may already be an option for this bugid check too, but I have no idea >>>> what the format of that file is. >>>> >>>> >>> >>> Andrew, can you please try your push again? >>> >>> I chatted with Mark and the OpenJDK 6 HotSpot Mercurial repository should >>> be >>> configured to do lax checking on the bug ids. >>> >>> Thanks, >>> >>> -Joe >>> >>> >> >> Sorry, same failure still occurs :( >> >> I didn't see any changes to .jcheck, which I would assume are needed >> to fix this (mr added one for the lax comments with the rebase). >> > > *sigh* > > Okay; I'll chat with Mark again to get to the bottom of this. > > -Joe > Any further news? Can we not just turn off jcheck for jdk6? -- 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 vladimir.kozlov at sun.com Tue Aug 25 18:14:03 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 26 Aug 2009 01:14:03 +0000 Subject: hg: jdk7/hotspot/hotspot: 14 new changesets Message-ID: <20090826011439.3635B1258A@hg.openjdk.java.net> Changeset: 046932b72aa2 Author: never Date: 2009-08-14 00:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/046932b72aa2 6862956: PhaseIdealLoop should have a CFG verification mode Reviewed-by: kvn, twisti ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phase.hpp Changeset: 1a81ea4b45d4 Author: kvn Date: 2009-08-14 12:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1a81ea4b45d4 6869822: assert(Universe::narrow_oop_shift() == 0,"use unscaled narrow oop") Summary: Replace the assert with narrow_oop_shift set to 0. Reviewed-by: never, jcoomes ! src/share/vm/memory/universe.cpp Changeset: a70508bb21c3 Author: never Date: 2009-08-14 15:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a70508bb21c3 6862863: C2 compiler fails in elide_copy() Reviewed-by: kvn ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/postaloc.cpp Changeset: 55784fd95fe3 Author: never Date: 2009-08-14 15:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/55784fd95fe3 Merge Changeset: 7c14587118b3 Author: never Date: 2009-08-14 22:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7c14587118b3 Merge Changeset: c8e2135f7e30 Author: cfang Date: 2009-08-17 09:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c8e2135f7e30 6829127: Deoptimization Failure on Specjvm98 _227_mtrt with -XX:+DeoptimizeALot since Hs11 b01 Summary: Make sure the control word is correct in deopt_blob after restore_result_registers Reviewed-by: kvn, never ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp Changeset: 662f330d7275 Author: cfang Date: 2009-08-17 12:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/662f330d7275 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) Summary: delay dead code elimination in set_req_X to make it safe Reviewed-by: kvn, never ! src/share/vm/opto/phaseX.cpp + test/compiler/6866651/Test.java Changeset: d0acbc302e14 Author: never Date: 2009-08-17 14:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d0acbc302e14 6795465: Crash in assembler_sparc.cpp with client compiler on solaris-sparc Reviewed-by: twisti, cfang ! src/cpu/sparc/vm/c1_Defs_sparc.hpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/share/vm/includeDB_compiler1 + test/compiler/6795465/Test6795465.java Changeset: cd18bd5e667c Author: never Date: 2009-08-19 18:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/cd18bd5e667c 6873777: FPU control word optimization still performed with SSE Reviewed-by: kvn ! src/share/vm/opto/compile.cpp Changeset: 357d4e2eb4dd Author: kvn Date: 2009-08-19 19:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/357d4e2eb4dd 6873799: enable escape analysis by default Summary: enable escape analysis by default Reviewed-by: never ! src/share/vm/opto/c2_globals.hpp Changeset: 72088be4b386 Author: cfang Date: 2009-08-20 12:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/72088be4b386 6873116: Modify reexecute implementation to use pcDesc to record the reexecute bit Summary: use PcDesc to keep record of the reexecute bit instead of using DebugInfoStreams Reviewed-by: kvn, never, twisti ! agent/src/share/classes/sun/jvm/hotspot/code/DebugInfoReadStream.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/code/PCDesc.java ! agent/src/share/classes/sun/jvm/hotspot/code/ScopeDesc.java ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/code/debugInfo.hpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/pcDesc.cpp ! src/share/vm/code/pcDesc.hpp ! src/share/vm/code/scopeDesc.cpp ! src/share/vm/code/scopeDesc.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/runtime/vframe.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 82bd76d4d7f2 Author: kvn Date: 2009-08-24 11:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/82bd76d4d7f2 6873800: enable compressed oops by default Summary: enable compressed oops by default Reviewed-by: never, ysr ! src/share/vm/runtime/arguments.cpp Changeset: cdb8b7c37ac1 Author: never Date: 2009-08-24 22:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/cdb8b7c37ac1 6875329: fix for 6795465 broke exception handler cloning Reviewed-by: kvn ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp Changeset: aba04734b61e Author: kvn Date: 2009-08-25 13:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/aba04734b61e Merge From Joe.Darcy at Sun.COM Tue Aug 25 21:36:27 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 25 Aug 2009 21:36:27 -0700 Subject: Bugids already used in this repository (Re: [FOR REVIEW] hs14 merge for OpenJDK6) In-Reply-To: <17c6771e0908250749s5c153aa4m40b15d155e3c5bbe@mail.gmail.com> References: <17c6771e0907312044q43080f55y3353927a57dca99f@mail.gmail.com> <4A78DB80.2030504@sun.com> <17c6771e0908041817h48a5fd1dhcfeb93dc1ae9c0ae@mail.gmail.com> <4A78E151.9070304@sun.com> <17c6771e0908050357u792fd707h4f28cb9b08e9e395@mail.gmail.com> <4A79F131.7040105@sun.com> <17c6771e0908051639h4c9a9c79vfdc4f6048d17cca8@mail.gmail.com> <4A84B194.1070108@sun.com> <17c6771e0908140537g6f61faf8h3f912415b2f3e9c3@mail.gmail.com> <4A898E4F.5020007@sun.com> <17c6771e0908250749s5c153aa4m40b15d155e3c5bbe@mail.gmail.com> Message-ID: <4A94BBCB.9020206@sun.com> Andrew John Hughes wrote: > 2009/8/17 Joseph D. Darcy : > >> Andrew John Hughes wrote: >> >>> 2009/8/14 Joe Darcy : >>> >>> >>>> Andrew John Hughes wrote: >>>> >>>> >>>>> 2009/8/5 Tim Bell : >>>>> >>>>> >>>>> >>>>>> Andrew John Hughes wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Thanks Tim, that seems to have fixed the permissions issue. >>>>>>> >>>>>>> >>>>>>> >>>>>> Good. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> There now seems to be an issue with jcheck, as the merge causes some >>>>>>> bugids to be repeated: >>>>>>> >>>>>>> >>>>>>> >>>>>> Hmmm - how did these changesets come in through two different paths? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> pushing to ssh://hg.openjdk.java.net/jdk6/jdk6-gate/hotspot >>>>>>> searching for changes >>>>>>> remote: adding changesets >>>>>>> remote: adding manifests >>>>>>> remote: adding file changes >>>>>>> remote: added 555 changesets with 4771 changes to 1453 files >>>>>>> remote: >>>>>>> remote: > Changeset: 100:d821d920b465 >>>>>>> remote: > Author: kvn >>>>>>> remote: > Date: 2008-03-11 11:04 >>>>>>> remote: > >>>>>>> remote: > 6623167: C2 crashed in StoreCMNode::Value >>>>>>> remote: > Summary: C2 crashed in StoreCMNode::Value because >>>>>>> n->in(MemNode::OopStore) is 0. >>>>>>> remote: > Reviewed-by: rasbold, never >>>>>>> remote: >>>>>>> remote: Bugid 6623167 already used in this repository, in revision 20 >>>>>>> remote: >>>>>>> remote: > Changeset: 104:2c106685d6d0 >>>>>>> remote: > Author: dcubed >>>>>>> remote: > Date: 2008-03-12 18:06 >>>>>>> remote: > >>>>>>> remote: > 6497639: 4/3 Profiling Swing application caused JVM crash >>>>>>> remote: > Summary: Make RedefineClasses() interoperate better with >>>>>>> class sharing. >>>>>>> remote: > Reviewed-by: sspitsyn, jmasa >>>>>>> remote: >>>>>>> remote: Bugid 6497639 already used in this repository, in revision 20 >>>>>>> remote: >>>>>>> remote: > Changeset: 105:d8b3ef7ee3e5 >>>>>>> remote: > Author: dcubed >>>>>>> remote: > Date: 2008-03-12 18:07 >>>>>>> remote: > >>>>>>> remote: > 6599425: 4/3 OopMapCache::lookup() can cause later crash or >>>>>>> assert() failure >>>>>>> remote: > Summary: Add should_not_be_cached() to markOop and methodOop >>>>>>> and query that status inOopMapCache::lookup() >>>>>>> remote: > Reviewed-by: coleenp, sspitsyn, jmasa >>>>>>> remote: >>>>>>> remote: Bugid 6599425 already used in this repository, in revision 20 >>>>>>> remote: >>>>>>> remote: > Changeset: 240:65fe2bd88839 >>>>>>> remote: > Author: never >>>>>>> remote: > Date: 2008-06-05 21:44 >>>>>>> remote: > >>>>>>> remote: > 6614100: EXCEPTION_ACCESS_VIOLATION while running Eclipse >>>>>>> with 1.6.0_05-ea >>>>>>> remote: > Reviewed-by: kvn, jrose, rasbold >>>>>>> remote: >>>>>>> remote: Bugid 6614100 already used in this repository, in revision 20 >>>>>>> remote: >>>>>>> remote: > Changeset: 286:3e82d72933d0 >>>>>>> remote: > Author: xlu >>>>>>> remote: > Date: 2008-06-26 14:15 >>>>>>> remote: > >>>>>>> remote: > 6718830: Hotspot fails to build with gcc 4.3 >>>>>>> remote: > Summary: Fixed linux make file and couple adlc code to meet >>>>>>> the changes of gcc 4.3 >>>>>>> remote: > Reviewed-by: kamg, igor >>>>>>> remote: >>>>>>> remote: Bugid 6718830 already used in this repository, in revision 32 >>>>>>> remote: >>>>>>> remote: > Changeset: 289:551f4309f476 >>>>>>> remote: > Author: ohair >>>>>>> remote: > Date: 2008-07-03 10:46 >>>>>>> remote: > >>>>>>> remote: > 6695777: Queens.class should be built from source, not put >>>>>>> in source repo >>>>>>> remote: > Reviewed-by: kvn >>>>>>> remote: >>>>>>> remote: Bugid 6695777 already used in this repository, in revision 20 >>>>>>> remote: >>>>>>> remote: > Changeset: 314:54499b980c23 >>>>>>> remote: > Author: swamyv >>>>>>> remote: > Date: 2008-07-29 13:54 >>>>>>> remote: > >>>>>>> remote: > 6710791: Remove files or build from source:maf-1_0.jar, >>>>>>> jlfg-1_0.jar >>>>>>> remote: > Summary: Removed maf-1_0.jar and jlfg-1_0.jar files. >>>>>>> remote: > Reviewed-by: poonam, jjh >>>>>>> remote: >>>>>>> remote: Bugid 6710791 already used in this repository, in revision 20 >>>>>>> remote: >>>>>>> remote: > Changeset: 360:fa4d1d240383 >>>>>>> remote: > Author: never >>>>>>> remote: > Date: 2008-08-26 15:49 >>>>>>> remote: > >>>>>>> remote: > 6741642: bad enum definition in ciTypeFlow.hpp >>>>>>> remote: > Reviewed-by: rasbold, martin >>>>>>> remote: > Contributed-by: doko at ubuntu.com >>>>>>> remote: >>>>>>> remote: Bugid 6741642 already used in this repository, in revision 22 >>>>>>> remote: >>>>>>> remote: > Changeset: 589:748572b86af6 >>>>>>> remote: > Author: never >>>>>>> remote: > Date: 2009-04-07 14:46 >>>>>>> remote: > >>>>>>> remote: > 6636360: compiler/6595044/Main.java test fails with 64bit >>>>>>> java on solaris-sparcv9 with SIGSEGV >>>>>>> remote: > Reviewed-by: kvn, twisti >>>>>>> remote: >>>>>>> remote: Bugid 6636360 already used in this repository, in revision 29 >>>>>>> remote: >>>>>>> remote: abort: pretxnchangegroup.0.jcheck hook failed >>>>>>> remote: transaction abort! >>>>>>> remote: rollback completed >>>>>>> abort: unexpected response: empty string >>>>>>> >>>>>>> Is there a way of getting it to ignore these for this one push? I >>>>>>> don't know of a way to just pull out these nine changesets from the >>>>>>> 555 waiting to go... >>>>>>> >>>>>>> >>>>>>> >>>>>> I think they would need to be added to the jcheck whitelist for all >>>>>> time- >>>>>> but that is more of a question for Mark or Kelly. >>>>>> >>>>>> Tim >>>>>> >>>>>> >>>>>> >>>>>> >>>>> The early revisions (20, 32) are from OpenJDK6 which was rebased to >>>>> allow HotSpot patches to be applied on top. So what happened here is >>>>> that, as the fixes were already applied to OpenJDK6, the new >>>>> changesets pulled in by the merge will be no-ops but still exist to >>>>> keep the change history accurate. >>>>> >>>>> I think we just need a way of disabling this check. OpenJDK6 already >>>>> has whitespace and comment checks turned to lax. See .jcheck: >>>>> http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/0282bf49b0f6. There >>>>> may already be an option for this bugid check too, but I have no idea >>>>> what the format of that file is. >>>>> >>>>> >>>>> >>>> Andrew, can you please try your push again? >>>> >>>> I chatted with Mark and the OpenJDK 6 HotSpot Mercurial repository should >>>> be >>>> configured to do lax checking on the bug ids. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> >>>> >>> Sorry, same failure still occurs :( >>> >>> I didn't see any changes to .jcheck, which I would assume are needed >>> to fix this (mr added one for the lax comments with the rebase). >>> >>> >> *sigh* >> >> Okay; I'll chat with Mark again to get to the bottom of this. >> >> -Joe >> >> > > Any further news? Can we not just turn off jcheck for jdk6? > I spoke with Mark R. and he is working on a jcheck fix to allow your change to go back. -Joe From vladimir.kozlov at sun.com Wed Aug 26 13:17:22 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 26 Aug 2009 20:17:22 +0000 Subject: hg: hsx/hsx16/baseline: 6827605: new String intrinsics may prevent EA scalar replacement Message-ID: <20090826201724.D1EE912601@hg.openjdk.java.net> Changeset: e502d7524e3a Author: kvn Date: 2009-08-26 10:46 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/e502d7524e3a 6827605: new String intrinsics may prevent EA scalar replacement Summary: don't use SSE42 string indexOf intrinsic if it is called for new object which could be scalar replaced. Reviewed-by: never ! src/share/vm/opto/library_call.cpp From Thomas.Rodriguez at Sun.COM Wed Aug 26 14:51:01 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 26 Aug 2009 14:51:01 -0700 Subject: Review request: Zero assembler port of HotSpot In-Reply-To: <20090825111221.GA3512@redhat.com> References: <20090817143251.GB3394@redhat.com> <20090825111221.GA3512@redhat.com> Message-ID: On Aug 25, 2009, at 4:12 AM, Gary Benson wrote: > Hi Tom, > > Tom Rodriguez wrote: >> Some generic comments first. The normal hotspot style is for the { >> to being always be on the same line instead of having a break in >> between. Many of the new files put a line break in between. > > Tqhis dates back from when I originally started work on all this. > Back then the i486 and amd64 ports were separate, and the amd64 > port had a different coding style from the others. I followed the > amd64 convention thinking that, because it was the newest, it was > most likely to be right (Oops!) Would you like me to reformat it? The original parts of amd64 were done with different formatting than is the standard and we've been gradually fixing it as we've gone along. While we don't have a strictly specified coding standard there are a few constants. 2 character indentation, mixed case type names, lowercase with underscores for fields and methods, trailing brace on same line. There are obvious counter examples like all the oop types start with lowercase but that the preferred style. > >> I don't really like the introduction of the CORE_BUILD define. It >> seems orthogonal to the normal way of selecting builds. Also zero >> is a core-like build but it's not really core so reusing core for >> the build directory doesn't seem right. > > Can you elaborate on this? From the Makefiles I got the impression > that what "core" meant was "everything but the compiler": is that not > correct? Originally core was interpreter only with nothing required by the compilers included at all. Core was a bit of a pain to maintain so we demoted it to interpreter only without the compiler itself. Even your vm version changes made a distinction between Core and Zero vm. Maybe it's acceptable that the name is linux_zero_core but it seems aberrant to me. > >> What's going to happen when shark is added? > > To build Zero without Shark you set ZERO_BUILD=true and > CORE_BUILD=true. > To build Zero with Shark you set ZERO_BUILD=true and SHARK_BUILD=true. > So CORE_BUILD=true is used only when you're building interpreter-only. Except that we don't currently need CORE_BUILD to build core so I don't quote understand it's addition. > >> I guess I would expect the build directories to look like >> linux_i486_zero instead of linux_zero_core which is what I think >> you'd currently get. > > I originally tried doing it that way, but it was next to impossible. > The modified Makefiles treat "zero" as the architecture of the build > (ie a lot of the various $*ARCH variables are set to "zero"). When > you're building with Shark you get linux_zero_shark. But the build directory seem pretty orthogonal to everything else why is it hard to make this work? > Note that this only a build-time thing; the JDK you get at the end > will have its architecture-dependent stuff in a directory that matches > the name of the platform (ie i386, sparc, ppc, etc). of course. > >> Is there some reason you can't allow ARCH_DATA_MODEL to be specified >> directly instead of adding ZERO_BITSPERWORD? And couldn't the same >> be done with ZERO_ENDIANNESS being replaced with ENDIANNESS? I'd >> prefer to generalize the makefiles instead of adding exceptions for >> zero. Maybe ZERO_LIBARCH could be handled similarly, though in at >> least one case we're inconsistent in our use of x86 vs. i386. > > I'm pretty sure these could be changed, the first two at any rate. That would be better. > >> Can you rename method_entry_t to something like MethodEntryFunc? > > Sure. > >> I'm surprised by the amount of stubs you have. Presumably these are >> only because of virtuals for types you don't use? > > There's virtuals in there, yes, but a lot of them are simply ordinary > methods that are referenced by other code that doesn't get used when > you build with Zero. I toyed with the idea of replacing all the > calls to Unimplemented with calls to ShouldNotCallThis, just to make > the point that they aren't used. What do you think? ShouldNotCallThis() seems more accurate. > >> Wouldn't it be better to ifndef ZERO the files that aren't needed? >> I'm assuming it's not a huge number of files, something like >> assembler, stubRoutines, stubGenerator and maybe some others? Maybe >> that gets into a rathole? > > I'm not sure what you mean by "ifndef ZERO the files that aren't > needed"... It seems like part of the reason for stubbing so much out is to deal with source files that you aren't actually using. Wouldn't it be better to just leave them out of the build? This could either be done by ifndef'ing ZERO the contents of the cpp or hpps. The way this has been managed for other kinds targets is through having alternate includeDB_* files. Back when core was really the interpreter only we were split into includeDB_core and includeDB_ci where ci was the compiler code support. Maybe to properly support zero we should make a split. Anyway, I'm not sure it's worth bothering with at the moment. The amount of stubbing isn't huge but it could make it easy to break zero. > >> There's something unsatisfying about the structure of these changes >> that I can't put my finger on. Maybe it's that zero files end up >> containing both architecture independent and architecture dependent >> stuff. I know that's a pretty useless comment and I'm not sure what >> to do about it. Maybe you have some thoughts on this? Anyway, >> unless I can come up with something concrete doesn't worry about >> this. > > Ok. > >> Also I only looked at the hotspot pieces so someone familiar with the >> other parts will have to review those before they can be committed. > > Sure. > >> hotspot/make/Makefile >> >> Don't reuse C2_BASE_DIR: >> >> CORE_BASE_DIR=$(OUTPUTDIR)/$(VM_PLATFORM)_core > > Ok, should be simple. > >> hotspot/make/linux/makefiles/buildtree.make >> >> ZERO_ARCH_DATA_MODEL instead of ZERO_BITSPERWORD ? > > Or just ARCH_DATA_MODEL as you said before. Yes. That would be preferred. > >> hotspot/make/linux/makefiles/vm.make >> >> remove the extra def of STATIC_CXX > > Ah, missed that :) > >> hotspot/src/share/vm/runtime/icache.cpp >> >> Why are you ifdefing this code instead of providing an empty >> implementation? > > I think it turned out neater than trying to fudge call_flush_stub to > pass the guarantee that the first call was for the flush stub itself. > I can try and do it that way if you like? It seems better to handle this as a zero problem instead of ifdef'ing the core. The other way to look at it is, if there's no generated code to be flushed why are we calling flush? > >> As an aside, I'm not sure it's safe to not provide an implementation >> of this at all. Even the installation of newly generated code >> requires an icache flush, otherwise you might just see garbage >> instead of the code you actually generated. Is shark handling this >> differently? > > It's safe because there is never any actual code in codebuffers in > Zero or Shark. In Zero everything that's executed is code compiled by > the C++ compiler; in Shark, the cache invalidation is done by LLVM. Ok. > >> hotspot/src/share/vm/runtime/jniHandles.hpp >> >> What's the purpose of promoting clear() to protected in >> JNIHandleBlock? >> There are no subclasses of JNIHandle that I can see. It seems like >> only >> the friend declaration is needed and I don't think you need to >> ifdef it. >> It seems reasonable to allow CppInterpreter access to that. > > What should I do, just make clear public? Just leave in the friend but without an ifdef. > >> hotspot/src/share/vm/runtime/signature.hpp >> >> I'm ok with these change as is but it's unfortunate that there are >> ifdefs here at all. Any ideas how to restructure this to eliminate >> them completely? > > It should be possible to remove them, but it would require the > implementation of pass_float for i486 and sparc (which currently > pass floats as ints). Shall I do this? It might be best to save it for another day instead of cluttering up your change. >> hotspot/src/share/vm/utilities/vmError.cpp >> >> The direct inclusion of stackPrinter_zero.hpp isn't very nice and >> the scattered ifdef to support it's use are somewhat ugly. Is there >> some reason the stack printing for zero can't be integrated better >> into the existing printing logic? > > I'll look into this. > >> src/cpu/zero/vm/assembler_zero.cpp >> >> Why do some functions like code_fill_byte have implementations? >> Shouldn't they be Unimplemented()? > > Everything with an implementation is used somewhere by something. > For example, code_fill_byte is used by CodeBuffer::relocate_code_to > to clear any padding left after whatever was in the codebuffer. So what actually ends up in a code buffer with shark if not code? > >> src/cpu/zero/vm/assembler_zero.hpp >> >> Can you move the include block to the beginning of the file. > > Sure. Is there a better place I can include those files though? > I was never particularly happy with having them in that file. Well you might move them closer to their real uses. Maybe cppInterpreter_zero.hpp? I think it depends on how broadly it really needs to be included. If you can get away with forward declaring the types and keep the dependencies in a single cpp that would be even better. > >> src/cpu/zero/vm/bytecodeInterpreter_zero.hpp >> >> what's the purpose of the LOTS_OF_REGS define? There's no reference >> to it anywhere else. > > It's used in bytecodeInterpreter.cpp: > > #ifdef LOTS_OF_REGS > register JavaThread* THREAD = istate->thread(); > register volatile jbyte* BYTE_MAP_BASE = _byte_map_base; > #else > #undef THREAD > #define THREAD istate->thread() > #undef BYTE_MAP_BASE > #define BYTE_MAP_BASE _byte_map_base > #endif Ah thanks. I was looking at your patch and not at the rest of workspace. Bad name but oh well. > >> hotspot/src/cpu/zero/vm/frame_zero.hpp >> >> Shouldn't is_deoptimizer_frame be is_deoptimized_frame? > > I'll change it. > >> hotspot/src/cpu/zero/vm/frame_zero.inline.hpp >> >> I think you should be calling find_blob_unsafe instead of find_blob >> as the other frame code does. > > Ok. > > Thanks for looking into this for me. I apologize for the wait time on this. tom > > Cheers, > Gary > > -- > http://gbenson.net/ From vladimir.kozlov at sun.com Wed Aug 26 15:33:23 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 26 Aug 2009 22:33:23 +0000 Subject: hg: hsx/hsx16/baseline: 6875866: Intrinsic for String.indexOf() is broken on x86 with SSE4.2 Message-ID: <20090826223326.6D93412627@hg.openjdk.java.net> Changeset: 9f00229d78ce Author: kvn Date: 2009-08-26 12:54 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/9f00229d78ce 6875866: Intrinsic for String.indexOf() is broken on x86 with SSE4.2 Summary: Start rescan from the next element after the previous match. Reviewed-by: never ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad + test/compiler/6875866/Test.java From Thomas.Rodriguez at Sun.COM Wed Aug 26 15:55:12 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 26 Aug 2009 15:55:12 -0700 Subject: SA and disassemblers Message-ID: <147E5C84-EC8D-4628-82CE-33F815AE888D@sun.com> One of the limitations of the current SA is that it doesn't have a disassembler for amd64 which makes looking at 64 bit cores somewhat challenging. Instead of trying to implement a full disassembler for x64 in Java I think we should switch the SA to using hsdis-arch for the decoding. It requires a minor extension to the decode_instructions interface so that we can disassemble a buffer of code that's not physically located where the code came from. I've got a working version of this that also fixes the printing to match up better with what the JVM itself prints. I was planning on blowing away the other disassemblers completely because they don't really fit into the new model. I thought I'd float this before finishing it to see if there are any concerns. The initial webrev is at http://cr.openjdk.java.net/~never/sadis . This includes building the SA with source 1.5 to allow use of printf which will probably be pushed separately. tom From jon.masamitsu at sun.com Wed Aug 26 18:02:42 2009 From: jon.masamitsu at sun.com (jon.masamitsu at sun.com) Date: Thu, 27 Aug 2009 01:02:42 +0000 Subject: hg: hsx/hsx16/baseline: 6798898: CMS: bugs related to class unloading Message-ID: <20090827010245.DEE881263C@hg.openjdk.java.net> Changeset: c41db48fadd5 Author: jmasa Date: 2009-08-26 15:43 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/c41db48fadd5 6798898: CMS: bugs related to class unloading Summary: Override should_remember_klasses() and remember_klass() as needed. Reviewed-by: ysr, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.inline.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/referenceProcessor.cpp From doko at ubuntu.com Thu Aug 27 03:55:55 2009 From: doko at ubuntu.com (Matthias Klose) Date: Thu, 27 Aug 2009 12:55:55 +0200 Subject: [patch] Adding stack markings to the x86 assembly for not using executable stack Message-ID: <4A96663B.1040109@ubuntu.com> This was reported as https://edge.launchpad.net/bugs/409736 Java is marked to have an executable stack[1]. This is potentially dangerous, and is simply an oversight from one of the compiled assembly files. Adding stack markings to the assembly solves the issue. sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java passes both stock and and with non-exec-stack. gcc -fstack-protector is the default on Ubuntu. I'd like to see this patch for the IcedTea 1.6 release as well. Matthias -------------- next part -------------- A non-text attachment was scrubbed... Name: p2.diff Type: text/x-diff Size: 1535 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090827/f82588b0/attachment.bin From gnu_andrew at member.fsf.org Thu Aug 27 04:04:07 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 27 Aug 2009 12:04:07 +0100 Subject: [patch] Adding stack markings to the x86 assembly for not using executable stack In-Reply-To: <4A96663B.1040109@ubuntu.com> References: <4A96663B.1040109@ubuntu.com> Message-ID: <17c6771e0908270404t3554158cka2afe14cd636f572@mail.gmail.com> 2009/8/27 Matthias Klose : > This was reported as https://edge.launchpad.net/bugs/409736 > > Java is marked to have an executable stack[1]. This is potentially > dangerous, and is simply an oversight from one of the compiled assembly > files. Adding stack markings to the assembly solves the issue. > > sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java passes > both stock and and with non-exec-stack. > > gcc -fstack-protector is the default on Ubuntu. I'd like to see this patch > for the IcedTea 1.6 release as well. > > ?Matthias > I've heard about this issue before from Gentoo users and the fix, if it truly is this simple, would be good to have. Are you sending this patch upstream? It would be good to have some feedback from the HotSpot developers before we commit this for a release. Does this affect SPARC too? -- 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 Thu Aug 27 08:52:59 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 27 Aug 2009 16:52:59 +0100 Subject: Fwd: [PATCH FOR REVIEW]: Make source/target options explicit for CORBA bootstrap tools In-Reply-To: <814FBE93-D15C-490B-9D9F-8ECDE86AE733@Sun.COM> References: <17c6771e0908180524j50fc9d85q753cebc0e9587d3d@mail.gmail.com> <01F1CCA5-2245-4513-BC63-18FE2A48FEE6@sun.com> <17c6771e0908180913t4ee9adfcud1aa3b1fa3986d7d@mail.gmail.com> <17c6771e0908191610w11b584b9xb53020fa87f58ba@mail.gmail.com> <4A8C87B6.2040509@sun.com> <17c6771e0908200548o7d9f0crfbfb96bb1aef97ed@mail.gmail.com> <17c6771e0908270353s1667f85ci20fbfede67657d56@mail.gmail.com> <814FBE93-D15C-490B-9D9F-8ECDE86AE733@Sun.COM> Message-ID: <17c6771e0908270852yf99b40ewdbe3ab5514b18c9@mail.gmail.com> The patch http://cr.openjdk.java.net/~andrew/ecj/02/webrev.02/ syncs the CORBA Defs-java.gmk to match the JDK version. The javac changes have already been approved by Jonathon (see below). Does the addition to support USE_HOTSPOT_INTERPRETER_MODE look ok? If so, I'll push the patch. Thanks. ---------- Forwarded message ---------- From: Jonathan Gibbons Date: 2009/8/27 Subject: Re: [PATCH FOR REVIEW]: Make source/target options explicit for CORBA bootstrap tools To: Andrew John Hughes Cc: build-dev at openjdk.java.net On Aug 27, 2009, at 3:53 AM, Andrew John Hughes wrote: > 2009/8/20 Andrew John Hughes : >> >> 2009/8/20 Jonathan Gibbons : >>> >>> Andrew John Hughes wrote: >>> >>> 2009/8/18 Andrew John Hughes : >>> >>> >>> 2009/8/18 Jonathan Gibbons : >>> >>> >>> Andrew, >>> >>> If this is a patch for jdk7, it does not appear to be a patch to a recent >>> copy >>> of 7. >>> >>> >>> It's against b69 which is the latest release (from Friday). ?The >>> patches are against the IcedTea forest so builds can be tested with >>> IcedTea as well. >>> >>> Specifically, you do not seem to have the recent changeset ?to set >>> >>> >>> the source/target used to compile JDK to 7. [1] >>> >>> >>> >>> Er... yes I do: >>> >>> # Add the source level >>> LANGUAGE_VERSION = -source 7 >>> JAVACFLAGS ?+= $(LANGUAGE_VERSION) >>> >>> # Add the class version we want >>> TARGET_CLASS_VERSION = 7 >>> CLASS_VERSION = -target $(TARGET_CLASS_VERSION) >>> JAVACFLAGS ?+= $(CLASS_VERSION) >>> JAVACFLAGS ?+= -encoding ascii >>> JAVACFLAGS ?+= -classpath $(BOOTDIR)/lib/tools.jar >>> JAVACFLAGS ?+= $(OTHER_JAVACFLAGS) >>> >>> but these only cover the rt classes and not the bootstrap classes. >>> >>> >>> >>> While your patch does not directly conflict with any edits in that patch, >>> and >>> while the effect of your patch looks OK, in that patch I was extending the >>> precedent of TARGET_CLASS_VERSION to have an explicit macro for >>> (just) the version number, so that it is easy to change the value of (just) >>> the version number from the command line. >>> >>> With that in mind, I would suggest something like the following for your >>> patch: >>> >>> BOOT_SOURCE_LANGUAGE_VERSION = 6 >>> BOOT_TARGET_CLASS_VERSION = 6 >>> BOOT_JAVACFLAGS ?+= -encoding ascii -source $(BOOT_SOURCE_LANGUAGE_VERSION) >>> -target $(BOOT_TARGET_CLASS_VERSION) >>> >>> >>> >>> I didn't copy this for the 6 changes because I didn't immediately see >>> the point of using variables just for this single use. ?I forgot that >>> it is possible to override these from the command line, so I've update >>> the patch: >>> >>> http://cr.openjdk.java.net/~andrew/ecj/02/webrev.02/ >>> >>> >>> >>> -- Jon >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/compiler-dev/2009-July/001286.html >>> >>> >>> On Aug 18, 2009, at 5:24 AM, Andrew John Hughes wrote: >>> >>> >>> >>> Currently the javac calls for building the bootstrap tools (not the >>> classes for the final JDK, which correctly now use source and target >>> 7) don't set an explicit source and target version. >>> >>> The webrev: >>> >>> http://cr.openjdk.java.net/~andrew/ecj/02/webrev.01/ >>> >>> sets these to 6 explicitly, as happens in the Ant builds performed by >>> langtools/jaxp/jaxws. ?This is noticeable especially when using ecj as >>> the bootstrap javac as it defaults to a version < 1.5, and the build >>> fails. >>> >>> Ok to push? >>> >>> 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 >>> >>> >>> >>> >>> -- >>> 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 >>> >>> >>> >>> Is this version now ok? ?If so, I'll push it to the build gate using >>> the bug ID Kelly allocated for the same fix in JDK. >>> >>> >>> Andrew, >>> >>> I approve your webrev http://cr.openjdk.java.net/~andrew/ecj/02/webrev.02/ >> >> Thanks. ?Pushed this last night: >> http://hg.openjdk.java.net/jdk7/build/corba/rev/8001ba2bf10d >> >>> My earlier confusion was caused by the fact that the corba Makefile is not >>> consistent with the jdk Makefile with respect to the use of >>> SOURCE_LANGUAGE_VERSION. >>> It would be good to (separately) fix that inconsistency, but that does not >>> affect the validity of what you propose here. >>> >> >> Yes, I see what you mean now. ?Here's another webrev: >> >> http://cr.openjdk.java.net/~andrew/consistency/01/webrev.01/ >> >> which should make the two fairly consistent. ?It brings in a lot of >> changes to the version in JDK that seem to have been missed from >> CORBA, namely: >> >> ?* Turning off option outputs on fastdebug builds >> ?* Supporting USE_HOTSPOT_INTERPRETER_MODE >> ?* Supporting JAVAC_MAX_WARNINGS and JAVAC_WARNINGS_FATAL >> ?* The SOURCE_LANGUAGE_VERSION sync above >> ?* Include JAR_JFLAGS in BOOT_JAR_JFLAGS >> >> The following differences remain, which didn't seem appropriate to include: >> >> -JAVACFLAGS ?+= -classpath $(BOOTDIR)/lib/tools.jar >> +JAVACFLAGS ?+= "-Xbootclasspath:$(CLASSBINDIR)" >> ?JAVACFLAGS ?+= $(OTHER_JAVACFLAGS) >> >> ?# Needed for javah >> -JAVAHFLAGS += -classpath $(CLASSBINDIR) >> +JAVAHFLAGS += -bootclasspath $(CLASSBINDIR) >> >> I wasn't sure of the pros/cons of these changes but can easy add them if needed. >> >>> -- Jon >>> >> >> >> >> -- >> 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 >> > > Does this change look ok? Can I push it? > > 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 Andrew, The changes regarding flags for javac look OK. ?I can't speak to the Hotspot options. -- Jon -- 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 kees at ubuntu.com Thu Aug 27 09:22:35 2009 From: kees at ubuntu.com (Kees Cook) Date: Thu, 27 Aug 2009 09:22:35 -0700 Subject: [patch] Adding stack markings to the x86 assembly for not using executable stack In-Reply-To: <4A96663B.1040109@ubuntu.com> References: <4A96663B.1040109@ubuntu.com> Message-ID: <20090827162235.GI10947@outflux.net> Hi, On Thu, Aug 27, 2009 at 12:55:55PM +0200, Matthias Klose wrote: > This was reported as https://edge.launchpad.net/bugs/409736 > > Java is marked to have an executable stack[1]. This is potentially > dangerous, and is simply an oversight from one of the compiled > assembly files. Adding stack markings to the assembly solves the > issue. > > sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java > passes both stock and and with non-exec-stack. > > gcc -fstack-protector is the default on Ubuntu. I'd like to see this > patch for the IcedTea 1.6 release as well. Just to clarify: these stack markings have to do with the memory protections[1] for every Java's invocation (and is not related to -fstack-protector). For systems with NX hardware (or NX-emulation patches) this improves the overall security in Java against exploitable of memory corruption bugs. If these patches are not okay, we can also set ASFLAGS to include "-Wa,--noexecstack". Thanks, -Kees [1] https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks -- Kees Cook Ubuntu Security Team From kees at ubuntu.com Thu Aug 27 09:25:42 2009 From: kees at ubuntu.com (Kees Cook) Date: Thu, 27 Aug 2009 09:25:42 -0700 Subject: [patch] Adding stack markings to the x86 assembly for not using executable stack In-Reply-To: <17c6771e0908270404t3554158cka2afe14cd636f572@mail.gmail.com> References: <4A96663B.1040109@ubuntu.com> <17c6771e0908270404t3554158cka2afe14cd636f572@mail.gmail.com> Message-ID: <20090827162542.GJ10947@outflux.net> Hi Andrew, On Thu, Aug 27, 2009 at 12:04:07PM +0100, Andrew John Hughes wrote: > 2009/8/27 Matthias Klose : > > This was reported as https://edge.launchpad.net/bugs/409736 > > > > Java is marked to have an executable stack[1]. This is potentially > > dangerous, and is simply an oversight from one of the compiled assembly > > files. Adding stack markings to the assembly solves the issue. > > > > sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java passes > > both stock and and with non-exec-stack. > > > > gcc -fstack-protector is the default on Ubuntu. I'd like to see this patch > > for the IcedTea 1.6 release as well. > > > > ?Matthias > > > > I've heard about this issue before from Gentoo users and the fix, if > it truly is this simple, would be good to have. The question tends to be one of portability. In cases were non-gcc is used, ifdef's need to be built around the flag line. I can provide some examples, if needed. > Are you sending this patch upstream? It would be good to have some > feedback from the HotSpot developers before we commit this for a > release. > > Does this affect SPARC too? I'm not familiar with SPARC hardware, but if it supports "execute" memory protections, then it is a valuable change there too. It it doesn't, it won't hurt anything, IIUC. -Kees -- Kees Cook Ubuntu Security Team From gnu_andrew at member.fsf.org Thu Aug 27 10:01:06 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 27 Aug 2009 18:01:06 +0100 Subject: [patch] Adding stack markings to the x86 assembly for not using executable stack In-Reply-To: <20090827162542.GJ10947@outflux.net> References: <4A96663B.1040109@ubuntu.com> <17c6771e0908270404t3554158cka2afe14cd636f572@mail.gmail.com> <20090827162542.GJ10947@outflux.net> Message-ID: <17c6771e0908271001i4e32911awf0f0b1e8c6eba726@mail.gmail.com> 2009/8/27 Kees Cook : > Hi Andrew, > > On Thu, Aug 27, 2009 at 12:04:07PM +0100, Andrew John Hughes wrote: >> 2009/8/27 Matthias Klose : >> > This was reported as https://edge.launchpad.net/bugs/409736 >> > >> > Java is marked to have an executable stack[1]. This is potentially >> > dangerous, and is simply an oversight from one of the compiled assembly >> > files. Adding stack markings to the assembly solves the issue. >> > >> > sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java passes >> > both stock and and with non-exec-stack. >> > >> > gcc -fstack-protector is the default on Ubuntu. I'd like to see this patch >> > for the IcedTea 1.6 release as well. >> > >> > ?Matthias >> > >> >> I've heard about this issue before from Gentoo users and the fix, if >> it truly is this simple, would be good to have. > > The question tends to be one of portability. ?In cases were non-gcc is > used, ifdef's need to be built around the flag line. ?I can provide some > examples, if needed. > I don't see an immediate problem, as they only affect x86/linux and x86_64/linux where the compiler is gcc. >> Are you sending this patch upstream? ?It would be good to have some >> feedback from the HotSpot developers before we commit this for a >> release. >> >> Does this affect SPARC too? > > I'm not familiar with SPARC hardware, but if it supports "execute" memory > protections, then it is a valuable change there too. ?It it doesn't, it > won't hurt anything, IIUC. > > -Kees > > -- > Kees Cook > Ubuntu Security Team > Do you have an SCA, either via Ubuntu or personally? A webrev needs to be prepared against one of the HotSpot forests and posted to hotspot-dev. If this is the compiler, hotspot-comp is appropriate and twisti can review it ;) -- 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 Vladimir.Kozlov at Sun.COM Thu Aug 27 11:10:17 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 27 Aug 2009 11:10:17 -0700 Subject: SA and disassemblers In-Reply-To: <147E5C84-EC8D-4628-82CE-33F815AE888D@sun.com> References: <147E5C84-EC8D-4628-82CE-33F815AE888D@sun.com> Message-ID: <4A96CC09.7020807@sun.com> Tom, It is very nice cleanup. I assume you will fix it for linux and win also. Thanks, Vladimir Tom Rodriguez wrote: > One of the limitations of the current SA is that it doesn't have a > disassembler for amd64 which makes looking at 64 bit cores somewhat > challenging. Instead of trying to implement a full disassembler for x64 > in Java I think we should switch the SA to using hsdis-arch for the > decoding. It requires a minor extension to the decode_instructions > interface so that we can disassemble a buffer of code that's not > physically located where the code came from. I've got a working version > of this that also fixes the printing to match up better with what the > JVM itself prints. I was planning on blowing away the other > disassemblers completely because they don't really fit into the new > model. I thought I'd float this before finishing it to see if there are > any concerns. The initial webrev is at > http://cr.openjdk.java.net/~never/sadis. This includes building the SA > with source 1.5 to allow use of printf which will probably be pushed > separately. > > tom From John.Coomes at sun.com Thu Aug 27 11:20:45 2009 From: John.Coomes at sun.com (John Coomes) Date: Thu, 27 Aug 2009 11:20:45 -0700 Subject: SA and disassemblers In-Reply-To: <147E5C84-EC8D-4628-82CE-33F815AE888D@sun.com> References: <147E5C84-EC8D-4628-82CE-33F815AE888D@sun.com> Message-ID: <19094.52861.212711.66754@sun.com> Tom Rodriguez (Thomas.Rodriguez at Sun.COM) wrote: > One of the limitations of the current SA is that it doesn't have a > disassembler for amd64 which makes looking at 64 bit cores somewhat > challenging. Instead of trying to implement a full disassembler for > x64 in Java I think we should switch the SA to using hsdis-arch for > the decoding. It requires a minor extension to the > decode_instructions interface so that we can disassemble a buffer of > code that's not physically located where the code came from. I've got > a working version of this that also fixes the printing to match up > better with what the JVM itself prints. I was planning on blowing > away the other disassemblers completely because they don't really fit > into the new model. I thought I'd float this before finishing it to > see if there are any concerns. > ... Only concern is hsdis on windows. I haven't tried it, but the hsdis/README indicates it's a pain to get it built on windows, recommending a cross-compile on linux as the best alternative. Is that still true? -John From Thomas.Rodriguez at Sun.COM Thu Aug 27 11:23:06 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 27 Aug 2009 11:23:06 -0700 Subject: SA and disassemblers In-Reply-To: <19094.52861.212711.66754@sun.com> References: <147E5C84-EC8D-4628-82CE-33F815AE888D@sun.com> <19094.52861.212711.66754@sun.com> Message-ID: <9CBF7784-BA35-497B-BFA3-0726F6CE1555@Sun.COM> On Aug 27, 2009, at 11:20 AM, John Coomes wrote: > Tom Rodriguez (Thomas.Rodriguez at Sun.COM) wrote: >> One of the limitations of the current SA is that it doesn't have a >> disassembler for amd64 which makes looking at 64 bit cores somewhat >> challenging. Instead of trying to implement a full disassembler for >> x64 in Java I think we should switch the SA to using hsdis-arch for >> the decoding. It requires a minor extension to the >> decode_instructions interface so that we can disassemble a buffer of >> code that's not physically located where the code came from. I've >> got >> a working version of this that also fixes the printing to match up >> better with what the JVM itself prints. I was planning on blowing >> away the other disassemblers completely because they don't really fit >> into the new model. I thought I'd float this before finishing it to >> see if there are any concerns. >> ... > > Only concern is hsdis on windows. I haven't tried it, but the > hsdis/README indicates it's a pain to get it built on windows, > recommending a cross-compile on linux as the best alternative. Is > that still true? I built it last time using cross compiling and it worked just fine so I don't see any reason to expect difficulty. tom > > -John > From Thomas.Rodriguez at Sun.COM Thu Aug 27 11:24:45 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 27 Aug 2009 11:24:45 -0700 Subject: SA and disassemblers In-Reply-To: <4A96CC09.7020807@sun.com> References: <147E5C84-EC8D-4628-82CE-33F815AE888D@sun.com> <4A96CC09.7020807@sun.com> Message-ID: <9BD1BA3B-E86C-446E-A1FD-005DEEDED180@Sun.COM> Yes I still have to write the Disassembler native methods for those. I may try to write a shared version of the them so that I don't have to duplicate the sources. tom On Aug 27, 2009, at 11:10 AM, Vladimir Kozlov wrote: > Tom, > > It is very nice cleanup. I assume you will fix it for linux and win > also. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> One of the limitations of the current SA is that it doesn't have a >> disassembler for amd64 which makes looking at 64 bit cores somewhat >> challenging. Instead of trying to implement a full disassembler >> for x64 in Java I think we should switch the SA to using hsdis-arch >> for the decoding. It requires a minor extension to the >> decode_instructions interface so that we can disassemble a buffer >> of code that's not physically located where the code came from. >> I've got a working version of this that also fixes the printing to >> match up better with what the JVM itself prints. I was planning on >> blowing away the other disassemblers completely because they don't >> really fit into the new model. I thought I'd float this before >> finishing it to see if there are any concerns. The initial webrev >> is at http://cr.openjdk.java.net/~never/sadis. This includes >> building the SA with source 1.5 to allow use of printf which will >> probably be pushed separately. >> tom From gbenson at redhat.com Fri Aug 28 04:14:10 2009 From: gbenson at redhat.com (Gary Benson) Date: Fri, 28 Aug 2009 12:14:10 +0100 Subject: Review request: Zero assembler port of HotSpot In-Reply-To: References: <20090817143251.GB3394@redhat.com> <20090825111221.GA3512@redhat.com> Message-ID: <20090828111409.GB3556@redhat.com> Tom Rodriguez wrote: > On Aug 25, 2009, at 4:12 AM, Gary Benson wrote: > > Tom Rodriguez wrote: > > > Some generic comments first. The normal hotspot style is for > > > the { to being always be on the same line instead of having a > > > break in between. Many of the new files put a line break in > > > between. > > > > This dates back from when I originally started work on all this. > > Back then the i486 and amd64 ports were separate, and the amd64 > > port had a different coding style from the others. I followed the > > amd64 convention thinking that, because it was the newest, it was > > most likely to be right (Oops!) Would you like me to reformat it? > > The original parts of amd64 were done with different formatting than > is the standard and we've been gradually fixing it as we've gone > along. While we don't have a strictly specified coding standard > there are a few constants. 2 character indentation, mixed case type > names, lowercase with underscores for fields and methods, trailing > brace on same line. There are obvious counter examples like all the > oop types start with lowercase but that the preferred style. Ok, I'll reformat it for my next webrev. > > > I don't really like the introduction of the CORE_BUILD define. > > > It seems orthogonal to the normal way of selecting builds. Also > > > zero is a core-like build but it's not really core so reusing > > > core for the build directory doesn't seem right. > > > > Can you elaborate on this? From the Makefiles I got the > > impression that what "core" meant was "everything but the > > compiler": is that not correct? > > Originally core was interpreter only with nothing required by the > compilers included at all. Core was a bit of a pain to maintain so > we demoted it to interpreter only without the compiler itself. Even > your vm version changes made a distinction between Core and Zero vm. > Maybe it's acceptable that the name is linux_zero_core but it seems > aberrant to me. > > > > What's going to happen when shark is added? > > > > To build Zero without Shark you set ZERO_BUILD=true and > > CORE_BUILD=true. To build Zero with Shark you set ZERO_BUILD=true > > and SHARK_BUILD=true. So CORE_BUILD=true is used only when you're > > building interpreter-only. > > Except that we don't currently need CORE_BUILD to build core so I > don't quote understand it's addition. I'll see if I can get rid of it. > > > I guess I would expect the build directories to look like > > > linux_i486_zero instead of linux_zero_core which is what I think > > > you'd currently get. > > > > I originally tried doing it that way, but it was next to > > impossible. The modified Makefiles treat "zero" as the > > architecture of the build (ie a lot of the various $*ARCH > > variables are set to "zero"). When you're building with Shark you > > get linux_zero_shark. > > But the build directory seem pretty orthogonal to everything else > why is it hard to make this work? I don't recall (it was a long time ago!) I'll have another go... > > > I'm surprised by the amount of stubs you have. Presumably these > > > are only because of virtuals for types you don't use? > > > > There's virtuals in there, yes, but a lot of them are simply > > ordinary methods that are referenced by other code that doesn't > > get used when you build with Zero. I toyed with the idea of > > replacing all the calls to Unimplemented with calls to > > ShouldNotCallThis, just to make the point that they aren't used. > > What do you think? > > ShouldNotCallThis() seems more accurate. Ok, I'll change it. > > > Wouldn't it be better to ifndef ZERO the files that aren't > > > needed? I'm assuming it's not a huge number of files, something > > > like assembler, stubRoutines, stubGenerator and maybe some > > > others? Maybe that gets into a rathole? > > > > I'm not sure what you mean by "ifndef ZERO the files that aren't > > needed"... > > It seems like part of the reason for stubbing so much out is to deal > with source files that you aren't actually using. Wouldn't it be > better to just leave them out of the build? This could either be > done by ifndef'ing ZERO the contents of the cpp or hpps. The way > this has been managed for other kinds targets is through having > alternate includeDB_* files. Back when core was really the > interpreter only we were split into includeDB_core and includeDB_ci > where ci was the compiler code support. Maybe to properly support > zero we should make a split. Anyway, I'm not sure it's worth > bothering with at the moment. The amount of stubbing isn't huge but > it could make it easy to break zero. XXX > > > hotspot/src/share/vm/runtime/icache.cpp > > > > > > Why are you ifdefing this code instead of providing an empty > > > implementation? > > > > I think it turned out neater than trying to fudge call_flush_stub > > to pass the guarantee that the first call was for the flush stub > > itself. I can try and do it that way if you like? > > It seems better to handle this as a zero problem instead of > ifdef'ing the core. Ok, I'll change it. > The other way to look at it is, if there's no generated code to be > flushed why are we calling flush? There's no generated _code_, but there is data in Zero's codebuffers. See my answer to your next question... > > > src/cpu/zero/vm/assembler_zero.cpp > > > > > > Why do some functions like code_fill_byte have implementations? > > > Shouldn't they be Unimplemented()? > > > > Everything with an implementation is used somewhere by something. > > For example, code_fill_byte is used by CodeBuffer::relocate_code_to > > to clear any padding left after whatever was in the codebuffer. > > So what actually ends up in a code buffer with shark if not code? Shark's code buffers are used for two purposes: - HotSpot's stack walker discovers the nmethod of a compiled frames by finding the code buffer that contains the PC of the frame. It then discovers the BCI of that frame by looking for the PC in that nmethod's oopmap. In Shark, the PC points into some opaque block of code that LLVM generated, so it's not possible to determine the BCI. To get around this, every time Shark generates an oopmap it inserts a byte into the code buffer and (in a roundabout way) supplies the address of that byte to the stack walker as the "PC" of that particular frame. - Because the code that Shark generates is an opaque blob, it's not possible to inline oops into the code because it's not possible to rewrite them. To work around this, Shark stores "inlined" oops in the code buffer along with a relocation so they get rewritten where necessary by the standard HotSpot code. It's not 100% necessary for _Zero_ to have stuff in code buffers -- pre-Shark versions of Zero didn't -- but doing so allows Zero and Shark to share the same calling convention without impacting speed. > > > hotspot/src/share/vm/runtime/signature.hpp > > > > > > I'm ok with these change as is but it's unfortunate that there > > > are ifdefs here at all. Any ideas how to restructure this to > > > eliminate them completely? > > > > It should be possible to remove them, but it would require the > > implementation of pass_float for i486 and sparc (which currently > > pass floats as ints). Shall I do this? > > It might be best to save it for another day instead of cluttering up > your change. Cool. > > > src/cpu/zero/vm/assembler_zero.hpp > > > > > > Can you move the include block to the beginning of the file. > > > > Sure. Is there a better place I can include those files though? > > I was never particularly happy with having them in that file. > > Well you might move them closer to their real uses. Maybe > cppInterpreter_zero.hpp? That file (and most of the other platform-dependent headers) get included like this: cppInterpreter.hpp: class CppInterpreter: public AbstractInterpreter { ... #include "incls/_cppInterpreter_pd.hpp.incl" ... }; so that doesn't work. I think libffi.h is only required in a couple of .cpp files, so I'll try and move that into there. As for the other two... not sure. I'll try and move them somewhere nicer. Cheers, Gary -- http://gbenson.net/ From daniel.daugherty at sun.com Fri Aug 28 12:48:59 2009 From: daniel.daugherty at sun.com (daniel.daugherty at sun.com) Date: Fri, 28 Aug 2009 19:48:59 +0000 Subject: hg: hsx/hsx16/baseline: 2 new changesets Message-ID: <20090828194904.DE17F12773@hg.openjdk.java.net> Changeset: 1760a1cbed36 Author: dcubed Date: 2009-08-11 11:57 -0600 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/1760a1cbed36 6862945: 4/3 conversion of jmethodID to methodOop in JVMTI is too expensive Summary: Refactor JNIHandles::checked_resolve_jmethod_id() into fast and paranoid parts. Reviewed-by: never, alanb ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/runtime/jniHandles.hpp Changeset: 3cfb7ee91f59 Author: dcubed Date: 2009-08-28 11:10 -0600 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/3cfb7ee91f59 Merge From kees at ubuntu.com Fri Aug 28 13:51:47 2009 From: kees at ubuntu.com (Kees Cook) Date: Fri, 28 Aug 2009 13:51:47 -0700 Subject: [patch] Adding stack markings to the x86 assembly for not using executable stack In-Reply-To: <17c6771e0908271001i4e32911awf0f0b1e8c6eba726@mail.gmail.com> References: <4A96663B.1040109@ubuntu.com> <17c6771e0908270404t3554158cka2afe14cd636f572@mail.gmail.com> <20090827162542.GJ10947@outflux.net> <17c6771e0908271001i4e32911awf0f0b1e8c6eba726@mail.gmail.com> Message-ID: <20090828205147.GF10947@outflux.net> Hi, On Thu, Aug 27, 2009 at 06:01:06PM +0100, Andrew John Hughes wrote: > 2009/8/27 Kees Cook : > > On Thu, Aug 27, 2009 at 12:04:07PM +0100, Andrew John Hughes wrote: > >> 2009/8/27 Matthias Klose : > >> > This was reported as https://edge.launchpad.net/bugs/409736 > >> > > >> > Java is marked to have an executable stack[1]. This is potentially > >> > dangerous, and is simply an oversight from one of the compiled assembly > >> > files. Adding stack markings to the assembly solves the issue. > >> > > >> > sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java passes > >> > both stock and and with non-exec-stack. > >> > > >> > gcc -fstack-protector is the default on Ubuntu. I'd like to see this patch > >> > for the IcedTea 1.6 release as well. > >> > > >> > ?Matthias > >> > > >> > >> I've heard about this issue before from Gentoo users and the fix, if > >> it truly is this simple, would be good to have. > > > > The question tends to be one of portability. ?In cases were non-gcc is > > used, ifdef's need to be built around the flag line. ?I can provide some > > examples, if needed. > > > > I don't see an immediate problem, as they only affect x86/linux and > x86_64/linux where the compiler is gcc. Okay, sounds good. > >> Are you sending this patch upstream? ?It would be good to have some > >> feedback from the HotSpot developers before we commit this for a > >> release. > >> > >> Does this affect SPARC too? > > > > I'm not familiar with SPARC hardware, but if it supports "execute" memory > > protections, then it is a valuable change there too. ?It it doesn't, it > > won't hurt anything, IIUC. > > Do you have an SCA, either via Ubuntu or personally? A webrev needs to > be prepared against one of the HotSpot forests and posted to > hotspot-dev. If this is the compiler, hotspot-comp is appropriate and > twisti can review it ;) I haven't signed it yet, but these two (identical) lines are unlikely to be attributable to me anyway, they're common knowledge for this area of work. I'll go figure out what I need to do for the SCA for future stuff, though. Thanks! -Kees -- Kees Cook Ubuntu Security Team From vladimir.kozlov at sun.com Fri Aug 28 15:37:04 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 28 Aug 2009 22:37:04 +0000 Subject: hg: hsx/hsx16/baseline: 6876584: parameters order is incorrect for enc_String_Equals() in x86_32.ad Message-ID: <20090828223708.6F874127CA@hg.openjdk.java.net> Changeset: 74453a25211d Author: kvn Date: 2009-08-28 11:08 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/74453a25211d 6876584: parameters order is incorrect for enc_String_Equals() in x86_32.ad Summary: Fixed parameters order for enc_String_Equals() Reviewed-by: never, twisti ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! test/compiler/6875866/Test.java From daniel.daugherty at sun.com Fri Aug 28 18:37:02 2009 From: daniel.daugherty at sun.com (daniel.daugherty at sun.com) Date: Sat, 29 Aug 2009 01:37:02 +0000 Subject: hg: hsx/hsx16/baseline: 3 new changesets Message-ID: <20090829013709.B76B8127ED@hg.openjdk.java.net> Changeset: 9601152ccfc1 Author: dcubed Date: 2009-08-28 12:25 -0600 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/9601152ccfc1 6875393: 2/3 JNI itable index cache is broken Summary: Add missing initialization of cache size. Reviewed-by: tbell ! src/share/vm/oops/instanceKlass.cpp Changeset: d2d605b757aa Author: dcubed Date: 2009-08-28 14:30 -0600 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/d2d605b757aa Merge ! src/share/vm/oops/instanceKlass.cpp Changeset: 4ca13e754354 Author: dcubed Date: 2009-08-28 15:41 -0700 URL: http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/4ca13e754354 Merge From gnu_andrew at member.fsf.org Sat Aug 29 17:11:29 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Sun, 30 Aug 2009 01:11:29 +0100 Subject: [patch] Adding stack markings to the x86 assembly for not using executable stack In-Reply-To: <20090828205147.GF10947@outflux.net> References: <4A96663B.1040109@ubuntu.com> <17c6771e0908270404t3554158cka2afe14cd636f572@mail.gmail.com> <20090827162542.GJ10947@outflux.net> <17c6771e0908271001i4e32911awf0f0b1e8c6eba726@mail.gmail.com> <20090828205147.GF10947@outflux.net> Message-ID: <17c6771e0908291711k75543e2en81a3236ed8045fd@mail.gmail.com> 2009/8/28 Kees Cook : > Hi, > > On Thu, Aug 27, 2009 at 06:01:06PM +0100, Andrew John Hughes wrote: >> 2009/8/27 Kees Cook : >> > On Thu, Aug 27, 2009 at 12:04:07PM +0100, Andrew John Hughes wrote: >> >> 2009/8/27 Matthias Klose : >> >> > This was reported as https://edge.launchpad.net/bugs/409736 >> >> > >> >> > Java is marked to have an executable stack[1]. This is potentially >> >> > dangerous, and is simply an oversight from one of the compiled assembly >> >> > files. Adding stack markings to the assembly solves the issue. >> >> > >> >> > sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java passes >> >> > both stock and and with non-exec-stack. >> >> > >> >> > gcc -fstack-protector is the default on Ubuntu. I'd like to see this patch >> >> > for the IcedTea 1.6 release as well. >> >> > >> >> > ?Matthias >> >> > >> >> >> >> I've heard about this issue before from Gentoo users and the fix, if >> >> it truly is this simple, would be good to have. >> > >> > The question tends to be one of portability. ?In cases were non-gcc is >> > used, ifdef's need to be built around the flag line. ?I can provide some >> > examples, if needed. >> > >> >> I don't see an immediate problem, as they only affect x86/linux and >> x86_64/linux where the compiler is gcc. > > Okay, sounds good. > >> >> Are you sending this patch upstream? ?It would be good to have some >> >> feedback from the HotSpot developers before we commit this for a >> >> release. >> >> >> >> Does this affect SPARC too? >> > >> > I'm not familiar with SPARC hardware, but if it supports "execute" memory >> > protections, then it is a valuable change there too. ?It it doesn't, it >> > won't hurt anything, IIUC. >> >> Do you have an SCA, either via Ubuntu or personally? A webrev needs to >> be prepared against one of the HotSpot forests and posted to >> hotspot-dev. ?If this is the compiler, hotspot-comp is appropriate and >> twisti can review it ;) > > I haven't signed it yet, but these two (identical) lines are unlikely > to be attributable to me anyway, they're common knowledge for this area > of work. > > I'll go figure out what I need to do for the SCA for future stuff, though. > I agree with you, and we'd have allowed it for GNU Classpath. But Sun require an SCA for everything. > Thanks! > > -Kees > > -- > Kees Cook > Ubuntu Security Team > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Christian.Thalinger at Sun.COM Mon Aug 31 00:09:57 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 31 Aug 2009 09:09:57 +0200 Subject: [patch] Adding stack markings to the x86 assembly for not using executable stack In-Reply-To: <17c6771e0908291711k75543e2en81a3236ed8045fd@mail.gmail.com> References: <4A96663B.1040109@ubuntu.com> <17c6771e0908270404t3554158cka2afe14cd636f572@mail.gmail.com> <20090827162542.GJ10947@outflux.net> <17c6771e0908271001i4e32911awf0f0b1e8c6eba726@mail.gmail.com> <20090828205147.GF10947@outflux.net> <17c6771e0908291711k75543e2en81a3236ed8045fd@mail.gmail.com> Message-ID: <4A9B7745.4020900@Sun.COM> Andrew John Hughes wrote: >>> Do you have an SCA, either via Ubuntu or personally? A webrev needs to >>> be prepared against one of the HotSpot forests and posted to >>> hotspot-dev. If this is the compiler, hotspot-comp is appropriate and >>> twisti can review it ;) >> I haven't signed it yet, but these two (identical) lines are unlikely >> to be attributable to me anyway, they're common knowledge for this area >> of work. >> >> I'll go figure out what I need to do for the SCA for future stuff, though. >> > > I agree with you, and we'd have allowed it for GNU Classpath. > But Sun require an SCA for everything. Yes, please sign the SCA and submit a patch for review. -- Christian