From Vladimir.Kozlov at Sun.COM Mon Dec 1 10:48:03 2008 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 01 Dec 2008 10:48:03 -0800 Subject: C2 Scalar Replacement Behavior? In-Reply-To: References: <4921D585.4050700@sun.com> Message-ID: <49343163.30707@sun.com> Edward Lee wrote: > On Mon, Nov 17, 2008 at 2:35 PM, Vladimir Kozlov > wrote: >> All uses of scalar replaceable object's fields should be replaced >> with values stored into the fields (or with default value 0 if >> there were no stores). > Ah, okay. Thanks. I've been seeing this behavior by setting the > PrintOptoAssembly option for a method through .hotspot_compiler. In > particular, I've been looking at a "pack-and-pass" pattern for short > lifetime objects: > > foo(A,B) { > bar(new pack(A,B)) > } > > Where the optimized asm has the inlined bar() accessing B directly > (foo's param) with +DoEscapeAnalysis instead of dereferencing an extra > pointer of an allocated pack object. > > (Side question, where do I find the structure of Thread::current()? A > quick glance seems to imply [[current() + #68] + #24] is the thread's > allocation bump pointer position and [current() + #76] is perhaps a > allocation watermark where exceeding it slowpaths to > _new_instance_Java. Is this runtime/thread.hpp or is there a simple > way to see what offsets correspond to?) Thread structure is defined in src/share/vm/runtime/thread.hpp Note, PrintOptoAssembly prints a pseudo-assembler code which may hide the actual assembler code to reduce output. The code for next pseudo-assembler code MOV EBX, Thread::current() is in OS/platform specific AD file, for example in src/os_cpu/linux_x86/vm/linux_x86_32.ad it "instruct tlsLoadP" and it uses MacroAssembler::get_thread() in assembler_linux_x86.cpp to generate assembler code. The offsets you see is for TLAB allocation and the offset are defined in thread.hpp (look for TLAB_FIELD_OFFSET macro) and in src/share/vm/memory/threadLocalAllocBuffer.hpp. > >> We have to keep allocations if optimizer was not able to eliminate >> all loads (for example, volatile fields). > So on the way to macro expand deciding if all the loads of the > allocation have been eliminated, the ideal graph has 2 pairs of nodes: > one using the foo's parameter and another using the allocated pack > object's fields. Assuming an allocation can't be scalar replaced, at > what point does the optimizer drop "use param" and go with "use > alloced object?" We keep both. It is safe to keep only fields loads which were not eliminated by Optimizer and "use param" for other fields values since EA determined that the object does not escape. > > When I turn off -DoEscapeAnalysis, I notice that field references are > again field references even though the value is available through the > parameter. Arguably, the field access needs to be there because > potentially another thread might have changed that newly allocated Yes, it is correct. We have to keep loads since we don't know at what point an object may escape without EA. > object's field. Or is it that optimize_memory_chain wouldn't have > decided to use the param without escape analysis? > > Ed Vladimir From mark at klomp.org Mon Dec 1 15:52:15 2008 From: mark at klomp.org (Mark Wielaard) Date: Tue, 02 Dec 2008 00:52:15 +0100 Subject: HotSpot just got Hotter - IcedTea6 support for latest HotSpot In-Reply-To: <17c6771e0812010937w62cbab8bs3e2e4ed7cdefa3b7@mail.gmail.com> References: <17c6771e0812010937w62cbab8bs3e2e4ed7cdefa3b7@mail.gmail.com> Message-ID: <1228175535.22459.165.camel@dijkstra.wildebeest.org> Hi Andrew, I CCed hotspot-dev to see if the hotspot hackers can also provide some feedback (on picking the right hotspot version to ship by default). On Mon, 2008-12-01 at 17:37 +0000, Andrew John Hughes wrote: > I've added two new options to IcedTea6: > > --with-hotspot-build=x > --with-hotspot-src-zip= > > When --with-hotspot-build is given, the build will attempt to use the > specified version of HotSpot. The version numbers are contained in > the new file hotspot.map which maps build numbers to changesets. The > build number is also used in the name of some patches so correct > versions are applied. This may yet be simplified to just do old/new. > Feedback welcome. > > With this patch, the build defaults to using hs14.0b08 (the current > OJ7 HotSpot) and will download this from hg.openjdk.java.net unless > --with-hotspot-src-zip is used. --with-hotspot-build=original or > --without-hotspot-build will disable this and return to the existing > hs10.0b19 version. Wow, this is pretty cool! It should make it much simpler to try out and use a newer hotspot with the stable, openjdk6 based, core. I think that supporting more than 2, lets call them "stable" and "latest", might be a bit ambitious. We risk having to try to keep up with all the different versions and duplicating all our patches against more and more versions. This is also why I CCed hotspot-dev, hopefully they can advise on the best values for "stable" (what is used in update 10 for example?) and "latest" (should be ok, but we wouldn't advise it for production yet). Ideally, we make sure that the "stable" version is the version backported also to openjdk6 itself. Or maybe 3 versions at most "openjdk6 base", "stable/production", "latest"? Encoding the versions in the patch file names is slightly ugly imho. If at all possible try moving them into their own subdirectory. (This is more in general, not particular for your patch, the patches dir is growing at an alarming rate, I guess I should have done the subdir thing myself also for the new xrender patch set.) Also it would be great to have hotspot patches that are just for any version. For example I saw the sparc-ptracefix that is identical for both versions (just a random pick, I didn't actually go over all patches). Note that the openjdk6 hotspot actually contains some tests that aren't in the newer hotspot repo. It would be nice if we never got less tests (currently there are 20, including one icedtea only one - the lucene test). Thanks for doing this. It will be nice to easily plug in newer hotspots. Cheers, Mark From gnu_andrew at member.fsf.org Mon Dec 1 16:10:32 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 2 Dec 2008 00:10:32 +0000 Subject: HotSpot just got Hotter - IcedTea6 support for latest HotSpot In-Reply-To: <1228175535.22459.165.camel@dijkstra.wildebeest.org> References: <17c6771e0812010937w62cbab8bs3e2e4ed7cdefa3b7@mail.gmail.com> <1228175535.22459.165.camel@dijkstra.wildebeest.org> Message-ID: <17c6771e0812011610n1eef51a3qce1e184d94a29f8f@mail.gmail.com> On 01/12/2008, Mark Wielaard wrote: > Hi Andrew, > > I CCed hotspot-dev to see if the hotspot hackers can also provide some > feedback (on picking the right hotspot version to ship by default). > > > On Mon, 2008-12-01 at 17:37 +0000, Andrew John Hughes wrote: > > I've added two new options to IcedTea6: > > > > --with-hotspot-build=x > > --with-hotspot-src-zip= > > > > When --with-hotspot-build is given, the build will attempt to use the > > specified version of HotSpot. The version numbers are contained in > > the new file hotspot.map which maps build numbers to changesets. The > > build number is also used in the name of some patches so correct > > versions are applied. This may yet be simplified to just do old/new. > > Feedback welcome. > > > > With this patch, the build defaults to using hs14.0b08 (the current > > OJ7 HotSpot) and will download this from hg.openjdk.java.net unless > > --with-hotspot-src-zip is used. --with-hotspot-build=original or > > --without-hotspot-build will disable this and return to the existing > > hs10.0b19 version. > > > Wow, this is pretty cool! It should make it much simpler to try out and > use a newer hotspot with the stable, openjdk6 based, core. > > I think that supporting more than 2, lets call them "stable" and > "latest", might be a bit ambitious. We risk having to try to keep up > with all the different versions and duplicating all our patches against > more and more versions. This is also why I CCed hotspot-dev, hopefully > they can advise on the best values for "stable" (what is used in update > 10 for example?) and "latest" (should be ok, but we wouldn't advise it > for production yet). > I had similar thoughts as I was preparing the patch. I think as a team we should keep support for two but maybe leave the infrastructure in place so if anyone else feels the urge they can add more. In that vein, I'll probably rename '14.0b08' to 'latest'. 6u10 ships 11.0b15 which predates hg. It might be in the old svn repositories somewhere, I didn't check your hg work on icedtea.classpath.org. My hope would be that Sun move to this for the original bundle anyway. We can then support that and the latest build fairly easily. The latest has to be support by IcedTea7 anyway (which is what I used to create most of the 14.0b08 patches). > Ideally, we make sure that the "stable" version is the version > backported also to openjdk6 itself. Or maybe 3 versions at most > "openjdk6 base", "stable/production", "latest"? > As I say, I would hope Sun would make the first two equivalent in their bundles but they've already left us with an outdated HotSpot for quite a while (6u10 has been out a bit now). > Encoding the versions in the patch file names is slightly ugly imho. If > at all possible try moving them into their own subdirectory. (This is > more in general, not particular for your patch, the patches dir is > growing at an alarming rate, I guess I should have done the subdir thing > myself also for the new xrender patch set.) > I agree; we should probably make things hierarchical. 'ecj' is probably also worthy of a subdirectory now I've started to split that into separate patches (it was unmanageable as a homogeneous lump). > Also it would be great to have hotspot patches that are just for any > version. For example I saw the sparc-ptracefix that is identical for > both versions (just a random pick, I didn't actually go over all > patches). > Ah ok that is strange because it didn't apply. I only created two variants where the build failed to patch. Perhaps this is due to an ugliness arising from the change of directory structure in 7. In 7, builds end up in build not control/build and HotSpot's build machinery is in hotspot/make not hotspot/build. You'll see I've also had to fix Makefile.am to cope with this when applying Gary's zero work. This may be the only difference in such patches. You are right that ptracefix is identical though - maybe I screwed up somewhere with the original patch. > Note that the openjdk6 hotspot actually contains some tests that aren't > in the newer hotspot repo. It would be nice if we never got less tests > (currently there are 20, including one icedtea only one - the lucene > test). > Yes we need a patch equivalent to the hotspot7 one which is only applied for original builds. I also need to split out the lucene test from the fix. > Thanks for doing this. It will be nice to easily plug in newer hotspots. > :) > Cheers, > > > Mark > > Cheers, -- Andrew :-) 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 Joe.Darcy at Sun.COM Mon Dec 1 17:08:57 2008 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Mon, 01 Dec 2008 17:08:57 -0800 Subject: HotSpot just got Hotter - IcedTea6 support for latest HotSpot In-Reply-To: <17c6771e0812011610n1eef51a3qce1e184d94a29f8f@mail.gmail.com> References: <17c6771e0812010937w62cbab8bs3e2e4ed7cdefa3b7@mail.gmail.com> <1228175535.22459.165.camel@dijkstra.wildebeest.org> <17c6771e0812011610n1eef51a3qce1e184d94a29f8f@mail.gmail.com> Message-ID: <49348AA9.8040504@sun.com> On 12/01/08 04:10 PM, Andrew John Hughes wrote: > On 01/12/2008, Mark Wielaard wrote: > >> Hi Andrew, >> >> I CCed hotspot-dev to see if the hotspot hackers can also provide some >> feedback (on picking the right hotspot version to ship by default). >> >> >> On Mon, 2008-12-01 at 17:37 +0000, Andrew John Hughes wrote: >> > I've added two new options to IcedTea6: >> > >> > --with-hotspot-build=x >> > --with-hotspot-src-zip= >> > >> > When --with-hotspot-build is given, the build will attempt to use the >> > specified version of HotSpot. The version numbers are contained in >> > the new file hotspot.map which maps build numbers to changesets. The >> > build number is also used in the name of some patches so correct >> > versions are applied. This may yet be simplified to just do old/new. >> > Feedback welcome. >> > >> > With this patch, the build defaults to using hs14.0b08 (the current >> > OJ7 HotSpot) and will download this from hg.openjdk.java.net unless >> > --with-hotspot-src-zip is used. --with-hotspot-build=original or >> > --without-hotspot-build will disable this and return to the existing >> > hs10.0b19 version. >> >> >> Wow, this is pretty cool! It should make it much simpler to try out and >> use a newer hotspot with the stable, openjdk6 based, core. >> >> I think that supporting more than 2, lets call them "stable" and >> "latest", might be a bit ambitious. We risk having to try to keep up >> with all the different versions and duplicating all our patches against >> more and more versions. This is also why I CCed hotspot-dev, hopefully >> they can advise on the best values for "stable" (what is used in update >> 10 for example?) and "latest" (should be ok, but we wouldn't advise it >> for production yet). >> >> > > I had similar thoughts as I was preparing the patch. I think as a > team we should keep support for two but maybe leave the infrastructure > in place so if anyone else feels the urge they can add more. In that > vein, I'll probably rename '14.0b08' to 'latest'. > > 6u10 ships 11.0b15 which predates hg. It might be in the old svn > repositories somewhere, I didn't check your hg work on > icedtea.classpath.org. My hope would be that Sun move to this for the > original bundle anyway. We can then support that and the latest build > fairly easily. The latest has to be support by IcedTea7 anyway (which > is what I used to create most of the 14.0b08 patches). > > >> Ideally, we make sure that the "stable" version is the version >> backported also to openjdk6 itself. Or maybe 3 versions at most >> "openjdk6 base", "stable/production", "latest"? >> >> > > As I say, I would hope Sun would make the first two equivalent in > their bundles but they've already left us with an outdated HotSpot for > quite a while (6u10 has been out a bit now). > We will be publishing an OpenJDK 6 source bundle with HotSpot 11 later this week. Since the inception of the OpenJDK 6 code base, I've generally kept the HotSpot published in OpenJDK 6 current with the HotSpot in the currently shipping 6 update release, with some delays as with this HS 10 to HS 11 transition. Going forward, after the Mercurial transition for OpenJDK 6 the HotSpot team has committed to closer sharing of the HotSpot code bases for OpenJDK 6 and the 6 update release: http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-September/000150.html -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20081201/db4086f8/attachment.html From gbenson at redhat.com Tue Dec 2 01:37:23 2008 From: gbenson at redhat.com (Gary Benson) Date: Tue, 2 Dec 2008 09:37:23 +0000 Subject: HotSpot just got Hotter - IcedTea6 support for latest HotSpot In-Reply-To: <1228175535.22459.165.camel@dijkstra.wildebeest.org> References: <17c6771e0812010937w62cbab8bs3e2e4ed7cdefa3b7@mail.gmail.com> <1228175535.22459.165.camel@dijkstra.wildebeest.org> Message-ID: <20081202093722.GA4500@redhat.com> Mark Wielaard wrote: > I think that supporting more than 2, lets call them "stable" and > "latest", might be a bit ambitious. We risk having to try to keep > up with all the different versions and duplicating all our patches > against more and more versions. I'd extend this and say can we not just support one? When Andrew said he was doing this last Thursday, my original thought was "great, we can get rid of all this two-versions-of-HotSpot stuff", so the thought of not only retaining it but possibly adding more is... unpleasant. My biggest issue was that, when there were problems with patches where there were two versions of something -- usually because of a new OpenJDK build -- people would often just fix one version and leave the other. So I'd wake up in the morning and suddenly my stuff wouldn't build and I'd spend all day making a fix that turned out to have already been applied in the "other" HotSpot. This is why I developed Shark out of the main tree fwiw. It was easier for me to deal with a huge dislocation every month or so -- when I was ready for it -- rather than potentially every day. Cheers, Gary -- http://gbenson.net/ From mark at klomp.org Tue Dec 2 02:25:58 2008 From: mark at klomp.org (Mark Wielaard) Date: Tue, 02 Dec 2008 11:25:58 +0100 Subject: HotSpot just got Hotter - IcedTea6 support for latest HotSpot In-Reply-To: <20081202093722.GA4500@redhat.com> References: <17c6771e0812010937w62cbab8bs3e2e4ed7cdefa3b7@mail.gmail.com> <1228175535.22459.165.camel@dijkstra.wildebeest.org> <20081202093722.GA4500@redhat.com> Message-ID: <1228213558.3435.24.camel@dijkstra.wildebeest.org> On Tue, 2008-12-02 at 09:37 +0000, Gary Benson wrote: > Mark Wielaard wrote: > > I think that supporting more than 2, lets call them "stable" and > > "latest", might be a bit ambitious. We risk having to try to keep > > up with all the different versions and duplicating all our patches > > against more and more versions. > > I'd extend this and say can we not just support one? When Andrew said > he was doing this last Thursday, my original thought was "great, we > can get rid of all this two-versions-of-HotSpot stuff", so the thought > of not only retaining it but possibly adding more is... unpleasant. > > My biggest issue was that, when there were problems with patches where > there were two versions of something -- usually because of a new > OpenJDK build -- people would often just fix one version and leave the > other. So I'd wake up in the morning and suddenly my stuff wouldn't > build and I'd spend all day making a fix that turned out to have > already been applied in the "other" HotSpot. This is why I developed > Shark out of the main tree fwiw. It was easier for me to deal with a > huge dislocation every month or so -- when I was ready for it -- rather > than potentially every day. Yeah. So it might be good to better write down the requirements and reasons to make hotspot upgrading easier: - The current hotspot on openjdk6 is just too old, we keep adding more and more backported patches for crasher bugs that we know are fixed in later versions or build fixes for newer/older toolchains on gnu/linux distros (we are carrying about 25 such patches now, excluding the sparc, zero and shark work). - The build setup of hotspot in openjdk6 is different from the main hotspot repo (make versus build). This is causing a lot of the pain of maintaining the zero/non-zero (7b24/6b13) divergences. Andrew tries to make this work a bit easier with his HOTSPOT_MAKE_DIR addition. But ideally we would only support hotspots with the newer build dir setup. - We want an easy mechanism for trying out newer hotspots so you can easily build a newer version and let people try out performance improvements or new features/flags (but on top of the stable 6 core build). I really like this part of Andrew's patch, which lets you select either a hg revision/version number or a prepackaged hotspot src zip. - We want to support the linux/sparc bits (the various icedtea-sparc-*.patches). Some of this is actually already in newer hotspots. - We want to support zero/shark. Ideally without having to have separate sets of ZERO_PATCHES and NON_ZERO_PATCHES (all our NON_ZERO_PATCHES are actually rebases of ZERO_PATCHES to older hotspot versions). This requires a hotspot that includes at a minimum the C++ interpreter. What is the best way to combine all these properties and keep our maintance level as low as possible. Which hotspot version(s) to support by default that make it easy to provide support for all of the above requirements. Did I forget anything? Cheers, Mark From gnu_andrew at member.fsf.org Tue Dec 2 02:27:11 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 2 Dec 2008 10:27:11 +0000 Subject: HotSpot just got Hotter - IcedTea6 support for latest HotSpot In-Reply-To: <20081202093722.GA4500@redhat.com> References: <17c6771e0812010937w62cbab8bs3e2e4ed7cdefa3b7@mail.gmail.com> <1228175535.22459.165.camel@dijkstra.wildebeest.org> <20081202093722.GA4500@redhat.com> Message-ID: <17c6771e0812020227kd5ed588x774db1030220e40d@mail.gmail.com> On 02/12/2008, Gary Benson wrote: > Mark Wielaard wrote: > > I think that supporting more than 2, lets call them "stable" and > > "latest", might be a bit ambitious. We risk having to try to keep > > up with all the different versions and duplicating all our patches > > against more and more versions. > > > I'd extend this and say can we not just support one? When Andrew said > he was doing this last Thursday, my original thought was "great, we > can get rid of all this two-versions-of-HotSpot stuff", so the thought > of not only retaining it but possibly adding more is... unpleasant. > > My biggest issue was that, when there were problems with patches where > there were two versions of something -- usually because of a new > OpenJDK build -- people would often just fix one version and leave the > other. So I'd wake up in the morning and suddenly my stuff wouldn't > build and I'd spend all day making a fix that turned out to have > already been applied in the "other" HotSpot. This is why I developed > Shark out of the main tree fwiw. It was easier for me to deal with a > huge dislocation every month or so -- when I was ready for it -- rather > than potentially every day. > > Cheers, > Gary > > > -- > http://gbenson.net/ > I know what you mean. With IcedTea7, we've actually been supporting 3 versions of HotSpot and each merge of IcedTea6 to IcedTea7 means fixing patches to work with 7 (including the zero stuff). This does simplify things because the default is now the OpenJDK7 HotSpot. This means IcedTea6 and IcedTea7 can use the same HotSpot patches and hopefully you'll bump Zero up to this version too (I've already patched it to at least build in 7, but it really needs a sanity check). Then we are all on the same page at last. Keeping the original around too is basically so we still build something close to what Sun provides. However, if this bitrots because no-one is bothered about using the version of HotSpot in the main tarball, then we can throw them away. But I'd like to see how things develop first before we do that. -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Tue Dec 2 02:40:30 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 2 Dec 2008 10:40:30 +0000 Subject: HotSpot just got Hotter - IcedTea6 support for latest HotSpot In-Reply-To: <1228213558.3435.24.camel@dijkstra.wildebeest.org> References: <17c6771e0812010937w62cbab8bs3e2e4ed7cdefa3b7@mail.gmail.com> <1228175535.22459.165.camel@dijkstra.wildebeest.org> <20081202093722.GA4500@redhat.com> <1228213558.3435.24.camel@dijkstra.wildebeest.org> Message-ID: <17c6771e0812020240j14ea4643t54946456af23b173@mail.gmail.com> On 02/12/2008, Mark Wielaard wrote: > On Tue, 2008-12-02 at 09:37 +0000, Gary Benson wrote: > > Mark Wielaard wrote: > > > I think that supporting more than 2, lets call them "stable" and > > > "latest", might be a bit ambitious. We risk having to try to keep > > > up with all the different versions and duplicating all our patches > > > against more and more versions. > > > > I'd extend this and say can we not just support one? When Andrew said > > he was doing this last Thursday, my original thought was "great, we > > can get rid of all this two-versions-of-HotSpot stuff", so the thought > > of not only retaining it but possibly adding more is... unpleasant. > > > > My biggest issue was that, when there were problems with patches where > > there were two versions of something -- usually because of a new > > OpenJDK build -- people would often just fix one version and leave the > > other. So I'd wake up in the morning and suddenly my stuff wouldn't > > build and I'd spend all day making a fix that turned out to have > > already been applied in the "other" HotSpot. This is why I developed > > Shark out of the main tree fwiw. It was easier for me to deal with a > > huge dislocation every month or so -- when I was ready for it -- rather > > than potentially every day. > > > Yeah. So it might be good to better write down the requirements and > reasons to make hotspot upgrading easier: > > - The current hotspot on openjdk6 is just too old, we keep adding more > and more backported patches for crasher bugs that we know are fixed in > later versions or build fixes for newer/older toolchains on gnu/linux > distros (we are carrying about 25 such patches now, excluding the sparc, > zero and shark work). When I merge this patch, this won't be the default any more. If someone wants to continue to maintain it, then they are welcome to step up and do so. But I expect main dev. effort to go to the OJ7 HotSpot now. > - The build setup of hotspot in openjdk6 is different from the main > hotspot repo (make versus build). This is causing a lot of the pain of > maintaining the zero/non-zero (7b24/6b13) divergences. Andrew tries to > make this work a bit easier with his HOTSPOT_MAKE_DIR addition. But > ideally we would only support hotspots with the newer build dir setup. I don't think it's much more than a name change. > - We want an easy mechanism for trying out newer hotspots so you can > easily build a newer version and let people try out performance > improvements or new features/flags (but on top of the stable 6 core > build). I really like this part of Andrew's patch, which lets you select > either a hg revision/version number or a prepackaged hotspot src zip. Indeed; the HotSpot src zip can be anything you want really. You just have to get the patches to apply :) > - We want to support the linux/sparc bits (the various > icedtea-sparc-*.patches). Some of this is actually already in newer > hotspots. Already handled: if !WITH_ALT_HSBUILD ICEDTEA_PATCHES += \ patches/icedtea-hotspot7-tests.patch \ patches/icedtea-sparc.patch endif The main big SPARC patch is not applied for 7. > - We want to support zero/shark. Ideally without having to have separate > sets of ZERO_PATCHES and NON_ZERO_PATCHES (all our NON_ZERO_PATCHES are > actually rebases of ZERO_PATCHES to older hotspot versions). This > requires a hotspot that includes at a minimum the C++ interpreter. > Are ZERO_PATCHES patches which enable the Zero build (that's what I assumed) or just OJ7 patches? If they are the latter, we should have been applying them to 7. > What is the best way to combine all these properties and keep our > maintance level as low as possible. Which hotspot version(s) to support > by default that make it easy to provide support for all of the above > requirements. Did I forget anything? > I suggest supporting one HotSpot version across both IcedTea6 and 7. I don't see a good reason to go for the slightly newer one Joe plans to package over just using the latest, but it does sound like we will be stuck in the same situation of backporting again. This won't be as new as Gary's b24 one even (which is hs12 IIRC). > Cheers, > > > Mark > > -- Andrew :-) 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 gbenson at redhat.com Tue Dec 2 02:41:41 2008 From: gbenson at redhat.com (Gary Benson) Date: Tue, 2 Dec 2008 10:41:41 +0000 Subject: HotSpot just got Hotter - IcedTea6 support for latest HotSpot In-Reply-To: <17c6771e0812020227kd5ed588x774db1030220e40d@mail.gmail.com> References: <17c6771e0812010937w62cbab8bs3e2e4ed7cdefa3b7@mail.gmail.com> <1228175535.22459.165.camel@dijkstra.wildebeest.org> <20081202093722.GA4500@redhat.com> <17c6771e0812020227kd5ed588x774db1030220e40d@mail.gmail.com> Message-ID: <20081202104141.GD4500@redhat.com> Andrew John Hughes wrote: > This does simplify things because the default is now the OpenJDK7 > HotSpot. This means IcedTea6 and IcedTea7 can use the same HotSpot > patches and hopefully you'll bump Zero up to this version too (I've > already patched it to at least build in 7, but it really needs a > sanity check). Then we are all on the same page at last. If you can get it so that the new icedtea6 builds with some HotSpot 7 then I'll switch over to it for my JCK runs. Cheers, Gary -- http://gbenson.net/ From gnu_andrew at member.fsf.org Tue Dec 2 02:43:30 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 2 Dec 2008 10:43:30 +0000 Subject: HotSpot just got Hotter - IcedTea6 support for latest HotSpot In-Reply-To: <20081202104141.GD4500@redhat.com> References: <17c6771e0812010937w62cbab8bs3e2e4ed7cdefa3b7@mail.gmail.com> <1228175535.22459.165.camel@dijkstra.wildebeest.org> <20081202093722.GA4500@redhat.com> <17c6771e0812020227kd5ed588x774db1030220e40d@mail.gmail.com> <20081202104141.GD4500@redhat.com> Message-ID: <17c6771e0812020243n796e3eaeo748bef7c20a2c813@mail.gmail.com> On 02/12/2008, Gary Benson wrote: > Andrew John Hughes wrote: > > This does simplify things because the default is now the OpenJDK7 > > HotSpot. This means IcedTea6 and IcedTea7 can use the same HotSpot > > patches and hopefully you'll bump Zero up to this version too (I've > > already patched it to at least build in 7, but it really needs a > > sanity check). Then we are all on the same page at last. > > > If you can get it so that the new icedtea6 builds with some HotSpot 7 > then I'll switch over to it for my JCK runs. > > > Cheers, > Gary > > -- > http://gbenson.net/ > That's what I've done. $ /home/andrew/build/icedtea6/bin/java -version java version "1.6.0_0" IcedTea6 1.4-r990fb5e4f060 Runtime Environment (build 1.6.0_0-b13) OpenJDK 64-Bit Server VM (build 14.0-b08, mixed mode) Zero just needs fixing up. -- Andrew :-) 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 mark at klomp.org Tue Dec 2 03:14:32 2008 From: mark at klomp.org (Mark Wielaard) Date: Tue, 02 Dec 2008 12:14:32 +0100 Subject: HotSpot just got Hotter - IcedTea6 support for latest HotSpot In-Reply-To: <17c6771e0812020240j14ea4643t54946456af23b173@mail.gmail.com> References: <17c6771e0812010937w62cbab8bs3e2e4ed7cdefa3b7@mail.gmail.com> <1228175535.22459.165.camel@dijkstra.wildebeest.org> <20081202093722.GA4500@redhat.com> <1228213558.3435.24.camel@dijkstra.wildebeest.org> <17c6771e0812020240j14ea4643t54946456af23b173@mail.gmail.com> Message-ID: <1228216472.3435.33.camel@dijkstra.wildebeest.org> Hi Andrew, On Tue, 2008-12-02 at 10:40 +0000, Andrew John Hughes wrote: > > - We want to support zero/shark. Ideally without having to have separate > > sets of ZERO_PATCHES and NON_ZERO_PATCHES (all our NON_ZERO_PATCHES are > > actually rebases of ZERO_PATCHES to older hotspot versions). This > > requires a hotspot that includes at a minimum the C++ interpreter. > > > Are ZERO_PATCHES patches which enable the Zero build (that's what I > assumed) or just OJ7 patches? If they are the latter, we should have > been applying them to 7. They are, plus the integration of the newer hotspot (icedtea-hotspot-6b12-7b24), plus forward ported versions of the NON_ZERO_PATCHES that wouldn't apply directly (icedtea-signed-types.patch/icedtea-signed-types-hot6.patch), plus some bug fixes (some of which are already in newer hotspots, icedtea-hotspot-citypeflow.patch). Cheers, Mark From gbenson at redhat.com Tue Dec 2 03:25:31 2008 From: gbenson at redhat.com (Gary Benson) Date: Tue, 2 Dec 2008 11:25:31 +0000 Subject: HotSpot just got Hotter - IcedTea6 support for latest HotSpot In-Reply-To: <17c6771e0812020243n796e3eaeo748bef7c20a2c813@mail.gmail.com> References: <17c6771e0812010937w62cbab8bs3e2e4ed7cdefa3b7@mail.gmail.com> <1228175535.22459.165.camel@dijkstra.wildebeest.org> <20081202093722.GA4500@redhat.com> <17c6771e0812020227kd5ed588x774db1030220e40d@mail.gmail.com> <20081202104141.GD4500@redhat.com> <17c6771e0812020243n796e3eaeo748bef7c20a2c813@mail.gmail.com> Message-ID: <20081202112531.GF4500@redhat.com> Andrew John Hughes wrote: > On 02/12/2008, Gary Benson wrote: > > Andrew John Hughes wrote: > > > This does simplify things because the default is now the > > > OpenJDK7 HotSpot. This means IcedTea6 and IcedTea7 can use the > > > same HotSpot patches and hopefully you'll bump Zero up to this > > > version too (I've already patched it to at least build in 7, but > > > it really needs a sanity check). Then we are all on the same > > > page at last. > > > > If you can get it so that the new icedtea6 builds with some > > HotSpot 7 then I'll switch over to it for my JCK runs. > > That's what I've done. I meant with Zero :) Cheers, Gary -- http://gbenson.net/ From mark at klomp.org Tue Dec 2 04:51:40 2008 From: mark at klomp.org (Mark Wielaard) Date: Tue, 02 Dec 2008 13:51:40 +0100 Subject: HotSpot just got Hotter - IcedTea6 support for latest HotSpot In-Reply-To: <4935132B.8090208@redhat.com> References: <17c6771e0812010937w62cbab8bs3e2e4ed7cdefa3b7@mail.gmail.com> <1228175535.22459.165.camel@dijkstra.wildebeest.org> <20081202093722.GA4500@redhat.com> <1228213558.3435.24.camel@dijkstra.wildebeest.org> <4935132B.8090208@redhat.com> Message-ID: <1228222300.3435.43.camel@dijkstra.wildebeest.org> Hi Andrew, On Tue, 2008-12-02 at 10:51 +0000, Andrew Haley wrote: > Mark Wielaard wrote: > > - We want an easy mechanism for trying out newer hotspots so you can > > easily build a newer version and let people try out performance > > improvements or new features/flags (but on top of the stable 6 core > > build). I really like this part of Andrew's patch, which lets you select > > either a hg revision/version number or a prepackaged hotspot src zip. > > Well, yeah, it's nice, but this isn't worth doing if the need to support > pluggable VMs leads to cruft in other areas. I think it is a much cleaner way than the current setup, where we carry a giant patch (icedtea-hotspot-6b12-7b24.patch) that needs (manual) updating whenever we update 6bxx drops. It makes any updates to the hotspot core independent of updates of the other modules. > > What is the best way to combine all these properties and keep our > > maintance level as low as possible. Which hotspot version(s) to support > > by default that make it easy to provide support for all of the above > > requirements. Did I forget anything? > > You have to ask: is this flexible configury part of the solution, or > part of the problem? Right now it's not clear to me. > > Generally speaking, new hotspot is better than old. We run the risk > that multiple build options will make the system fragile. It's much > better, where possible, to have everyone building the same sources. Yes. I think the major churn comes from supporting the old openjdk6 based hotspot because it needs so many backported patches, doesn't include sparc, has a different build dir layout, and doesn't come with the c++ interpreter for zero. It would be wise to only support newer hotspots that have at least most of that fixed. Cheers, Mark From gnu_andrew at member.fsf.org Tue Dec 2 09:22:42 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 2 Dec 2008 17:22:42 +0000 Subject: HotSpot just got Hotter - IcedTea6 support for latest HotSpot In-Reply-To: <49353668.7080405@redhat.com> References: <17c6771e0812010937w62cbab8bs3e2e4ed7cdefa3b7@mail.gmail.com> <1228175535.22459.165.camel@dijkstra.wildebeest.org> <20081202093722.GA4500@redhat.com> <1228213558.3435.24.camel@dijkstra.wildebeest.org> <4935132B.8090208@redhat.com> <1228222300.3435.43.camel@dijkstra.wildebeest.org> <49353668.7080405@redhat.com> Message-ID: <17c6771e0812020922q2608cf5cl1d5d1869bf0b84c3@mail.gmail.com> 2008/12/2 Andrew Haley : > Mark Wielaard wrote: > >> On Tue, 2008-12-02 at 10:51 +0000, Andrew Haley wrote: >>> Mark Wielaard wrote: >>>> - We want an easy mechanism for trying out newer hotspots so you can >>>> easily build a newer version and let people try out performance >>>> improvements or new features/flags (but on top of the stable 6 core >>>> build). I really like this part of Andrew's patch, which lets you select >>>> either a hg revision/version number or a prepackaged hotspot src zip. >>> Well, yeah, it's nice, but this isn't worth doing if the need to support >>> pluggable VMs leads to cruft in other areas. >> >> I think it is a much cleaner way than the current setup, > > No argument. > >>>> What is the best way to combine all these properties and keep our >>>> maintance level as low as possible. Which hotspot version(s) to support >>>> by default that make it easy to provide support for all of the above >>>> requirements. Did I forget anything? >>> You have to ask: is this flexible configury part of the solution, or >>> part of the problem? Right now it's not clear to me. >>> >>> Generally speaking, new hotspot is better than old. We run the risk >>> that multiple build options will make the system fragile. It's much >>> better, where possible, to have everyone building the same sources. >> >> Yes. I think the major churn comes from supporting the old openjdk6 >> based hotspot because it needs so many backported patches, doesn't >> include sparc, has a different build dir layout, and doesn't come with >> the c++ interpreter for zero. It would be wise to only support newer >> hotspots that have at least most of that fixed. > > Of course, but that's not the question. Obviously we don't want the > old openjdk6 based hotspot. > > Andrew. > Zero is now supported so I've pushed to the main tree. We can drop support for the bundled HotSpot once we know things are stable. -- Andrew :-) 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 Tue Dec 2 09:50:14 2008 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Tue, 02 Dec 2008 09:50:14 -0800 Subject: HotSpot just got Hotter - IcedTea6 support for latest HotSpot In-Reply-To: <17c6771e0812020922q2608cf5cl1d5d1869bf0b84c3@mail.gmail.com> References: <17c6771e0812010937w62cbab8bs3e2e4ed7cdefa3b7@mail.gmail.com> <1228175535.22459.165.camel@dijkstra.wildebeest.org> <20081202093722.GA4500@redhat.com> <1228213558.3435.24.camel@dijkstra.wildebeest.org> <4935132B.8090208@redhat.com> <1228222300.3435.43.camel@dijkstra.wildebeest.org> <49353668.7080405@redhat.com> <17c6771e0812020922q2608cf5cl1d5d1869bf0b84c3@mail.gmail.com> Message-ID: <49357556.6020307@sun.com> Just a note here: The plan was to push a "newer" version of Hotspot Express to the 6Open JDK (which we just did), and then update to the OpenJDK 7 Hotspot shortly after the new year. I would definitely agree that having to maintain only the JDK7 Hotspot for both 6Open and OpenJDK is by far the preferred method of operation. Keeping track of release trains is a royal PITA (believe me, I have to currently keep track of 7 different versions right now), and there is substantial agreement that Hotspot 14 (the version currently in JDK7) is what we should standardized on for the 6Open & 7 releases, and all work should go to the Hotspot OpenJDK repositories for both 6Open and 7. We were just waiting a bit for some HS14 issues to get stabilized and make sure all the 6Open fixes/compatibility was worked out in HS14 before pushing it to the official 6Open repos. I can't commit to a date when HS14 will be pushed out as the 6Open Hotspot, but I'd like to think it will be shortly after New Years. If everyone else is comfortable with HS14 on 6Open, then it may happen sooner. But I can't say for sure. Naturally, people are welcome to put HS14 into any IceTea6 distro whenever they feel it works well. I'm just talking about the 6Open repos hosted by Sun. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From gnu_andrew at member.fsf.org Tue Dec 2 09:53:36 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 2 Dec 2008 17:53:36 +0000 Subject: HotSpot just got Hotter - IcedTea6 support for latest HotSpot In-Reply-To: <49357556.6020307@sun.com> References: <17c6771e0812010937w62cbab8bs3e2e4ed7cdefa3b7@mail.gmail.com> <1228175535.22459.165.camel@dijkstra.wildebeest.org> <20081202093722.GA4500@redhat.com> <1228213558.3435.24.camel@dijkstra.wildebeest.org> <4935132B.8090208@redhat.com> <1228222300.3435.43.camel@dijkstra.wildebeest.org> <49353668.7080405@redhat.com> <17c6771e0812020922q2608cf5cl1d5d1869bf0b84c3@mail.gmail.com> <49357556.6020307@sun.com> Message-ID: <17c6771e0812020953l6ed9ec3dldbb241891750bf5c@mail.gmail.com> 2008/12/2 Erik Trimble : > Just a note here: > > The plan was to push a "newer" version of Hotspot Express to the 6Open JDK > (which we just did), and then update to the OpenJDK 7 Hotspot shortly after > the new year. > > I would definitely agree that having to maintain only the JDK7 Hotspot for > both 6Open and OpenJDK is by far the preferred method of operation. > > Keeping track of release trains is a royal PITA (believe me, I have to > currently keep track of 7 different versions right now), and there is > substantial agreement that Hotspot 14 (the version currently in JDK7) is > what we should standardized on for the 6Open & 7 releases, and all work > should go to the Hotspot OpenJDK repositories for both 6Open and 7. We > were just waiting a bit for some HS14 issues to get stabilized and make sure > all the 6Open fixes/compatibility was worked out in HS14 before pushing it > to the official 6Open repos. > > I can't commit to a date when HS14 will be pushed out as the 6Open Hotspot, > but I'd like to think it will be shortly after New Years. If everyone else > is comfortable with HS14 on 6Open, then it may happen sooner. But I can't > say for sure. > > Naturally, people are welcome to put HS14 into any IceTea6 distro whenever > they feel it works well. I'm just talking about the 6Open repos hosted by > Sun. > > -- > Erik Trimble > Java System Support > Mailstop: usca22-123 > Phone: x17195 > Santa Clara, CA > Timezone: US/Pacific (GMT-0800) > > That's good to know; we just did what you were planning to do anyway but quicker :D Cheers, -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From aph at redhat.com Tue Dec 2 02:51:23 2008 From: aph at redhat.com (Andrew Haley) Date: Tue, 02 Dec 2008 10:51:23 +0000 Subject: HotSpot just got Hotter - IcedTea6 support for latest HotSpot In-Reply-To: <1228213558.3435.24.camel@dijkstra.wildebeest.org> References: <17c6771e0812010937w62cbab8bs3e2e4ed7cdefa3b7@mail.gmail.com> <1228175535.22459.165.camel@dijkstra.wildebeest.org> <20081202093722.GA4500@redhat.com> <1228213558.3435.24.camel@dijkstra.wildebeest.org> Message-ID: <4935132B.8090208@redhat.com> Mark Wielaard wrote: > - We want an easy mechanism for trying out newer hotspots so you can > easily build a newer version and let people try out performance > improvements or new features/flags (but on top of the stable 6 core > build). I really like this part of Andrew's patch, which lets you select > either a hg revision/version number or a prepackaged hotspot src zip. Well, yeah, it's nice, but this isn't worth doing if the need to support pluggable VMs leads to cruft in other areas. > - We want to support the linux/sparc bits (the various > icedtea-sparc-*.patches). Some of this is actually already in newer > hotspots. > - We want to support zero/shark. Ideally without having to have separate > sets of ZERO_PATCHES and NON_ZERO_PATCHES (all our NON_ZERO_PATCHES are > actually rebases of ZERO_PATCHES to older hotspot versions). This > requires a hotspot that includes at a minimum the C++ interpreter. Yes, it does. > What is the best way to combine all these properties and keep our > maintance level as low as possible. Which hotspot version(s) to support > by default that make it easy to provide support for all of the above > requirements. Did I forget anything? You have to ask: is this flexible configury part of the solution, or part of the problem? Right now it's not clear to me. Generally speaking, new hotspot is better than old. We run the risk that multiple build options will make the system fragile. It's much better, where possible, to have everyone building the same sources. Andrew. From aph at redhat.com Tue Dec 2 05:21:44 2008 From: aph at redhat.com (Andrew Haley) Date: Tue, 02 Dec 2008 13:21:44 +0000 Subject: HotSpot just got Hotter - IcedTea6 support for latest HotSpot In-Reply-To: <1228222300.3435.43.camel@dijkstra.wildebeest.org> References: <17c6771e0812010937w62cbab8bs3e2e4ed7cdefa3b7@mail.gmail.com> <1228175535.22459.165.camel@dijkstra.wildebeest.org> <20081202093722.GA4500@redhat.com> <1228213558.3435.24.camel@dijkstra.wildebeest.org> <4935132B.8090208@redhat.com> <1228222300.3435.43.camel@dijkstra.wildebeest.org> Message-ID: <49353668.7080405@redhat.com> Mark Wielaard wrote: > On Tue, 2008-12-02 at 10:51 +0000, Andrew Haley wrote: >> Mark Wielaard wrote: >>> - We want an easy mechanism for trying out newer hotspots so you can >>> easily build a newer version and let people try out performance >>> improvements or new features/flags (but on top of the stable 6 core >>> build). I really like this part of Andrew's patch, which lets you select >>> either a hg revision/version number or a prepackaged hotspot src zip. >> Well, yeah, it's nice, but this isn't worth doing if the need to support >> pluggable VMs leads to cruft in other areas. > > I think it is a much cleaner way than the current setup, No argument. >>> What is the best way to combine all these properties and keep our >>> maintance level as low as possible. Which hotspot version(s) to support >>> by default that make it easy to provide support for all of the above >>> requirements. Did I forget anything? >> You have to ask: is this flexible configury part of the solution, or >> part of the problem? Right now it's not clear to me. >> >> Generally speaking, new hotspot is better than old. We run the risk >> that multiple build options will make the system fragile. It's much >> better, where possible, to have everyone building the same sources. > > Yes. I think the major churn comes from supporting the old openjdk6 > based hotspot because it needs so many backported patches, doesn't > include sparc, has a different build dir layout, and doesn't come with > the c++ interpreter for zero. It would be wise to only support newer > hotspots that have at least most of that fixed. Of course, but that's not the question. Obviously we don't want the old openjdk6 based hotspot. Andrew. From doko at ubuntu.com Tue Dec 2 09:12:20 2008 From: doko at ubuntu.com (Matthias Klose) Date: Tue, 02 Dec 2008 18:12:20 +0100 Subject: fix hotspot build failures with -D_FORTIFY_SOURCE=2 and -Wformat=1 Message-ID: <49356C74.2000700@ubuntu.com> These options are the default in IntrepidIbex (Ubuntu 8.10). Find attached two patches to fix these warnings, plus one patch to turn off the -Wformat=1 warnings. Matthias -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hotspot-warn-no-errformat.diff Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20081202/62eecfd7/attachment.ksh -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea-format-warnings.patch Type: text/x-diff Size: 1148 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20081202/62eecfd7/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea-fortify-source.patch Type: text/x-diff Size: 2255 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20081202/62eecfd7/attachment-0001.bin From David.Holmes at Sun.COM Tue Dec 2 15:52:56 2008 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Wed, 03 Dec 2008 09:52:56 +1000 Subject: fix hotspot build failures with -D_FORTIFY_SOURCE=2 and -Wformat=1 In-Reply-To: <49356C74.2000700@ubuntu.com> References: <49356C74.2000700@ubuntu.com> Message-ID: <4935CA58.70403@sun.com> Hi Matthias, Can't we get rid of all the dummy variables here: count = sscanf(s,"%c %d %d %d %d %d %lu %lu %lu %lu %lu %lu %lu", - &idummy, &idummy, &idummy, &idummy, &idummy, &idummy, + &cdummy, &idummy, &idummy, &idummy, &idummy, &idummy, &ldummy, &ldummy, &ldummy, &ldummy, &ldummy, &user_time, &sys_time); by using the %*d %*c format specifiers to parse but not store the value. And here: - ::write(defaultStream::output_fd(), s, (int)strlen(s)); + ssize_t rv = ::write(defaultStream::output_fd(), s, (int)strlen(s)); if we are ignoring the return value anyway (which might be the real error here!) wouldn't a cast to void be a cleaner fix? Just a thought. David Holmes Matthias Klose said the following on 12/03/08 03:12: > These options are the default in IntrepidIbex (Ubuntu 8.10). Find attached two > patches to fix these warnings, plus one patch to turn off the -Wformat=1 warnings. > > Matthias > From Kelly.Ohair at Sun.COM Tue Dec 2 17:21:18 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 02 Dec 2008 17:21:18 -0800 Subject: fix hotspot build failures with -D_FORTIFY_SOURCE=2 and -Wformat=1 In-Reply-To: <4935CA58.70403@sun.com> References: <49356C74.2000700@ubuntu.com> <4935CA58.70403@sun.com> Message-ID: <4935DF0E.5040701@sun.com> David Holmes - Sun Microsystems wrote: > Hi Matthias, > > Can't we get rid of all the dummy variables here: > > count = sscanf(s,"%c %d %d %d %d %d %lu %lu %lu %lu %lu %lu %lu", > - &idummy, &idummy, &idummy, &idummy, &idummy, &idummy, > + &cdummy, &idummy, &idummy, &idummy, &idummy, &idummy, > &ldummy, &ldummy, &ldummy, &ldummy, &ldummy, > &user_time, &sys_time); > > by using the %*d %*c format specifiers to parse but not store the value. > > And here: > > - ::write(defaultStream::output_fd(), s, (int)strlen(s)); > + ssize_t rv = ::write(defaultStream::output_fd(), s, (int)strlen(s)); > > if we are ignoring the return value anyway (which might be the real > error here!) wouldn't a cast to void be a cleaner fix? I tend to agree on the (void) cast, and seems like we run the risk of a 'local variable assigned to but not used' warning... or do any C/C++ compilers do that? -kto > > Just a thought. > > David Holmes > > Matthias Klose said the following on 12/03/08 03:12: >> These options are the default in IntrepidIbex (Ubuntu 8.10). Find >> attached two >> patches to fix these warnings, plus one patch to turn off the >> -Wformat=1 warnings. >> >> Matthias >> From edilee at gmail.com Tue Dec 2 23:59:31 2008 From: edilee at gmail.com (Edward Lee) Date: Wed, 3 Dec 2008 01:59:31 -0600 Subject: Run optimizations before Escape Analysis? Message-ID: I've been trying to help EA find more NoEscape allocations because I've noticed it missing out on some cases that could be made available by simple optimizations. For example.. void foo(int a, int b) Object newObj = new Object(); if (a != b) staticField = newObj; If a method bar() always calls foo() with both arguments as the same value, even if foo() is inlined into bar(), escape analysis won't realize the static field isn't set from bar(). It seems that initializing IterGVN before escape analysis and then running another instance of IterGVN from Optimize causes badness (issues relating to GVN hash table being an invalid address when creating oop_null for EA). I've coded a little pass that gets run right before escape analysis basically doing some of what IterGVN.optimize() would have done on IfNodes, and EA is able to say newObj doesn't escape. But this is quite hacky, and I'm basically reimplementing transform+subsume_node. (Using substitute_by ran into gvn hash lock issues.) Is there a better way to run a stripped down IterGVN/CCP without having issues of running them twice? Ed From twisti at complang.tuwien.ac.at Wed Dec 3 01:05:58 2008 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Wed, 03 Dec 2008 10:05:58 +0100 Subject: fix hotspot build failures with -D_FORTIFY_SOURCE=2 and -Wformat=1 In-Reply-To: <49356C74.2000700@ubuntu.com> References: <49356C74.2000700@ubuntu.com> Message-ID: <1228295158.1541.833.camel@localhost.localdomain> On Tue, 2008-12-02 at 18:12 +0100, Matthias Klose wrote: > --- openjdk/hotspot/src/share/vm/prims/jvm.cpp~ 2008-11-20 > 09:41:05.000000000 +0100 > +++ openjdk/hotspot/src/share/vm/prims/jvm.cpp 2008-12-02 > 16:55:32.000000000 +0100 > @@ -2474,7 +2474,7 @@ > if (Arguments::vfprintf_hook() != NULL) { > jio_fprintf(defaultStream::output_stream(), "%s", s); > } else { > - ::write(defaultStream::output_fd(), s, (int)strlen(s)); > + ssize_t rv = ::write(defaultStream::output_fd(), s, > (int)strlen(s)); > } > } David and Kelly already answered what I wanted to say, but as I still have this compose window open since yesterday... :-) I would also prefer the void cast here as it would be much clearer for the unexperienced reader. - Christian From daniel.daugherty at sun.com Wed Dec 3 01:48:10 2008 From: daniel.daugherty at sun.com (daniel.daugherty at sun.com) Date: Wed, 03 Dec 2008 09:48:10 +0000 Subject: hg: jdk7/hotspot/hotspot: 6743339: Enable building sa-jdi.jar and sawindbg.dll on Windows with hotspot build Message-ID: <20081203094813.37A2EDF1C@hg.openjdk.java.net> Changeset: b6272ef4a18f Author: poonam Date: 2008-11-27 18:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b6272ef4a18f 6743339: Enable building sa-jdi.jar and sawindbg.dll on Windows with hotspot build Summary: These changes enable the SA binaries build with hotspot build on Windows Reviewed-by: swamyv ! make/windows/build.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/sa.make From aph at redhat.com Wed Dec 3 02:16:20 2008 From: aph at redhat.com (Andrew Haley) Date: Wed, 03 Dec 2008 10:16:20 +0000 Subject: fix hotspot build failures with -D_FORTIFY_SOURCE=2 and -Wformat=1 In-Reply-To: <4935DF0E.5040701@sun.com> References: <49356C74.2000700@ubuntu.com> <4935CA58.70403@sun.com> <4935DF0E.5040701@sun.com> Message-ID: <49365C74.4010201@redhat.com> Kelly O'Hair wrote: > > > David Holmes - Sun Microsystems wrote: >> Hi Matthias, >> >> Can't we get rid of all the dummy variables here: >> >> count = sscanf(s,"%c %d %d %d %d %d %lu %lu %lu %lu %lu %lu %lu", >> - &idummy, &idummy, &idummy, &idummy, &idummy, &idummy, >> + &cdummy, &idummy, &idummy, &idummy, &idummy, &idummy, >> &ldummy, &ldummy, &ldummy, &ldummy, &ldummy, >> &user_time, &sys_time); >> >> by using the %*d %*c format specifiers to parse but not store the value. >> >> And here: >> >> - ::write(defaultStream::output_fd(), s, (int)strlen(s)); >> + ssize_t rv = ::write(defaultStream::output_fd(), s, (int)strlen(s)); >> >> if we are ignoring the return value anyway (which might be the real >> error here!) wouldn't a cast to void be a cleaner fix? > > I tend to agree on the (void) cast, and seems like we run the risk of a > 'local variable assigned to but not used' warning... or do any C/C++ > compilers do that? Yeah, they do. gcc has attribute ((unused)) for unused decls, which one might as well use in Linux-specific code. Andrew. From gbenson at redhat.com Wed Dec 3 03:52:05 2008 From: gbenson at redhat.com (Gary Benson) Date: Wed, 3 Dec 2008 11:52:05 +0000 Subject: [PATCH] 6779290: Casts in SharedRuntime::f2i, f2l, d2i and d2l rely on undefined behaviour Message-ID: <20081203115204.GB4101@redhat.com> Hi all, In C++, the result of an overflowing cast to a signed integer is undefined. The functions used to implement f2i, f2l, d2i and d2l, however, rely on the assumption that the result of an overflowing cast will be the largest magnitude number with the correct sign. The attached patch fixes. Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- diff -r dcb49b482348 -r f63a8dee04ae openjdk/hotspot/src/share/vm/runtime/sharedRuntime.cpp --- openjdk/hotspot/src/share/vm/runtime/sharedRuntime.cpp Mon Nov 03 14:00:57 2008 +0000 +++ openjdk/hotspot/src/share/vm/runtime/sharedRuntime.cpp Mon Nov 03 15:56:17 2008 +0000 @@ -173,64 +173,46 @@ JRT_END JRT_LEAF(jint, SharedRuntime::f2i(jfloat x)) - if (g_isnan(x)) {return 0;} - jlong lltmp = (jlong)x; - jint ltmp = (jint)lltmp; - if (ltmp == lltmp) { - return ltmp; - } else { - if (x < 0) { - return min_jint; - } else { - return max_jint; - } - } + if (g_isnan(x)) + return 0; + if (x >= (jfloat) max_jint) + return max_jint; + if (x <= (jfloat) min_jint) + return min_jint; + return (jint) x; JRT_END JRT_LEAF(jlong, SharedRuntime::f2l(jfloat x)) - if (g_isnan(x)) {return 0;} - jlong lltmp = (jlong)x; - if (lltmp != min_jlong) { - return lltmp; - } else { - if (x < 0) { - return min_jlong; - } else { - return max_jlong; - } - } + if (g_isnan(x)) + return 0; + if (x >= (jfloat) max_jlong) + return max_jlong; + if (x <= (jfloat) min_jlong) + return min_jlong; + return (jlong) x; JRT_END JRT_LEAF(jint, SharedRuntime::d2i(jdouble x)) - if (g_isnan(x)) {return 0;} - jlong lltmp = (jlong)x; - jint ltmp = (jint)lltmp; - if (ltmp == lltmp) { - return ltmp; - } else { - if (x < 0) { - return min_jint; - } else { - return max_jint; - } - } + if (g_isnan(x)) + return 0; + if (x >= (jdouble) max_jint) + return max_jint; + if (x <= (jdouble) min_jint) + return min_jint; + return (jint) x; JRT_END JRT_LEAF(jlong, SharedRuntime::d2l(jdouble x)) - if (g_isnan(x)) {return 0;} - jlong lltmp = (jlong)x; - if (lltmp != min_jlong) { - return lltmp; - } else { - if (x < 0) { - return min_jlong; - } else { - return max_jlong; - } - } + if (g_isnan(x)) + return 0; + if (x >= (jdouble) max_jlong) + return max_jlong; + if (x <= (jdouble) min_jlong) + return min_jlong; + return (jlong) x; JRT_END -------------- next part -------------- /* @test * @bug 6779290 * @summary Check that [fd]2[il] overflow correctly */ public class Test6779290 { public static void check_f2i(int expect) { float check = expect; check *= 2; int actual = (int) check; if (actual != expect) throw new RuntimeException("expecting " + expect + ", got " + actual); } public static void check_f2l(long expect) { float check = expect; check *= 2; long actual = (long) check; if (actual != expect) throw new RuntimeException("expecting " + expect + ", got " + actual); } public static void check_d2i(int expect) { double check = expect; check *= 2; int actual = (int) check; if (actual != expect) throw new RuntimeException("expecting " + expect + ", got " + actual); } public static void check_d2l(long expect) { double check = expect; check *= 2; long actual = (long) check; if (actual != expect) throw new RuntimeException("expecting " + expect + ", got " + actual); } public static void main(String[] args) { check_f2i(Integer.MAX_VALUE); check_f2i(Integer.MIN_VALUE); check_f2l(Long.MAX_VALUE); check_f2l(Long.MIN_VALUE); check_d2i(Integer.MAX_VALUE); check_d2i(Integer.MIN_VALUE); check_d2l(Long.MAX_VALUE); check_d2l(Long.MIN_VALUE); } } From doko at ubuntu.com Wed Dec 3 04:38:27 2008 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 03 Dec 2008 13:38:27 +0100 Subject: fix hotspot build failures with -D_FORTIFY_SOURCE=2 and -Wformat=1 In-Reply-To: <1228295158.1541.833.camel@localhost.localdomain> References: <49356C74.2000700@ubuntu.com> <1228295158.1541.833.camel@localhost.localdomain> Message-ID: <49367DC3.7090802@ubuntu.com> Christian Thalinger schrieb: > On Tue, 2008-12-02 at 18:12 +0100, Matthias Klose wrote: >> --- openjdk/hotspot/src/share/vm/prims/jvm.cpp~ 2008-11-20 >> 09:41:05.000000000 +0100 >> +++ openjdk/hotspot/src/share/vm/prims/jvm.cpp 2008-12-02 >> 16:55:32.000000000 +0100 >> @@ -2474,7 +2474,7 @@ >> if (Arguments::vfprintf_hook() != NULL) { >> jio_fprintf(defaultStream::output_stream(), "%s", s); >> } else { >> - ::write(defaultStream::output_fd(), s, (int)strlen(s)); >> + ssize_t rv = ::write(defaultStream::output_fd(), s, >> (int)strlen(s)); >> } >> } > > David and Kelly already answered what I wanted to say, but as I still > have this compose window open since yesterday... :-) > > I would also prefer the void cast here as it would be much clearer for > the unexperienced reader. a void cast doesn't help. collected some suggestions, and the "best" seems to be ssize_t rv_neverused __attribute__((unused)) = ... although this file cannot be built with -Wunused or -Wunused-variable anyway. Matthias From twisti at complang.tuwien.ac.at Wed Dec 3 04:46:56 2008 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Wed, 03 Dec 2008 13:46:56 +0100 Subject: fix hotspot build failures with -D_FORTIFY_SOURCE=2 and -Wformat=1 In-Reply-To: <49367DC3.7090802@ubuntu.com> References: <49356C74.2000700@ubuntu.com> <1228295158.1541.833.camel@localhost.localdomain> <49367DC3.7090802@ubuntu.com> Message-ID: <1228308416.1541.836.camel@localhost.localdomain> On Wed, 2008-12-03 at 13:38 +0100, Matthias Klose wrote: > Christian Thalinger schrieb: > > On Tue, 2008-12-02 at 18:12 +0100, Matthias Klose wrote: > >> --- openjdk/hotspot/src/share/vm/prims/jvm.cpp~ 2008-11-20 > >> 09:41:05.000000000 +0100 > >> +++ openjdk/hotspot/src/share/vm/prims/jvm.cpp 2008-12-02 > >> 16:55:32.000000000 +0100 > >> @@ -2474,7 +2474,7 @@ > >> if (Arguments::vfprintf_hook() != NULL) { > >> jio_fprintf(defaultStream::output_stream(), "%s", s); > >> } else { > >> - ::write(defaultStream::output_fd(), s, (int)strlen(s)); > >> + ssize_t rv = ::write(defaultStream::output_fd(), s, > >> (int)strlen(s)); > >> } > >> } > > > > David and Kelly already answered what I wanted to say, but as I still > > have this compose window open since yesterday... :-) > > > > I would also prefer the void cast here as it would be much clearer for > > the unexperienced reader. > > a void cast doesn't help. collected some suggestions, and the "best" seems to be > > ssize_t rv_neverused __attribute__((unused)) = ... > > although this file cannot be built with -Wunused or -Wunused-variable anyway. A void cast does not help? What GCC version is that or even better, what is the warning? - Christian From doko at ubuntu.com Wed Dec 3 05:46:08 2008 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 03 Dec 2008 14:46:08 +0100 Subject: fix hotspot build failures with -D_FORTIFY_SOURCE=2 and -Wformat=1 In-Reply-To: <4935DF0E.5040701@sun.com> References: <49356C74.2000700@ubuntu.com> <4935CA58.70403@sun.com> <4935DF0E.5040701@sun.com> Message-ID: <49368DA0.8060808@ubuntu.com> Kelly O'Hair schrieb: > > > David Holmes - Sun Microsystems wrote: >> Hi Matthias, >> >> Can't we get rid of all the dummy variables here: >> >> count = sscanf(s,"%c %d %d %d %d %d %lu %lu %lu %lu %lu %lu %lu", >> - &idummy, &idummy, &idummy, &idummy, &idummy, &idummy, >> + &cdummy, &idummy, &idummy, &idummy, &idummy, &idummy, >> &ldummy, &ldummy, &ldummy, &ldummy, &ldummy, >> &user_time, &sys_time); >> >> by using the %*d %*c format specifiers to parse but not store the value. >> >> And here: >> >> - ::write(defaultStream::output_fd(), s, (int)strlen(s)); >> + ssize_t rv = ::write(defaultStream::output_fd(), s, (int)strlen(s)); >> >> if we are ignoring the return value anyway (which might be the real >> error here!) wouldn't a cast to void be a cleaner fix? > > I tend to agree on the (void) cast, and seems like we run the risk of a > 'local variable assigned to but not used' warning... or do any C/C++ > compilers do that? int fn () __attribute__ ((warn_unused_result)); int foo () { if (fn () < 0) return -1; (void) fn (); return 0; } gcc (4.3.x, 4.4) still warns about the unused return value. hotspot currently cannot be built with -Wunused or -Wunused-variable. From twisti at complang.tuwien.ac.at Wed Dec 3 06:20:50 2008 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Wed, 03 Dec 2008 15:20:50 +0100 Subject: fix hotspot build failures with -D_FORTIFY_SOURCE=2 and -Wformat=1 In-Reply-To: <49368DA0.8060808@ubuntu.com> References: <49356C74.2000700@ubuntu.com> <4935CA58.70403@sun.com> <4935DF0E.5040701@sun.com> <49368DA0.8060808@ubuntu.com> Message-ID: <1228314050.1541.839.camel@localhost.localdomain> On Wed, 2008-12-03 at 14:46 +0100, Matthias Klose wrote: > int fn () __attribute__ ((warn_unused_result)); > int foo () > { > if (fn () < 0) return -1; > (void) fn (); > return 0; > } > > gcc (4.3.x, 4.4) still warns about the unused return value. I see the problem. write is defined with __wur (which is most likely __attribute__ ((warn_unused_result)), I did not check) in glibc-2.7, but not in e.g. glibc-2.3.6, and GCC warns about it even when a (void) cast is used. I'd say this is a bug in GCC. When I explicitly ask for ignoring the return value, it should do it. - Christian From Vladimir.Kozlov at Sun.COM Wed Dec 3 07:34:48 2008 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 03 Dec 2008 07:34:48 -0800 Subject: Run optimizations before Escape Analysis? In-Reply-To: References: Message-ID: <4936A718.4070604@sun.com> Ed, You can try to move EA code into Optimize() method after first IterGVN.optimize() and remove nulling _congraph. Also you need to use PhaseIterGVN igvn in EA code instead of _compile->initial_gvn(). Add new field _igvn in ConnectionGraph class and initialize it by passing igvn to ConnectionGraph constructor. See if it will give you more NoEscape allocations. Vladimir Edward Lee wrote: > I've been trying to help EA find more NoEscape allocations because > I've noticed it missing out on some cases that could be made available > by simple optimizations. For example.. > > void foo(int a, int b) > Object newObj = new Object(); > if (a != b) > staticField = newObj; > > If a method bar() always calls foo() with both arguments as the same > value, even if foo() is inlined into bar(), escape analysis won't > realize the static field isn't set from bar(). > > It seems that initializing IterGVN before escape analysis and then > running another instance of IterGVN from Optimize causes badness > (issues relating to GVN hash table being an invalid address when > creating oop_null for EA). I've coded a little pass that gets run > right before escape analysis basically doing some of what > IterGVN.optimize() would have done on IfNodes, and EA is able to say > newObj doesn't escape. But this is quite hacky, and I'm basically > reimplementing transform+subsume_node. (Using substitute_by ran into > gvn hash lock issues.) > > Is there a better way to run a stripped down IterGVN/CCP without > having issues of running them twice? > > Ed From Scott.Oaks at Sun.COM Wed Dec 3 11:53:06 2008 From: Scott.Oaks at Sun.COM (Scott Oaks) Date: Wed, 03 Dec 2008 14:53:06 -0500 Subject: Loop compilation weirdness Message-ID: <1228333986.34426.261.camel@sr1-unyc10-07> As many of you may know, in the appserver we spent a great deal of time converting characters (from Strings) to bytes (for HTTP traffic). The vast majority of this is ISO_8859_1 encoding, so the conversion is a simple loop that does b[bIndex++] = (byte) c[cIndex++]. Still, we'd been using the NIO converters for this rather than coding it ourselves. In certain cases, the overhead of wrapping the arrays into buffers introduces a huge performance penalty (and increased GC), so we're thinking of doing this special-case conversion directly. So we wrote a simple loop to do the conversion and found out that for 8K buffers of HTTP requests, the simple loop takes significantly longer than calling the NIO. If we take the loop from sun/nio/cs/ISO_8859_1.java and code it directly, we get the expected performance. [An aside for the curious: we often convert 8K buffers because that's a JSP page size. But we also often convert really small strings, and its the conversion of those small 16-character strings where the overhead of calling the NIO converter kicks in.] The attached code boils this all down: the convertFast method (derived from the ISO_8859_1 class) is the fastest for arrays of all sizes; convertNio is fast for large arrays and slow for small arrays; and convertSimple is generally fast for small arrays, but 2-3x slower than convertFast for large arrays. In fact, the key part of the convertFast method is this: while (...characters to process ... ) { if (dp >= dl) { return CoderResult.OVERFLOW; // We need to reset the output byte array. If we reset it directly // (e.g. if we just set dp=0 here), performance drops by 50% // and is hence equivalent to convertSimple } da[dp++] = (byte) c; } So if we return out of this loop, reset the output byte buffer, and return to the loop -- then the loop is optimized faster than if we reset the output byte buffer directly in the if statement (a little clearer if you look at the entire code). Oddly, this is true even though in this particular test, the body of the if statement is never executed. So my long-winded question is why the loop is compiled differently when we return out of the if statement rather than if we process a simple statement in the if statement. And in general, why the simpler convertSimple method in the attached is sub-optimal to the more complex convertFast, at least for large arrays. Is this just an odd corner-case-or-something bug, or is there some basic fast loop-writing construct I'm not aware of here? If you run as is, the key thing to look at is the second test for strings of 8192, which on my very old sparc machine gives me 537ms for fast and 1474ms for simple; on my x4100 with Linux it gives me 96ms/207ms respectively. You can comment out the return from the if and uncomment the dp=0 line, and see the performance of the "fast" test drop by 2-3x. We've tested this is with both JDK 6_07 and the lastest promotion of JDK 7 -Scott -------------- next part -------------- A non-text attachment was scrubbed... Name: C2BTest.java Type: text/x-java Size: 3704 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20081203/316ad1d3/attachment.bin From edilee at gmail.com Wed Dec 3 12:03:25 2008 From: edilee at gmail.com (Edward Lee) Date: Wed, 3 Dec 2008 14:03:25 -0600 Subject: Run optimizations before Escape Analysis? In-Reply-To: <4936A718.4070604@sun.com> References: <4936A718.4070604@sun.com> Message-ID: On Wed, Dec 3, 2008 at 9:34 AM, Vladimir Kozlov wrote: > You can try to move EA code into Optimize() method after first > IterGVN.optimize() and remove nulling _congraph. That seems to work. Attached is a patch that moves escape analysis after the first IterGVN.optimize() call. Things will still get optimized later through CCP.do_transform and IterGVN.optimize(). However, it turns out the initial GVN handles the duplicate argument case with the basic value numbering, but this change still helps in my situation. I can now tweak Ideal for various nodes that can lead to dead code, and now EA won't need to consider those nodes when computing escape properties. Arguably, there's value even without my custom Ideal changes for nodes that can be removed when reshaping the graph. Thanks, Ed -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: escape.after.txt Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20081203/006e8958/attachment.txt From Kelly.Ohair at Sun.COM Wed Dec 3 12:24:55 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 03 Dec 2008 12:24:55 -0800 Subject: fix hotspot build failures with -D_FORTIFY_SOURCE=2 and -Wformat=1 In-Reply-To: <1228314050.1541.839.camel@localhost.localdomain> References: <49356C74.2000700@ubuntu.com> <4935CA58.70403@sun.com> <4935DF0E.5040701@sun.com> <49368DA0.8060808@ubuntu.com> <1228314050.1541.839.camel@localhost.localdomain> Message-ID: <4936EB17.3070607@sun.com> Casting a function call to (void) is a well defined, well understood and explicit language syntax. The function return is being explicitly ignored. If we have to jump through hoops for this gcc then maybe the -Werror should just be turned off for this gcc release in the Makefiles. -kto Christian Thalinger wrote: > On Wed, 2008-12-03 at 14:46 +0100, Matthias Klose wrote: >> int fn () __attribute__ ((warn_unused_result)); >> int foo () >> { >> if (fn () < 0) return -1; >> (void) fn (); >> return 0; >> } >> >> gcc (4.3.x, 4.4) still warns about the unused return value. > > I see the problem. write is defined with __wur (which is most likely > __attribute__ ((warn_unused_result)), I did not check) in glibc-2.7, but > not in e.g. glibc-2.3.6, and GCC warns about it even when a (void) cast > is used. > > I'd say this is a bug in GCC. When I explicitly ask for ignoring the > return value, it should do it. > > - Christian > From doko at ubuntu.com Wed Dec 3 12:36:35 2008 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 03 Dec 2008 21:36:35 +0100 Subject: fix hotspot build failures with -D_FORTIFY_SOURCE=2 and -Wformat=1 In-Reply-To: <4936EB17.3070607@sun.com> References: <49356C74.2000700@ubuntu.com> <4935CA58.70403@sun.com> <4935DF0E.5040701@sun.com> <49368DA0.8060808@ubuntu.com> <1228314050.1541.839.camel@localhost.localdomain> <4936EB17.3070607@sun.com> Message-ID: <4936EDD3.6040809@ubuntu.com> Kelly O'Hair schrieb: > Casting a function call to (void) is a well defined, well understood > and explicit language syntax. The function return is being explicitly > ignored. > If we have to jump through hoops for this gcc then maybe the -Werror should > just be turned off for this gcc release in the Makefiles. > > -kto > > Christian Thalinger wrote: >> On Wed, 2008-12-03 at 14:46 +0100, Matthias Klose wrote: >>> int fn () __attribute__ ((warn_unused_result)); >>> int foo () >>> { >>> if (fn () < 0) return -1; >>> (void) fn (); >>> return 0; >>> } >>> >>> gcc (4.3.x, 4.4) still warns about the unused return value. >> >> I see the problem. write is defined with __wur (which is most likely >> __attribute__ ((warn_unused_result)), I did not check) in glibc-2.7, but >> not in e.g. glibc-2.3.6, and GCC warns about it even when a (void) cast >> is used. >> >> I'd say this is a bug in GCC. When I explicitly ask for ignoring the >> return value, it should do it. this is http://gcc.gnu.org/PR25509, not seen as a bug in GCC. I'll discuss a solution for Ubuntu with my coworkers next week. Matthias From John.Rose at Sun.COM Wed Dec 3 14:22:22 2008 From: John.Rose at Sun.COM (John Rose) Date: Wed, 03 Dec 2008 14:22:22 -0800 Subject: Loop compilation weirdness In-Reply-To: <1228333986.34426.261.camel@sr1-unyc10-07> References: <1228333986.34426.261.camel@sr1-unyc10-07> Message-ID: <6B9709B6-8801-43E0-A847-B607E09DB87A@sun.com> On Dec 3, 2008, at 11:53 AM, Scott Oaks wrote: > So my long-winded question is why the loop is compiled differently > when > we return out of the if statement rather than if we process a simple > statement in the if statement. Here's a short answer: Simpler loops are optimized better. What's a simple loop (besides fewer statements)? Loops with more loop invariant and loop index values are generally simpler. Loops with fewer internal control merges are generally simpler. In the case of your code, the slower loop has a conditional path that merges back into the loop body. At that merge point, the 'boff' value becomes something much more complicated than a simple index variable. (Even though it is a variable in the heap, the optimized loop probably keeps it in a register most of the time. The Java memory model is designed to allow this.) Note that I said "internal control merges" not the more obvious "internal branches of control". If a loop has a branch that exits the loop, it does not greatly complicate the optimization of the loop. For example, a conditional branch that changes the value of a loop invariant or index variable and then exits the loop does not destroy the quality of the variable for the loop body. Only a subsequent merge back into the loop body will do this. (This is a consequence of SSA-based optimization.) It is common for even simple Java loops to have tens of exit points, most of them for never-taken potential exceptions (null check, cast, range check, etc.). But this is all off-the-cuff. I haven't compiled your code. For better information in your particular case, use the disassembler: http://wikis.sun.com/display/HotSpotInternals/PrintAssembly Good luck, -- John P.S. The System.arraycopy intrinsic is heavily optimized, and in some cases is faster than a hand-written loop. For NIO, there is also sun.misc.Unsafe.copyMemory, which can copy any combination of {C heap, Java heap} to {C heap, Java heap} arrays. This uses the same intrinsic optimizations as System.arraycopy. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20081203/0f15f596/attachment.html From Scott.Oaks at Sun.COM Wed Dec 3 14:34:56 2008 From: Scott.Oaks at Sun.COM (Scott Oaks) Date: Wed, 03 Dec 2008 17:34:56 -0500 Subject: Loop compilation weirdness In-Reply-To: <6B9709B6-8801-43E0-A847-B607E09DB87A@sun.com> References: <1228333986.34426.261.camel@sr1-unyc10-07> <6B9709B6-8801-43E0-A847-B607E09DB87A@sun.com> Message-ID: <1228343696.34426.285.camel@sr1-unyc10-07> Thanks; that makes sense. A little counter-intuitive to me that the far-simpler-to-write code isn't the simpler code to execute, but now I see the point about branching out of the loop vs. merging back in. > P.S. The System.arraycopy intrinsic is heavily optimized, and in some > cases is faster than a hand-written loop. Always faster (or at least as fast), I would expect (and I've filed bugs on that in the past...). But this isn't a simple array copy; it's type converting as it goes. -Scott From martinrb at google.com Wed Dec 3 17:04:42 2008 From: martinrb at google.com (Martin Buchholz) Date: Wed, 3 Dec 2008 17:04:42 -0800 Subject: OpenJDK 6 build 14 source posted In-Reply-To: <4936E036.7030407@sun.com> References: <4936E036.7030407@sun.com> Message-ID: <1ccfd1c10812031704o47edf8b3j75a4b149a049278@mail.gmail.com> On Wed, Dec 3, 2008 at 11:38, Joe Darcy wrote: > The source bundle for OpenJDK 6 build 14 is available for download from: > > http://download.java.net/openjdk/jdk6/ The new Hotspot 11 failed to compile on a modified 64-bit (debian arch=amd64) Ubuntu dapper system as follows: cc1plus: warnings being treated as errors /usr/local/google/home/martin/ws/buildAllOpenJDK6/hotspot/src/share/vm/utilities/ostream.cpp: In member function 'bool networkStream::connect(const char*, short int)': /usr/local/google/home/martin/ws/buildAllOpenJDK6/hotspot/src/share/vm/utilities/ostream.cpp:835: warning: comparison is always false due to limited range of data type 32-bit systems are unaffected (not sure why). gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) Running make with WARNINGS_ARE_ERRORS="" as previously advertised, appears to be the workaround. Martin From Xiaobin.Lu at Sun.COM Wed Dec 3 17:06:18 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Wed, 03 Dec 2008 17:06:18 -0800 Subject: OpenJDK 6 build 14 source posted In-Reply-To: <1ccfd1c10812031704o47edf8b3j75a4b149a049278@mail.gmail.com> References: <4936E036.7030407@sun.com> <1ccfd1c10812031704o47edf8b3j75a4b149a049278@mail.gmail.com> Message-ID: <49372D0A.7010001@Sun.COM> I am looking into these failures and trying to fix these now on the latest ubuntu 8.10 installation. The gcc/g++ is 4.3.2. -Xiaobin Martin Buchholz wrote: > On Wed, Dec 3, 2008 at 11:38, Joe Darcy wrote: > >> The source bundle for OpenJDK 6 build 14 is available for download from: >> >> http://download.java.net/openjdk/jdk6/ >> > > The new Hotspot 11 failed to compile on a modified 64-bit (debian arch=amd64) > Ubuntu dapper system as follows: > > cc1plus: warnings being treated as errors > /usr/local/google/home/martin/ws/buildAllOpenJDK6/hotspot/src/share/vm/utilities/ostream.cpp: > In member function 'bool networkStream::connect(const char*, short > int)': > /usr/local/google/home/martin/ws/buildAllOpenJDK6/hotspot/src/share/vm/utilities/ostream.cpp:835: > warning: comparison is always false due to limited range of data type > > 32-bit systems are unaffected (not sure why). > > gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) > > Running make with WARNINGS_ARE_ERRORS="" as previously advertised, > appears to be the workaround. > > Martin > From David.Holmes at Sun.COM Wed Dec 3 18:04:32 2008 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Thu, 04 Dec 2008 12:04:32 +1000 Subject: fix hotspot build failures with -D_FORTIFY_SOURCE=2 and -Wformat=1 In-Reply-To: <4936EDD3.6040809@ubuntu.com> References: <49356C74.2000700@ubuntu.com> <4935CA58.70403@sun.com> <4935DF0E.5040701@sun.com> <49368DA0.8060808@ubuntu.com> <1228314050.1541.839.camel@localhost.localdomain> <4936EB17.3070607@sun.com> <4936EDD3.6040809@ubuntu.com> Message-ID: <49373AB0.1000209@sun.com> Matthias Klose said the following on 12/04/08 06:36: > this is http://gcc.gnu.org/PR25509, not seen as a bug in GCC. I'll discuss a > solution for Ubuntu with my coworkers next week. What a dismal state of affairs. :( David From glewis at eyesbeyond.com Wed Dec 3 21:14:27 2008 From: glewis at eyesbeyond.com (Greg Lewis) Date: Wed, 3 Dec 2008 21:14:27 -0800 Subject: Recent HotSpot changes in OpenJDK break Mac OS X Message-ID: <20081204051427.GA91245@misty.eyesbeyond.com> G'day all, I'm working on the BSD port of OpenJDK and we recently merged in HotSpot changes that have broken the build on Mac OS X. The breakage looks like this: /Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/interp_masm_x86_32.hpp: In member function 'void InterpreterMacroAssembler::empty_expression_stack()': /Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/interp_masm_x86_32.hpp:123: error: call of overloaded 'movptr(Address, int)' is ambiguous /Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2010: note: candidates are: void MacroAssembler::movptr(Address, intptr_t) /Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2012: note: void MacroAssembler::movptr(Address, RegisterImpl*) make[6]: *** [incls/_precompiled.incl.gch] Error 1 The guilty line of code in interp_masm_x86_32.hpp is this one: // NULL last_sp until next java call movptr(Address(rbp, frame::interpreter_frame_last_sp_offset * wordSize), (int32_t)NULL_WORD); There are many other similar instances though, thats just the first one the compiler encounters. The prototypes in assember_x86.hpp are: void movptr(Address dst, intptr_t src); void movptr(Address dst, Register src); Note that Mac OS X is not LP64, so the additional prototype for movptr that takes an int32_t as the second parameter doesn't get defined (and it wouldn't be helpful anyway since that definition is specifically for 64 bit x86 OSes). The code is basically relying on int32_t and intptr_t being typedef'ed to the same thing on 32 bit platforms. However, there is no language standard I'm aware of that guarantees this. On FreeBSD and Linux they are both typedef'ed to an int, so this works. I suspect the same is true on Solaris although I haven't got a box I can check that on. However, on Mac OS X int32_t is typedef'ed as an int and intptr_t is typedef'ed as a long, hence the above error. This could be "fixed" with a Mac OS X specific definition that takes an int32_t, but thats just papering over the broken assumption in the code. I'd also like to avoid littering the code with #ifdef's that call the int32_t version on LP64 and the intptr_t version otherwise. Another way would be something like this: #ifdef _LP64 #define 32BIT_MOVPTR_CAST_TYPE int32_t #else #define 32BIT_MOVPTR_CAST_TYPE intptr_t #endif and then cast to (32BIT_MOVPTR_CAST_TYPE). That still seems hacky though, and introduces a lot of gratuitous changes into the BSD port which will make merging harder. Can anyone think of a more general solution that doesn't undo the merge of the 32 and 64 bit code that appears to be responsible for this? -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org From Xiaobin.Lu at Sun.COM Wed Dec 3 21:38:56 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Wed, 03 Dec 2008 21:38:56 -0800 Subject: Recent HotSpot changes in OpenJDK break Mac OS X In-Reply-To: <20081204051427.GA91245@misty.eyesbeyond.com> References: <20081204051427.GA91245@misty.eyesbeyond.com> Message-ID: <49376CF0.5070601@Sun.COm> Hi Greg, You probably need to join bsd-port-dev at openjdk.java.net alias if you haven't. And then you can open the email archive to see more on the thing you discovered below. Regards, -Xiaobin Greg Lewis wrote: > G'day all, > > I'm working on the BSD port of OpenJDK and we recently merged in HotSpot > changes that have broken the build on Mac OS X. > > The breakage looks like this: > > /Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/interp_masm_x86_32.hpp: > In member function 'void InterpreterMacroAssembler::empty_expression_stack()': > /Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/interp_masm_x86_32.hpp:123: > error: call of overloaded 'movptr(Address, int)' is ambiguous > /Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2010: > note: candidates are: void MacroAssembler::movptr(Address, intptr_t) > /Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2012: > note: void MacroAssembler::movptr(Address, RegisterImpl*) > make[6]: *** [incls/_precompiled.incl.gch] Error 1 > > The guilty line of code in interp_masm_x86_32.hpp is this one: > > // NULL last_sp until next java call > movptr(Address(rbp, frame::interpreter_frame_last_sp_offset * wordSize), (int32_t)NULL_WORD); > > There are many other similar instances though, thats just the first one the > compiler encounters. > > The prototypes in assember_x86.hpp are: > > void movptr(Address dst, intptr_t src); > void movptr(Address dst, Register src); > > Note that Mac OS X is not LP64, so the additional prototype for movptr > that takes an int32_t as the second parameter doesn't get defined (and it > wouldn't be helpful anyway since that definition is specifically for 64 bit > x86 OSes). > > The code is basically relying on int32_t and intptr_t being typedef'ed to > the same thing on 32 bit platforms. However, there is no language standard > I'm aware of that guarantees this. On FreeBSD and Linux they are both > typedef'ed to an int, so this works. I suspect the same is true on Solaris > although I haven't got a box I can check that on. However, on Mac OS X > int32_t is typedef'ed as an int and intptr_t is typedef'ed as a long, hence > the above error. > > This could be "fixed" with a Mac OS X specific definition that takes an > int32_t, but thats just papering over the broken assumption in the code. > I'd also like to avoid littering the code with #ifdef's that call the > int32_t version on LP64 and the intptr_t version otherwise. Another way > would be something like this: > > #ifdef _LP64 > #define 32BIT_MOVPTR_CAST_TYPE int32_t > #else > #define 32BIT_MOVPTR_CAST_TYPE intptr_t > #endif > > and then cast to (32BIT_MOVPTR_CAST_TYPE). That still seems hacky though, > and introduces a lot of gratuitous changes into the BSD port which will > make merging harder. > > Can anyone think of a more general solution that doesn't undo the merge of > the 32 and 64 bit code that appears to be responsible for this? > > From twisti at complang.tuwien.ac.at Thu Dec 4 00:22:43 2008 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Thu, 04 Dec 2008 09:22:43 +0100 Subject: fix hotspot build failures with -D_FORTIFY_SOURCE=2 and -Wformat=1 In-Reply-To: <49373AB0.1000209@sun.com> References: <49356C74.2000700@ubuntu.com> <4935CA58.70403@sun.com> <4935DF0E.5040701@sun.com> <49368DA0.8060808@ubuntu.com> <1228314050.1541.839.camel@localhost.localdomain> <4936EB17.3070607@sun.com> <4936EDD3.6040809@ubuntu.com> <49373AB0.1000209@sun.com> Message-ID: <1228378964.1541.844.camel@localhost.localdomain> On Thu, 2008-12-04 at 12:04 +1000, David Holmes - Sun Microsystems wrote: > Matthias Klose said the following on 12/04/08 06:36: > > this is http://gcc.gnu.org/PR25509, not seen as a bug in GCC. I'll discuss a > > solution for Ubuntu with my coworkers next week. > > What a dismal state of affairs. :( Ugh, yeah. After reading some of the comments, I'd say it's a bug in GCC and glibc. I wonder if that ever gets changed... on either side... - Christian From jon.masamitsu at sun.com Thu Dec 4 00:53:27 2008 From: jon.masamitsu at sun.com (jon.masamitsu at sun.com) Date: Thu, 04 Dec 2008 08:53:27 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20081204085331.AFECDDF87@hg.openjdk.java.net> Changeset: 27a80744a83b Author: ysr Date: 2008-12-01 23:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/27a80744a83b 6778647: snap(), snap_policy() should be renamed setup(), setup_policy() Summary: Renamed Reference{Policy,Pocessor} methods from snap{,_policy}() to setup{,_policy}() Reviewed-by: apetrusenko ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/referencePolicy.cpp ! src/share/vm/memory/referencePolicy.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp Changeset: 95cad1ab2510 Author: jmasa Date: 2008-12-03 14:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/95cad1ab2510 Merge From aph at redhat.com Thu Dec 4 03:39:43 2008 From: aph at redhat.com (Andrew Haley) Date: Thu, 04 Dec 2008 11:39:43 +0000 Subject: OpenJDK 6 build 14 source posted In-Reply-To: <1ccfd1c10812031704o47edf8b3j75a4b149a049278@mail.gmail.com> References: <4936E036.7030407@sun.com> <1ccfd1c10812031704o47edf8b3j75a4b149a049278@mail.gmail.com> Message-ID: <4937C17F.3090904@redhat.com> Martin Buchholz wrote: > On Wed, Dec 3, 2008 at 11:38, Joe Darcy wrote: >> The source bundle for OpenJDK 6 build 14 is available for download from: >> >> http://download.java.net/openjdk/jdk6/ > > The new Hotspot 11 failed to compile on a modified 64-bit (debian arch=amd64) > Ubuntu dapper system as follows: > > cc1plus: warnings being treated as errors > /usr/local/google/home/martin/ws/buildAllOpenJDK6/hotspot/src/share/vm/utilities/ostream.cpp: > In member function 'bool networkStream::connect(const char*, short > int)': > /usr/local/google/home/martin/ws/buildAllOpenJDK6/hotspot/src/share/vm/utilities/ostream.cpp:835: > warning: comparison is always false due to limited range of data type > > 32-bit systems are unaffected (not sure why). It's a bug. The code is basically this: #include typedef uint32_t in_addr_t; in_addr_t s_addr; int pp () { return (s_addr == (unsigned long)-1); } Promoting -1 to unsigned long on an LP64 machine gives 0xffffffffffffffff, which won't fit in an in_addr_t. Another weird corner case in C: 6.3.1.3 para 2. Andrew. From Kelly.Ohair at Sun.COM Thu Dec 4 10:34:15 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 04 Dec 2008 10:34:15 -0800 Subject: fix hotspot build failures with -D_FORTIFY_SOURCE=2 and -Wformat=1 In-Reply-To: <1228378964.1541.844.camel@localhost.localdomain> References: <49356C74.2000700@ubuntu.com> <4935CA58.70403@sun.com> <4935DF0E.5040701@sun.com> <49368DA0.8060808@ubuntu.com> <1228314050.1541.839.camel@localhost.localdomain> <4936EB17.3070607@sun.com> <4936EDD3.6040809@ubuntu.com> <49373AB0.1000209@sun.com> <1228378964.1541.844.camel@localhost.localdomain> Message-ID: <493822A7.4070605@sun.com> The issue seems so simple to me. If the function return is to be ignored, you make an explicit cast to void. This practice is so old and common I don't understand why it's so complicated. gcc/g++ are not the only compilers on the planet. Writing portable C or C++ code becomes increasingly more complicated when you have to rely on special features of the compiler to get them to shut up about perfectly valid code. What happened to following the standards? WG14/N1124 6.3.2.2 void "... If an expression of any other type is evaluated as a void expression, its value or designator is discarded. (A void expression is evaluated for its side effects.)" Sigh... :^( -kto Christian Thalinger wrote: > On Thu, 2008-12-04 at 12:04 +1000, David Holmes - Sun Microsystems > wrote: >> Matthias Klose said the following on 12/04/08 06:36: >>> this is http://gcc.gnu.org/PR25509, not seen as a bug in GCC. I'll discuss a >>> solution for Ubuntu with my coworkers next week. >> What a dismal state of affairs. :( > > Ugh, yeah. After reading some of the comments, I'd say it's a bug in > GCC and glibc. I wonder if that ever gets changed... on either side... > > - Christian > From John.Coomes at sun.com Thu Dec 4 10:53:34 2008 From: John.Coomes at sun.com (John Coomes) Date: Thu, 4 Dec 2008 10:53:34 -0800 Subject: OpenJDK 6 build 14 source posted In-Reply-To: <4937C17F.3090904@redhat.com> References: <4936E036.7030407@sun.com> <1ccfd1c10812031704o47edf8b3j75a4b149a049278@mail.gmail.com> <4937C17F.3090904@redhat.com> Message-ID: <18744.10030.107701.463469@sun.com> Andrew Haley (aph at redhat.com) wrote: > Martin Buchholz wrote: > > On Wed, Dec 3, 2008 at 11:38, Joe Darcy wrote: > >> The source bundle for OpenJDK 6 build 14 is available for download from: > >> > >> http://download.java.net/openjdk/jdk6/ > > > > The new Hotspot 11 failed to compile on a modified 64-bit (debian arch=amd64) > > Ubuntu dapper system as follows: > > > > cc1plus: warnings being treated as errors > > /usr/local/google/home/martin/ws/buildAllOpenJDK6/hotspot/src/share/vm/utilities/ostream.cpp: > > In member function 'bool networkStream::connect(const char*, short > > int)': > > /usr/local/google/home/martin/ws/buildAllOpenJDK6/hotspot/src/share/vm/utilities/ostream.cpp:835: > > warning: comparison is always false due to limited range of data type > > > > 32-bit systems are unaffected (not sure why). > > It's a bug. The code is basically this: > ... This is http://bugs.sun.com/view_bug.do?bug_id=6679422. FWIW, the trivial fix is in jdk7: http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/092ea87cc974 Joe, I can try to get this into jdk6-open, but not until next week at the earliest. Let me know. -John From aph at redhat.com Thu Dec 4 11:01:40 2008 From: aph at redhat.com (Andrew Haley) Date: Thu, 04 Dec 2008 19:01:40 +0000 Subject: fix hotspot build failures with -D_FORTIFY_SOURCE=2 and -Wformat=1 In-Reply-To: <493822A7.4070605@sun.com> References: <49356C74.2000700@ubuntu.com> <4935CA58.70403@sun.com> <4935DF0E.5040701@sun.com> <49368DA0.8060808@ubuntu.com> <1228314050.1541.839.camel@localhost.localdomain> <4936EB17.3070607@sun.com> <4936EDD3.6040809@ubuntu.com> <49373AB0.1000209@sun.com> <1228378964.1541.844.camel@localhost.localdomain> <493822A7.4070605@sun.com> Message-ID: <49382914.4080808@redhat.com> Kelly O'Hair wrote: > The issue seems so simple to me. > If the function return is to be ignored, you make an explicit cast > to void. This practice is so old and common I don't understand why > it's so complicated. > gcc/g++ are not the only compilers on the planet. > Writing portable C or C++ code becomes increasingly more complicated > when you have to rely on special features of the compiler to get them > to shut up about perfectly valid code. > > What happened to following the standards? > > WG14/N1124 6.3.2.2 void > > "... If an expression of any other type is evaluated as a void > expression, its value or designator is discarded. > (A void expression is evaluated for its side effects.)" Huh? The standard doesn't say that you should not warn about legal but potentially problematic code. That's what most warnings are, after all. Andrew. From Joe.Darcy at Sun.COM Thu Dec 4 11:14:47 2008 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 04 Dec 2008 11:14:47 -0800 Subject: OpenJDK 6 build 14 source posted In-Reply-To: <18744.10030.107701.463469@sun.com> References: <4936E036.7030407@sun.com> <1ccfd1c10812031704o47edf8b3j75a4b149a049278@mail.gmail.com> <4937C17F.3090904@redhat.com> <18744.10030.107701.463469@sun.com> Message-ID: <49382C27.1010102@sun.com> John Coomes wrote: > Andrew Haley (aph at redhat.com) wrote: > >> Martin Buchholz wrote: >> >>> On Wed, Dec 3, 2008 at 11:38, Joe Darcy wrote: >>> >>>> The source bundle for OpenJDK 6 build 14 is available for download from: >>>> >>>> http://download.java.net/openjdk/jdk6/ >>>> >>> The new Hotspot 11 failed to compile on a modified 64-bit (debian arch=amd64) >>> Ubuntu dapper system as follows: >>> >>> cc1plus: warnings being treated as errors >>> /usr/local/google/home/martin/ws/buildAllOpenJDK6/hotspot/src/share/vm/utilities/ostream.cpp: >>> In member function 'bool networkStream::connect(const char*, short >>> int)': >>> /usr/local/google/home/martin/ws/buildAllOpenJDK6/hotspot/src/share/vm/utilities/ostream.cpp:835: >>> warning: comparison is always false due to limited range of data type >>> >>> 32-bit systems are unaffected (not sure why). >>> >> It's a bug. The code is basically this: >> ... >> > > This is http://bugs.sun.com/view_bug.do?bug_id=6679422. FWIW, the > trivial fix is in jdk7: > > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/092ea87cc974 > > Joe, I can try to get this into jdk6-open, but not until next week at > the earliest. Let me know. > > -John > > John, Yes, please get the fix back into the OpenJDK 6 HotSpot Mercurial repository, once it is open for business. -Joe From Kelly.Ohair at Sun.COM Thu Dec 4 11:57:13 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 04 Dec 2008 11:57:13 -0800 Subject: fix hotspot build failures with -D_FORTIFY_SOURCE=2 and -Wformat=1 In-Reply-To: <49382914.4080808@redhat.com> References: <49356C74.2000700@ubuntu.com> <4935CA58.70403@sun.com> <4935DF0E.5040701@sun.com> <49368DA0.8060808@ubuntu.com> <1228314050.1541.839.camel@localhost.localdomain> <4936EB17.3070607@sun.com> <4936EDD3.6040809@ubuntu.com> <49373AB0.1000209@sun.com> <1228378964.1541.844.camel@localhost.localdomain> <493822A7.4070605@sun.com> <49382914.4080808@redhat.com> Message-ID: <49383619.3010401@sun.com> Both fwrite() and (void)fwrite() are legal, the first one is a potential error, but the later is defined by the standard as having the function return value explicitly "discarded". So warning about a value that has been explicitly "discarded" by the terms of the standard seems like a very questionable warning. -kto Andrew Haley wrote: > Kelly O'Hair wrote: >> The issue seems so simple to me. >> If the function return is to be ignored, you make an explicit cast >> to void. This practice is so old and common I don't understand why >> it's so complicated. > >> gcc/g++ are not the only compilers on the planet. >> Writing portable C or C++ code becomes increasingly more complicated >> when you have to rely on special features of the compiler to get them >> to shut up about perfectly valid code. >> >> What happened to following the standards? >> >> WG14/N1124 6.3.2.2 void >> >> "... If an expression of any other type is evaluated as a void >> expression, its value or designator is discarded. >> (A void expression is evaluated for its side effects.)" > > Huh? The standard doesn't say that you should not warn about > legal but potentially problematic code. That's what most > warnings are, after all. > > Andrew. From aph at redhat.com Thu Dec 4 12:27:41 2008 From: aph at redhat.com (Andrew Haley) Date: Thu, 04 Dec 2008 20:27:41 +0000 Subject: fix hotspot build failures with -D_FORTIFY_SOURCE=2 and -Wformat=1 In-Reply-To: <49383619.3010401@sun.com> References: <49356C74.2000700@ubuntu.com> <4935CA58.70403@sun.com> <4935DF0E.5040701@sun.com> <49368DA0.8060808@ubuntu.com> <1228314050.1541.839.camel@localhost.localdomain> <4936EB17.3070607@sun.com> <4936EDD3.6040809@ubuntu.com> <49373AB0.1000209@sun.com> <1228378964.1541.844.camel@localhost.localdomain> <493822A7.4070605@sun.com> <49382914.4080808@redhat.com> <49383619.3010401@sun.com> Message-ID: <49383D3D.9070805@redhat.com> Kelly O'Hair wrote: > Both fwrite() and (void)fwrite() are legal, > the first one is a potential error, but the later > is defined by the standard as having the function return value > explicitly "discarded". The standard doesn't distinguish between them. Both are evaluated as void expressions. > So warning about a value that has been explicitly "discarded" by > the terms of the standard seems like a very questionable warning. Perhaps so, but that is nothing to do with standards conformance, which you were questioning. Let me be clear: a C compiler is allowed to warn about anything at all, as long as every standard program is executed according to the rules of the abstract machine. Andrew. > Andrew Haley wrote: >> Kelly O'Hair wrote: >>> The issue seems so simple to me. >>> If the function return is to be ignored, you make an explicit cast >>> to void. This practice is so old and common I don't understand why >>> it's so complicated. >> >>> gcc/g++ are not the only compilers on the planet. >>> Writing portable C or C++ code becomes increasingly more complicated >>> when you have to rely on special features of the compiler to get them >>> to shut up about perfectly valid code. >>> >>> What happened to following the standards? >>> >>> WG14/N1124 6.3.2.2 void >>> >>> "... If an expression of any other type is evaluated as a void >>> expression, its value or designator is discarded. >>> (A void expression is evaluated for its side effects.)" >> >> Huh? The standard doesn't say that you should not warn about >> legal but potentially problematic code. That's what most >> warnings are, after all. >> >> Andrew. From doko at ubuntu.com Thu Dec 4 12:51:13 2008 From: doko at ubuntu.com (Matthias Klose) Date: Thu, 04 Dec 2008 21:51:13 +0100 Subject: [Fwd: changeset in /hg/icedtea6: 2008-12-04 Matthias Klose these patches are needed to build hotspot on sparc-linux. there are a few other sparc related patches in the icedtea repository. Matthias -------------- next part -------------- An embedded message was scrubbed... From: doko at ubuntu.com Subject: changeset in /hg/icedtea6: 2008-12-04 Matthias Klose Changeset: 3a86a8dcf27c Author: never Date: 2008-11-25 13:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3a86a8dcf27c 6756768: C1 generates invalid code Reviewed-by: kvn, jrose ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_ValueMap.hpp + test/compiler/6756768/Test6756768.java + test/compiler/6756768/Test6756768_2.java Changeset: 424f9bfe6b96 Author: kvn Date: 2008-12-03 13:41 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/424f9bfe6b96 6775880: EA +DeoptimizeALot: assert(mon_info->owner()->is_locked(),"object must be locked now") Summary: Create new "eliminated" BoxLock node for monitor debug info when corresponding locks are eliminated. Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/output.cpp + test/compiler/6775880/Test.java Changeset: 1f54ed41d6ae Author: kvn Date: 2008-12-04 08:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1f54ed41d6ae Merge From Kelly.Ohair at Sun.COM Thu Dec 4 13:42:00 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 04 Dec 2008 13:42:00 -0800 Subject: fix hotspot build failures with -D_FORTIFY_SOURCE=2 and -Wformat=1 In-Reply-To: <49383D3D.9070805@redhat.com> References: <49356C74.2000700@ubuntu.com> <4935CA58.70403@sun.com> <4935DF0E.5040701@sun.com> <49368DA0.8060808@ubuntu.com> <1228314050.1541.839.camel@localhost.localdomain> <4936EB17.3070607@sun.com> <4936EDD3.6040809@ubuntu.com> <49373AB0.1000209@sun.com> <1228378964.1541.844.camel@localhost.localdomain> <493822A7.4070605@sun.com> <49382914.4080808@redhat.com> <49383619.3010401@sun.com> <49383D3D.9070805@redhat.com> Message-ID: <49384EA8.6040305@sun.com> It's a quality of the compiler implementation issue. I know there are no formal standard violations here, but the intent of an explicit void cast has always been clear. -kto Andrew Haley wrote: > Kelly O'Hair wrote: >> Both fwrite() and (void)fwrite() are legal, >> the first one is a potential error, but the later >> is defined by the standard as having the function return value >> explicitly "discarded". > > The standard doesn't distinguish between them. Both are evaluated > as void expressions. > >> So warning about a value that has been explicitly "discarded" by >> the terms of the standard seems like a very questionable warning. > > Perhaps so, but that is nothing to do with standards conformance, > which you were questioning. Let me be clear: a C compiler is allowed > to warn about anything at all, as long as every standard program is > executed according to the rules of the abstract machine. > > Andrew. > > >> Andrew Haley wrote: >>> Kelly O'Hair wrote: >>>> The issue seems so simple to me. >>>> If the function return is to be ignored, you make an explicit cast >>>> to void. This practice is so old and common I don't understand why >>>> it's so complicated. >>>> gcc/g++ are not the only compilers on the planet. >>>> Writing portable C or C++ code becomes increasingly more complicated >>>> when you have to rely on special features of the compiler to get them >>>> to shut up about perfectly valid code. >>>> >>>> What happened to following the standards? >>>> >>>> WG14/N1124 6.3.2.2 void >>>> >>>> "... If an expression of any other type is evaluated as a void >>>> expression, its value or designator is discarded. >>>> (A void expression is evaluated for its side effects.)" >>> Huh? The standard doesn't say that you should not warn about >>> legal but potentially problematic code. That's what most >>> warnings are, after all. >>> >>> Andrew. > From David.Holmes at Sun.COM Thu Dec 4 17:06:53 2008 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Fri, 05 Dec 2008 11:06:53 +1000 Subject: fix hotspot build failures with -D_FORTIFY_SOURCE=2 and -Wformat=1 In-Reply-To: <49384EA8.6040305@sun.com> References: <49356C74.2000700@ubuntu.com> <4935CA58.70403@sun.com> <4935DF0E.5040701@sun.com> <49368DA0.8060808@ubuntu.com> <1228314050.1541.839.camel@localhost.localdomain> <4936EB17.3070607@sun.com> <4936EDD3.6040809@ubuntu.com> <49373AB0.1000209@sun.com> <1228378964.1541.844.camel@localhost.localdomain> <493822A7.4070605@sun.com> <49382914.4080808@redhat.com> <49383619.3010401@sun.com> <49383D3D.9070805@redhat.com> <49384EA8.6040305@sun.com> Message-ID: <49387EAD.7020202@sun.com> I don't know who is most at fault here: the glibc folk for marking these methods with an attribute that forces a warning to always be issued regardless of what the developer writes in his code, or selects for her compiler options; or the gcc folk for providing such an attribute in the first place. :-( Too much hand-holding if you ask me. But having to store into an unused local to get around this is plain absurd! David Holmes Kelly O'Hair said the following on 12/05/08 07:42: > It's a quality of the compiler implementation issue. > I know there are no formal standard violations here, but the > intent of an explicit void cast has always been clear. > > -kto > > Andrew Haley wrote: >> Kelly O'Hair wrote: >>> Both fwrite() and (void)fwrite() are legal, >>> the first one is a potential error, but the later >>> is defined by the standard as having the function return value >>> explicitly "discarded". >> >> The standard doesn't distinguish between them. Both are evaluated >> as void expressions. >> >>> So warning about a value that has been explicitly "discarded" by >>> the terms of the standard seems like a very questionable warning. >> >> Perhaps so, but that is nothing to do with standards conformance, >> which you were questioning. Let me be clear: a C compiler is allowed >> to warn about anything at all, as long as every standard program is >> executed according to the rules of the abstract machine. >> >> Andrew. >> >> >>> Andrew Haley wrote: >>>> Kelly O'Hair wrote: >>>>> The issue seems so simple to me. >>>>> If the function return is to be ignored, you make an explicit cast >>>>> to void. This practice is so old and common I don't understand why >>>>> it's so complicated. >>>>> gcc/g++ are not the only compilers on the planet. >>>>> Writing portable C or C++ code becomes increasingly more complicated >>>>> when you have to rely on special features of the compiler to get them >>>>> to shut up about perfectly valid code. >>>>> >>>>> What happened to following the standards? >>>>> >>>>> WG14/N1124 6.3.2.2 void >>>>> >>>>> "... If an expression of any other type is evaluated as a void >>>>> expression, its value or designator is discarded. >>>>> (A void expression is evaluated for its side effects.)" >>>> Huh? The standard doesn't say that you should not warn about >>>> legal but potentially problematic code. That's what most >>>> warnings are, after all. >>>> >>>> Andrew. >> From john.coomes at sun.com Thu Dec 4 20:35:18 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 05 Dec 2008 04:35:18 +0000 Subject: hg: jdk7/hotspot: 2 new changesets Message-ID: <20081205043518.D4AF1D0C2@hg.openjdk.java.net> Changeset: 541bdc5ad32f Author: ohair Date: 2008-12-01 15:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/541bdc5ad32f 6750229: Upgrade Recommended Linux and Windows Build OS Reviewed-by: xdono ! README-builds.html Changeset: a20db75d7f33 Author: xdono Date: 2008-12-04 11:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/a20db75d7f33 Added tag jdk7-b41 for changeset 541bdc5ad32f ! .hgtags From john.coomes at sun.com Thu Dec 4 20:37:06 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 05 Dec 2008 04:37:06 +0000 Subject: hg: jdk7/hotspot/corba: Added tag jdk7-b41 for changeset c90eeda9594e Message-ID: <20081205043708.39339D0C7@hg.openjdk.java.net> Changeset: d9a0ca94dcf8 Author: xdono Date: 2008-12-04 11:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/d9a0ca94dcf8 Added tag jdk7-b41 for changeset c90eeda9594e ! .hgtags From john.coomes at sun.com Thu Dec 4 20:41:26 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 05 Dec 2008 04:41:26 +0000 Subject: hg: jdk7/hotspot/jaxp: Added tag jdk7-b41 for changeset 0758bd3e2852 Message-ID: <20081205044129.4F93DD0CC@hg.openjdk.java.net> Changeset: 036e0dca841a Author: xdono Date: 2008-12-04 11:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/036e0dca841a Added tag jdk7-b41 for changeset 0758bd3e2852 ! .hgtags From john.coomes at sun.com Thu Dec 4 20:43:17 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 05 Dec 2008 04:43:17 +0000 Subject: hg: jdk7/hotspot/jaxws: Added tag jdk7-b41 for changeset a8379d24aa03 Message-ID: <20081205044319.9D056D0D1@hg.openjdk.java.net> Changeset: 621c02d83abc Author: xdono Date: 2008-12-04 11:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/621c02d83abc Added tag jdk7-b41 for changeset a8379d24aa03 ! .hgtags From john.coomes at sun.com Thu Dec 4 20:45:26 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 05 Dec 2008 04:45:26 +0000 Subject: hg: jdk7/hotspot/jdk: 17 new changesets Message-ID: <20081205044859.904ACD0D6@hg.openjdk.java.net> Changeset: 5102df668164 Author: mullan Date: 2008-11-05 15:55 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5102df668164 6744888: OCSP validation code should permit some clock skew when checking validity of OCSP responses Summary: Allow for up to 10 minutes of clock skew when validating OCSP responses Reviewed-by: vinnie ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java Changeset: 6923a82c1036 Author: mullan Date: 2008-11-06 11:58 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6923a82c1036 Merge Changeset: 3a3e02a55de8 Author: mullan Date: 2008-11-06 12:12 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3a3e02a55de8 6765046: CertPathValidatorException(Throwable).getMessage() always returns null since b37 Reviewed-by: vinnie ! src/share/classes/java/security/cert/CertPathValidatorException.java + test/java/security/cert/CertPathValidatorException/GetMessage.java Changeset: 810a95940b99 Author: emcmanus Date: 2008-11-07 11:48 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/810a95940b99 5072267: A way to communicate client context such as locale to the JMX server Summary: Support for client contexts and also for localization of descriptions Reviewed-by: dfuchs ! src/share/classes/com/sun/jmx/defaults/ServiceName.java ! src/share/classes/com/sun/jmx/event/EventParams.java ! src/share/classes/com/sun/jmx/event/LeaseManager.java ! src/share/classes/com/sun/jmx/interceptor/SingleMBeanForwarder.java ! src/share/classes/com/sun/jmx/mbeanserver/JmxMBeanServer.java - src/share/classes/com/sun/jmx/namespace/JMXNamespaceUtils.java ! src/share/classes/com/sun/jmx/namespace/ObjectNameRouter.java ! src/share/classes/com/sun/jmx/namespace/RoutingConnectionProxy.java ! src/share/classes/com/sun/jmx/namespace/RoutingProxy.java ! src/share/classes/com/sun/jmx/namespace/RoutingServerProxy.java ! src/share/classes/com/sun/jmx/remote/util/EventClientConnection.java + src/share/classes/javax/management/ClientContext.java ! src/share/classes/javax/management/Descriptor.java ! src/share/classes/javax/management/JMX.java ! src/share/classes/javax/management/MBeanInfo.java ! src/share/classes/javax/management/MBeanServerNotification.java ! src/share/classes/javax/management/Notification.java ! src/share/classes/javax/management/event/EventClient.java ! src/share/classes/javax/management/event/EventClientDelegate.java ! src/share/classes/javax/management/event/EventClientDelegateMBean.java ! src/share/classes/javax/management/event/EventRelay.java ! src/share/classes/javax/management/event/package-info.java ! src/share/classes/javax/management/namespace/JMXNamespaces.java ! src/share/classes/javax/management/namespace/JMXRemoteNamespace.java ! src/share/classes/javax/management/remote/JMXConnectorFactory.java ! src/share/classes/javax/management/remote/JMXConnectorServer.java ! src/share/classes/javax/management/remote/JMXConnectorServerMBean.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! test/javax/management/Introspector/AnnotationTest.java + test/javax/management/context/ContextForwarderTest.java + test/javax/management/context/ContextTest.java + test/javax/management/context/LocaleAwareBroadcasterTest.java + test/javax/management/context/LocaleTest.java + test/javax/management/context/LocalizableTest.java + test/javax/management/context/RemoteContextTest.java + test/javax/management/context/localizable/MBeanDescriptions.properties + test/javax/management/context/localizable/MBeanDescriptions_fr.java + test/javax/management/context/localizable/Whatsit.java + test/javax/management/context/localizable/WhatsitMBean.java ! test/javax/management/eventService/CustomForwarderTest.java ! test/javax/management/eventService/EventClientExecutorTest.java ! test/javax/management/eventService/EventManagerTest.java ! test/javax/management/eventService/ListenerTest.java ! test/javax/management/eventService/NotSerializableNotifTest.java ! test/javax/management/eventService/UsingEventService.java ! test/javax/management/namespace/EventWithNamespaceControlTest.java ! test/javax/management/namespace/JMXNamespaceSecurityTest.java ! test/javax/management/namespace/JMXNamespaceViewTest.java ! test/javax/management/namespace/JMXRemoteTargetNamespace.java ! test/javax/management/namespace/NamespaceNotificationsTest.java ! test/javax/management/namespace/NullDomainObjectNameTest.java ! test/javax/management/namespace/NullObjectNameTest.java ! test/javax/management/openmbean/CompositeDataStringTest.java ! test/javax/management/remote/mandatory/connectorServer/ForwarderChainTest.java ! test/javax/management/remote/mandatory/connectorServer/StandardForwardersTest.java ! test/javax/management/remote/mandatory/provider/ProviderTest.java ! test/javax/management/remote/mandatory/subjectDelegation/SimpleStandard.java Changeset: 2410a0b48d06 Author: emcmanus Date: 2008-11-07 19:19 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2410a0b48d06 6336968: Methods to convert AttributeList to/from Map 6750008: Add JMX.getSpecificationVersion(MBeanServerConnection) and document interop 6750472: Add a way to convert a CompositeData into a Map 6752563: Allow CompositeDataSupport to have zero items Summary: Small JMX RFEs Reviewed-by: dfuchs ! src/share/classes/javax/management/AttributeList.java ! src/share/classes/javax/management/JMX.java ! src/share/classes/javax/management/MBeanServerConnection.java ! src/share/classes/javax/management/MBeanServerNotification.java ! src/share/classes/javax/management/QueryNotificationFilter.java ! src/share/classes/javax/management/openmbean/CompositeDataSupport.java ! src/share/classes/javax/management/package.html + test/javax/management/MBeanServer/AttributeListMapTest.java + test/javax/management/MBeanServer/AttributeListTypeSafeTest.java + test/javax/management/openmbean/CompositeDataToMapTest.java + test/javax/management/remote/mandatory/version/JMXSpecVersionTest.java Changeset: 275fa248e808 Author: alanb Date: 2008-11-11 08:59 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/275fa248e808 6763122: ZipFile ctor does not throw exception when file is not a zip file Reviewed-by: bristor ! src/share/native/java/util/zip/zip_util.c ! test/java/util/zip/TestEmptyZip.java Changeset: e81b47f0b40f Author: alanb Date: 2008-11-11 09:07 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e81b47f0b40f Merge - src/share/classes/com/sun/jmx/namespace/JMXNamespaceUtils.java Changeset: d2f96992b77b Author: weijun Date: 2008-11-12 16:00 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d2f96992b77b 6733095: Failure when SPNEGO request non-Mutual Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/GSSContextImpl.java ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java ! test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/NonMutualSpnego.java Changeset: 76edd0698e0a Author: weijun Date: 2008-11-12 16:01 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/76edd0698e0a 6765491: Krb5LoginModule a little too restrictive, and the doc is not clear. Reviewed-by: valeriep ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! test/sun/security/krb5/auto/Context.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/auto/LoginModuleOptions.java Changeset: a85ef87f9eaa Author: chegar Date: 2008-11-12 16:38 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a85ef87f9eaa 6755625: Add HttpURLConnection.setFixedLengthStreamingMode(long) Reviewed-by: jccollet ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnectionOldImpl.java ! src/share/classes/java/net/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/https/HttpsURLConnectionImpl.java ! test/com/sun/net/httpserver/bugs/FixedLengthInputStream.java Changeset: 84bd7fd5fb65 Author: chegar Date: 2008-11-13 09:40 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/84bd7fd5fb65 Merge Changeset: 5c1a8571946f Author: tbell Date: 2008-11-13 11:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5c1a8571946f Merge - src/share/classes/com/sun/jmx/namespace/JMXNamespaceUtils.java Changeset: 16efbe49c725 Author: xuelei Date: 2008-11-13 23:08 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/16efbe49c725 6728126: Parsing Extensions in Client Hello message is done in a wrong way Summary: the inputStream.read(byte[], int, 0) is not always return zero. Reviewed-by: wetmore, weijun ! src/share/classes/sun/security/ssl/HelloExtensions.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/EmptyExtensionData.java Changeset: dcb8d806d731 Author: xuelei Date: 2008-11-13 23:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/dcb8d806d731 6745052: SLServerSocket file descriptor leak Summary: SSLServerSocketImpl.checkEnabledSuites() does not release the temporary socket properly Reviewed-by: wetmore, weijun ! src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: 67718d2bd49c Author: dfuchs Date: 2008-11-14 17:22 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/67718d2bd49c 6683213: CounterMonitor's derived Gauge badly initialized Reviewed-by: emcmanus ! src/share/classes/javax/management/monitor/CounterMonitor.java ! src/share/classes/javax/management/monitor/GaugeMonitor.java ! src/share/classes/javax/management/monitor/Monitor.java + test/javax/management/monitor/DerivedGaugeMonitorTest.java Changeset: 44941f893cea Author: tbell Date: 2008-11-21 15:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/44941f893cea Merge Changeset: b213ea31bcb3 Author: xdono Date: 2008-12-04 11:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b213ea31bcb3 Added tag jdk7-b41 for changeset 44941f893cea ! .hgtags From john.coomes at sun.com Thu Dec 4 20:54:27 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 05 Dec 2008 04:54:27 +0000 Subject: hg: jdk7/hotspot/langtools: 3 new changesets Message-ID: <20081205045433.BC223D0DB@hg.openjdk.java.net> Changeset: 4cdaaf4c5dca Author: mcimadamore Date: 2008-11-12 14:17 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/4cdaaf4c5dca 6768932: Add support for multiline diagnostics Summary: Added basic support for multiline/tabular diagnostics Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/AbstractLog.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/LayoutCharacters.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java Changeset: ded6b40f558e Author: tbell Date: 2008-11-21 15:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/ded6b40f558e Merge Changeset: 1d4f01925bd0 Author: xdono Date: 2008-12-04 11:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/1d4f01925bd0 Added tag jdk7-b41 for changeset ded6b40f558e ! .hgtags From mark at klomp.org Fri Dec 5 01:13:36 2008 From: mark at klomp.org (Mark Wielaard) Date: Fri, 05 Dec 2008 10:13:36 +0100 Subject: OpenJDK 6 build 14 source posted In-Reply-To: <18744.10030.107701.463469@sun.com> References: <4936E036.7030407@sun.com> <1ccfd1c10812031704o47edf8b3j75a4b149a049278@mail.gmail.com> <4937C17F.3090904@redhat.com> <18744.10030.107701.463469@sun.com> Message-ID: <1228468416.3521.13.camel@dijkstra.wildebeest.org> Hi John, On Thu, 2008-12-04 at 10:53 -0800, John Coomes wrote: > > > 32-bit systems are unaffected (not sure why). > > > > It's a bug. The code is basically this: > > ... > > This is http://bugs.sun.com/view_bug.do?bug_id=6679422. FWIW, the > trivial fix is in jdk7: > > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/092ea87cc974 In the icedtea-signed-types.patch (part of the PPC work for zero and cacao from Gary and Christian [1]) the fix is to cast it to (in_addr_t), which seems slightly cleaner to me since you already have that as typedef. Cheers, Mark [1] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2007-November/000562.html From Coleen.Phillimore at Sun.COM Fri Dec 5 04:37:50 2008 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore) Date: Fri, 05 Dec 2008 07:37:50 -0500 Subject: fix hotspot build failures with -D_FORTIFY_SOURCE=2 and -Wformat=1 In-Reply-To: <49387EAD.7020202@sun.com> References: <49356C74.2000700@ubuntu.com> <4935CA58.70403@sun.com> <4935DF0E.5040701@sun.com> <49368DA0.8060808@ubuntu.com> <1228314050.1541.839.camel@localhost.localdomain> <4936EB17.3070607@sun.com> <4936EDD3.6040809@ubuntu.com> <49373AB0.1000209@sun.com> <1228378964.1541.844.camel@localhost.localdomain> <493822A7.4070605@sun.com> <49382914.4080808@redhat.com> <49383619.3010401@sun.com> <49383D3D.9070805@redhat.com> <49384EA8.6040305@sun.com> <49387EAD.7020202@sun.com> Message-ID: <4939209E.9080406@sun.com> Are there pragmas in gcc to disable selected warning messages like there are in the windows Visual C++ and as far as I can remember, the EDG front ends? An implementation is free to warn about whatever it wants but generally provides pragmas or command line options to disable certain warnings. It's better than turning them all off or remembering to write silly code to satisfy a certain compiler. Coleen David Holmes - Sun Microsystems wrote: > I don't know who is most at fault here: the glibc folk for marking > these methods with an attribute that forces a warning to always be > issued regardless of what the developer writes in his code, or selects > for her compiler options; or the gcc folk for providing such an > attribute in the first place. :-( Too much hand-holding if you ask me. > > But having to store into an unused local to get around this is plain > absurd! > > David Holmes > > Kelly O'Hair said the following on 12/05/08 07:42: >> It's a quality of the compiler implementation issue. >> I know there are no formal standard violations here, but the >> intent of an explicit void cast has always been clear. >> >> -kto >> >> Andrew Haley wrote: >>> Kelly O'Hair wrote: >>>> Both fwrite() and (void)fwrite() are legal, >>>> the first one is a potential error, but the later >>>> is defined by the standard as having the function return value >>>> explicitly "discarded". >>> >>> The standard doesn't distinguish between them. Both are evaluated >>> as void expressions. >>> >>>> So warning about a value that has been explicitly "discarded" by >>>> the terms of the standard seems like a very questionable warning. >>> >>> Perhaps so, but that is nothing to do with standards conformance, >>> which you were questioning. Let me be clear: a C compiler is allowed >>> to warn about anything at all, as long as every standard program is >>> executed according to the rules of the abstract machine. >>> >>> Andrew. >>> >>> >>>> Andrew Haley wrote: >>>>> Kelly O'Hair wrote: >>>>>> The issue seems so simple to me. >>>>>> If the function return is to be ignored, you make an explicit cast >>>>>> to void. This practice is so old and common I don't understand why >>>>>> it's so complicated. >>>>>> gcc/g++ are not the only compilers on the planet. >>>>>> Writing portable C or C++ code becomes increasingly more complicated >>>>>> when you have to rely on special features of the compiler to get >>>>>> them >>>>>> to shut up about perfectly valid code. >>>>>> >>>>>> What happened to following the standards? >>>>>> >>>>>> WG14/N1124 6.3.2.2 void >>>>>> >>>>>> "... If an expression of any other type is evaluated as a void >>>>>> expression, its value or designator is discarded. >>>>>> (A void expression is evaluated for its side effects.)" >>>>> Huh? The standard doesn't say that you should not warn about >>>>> legal but potentially problematic code. That's what most >>>>> warnings are, after all. >>>>> >>>>> Andrew. >>> From John.Coomes at sun.com Fri Dec 5 10:22:03 2008 From: John.Coomes at sun.com (John Coomes) Date: Fri, 5 Dec 2008 10:22:03 -0800 Subject: OpenJDK 6 build 14 source posted In-Reply-To: <1228468416.3521.13.camel@dijkstra.wildebeest.org> References: <4936E036.7030407@sun.com> <1ccfd1c10812031704o47edf8b3j75a4b149a049278@mail.gmail.com> <4937C17F.3090904@redhat.com> <18744.10030.107701.463469@sun.com> <1228468416.3521.13.camel@dijkstra.wildebeest.org> Message-ID: <18745.29003.253664.806959@sun.com> Mark Wielaard (mark at klomp.org) wrote: > Hi John, > > On Thu, 2008-12-04 at 10:53 -0800, John Coomes wrote: > > > > 32-bit systems are unaffected (not sure why). > > > > > > It's a bug. The code is basically this: > > > ... > > > > This is http://bugs.sun.com/view_bug.do?bug_id=6679422. FWIW, the > > trivial fix is in jdk7: > > > > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/092ea87cc974 > > In the icedtea-signed-types.patch (part of the PPC work for zero and > cacao from Gary and Christian [1]) the fix is to cast it to (in_addr_t), > which seems slightly cleaner to me since you already have that as > typedef. Hi Mark, IIRC, the in_addr_t typedef is missing on windows. I'll double check before submitting a fix. -John > [1] > http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2007-November/000562.html > From aph at redhat.com Fri Dec 5 10:26:53 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 05 Dec 2008 18:26:53 +0000 Subject: OpenJDK 6 build 14 source posted In-Reply-To: <18745.29003.253664.806959@sun.com> References: <4936E036.7030407@sun.com> <1ccfd1c10812031704o47edf8b3j75a4b149a049278@mail.gmail.com> <4937C17F.3090904@redhat.com> <18744.10030.107701.463469@sun.com> <1228468416.3521.13.camel@dijkstra.wildebeest.org> <18745.29003.253664.806959@sun.com> Message-ID: <4939726D.1060503@redhat.com> John Coomes wrote: > Mark Wielaard (mark at klomp.org) wrote: >> Hi John, >> >> On Thu, 2008-12-04 at 10:53 -0800, John Coomes wrote: >>>>> 32-bit systems are unaffected (not sure why). >>>> It's a bug. The code is basically this: >>>> ... >>> This is http://bugs.sun.com/view_bug.do?bug_id=6679422. FWIW, the >>> trivial fix is in jdk7: >>> >>> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/092ea87cc974 >> In the icedtea-signed-types.patch (part of the PPC work for zero and >> cacao from Gary and Christian [1]) the fix is to cast it to (in_addr_t), >> which seems slightly cleaner to me since you already have that as >> typedef. > > Hi Mark, > > IIRC, the in_addr_t typedef is missing on windows. I'll double check > before submitting a fix. Probably is. Maybe int32_t is the best portable solution, unpleasant tho' it is. Andrew. From jon.masamitsu at sun.com Fri Dec 5 11:13:28 2008 From: jon.masamitsu at sun.com (jon.masamitsu at sun.com) Date: Fri, 05 Dec 2008 19:13:28 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20081205191333.E19A4D1AB@hg.openjdk.java.net> Changeset: 85f1b9537f70 Author: iveresov Date: 2008-12-03 14:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/85f1b9537f70 6779436: NUMA allocator: libnuma expects certain size of the buffer in numa_node_to_cpus() Summary: In os::Linux::rebuild_cpu_to_node_map() fix the size of the CPU bitmap. Fixed arithmetic in MutableNUMASpace::adaptive_chunk_size() that could cause overflows and underflows of the chunk_size variable. Reviewed-by: apetrusenko ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/runtime/globals.hpp Changeset: ab25f609be4a Author: jmasa Date: 2008-12-04 09:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ab25f609be4a Merge Changeset: 8a0c882e46d6 Author: jmasa Date: 2008-12-04 13:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8a0c882e46d6 Merge From Xiaobin.Lu at Sun.COM Fri Dec 5 11:28:31 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Fri, 05 Dec 2008 11:28:31 -0800 Subject: review request for 6781583 Message-ID: <493980DF.4030004@Sun.COM> Webrev: http://webrev.invokedynamic.info/xiaobin.lu/6781583/webrev/ Details: Due to more restrictions on implicit type conversion put to the latest GCC compiler such as GCC 4.3.2, the hotspot build fails on 64 bit platforms. I've fixed part of the problem on 32 bit platform with 6718830 & 6681796, however, I just noticed that we need to do more on 64 bit platforms as well. One of the thing you might notice with the fix is that I explicitly use "%lld" to print jlong instead of using PTR_FORMAT. The reason of doing this is that jlong is defined as "long long int", and PTR_FORMAT is actually used to print "long int" on 64 bit platforms. GCC 4.3.2 doesn't even allow conversions between "long long" and "long" even though they have the same size on most of today's 64 bit platforms. Other part of the fix is pretty straightforward. Reviewed by: Verified by: JPRT Built on 32 bit GCC 4.3.2 and it succeeded Thanks, -Xiaobin From martinrb at google.com Fri Dec 5 12:26:42 2008 From: martinrb at google.com (Martin Buchholz) Date: Fri, 5 Dec 2008 12:26:42 -0800 Subject: review request for 6781583 In-Reply-To: <493980DF.4030004@Sun.COM> References: <493980DF.4030004@Sun.COM> Message-ID: <1ccfd1c10812051226j4d92106bnf02fb664298cb443@mail.gmail.com> I think the JDK should provide, along with every "java native" type like jlong, a format macro that can be used along with that type in format strings. This should be done in the same header file that provides the type. This would allow not only code in the JDK, but also user native code, to be able to use format strings portably. E.g. here's jni_md.h #ifdef _LP64 /* 64-bit Solaris */ typedef long jlong; #else typedef long long jlong; #endif we could do something like #ifdef _LP64 /* 64-bit Solaris */ typedef long jlong; #define JNI_PRIjlong "ld" #else typedef long long jlong; #define JNI_PRIjlong "lld" #endif This would be more work, because it would be a change to the Java Platform (JNI spec), but it's the right thing to do. Martin On Fri, Dec 5, 2008 at 11:28, Xiaobin Lu wrote: > Webrev: http://webrev.invokedynamic.info/xiaobin.lu/6781583/webrev/ > > Details: > > Due to more restrictions on implicit type conversion put to the latest GCC > compiler such as GCC 4.3.2, the hotspot build fails on 64 bit platforms. > I've fixed part of the problem on 32 bit platform with 6718830 & 6681796, > however, I just noticed that we need to do more on 64 bit platforms as well. > > One of the thing you might notice with the fix is that I explicitly use > "%lld" to print jlong instead of using PTR_FORMAT. The reason of doing this > is that jlong is defined as "long long int", and PTR_FORMAT is actually used > to print "long int" on 64 bit platforms. GCC 4.3.2 doesn't even allow > conversions between "long long" and "long" even though they have the same > size on most of today's 64 bit platforms. Other part of the fix is pretty > straightforward. > > Reviewed by: > > Verified by: > JPRT > Built on 32 bit GCC 4.3.2 and it succeeded > > Thanks, > -Xiaobin > > > From lev.serebryakov at sun.com Fri Dec 5 14:40:22 2008 From: lev.serebryakov at sun.com (lev.serebryakov at sun.com) Date: Fri, 05 Dec 2008 22:40:22 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20081205224059.5E949D266@hg.openjdk.java.net> Changeset: dc16daa0329d Author: poonam Date: 2008-12-04 17:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/dc16daa0329d 6739363: Xcheck jni doesn't check native function arguments Summary: Fix adds support for verifying arguments with -Xcheck:jni. Reviewed-by: coleenp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/includeDB_core ! src/share/vm/includeDB_features ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jniCheck.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 63d1bf926938 Author: poonam Date: 2008-12-04 17:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/63d1bf926938 Merge - src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.hpp Changeset: 8724fb00c422 Author: blacklion Date: 2008-12-05 15:06 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8724fb00c422 Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/includeDB_core From Xiaobin.Lu at Sun.COM Fri Dec 5 18:40:21 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Fri, 05 Dec 2008 18:40:21 -0800 Subject: review request for 6781583 In-Reply-To: <493980DF.4030004@Sun.COM> References: <493980DF.4030004@Sun.COM> Message-ID: <4939E615.1090001@Sun.COM> Webrev updated: http://webrev.invokedynamic.info/xiaobin.lu/6781583/webrev/ Thanks to everyone who replied to my review request. I did a full compilation on Ubuntu 8.10 and notice that the product build actually generated some other compilation errors. I believe these were discussed earlier. So I made some more changes and now the compilation succeeds on both jvmg and product build. The build also passed on latest OpenSolaris build. Here is some explanation on the changes: 1. I modified "jlong" definition to make it conform with the definition on JDK side. This change will make the complaint about using INT64_FORMAT to print data types with "long long". So now, it is perfect ok to use INT64_FORMAT to print jlong. 2. There is some weird change in javaClasses.cpp which casts "nmethod* nm" to "intptr_t". This has to be done since otherwise, gcc will complain about using PTR_FORMAT (which isn't defined as "%p", but as "0x%016x") to print nmethod*. We could change PTR_FORMAT to use %p, but "%p" has its own issue since it does not prepend "0x" to the data on Windows & Solaris. So I would rather leave that as is for now. 3. I added a few return values on some system/library calls to avoid compiler error. I believe it is better to fix these places rather than just removing "-Werror" from gcc.make. Luckily, we don't have many of those. Feel free to let me know your thoughts. Thanks, -Xiaobin Xiaobin Lu wrote: > Webrev: http://webrev.invokedynamic.info/xiaobin.lu/6781583/webrev/ > > Details: > > Due to more restrictions on implicit type conversion put to the latest > GCC compiler such as GCC 4.3.2, the hotspot build fails on 64 bit > platforms. I've fixed part of the problem on 32 bit platform with > 6718830 & 6681796, however, I just noticed that we need to do more on > 64 bit platforms as well. > > One of the thing you might notice with the fix is that I explicitly > use "%lld" to print jlong instead of using PTR_FORMAT. The reason of > doing this is that jlong is defined as "long long int", and PTR_FORMAT > is actually used to print "long int" on 64 bit platforms. GCC 4.3.2 > doesn't even allow conversions between "long long" and "long" even > though they have the same size on most of today's 64 bit platforms. > Other part of the fix is pretty straightforward. > > Reviewed by: > > Verified by: > JPRT > Built on 32 bit GCC 4.3.2 and it succeeded > > Thanks, > -Xiaobin > > From erik.trimble at sun.com Fri Dec 5 20:50:22 2008 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Sat, 06 Dec 2008 04:50:22 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20081206045031.38763D292@hg.openjdk.java.net> Changeset: 2e4f74ff86a1 Author: xdono Date: 2008-12-04 11:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2e4f74ff86a1 Added tag jdk7-b41 for changeset f9d938ede196 ! .hgtags Changeset: 7cee1a61ffd7 Author: trims Date: 2008-12-05 15:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7cee1a61ffd7 Merge Changeset: 3c4d36b4a7ac Author: trims Date: 2008-12-05 15:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3c4d36b4a7ac 6781742: Bump HS14 build number to 09 Summary: Update Hotspot 14 build number to b09 Reviewed-by: jcoomes ! make/hotspot_version From Xiaobin.Lu at Sun.COM Sun Dec 7 21:47:32 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Sun, 07 Dec 2008 21:47:32 -0800 Subject: fix hotspot build failures with -D_FORTIFY_SOURCE=2 and -Wformat=1 In-Reply-To: <49387EAD.7020202@sun.com> References: <49356C74.2000700@ubuntu.com> <4935CA58.70403@sun.com> <4935DF0E.5040701@sun.com> <49368DA0.8060808@ubuntu.com> <1228314050.1541.839.camel@localhost.localdomain> <4936EB17.3070607@sun.com> <4936EDD3.6040809@ubuntu.com> <49373AB0.1000209@sun.com> <1228378964.1541.844.camel@localhost.localdomain> <493822A7.4070605@sun.com> <49382914.4080808@redhat.com> <49383619.3010401@sun.com> <49383D3D.9070805@redhat.com> <49384EA8.6040305@sun.com> <49387EAD.7020202@sun.com> Message-ID: <493CB4F4.7090203@Sun.COm> FYI, I've filed bug 6781583 to address this, there are also some casts problems when doing compilation on 64 bit platforms. I agree it is ugly to use a unused local variable to make the aggressive compiler happy, but I don't find other options such as pragam etc to get around this. Luckily, we don't have many of these except for a few fwrite and write calls, so it is not so bad to just put unused variables there ( I would also put a comment to tell why it is there.) -Xiaobin David Holmes - Sun Microsystems wrote: > I don't know who is most at fault here: the glibc folk for marking > these methods with an attribute that forces a warning to always be > issued regardless of what the developer writes in his code, or selects > for her compiler options; or the gcc folk for providing such an > attribute in the first place. :-( Too much hand-holding if you ask me. > > But having to store into an unused local to get around this is plain > absurd! > > David Holmes > > Kelly O'Hair said the following on 12/05/08 07:42: >> It's a quality of the compiler implementation issue. >> I know there are no formal standard violations here, but the >> intent of an explicit void cast has always been clear. >> >> -kto >> >> Andrew Haley wrote: >>> Kelly O'Hair wrote: >>>> Both fwrite() and (void)fwrite() are legal, >>>> the first one is a potential error, but the later >>>> is defined by the standard as having the function return value >>>> explicitly "discarded". >>> >>> The standard doesn't distinguish between them. Both are evaluated >>> as void expressions. >>> >>>> So warning about a value that has been explicitly "discarded" by >>>> the terms of the standard seems like a very questionable warning. >>> >>> Perhaps so, but that is nothing to do with standards conformance, >>> which you were questioning. Let me be clear: a C compiler is allowed >>> to warn about anything at all, as long as every standard program is >>> executed according to the rules of the abstract machine. >>> >>> Andrew. >>> >>> >>>> Andrew Haley wrote: >>>>> Kelly O'Hair wrote: >>>>>> The issue seems so simple to me. >>>>>> If the function return is to be ignored, you make an explicit cast >>>>>> to void. This practice is so old and common I don't understand why >>>>>> it's so complicated. >>>>>> gcc/g++ are not the only compilers on the planet. >>>>>> Writing portable C or C++ code becomes increasingly more complicated >>>>>> when you have to rely on special features of the compiler to get >>>>>> them >>>>>> to shut up about perfectly valid code. >>>>>> >>>>>> What happened to following the standards? >>>>>> >>>>>> WG14/N1124 6.3.2.2 void >>>>>> >>>>>> "... If an expression of any other type is evaluated as a void >>>>>> expression, its value or designator is discarded. >>>>>> (A void expression is evaluated for its side effects.)" >>>>> Huh? The standard doesn't say that you should not warn about >>>>> legal but potentially problematic code. That's what most >>>>> warnings are, after all. >>>>> >>>>> Andrew. >>> From twisti at complang.tuwien.ac.at Mon Dec 8 03:18:48 2008 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Mon, 08 Dec 2008 12:18:48 +0100 Subject: review request for 6781583 In-Reply-To: <4939E615.1090001@Sun.COM> References: <493980DF.4030004@Sun.COM> <4939E615.1090001@Sun.COM> Message-ID: <1228735128.980.12.camel@localhost.localdomain> On Fri, 2008-12-05 at 18:40 -0800, Xiaobin Lu wrote: > 1. I modified "jlong" definition to make it conform with the definition > on JDK side. This change will make the complaint about using > INT64_FORMAT to print data types with "long long". So now, it is perfect > ok to use INT64_FORMAT to print jlong. Yes, I think that's what a jlong should be on 64-bit architectures. > > 2. There is some weird change in javaClasses.cpp which casts "nmethod* > nm" to "intptr_t". This has to be done since otherwise, gcc will > complain about using PTR_FORMAT (which isn't defined as "%p", but as > "0x%016x") to print nmethod*. We could change PTR_FORMAT to use %p, but > "%p" has its own issue since it does not prepend "0x" to the data on > Windows & Solaris. So I would rather leave that as is for now. > > 3. I added a few return values on some system/library calls to avoid > compiler error. I believe it is better to fix these places rather than > just removing "-Werror" from gcc.make. Luckily, we don't have many of those. Using an assert on the return values looks like the best thing to do here. - Christian From tromey at redhat.com Mon Dec 8 10:37:26 2008 From: tromey at redhat.com (Tom Tromey) Date: Mon, 08 Dec 2008 11:37:26 -0700 Subject: fix hotspot build failures with -D_FORTIFY_SOURCE=2 and -Wformat=1 In-Reply-To: <493CB4F4.7090203@Sun.COm> (Xiaobin Lu's message of "Sun\, 07 Dec 2008 21\:47\:32 -0800") References: <49356C74.2000700@ubuntu.com> <4935CA58.70403@sun.com> <4935DF0E.5040701@sun.com> <49368DA0.8060808@ubuntu.com> <1228314050.1541.839.camel@localhost.localdomain> <4936EB17.3070607@sun.com> <4936EDD3.6040809@ubuntu.com> <49373AB0.1000209@sun.com> <1228378964.1541.844.camel@localhost.localdomain> <493822A7.4070605@sun.com> <49382914.4080808@redhat.com> <49383619.3010401@sun.com> <49383D3D.9070805@redhat.com> <49384EA8.6040305@sun.com> <49387EAD.7020202@sun.com> <493CB4F4.7090203@Sun.COm> Message-ID: >>>>> ">" == Xiaobin Lu writes: >> I agree it is ugly to use a unused local variable to make the >> aggressive compiler happy, but I don't find other options such as >> pragam etc to get around this. You could try an inline wrapper function. This did not warn for me: int fn () __attribute__ ((warn_unused_result)); static inline int fn2() { return fn (); } int foo () { fn2 (); return 0; } I don't know whether or not this would be considered a bug in gcc, though. Tom From edilee at gmail.com Tue Dec 9 10:07:25 2008 From: edilee at gmail.com (Edward Lee) Date: Tue, 9 Dec 2008 12:07:25 -0600 Subject: Odd Loop x86 CodeGen Behavior Message-ID: Some reason codegen is adding unnecessary stores that in turn cause unnecessary loads to be added. Below is a snippet of the output of opto assembly after some changes I've done to the nodes such as removing the safepoint for this particular backedge. Any tips on where I should look would be useful. The high level code is doing HashMap.get where the object has a custom equals method inlined that checks a long field. Kinda like.. if (entry.hash == hash_ECX && entry.key.longField == long_ESP_64) The odd behavior is in B8 and B10, where long_ESP_64 gets loaded into EAX,EDX in B8 and written back to the stack in B10 even though both pair of load/stores are unnecessary. It seems that code gen is confused by the fact that B3 loads long_ESP_64 into EAX,EDX for the long compare and the branch from B3->B9 has a higher frequency (0.029548) than the branch B2->B8 (0.023747). But the really odd thing is why does B10 even exist in the first place? There's no point in writing EAX,EDX back to the stack, and this seems to be purely an artifact of code gen as the ideal graph doesn't have any store nodes to that location. 080 B2: # B8 B3 <- B1 B10 Loop: B2-B10 inner Freq: 1.01271 080 MOV EDI,[EBX + #8] ! Field java/util/HashMap$Entry.hash 083 CMP EDI,ECX 085 Jne,s B8 P=0.023747 C=6443.000000 085 087 B3: # B9 B4 <- B2 Freq: 0.98866 087 MOV ESI,[EBX + #12] ! Field java/util/HashMap$Entry.key 08a MOV EBP.lo,[ESI + #8] MOV EBP.hi,[ESI + #8]+4 ! Field customEquals.longField 090 MOV EAX,[ESP + #64] MOV EDX,[ESP + #68] 098 CMP EAX.lo,EBP.lo ! Long compare; set flags for low bits JNE,s skip CMP EAX.hi,EBP.hi skip: 09e Jne,s B9 P=0.029548 C=6701.000000 09e 0a0 B4: # B5 <- B3 B9 Freq: 0.959448 0a0 MOV EBX,[EBX + #16] ! Field java/util/HashMap$Entry.value ... 0d8 RET 0e0 B8: # B9 <- B2 Freq: 0.0240485 0e0 MOV EAX,[ESP + #64] MOV EDX,[ESP + #68] 0e0 0e8 B9: # B7 B10 <- B3 B8 Freq: 0.0532613 0e8 MOV EBX,[EBX + #20] ! Field java/util/HashMap$Entry.next 0eb TEST EBX,EBX 0ed Je,s B4 P=0.038502 C=718.000000 0ed 0ef B10: # B2 <- B9 Freq: 0.0512106 0ef MOV [ESP + #64],EAX MOV [ESP + #68],EDX 0f7 JMP B2 Ed From edilee at gmail.com Tue Dec 9 10:52:39 2008 From: edilee at gmail.com (Edward Lee) Date: Tue, 9 Dec 2008 12:52:39 -0600 Subject: Scalar replacable object pointers won't be equal to anything else Message-ID: I've been running into several instances of HashMap.get(new Packed(v1, v2)) used to retrieve items that have Keys with custom equals() methods. Part of HashMap.get() checks if the entry's key is == equal to the argument key before using equals(). This behavior prevents inlined NoEscape objects from having its allocation removed, so when the newly allocated object's field accesses are optimized to earlier memory references, the only use of the object is a pointer comparison that will always be false. Attached is a quick patch that converts potentially scalar replacable object's CmpP use into a not-equal value, so that optimizations down the way will get rid of the dependent branch as well as remove the allocation entirely. (Just to make sure, any local allocation should have AddP.Identify() calls point to the same allocation, so if there /is/ a situation where CmpP is given the same local allocation, it'll simplify to an EQ comparison node. Additionally, escape analysis would make sure that allocations passed to other methods wouldn't show up as NoEscape.) Ed -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: stack.cmpp.txt Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20081209/f54155df/attachment.txt From Vladimir.Kozlov at Sun.COM Tue Dec 9 12:21:01 2008 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 09 Dec 2008 12:21:01 -0800 Subject: Scalar replacable object pointers won't be equal to anything else In-Reply-To: References: Message-ID: <493ED32D.2050402@sun.com> Ed, There is code in CmpPNode::sub() to optimize CmpP for allocations. Why it does not work for your case? Thanks, Vladimir Edward Lee wrote: > I've been running into several instances of HashMap.get(new Packed(v1, > v2)) used to retrieve items that have Keys with custom equals() > methods. Part of HashMap.get() checks if the entry's key is == equal > to the argument key before using equals(). This behavior prevents > inlined NoEscape objects from having its allocation removed, so when > the newly allocated object's field accesses are optimized to earlier > memory references, the only use of the object is a pointer comparison > that will always be false. > > Attached is a quick patch that converts potentially scalar replacable > object's CmpP use into a not-equal value, so that optimizations down > the way will get rid of the dependent branch as well as remove the > allocation entirely. > > (Just to make sure, any local allocation should have AddP.Identify() > calls point to the same allocation, so if there /is/ a situation where > CmpP is given the same local allocation, it'll simplify to an EQ > comparison node. Additionally, escape analysis would make sure that > allocations passed to other methods wouldn't show up as NoEscape.) > > Ed > From Vladimir.Kozlov at Sun.COM Tue Dec 9 13:29:55 2008 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 09 Dec 2008 13:29:55 -0800 Subject: Odd Loop x86 CodeGen Behavior In-Reply-To: References: Message-ID: <493EE353.8020507@sun.com> The stack spills you see are generated by Register Allocator. And I agree they are not needed. Do you have a small test to show this problem? Thanks, Vladimir Edward Lee wrote: > Some reason codegen is adding unnecessary stores that in turn cause > unnecessary loads to be added. Below is a snippet of the output of > opto assembly after some changes I've done to the nodes such as > removing the safepoint for this particular backedge. Any tips on where > I should look would be useful. > > The high level code is doing HashMap.get where the object has a custom > equals method inlined that checks a long field. Kinda like.. > > if (entry.hash == hash_ECX && entry.key.longField == long_ESP_64) > > The odd behavior is in B8 and B10, where long_ESP_64 gets loaded into > EAX,EDX in B8 and written back to the stack in B10 even though both > pair of load/stores are unnecessary. It seems that code gen is > confused by the fact that B3 loads long_ESP_64 into EAX,EDX for the > long compare and the branch from B3->B9 has a higher frequency > (0.029548) than the branch B2->B8 (0.023747). > > But the really odd thing is why does B10 even exist in the first > place? There's no point in writing EAX,EDX back to the stack, and this > seems to be purely an artifact of code gen as the ideal graph doesn't > have any store nodes to that location. > > 080 B2: # B8 B3 <- B1 B10 Loop: B2-B10 inner Freq: 1.01271 > 080 MOV EDI,[EBX + #8] ! Field java/util/HashMap$Entry.hash > 083 CMP EDI,ECX > 085 Jne,s B8 P=0.023747 C=6443.000000 > 085 > 087 B3: # B9 B4 <- B2 Freq: 0.98866 > 087 MOV ESI,[EBX + #12] ! Field java/util/HashMap$Entry.key > 08a MOV EBP.lo,[ESI + #8] > MOV EBP.hi,[ESI + #8]+4 ! Field customEquals.longField > 090 MOV EAX,[ESP + #64] > MOV EDX,[ESP + #68] > 098 CMP EAX.lo,EBP.lo ! Long compare; set flags for low bits > JNE,s skip > CMP EAX.hi,EBP.hi > skip: > 09e Jne,s B9 P=0.029548 C=6701.000000 > 09e > 0a0 B4: # B5 <- B3 B9 Freq: 0.959448 > 0a0 MOV EBX,[EBX + #16] ! Field java/util/HashMap$Entry.value > ... > 0d8 RET > > 0e0 B8: # B9 <- B2 Freq: 0.0240485 > 0e0 MOV EAX,[ESP + #64] > MOV EDX,[ESP + #68] > 0e0 > 0e8 B9: # B7 B10 <- B3 B8 Freq: 0.0532613 > 0e8 MOV EBX,[EBX + #20] ! Field java/util/HashMap$Entry.next > 0eb TEST EBX,EBX > 0ed Je,s B4 P=0.038502 C=718.000000 > 0ed > 0ef B10: # B2 <- B9 Freq: 0.0512106 > 0ef MOV [ESP + #64],EAX > MOV [ESP + #68],EDX > 0f7 JMP B2 > > Ed From edilee at gmail.com Tue Dec 9 14:25:23 2008 From: edilee at gmail.com (Edward Lee) Date: Tue, 9 Dec 2008 16:25:23 -0600 Subject: Scalar replacable object pointers won't be equal to anything else In-Reply-To: <493ED32D.2050402@sun.com> References: <493ED32D.2050402@sun.com> Message-ID: When expanding HashMap.get(new Packed(v1, v2)), it looks something like.. tmp = new Packed(v1, v2) for (e = table[tmp.hashCode()]; e != null; e = e.next) if (e.key == tmp) return e.value On Tue, Dec 9, 2008 at 2:21 PM, Vladimir Kozlov wrote: > There is code in CmpPNode::sub() to optimize CmpP for > allocations. Why it does not work for your case? For this particular CmpPNode::sub() call, it uses MemNode::detect_ptr_independence() that eventually calls MemNode::all_controls_dominate() where the dom node is the LoadP for list.key and sub node is the tmp Allocate. The LoadP is inside the loop, so the Allocate node isn't dominated by all of the LoadP's loop control. Ed From edilee at gmail.com Tue Dec 9 14:45:34 2008 From: edilee at gmail.com (Edward Lee) Date: Tue, 9 Dec 2008 16:45:34 -0600 Subject: Odd Loop x86 CodeGen Behavior In-Reply-To: <493EE353.8020507@sun.com> References: <493EE353.8020507@sun.com> Message-ID: On Tue, Dec 9, 2008 at 3:29 PM, Vladimir Kozlov wrote: > The stack spills you see are generated by Register Allocator. Sorry, I wasn't clear in the original message, but ESP+64 is actually an input parameter. #r051 esp+68: parm 2: long #r050 esp+64: parm 2: long I noticed I could set TraceSpilling option in hotspot_compiler, but I'm not familiar with that output. Should I be looking at that output? > Do you have a small test to show this problem? I suppose it isn't possible to give the ideal node graph and reconstruct from there? I'll see if I can make a small java method that doesn't require the custom transformations I've got going on. Ed From Vladimir.Kozlov at Sun.COM Tue Dec 9 15:30:06 2008 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 09 Dec 2008 15:30:06 -0800 Subject: Scalar replacable object pointers won't be equal to anything else In-Reply-To: References: <493ED32D.2050402@sun.com> Message-ID: <493EFF7E.2000409@sun.com> I see. And this is correct since in general case we don't know if the pointer to the allocation is stored into list.key field. It would be nice if we can eliminate CmpP early. With EA we have the knowledge about all references to allocations. Could you try the next change in detect_ptr_independence()?: diff -r 7a018855d2f0 src/share/vm/opto/memnode.cpp --- a/src/share/vm/opto/memnode.cpp Mon Dec 08 17:15:02 2008 -0800 +++ b/src/share/vm/opto/memnode.cpp Tue Dec 09 15:25:29 2008 -0800 @@ -379,9 +379,29 @@ bool MemNode::detect_ptr_independence(No } else if (a1 != NULL && a2 != NULL) { // both allocations return (a1 != a2); } else if (a1 != NULL) { // one allocation a1 + if (EliminateAllocations && a1->_is_scalar_replaceable) { + ConnectionGraph *cgr = phase->C->congraph(); + PointsToNode::EscapeState es = PointsToNode::GlobalEscape; + if (cgr != NULL) + es = cgr->escape_state(p2, phase); + if (es == PointsToNode::GlobalEscape) { + return true; // different escape status + } + } + } // (Note: p2->is_Con implies p2->in(0)->is_Root, which dominates.) return all_controls_dominate(p2, a1); } else { //(a2 != NULL) // one allocation a2 + if (EliminateAllocations && a2->_is_scalar_replaceable) { + ConnectionGraph *cgr = phase->C->congraph(); + PointsToNode::EscapeState es = PointsToNode::GlobalEscape; + if (cgr != NULL) + es = cgr->escape_state(p1, phase); + if (es == PointsToNode::GlobalEscape) { + return true; // different escape status + } + } + } return all_controls_dominate(p1, a2); } return false; Thanks, Vladimir Edward Lee wrote: > When expanding HashMap.get(new Packed(v1, v2)), it looks something like.. > > tmp = new Packed(v1, v2) > for (e = table[tmp.hashCode()]; e != null; e = e.next) > if (e.key == tmp) return e.value > > On Tue, Dec 9, 2008 at 2:21 PM, Vladimir Kozlov wrote: >> There is code in CmpPNode::sub() to optimize CmpP for >> allocations. Why it does not work for your case? > > For this particular CmpPNode::sub() call, it uses > MemNode::detect_ptr_independence() that eventually calls > MemNode::all_controls_dominate() where the dom node is the LoadP for > list.key and sub node is the tmp Allocate. > > The LoadP is inside the loop, so the Allocate node isn't dominated by > all of the LoadP's loop control. > > Ed From Vladimir.Kozlov at Sun.COM Tue Dec 9 15:40:44 2008 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 09 Dec 2008 15:40:44 -0800 Subject: Odd Loop x86 CodeGen Behavior In-Reply-To: References: <493EE353.8020507@sun.com> Message-ID: <493F01FC.6000504@sun.com> Don't look on TraceSpilling now. First, we need to know where stores in B10 are coming from. Look what the ideal graph is generated before matcher. You can use -XX:+PrintIdeal. Vladimir Edward Lee wrote: > On Tue, Dec 9, 2008 at 3:29 PM, Vladimir Kozlov wrote: >> The stack spills you see are generated by Register Allocator. > Sorry, I wasn't clear in the original message, but ESP+64 is actually > an input parameter. > #r051 esp+68: parm 2: long > #r050 esp+64: parm 2: long > > I noticed I could set TraceSpilling option in hotspot_compiler, but > I'm not familiar with that output. Should I be looking at that output? > >> Do you have a small test to show this problem? > I suppose it isn't possible to give the ideal node graph and > reconstruct from there? I'll see if I can make a small java method > that doesn't require the custom transformations I've got going on. > > Ed From edilee at gmail.com Tue Dec 9 21:57:52 2008 From: edilee at gmail.com (Edward Lee) Date: Tue, 9 Dec 2008 23:57:52 -0600 Subject: Scalar replacable object pointers won't be equal to anything else In-Reply-To: <493EFF7E.2000409@sun.com> References: <493ED32D.2050402@sun.com> <493EFF7E.2000409@sun.com> Message-ID: On Tue, Dec 9, 2008 at 5:30 PM, Vladimir Kozlov wrote: > Could you try the next change in detect_ptr_independence()?: I had to add the phase to subnode's virtual sub() declaration because CmpPNode::sub passes NULL to things expecting a phase. I've attached what is working for me, and it makes one allocation scalar replacable. Additionally, with the "do escape analysis after an initial IterGVN.optimize pass," it's able to scalar replace another similar situation. Ed -------------- next part -------------- A non-text attachment was scrubbed... Name: elim.cmpp.diff Type: application/octet-stream Size: 14523 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20081209/306e15a7/attachment.obj From edilee at gmail.com Tue Dec 9 22:29:58 2008 From: edilee at gmail.com (Edward Lee) Date: Wed, 10 Dec 2008 00:29:58 -0600 Subject: Odd Loop x86 CodeGen Behavior In-Reply-To: <493F01FC.6000504@sun.com> References: <493EE353.8020507@sun.com> <493F01FC.6000504@sun.com> Message-ID: On Tue, Dec 9, 2008 at 5:40 PM, Vladimir Kozlov wrote: > First, we need to know where stores in B10 are coming from. > Look what the ideal graph is generated before matcher. There are only two uses of this input parameter -- neither should be causing the writes in B10. #r051 esp+68: parm 2: long #r050 esp+64: parm 2: long 12 Parm === 3 [[ 876 1080 ]] Parm2: long !orig=[840] !jvms: ... @ bci:-1 3 Start === 3 0 [[... 876 XorL === _ 875 12 [[ 877 ]] !jvms: customEquals::hashCode @ bci:12 HashMap::get ... 875 ConvI2L === _ 871 [[ 876 ]] ... result of other hash function xor 1080 CmpL === _ 12 1077 [[ 1081 ]] !jvms: customEquals::equals @ bci:21 HashMap::get ... 1077 LoadL === 996 7 1076 [[ 1080 ]] customEquals:exact+8 *, name=longField, idx=20; #long ... And those get code generated to.. B1: ... 047 XOR ECX.lo,[ESP + #64] XOR ECX.hi,[ESP + #64]+4 B3: ... 090 MOV EAX,[ESP + #64] MOV EDX,[ESP + #68] 098 CMP EAX.lo,EBP.lo ! Long compare; set flags for low bits JNE,s skip CMP EAX.hi,EBP.hi skip: 09e Jne,s B9 P=0.029548 C=6701.000000 I've attached the original output, so customEquals.longField would actually be org/apache/derby/iapi/store/raw/PageKey.pageNumber. Note there's some "magic" going on to end up with the attached ideal graph, but it shouldn't affect the code gen. Also, the basic blocks are slightly different in the attached file (sometimes codegen decides to use a Je,s and othertimes Je). Ed -------------- next part -------------- A non-text attachment was scrubbed... Name: funky.loads Type: application/octet-stream Size: 28723 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20081210/c97f17df/attachment.obj From edilee at gmail.com Wed Dec 10 07:46:09 2008 From: edilee at gmail.com (Edward Lee) Date: Wed, 10 Dec 2008 09:46:09 -0600 Subject: Odd Loop x86 CodeGen Behavior In-Reply-To: References: <493EE353.8020507@sun.com> <493F01FC.6000504@sun.com> Message-ID: On Wed, Dec 10, 2008 at 12:29 AM, Edward Lee wrote: > I've attached the original output... To help figure out what the ideal graph/x86 is doing, I've "hand-disassembled" to the resulting inlined/magic high level, which should be something similar to.. BasePage FileContainer::getUserPage(BaseContainerHandle a0, long pageNumber, boolean a2, boolean a3) { Entry[] table = this.pageCache.cache_.table; int hash = (int) (this.identity.containerId ^ this.identity.segmentId); hash = (int) ((long) hash ^ pageNumber); hash = hash ^ (hash >>> 20) ^ (hash >>> 12); hash = hash ^ (hash >>> 7) ^ (hash >>> 4); Entry entry = table[hash & table.length - 1]; while (entry != null) { if (entry.hash == hash && entry.key.pageNumber == pageNumber) break; entry = entry.next; } this.pageCache.stat.findHit++; entry.value.recentlyUsed_ = true; entry.value.keepCount++; this.latchPage(a0, entry.value.entry, a3); return entry.value.entry; } Ed From edilee at gmail.com Wed Dec 10 12:11:18 2008 From: edilee at gmail.com (Edward Lee) Date: Wed, 10 Dec 2008 14:11:18 -0600 Subject: Compiling Linux hsdis (uintptr_t, dlsym undefined; wrong ELF class) Message-ID: I was trying to compile hsdis on Linux 2.6.18-53.el5 x86_64 and ran into a few issues. The first couple was fixed by a patch [1] to address various things being undefined: hsdis.c:50: error: expected specifier-qualifier-list before 'uintptr_t' hsdis-demo.c:(.text+0x96): undefined reference to `dlsym' hsdis-demo.c:(.text+0xcc): undefined reference to `dlopen' hsdis-demo.c:(.text+0x1fa): undefined reference to `dlerror' The next issue was that the disassembler couldn't use hsdis-i386.so. I found out with +WizardMode that the problem was "wrong ELF class: ELFCLASS64". So I had to recompile both binutils and hsdis with the -m32 option. bin/linux/hsdis-i386.so: ELF 64-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped .. instead of .. bin/linux/hsdis-i386.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped I've updated the original patch [1] to have changes to Makefile and README about using -m32. Ed [1] http://groups.google.com/group/jvm-languages/msg/4b7b6f19ab719cb7 -------------- next part -------------- A non-text attachment was scrubbed... Name: hsdis.m32.patch Type: application/octet-stream Size: 1366 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20081210/cb07733d/attachment.obj From edilee at gmail.com Wed Dec 10 14:08:49 2008 From: edilee at gmail.com (Edward Lee) Date: Wed, 10 Dec 2008 16:08:49 -0600 Subject: Unnecessary Long computation/loads feeding into ConvL2I Message-ID: I was looking at the OptoAssembly and final x86 code for the following code sequence and noticed a bit of unnecessary work in the generated code: int hash = (int) (this.identity.containerId ^ this.identity.segmentId); hash = (int) ((long) hash ^ pageNumber); The ideal graph looks like.. L2I(XorL( I2L(L2I(XorL(containerId, segmentId))), pageNumber)) It eventually becomes.. mov 0x10(%esi),%ecx ; containerId.lo mov 0x14(%esi),%ebx ; containerId.hi xor 0x8(%esi),%ecx ; XorL segmentId.lo xor 0xc(%esi),%ebx ; XorL segmentId.hi mov %ecx,%ebx ; 2-line upcast I2L sar $0x1f,%ebx ; I2L xor 0x40(%esp),%ecx ; XorL pageNumber.lo xor 0x44(%esp),%ebx ; XorL pageNumber.hi mov %ecx,%ebx ; unnecessary ?? L2I (Opto: MOV EBX,ECX.lo) The attached patch splits L2I(XorL(a,b)) into XorI(L2I(a),L2I(b)) and in this situation, it's simplified to.. XorI( L2I(XorL(containerId, segmentId)), L2I(pageNumber)) mov 0x10(%esi),%ebp ; containerId.lo mov 0x14(%esi),%edi ; containerId.hi xor 0x8(%esi),%ebp ; XorL segmentId.lo xor 0xc(%esi),%edi ; XorL segmentId.hi mov 0x40(%esp),%eax ; pageNumber.lo mov 0x44(%esp),%edx ; pageNumber.hi mov %ebp,%ebx ; (Opto: MOV EBX,EBP.lo) xor %eax,%ebx ; XorI pageNumber.lo Unfortunately, there's still a number of rough spots.. As per comments in ConvL2INode::Ideal.. // Disable optimization: LoadL->ConvL2I ==> LoadI. // It causes problems (sizes of Load and Store nodes do not match) // in objects initialization code and Escape Analysis. This forces the loads to stay as long loads, and this causes unnecessary register pressure. In the "after" x86 code, pageNumber is explicitly moved into eax and edx even though xor could have just used 0x40(%esp) directly. Also, all the high bits of the longs should be completely ignored. Additionally, it seems that EBP.lo in the OptoAssembly output gets treated as a separate entity from EBP. Otherwise, the xor could have just used %ebp (EBP.lo) directly as in "xor 0x40($esp), %ebp". Ideally the whole sequence should look like.. mov 0x10(%esi),%ebp ; containerId.lo xor 0x8(%esi),%ebp ; XorI segmentId.lo xor 0x40(%esp),%ebp ; XorI pageNumber.lo Ed -------------- next part -------------- A non-text attachment was scrubbed... Name: bitwise.l2i.patch Type: application/octet-stream Size: 1597 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20081210/a3698648/attachment.obj From lev.serebryakov at sun.com Thu Dec 11 08:18:08 2008 From: lev.serebryakov at sun.com (lev.serebryakov at sun.com) Date: Thu, 11 Dec 2008 16:18:08 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20081211161812.C3853D60E@hg.openjdk.java.net> Changeset: 7b920868b475 Author: coleenp Date: 2008-12-08 15:50 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7b920868b475 6773838: There is no calling stack for Compiler thread in hs_err file on x86 Summary: On solaris, the inline assembly wasn't being processed. Added volatile to il file fixed it. Reviewed-by: phh, kvn ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/os_cpu/solaris_x86/vm/solaris_x86_64.il Changeset: 3ad2b8576c4a Author: coleenp Date: 2008-12-09 09:55 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3ad2b8576c4a 6689685: Hotspot crash error message should include libraries version Summary: Print out JDK/JRE version that hotspot knows about. Reviewed-by: kamg, blacklion, acorn, alanb ! src/share/vm/utilities/vmError.cpp From Vladimir.Kozlov at Sun.COM Thu Dec 11 08:57:08 2008 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 11 Dec 2008 08:57:08 -0800 Subject: Scalar replacable object pointers won't be equal to anything else In-Reply-To: References: <493ED32D.2050402@sun.com> <493EFF7E.2000409@sun.com> Message-ID: <49414664.2070504@sun.com> Ed, I am thinking that you may try to run an additional IGVN optimization after EA in Compile::Optimize() in case we found non globally escaping opbjects. It may simplify the graph before loop optimizations: if (!has_non_escaping_obj) { _congraph = NULL; } if (failing()) return; + + if (has_non_escaping_obj) { + igvn.optimize(); + if (failing()) return; + } } Vlaidimir Edward Lee wrote: > On Tue, Dec 9, 2008 at 5:30 PM, Vladimir Kozlov wrote: >> Could you try the next change in detect_ptr_independence()?: > > I had to add the phase to subnode's virtual sub() declaration because > CmpPNode::sub passes NULL to things expecting a phase. I've attached > what is working for me, and it makes one allocation scalar replacable. > Additionally, with the "do escape analysis after an initial > IterGVN.optimize pass," it's able to scalar replace another similar > situation. > > Ed From Vladimir.Kozlov at Sun.COM Thu Dec 11 09:41:25 2008 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 11 Dec 2008 09:41:25 -0800 Subject: Unnecessary Long computation/loads feeding into ConvL2I In-Reply-To: References: Message-ID: <494150C5.5010705@sun.com> Ed, These changes are platform specific for 32-bits x86. And we are trying to stay platform neutral during ideal optimizations. What you can do is to add new mach nodes in x86_32.ad: instruct xorl2i_reg_reg(eRegI dst, eRegL src1, eRegL src2, eFlagsReg cr) %{ match(Set dst (ConvL2I (XorL src1 src2))); expand %{ xorI_eReg(src1, src2, cr); convL2I_reg(dst, src1); %} %} instruct xorl2i_reg_mem(eRegI dst, eRegL src1, memory src2, eFlagsReg cr) %{ match(Set dst (ConvL2I (XorL src1 src2))); expand %{ xorI_eReg_mem(src1, src2, cr); convL2I_reg(dst, src1); %} %} Unfortunately, with our current implementation you can't avoid L2I conversion if register allocator uses different registers for src1 and dst. Vladimir Edward Lee wrote: > I was looking at the OptoAssembly and final x86 code for the following > code sequence and noticed a bit of unnecessary work in the generated > code: > > int hash = (int) (this.identity.containerId ^ this.identity.segmentId); > hash = (int) ((long) hash ^ pageNumber); > > The ideal graph looks like.. > L2I(XorL( > I2L(L2I(XorL(containerId, segmentId))), > pageNumber)) > > It eventually becomes.. > mov 0x10(%esi),%ecx ; containerId.lo > mov 0x14(%esi),%ebx ; containerId.hi > xor 0x8(%esi),%ecx ; XorL segmentId.lo > xor 0xc(%esi),%ebx ; XorL segmentId.hi > mov %ecx,%ebx ; 2-line upcast I2L > sar $0x1f,%ebx ; I2L > xor 0x40(%esp),%ecx ; XorL pageNumber.lo > xor 0x44(%esp),%ebx ; XorL pageNumber.hi > mov %ecx,%ebx ; unnecessary ?? L2I (Opto: MOV EBX,ECX.lo) > > The attached patch splits L2I(XorL(a,b)) into XorI(L2I(a),L2I(b)) and > in this situation, it's simplified to.. > > XorI( > L2I(XorL(containerId, segmentId)), > L2I(pageNumber)) > > mov 0x10(%esi),%ebp ; containerId.lo > mov 0x14(%esi),%edi ; containerId.hi > xor 0x8(%esi),%ebp ; XorL segmentId.lo > xor 0xc(%esi),%edi ; XorL segmentId.hi > mov 0x40(%esp),%eax ; pageNumber.lo > mov 0x44(%esp),%edx ; pageNumber.hi > mov %ebp,%ebx ; (Opto: MOV EBX,EBP.lo) > xor %eax,%ebx ; XorI pageNumber.lo > > Unfortunately, there's still a number of rough spots.. As per comments > in ConvL2INode::Ideal.. > // Disable optimization: LoadL->ConvL2I ==> LoadI. > // It causes problems (sizes of Load and Store nodes do not match) > // in objects initialization code and Escape Analysis. > > This forces the loads to stay as long loads, and this causes > unnecessary register pressure. In the "after" x86 code, pageNumber is > explicitly moved into eax and edx even though xor could have just used > 0x40(%esp) directly. Also, all the high bits of the longs should be > completely ignored. > > Additionally, it seems that EBP.lo in the OptoAssembly output gets > treated as a separate entity from EBP. Otherwise, the xor could have > just used %ebp (EBP.lo) directly as in "xor 0x40($esp), %ebp". > > Ideally the whole sequence should look like.. > > mov 0x10(%esi),%ebp ; containerId.lo > xor 0x8(%esi),%ebp ; XorI segmentId.lo > xor 0x40(%esp),%ebp ; XorI pageNumber.lo > > Ed From Thomas.Rodriguez at Sun.COM Thu Dec 11 09:49:26 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 11 Dec 2008 09:49:26 -0800 Subject: Unnecessary Long computation/loads feeding into ConvL2I In-Reply-To: <494150C5.5010705@sun.com> References: <494150C5.5010705@sun.com> Message-ID: You might also a rule for (Set dst (ConvL2I (LoadL mem))) that loads from the appropriate half of the long. tom On Dec 11, 2008, at 9:41 AM, Vladimir Kozlov wrote: > Ed, > > These changes are platform specific for 32-bits x86. > And we are trying to stay platform neutral during ideal > optimizations. > > What you can do is to add new mach nodes in x86_32.ad: > > instruct xorl2i_reg_reg(eRegI dst, eRegL src1, eRegL src2, eFlagsReg > cr) %{ > match(Set dst (ConvL2I (XorL src1 src2))); > expand %{ > xorI_eReg(src1, src2, cr); > convL2I_reg(dst, src1); > %} > %} > > instruct xorl2i_reg_mem(eRegI dst, eRegL src1, memory src2, > eFlagsReg cr) %{ > match(Set dst (ConvL2I (XorL src1 src2))); > expand %{ > xorI_eReg_mem(src1, src2, cr); > convL2I_reg(dst, src1); > %} > %} > > Unfortunately, with our current implementation you can't > avoid L2I conversion if register allocator uses different > registers for src1 and dst. > > Vladimir > > > Edward Lee wrote: >> I was looking at the OptoAssembly and final x86 code for the >> following >> code sequence and noticed a bit of unnecessary work in the generated >> code: >> int hash = (int) (this.identity.containerId ^ >> this.identity.segmentId); >> hash = (int) ((long) hash ^ pageNumber); >> The ideal graph looks like.. >> L2I(XorL( >> I2L(L2I(XorL(containerId, segmentId))), >> pageNumber)) >> It eventually becomes.. >> mov 0x10(%esi),%ecx ; containerId.lo >> mov 0x14(%esi),%ebx ; containerId.hi >> xor 0x8(%esi),%ecx ; XorL segmentId.lo >> xor 0xc(%esi),%ebx ; XorL segmentId.hi >> mov %ecx,%ebx ; 2-line upcast I2L >> sar $0x1f,%ebx ; I2L >> xor 0x40(%esp),%ecx ; XorL pageNumber.lo >> xor 0x44(%esp),%ebx ; XorL pageNumber.hi >> mov %ecx,%ebx ; unnecessary ?? L2I (Opto: MOV EBX,ECX.lo) >> The attached patch splits L2I(XorL(a,b)) into XorI(L2I(a),L2I(b)) and >> in this situation, it's simplified to.. >> XorI( >> L2I(XorL(containerId, segmentId)), >> L2I(pageNumber)) >> mov 0x10(%esi),%ebp ; containerId.lo >> mov 0x14(%esi),%edi ; containerId.hi >> xor 0x8(%esi),%ebp ; XorL segmentId.lo >> xor 0xc(%esi),%edi ; XorL segmentId.hi >> mov 0x40(%esp),%eax ; pageNumber.lo >> mov 0x44(%esp),%edx ; pageNumber.hi >> mov %ebp,%ebx ; (Opto: MOV EBX,EBP.lo) >> xor %eax,%ebx ; XorI pageNumber.lo >> Unfortunately, there's still a number of rough spots.. As per >> comments >> in ConvL2INode::Ideal.. >> // Disable optimization: LoadL->ConvL2I ==> LoadI. >> // It causes problems (sizes of Load and Store nodes do not match) >> // in objects initialization code and Escape Analysis. >> This forces the loads to stay as long loads, and this causes >> unnecessary register pressure. In the "after" x86 code, pageNumber is >> explicitly moved into eax and edx even though xor could have just >> used >> 0x40(%esp) directly. Also, all the high bits of the longs should be >> completely ignored. >> Additionally, it seems that EBP.lo in the OptoAssembly output gets >> treated as a separate entity from EBP. Otherwise, the xor could have >> just used %ebp (EBP.lo) directly as in "xor 0x40($esp), %ebp". >> Ideally the whole sequence should look like.. >> mov 0x10(%esi),%ebp ; containerId.lo >> xor 0x8(%esi),%ebp ; XorI segmentId.lo >> xor 0x40(%esp),%ebp ; XorI pageNumber.lo >> Ed From Vladimir.Kozlov at Sun.COM Thu Dec 11 20:46:15 2008 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 11 Dec 2008 20:46:15 -0800 Subject: Odd Loop x86 CodeGen Behavior In-Reply-To: References: <493EE353.8020507@sun.com> <493F01FC.6000504@sun.com> Message-ID: <4941EC97.8000209@sun.com> Ed, The next parts of code are generated for MachSpillCopy mach nodes: 090 MOV EAX,[ESP + #64] MOV EDX,[ESP + #68] 0dd B7: # B8 <- B2 Freq: 0.0579261 0dd MOV EAX,[ESP + #64] MOV EDX,[ESP + #68] 0ec B9: # B2 <- B8 Freq: 0.087028 0ec MOV [ESP + #64],EAX MOV [ESP + #68],EDX MachSpillCopy nodes for the last 2 (at the address dd and ec) should be eliminated at least in post_allocate_copy_removal(). Could you look why it is not happening? Pay more attention to the code guarded by !is_single_register() method. Thanks, Vladimir Edward Lee wrote: > On Wed, Dec 10, 2008 at 12:29 AM, Edward Lee wrote: >> I've attached the original output... > To help figure out what the ideal graph/x86 is doing, I've > "hand-disassembled" to the resulting inlined/magic high level, which > should be something similar to.. > > BasePage FileContainer::getUserPage(BaseContainerHandle a0, > long pageNumber, boolean a2, boolean a3) { > > Entry[] table = this.pageCache.cache_.table; > > int hash = (int) (this.identity.containerId ^ this.identity.segmentId); > hash = (int) ((long) hash ^ pageNumber); > hash = hash ^ (hash >>> 20) ^ (hash >>> 12); > hash = hash ^ (hash >>> 7) ^ (hash >>> 4); > > Entry entry = table[hash & table.length - 1]; > while (entry != null) { > if (entry.hash == hash && entry.key.pageNumber == pageNumber) > break; > entry = entry.next; > } > > this.pageCache.stat.findHit++; > entry.value.recentlyUsed_ = true; > entry.value.keepCount++; > > this.latchPage(a0, entry.value.entry, a3); > > return entry.value.entry; > } > > Ed From vladimir.kozlov at sun.com Thu Dec 11 20:53:16 2008 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 12 Dec 2008 04:53:16 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20081212045322.72160D678@hg.openjdk.java.net> Changeset: 7a018855d2f0 Author: jrose Date: 2008-12-08 17:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7a018855d2f0 6779339: turn off LinkWellKnownClasses by default pending further testing Summary: temporarily turn off LinkWellKnownClasses optimization Reviewed-by: never, kvn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/runtime/globals.hpp Changeset: 284d0af00d53 Author: jrose Date: 2008-12-09 12:41 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/284d0af00d53 6771309: debugging AD files is difficult without #line directives in generated code Summary: more and better #line and #define directives in the generated code; ADLC itself accepts #line directives Reviewed-by: never, kvn ! make/linux/adlc_updater ! make/linux/makefiles/adlc.make ! make/solaris/adlc_updater ! make/solaris/makefiles/adlc.make ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/adlparse.hpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/dfa.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/formssel.cpp Changeset: 7b75310e57e2 Author: kvn Date: 2008-12-11 17:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7b75310e57e2 Merge ! src/share/vm/runtime/globals.hpp From volker.simonis at gmail.com Fri Dec 12 09:03:56 2008 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 12 Dec 2008 18:03:56 +0100 Subject: Verification failure in SPECJVM2008.scimark.fft.small on Windows/32bit In-Reply-To: References: <27F53E5C-6F69-49A3-A7D8-443ED4F35060@sun.com> <57B328E3-C3EA-4F57-A284-799C01ED5F93@Sun.COM> Message-ID: Just to bring this discussion to an end: we discovered that this problem can be solved by using SP2 of Windows Server 2003 instead of SP1. I'm still not sure that SP2 fixes a real Windows bug, but at least the tests now runs as expected. As I said before, I'm still not convinced that the problem is only in the MS runtime, because I know from other problems we had that there are really nasty interactions between the MS runtime, the MS VC compiler and the machine code generated by the HotSpot when it comes to floating point computations. So hopefully we won't see them again with the next SP... Best regards, Volker PS: after I reread the thread I must admit, that some details are confusing, so just for the sake of completness: the problems mentioned in this thread happend with a 32-bit JDK on a 64-bit Windows Server 2003 with SP1 running on a multicore CPU with support for at least SSE2. They disappeared after the instalaltion of SP2. On 11/11/08, Tom Rodriguez wrote: > I tried reproducing this without luck though I couldn't find many machines > with the right configuration. I'll try to find a machine that reproduces > this. Thanks for the report. > > tom > > > On Nov 11, 2008, at 2:23 AM, Volker Simonis wrote: > > > > Hi, > > > > unfortunately I had no success in finding a solution for this problem. > > I have therefore opened a bug report (" Floating point failure in > > 32-bit JDK 6/7 on multicore Windows with -XX:UseSSE=2" with the > > internal review ID 1389916). > > > > I think this is quite a serious problem and it would be nice, if > > somebody could have a look on it. > > > > Thank you and best regards, > > Volker > > > > PS: with the option "-XX:+TraceRuntimeCalls" I could see that the > > benchmark calls "SharedRuntime::dsin(jdouble x)" quite often. The > > problem is probably also not related to any kind of OnStackReplacement > > or Deoptimization (I checked with "-XX:+TraceOnStackReplacement" and > > "-XX:+TraceDeoptimization) because the offending methods are compiled > > quite some time before the actual failure happens. > > > > > > > > On 10/31/08, Volker Simonis wrote: > > > > > Funny enough, my previous problem, which was caused by an uncleared FP > > > status register, only happend on 64-bit Windows and only with MSVC > > > 2005 and 2008 while this problem happens only on 32-bit Windows and > > > with MSVC 2005 (the one we use for our builds) as well as with older > > > versions of MSVC (i.e. the one that is used for the official Java 7 > > > buildss by SUN). > > > > > > I finally found some documentation about the calling conventions on > > > Windows/x64 and it states: "A callee that modifies any of the fields > > > within FPCSR/MXCSR must restore them before returning to its caller. > > > Furthermore, a caller that has modified any of these fields must > > > restore them to their standard values before invoking a callee unless > > > by agreement the callee expects the modified values". I could however > > > only find this information for MSVC 2005 and 2008 (see > > > > http://msdn.microsoft.com/en-us/library/ms235300(VS.80).aspx > and > > > http://msdn.microsoft.com/en-us/library/ms235300.aspx) > and I think you > > > use an older version for Windows builds, right? > > > > > > > > > Volker > > > > > > > > > On 10/30/08, Tom Rodriguez wrote: > > > > > > > I haven't had a chance to investigate yet, but I wonder if this is > related > > > > to the MXCSR issue you had mentioned previously? AlwaysRestoreFPU > doesn't > > > > deal with the MXCSR. -XX:+RestoreMXCSROnJNICalls does something > similar > > > > though. > > > > > > > > tom > > > > > > > > > > > > On Oct 30, 2008, at 11:22 AM, Volker Simonis wrote: > > > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > I ran the benchmark all day and I couldn't reproduce the problem > > > > > neither with -XX:UseSSE=0 nor with -XX:UseSSE=1 although I havent > done > > > > > that many runs with -XX:UseSSE=1 like with -XX:UseSSE=0. It seems > the > > > > > problem only shows up with -XX:UseSSE=2 or higher. I'll start a run > > > > > with "-XX:UseSSE=2 -XX:+CheckJNICalls" now and post the results > > > > > tomorrow. I have also found some other options which may be worth > > > > > trying them out: -XX:+AlwaysRestoreFPU and -XX:+VerifyFPU where the > > > > > last one is only available in the debug build. > > > > > > > > > > I've noticed that the tests uses a java.lang.ThreadLocal double > array > > > > > to store and compute the values. May this be a problem perhaps? > > > > > > > > > > Did you had a chance to reproduce the problem? > > > > > > > > > > Regards, > > > > > Volker > > > > > > > > > > On 10/29/08, Tom Rodriguez wrote: > > > > > > > > > > > > > > > > I haven't seen this before, though I pretty much never benchmark > on > > > > > > > > > > > > > > > windows. > > > > > > > > > > > > > > > Is the use of -XX:+CITime required? have you tried debug builds? > Does > > > > > > > > > > > > > > > it > > > > > > > > > > > > > > > reproduce with -XX:UseSSE=0? It might be interesting to run with > > > > > > -XX:+CheckJNICalls which will verify the various fp control words > have > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > right value. I'll see if I can reproduce it here. > > > > > > > > > > > > tom > > > > > > > > > > > > > > > > > > On Oct 29, 2008, at 11:55 AM, Volker Simonis wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > we have problems with SPECJVM2008 on Windows/x86 machines with > at > > > > > > > least 4 cores and at least 4 benchmark threads. The benchmark > > > > > > > reproducible fails in the result verification of the > sub-benchmark > > > > > > > scimark.fft.small (however in random places). > > > > > > > > > > > > > > We could reproduce the problem with JDK 6u7 and 6u10 as well as > with > > > > > > > the latest JDK 7b38 however only for the 32-bit Windows > versions. > > > > > > > > > > > > > > Because the problem occurs with both, C1 and C2 and because the > > > > > > > problem isn't reproducible neither with -Xint, nor with the > 64-bit > > > > > > > Windows or the Linux JDK, we think that this may be a problem in > the > > > > > > > HotSpot runtime (perhaps a timing/concurrency problem with the > > > > > > > handling of 64-bit doubles in a 32-bit JDK on multi core > machines?), > > > > > > > but this is only a wild guess. > > > > > > > > > > > > > > We also observed that all the files (JDK, test classes and > result > > > > > > > files) had to be on the local host in order to reproduce the > problem > > > > > > > and we had the impression that the benchmark fails more quickly > on > > > > > > > Intel XEON, compared to AMD Opteron (we tested on the following > > > > > > > hardware: Intel (2x XEON (with HT), 3.4GHz, 8GB, MS Win Server > 2003 > > > > > > > Enterprise x64, SP1) and AMD (4x Opteron 270, 2.0GHz, 9GB, MS > Win > > > > > > > Server 2003 Enterprise x64, SP1)). > > > > > > > > > > > > > > Has anybody else already observed this problem? Is this perhaps > an > > > > > > > issue of SPECJVM2008.scimark.fft.small? > > > > > > > > > > > > > > Any comments would be highly appreciated! > > > > > > > > > > > > > > Regards, > > > > > > > Volker > > > > > > > > > > > > > > PS: JVM2008 is available from > > > > > > > > > > > > > > > > > > > > http://www.spec.org/download.html > > > > > > > > > > > > > > > > > > > > > > > > > > PPS: here's the command line we used for the tests: java -server > > > > > > > -XX:+CITime -Djava.io.tmpdir=tmp -jar SPECjvm2008.jar -ikv -wt > 30 -it > > > > > > > 60 -bt 4 --base scimark.fft.small scimark.fft.small > scimark.fft.small > > > > > > > scimark.fft.small scimark.fft.small scimark.fft.small > > > > > > > scimark.fft.small scimark.fft.small scimark.fft.small > > > > > > > scimark.fft.small scimark.fft.small scimark.fft.small > > > > > > > scimark.fft.small scimark.fft.small scimark.fft.small > > > > > > > scimark.fft.small scimark.fft.small scimark.fft.small > > > > > > > scimark.fft.small scimark.fft.small > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From fw at deneb.enyo.de Fri Dec 12 12:57:21 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 12 Dec 2008 21:57:21 +0100 Subject: fix hotspot build failures with -D_FORTIFY_SOURCE=2 and -Wformat=1 In-Reply-To: <4935CA58.70403@sun.com> (David Holmes's message of "Wed, 03 Dec 2008 09:52:56 +1000") References: <49356C74.2000700@ubuntu.com> <4935CA58.70403@sun.com> Message-ID: <87k5a56rim.fsf@mid.deneb.enyo.de> * David Holmes: > And here: > > - ::write(defaultStream::output_fd(), s, (int)strlen(s)); > + ssize_t rv = ::write(defaultStream::output_fd(), s, (int)strlen(s)); > > if we are ignoring the return value anyway (which might be the real > error here!) Looks like a bug to me because the file descriptor might refer to a terminal. From dawn2004 at gmail.com Fri Dec 12 14:42:03 2008 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Fri, 12 Dec 2008 14:42:03 -0800 (PST) Subject: How to debug hotspot integrated with java codes Message-ID: <20984867.post@talk.nabble.com> Hi, guys. Now I'm debugging Hotspot. I'm using GDB. When I debug the source codes written in c++, it's fine. But if the VM has launched, I cannot trace into the source codes written in java. e.g. When I find Hotspot cannot load some class, and I wanna step into the class java.lang.ClassLoader , I don't know how to trace it. Apparently, I cannot do that with GDB. Can you guys give me some suggestion for debug in this situation? I spend several days on this problem, and really need some help on the debug things. Thanks a lot in advance!! -- View this message in context: http://www.nabble.com/How-to-debug-hotspot-integrated-with-java-codes-tp20984867p20984867.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From Xiaobin.Lu at Sun.COM Fri Dec 12 15:15:39 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Fri, 12 Dec 2008 15:15:39 -0800 Subject: How to debug hotspot integrated with java codes In-Reply-To: <20984867.post@talk.nabble.com> References: <20984867.post@talk.nabble.com> Message-ID: <4942F09B.7070200@Sun.COM> Refer to http://developers.sun.com/sunstudio/overview/topics/debug_index.html to find more details on how to use Sun Studio which is available on Linux to debug mixed Java and native code. -Xiaobin Colin(Du Li) wrote: > Hi, guys. > > Now I'm debugging Hotspot. I'm using GDB. When I debug the source codes > written in c++, it's fine. But if the VM has launched, I cannot trace into > the source codes written in java. e.g. When I find Hotspot cannot load some > class, and I wanna step into the class java.lang.ClassLoader , I don't know > how to trace it. Apparently, I cannot do that with GDB. > Can you guys give me some suggestion for debug in this situation? > I spend several days on this problem, and really need some help on the > debug things. > > Thanks a lot in advance!! > > > > From lev.serebryakov at sun.com Fri Dec 12 15:15:05 2008 From: lev.serebryakov at sun.com (lev.serebryakov at sun.com) Date: Fri, 12 Dec 2008 23:15:05 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20081212231514.AC659D7A9@hg.openjdk.java.net> Changeset: 24fda36852ce Author: coleenp Date: 2008-12-10 15:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/24fda36852ce 6727377: VM stack guard pages on Windows should PAGE_READWRITE not PAGE_EXECUTE_READWRITE Summary: Make reguard_stack change access to RW, not execute and use os::protect_memory with the new parameter when change needed to X. Reviewed-by: acorn, jcoomes ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp Changeset: a7fac4381b50 Author: blacklion Date: 2008-12-11 03:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a7fac4381b50 6639341: sometimes contended-exit event comes after contended-entered on another thread Summary: DTrace probe "contended-exit" should be fired before unparking object, or context could be lost. Probe firing was moved to proper place. Reviewed-by: coleenp, kamg ! src/share/vm/runtime/synchronizer.cpp Changeset: 06d2c3204df4 Author: blacklion Date: 2008-12-12 10:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/06d2c3204df4 Merge From jon.masamitsu at sun.com Fri Dec 12 19:20:00 2008 From: jon.masamitsu at sun.com (jon.masamitsu at sun.com) Date: Sat, 13 Dec 2008 03:20:00 +0000 Subject: hg: jdk7/hotspot/hotspot: 5 new changesets Message-ID: <20081213032010.D6592D7E2@hg.openjdk.java.net> Changeset: d249b360e026 Author: ysr Date: 2008-12-10 23:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d249b360e026 6782457: CMS: Livelock in CompactibleFreeListSpace::block_size() 6736295: SIGSEGV in product jvm, assertion "these are the only valid states during a mark sweep" in fastdebug Summary: Restructured the code in the perm gen allocation retry loop so as to avoid "safepoint-blocking" on locks, in this case the Heap_lock, while holding uninitialized allocated heap storage. Reviewed-by: apetrusenko, iveresov, jcoomes, jmasa, poonam ! src/share/vm/memory/permGen.cpp Changeset: 7d7a7c599c17 Author: jcoomes Date: 2008-12-11 12:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7d7a7c599c17 6578152: fill_region_with_object has usability and safety issues Reviewed-by: apetrusenko, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/includeDB_gc ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.hpp ! src/share/vm/runtime/globals.hpp Changeset: 7c2386d67889 Author: jcoomes Date: 2008-12-11 12:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7c2386d67889 6765745: par compact - allow young gen spaces to be split Reviewed-by: jmasa ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp Changeset: 0f773163217d Author: jcoomes Date: 2008-12-11 12:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0f773163217d 6765954: par compact - stress mode for splitting young gen spaces Reviewed-by: jmasa ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: ffe19141e312 Author: jmasa Date: 2008-12-12 15:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ffe19141e312 Merge ! src/share/vm/runtime/globals.hpp From thomas.rodriguez at sun.com Sat Dec 13 01:16:40 2008 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Sat, 13 Dec 2008 09:16:40 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20081213091649.5AA6AD7FD@hg.openjdk.java.net> Changeset: ac8fe14c93e4 Author: never Date: 2008-12-12 19:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ac8fe14c93e4 6767587: missing call to make_not_entrant after deoptimizing for patching volatiles Reviewed-by: rasbold, kvn ! src/share/vm/c1/c1_Runtime1.cpp Changeset: a738a625039a Author: never Date: 2008-12-12 19:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a738a625039a 6757316: load_constant() produces a wrong long constant, with high a low words swapped Reviewed-by: rasbold, jrose, kvn ! src/share/vm/c1/c1_LIRGenerator.cpp + test/compiler/6757316/Test6757316.java Changeset: 80206b8a9128 Author: never Date: 2008-12-12 19:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/80206b8a9128 6758234: if (k cond (a ? : b: c)) returns reversed answer if k is constant and b and c are longs Reviewed-by: kvn, jrose ! src/share/vm/c1/c1_Optimizer.cpp + test/compiler/6758234/Test6758234.java From Karen.Kinnear at Sun.COM Sat Dec 13 09:27:29 2008 From: Karen.Kinnear at Sun.COM (Karen Kinnear) Date: Sat, 13 Dec 2008 12:27:29 -0500 Subject: How to debug hotspot integrated with java codes In-Reply-To: <4942F09B.7070200@Sun.COM> References: <20984867.post@talk.nabble.com> <4942F09B.7070200@Sun.COM> Message-ID: Colin, For this specific problem, you can also try vm command line flags: -XX:+TraceClassResolution -XX:+TraceClassLoading You might get a bit more information about what exception you get when trying to load a class. hope this helps, Karen On Dec 12, 2008, at 6:15 PM, Xiaobin Lu wrote: > Refer to http://developers.sun.com/sunstudio/overview/topics/debug_index.html > to find more details on how to use Sun Studio which is available on > Linux to debug mixed Java and native code. > > -Xiaobin > > Colin(Du Li) wrote: >> Hi, guys. >> >> Now I'm debugging Hotspot. I'm using GDB. When I debug the source >> codes >> written in c++, it's fine. But if the VM has launched, I cannot >> trace into >> the source codes written in java. e.g. When I find Hotspot cannot >> load some >> class, and I wanna step into the class java.lang.ClassLoader , I >> don't know >> how to trace it. Apparently, I cannot do that with GDB. Can you >> guys give me some suggestion for debug in this situation? >> I spend several days on this problem, and really need some help on >> the >> debug things. >> >> Thanks a lot in advance!! >> >> >> >> > From neojia at gmail.com Sat Dec 13 13:20:20 2008 From: neojia at gmail.com (Neo Jia) Date: Sat, 13 Dec 2008 13:20:20 -0800 Subject: How to debug hotspot integrated with java codes In-Reply-To: References: <20984867.post@talk.nabble.com> <4942F09B.7070200@Sun.COM> Message-ID: <035CA0AF-C2D0-478D-BC06-CC772B6E1639@gmail.com> What is the error message? Thanks, Neo --------- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! On Dec 13, 2008, at 9:27 AM, Karen Kinnear wrote: > Colin, > > For this specific problem, you can also try vm command line flags: > -XX:+TraceClassResolution -XX:+TraceClassLoading > > You might get a bit more information about what exception you get > when trying to load > a class. > > hope this helps, > Karen > > On Dec 12, 2008, at 6:15 PM, Xiaobin Lu wrote: > >> Refer to http://developers.sun.com/sunstudio/overview/topics/debug_index.html >> to find more details on how to use Sun Studio which is available >> on Linux to debug mixed Java and native code. >> >> -Xiaobin >> >> Colin(Du Li) wrote: >>> Hi, guys. >>> >>> Now I'm debugging Hotspot. I'm using GDB. When I debug the source >>> codes >>> written in c++, it's fine. But if the VM has launched, I cannot >>> trace into >>> the source codes written in java. e.g. When I find Hotspot cannot >>> load some >>> class, and I wanna step into the class java.lang.ClassLoader , I >>> don't know >>> how to trace it. Apparently, I cannot do that with GDB. Can you >>> guys give me some suggestion for debug in this situation? >>> I spend several days on this problem, and really need some help >>> on the >>> debug things. >>> >>> Thanks a lot in advance!! >>> >>> >>> >>> >> > From dawn2004 at gmail.com Mon Dec 15 10:49:29 2008 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Mon, 15 Dec 2008 10:49:29 -0800 (PST) Subject: How to debug hotspot integrated with java codes In-Reply-To: <4942F09B.7070200@Sun.COM> References: <20984867.post@talk.nabble.com> <4942F09B.7070200@Sun.COM> Message-ID: <21019431.post@talk.nabble.com> Hi, Xiaobin, I tried dbx, but dbx will hang after echo "reading libzip.so" as below: >$ dbx $LD_LIBRARY_PATH/gamma For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc Reading gamma Reading ld-linux.so.2 Reading libjvm.so Reading libm.so.6 Reading libdl.so.2 Reading libpthread.so.0 Reading libc.so.6 (dbx) run -version Running: gamma -version (process id 5777) Reading librt.so.1 Reading libhpi.so Reading libnsl.so.1 Reading libnss_files.so.2 Reading libverify.so Reading libjava.so Reading libzip.so .... Then I have to kill this process to stop it. xiaobin.lu wrote: > > Refer to > http://developers.sun.com/sunstudio/overview/topics/debug_index.html to > find more details on how to use Sun Studio which is available on Linux > to debug mixed Java and native code. > > -Xiaobin > > Colin(Du Li) wrote: >> Hi, guys. >> >> Now I'm debugging Hotspot. I'm using GDB. When I debug the source codes >> written in c++, it's fine. But if the VM has launched, I cannot trace >> into >> the source codes written in java. e.g. When I find Hotspot cannot load >> some >> class, and I wanna step into the class java.lang.ClassLoader , I don't >> know >> how to trace it. Apparently, I cannot do that with GDB. >> Can you guys give me some suggestion for debug in this situation? >> I spend several days on this problem, and really need some help on the >> debug things. >> >> Thanks a lot in advance!! >> >> >> >> > > > -- View this message in context: http://www.nabble.com/How-to-debug-hotspot-integrated-with-java-codes-tp20984867p21019431.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From dawn2004 at gmail.com Mon Dec 15 10:55:44 2008 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Mon, 15 Dec 2008 10:55:44 -0800 (PST) Subject: How to debug hotspot integrated with java codes In-Reply-To: <035CA0AF-C2D0-478D-BC06-CC772B6E1639@gmail.com> References: <20984867.post@talk.nabble.com> <4942F09B.7070200@Sun.COM> <035CA0AF-C2D0-478D-BC06-CC772B6E1639@gmail.com> Message-ID: <21019434.post@talk.nabble.com> The error message is below: Exception in thread "main" java.lang.NoClassDefFoundError: Caused by: java.lang.ClassNotFoundException: at java.net.URLClassLoader$1.run(URLClassLoader.java:221) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:209) at java.lang.ClassLoader.loadClass(ClassLoader.java:324) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:269) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:337) I don't think it give much hint. What I did is just move some object in heap to a new location, then, this kind of exceptions are always thrown. Thanks. NeoJia wrote: > > What is the error message? > > Thanks, > Neo > > --------- > I would remember that if researchers were not ambitious > probably today we haven't the technology we are using! > > On Dec 13, 2008, at 9:27 AM, Karen Kinnear > wrote: > >> Colin, >> >> For this specific problem, you can also try vm command line flags: >> -XX:+TraceClassResolution -XX:+TraceClassLoading >> >> You might get a bit more information about what exception you get >> when trying to load >> a class. >> >> hope this helps, >> Karen >> >> On Dec 12, 2008, at 6:15 PM, Xiaobin Lu wrote: >> >>> Refer to >>> http://developers.sun.com/sunstudio/overview/topics/debug_index.html >>> to find more details on how to use Sun Studio which is available >>> on Linux to debug mixed Java and native code. >>> >>> -Xiaobin >>> >>> Colin(Du Li) wrote: >>>> Hi, guys. >>>> >>>> Now I'm debugging Hotspot. I'm using GDB. When I debug the source >>>> codes >>>> written in c++, it's fine. But if the VM has launched, I cannot >>>> trace into >>>> the source codes written in java. e.g. When I find Hotspot cannot >>>> load some >>>> class, and I wanna step into the class java.lang.ClassLoader , I >>>> don't know >>>> how to trace it. Apparently, I cannot do that with GDB. Can you >>>> guys give me some suggestion for debug in this situation? >>>> I spend several days on this problem, and really need some help >>>> on the >>>> debug things. >>>> >>>> Thanks a lot in advance!! >>>> >>>> >>>> >>>> >>> >> > > -- View this message in context: http://www.nabble.com/How-to-debug-hotspot-integrated-with-java-codes-tp20984867p21019434.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From dawn2004 at gmail.com Mon Dec 15 10:57:00 2008 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Mon, 15 Dec 2008 10:57:00 -0800 (PST) Subject: How to debug hotspot integrated with java codes Message-ID: <21019431.post@talk.nabble.com> Hi, Xiaobin, I tried dbx, but dbx will hang after echo "reading libzip.so" as below: >$ dbx $LD_LIBRARY_PATH/gamma For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc Reading gamma Reading ld-linux.so.2 Reading libjvm.so Reading libm.so.6 Reading libdl.so.2 Reading libpthread.so.0 Reading libc.so.6 (dbx) run -version Running: gamma -version (process id 5777) Reading librt.so.1 Reading libhpi.so Reading libnsl.so.1 Reading libnss_files.so.2 Reading libverify.so Reading libjava.so Reading libzip.so .... Then I have to kill this process to stop it. Do you know how to resolve this problem and start dbx properly? Thanks. xiaobin.lu wrote: > > Refer to > http://developers.sun.com/sunstudio/overview/topics/debug_index.html to > find more details on how to use Sun Studio which is available on Linux > to debug mixed Java and native code. > > -Xiaobin > > Colin(Du Li) wrote: >> Hi, guys. >> >> Now I'm debugging Hotspot. I'm using GDB. When I debug the source codes >> written in c++, it's fine. But if the VM has launched, I cannot trace >> into >> the source codes written in java. e.g. When I find Hotspot cannot load >> some >> class, and I wanna step into the class java.lang.ClassLoader , I don't >> know >> how to trace it. Apparently, I cannot do that with GDB. >> Can you guys give me some suggestion for debug in this situation? >> I spend several days on this problem, and really need some help on the >> debug things. >> >> Thanks a lot in advance!! >> >> >> >> > > > -- View this message in context: http://www.nabble.com/How-to-debug-hotspot-integrated-with-java-codes-tp20984867p21019431.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From Xiaobin.Lu at Sun.COM Mon Dec 15 13:24:54 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Mon, 15 Dec 2008 13:24:54 -0800 Subject: How to debug hotspot integrated with java codes In-Reply-To: <21019431.post@talk.nabble.com> References: <21019431.post@talk.nabble.com> Message-ID: <4946CB26.3090601@Sun.COM> Hi Colin, It looks like the process hang when it tried to load some classes. Did the application work without dbx attached to it? Along the link I sent to you, there is a link (http://developers.sun.com/solaris/articles/Java_debug/Java_debug_content.html) which tells you how to debug Java process, please take a look at it. We have a script to launch dbx internally and it takes care of the LD_LIBRARY_PATH problem as well. I am attaching it in the email. You can start that script as the following: dbxr -server (or -client which loads the server or client VM) -Xiaobin On 12/15/08 10:57, Colin(Du Li) wrote: > Hi, Xiaobin, > > I tried dbx, but dbx will hang after echo "reading libzip.so" as below: > >> $ dbx $LD_LIBRARY_PATH/gamma >> > For information about new features see `help changes' > To remove this message, put `dbxenv suppress_startup_message 7.6' in your > .dbxrc > Reading gamma > Reading ld-linux.so.2 > Reading libjvm.so > Reading libm.so.6 > Reading libdl.so.2 > Reading libpthread.so.0 > Reading libc.so.6 > (dbx) run -version > Running: gamma -version > (process id 5777) > Reading librt.so.1 > Reading libhpi.so > Reading libnsl.so.1 > Reading libnss_files.so.2 > Reading libverify.so > Reading libjava.so > Reading libzip.so > .... > > Then I have to kill this process to stop it. > Do you know how to resolve this problem and start dbx properly? > Thanks. > > > xiaobin.lu wrote: > >> Refer to >> http://developers.sun.com/sunstudio/overview/topics/debug_index.html to >> find more details on how to use Sun Studio which is available on Linux >> to debug mixed Java and native code. >> >> -Xiaobin >> >> Colin(Du Li) wrote: >> >>> Hi, guys. >>> >>> Now I'm debugging Hotspot. I'm using GDB. When I debug the source codes >>> written in c++, it's fine. But if the VM has launched, I cannot trace >>> into >>> the source codes written in java. e.g. When I find Hotspot cannot load >>> some >>> class, and I wanna step into the class java.lang.ClassLoader , I don't >>> know >>> how to trace it. Apparently, I cannot do that with GDB. >>> Can you guys give me some suggestion for debug in this situation? >>> I spend several days on this problem, and really need some help on the >>> debug things. >>> >>> Thanks a lot in advance!! >>> >>> >>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20081215/5312d9a8/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dbxr Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20081215/5312d9a8/attachment.ksh From dawn2004 at gmail.com Mon Dec 15 14:23:39 2008 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Mon, 15 Dec 2008 14:23:39 -0800 (PST) Subject: How to debug hotspot integrated with java codes In-Reply-To: <4946CB26.3090601@Sun.COM> References: <20984867.post@talk.nabble.com> <4942F09B.7070200@Sun.COM> <21019431.post@talk.nabble.com> <4946CB26.3090601@Sun.COM> Message-ID: <21023174.post@talk.nabble.com> Hi, Xiaobin, The "gamma" application works well without dbx attached to it. I tried the script. It give error message "Can't find realpath. Exiting...". I guess I need modified the "realpath" in the script. Right? However, what does "realpath" mean? Thanks a lot. xiaobin.lu wrote: > > Hi Colin, > > It looks like the process hang when it tried to load some classes. Did > the application work without dbx attached to it? > > Along the link I sent to you, there is a link > (http://developers.sun.com/solaris/articles/Java_debug/Java_debug_content.html) > which tells you how to debug Java process, please take a look at it. We > have a script to launch dbx internally and it takes care of the > LD_LIBRARY_PATH problem as well. I am attaching it in the email. You can > start that script as the following: > > dbxr -server (or -client which loads the > server or client VM) > > -Xiaobin > > On 12/15/08 10:57, Colin(Du Li) wrote: >> Hi, Xiaobin, >> >> I tried dbx, but dbx will hang after echo "reading libzip.so" as below: >> >>> $ dbx $LD_LIBRARY_PATH/gamma >>> >> For information about new features see `help changes' >> To remove this message, put `dbxenv suppress_startup_message 7.6' in your >> .dbxrc >> Reading gamma >> Reading ld-linux.so.2 >> Reading libjvm.so >> Reading libm.so.6 >> Reading libdl.so.2 >> Reading libpthread.so.0 >> Reading libc.so.6 >> (dbx) run -version >> Running: gamma -version >> (process id 5777) >> Reading librt.so.1 >> Reading libhpi.so >> Reading libnsl.so.1 >> Reading libnss_files.so.2 >> Reading libverify.so >> Reading libjava.so >> Reading libzip.so >> .... >> >> Then I have to kill this process to stop it. >> Do you know how to resolve this problem and start dbx properly? >> Thanks. >> >> >> xiaobin.lu wrote: >> >>> Refer to >>> http://developers.sun.com/sunstudio/overview/topics/debug_index.html to >>> find more details on how to use Sun Studio which is available on Linux >>> to debug mixed Java and native code. >>> >>> -Xiaobin >>> >>> Colin(Du Li) wrote: >>> >>>> Hi, guys. >>>> >>>> Now I'm debugging Hotspot. I'm using GDB. When I debug the source codes >>>> written in c++, it's fine. But if the VM has launched, I cannot trace >>>> into >>>> the source codes written in java. e.g. When I find Hotspot cannot load >>>> some >>>> class, and I wanna step into the class java.lang.ClassLoader , I don't >>>> know >>>> how to trace it. Apparently, I cannot do that with GDB. >>>> Can you guys give me some suggestion for debug in this situation? >>>> I spend several days on this problem, and really need some help on the >>>> debug things. >>>> >>>> Thanks a lot in advance!! >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> > > > #!/bin/sh > clean_temp_files() { > rm -f /tmp/dbxr.$$ /tmp/cmd.$$ > } > > arch= > if [ -f /proc/cpuinfo ] ; then > arch=`uname -m` > if [ "$arch" = i686 ]; then > arch=i386 > realpath=/net/smite.sfbay/export/linux-i586/bin/realpath > fi > else > arch=`uname -p` > if [ "$arch" = sparc ] ; then > realpath=/home/xl116366/bin/realpath > PATH=/shared/dp/venus/sparc-S2/bin:$PATH > elif [ "$arch" = i386 ] ; then > realpath=/net/smite.sfbay/export/i386/realpath > PATH=/shared/dp/venus/intel-S2/bin:$PATH > fi > fi > if [ -z "$arch" ]; then > echo "Unknown architecture. Exiting..." > exit 1 > fi > > if [ ! -x $realpath ]; then > echo "Can't find realpath. Exiting..." > exit 1 > fi > > exe=$1 > if [ ! -x "$1" ]; then > exe=`which $1` > dir=`$realpath $exe` > else > dir=`$realpath $exe` > fi > dir=`dirname $dir` > dir=`dirname $dir` > if [ `basename $dir` = "bin" ]; then > dir=`dirname $dir` > fi > dir=`$realpath $dir` > > trap clean_temp_files 2 > > usage() { > echo "Usage: dbxr [ -dbx | -gdb ] [ -window ] [ -core ] [ -corefile > ] command ..." > exit > } > > if [ `uname` = "SunOS" ]; then > debugger=dbx > else > debugger=gdb > fi > > debugargs= > debugprecmd= > while [ $# -gt 0 ]; do > if [ $1 = -core ] ; then > debugargs=core > shift > elif [ $1 = -corefile ] ; then > debugargs="$2" > shift 2 > elif [ $1 = -help ] ; then > usage > elif [ $1 = -dbx ] ; then > debugger=dbx > shift > elif [ $1 = -gdb ] ; then > debugger=gdb > shift > elif [ $1 = -window ] ; then > if [ -x /usr/dt/bin/dtterm ]; then > debugprecmd="/usr/dt/bin/dtterm -e" > else > debugprecmd="xterm -e" > fi > shift > elif [ $1 = -echo ] ; then > debugprecmd="echo" > shift > else > break; > fi > done > > jvmcfg=$dir/lib/$arch/jvm.cfg > extra=:$dir/../lib/$arch > if [ -d $dir/jre ]; then > dir=$dir/jre > extra=:$dir/../lib/$arch > jvmcfg=$dir/lib/$arch/jvm.cfg > fi > if [ "$2" = -client ]; then > > LD_LIBRARY_PATH=$dir/lib/$arch/client:$dir/lib/$arch$extra:$LD_LIBRARY_PATH > elif [ "$2" = -server ]; then > > LD_LIBRARY_PATH=$dir/lib/$arch/server:$dir/lib/$arch$extra:$LD_LIBRARY_PATH > elif [ "$2" = -d64 ]; then > if [ "$extra" != "" ]; then > extra=$extra"v9" > fi > > if [ "$arch" = i386 ]; then > > LD_LIBRARY_PATH=$dir/lib/amd64/server:$dir/lib/amd64:$dir/../lib/amd64:$LD_LIBRARY_PATH > #echo $LD_LIBRARY_PATH > else > > LD_LIBRARY_PATH=$dir/lib/sparcv9/server:$dir/lib/sparcv9$extra:$LD_LIBRARY_PATH > fi > else > default=`awk '/^-/ { print substr($1, 2); exit(0); }' $jvmcfg` > > LD_LIBRARY_PATH=$dir/lib/$arch/$default:$dir/lib/$arch$extra:$LD_LIBRARY_PATH > fi > export LD_LIBRARY_PATH PATH > javacmd=$* > > shift > if [ $debugger = "gdb" ] ; then > echo "handle SIGSEGV noprint nostop pass" >> /tmp/cmd.$$ > echo "handle SIGUSR2 noprint nostop pass" >> /tmp/cmd.$$ > echo "handle SIGILL noprint nostop pass" >> /tmp/cmd.$$ > echo "handle SIGABRT print stop nopass" >> /tmp/cmd.$$ > echo "shell rm /tmp/cmd.$$" >> /tmp/cmd.$$ > echo "set args $*" >> /tmp/cmd.$$ > exec $debugprecmd $debugger --command=/tmp/cmd.$$ $exe > else > rm -f /tmp/cmd.$$ > echo $debugargs > if [ "$debugargs" != "" ]; then > echo "debug $exe $debugargs" > /tmp/cmd.$$ > else > echo "debug $exe" >> /tmp/cmd.$$ > echo "runargs $*" >> /tmp/cmd.$$ > fi > echo "if [ -f ~/.dbxr.rc ]; then source ~/.dbxr.rc; fi" >> /tmp/cmd.$$ > echo "rm /tmp/cmd.$$" >> /tmp/cmd.$$ > exec $debugprecmd $debugger -c "source /tmp/cmd.$$" > fi > clean_temp_files > > -- View this message in context: http://www.nabble.com/How-to-debug-hotspot-integrated-with-java-codes-tp20984867p21023174.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From Xiaobin.Lu at Sun.COM Mon Dec 15 14:52:47 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Mon, 15 Dec 2008 14:52:47 -0800 Subject: How to debug hotspot integrated with java codes In-Reply-To: <21023174.post@talk.nabble.com> References: <20984867.post@talk.nabble.com> <4942F09B.7070200@Sun.COM> <21019431.post@talk.nabble.com> <4946CB26.3090601@Sun.COM> <21023174.post@talk.nabble.com> Message-ID: <4946DFBF.9080800@Sun.COM> I am attaching the realpath program and as its name suggests, it resolve the file path and gives it the real full path. -Xiaobin On 12/15/08 14:23, Colin(Du Li) wrote: > Hi, Xiaobin, > > The "gamma" application works well without dbx attached to it. > > I tried the script. It give error message "Can't find realpath. > Exiting...". > I guess I need modified the "realpath" in the script. Right? > However, what does "realpath" mean? > Thanks a lot. > > > xiaobin.lu wrote: > >> Hi Colin, >> >> It looks like the process hang when it tried to load some classes. Did >> the application work without dbx attached to it? >> >> Along the link I sent to you, there is a link >> (http://developers.sun.com/solaris/articles/Java_debug/Java_debug_content.html) >> which tells you how to debug Java process, please take a look at it. We >> have a script to launch dbx internally and it takes care of the >> LD_LIBRARY_PATH problem as well. I am attaching it in the email. You can >> start that script as the following: >> >> dbxr -server (or -client which loads the >> server or client VM) >> >> -Xiaobin >> >> On 12/15/08 10:57, Colin(Du Li) wrote: >> >>> Hi, Xiaobin, >>> >>> I tried dbx, but dbx will hang after echo "reading libzip.so" as below: >>> >>> >>>> $ dbx $LD_LIBRARY_PATH/gamma >>>> >>>> >>> For information about new features see `help changes' >>> To remove this message, put `dbxenv suppress_startup_message 7.6' in your >>> .dbxrc >>> Reading gamma >>> Reading ld-linux.so.2 >>> Reading libjvm.so >>> Reading libm.so.6 >>> Reading libdl.so.2 >>> Reading libpthread.so.0 >>> Reading libc.so.6 >>> (dbx) run -version >>> Running: gamma -version >>> (process id 5777) >>> Reading librt.so.1 >>> Reading libhpi.so >>> Reading libnsl.so.1 >>> Reading libnss_files.so.2 >>> Reading libverify.so >>> Reading libjava.so >>> Reading libzip.so >>> .... >>> >>> Then I have to kill this process to stop it. >>> Do you know how to resolve this problem and start dbx properly? >>> Thanks. >>> >>> >>> xiaobin.lu wrote: >>> >>> >>>> Refer to >>>> http://developers.sun.com/sunstudio/overview/topics/debug_index.html to >>>> find more details on how to use Sun Studio which is available on Linux >>>> to debug mixed Java and native code. >>>> >>>> -Xiaobin >>>> >>>> Colin(Du Li) wrote: >>>> >>>> >>>>> Hi, guys. >>>>> >>>>> Now I'm debugging Hotspot. I'm using GDB. When I debug the source codes >>>>> written in c++, it's fine. But if the VM has launched, I cannot trace >>>>> into >>>>> the source codes written in java. e.g. When I find Hotspot cannot load >>>>> some >>>>> class, and I wanna step into the class java.lang.ClassLoader , I don't >>>>> know >>>>> how to trace it. Apparently, I cannot do that with GDB. >>>>> Can you guys give me some suggestion for debug in this situation? >>>>> I spend several days on this problem, and really need some help on the >>>>> debug things. >>>>> >>>>> Thanks a lot in advance!! >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> #!/bin/sh >> clean_temp_files() { >> rm -f /tmp/dbxr.$$ /tmp/cmd.$$ >> } >> >> arch= >> if [ -f /proc/cpuinfo ] ; then >> arch=`uname -m` >> if [ "$arch" = i686 ]; then >> arch=i386 >> realpath=/net/smite.sfbay/export/linux-i586/bin/realpath >> fi >> else >> arch=`uname -p` >> if [ "$arch" = sparc ] ; then >> realpath=/home/xl116366/bin/realpath >> PATH=/shared/dp/venus/sparc-S2/bin:$PATH >> elif [ "$arch" = i386 ] ; then >> realpath=/net/smite.sfbay/export/i386/realpath >> PATH=/shared/dp/venus/intel-S2/bin:$PATH >> fi >> fi >> if [ -z "$arch" ]; then >> echo "Unknown architecture. Exiting..." >> exit 1 >> fi >> >> if [ ! -x $realpath ]; then >> echo "Can't find realpath. Exiting..." >> exit 1 >> fi >> >> exe=$1 >> if [ ! -x "$1" ]; then >> exe=`which $1` >> dir=`$realpath $exe` >> else >> dir=`$realpath $exe` >> fi >> dir=`dirname $dir` >> dir=`dirname $dir` >> if [ `basename $dir` = "bin" ]; then >> dir=`dirname $dir` >> fi >> dir=`$realpath $dir` >> >> trap clean_temp_files 2 >> >> usage() { >> echo "Usage: dbxr [ -dbx | -gdb ] [ -window ] [ -core ] [ -corefile >> ] command ..." >> exit >> } >> >> if [ `uname` = "SunOS" ]; then >> debugger=dbx >> else >> debugger=gdb >> fi >> >> debugargs= >> debugprecmd= >> while [ $# -gt 0 ]; do >> if [ $1 = -core ] ; then >> debugargs=core >> shift >> elif [ $1 = -corefile ] ; then >> debugargs="$2" >> shift 2 >> elif [ $1 = -help ] ; then >> usage >> elif [ $1 = -dbx ] ; then >> debugger=dbx >> shift >> elif [ $1 = -gdb ] ; then >> debugger=gdb >> shift >> elif [ $1 = -window ] ; then >> if [ -x /usr/dt/bin/dtterm ]; then >> debugprecmd="/usr/dt/bin/dtterm -e" >> else >> debugprecmd="xterm -e" >> fi >> shift >> elif [ $1 = -echo ] ; then >> debugprecmd="echo" >> shift >> else >> break; >> fi >> done >> >> jvmcfg=$dir/lib/$arch/jvm.cfg >> extra=:$dir/../lib/$arch >> if [ -d $dir/jre ]; then >> dir=$dir/jre >> extra=:$dir/../lib/$arch >> jvmcfg=$dir/lib/$arch/jvm.cfg >> fi >> if [ "$2" = -client ]; then >> >> LD_LIBRARY_PATH=$dir/lib/$arch/client:$dir/lib/$arch$extra:$LD_LIBRARY_PATH >> elif [ "$2" = -server ]; then >> >> LD_LIBRARY_PATH=$dir/lib/$arch/server:$dir/lib/$arch$extra:$LD_LIBRARY_PATH >> elif [ "$2" = -d64 ]; then >> if [ "$extra" != "" ]; then >> extra=$extra"v9" >> fi >> >> if [ "$arch" = i386 ]; then >> >> LD_LIBRARY_PATH=$dir/lib/amd64/server:$dir/lib/amd64:$dir/../lib/amd64:$LD_LIBRARY_PATH >> #echo $LD_LIBRARY_PATH >> else >> >> LD_LIBRARY_PATH=$dir/lib/sparcv9/server:$dir/lib/sparcv9$extra:$LD_LIBRARY_PATH >> fi >> else >> default=`awk '/^-/ { print substr($1, 2); exit(0); }' $jvmcfg` >> >> LD_LIBRARY_PATH=$dir/lib/$arch/$default:$dir/lib/$arch$extra:$LD_LIBRARY_PATH >> fi >> export LD_LIBRARY_PATH PATH >> javacmd=$* >> >> shift >> if [ $debugger = "gdb" ] ; then >> echo "handle SIGSEGV noprint nostop pass" >> /tmp/cmd.$$ >> echo "handle SIGUSR2 noprint nostop pass" >> /tmp/cmd.$$ >> echo "handle SIGILL noprint nostop pass" >> /tmp/cmd.$$ >> echo "handle SIGABRT print stop nopass" >> /tmp/cmd.$$ >> echo "shell rm /tmp/cmd.$$" >> /tmp/cmd.$$ >> echo "set args $*" >> /tmp/cmd.$$ >> exec $debugprecmd $debugger --command=/tmp/cmd.$$ $exe >> else >> rm -f /tmp/cmd.$$ >> echo $debugargs >> if [ "$debugargs" != "" ]; then >> echo "debug $exe $debugargs" > /tmp/cmd.$$ >> else >> echo "debug $exe" >> /tmp/cmd.$$ >> echo "runargs $*" >> /tmp/cmd.$$ >> fi >> echo "if [ -f ~/.dbxr.rc ]; then source ~/.dbxr.rc; fi" >> /tmp/cmd.$$ >> echo "rm /tmp/cmd.$$" >> /tmp/cmd.$$ >> exec $debugprecmd $debugger -c "source /tmp/cmd.$$" >> fi >> clean_temp_files >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20081215/9c9cf0ce/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: realpath Type: application/octet-stream Size: 6296 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20081215/9c9cf0ce/attachment.obj From David.Holmes at Sun.COM Tue Dec 16 18:15:56 2008 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Wed, 17 Dec 2008 12:15:56 +1000 Subject: What are the make/solaris/makefiles/reorder_* files ? Message-ID: <494860DC.30504@sun.com> Eg make/solaris/makefiles/reorder_COMPILER1_amd64 What are these files? How are they generated and maintained? Thanks, David Holmes From Vladimir.Kozlov at Sun.COM Tue Dec 16 19:41:32 2008 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 16 Dec 2008 19:41:32 -0800 Subject: What are the make/solaris/makefiles/reorder_* files ? In-Reply-To: <494860DC.30504@sun.com> References: <494860DC.30504@sun.com> Message-ID: <494874EC.5070804@sun.com> These files are used by solaris linker to map hot VM methods into first memory pages for libjvm.so to improve startup (C1) and performance of VM code (C2). Several years ago it gave us up to 2% improvement in jbb2000. The script make/solaris/reorder.sh was used to generate these files, it builds libmcount.so from JDK sources jdk/make/tools/reorder/ and profiled version of VM to use hprof tool to find hot methods (reorder_* files contain the list of all VM methods ordered by invocation count) by running several benchmarks and collecting data. But the script is broken now. Several years ago I thought to fix it and clean reorder_* files to avoid long list of warnings when product version of libjvm.so is built. But I never had time to finish it. There was also an idea to use Sun's Performance Analyzer to generated these map files. And I think, reorder_COMPILER1_amd64 is copy of reorder_COMPILER1_i486. Thanks, Vladimir David Holmes - Sun Microsystems wrote: > Eg make/solaris/makefiles/reorder_COMPILER1_amd64 > > What are these files? How are they generated and maintained? > > Thanks, > David Holmes From David.Holmes at Sun.COM Tue Dec 16 19:46:52 2008 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Wed, 17 Dec 2008 13:46:52 +1000 Subject: What are the make/solaris/makefiles/reorder_* files ? In-Reply-To: <494874EC.5070804@sun.com> References: <494860DC.30504@sun.com> <494874EC.5070804@sun.com> Message-ID: <4948762C.7000806@sun.com> Thanks Vladimir. So these files are out of date in JDK7 too - hadn't realized that. It was the long list of linker warnings (in our product) that I wanted to get rid of too ... maybe I should just drop the use of the reorder list in the mapfile entry. David Vladimir Kozlov said the following on 12/17/08 13:41: > These files are used by solaris linker to map hot VM methods > into first memory pages for libjvm.so to improve startup (C1) > and performance of VM code (C2). Several years ago it gave > us up to 2% improvement in jbb2000. > > The script make/solaris/reorder.sh was used to generate these files, > it builds libmcount.so from JDK sources jdk/make/tools/reorder/ > and profiled version of VM to use hprof tool to find hot methods > (reorder_* files contain the list of all VM methods ordered > by invocation count) by running several benchmarks and collecting data. > > But the script is broken now. Several years ago I thought to fix > it and clean reorder_* files to avoid long list of warnings > when product version of libjvm.so is built. But I never had time > to finish it. There was also an idea to use Sun's Performance Analyzer > to generated these map files. > > And I think, reorder_COMPILER1_amd64 is copy of reorder_COMPILER1_i486. > > Thanks, > Vladimir > > David Holmes - Sun Microsystems wrote: >> Eg make/solaris/makefiles/reorder_COMPILER1_amd64 >> >> What are these files? How are they generated and maintained? >> >> Thanks, >> David Holmes From twisti at complang.tuwien.ac.at Wed Dec 17 01:20:15 2008 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Wed, 17 Dec 2008 10:20:15 +0100 Subject: What are the make/solaris/makefiles/reorder_* files ? In-Reply-To: <494874EC.5070804@sun.com> References: <494860DC.30504@sun.com> <494874EC.5070804@sun.com> Message-ID: <1229505615.8229.26.camel@localhost.localdomain> On Tue, 2008-12-16 at 19:41 -0800, Vladimir Kozlov wrote: > And I think, reorder_COMPILER1_amd64 is copy of reorder_COMPILER1_i486. Almost: $ diff -u reorder_COMPILER1_i486 reorder_COMPILER1_amd64 --- reorder_COMPILER1_i486 2008-09-22 12:14:23.727071401 +0200 +++ reorder_COMPILER1_amd64 2008-09-22 12:14:23.719267555 +0200 @@ -2175,7 +2175,6 @@ text: .text%jni_GetStringUTFRegion: jni.o; text: .text%__1cQjava_lang_StringOas_utf8_string6FpnHoopDesc_ii_pc_; text: .text%JVM_FindClassFromClassLoader; -text: .text%JVM_FindClassFromBootLoader; text: .text%JVM_IsInterface; text: .text%JVM_GetClassDeclaredConstructors; text: .text%__1cNmethodOopDescOis_initializer6kM_i_; - Christian From Paul.Hohensee at Sun.COM Wed Dec 17 07:34:12 2008 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Wed, 17 Dec 2008 10:34:12 -0500 Subject: What are the make/solaris/makefiles/reorder_* files ? In-Reply-To: <4948762C.7000806@sun.com> References: <494860DC.30504@sun.com> <494874EC.5070804@sun.com> <4948762C.7000806@sun.com> Message-ID: <49491BF4.601@sun.com> We "should" run the script when we're about to release a new version of the vm. It's not worth running until we've got a stable release. Paul David Holmes - Sun Microsystems wrote: > Thanks Vladimir. So these files are out of date in JDK7 too - hadn't > realized that. It was the long list of linker warnings (in our > product) that I wanted to get rid of too ... maybe I should just drop > the use of the reorder list in the mapfile entry. > > David > > Vladimir Kozlov said the following on 12/17/08 13:41: >> These files are used by solaris linker to map hot VM methods >> into first memory pages for libjvm.so to improve startup (C1) >> and performance of VM code (C2). Several years ago it gave >> us up to 2% improvement in jbb2000. >> >> The script make/solaris/reorder.sh was used to generate these files, >> it builds libmcount.so from JDK sources jdk/make/tools/reorder/ >> and profiled version of VM to use hprof tool to find hot methods >> (reorder_* files contain the list of all VM methods ordered >> by invocation count) by running several benchmarks and collecting data. >> >> But the script is broken now. Several years ago I thought to fix >> it and clean reorder_* files to avoid long list of warnings >> when product version of libjvm.so is built. But I never had time >> to finish it. There was also an idea to use Sun's Performance Analyzer >> to generated these map files. >> >> And I think, reorder_COMPILER1_amd64 is copy of reorder_COMPILER1_i486. >> >> Thanks, >> Vladimir >> >> David Holmes - Sun Microsystems wrote: >>> Eg make/solaris/makefiles/reorder_COMPILER1_amd64 >>> >>> What are these files? How are they generated and maintained? >>> >>> Thanks, >>> David Holmes From daniel.daugherty at sun.com Wed Dec 17 10:32:15 2008 From: daniel.daugherty at sun.com (daniel.daugherty at sun.com) Date: Wed, 17 Dec 2008 18:32:15 +0000 Subject: hg: jdk7/hotspot/hotspot: 6653214: MemoryPoolMXBean.setUsageThreshold() does not support large heap sizes. Message-ID: <20081217183220.AE5D5D9B7@hg.openjdk.java.net> Changeset: 2494ab195856 Author: swamyv Date: 2008-12-15 13:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2494ab195856 6653214: MemoryPoolMXBean.setUsageThreshold() does not support large heap sizes. Reviewed-by: ysr, mchung ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/services/management.cpp From vladimir.kozlov at sun.com Wed Dec 17 19:27:11 2008 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Thu, 18 Dec 2008 03:27:11 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20081218032715.CEDDADA52@hg.openjdk.java.net> Changeset: dd70dd4c91de Author: kvn Date: 2008-12-16 12:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/dd70dd4c91de 6782820: Server VM fails with "unhandled implicit exception in compiled code" Summary: Restore the code which sets a control edge for a klass load node. Reviewed-by: never ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/macro.cpp Changeset: 6c345e1c5992 Author: kvn Date: 2008-12-17 14:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6c345e1c5992 Merge From vladimir.kozlov at sun.com Thu Dec 18 16:45:56 2008 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 19 Dec 2008 00:45:56 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20081219004600.95CD8DAC0@hg.openjdk.java.net> Changeset: 5496e074077f Author: kvn Date: 2008-12-18 11:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5496e074077f 6787050: assert(n->in(0) == 0L,"no control") with UseCompressedOops on sparcv9 Summary: Relax the assert for Sparc. Reviewed-by: never ! src/share/vm/opto/compile.cpp Changeset: eb811d2ef72e Author: kvn Date: 2008-12-18 13:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/eb811d2ef72e Merge From john.coomes at sun.com Thu Dec 18 23:33:11 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Dec 2008 07:33:11 +0000 Subject: hg: jdk7/hotspot: 3 new changesets Message-ID: <20081219073311.433F2DB17@hg.openjdk.java.net> Changeset: 60aab86966e9 Author: ohair Date: 2008-12-05 17:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/60aab86966e9 6781784: Fix ant link in build readme Reviewed-by: michaelm ! README-builds.html Changeset: 94052b872873 Author: xdono Date: 2008-12-15 10:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/94052b872873 Merge Changeset: 848e684279d2 Author: xdono Date: 2008-12-18 21:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/848e684279d2 Added tag jdk7-b42 for changeset 94052b872873 ! .hgtags From john.coomes at sun.com Thu Dec 18 23:35:08 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Dec 2008 07:35:08 +0000 Subject: hg: jdk7/hotspot/corba: 2 new changesets Message-ID: <20081219073510.99EE9DB1C@hg.openjdk.java.net> Changeset: ccd6a16502e0 Author: xdono Date: 2008-12-15 16:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/ccd6a16502e0 6785258: Update copyright year Summary: Update copyright for files that have been modified starting July 2008 to Dec 2008 Reviewed-by: katleman, ohair, tbell ! make/common/Defs-windows.gmk ! make/common/shared/Compiler-msvc.gmk Changeset: 9cd740d48a48 Author: xdono Date: 2008-12-18 21:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/9cd740d48a48 Added tag jdk7-b42 for changeset ccd6a16502e0 ! .hgtags From john.coomes at sun.com Thu Dec 18 23:38:33 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Dec 2008 07:38:33 +0000 Subject: hg: jdk7/hotspot/jaxp: Added tag jdk7-b42 for changeset 036e0dca841a Message-ID: <20081219073835.68DC3DB21@hg.openjdk.java.net> Changeset: 96fe28d4a913 Author: xdono Date: 2008-12-18 21:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/96fe28d4a913 Added tag jdk7-b42 for changeset 036e0dca841a ! .hgtags From john.coomes at sun.com Thu Dec 18 23:40:33 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Dec 2008 07:40:33 +0000 Subject: hg: jdk7/hotspot/jaxws: Added tag jdk7-b42 for changeset 621c02d83abc Message-ID: <20081219074035.AB48CDB26@hg.openjdk.java.net> Changeset: 1ad2f51564db Author: xdono Date: 2008-12-18 21:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/1ad2f51564db Added tag jdk7-b42 for changeset 621c02d83abc ! .hgtags From john.coomes at sun.com Thu Dec 18 23:42:42 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Dec 2008 07:42:42 +0000 Subject: hg: jdk7/hotspot/jdk: 15 new changesets Message-ID: <20081219074550.932C1DB2B@hg.openjdk.java.net> Changeset: 4f985ba72055 Author: sherman Date: 2008-11-19 14:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4f985ba72055 6714428: 'os.name' system property shows wrong value on 64-bit Windows XP Summary: update to detect the correct os.name for 64-bit XP Reviewed-by: darcy ! src/windows/native/java/lang/java_props_md.c Changeset: 098e456e860e Author: emcmanus Date: 2008-11-20 10:10 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/098e456e860e 6772779: @NotificationInfo does not create MBeanNotificationInfo in the MBean's MBeanInfo 6773593: CompositeDataSupport constructor javadoc is not in sync with the implementation Reviewed-by: sjiang ! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java ! src/share/classes/javax/management/openmbean/CompositeDataSupport.java ! test/javax/management/Introspector/AnnotatedNotificationInfoTest.java Changeset: 9df22bc448a3 Author: sherman Date: 2008-11-20 14:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9df22bc448a3 6745216: missing 4 chraset aliases in sun.nio.cs package Summary: added "834" into x-IBM834's aliase list. Reviewed-by: alanb ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java Changeset: 97e2e87aa035 Author: dfuchs Date: 2008-11-21 18:18 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/97e2e87aa035 6774170: LocalRMIServerSocketFactory should protect against ServerSocket.accept().getInetAddress() being null Reviewed-by: emcmanus, jfdenise ! src/share/classes/sun/management/jmxremote/LocalRMIServerSocketFactory.java + test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java Changeset: ce2d0938ea27 Author: tbell Date: 2008-11-21 20:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ce2d0938ea27 Merge Changeset: d7b0a715bd3b Author: martin Date: 2008-11-23 09:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d7b0a715bd3b 6775152: freetype version check program problem main arg order Summary: Fix all compiler warnings Reviewed-by: ohair, tbell ! make/common/shared/Sanity.gmk Changeset: 31cb1c17f524 Author: mullan Date: 2008-11-25 10:17 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/31cb1c17f524 6728890: Add SwissSign root certificates to the JDK 6732157: Add VeriSign TSA Root Cert to the JDK 6754779: Add Camerfirma root certificates to the JDK 6768559: Add t-systems root CA certificate (Deutsche Telekom Root CA 2) to the JRE Reviewed-by: vinnie ! test/lib/security/cacerts/VerifyCACerts.java Changeset: b1620482689a Author: sherman Date: 2008-11-25 10:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b1620482689a 6774710: spp.sh used by genBasic.sh/genCopyDirectMemory.sh Summary: update the scripts to use java version of spp Reviewed-by: alanb ! test/java/nio/Buffer/genBasic.sh ! test/java/nio/Buffer/genCopyDirectMemory.sh Changeset: b7c47f49a53d Author: alanb Date: 2008-11-25 19:26 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b7c47f49a53d 6593946: (bf) X-Buffer.compact() does not discard mark as specified Summary: InvalidMarkException now correctly thrown. Thanks to keiths at redhat.com for the bug report and initial fix. Reviewed-by: sherman, darcy ! src/share/classes/java/nio/Buffer.java ! src/share/classes/java/nio/ByteBufferAs-X-Buffer.java ! src/share/classes/java/nio/Direct-X-Buffer.java ! src/share/classes/java/nio/Heap-X-Buffer.java ! test/java/nio/Buffer/Basic-X.java ! test/java/nio/Buffer/Basic.java ! test/java/nio/Buffer/BasicByte.java ! test/java/nio/Buffer/BasicChar.java ! test/java/nio/Buffer/BasicDouble.java ! test/java/nio/Buffer/BasicFloat.java ! test/java/nio/Buffer/BasicInt.java ! test/java/nio/Buffer/BasicLong.java ! test/java/nio/Buffer/BasicShort.java ! test/java/nio/Buffer/genBasic.sh Changeset: a0709a172b6d Author: chegar Date: 2008-11-26 15:37 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a0709a172b6d 6720866: Slow performance using HttpURLConnection for upload Reviewed-by: michaelm ! src/share/classes/sun/net/www/http/ChunkedOutputStream.java Changeset: 24a31530683d Author: emcmanus Date: 2008-11-27 15:44 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/24a31530683d 6776225: JMX.isNotificationSource wrong when DynamicWrapperMBean + SendNotification injection Reviewed-by: dfuchs, jfdenise ! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java ! src/share/classes/javax/management/JMX.java ! src/share/classes/javax/management/StandardEmitterMBean.java ! src/share/classes/javax/management/StandardMBean.java ! test/javax/management/MBeanServer/DynamicWrapperMBeanTest.java Changeset: 3d110bb4dc19 Author: sherman Date: 2008-11-29 20:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3d110bb4dc19 6725399: (ch) Channels.newInputStream should check for null Summary: update to check null arg for all Channels methods Reviewed-by: alanb ! src/share/classes/java/nio/channels/Channels.java ! test/java/nio/channels/Channels/Basic.java Changeset: d782143219d6 Author: tbell Date: 2008-12-05 09:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d782143219d6 Merge Changeset: 3ef0bdfa7609 Author: xdono Date: 2008-12-15 16:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3ef0bdfa7609 6785258: Update copyright year Summary: Update copyright for files that have been modified starting July 2008 to Dec 2008 Reviewed-by: katleman, ohair, tbell ! make/javax/swing/Makefile ! make/netbeans/jmx/build.xml ! make/sun/net/spi/Makefile ! make/sun/net/spi/nameservice/Makefile ! src/share/classes/com/sun/java/swing/SwingUtilities3.java ! src/share/classes/com/sun/java/swing/plaf/windows/DesktopProperty.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsDesktopManager.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsScrollBarUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTabbedPaneUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTableHeaderUI.java ! src/share/classes/com/sun/jmx/defaults/ServiceName.java ! src/share/classes/com/sun/jmx/mbeanserver/ClassLoaderRepositorySupport.java ! src/share/classes/com/sun/jmx/mbeanserver/ObjectInputStreamWithLoader.java ! src/share/classes/com/sun/jmx/mbeanserver/SecureClassLoaderRepository.java ! src/share/classes/com/sun/jmx/mbeanserver/WeakIdentityHashMap.java ! src/share/classes/com/sun/jmx/remote/internal/ArrayNotificationBuffer.java ! src/share/classes/com/sun/jmx/remote/internal/Unmarshal.java ! src/share/classes/com/sun/jmx/remote/util/ClassLoaderWithRepository.java ! src/share/classes/com/sun/jmx/remote/util/ClassLogger.java ! src/share/classes/com/sun/jmx/remote/util/OrderClassLoaders.java ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnectionOldImpl.java ! src/share/classes/java/awt/EventDispatchThread.java ! src/share/classes/java/net/HttpURLConnection.java ! src/share/classes/java/nio/Buffer.java ! src/share/classes/java/nio/channels/SelectableChannel.java ! src/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/javax/management/ClientContext.java ! src/share/classes/javax/management/DefaultLoaderRepository.java ! src/share/classes/javax/management/JMRuntimeException.java ! src/share/classes/javax/management/MBeanAttributeInfo.java ! src/share/classes/javax/management/MBeanConstructorInfo.java ! src/share/classes/javax/management/MBeanInfo.java ! src/share/classes/javax/management/Notification.java ! src/share/classes/javax/management/NotificationListener.java ! src/share/classes/javax/management/loading/DefaultLoaderRepository.java ! src/share/classes/javax/management/loading/MLetObjectInputStream.java ! src/share/classes/javax/management/modelmbean/ModelMBeanInfo.java ! src/share/classes/javax/management/openmbean/OpenMBeanParameterInfoSupport.java ! src/share/classes/javax/management/relation/MBeanServerNotificationFilter.java ! src/share/classes/javax/management/relation/Role.java ! src/share/classes/javax/management/relation/RoleList.java ! src/share/classes/javax/management/relation/RoleResult.java ! src/share/classes/javax/management/relation/RoleUnresolved.java ! src/share/classes/javax/management/relation/RoleUnresolvedList.java ! src/share/classes/javax/management/remote/rmi/NoCallStackClassLoader.java ! src/share/classes/javax/management/remote/rmi/RMIConnection.java ! src/share/classes/javax/management/remote/rmi/RMIServerImpl.java ! src/share/classes/javax/swing/AbstractCellEditor.java ! src/share/classes/javax/swing/AbstractListModel.java ! src/share/classes/javax/swing/AbstractSpinnerModel.java ! src/share/classes/javax/swing/ActionMap.java ! src/share/classes/javax/swing/AncestorNotifier.java ! src/share/classes/javax/swing/ArrayTable.java ! src/share/classes/javax/swing/ButtonGroup.java ! src/share/classes/javax/swing/DefaultBoundedRangeModel.java ! src/share/classes/javax/swing/DefaultButtonModel.java ! src/share/classes/javax/swing/DefaultFocusManager.java ! src/share/classes/javax/swing/DefaultSingleSelectionModel.java ! src/share/classes/javax/swing/GroupLayout.java ! src/share/classes/javax/swing/InputMap.java ! src/share/classes/javax/swing/JDesktopPane.java ! src/share/classes/javax/swing/JDialog.java ! src/share/classes/javax/swing/JLayeredPane.java ! src/share/classes/javax/swing/JMenu.java ! src/share/classes/javax/swing/JMenuItem.java ! src/share/classes/javax/swing/JSpinner.java ! src/share/classes/javax/swing/JTextField.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/KeyboardManager.java ! src/share/classes/javax/swing/LayoutComparator.java ! src/share/classes/javax/swing/LayoutFocusTraversalPolicy.java ! src/share/classes/javax/swing/LegacyGlueFocusTraversalPolicy.java ! src/share/classes/javax/swing/MultiUIDefaults.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java ! src/share/classes/javax/swing/SpringLayout.java ! src/share/classes/javax/swing/Timer.java ! src/share/classes/javax/swing/TimerQueue.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/UIManager.java ! src/share/classes/javax/swing/border/CompoundBorder.java ! src/share/classes/javax/swing/plaf/basic/BasicButtonListener.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxEditor.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicGraphicsUtils.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/basic/BasicLabelUI.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicRadioButtonUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToggleButtonUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java ! src/share/classes/javax/swing/plaf/basic/DragRecognitionSupport.java ! src/share/classes/javax/swing/plaf/basic/LazyActionMap.java ! src/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.java ! src/share/classes/javax/swing/plaf/metal/MetalBumps.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/metal/MetalRadioButtonUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSliderUI.java ! src/share/classes/javax/swing/plaf/metal/MetalToolBarUI.java ! src/share/classes/javax/swing/plaf/synth/DefaultSynthStyleFactory.java ! src/share/classes/javax/swing/plaf/synth/ImagePainter.java ! src/share/classes/javax/swing/plaf/synth/Region.java ! src/share/classes/javax/swing/plaf/synth/SynthButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java ! src/share/classes/javax/swing/plaf/synth/SynthContext.java ! src/share/classes/javax/swing/plaf/synth/SynthEditorPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java ! src/share/classes/javax/swing/plaf/synth/SynthParser.java ! src/share/classes/javax/swing/plaf/synth/SynthStyle.java ! src/share/classes/javax/swing/plaf/synth/SynthTextAreaUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java ! src/share/classes/javax/swing/table/AbstractTableModel.java ! src/share/classes/javax/swing/table/DefaultTableModel.java ! src/share/classes/javax/swing/text/AsyncBoxView.java ! src/share/classes/javax/swing/text/ComponentView.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/DefaultHighlighter.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/ElementIterator.java ! src/share/classes/javax/swing/text/GapContent.java ! src/share/classes/javax/swing/text/InternationalFormatter.java ! src/share/classes/javax/swing/text/LayoutQueue.java ! src/share/classes/javax/swing/text/MaskFormatter.java ! src/share/classes/javax/swing/text/SegmentCache.java ! src/share/classes/javax/swing/text/SimpleAttributeSet.java ! src/share/classes/javax/swing/text/StringContent.java ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/javax/swing/text/TableView.java ! src/share/classes/javax/swing/text/TextAction.java ! src/share/classes/javax/swing/text/TextLayoutStrategy.java ! src/share/classes/javax/swing/text/ZoneView.java ! src/share/classes/javax/swing/text/html/HRuleView.java ! src/share/classes/javax/swing/text/html/HTML.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/javax/swing/text/html/HTMLWriter.java ! src/share/classes/javax/swing/text/html/Map.java ! src/share/classes/javax/swing/text/html/MinimalHTMLWriter.java ! src/share/classes/javax/swing/text/html/OptionListModel.java ! src/share/classes/javax/swing/text/html/StyleSheet.java ! src/share/classes/javax/swing/text/html/TableView.java ! src/share/classes/javax/swing/text/html/parser/TagStack.java ! src/share/classes/javax/swing/text/rtf/MockAttributeSet.java ! src/share/classes/javax/swing/text/rtf/RTFParser.java ! src/share/classes/javax/swing/text/rtf/RTFReader.java ! src/share/classes/javax/swing/tree/DefaultTreeCellEditor.java ! src/share/classes/javax/swing/tree/DefaultTreeModel.java ! src/share/classes/javax/swing/tree/FixedHeightLayoutCache.java ! src/share/classes/javax/swing/tree/VariableHeightLayoutCache.java ! src/share/classes/javax/swing/undo/StateEdit.java ! src/share/classes/javax/swing/undo/UndoManager.java ! src/share/classes/javax/swing/undo/UndoableEditSupport.java ! src/share/classes/org/jcp/xml/dsig/internal/DigesterOutputStream.java ! src/share/classes/org/jcp/xml/dsig/internal/SignerOutputStream.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheNodeSetData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheOctetStreamData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMBase64Transform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14NMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalizationMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCryptoBinary.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMDigestMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMEnvelopedTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMExcC14NMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMHMACSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfoFactory.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyName.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperty.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMStructure.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSubTreeData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMUtils.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509Data.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509IssuerSerial.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLObject.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignatureFactory.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXSLTTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java ! src/share/classes/sun/awt/im/CompositionArea.java ! src/share/classes/sun/management/jmxremote/LocalRMIServerSocketFactory.java ! src/share/classes/sun/net/ProgressEvent.java ! src/share/classes/sun/net/httpserver/ExchangeImpl.java ! src/share/classes/sun/net/httpserver/FixedLengthInputStream.java ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/www/protocol/https/HttpsURLConnectionImpl.java ! src/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java ! src/share/classes/sun/swing/AccessibleMethod.java ! src/share/classes/sun/swing/SwingLazyValue.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/share/classes/sun/swing/plaf/synth/DefaultSynthStyle.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java ! src/share/classes/sun/util/calendar/ZoneInfo.java ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java ! src/share/native/sun/font/bidi/ubidi.c ! src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java ! test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh ! test/java/nio/Buffer/Basic-X.java ! test/java/nio/Buffer/Basic.java ! test/java/nio/Buffer/BasicByte.java ! test/java/nio/Buffer/BasicChar.java ! test/java/nio/Buffer/BasicDouble.java ! test/java/nio/Buffer/BasicFloat.java ! test/java/nio/Buffer/BasicInt.java ! test/java/nio/Buffer/BasicLong.java ! test/java/nio/Buffer/BasicShort.java ! test/java/nio/Buffer/genBasic.sh ! test/java/nio/Buffer/genCopyDirectMemory.sh ! test/java/nio/channels/Channels/Basic.java ! test/java/util/TimeZone/OldIDMappingTest.sh ! test/javax/management/Introspector/AnnotationTest.java ! test/javax/management/MBeanServer/MBeanExceptionTest.java ! test/javax/management/context/ContextTest.java ! test/javax/management/context/LocaleTest.java ! test/javax/management/context/LocalizableTest.java ! test/javax/management/context/localizable/MBeanDescriptions_fr.java ! test/javax/management/context/localizable/Whatsit.java ! test/javax/management/context/localizable/WhatsitMBean.java ! test/javax/management/remote/mandatory/provider/ProviderTest.java ! test/javax/management/remote/mandatory/subjectDelegation/SimpleStandard.java ! test/javax/swing/RepaintManager/6608456/bug6608456.java ! test/javax/swing/text/html/HRuleView/Test5062055.java ! test/javax/xml/crypto/dsig/GenerationTests.java Changeset: 51a20a7ee9c8 Author: xdono Date: 2008-12-18 21:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/51a20a7ee9c8 Added tag jdk7-b42 for changeset 3ef0bdfa7609 ! .hgtags From john.coomes at sun.com Thu Dec 18 23:50:44 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Dec 2008 07:50:44 +0000 Subject: hg: jdk7/hotspot/langtools: 6 new changesets Message-ID: <20081219075053.ECDB8DB30@hg.openjdk.java.net> Changeset: 1d1f34b36535 Author: mcimadamore Date: 2008-11-26 11:07 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/1d1f34b36535 6776289: Regression: javac7 doesnt resolve method calls properly Summary: Superclass' private methods shouldn't be considered during method resolution Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/generics/6711619/T6711619a.out + test/tools/javac/overload/T6776289.java Changeset: 6210fb7e7544 Author: jjg Date: 2008-12-01 12:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/6210fb7e7544 6778493: Fix (langtools) ant build to honor fcs MILESTONE setting Reviewed-by: ohair Contributed-by: mjw at redhat.com ! make/Makefile Changeset: 4674298aaf3b Author: tbell Date: 2008-12-05 09:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/4674298aaf3b Merge Changeset: fdfed22db054 Author: xdono Date: 2008-12-15 16:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/fdfed22db054 6785258: Update copyright year Summary: Update copyright for files that have been modified starting July 2008 to Dec 2008 Reviewed-by: katleman, ohair, tbell ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/javac/comp/Todo.java ! src/share/classes/com/sun/tools/javac/util/JavacMessages.java ! src/share/classes/com/sun/tools/javac/util/LayoutCharacters.java ! src/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java ! src/share/classes/com/sun/tools/javadoc/JavadocTodo.java ! src/share/classes/com/sun/tools/javadoc/Main.java ! src/share/classes/com/sun/tools/javadoc/Start.java ! src/share/classes/javax/tools/FileObject.java ! test/com/sun/javadoc/AuthorDD/AuthorDD.java ! test/com/sun/javadoc/lib/JavadocTester.java ! test/com/sun/javadoc/testSupplementary/TestSupplementary.java ! test/tools/apt/Basics/print.sh ! test/tools/apt/Compile/compile.sh ! test/tools/apt/Discovery/discovery.sh ! test/tools/apt/mirror/declaration/AnnoMirror.java ! test/tools/apt/mirror/declaration/AnnoTypeDecl.java ! test/tools/apt/mirror/declaration/AnnoTypeElemDecl.java ! test/tools/apt/mirror/declaration/AnnoVal.java ! test/tools/apt/mirror/declaration/ClassDecl.java ! test/tools/apt/mirror/declaration/ConstExpr.java ! test/tools/apt/mirror/declaration/ConstructorDecl.java ! test/tools/apt/mirror/declaration/EnumDecl.java ! test/tools/apt/mirror/declaration/FieldDecl.java ! test/tools/apt/mirror/declaration/GetAnno.java ! test/tools/apt/mirror/declaration/InterfaceDecl.java ! test/tools/apt/mirror/declaration/MethodDecl.java ! test/tools/apt/mirror/declaration/PackageDecl.java ! test/tools/apt/mirror/declaration/ParameterDecl.java ! test/tools/apt/mirror/type/AnnoTyp.java ! test/tools/apt/mirror/type/ArrayTyp.java ! test/tools/apt/mirror/type/ClassTyp.java ! test/tools/apt/mirror/type/EnumTyp.java ! test/tools/apt/mirror/type/InterfaceTyp.java ! test/tools/apt/mirror/type/PrimitiveTyp.java ! test/tools/apt/mirror/type/TypeVar.java ! test/tools/apt/mirror/type/WildcardTyp.java ! test/tools/apt/mirror/util/Overrides.java ! test/tools/apt/mirror/util/TypeCreation.java ! test/tools/javac/6457284/T6457284.java ! test/tools/javac/links/T.java ! test/tools/javac/links/links.sh ! test/tools/javac/policy/test1/A.java ! test/tools/javac/policy/test1/D.java ! test/tools/javac/policy/test1/Test1a.java ! test/tools/javac/processing/6348193/T6348193.java ! test/tools/javadoc/BooleanConst.java ! test/tools/javadoc/BreakIteratorWarning.java ! test/tools/javadoc/FlagsTooEarly.java ! test/tools/javadoc/InlineTagsWithBraces.java ! test/tools/javadoc/LangVers.java ! test/tools/javadoc/MethodLinks.java ! test/tools/javadoc/NoStar.java ! test/tools/javadoc/T4994049/T4994049.java ! test/tools/javadoc/XWerror.java ! test/tools/javadoc/completionFailure/CompletionFailure.java ! test/tools/javadoc/dupOk/DupOk.java ! test/tools/javadoc/imports/MissingImport.java ! test/tools/javadoc/lib/Tester.java ! test/tools/javadoc/nestedClass/NestedClass.java ! test/tools/javadoc/sourceOnly/p/SourceOnly.java ! test/tools/javadoc/sourceOption/SourceOption.java ! test/tools/javadoc/subpackageIgnore/SubpackageIgnore.java Changeset: 5e5567c2db56 Author: xdono Date: 2008-12-15 17:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/5e5567c2db56 Merge Changeset: b044af4939c9 Author: xdono Date: 2008-12-18 21:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/b044af4939c9 Added tag jdk7-b42 for changeset 5e5567c2db56 ! .hgtags From Xiaobin.Lu at Sun.COM Fri Dec 19 11:42:34 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Fri, 19 Dec 2008 11:42:34 -0800 Subject: review request for 6787106 Message-ID: <494BF92A.405@Sun.COM> http://webrev.invokedynamic.info/xiaobin.lu/6787106/webrev/ CR 6787106: Hotspot 32 bit build fails on platforms having different definitions for intptr_t & int32_t Details: This bug was filed to fix the build failure on Mac OS X and I believe it is a good practice to put back the fix in Openjdk so that the BSD folks or whoever maintain the BSD port could merge the fix into their tree. Basically on Mac OS X, intptr_t & int32_t are not the same type on 32 bit platform and intptr_t and int64_t are not the same either. The former is typedefed as "long" and the latter is typedefed as "int" (or long long for int64_t). Those are usually same types on platforms such as Windows, Solaris and different flavors of Linux. Somewhere in our code, we assume they are the same type and that is where the problem arouse. In assembler_x86.hpp, we have the following definitions in MacroAssembler class: void movptr(Address dst, intptr_t src); void movptr(Address dst, Reigster src); (Register is defined as RegisterImpl*) And when we want to clear some destination address, we simply call "movptr(dest, (int32_t)NULL_WORD);". The cast is necessary to resolve the call to the one which accepts intptr_t as the second parameter. Well, this works on platforms which treat intptr_t & int32_t the same, but will break on other platforms which do not, hence, the build failed. My fix is to redefine NULL_WORD on 32 bit a little bit different, instead of define NULL_WORD as "0", I defined it as "(intptr_t)0". With that, in the places where we want to call "movptr(dest, (int32_t)NULL_WORD);", we can simply call "movptr(dest, NULL_WORD);", therefore, no ambiguity. Tom has a better solution which might address this in a more elegant way, but I don't believe we have enough time to address that in short term and I believe the solution I am suggesting here is ok at least to give a good build on Mac. Reviewed by: Verified by: JPRT Build passed on 32 bit & 64 bit Mac OS 10.5.5. Thanks, -Xiaobin From Xiaobin.Lu at Sun.COM Fri Dec 19 12:20:56 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Fri, 19 Dec 2008 12:20:56 -0800 Subject: review request for 6784100 Message-ID: <494C0228.5000001@Sun.COM> http://webrev.invokedynamic.info/xiaobin.lu/6784100/webrev/ 6784100: getTimeNanos - CAS reduction Details: getTimeNanos() is one of the hot methods for benchmarks such as Volano or SPECjbb. To ensure every calling threads to get most up-to-date time, the current implementation makes each thread to call CAS in a loop until the operation succeeds to set the global max_hrtime on Solaris. Usually, one CAS call succeeds. However, under systems having many cores and application has tons of threads, that call may need to be tried couple times, hence, performance may suffer. The fix is to just call CAS once and if it fails, we just use the current max_hrtime as the return result of getTimeNanos. If it succeeds, we can safely use the most up-to-date time. Performance measurement shows that on batoka system, volano client score improves about 5-6% on 15 runs. I am still running SPECjbb2005 to see whether we could observe any improvement there. The micro-benchmark shows that within certain amount of time, the calls getTimeNanos() doubles with the fix. Reviewed by: Contributed by: Dave Dice Verified by: JPRT (in progress). Thanks, -Xiaobin From John.Rose at Sun.COM Fri Dec 19 13:33:56 2008 From: John.Rose at Sun.COM (John Rose) Date: Fri, 19 Dec 2008 13:33:56 -0800 Subject: review request for 6787106 In-Reply-To: <494BF92A.405@Sun.COM> References: <494BF92A.405@Sun.COM> Message-ID: <84BEECB7-A6D4-42AF-9B4C-879EA15D2356@sun.com> +1 for BSD support, +1 for fewer casts, +1 for 32/64 source convergence! Two minor comments: Don't replace a name by a naked constant; use a cast in templateTable_x86_32: - __ movl(Address(rdx, 0), NULL_WORD); + __ movl(Address(rdx, 0), 0); ++ __ movl(Address(rdx, 0), (int32_t)NULL_WORD); It would be better to put parens around the macro definition: - #define NULL_WORD 0 + #define NULL_WORD (intptr_t)0 ++ #define NULL_WORD ((intptr_t)0) Reviewed. -- John On Dec 19, 2008, at 11:42 AM, Xiaobin Lu wrote: > http://webrev.invokedynamic.info/xiaobin.lu/6787106/webrev/ > > CR 6787106: Hotspot 32 bit build fails on platforms having > different definitions for intptr_t & int32_t -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20081219/75f3759a/attachment.html From David.Holmes at Sun.COM Fri Dec 19 15:13:12 2008 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Sat, 20 Dec 2008 09:13:12 +1000 Subject: review request for 6784100 In-Reply-To: <494C0228.5000001@Sun.COM> References: <494C0228.5000001@Sun.COM> Message-ID: <494C2A88.3050905@sun.com> Hi Xiaobin, This looks ok to me. It's somewhat sad that on a system where gethrtime never does the wrong thing and is in fact monotonic, that we end up always doing the most amount of work in getTimeNanos. Cheers, David Xiaobin Lu said the following on 12/20/08 06:20: > http://webrev.invokedynamic.info/xiaobin.lu/6784100/webrev/ > > 6784100: getTimeNanos - CAS reduction > > Details: > > getTimeNanos() is one of the hot methods for benchmarks such as Volano > or SPECjbb. To ensure every calling threads to get most up-to-date time, > the current implementation makes each thread to call CAS in a loop until > the operation succeeds to set the global max_hrtime on Solaris. Usually, > one CAS call succeeds. However, under systems having many cores and > application has tons of threads, that call may need to be tried couple > times, hence, performance may suffer. > > The fix is to just call CAS once and if it fails, we just use the > current max_hrtime as the return result of getTimeNanos. If it succeeds, > we can safely use the most up-to-date time. Performance measurement > shows that on batoka system, volano client score improves about 5-6% on > 15 runs. I am still running SPECjbb2005 to see whether we could observe > any improvement there. The micro-benchmark shows that within certain > amount of time, the calls getTimeNanos() doubles with the fix. > > Reviewed by: > Contributed by: Dave Dice > Verified by: > > JPRT (in progress). > > Thanks, > -Xiaobin > > From jon.masamitsu at sun.com Fri Dec 19 17:38:25 2008 From: jon.masamitsu at sun.com (jon.masamitsu at sun.com) Date: Sat, 20 Dec 2008 01:38:25 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20081220013833.50246DC1A@hg.openjdk.java.net> Changeset: d593294016c3 Author: jcoomes Date: 2008-12-18 01:27 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d593294016c3 6786195: many nsk.monitoring tests fail with -server -Xcomp Summary: remove Universe::_fillerArrayKlassObj and associated code Reviewed-by: jmasa, tonyp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp Changeset: 234c22e54b98 Author: jcoomes Date: 2008-12-18 10:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/234c22e54b98 6784849: par compact - can fail when to_space is non-empty Reviewed-by: jmasa, tonyp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp Changeset: b27c885f75f9 Author: jcoomes Date: 2008-12-18 10:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b27c885f75f9 6786188: par compact - "SplitALot" stress mode should fill to_space Reviewed-by: jmasa, tonyp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp Changeset: 7aadaf46ecd7 Author: jmasa Date: 2008-12-19 12:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7aadaf46ecd7 Merge From xiaobin.lu at sun.com Sat Dec 20 03:40:43 2008 From: xiaobin.lu at sun.com (xiaobin.lu at sun.com) Date: Sat, 20 Dec 2008 11:40:43 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20081220114049.A1CD3DC55@hg.openjdk.java.net> Changeset: c6065343356f Author: poonam Date: 2008-12-18 17:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c6065343356f 6786340: hs14b09a pit: a lot of tests failed in "-server -Xcomp" on solaris-amd64 using fastdebug bits Summary: Fixes the nsk-jdi PIT failures introduced by fix for 6739363 Reviewed-by: kvn, coleenp ! src/share/vm/runtime/javaCalls.cpp Changeset: 8a25d96bcf08 Author: xlu Date: 2008-12-19 14:40 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8a25d96bcf08 6784100: getTimeNanos - CAS reduction Summary: Get rid of the CAS loop in getTimeNanos to reduce coherence traffic on Solaris. Reviewed-by: acorn, kvn, ysr ! src/os/solaris/vm/os_solaris.cpp Changeset: ca7d48236048 Author: xlu Date: 2008-12-20 00:45 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ca7d48236048 Merge From groundskeeperwiley at yahoo.com Fri Dec 19 19:23:36 2008 From: groundskeeperwiley at yahoo.com (James Walsh) Date: Fri, 19 Dec 2008 19:23:36 -0800 (PST) Subject: SuperWord optimization Message-ID: <535236.3158.qm@web30006.mail.mud.yahoo.com> I have some basic questions about this optimization. Can anyone tell me what SSE instructions are supported by SuperWord? I've run a very simple program that should be accelerated by the packed move and arithmetic opcodes available in SSE but the code generated appears to be MMX. I've run the program with a 1.7 debug build with -XX:+TraceSuperWord and -XX:+Verbose and from the resulting data printed out it looks like SuperWord does recognize that my program should be optimized. Yet in the end the arithmetic optimizations are rejected as unsupported and the load/stores are rejected as unproductive. I looked in the file called /src/cpu/x86/vm/assembler_x86 and the only SSE opcode that I recognize is MOVAPS(xmm,xmm). Does the compiler know how to emit ADDPS/SUBPS/MULPS/DIVPS opcodes and I'm just looking in the wrong spot? From Ulf.Zibis at gmx.de Sun Dec 21 12:39:22 2008 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sun, 21 Dec 2008 21:39:22 +0100 Subject: java-nio-charset-enhanced -- Milestone 3 is released Message-ID: <494EA97A.6060404@gmx.de> Hi folks, milestone 3 of charset enhancement is released. - compared to JDK 6 classes, I downsized the footprint to 13 %, which also should perform class loading, because encoder maps will be lazy initialized. - additionally memory consumption of those encoders is reduced to roundabout 30 %, depending on particular charset. - In this release I established an alternative mapping technique, which should be faster for most real text's character distribution with minimal mapping failures, but maybe slower on massive occurrence of unmappable codes or rare characters. See my projects home: ---> https://java-nio-charset-enhanced.dev.java.net/ I believe, these technics could also be used for most multi-byte charsets. Happy holidays, -Ulf From rasbold at google.com Tue Dec 23 10:21:36 2008 From: rasbold at google.com (Chuck Rasbold) Date: Tue, 23 Dec 2008 10:21:36 -0800 Subject: SuperWord optimization In-Reply-To: <535236.3158.qm@web30006.mail.mud.yahoo.com> References: <535236.3158.qm@web30006.mail.mud.yahoo.com> Message-ID: <4149a0430812231021r7e1a600budf99a1b8be4de070@mail.gmail.com> You are looking in the wrong spot. The match rules for the server compiler are in src/cpu/x86/vm/x86*.ad. There you will see match rules for some double arithmetic operations, but not float or int, for example. Without the appropriate match rule, the superword transformation will reject an operation as unimplemented. Operations which are implemented but do not have the necessary vector inputs will be reported as unprofitable. Remember that superword is a work in progress, and one that is stalled, at that. There are bugs, as well as unimplemented features, and as you play with it, you'll run into a little of both. -- Chuck On Fri, Dec 19, 2008 at 7:23 PM, James Walsh wrote: > I have some basic questions about this optimization. Can anyone tell me what SSE instructions are supported by SuperWord? I've run a very simple program that should be accelerated by the packed move and arithmetic opcodes available in SSE but the code generated appears to be MMX. I've run the program with a 1.7 debug build with -XX:+TraceSuperWord and -XX:+Verbose and from the resulting data printed out it looks like SuperWord does recognize that my program should be optimized. Yet in the end the arithmetic optimizations are rejected as unsupported and the load/stores are rejected as unproductive. I looked in the file called /src/cpu/x86/vm/assembler_x86 and the only SSE opcode that I recognize is MOVAPS(xmm,xmm). Does the compiler know how to emit ADDPS/SUBPS/MULPS/DIVPS opcodes and I'm just looking in the wrong spot? > > > > From Vladimir.Kozlov at Sun.COM Tue Dec 23 12:13:04 2008 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 23 Dec 2008 12:13:04 -0800 Subject: Request for reviews (XS): 6788376: allow to ignore unrecognized VM options Message-ID: <49514650.5010602@sun.com> http://webrev.invokedynamic.info/kvn/6788376/index.html Fixed 6788376: allow to ignore unrecognized VM options Problem: Hotspot has flags which could be unavailable in different versions (server vs client, product vs debug) of VM. It complicates VM testing. Solution: Add new product flag -XX:+IgnoreUnrecognizedVMOptions. By default it is off. It does not works with options specified in a flags file (-XX:Flags=file). Add the flag to the test compiler/6775880/Test.java to run it with product VM (DeoptimizeALot flag is the debug flag unavailable in product VM). Reviewed by: Fix verified (y/n): y Other testing: JPRT From erik.trimble at sun.com Tue Dec 23 15:02:44 2008 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Tue, 23 Dec 2008 23:02:44 +0000 Subject: hg: jdk7/hotspot/hotspot: 5 new changesets Message-ID: <20081223230253.8DB12DE5A@hg.openjdk.java.net> Changeset: ad8c8ca4ab0f Author: xdono Date: 2008-12-15 16:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ad8c8ca4ab0f 6785258: Update copyright year Summary: Update copyright for files that have been modified starting July 2008 to Dec 2008 Reviewed-by: katleman, ohair, tbell ! src/cpu/x86/vm/vm_version_x86_32.hpp ! src/cpu/x86/vm/vm_version_x86_64.hpp ! src/os/linux/launcher/java.c ! src/os/linux/launcher/java.h ! src/os/linux/launcher/java_md.c ! src/os/linux/vm/globals_linux.hpp ! src/os/solaris/launcher/java.c ! src/os/solaris/launcher/java.h ! src/os/solaris/launcher/java_md.c ! src/os/solaris/vm/globals_solaris.hpp ! src/os/windows/vm/globals_windows.hpp ! src/os/windows/vm/os_windows.hpp ! src/os_cpu/linux_x86/vm/linux_x86_32.ad ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/XMLWriter.java ! src/share/tools/IdealGraphVisualizer/Difference/src/com/sun/hotspot/igv/difference/Difference.java ! src/share/tools/IdealGraphVisualizer/Filter/src/com/sun/hotspot/igv/filter/CustomFilter.java ! src/share/tools/IdealGraphVisualizer/Util/src/com/sun/hotspot/igv/util/PropertiesSheet.java ! src/share/tools/IdealGraphVisualizer/Util/src/com/sun/hotspot/igv/util/RangeSliderModel.java ! src/share/tools/IdealGraphVisualizer/View/src/com/sun/hotspot/igv/view/DiagramViewModel.java ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/adlparse.hpp ! src/share/vm/adlc/filebuff.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp ! src/share/vm/interpreter/bytecodeStream.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/memory/referencePolicy.cpp ! src/share/vm/memory/referencePolicy.hpp ! src/share/vm/memory/tenuredGeneration.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phase.hpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jniCheck.hpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiTrace.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/perfMemory.cpp ! src/share/vm/runtime/perfMemory.hpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/services/threadService.hpp ! src/share/vm/utilities/array.hpp ! src/share/vm/utilities/constantTag.hpp ! src/share/vm/utilities/growableArray.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/taskqueue.cpp Changeset: 5e5faba1ac11 Author: xdono Date: 2008-12-18 21:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5e5faba1ac11 Added tag jdk7-b42 for changeset ad8c8ca4ab0f ! .hgtags Changeset: 569b3b226089 Author: trims Date: 2008-12-20 09:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/569b3b226089 Merge ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/adlparse.hpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp Changeset: 26bc4770e671 Author: trims Date: 2008-12-20 09:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/26bc4770e671 Merge ! src/share/vm/runtime/javaCalls.cpp Changeset: fc6a5ae3fef5 Author: trims Date: 2008-12-20 09:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fc6a5ae3fef5 6787832: Bump Hotspot build number to 08 Summary: Update the HS14 build number to 08 Reviewed-by: jcoomes ! make/hotspot_version From erik.trimble at sun.com Tue Dec 23 19:31:06 2008 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Wed, 24 Dec 2008 03:31:06 +0000 Subject: hg: jdk7/hotspot/hotspot: 6788797: Fork HS14 to HS15 - renumber Major and build numbers of JVM Message-ID: <20081224033108.85DE7DE81@hg.openjdk.java.net> Changeset: 3cd5c5b027b1 Author: trims Date: 2008-12-23 19:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3cd5c5b027b1 6788797: Fork HS14 to HS15 - renumber Major and build numbers of JVM Summary: fork Hotspot 15 - redo verisoning numbers Reviewed-by: jcoomes ! make/hotspot_version From groundskeeperwiley at yahoo.com Wed Dec 24 13:13:15 2008 From: groundskeeperwiley at yahoo.com (James Walsh) Date: Wed, 24 Dec 2008 13:13:15 -0800 (PST) Subject: SuperWord optimization References: <535236.3158.qm@web30006.mail.mud.yahoo.com> <4149a0430812231021r7e1a600budf99a1b8be4de070@mail.gmail.com> Message-ID: <657532.97748.qm@web30003.mail.mud.yahoo.com> I found that definition file after I posted the list. It's going to take a while for me to wrap my head around hotspot. Is work on SuperWord stalled because of a fundamental problem with the code or is it a warm body issue? I'm interested in getting it into a working state. I hope no one minds me asking a lot of questions like the following: While perusing the repository for SSE code I noticed this code in a couple places, like x86_32.ad, to speed up neg/abs: static jlong* double_quadword(jlong *adr, jlong lo, jlong hi) { jlong *operand = (jlong*)(((long)adr)&((long)(~0xF))); operand[0] = lo; operand[1] = hi; return operand; } While this will certainly align operand to a 16byte boundary doesn't it run the risk of backing the pointer up too far and modifying the wrong address? Shouldn't adr be advanced 15 bytes and then have the logical AND applied to align operand to the first 16byte aligned memory address that starts at or after adr? Thanks for the quick response and happy holidays. ----- Original Message ---- From: Chuck Rasbold To: hotspot-dev at openjdk.java.net Sent: Wednesday, December 24, 2008 12:21:36 PM Subject: Re: SuperWord optimization You are looking in the wrong spot. The match rules for the server compiler are in src/cpu/x86/vm/x86*.ad. There you will see match rules for some double arithmetic operations, but not float or int, for example. Without the appropriate match rule, the superword transformation will reject an operation as unimplemented. Operations which are implemented but do not have the necessary vector inputs will be reported as unprofitable. Remember that superword is a work in progress, and one that is stalled, at that. There are bugs, as well as unimplemented features, and as you play with it, you'll run into a little of both. -- Chuck From christian.thalinger at gmail.com Sat Dec 27 02:42:29 2008 From: christian.thalinger at gmail.com (Christian Thalinger) Date: Sat, 27 Dec 2008 11:42:29 +0100 Subject: hg: jdk7/hotspot/hotspot: 6788797: Fork HS14 to HS15 - renumber Major and build numbers of JVM In-Reply-To: <20081224033108.85DE7DE81@hg.openjdk.java.net> References: <20081224033108.85DE7DE81@hg.openjdk.java.net> Message-ID: <1230374549.1229.22.camel@localhost.localdomain> On Wed, 2008-12-24 at 03:31 +0000, erik.trimble at sun.com wrote: > Changeset: 3cd5c5b027b1 > Author: trims > Date: 2008-12-23 19:28 -0800 > URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3cd5c5b027b1 > > 6788797: Fork HS14 to HS15 - renumber Major and build numbers of JVM > Summary: fork Hotspot 15 - redo verisoning numbers > Reviewed-by: jcoomes > > ! make/hotspot_version Out of curiosity, are there any milestones to bump HotSpot's major version? And if yes, what milestones are these and are they listed somewhere? I just found these bugs: [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6590301 [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6717462 [3] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6788797 which contain very little information. - Christian From volker.simonis at gmail.com Sat Dec 27 08:30:27 2008 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 27 Dec 2008 17:30:27 +0100 Subject: hg: jdk7/hotspot/hotspot: 6788797: Fork HS14 to HS15 - renumber Major and build numbers of JVM In-Reply-To: <1230374549.1229.22.camel@localhost.localdomain> References: <20081224033108.85DE7DE81@hg.openjdk.java.net> <1230374549.1229.22.camel@localhost.localdomain> Message-ID: ..and what does "Fork" mean in this context. For me this sounds as if the HS14 will continue to live in its own "branch". Will this be the "Express" VM which will be integrated into JDK 1.6 eventually? And where will the future development (I assume its more or less bug fixing?) of HS14 take place - will it be an open repository or a closed one? Thanks for the clarifications, Volker On Sat, Dec 27, 2008 at 11:42 AM, Christian Thalinger wrote: > > On Wed, 2008-12-24 at 03:31 +0000, erik.trimble at sun.com wrote: >> Changeset: 3cd5c5b027b1 >> Author: trims >> Date: 2008-12-23 19:28 -0800 >> URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3cd5c5b027b1 >> >> 6788797: Fork HS14 to HS15 - renumber Major and build numbers of JVM >> Summary: fork Hotspot 15 - redo verisoning numbers >> Reviewed-by: jcoomes >> >> ! make/hotspot_version > > Out of curiosity, are there any milestones to bump HotSpot's major > version? And if yes, what milestones are these and are they listed > somewhere? > > I just found these bugs: > > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6590301 > [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6717462 > [3] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6788797 > > which contain very little information. > > - Christian > > From James.Melvin at Sun.COM Sat Dec 27 11:18:49 2008 From: James.Melvin at Sun.COM (James Melvin) Date: Sat, 27 Dec 2008 14:18:49 -0500 Subject: hg: jdk7/hotspot/hotspot: 6788797: Fork HS14 to HS15 - renumber Major and build numbers of JVM In-Reply-To: <1230374549.1229.22.camel@localhost.localdomain> References: <20081224033108.85DE7DE81@hg.openjdk.java.net> <1230374549.1229.22.camel@localhost.localdomain> Message-ID: <49567F99.4000003@sun.com> Hi Christian, Hotspot productization is largely date-driven to align with other software deliveries or hardware launches. Thus, such milestones can't be public. Hotspot features are mostly on a train model... when ready, they get picked up and delivered in the next release, or in some cases 'turned on'. At the moment, HS15 is open for business, but is not yet fully planned. It's a great time to integrate features and higher risk bugfixes that require more extended bake time to fully stabilize. January will be a good time to assess the progress of various projects and determine which might align best with HS15. The challenge is the endgame is currently undefined and depends on several moving targets several months into 2009. Java is a pretty big ecosystem with Hotspot at the center. Although not definitive, I hope this helps provide some additional context for Hotspot releases and how things are basically managed. Going forward, we hope to externalize more of the process to the extent it's possible and there is sufficient bandwidth to manage things. This will help improve both transparency and participation. Thanks, Jim Christian Thalinger wrote: > On Wed, 2008-12-24 at 03:31 +0000, erik.trimble at sun.com wrote: >> Changeset: 3cd5c5b027b1 >> Author: trims >> Date: 2008-12-23 19:28 -0800 >> URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3cd5c5b027b1 >> >> 6788797: Fork HS14 to HS15 - renumber Major and build numbers of JVM >> Summary: fork Hotspot 15 - redo verisoning numbers >> Reviewed-by: jcoomes >> >> ! make/hotspot_version > > Out of curiosity, are there any milestones to bump HotSpot's major > version? And if yes, what milestones are these and are they listed > somewhere? > > I just found these bugs: > > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6590301 > [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6717462 > [3] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6788797 > > which contain very little information. > > - Christian > From James.Melvin at Sun.COM Sat Dec 27 12:21:46 2008 From: James.Melvin at Sun.COM (James Melvin) Date: Sat, 27 Dec 2008 15:21:46 -0500 Subject: hg: jdk7/hotspot/hotspot: 6788797: Fork HS14 to HS15 - renumber Major and build numbers of JVM In-Reply-To: References: <20081224033108.85DE7DE81@hg.openjdk.java.net> <1230374549.1229.22.camel@localhost.localdomain> Message-ID: <49568E5A.9060901@sun.com> > ..and what does "Fork" mean in this context. For me this sounds as if > the HS14 will continue to live in its own "branch". Yes, exactly. A copy ("fork") of the current mainline repository is being made for independent stabilization and delivery. This serves 2 purposes... 1) HS14 controlled stabilization and testing for production delivery 2) HS15 continues to be open for business, unabated I imagine this is a familiar development model in Software. > Will this be the "Express" VM which will be integrated into JDK 1.6 > eventually? Yes. Hotspot now productizes more frequently than the JDK. The idea behind "Hotspot Express" is to make the latest stable Hotspot source available to stabilizing JDKs for testing and delivery as a matched set. Note, this does not imply mix-and-match of binaries however. Fully tested pairs only to mitigate risk. > And where will the future development (I assume its more or less bug > fixing?) of HS14 take place - will it be an open repository or a > closed one? I presume closed, subject to OpenJDK6's adoption of HS14. But it's important to note that any bugs resolved in HS14 *must* be forward ported to HS15, if applicable. Also, bugfixes made to HS15, which are deemed critical to HS14, will be considered for backport if there is sufficient time for full testing. Security bugs are treated with priority. I'll take an action item to better document the "Hotspot Express" delivery model and make sure it's posted. Hope this helps, Jim Volker Simonis wrote: > ..and what does "Fork" mean in this context. For me this sounds as if > the HS14 will continue to live in its own "branch". Will this be the > "Express" VM which will be integrated into JDK 1.6 eventually? And > where will the future development (I assume its more or less bug > fixing?) of HS14 take place - will it be an open repository or a > closed one? > > Thanks for the clarifications, > Volker > > On Sat, Dec 27, 2008 at 11:42 AM, Christian Thalinger > wrote: >> On Wed, 2008-12-24 at 03:31 +0000, erik.trimble at sun.com wrote: >>> Changeset: 3cd5c5b027b1 >>> Author: trims >>> Date: 2008-12-23 19:28 -0800 >>> URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3cd5c5b027b1 >>> >>> 6788797: Fork HS14 to HS15 - renumber Major and build numbers of JVM >>> Summary: fork Hotspot 15 - redo verisoning numbers >>> Reviewed-by: jcoomes >>> >>> ! make/hotspot_version >> Out of curiosity, are there any milestones to bump HotSpot's major >> version? And if yes, what milestones are these and are they listed >> somewhere? >> >> I just found these bugs: >> >> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6590301 >> [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6717462 >> [3] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6788797 >> >> which contain very little information. >> >> - Christian >> >> From rasbold at google.com Mon Dec 29 09:53:17 2008 From: rasbold at google.com (Chuck Rasbold) Date: Mon, 29 Dec 2008 09:53:17 -0800 Subject: SuperWord optimization In-Reply-To: <657532.97748.qm@web30003.mail.mud.yahoo.com> References: <535236.3158.qm@web30006.mail.mud.yahoo.com> <4149a0430812231021r7e1a600budf99a1b8be4de070@mail.gmail.com> <657532.97748.qm@web30003.mail.mud.yahoo.com> Message-ID: <4149a0430812290953o43f864f7ve9e3496ef565906b@mail.gmail.com> The last I knew, the thing holding up SuperWord was a resource issue. But that was several months ago and I don't have any more recent information. As for the double_quadword function in x86_32.ad, it looks to me like the fp_signmask_pool is set up such that the extra buffer space for alignment adjustments is at the beginning of the pool, not the end. I think it will work reliably as coded. I can see how your first instinct would be to put it at the end, though, as you suggest. -- Chuck On Wed, Dec 24, 2008 at 1:13 PM, James Walsh wrote: > I found that definition file after I posted the list. It's going to take a while for > me to wrap my head around hotspot. Is work on > SuperWord stalled > because of a fundamental problem with the code or is > it a warm body issue? > I'm interested in getting it into a working state. I hope no one minds me asking > a lot of questions like the following: > > While perusing the repository for SSE code I noticed this code in a couple > places, like x86_32.ad, to speed up neg/abs: > > static jlong* double_quadword(jlong *adr, jlong lo, jlong hi) { > jlong *operand = (jlong*)(((long)adr)&((long)(~0xF))); > operand[0] = lo; > operand[1] = hi; > return operand; > } > > While this will certainly align operand to a 16byte boundary doesn't it run the risk > of backing the pointer up too far and modifying the wrong address? Shouldn't > adr be advanced 15 bytes and then have the logical AND applied to align operand > to the first 16byte aligned memory address that starts at or after adr? > > Thanks for the quick response and happy holidays. > > > > > > ----- Original Message ---- > From: Chuck Rasbold > To: hotspot-dev at openjdk.java.net > Sent: Wednesday, December 24, 2008 12:21:36 PM > Subject: Re: SuperWord optimization > > You are looking in the wrong spot. The match rules for the server > compiler are in src/cpu/x86/vm/x86*.ad. There you will see match rules > for some double arithmetic operations, but not float or int, for > example. > > Without the appropriate match rule, the superword transformation will > reject an operation as unimplemented. Operations which are implemented > but do not have the necessary vector inputs will be reported as > unprofitable. > > Remember that superword is a work in progress, and one that is > stalled, at that. There are bugs, as well as unimplemented features, > and as you play with it, you'll run into a little of both. > > -- Chuck > > > > > From volker.simonis at gmail.com Tue Dec 30 01:55:17 2008 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 30 Dec 2008 10:55:17 +0100 Subject: hg: jdk7/hotspot/hotspot: 6788797: Fork HS14 to HS15 - renumber Major and build numbers of JVM In-Reply-To: <49568E5A.9060901@sun.com> References: <20081224033108.85DE7DE81@hg.openjdk.java.net> <1230374549.1229.22.camel@localhost.localdomain> <49568E5A.9060901@sun.com> Message-ID: Hi James, thank you for the detailed description. Especially the following part was quite interesting for me: "But it's important to note that any bugs resolved in HS14 *must* be forward ported to HS15, if applicable. Also, bugfixes made to HS15, which are deemed critical to HS14, will be considered for backport if there is sufficient time for full testing." How could someone who wants to deliver a "as stable as possible" release of the OpenJDK HotSpot VM take advantage of this model. Is there a way to identify changes which are forwarded from the HS14 branch into the head trunk and the other way round, identify changes in the head revision which are considered for backporting into HS14? I.e. will it be possible for an external observer to build something which is "close" to a Sun-released HotSpot VM from the OpenJDK repository? In this context I've recently realized that some bugs are duplicated in the bug database. Is this because the same bug appearing in both, the head trunk and a "stabilization repository", needs two different bug IDs such that it can be fixed independently in both code lines? Could this be used to identify changes in the head revision which have also been made to a stabilized version? Thank you and a happy new year, Volker On Sat, Dec 27, 2008 at 9:21 PM, James Melvin wrote: >> ..and what does "Fork" mean in this context. For me this sounds as if >> the HS14 will continue to live in its own "branch". > > Yes, exactly. A copy ("fork") of the current mainline repository is > being made for independent stabilization and delivery. This serves 2 > purposes... > > 1) HS14 controlled stabilization and testing for production delivery > 2) HS15 continues to be open for business, unabated > > I imagine this is a familiar development model in Software. > > >> Will this be the "Express" VM which will be integrated into JDK 1.6 >> eventually? > > Yes. Hotspot now productizes more frequently than the JDK. The idea > behind "Hotspot Express" is to make the latest stable Hotspot source > available to stabilizing JDKs for testing and delivery as a matched set. > Note, this does not imply mix-and-match of binaries however. Fully > tested pairs only to mitigate risk. > > >> And where will the future development (I assume its more or less bug >> fixing?) of HS14 take place - will it be an open repository or a >> closed one? > > I presume closed, subject to OpenJDK6's adoption of HS14. But it's > important to note that any bugs resolved in HS14 *must* be forward > ported to HS15, if applicable. Also, bugfixes made to HS15, which are > deemed critical to HS14, will be considered for backport if there is > sufficient time for full testing. Security bugs are treated with priority. > > I'll take an action item to better document the "Hotspot Express" > delivery model and make sure it's posted. > > > Hope this helps, > > Jim > > > > Volker Simonis wrote: >> >> ..and what does "Fork" mean in this context. For me this sounds as if >> the HS14 will continue to live in its own "branch". Will this be the >> "Express" VM which will be integrated into JDK 1.6 eventually? And >> where will the future development (I assume its more or less bug >> fixing?) of HS14 take place - will it be an open repository or a >> closed one? >> >> Thanks for the clarifications, >> Volker >> >> On Sat, Dec 27, 2008 at 11:42 AM, Christian Thalinger >> wrote: >>> >>> On Wed, 2008-12-24 at 03:31 +0000, erik.trimble at sun.com wrote: >>>> >>>> Changeset: 3cd5c5b027b1 >>>> Author: trims >>>> Date: 2008-12-23 19:28 -0800 >>>> URL: >>>> http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3cd5c5b027b1 >>>> >>>> 6788797: Fork HS14 to HS15 - renumber Major and build numbers of JVM >>>> Summary: fork Hotspot 15 - redo verisoning numbers >>>> Reviewed-by: jcoomes >>>> >>>> ! make/hotspot_version >>> >>> Out of curiosity, are there any milestones to bump HotSpot's major >>> version? And if yes, what milestones are these and are they listed >>> somewhere? >>> >>> I just found these bugs: >>> >>> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6590301 >>> [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6717462 >>> [3] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6788797 >>> >>> which contain very little information. >>> >>> - Christian >>> >>> > From xenway at gmail.com Tue Dec 30 13:57:33 2008 From: xenway at gmail.com (xenway) Date: Wed, 31 Dec 2008 05:57:33 +0800 Subject: The Interpreter Mechanism? Message-ID: <1fc4689f0812301357w5b7b6563w3405f4c0e2fd7941@mail.gmail.com> Hi, Sorry to bother you all. I am trying to modify the hotspot interpreter to collect some profile data. The main thing I want to do is understand the mechanism of bytecode interpreter. I want to collect some data to the interpreter, especially the lock information whenever an invoke_monitor* bytecode operation is about to executed such that my specific data structure gets updated. Can you please guide me to the part of the code where interpreter works when I use '-Xint' option corresponding to a bytecode operation. I can't figure out how and where it is executed in the interpreter mode. Thanks, Alex Xie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20081231/4dac046b/attachment.html From James.Melvin at Sun.COM Wed Dec 31 00:27:29 2008 From: James.Melvin at Sun.COM (James Melvin) Date: Wed, 31 Dec 2008 03:27:29 -0500 Subject: hg: jdk7/hotspot/hotspot: 6788797: Fork HS14 to HS15 - renumber Major and build numbers of JVM In-Reply-To: References: <20081224033108.85DE7DE81@hg.openjdk.java.net> <1230374549.1229.22.camel@localhost.localdomain> <49568E5A.9060901@sun.com> Message-ID: <495B2CF1.6030400@sun.com> > In this context I've recently realized that some bugs are duplicated > in the bug database. Is this because the same bug appearing in both, > the head trunk and a "stabilization repository", needs two different > bug IDs such that it can be fixed independently in both code lines? > Could this be used to identify changes in the head revision which have > also been made to a stabilized version? Our current bug tracking tool allows for 1 main bug, and possibly several linked bugs for other releases the fix applies. Internally, we refer to these as the "main CR" and it's "sub CRs". Both main CRs and sub CRs have unique bug ids. However, ids for sub CRs start with a number '2' and are inexorably linked to the main CR. So, it might appear to be duplicate bugs, but they are really sub CRs. - Jim Main CR ids start a 6 and sub CRs start with a 2. Volker Simonis wrote: > Hi James, > > thank you for the detailed description. Especially the following part > was quite interesting for me: > > "But it's important to note that any bugs resolved in HS14 *must* be > forward ported to HS15, if applicable. Also, bugfixes made to HS15, > which are deemed critical to HS14, will be considered for backport if > there is sufficient time for full testing." > > How could someone who wants to deliver a "as stable as possible" > release of the OpenJDK HotSpot VM take advantage of this model. Is > there a way to identify changes which are forwarded from the HS14 > branch into the head trunk and the other way round, identify changes > in the head revision which are considered for backporting into HS14? > I.e. will it be possible for an external observer to build something > which is "close" to a Sun-released HotSpot VM from the OpenJDK > repository? > > In this context I've recently realized that some bugs are duplicated > in the bug database. Is this because the same bug appearing in both, > the head trunk and a "stabilization repository", needs two different > bug IDs such that it can be fixed independently in both code lines? > Could this be used to identify changes in the head revision which have > also been made to a stabilized version? > > Thank you and a happy new year, > Volker > > > > On Sat, Dec 27, 2008 at 9:21 PM, James Melvin wrote: >>> ..and what does "Fork" mean in this context. For me this sounds as if >>> the HS14 will continue to live in its own "branch". >> Yes, exactly. A copy ("fork") of the current mainline repository is >> being made for independent stabilization and delivery. This serves 2 >> purposes... >> >> 1) HS14 controlled stabilization and testing for production delivery >> 2) HS15 continues to be open for business, unabated >> >> I imagine this is a familiar development model in Software. >> >> >>> Will this be the "Express" VM which will be integrated into JDK 1.6 >>> eventually? >> Yes. Hotspot now productizes more frequently than the JDK. The idea >> behind "Hotspot Express" is to make the latest stable Hotspot source >> available to stabilizing JDKs for testing and delivery as a matched set. >> Note, this does not imply mix-and-match of binaries however. Fully >> tested pairs only to mitigate risk. >> >> >>> And where will the future development (I assume its more or less bug >>> fixing?) of HS14 take place - will it be an open repository or a >>> closed one? >> I presume closed, subject to OpenJDK6's adoption of HS14. But it's >> important to note that any bugs resolved in HS14 *must* be forward >> ported to HS15, if applicable. Also, bugfixes made to HS15, which are >> deemed critical to HS14, will be considered for backport if there is >> sufficient time for full testing. Security bugs are treated with priority. >> >> I'll take an action item to better document the "Hotspot Express" >> delivery model and make sure it's posted. >> >> >> Hope this helps, >> >> Jim >> >> >> >> Volker Simonis wrote: >>> ..and what does "Fork" mean in this context. For me this sounds as if >>> the HS14 will continue to live in its own "branch". Will this be the >>> "Express" VM which will be integrated into JDK 1.6 eventually? And >>> where will the future development (I assume its more or less bug >>> fixing?) of HS14 take place - will it be an open repository or a >>> closed one? >>> >>> Thanks for the clarifications, >>> Volker >>> >>> On Sat, Dec 27, 2008 at 11:42 AM, Christian Thalinger >>> wrote: >>>> On Wed, 2008-12-24 at 03:31 +0000, erik.trimble at sun.com wrote: >>>>> Changeset: 3cd5c5b027b1 >>>>> Author: trims >>>>> Date: 2008-12-23 19:28 -0800 >>>>> URL: >>>>> http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3cd5c5b027b1 >>>>> >>>>> 6788797: Fork HS14 to HS15 - renumber Major and build numbers of JVM >>>>> Summary: fork Hotspot 15 - redo verisoning numbers >>>>> Reviewed-by: jcoomes >>>>> >>>>> ! make/hotspot_version >>>> Out of curiosity, are there any milestones to bump HotSpot's major >>>> version? And if yes, what milestones are these and are they listed >>>> somewhere? >>>> >>>> I just found these bugs: >>>> >>>> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6590301 >>>> [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6717462 >>>> [3] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6788797 >>>> >>>> which contain very little information. >>>> >>>> - Christian >>>> >>>> From James.Melvin at Sun.COM Wed Dec 31 00:47:14 2008 From: James.Melvin at Sun.COM (James Melvin) Date: Wed, 31 Dec 2008 03:47:14 -0500 Subject: hg: jdk7/hotspot/hotspot: 6788797: Fork HS14 to HS15 - renumber Major and build numbers of JVM In-Reply-To: <495B2CF1.6030400@sun.com> References: <20081224033108.85DE7DE81@hg.openjdk.java.net> <1230374549.1229.22.camel@localhost.localdomain> <49568E5A.9060901@sun.com> <495B2CF1.6030400@sun.com> Message-ID: <495B3192.7070008@sun.com> And, yes. Following main and sub CRs should provide sufficient tracking information for fixes that apply to both the trunk and/or branch releases. Sub CRs typically represent forward or backward ports of the main CR fix. - Jim James Melvin wrote: > > In this context I've recently realized that some bugs are duplicated > > in the bug database. Is this because the same bug appearing in both, > > the head trunk and a "stabilization repository", needs two different > > bug IDs such that it can be fixed independently in both code lines? > > Could this be used to identify changes in the head revision which have > > also been made to a stabilized version? > > Our current bug tracking tool allows for 1 main bug, and possibly > several linked bugs for other releases the fix applies. Internally, we > refer to these as the "main CR" and it's "sub CRs". Both main CRs and > sub CRs have unique bug ids. However, ids for sub CRs start with a > number '2' and are inexorably linked to the main CR. So, it might appear > to be duplicate bugs, but they are really sub CRs. > > - Jim > > > > Main CR ids start a 6 and sub CRs start with a 2. > > > Volker Simonis wrote: >> Hi James, >> >> thank you for the detailed description. Especially the following part >> was quite interesting for me: >> >> "But it's important to note that any bugs resolved in HS14 *must* be >> forward ported to HS15, if applicable. Also, bugfixes made to HS15, >> which are deemed critical to HS14, will be considered for backport if >> there is sufficient time for full testing." >> >> How could someone who wants to deliver a "as stable as possible" >> release of the OpenJDK HotSpot VM take advantage of this model. Is >> there a way to identify changes which are forwarded from the HS14 >> branch into the head trunk and the other way round, identify changes >> in the head revision which are considered for backporting into HS14? >> I.e. will it be possible for an external observer to build something >> which is "close" to a Sun-released HotSpot VM from the OpenJDK >> repository? >> >> In this context I've recently realized that some bugs are duplicated >> in the bug database. Is this because the same bug appearing in both, >> the head trunk and a "stabilization repository", needs two different >> bug IDs such that it can be fixed independently in both code lines? >> Could this be used to identify changes in the head revision which have >> also been made to a stabilized version? >> >> Thank you and a happy new year, >> Volker >> >> >> >> On Sat, Dec 27, 2008 at 9:21 PM, James Melvin >> wrote: >>>> ..and what does "Fork" mean in this context. For me this sounds as if >>>> the HS14 will continue to live in its own "branch". >>> Yes, exactly. A copy ("fork") of the current mainline repository is >>> being made for independent stabilization and delivery. This serves 2 >>> purposes... >>> >>> 1) HS14 controlled stabilization and testing for production delivery >>> 2) HS15 continues to be open for business, unabated >>> >>> I imagine this is a familiar development model in Software. >>> >>> >>>> Will this be the "Express" VM which will be integrated into JDK 1.6 >>>> eventually? >>> Yes. Hotspot now productizes more frequently than the JDK. The idea >>> behind "Hotspot Express" is to make the latest stable Hotspot source >>> available to stabilizing JDKs for testing and delivery as a matched set. >>> Note, this does not imply mix-and-match of binaries however. Fully >>> tested pairs only to mitigate risk. >>> >>> >>>> And where will the future development (I assume its more or less bug >>>> fixing?) of HS14 take place - will it be an open repository or a >>>> closed one? >>> I presume closed, subject to OpenJDK6's adoption of HS14. But it's >>> important to note that any bugs resolved in HS14 *must* be forward >>> ported to HS15, if applicable. Also, bugfixes made to HS15, which are >>> deemed critical to HS14, will be considered for backport if there is >>> sufficient time for full testing. Security bugs are treated with >>> priority. >>> >>> I'll take an action item to better document the "Hotspot Express" >>> delivery model and make sure it's posted. >>> >>> >>> Hope this helps, >>> >>> Jim >>> >>> >>> >>> Volker Simonis wrote: >>>> ..and what does "Fork" mean in this context. For me this sounds as if >>>> the HS14 will continue to live in its own "branch". Will this be the >>>> "Express" VM which will be integrated into JDK 1.6 eventually? And >>>> where will the future development (I assume its more or less bug >>>> fixing?) of HS14 take place - will it be an open repository or a >>>> closed one? >>>> >>>> Thanks for the clarifications, >>>> Volker >>>> >>>> On Sat, Dec 27, 2008 at 11:42 AM, Christian Thalinger >>>> wrote: >>>>> On Wed, 2008-12-24 at 03:31 +0000, erik.trimble at sun.com wrote: >>>>>> Changeset: 3cd5c5b027b1 >>>>>> Author: trims >>>>>> Date: 2008-12-23 19:28 -0800 >>>>>> URL: >>>>>> http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3cd5c5b027b1 >>>>>> >>>>>> 6788797: Fork HS14 to HS15 - renumber Major and build numbers of JVM >>>>>> Summary: fork Hotspot 15 - redo verisoning numbers >>>>>> Reviewed-by: jcoomes >>>>>> >>>>>> ! make/hotspot_version >>>>> Out of curiosity, are there any milestones to bump HotSpot's major >>>>> version? And if yes, what milestones are these and are they listed >>>>> somewhere? >>>>> >>>>> I just found these bugs: >>>>> >>>>> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6590301 >>>>> [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6717462 >>>>> [3] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6788797 >>>>> >>>>> which contain very little information. >>>>> >>>>> - Christian >>>>> >>>>> From groundskeeperwiley at yahoo.com Wed Dec 31 10:32:19 2008 From: groundskeeperwiley at yahoo.com (James Walsh) Date: Wed, 31 Dec 2008 10:32:19 -0800 (PST) Subject: SuperWord optimization References: <535236.3158.qm@web30006.mail.mud.yahoo.com> <4149a0430812231021r7e1a600budf99a1b8be4de070@mail.gmail.com> <657532.97748.qm@web30003.mail.mud.yahoo.com> <4149a0430812290953o43f864f7ve9e3496ef565906b@mail.gmail.com> Message-ID: <148719.53851.qm@web30001.mail.mud.yahoo.com> Is there some documentation of hdl used in x86_32.ad? How would I describe a XMM register as a whole in that language? Obviously MOVAPS, ADDPS, etc and the like will need to reserve a whole XMM register, not just XMM0a etc. Looking at the description of the XMM double register definitions I could probably guess but if there is some official docs it would be nice to take a look at them. The quad word function could probably use a little remider for users to make sure they index into the array a sufficient amount or there could be problems. From yamauchi at google.com Wed Dec 31 17:34:30 2008 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Wed, 31 Dec 2008 17:34:30 -0800 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: References: <17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com> <17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com> <48C9ACD5.7030102@sun.com> <48CAB6DE.8070806@sun.com> <0607D027-8ADD-438B-91FB-A4D0AECAD113@sun.com> <8637E22A-8145-4C06-9E31-E7952FFA5630@Sun.COM> Message-ID: I still hope this patch will be accepted. On Fri, Sep 26, 2008 at 12:55 PM, Hiroshi Yamauchi wrote: > With the patch, I haven't seen it crash in my experience. > > Hiroshi > > On Thu, Sep 25, 2008 at 12:29 PM, Tom Rodriguez > wrote: >>> I'm not sure what you mean by collector. But as far as I can tell >>> AsyncGetCallTrace >>> is a lot more stable and shows more stack frames with the patch. If Sun >>> folks >>> have tests for it, it'd be great if someone can run them against this >>> patch. >> >> I was only referring to testing it with a profiling tool and the SunStudio >> collector is the only one I know of that uses AsyncGetCallTrace. When you >> say "a lot more stable" do you mean it doesn't crash or it crashes less? >> >> tom >> >>> >>> Thanks, >>> Hiroshi >>> >>> >>>> On Sep 17, 2008, at 4:50 PM, Hiroshi Yamauchi wrote: >>>> >>>>> Hi, Any comment about the patch itself? >>>>> >>>>> On Fri, Sep 12, 2008 at 11:37 AM, Joseph D. Darcy >>>>> wrote: >>>>>> >>>>>> Joseph D. Darcy wrote: >>>>>>> >>>>>>> Andrew John Hughes wrote: >>>>>>>> >>>>>>>> 2008/9/11 Andrew John Hughes : >>>>>>>>> >>>>>>>>> 2008/9/11 Daniel D. Daugherty : >>>>>>>>>> >>>>>>>>>> Andrew John Hughes wrote: >>>>>>>>>> >>>>>>>>>> FWIW, I don't see any change to the HS_ version numbers in our >>>>>>>>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot. >>>>>>>>>> Given OpenJDK6 was derived from something like b20, I guess this is >>>>>>>>>> not that strange. >>>>>>>>>> >>>>>>>>>> JDK7-B24 has the following values: >>>>>>>>>> >>>>>>>>>> HS_MAJOR_VER=12 >>>>>>>>>> HS_MINOR_VER=0 >>>>>>>>>> HS_BUILD_NUMBER=01 >>>>>>>>>> >>>>>>>>>> Joe stated earlier in this thread that OpenJDK6 is based on >>>>>>>>>> HSX-10 so its values should not be the same. For 1.6.0_07, >>>>>>>>>> I see: >>>>>>>>>> >>>>>>>>>> HS_MAJOR_VER=10 >>>>>>>>>> HS_MINOR_VER=0 >>>>>>>>>> HS_BUILD_NUMBER=23 >>>>>>>>>> >>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Hmmm... >>>>>>>>> Then either Gary's HotSpot patch doesn't update that file or >>>>>>>>> OpenJDK6 >>>>>>>>> is not based on the same as this 1.6.0_07 thing you mention. >>>>>>>>> I'll try and have a closer look later. >>>>>>>>> -- >>>>>>>>> Andrew :-) >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>>> IcedTea6 contains: >>>>>>>> >>>>>>>> HS_MAJOR_VER=10 >>>>>>>> HS_MINOR_VER=0 >>>>>>>> HS_BUILD_NUMBER=19 >>>>>>>> >>>>>>>> IcedTea/b33 contains: >>>>>>>> >>>>>>>> HS_MAJOR_VER=14 >>>>>>>> HS_MINOR_VER=0 >>>>>>>> HS_BUILD_NUMBER=01 >>>>>>>> >>>>>>>> icedtea-hotspot-6b11-7b24.patch only updates the src code and not >>>>>>>> make/hotspot_version >>>>>>>> so it's actually worryingly building a different version of HotSpot >>>>>>>> from the one it thinks it is. >>>>>>>> It will actually be 12-0-01 as you state, but will report 10-0-19. >>>>>>>> >>>>>>>> Overall, it would be better to always build against the most recent >>>>>>>> stable HotSpot tree if possible >>>>>>>> rather than the one provided by the build drop. Do we know what the >>>>>>>> most stable would be? >>>>>>> >>>>>>> Generally, the HotSpot in the base OpenJDK 6 should be pretty stable. >>>>>>> The >>>>>>> policy I've implemented, >>>>>>> >>>>>>> >>>>>>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-February/000005.html, >>>>>>> for the HotSpot in OpenJDK 6 is to track fixes in the 6 update >>>>>>> releases, >>>>>>> augmented with some other fixes for license corrections, gcc build >>>>>>> issues, >>>>>>> (and the occasional Eclipse crash). The HotSpot in the base OpenJDK 6 >>>>>>> code >>>>>>> base is very close to the HotSpot in the currently shipping 6 update >>>>>>> release. >>>>>> >>>>>> ... and going forward we will have much closer coordination between the >>>>>> OpenJDK 6 and 6 update HotSpots since we'll be using the same source >>>>>> for >>>>>> both; so the version information should be updated consistently, etc. >>>>>> >>>>>> >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-September/000150.html >>>>>> >>>>>> -Joe >>>>>> >>>> >>>> >> >> > From John.Rose at Sun.COM Wed Dec 31 20:01:41 2008 From: John.Rose at Sun.COM (John Rose) Date: Wed, 31 Dec 2008 20:01:41 -0800 Subject: SuperWord optimization In-Reply-To: <148719.53851.qm@web30001.mail.mud.yahoo.com> References: <535236.3158.qm@web30006.mail.mud.yahoo.com> <4149a0430812231021r7e1a600budf99a1b8be4de070@mail.gmail.com> <657532.97748.qm@web30003.mail.mud.yahoo.com> <4149a0430812290953o43f864f7ve9e3496ef565906b@mail.gmail.com> <148719.53851.qm@web30001.mail.mud.yahoo.com> Message-ID: <7D161C9E-CD80-464C-9D2F-507FA600DEDF@sun.com> On Dec 31, 2008, at 10:32 AM, James Walsh wrote: > Is there some documentation of hdl used in x86_32.ad? How would I > describe a XMM register as a whole in that language? The AD file describes machine registers in terms of 32-bit chunks. Each (named) chunk corresponds to a bit position in the register allocator's bitmasks. Stack frame slots are numbered also in the same uniform scheme, so it doesn't make sense to have some chunks be 128 bits, etc. That is why the AD file talks about parts [abcd] of the 128-bit XMM regs. The upside of this decision to standardize on a 32-bit unit is the spill and memory allocation logic (always a tricky part of register allocation) is simplified. Stack slots do not need to be typed; they are just 32-bit words. Another upside is that multi-purpose machine registers (e.g., two-floats-in-a-double or a long-in-two-ints) can also be represented readily. The downside of this is that 64-bit entities must be represented using (contiguous, aligned) register pairs. The register allocation logic is somewhat complicated by the need to work with such register pairs. Generalizing the code further to 128-bit entities is a moderately tricky problem, but I think that's what has to be done. The register allocation has an "ideal reg" query on each node which discloses what kind of register to allocate. The upshot of this query is (a) a mask of possible hardware register resources where the result has to live, and (b) whether the ultimate allocation is a single 32-bit unit or a (contiguous, aligned) pair. To cope with vectors, the system needs at least one new "ideal reg" type per vector size, perhaps an RegV4 (for XMM) or RegV8 (for YMM). The RegL probably will continue to serve well as a RegV2. > Obviously > MOVAPS, ADDPS, etc and the like will need to reserve a whole XMM > register, not just XMM0a etc. Looking at the description of the XMM > double register definitions I could probably guess but if there is > some > official docs it would be nice to take a look at them. Happy New Year! -- John